メールアカウント乗っ取り系のSPAM送信

ある日、メールの送信失敗率が急上昇した。
qmailsend-week-mod
(上記画像は対処して落ち着いた後に取ったもの)

慌ててメールキューを確認するとエラーメールが大量に・・・

調べてみると、全てある1ユーザに関するもの。
ログを確認していくと、そのユーザが、さまざまなIPアドレスからSMTP認証をかけてきて、認証に成功した上でSPAM送信が行われているじゃないですか。

Jul 22 18:47:21 mailserver qmail: 1374486441.012502 starting delivery 77399: msg 90220 to local example.com-hello@example.com
Jul 22 18:47:21 mailserver qmail: 1374486441.012529 status: local 2/100 remote 0/50
Jul 22 18:47:21 mailserver spamd[937]: spamd: connection from localhost.localdomain [127.0.0.1] at port 43120
Jul 22 18:47:21 mailserver spamd[937]: spamd: handle_user unable to find user: 'hello@example.com'
Jul 22 18:47:21 mailserver spamd[937]: spamd: processing message <201307220947.r6M9lLNe013087@mailserver.example.com> for hello@example.com:109
Jul 22 18:47:26 mailserver spamd[937]: spamd: clean message (0.0/18.0) for hello@example.com:109 in 5.9 seconds, 2050 bytes.
Jul 22 18:47:26 mailserver spamd[937]: spamd: result: . 0 - AWL,BAYES_20,CONTENT_TYPE_PRESENT,INVALIDYAHOOJP,ISO2022JP_BODY,ISO2022JP_CHARSET,SUBJECT_NEEDS_ENCODING,SUBJ_ILLEGAL_CHARS,URI_HEX scantime=5.9,size=2050,user=hello@example.com,uid=109,required_score=18.0,rhost=localhost.localdomain,raddr=127.0.0.1,rport=43120,mid=<201307220947.r6M9lLNe013087@mailserver.example.com>,bayes=0.090684,autolearn=disabled
Jul 22 18:52:46 mailserver vpopmail[17115]: vchkpw-submission: (PLAIN) login success hello@example.com:83.242.101.27
Jul 22 18:52:57 mailserver qmail: 1374486777.611039 new msg 90219
Jul 22 18:52:57 mailserver qmail: 1374486777.611077 info msg 90219: bytes 1364 from <hello@example.com> qp 17121 uid 103
Jul 22 18:52:57 mailserver qmail: 1374486777.638528 starting delivery 77421: msg 90219 to remote ~@~
Jul 22 18:52:57 mailserver qmail: 1374486777.638582 status: local 0/100 remote 1/50
Jul 22 18:52:57 mailserver qmail: 1374486777.641128 starting delivery 77422: msg 90219 to remote ~@~
Jul 22 18:52:57 mailserver qmail: 1374486777.641155 status: local 0/100 remote 2/50
Jul 22 18:52:57 mailserver qmail: 1374486777.641173 starting delivery 77423: msg 90219 to remote ~@~
Jul 22 18:52:57 mailserver qmail: 1374486777.641192 status: local 0/100 remote 3/50
Jul 22 18:52:57 mailserver qmail: 1374486777.641314 starting delivery 77424: msg 90219 to remote ~@~
Jul 22 18:52:57 mailserver qmail: 1374486777.641339 status: local 0/100 remote 4/50
Jul 22 18:52:57 mailserver qmail: 1374486777.641518 starting delivery 77425: msg 90219 to remote ~@~
Jul 22 18:52:57 mailserver qmail: 1374486777.641543 status: local 0/100 remote 5/50

そう、そのユーザのメールアカウント情報がどこかで漏れ、SPAMシステムに投入されたようなのです。

とりあえず、該当アカウントのパスワード変更し、メールキュー内のエラーメール群を消去したあと、対処開始。

確認すると、約24時間の間に、880のIPアドレスからSMTP認証のloginが行われているという事態。
また、ほとんどのIPアドレスからは1回しかアクセスがなかったので、相当大規模なシステムである模様。

# cat /var/log/maillog.? |grep vchkpw-submission|grep hello@example.com|grep succ|awk '{ print $10 }'|awk -F: '{ print $2 }' |sort|uniq -c|sort|wc
    880    1760   19476
# cat /var/log/maillog.? |grep vchkpw-submission|grep hello@example.com|grep succ|awk '{ print $10 }'|awk -F: '{ print $2 }' |sort|uniq -c|sort | tail
      2 93.85.128.230
      2 94.156.244.75
      2 94.170.246.170
      2 94.180.194.222
      2 95.52.132.238
      3 178.125.185.161
      3 46.118.66.80
      3 93.175.125.67
      3 93.78.3.92
      3 95.42.37.153
#

そんな確認を行っていると、30分が経過。
すると、いままで出ていた「password fail」のログが消えた。
そう、どうやらSPAM送信システム側で、このサーバでは送れない、という認識がされたようだ。

これで終わりかな?と思ったのですが、その後も12時間ごとに10回のメール送信を試みてる形跡が確認されています。

Jul 24 07:11:42 mailserver vpopmail[32749]: vchkpw-submission: password fail hello@example.com:91.225.163.32
Jul 24 07:16:21 mailserver vpopmail[1287]: vchkpw-submission: password fail hello@example.com:89.74.114.28
Jul 24 07:20:57 mailserver vpopmail[2147]: vchkpw-submission: password fail hello@example.com:192.162.224.10
Jul 24 19:13:23 mailserver vpopmail[8339]: vchkpw-submission: password fail hello@example.com:94.139.211.248
Jul 24 19:18:54 mailserver vpopmail[9449]: vchkpw-submission: password fail hello@example.com:178.120.193.67
Jul 24 19:24:18 mailserver vpopmail[10359]: vchkpw-submission: password fail hello@example.com:178.127.107.5
Jul 24 19:29:58 mailserver vpopmail[11422]: vchkpw-submission: password fail hello@example.com:114.41.229.41
Jul 24 19:35:23 mailserver vpopmail[13866]: vchkpw-submission: password fail hello@example.com:178.122.175.143
Jul 24 19:40:48 mailserver vpopmail[14894]: vchkpw-submission: password fail hello@example.com:46.211.194.44
Jul 24 19:46:03 mailserver vpopmail[16036]: vchkpw-submission: password fail hello@example.com:91.230.30.142
Jul 24 19:56:39 mailserver vpopmail[18000]: vchkpw-submission: password fail hello@example.com:176.115.59.82
Jul 24 20:02:02 mailserver vpopmail[19925]: vchkpw-submission: password fail hello@example.com:37.215.9.145
Jul 24 20:12:06 mailserver vpopmail[21887]: vchkpw-submission: password fail hello@example.com:115.187.55.14

いまさらNanonoteについてと、ついでにGCW-ZERO、あとKDEタブレット

Slaanesh Dev
DOSBoxというMS-DOSのソフトウェアを動かすためのソフトをBen Nanonoteに移植
DOSBox 0.74 v2.0 A320 Open Dingux and Ben Nanonote OpenWRT
まぁ、ここでいうMS-DOSのソフトとは、ゲームのことです。
「A320」というのは、「Dingoo A320」というLinuxのゲーム機です。
ハードウェア的にはかなり似てる点があります。

自動生成型ダンジョンの元祖Rogue(ローグ)と、その発展系Nethackの移植版
Nethack 3.4.3 and Rogue for Ben Nanonote
Nethackをさらに進化させてったものが、風来のシレンとかポケモンダンジョンになります。

・Jirka’s notesの「カテゴリー Nanonote
いまでも使ってるようで、いろいろ日記的なものを書いていますね。

GCW-ZERO
Jz4770搭載のLinux系ゲーム機。
Dingoo A320の後継機みたいなもの。
最初はほそぼそとやっていて、2012年10月頃に初期出荷をしたあと、「kickstarterで募集」したら大規模になっちゃっていろいろ大変だったみたいです。
今月になってようやくkickstarter分の発送が終わったようですね。
GCW-ZERO firmwareアップデートを見ると、firmwareの更新も順調そうですね。

KDE Tablet 「Flying Squirrel」製造計画(英語)
Nanonoteとは関係ないけど、メーリングリストを見ていたら出てきたので紹介。

EOMA-68というフォームファクターのCPUカードを使用したKDE搭載のタブレットを製造しようとしている。
進捗状況」を見ると、試作基板はできており、5月には第2次試作基板製造に向けた調整を行っていたようだ。
overlay

なお、EOMA-68は、物理形状はPCMCIAカードを流用している。

小型デジタルトランシーバX1p

中華サイトを見ていたら、トランシーバーX1pというもの広告を見かけた。
広告

Hytera(英語)/海能达通信股份有限公司(中国語)という会社の「X1p(英語製品のページ)」というのだった。

アナログ&デジタル対応
デジタル側は「ETSI Digital Mobile Radio(DMR)準拠」で、AES暗号化対応
アナログ側は特に明記がないが「アナログからデジタルへのスムースなマイグレートを可能にする」といううたい文句があるため、「Analogue Private Mobile Radio(PMR)準拠」と思われる。

まぁ、ようは、デジタル特定小電力(特小)ってことですね。

で・・・これ、いくらなんだろ?と調べてみたら

1個、600ドルとかするらしい
想像以上に高くてびっくり。

よくよく調べてみると、本気の業務向けで、GPSを使った位置情報送信システムも組み込めるとか。

日本で、遊びとして使うには合わない感じですね。

IP67防水
耐環境性試験MIL-STD-810 C/D/E/F/G準拠
USBでfirmware書き換え可能
Bluetoothレシーバ対応
GPSモジュールの組み込み対応(オプション対応)
バイブレーション機能あり
7.4V 「1100mAh」か「1800mAh」のバッテリー搭載で、アナログ時12時間、デジタル時15時間の利用可
1100mAhバッテリーの場合は21mm厚で240g、1800mAhは26mm厚で280g
1.8インチ 160×128 TFT液晶搭載

対応周波数: VHF側 136~174MHz、UHF側は3種類「400~470MHz」「450~520MHz」「350~400MHz」
周波数ステップは25/20/12.5KHz
出力 VHF 5W/1W、UHF 4W/1W

対応電波形式
アナログFM
・11K0F3E @ 12.5KHz
・14K0F3E @ 20KHz
・16K0F3E @ 25KHz
デジタル 4FSK Digital Modulation
・12.5kHz Data Only: 7K60FXD
・12.5kHz Data & Voice: 7K60FXW

対応プロトコル
・ETSI-TS102 361-1, 2&3

MediaTek MT6592(Cortex-A7 8コア)のGPUはMali 4コアになる?

MediaTek/MTK MT6592が使用するGPUは、いままでMediaTekが採用してきたImagination PowerVR SGX554MPシリーズではなく、ARM Maliシリーズになる、という話が出ているようです。

ネタ元:MTK手机网「MT6592采用ARM MALI四核图形处理器

MT6592は、ARM Cortex-A7 8コアで、GPUはPowerVR SGX554MPだと従来言われてきました。
それが最近の情報では、ARM Mali 4コアに切り替わる、という話になっているようです。

もうすぐリリース、とか言われているこの状況で、ほんとにGPUが切り替わるのか、というのが謎ですが、もし、ホントであれば、なかなか面白い感じですね。

USB電力計 サンワサプライ TAP-TST10をLinuxで使ってみた

サンワサプライから発売された「ワットモニターUSB TAP-TST10」というUSB接続タイプの電力計をLinuxで使ってみた。

埜中公博さんの「SANWA SUPPLY TAP-TST10 control tool」を使ってデータ取得しました。
githubにある「taptst10ctl.py」をCentOS6で動作させてみました。
(2013/11/19: 公開場所が変わりました「https://github.com/nonakap/taptst10ctl」。USBのデバイスへのアクセス手法の違いで「taptst10ctl.py」と「taptst10ctl0.py」があります)

# python taptst10ctl.py
Traceback (most recent call last):
  File "taptst10ctl.py", line 42, in <module>
    import usb.core
ImportError: No module named usb.core
#

あー・・・pyusbが入ってないからか・・・
pyusb-1.0.0a2.zipをダウンロードしてきて「python setup.py install」

# python taptst10ctl.py
Traceback (most recent call last):
  File "taptst10ctl.py", line 60, in <module>
    dev.set_configuration()
  File "/usr/lib/python2.6/site-packages/usb/core.py", line 547, in set_configuration
    self._ctx.managed_set_configuration(self, configuration)
  File "/usr/lib/python2.6/site-packages/usb/core.py", line 92, in managed_set_configuration
    self.backend.set_configuration(self.handle, cfg.bConfigurationValue)
  File "/usr/lib/python2.6/site-packages/usb/backend/libusb10.py", line 503, in set_configuration
    _check(_lib.libusb_set_configuration(dev_handle, config_value))
  File "/usr/lib/python2.6/site-packages/usb/backend/libusb10.py", line 403, in _check
    raise USBError(_str_error[ret], ret, _libusb_errno[ret])
usb.core.USBError: [Errno 16] Resource busy
#

「Resource busy」と何か別のプログラムが使っているらしい。

USBRH driver for Linux を CentOS 5 で使う」で紹介されている手法、手動でusbhidの認識を解除してみる方法を行ってみた。

# cd /sys/bus/usb/drivers/usbhid
#  ls -l
lrwxrwxrwx 1 root root    0  7月 17 09:38 2013 4-2:1.0 -> ../../../../devices/pci0000:00/0000:00:12.1/usb4/4-2/4-2:1.0
--w------- 1 root root 4096  7月 17 09:25 2013 bind
lrwxrwxrwx 1 root root    0  7月 17 09:25 2013 module -> ../../../../module/usbhid
--w------- 1 root root 4096  7月 17 09:25 2013 new_id
--w------- 1 root root 4096  7月 17 09:25 2013 remove_id
--w------- 1 root root 4096  7月 17 09:25 2013 uevent
--w------- 1 root root 4096  7月 17 09:25 2013 unbind
# echo "4-2:1.0" > unbind
# ls
bind  module  new_id  remove_id  uevent  unbind
#

これでusbhidを解除できたので、改めて実行。

# .taptst10ctl.py
No.,DateTime,Watt,kWh
1,2013/07/13 07:50,0.0,0.00
2,2013/07/13 08:00,47.0,0.00
3,2013/07/13 08:10,44.8,0.01
4,2013/07/13 08:20,18.5,0.01
5,2013/07/13 08:30,18.5,0.01
6,2013/07/13 08:40,18.1,0.02
<略>
637,2013/07/17 18:00,87.4,2.76
638,2013/07/17 18:10,83.8,2.78
639,2013/07/17 18:20,83.3,2.79
640,2013/07/17 18:30,82.8,2.80
641,2013/07/17 18:40,80.9,2.82
#

ちなみに、時々、以下のような感じで実行に失敗します。
その場合は、再実行すれば、だいたい大丈夫です。

# ./taptst10ctl.py
Traceback (most recent call last):
  File "./taptst10ctl.py", line 92, in <module>
    data = dev.read(ENDPOINT, 17, intf, 1000)
  File "/usr/lib/python2.6/site-packages/usb/core.py", line 654, in read
    self.__get_timeout(timeout)
  File "/usr/lib/python2.6/site-packages/usb/backend/libusb10.py", line 559, in intr_read
    timeout)
  File "/usr/lib/python2.6/site-packages/usb/backend/libusb10.py", line 641, in __read
    timeout))
  File "/usr/lib/python2.6/site-packages/usb/backend/libusb10.py", line 403, in _check
    raise USBError(_str_error[ret], ret, _libusb_errno[ret])
usb.core.USBError: [Errno 110] Operation timed out
#