モーグルとカバとパウダーの日記

モーグルやカバ(EXカービング)山スキー(BC)などがメインの日記でした。今は仕事のコンピュータ系のネタが主になっています。以前はスパム対策関連が多かったのですが最近はディープラーニング関連が多めです。

長野ディープラーニング同好会 #10

ディープラーニング同好会10回め開催しました。

長野ディープラーニング同好会 #10

第9回の続きで、学習の概念は説明したけども、じゃあ実際の実装はどうやってるの?というのを実際に実装してもらって確認しました。
一応、パーセプトロンの主要部分となるコードを書いていただいて、MNISTの認識を試してみることができました。
この辺のサンプルコードは2年前にやったディープラーニングハンズオンのほぼそのままなのですが、こういうのは変わらないからいいですね。

ただ、手で計算してもらって、その次にそのアルゴリズムをそのままpythonで実装して…という流れの資料にしていたのを、時間なくて端折って説明してしまったので、駆け足すぎた感じになったように思います。
たぶんColabとpython説明で1時間、パーセプトロンの学習方法復習して手で学習するので1時間、パーセプトロンの実装のところ1時間という感じで時間かけるべきなんだろうと感じました。

次回はこの続きで、活性化関数をシグモイドにかえて、前々回に説明した勾配降下法を使った式に変更し、その式の出し方も少し追いながら実装してテストできればと思います。

長野ディープラーニング同好会 #9

ディープラーニング同好会9回め開催しました。

長野ディープラーニング同好会 #9

第8回に引き続きで、ニューラルネットディープラーニングそのものについての解説ということでバックプロパゲーションとはなにをしているものなのか、を説明しました。
バックプロパゲーションの基本的な考えとして、教師信号とネットワークの出力の誤差をLとするとき、その誤差Lはネットワーク全体をfとすると重みWを変数とした関数の値、L=f(W)と考えられるので、その誤差Lを減らしていくのが学習、ということをあらためて説明しました。
そう考えると、初期値のWから誤差を減らすためには、fを微分して減る方向へWを動かす、ということを模式的なグラフを書くことで、感覚的に理解してもらえるよう、説明しました。
また、入力が1つしかないような非常に簡単なニューラルネットワークを考えてみて、それが数式で書くことが出来ること、多段になってもやはり数式で書けること、それをwで偏微分できること、なんかを説明しました。

その後、CNNの基本構造について説明しました。
これは畳み込み層の話を、先祖であるネオコグニトロンの考えから、特徴を抽出するためのフィルタであると考えれば良い、ということで説明しました。

今回はちょっとだけ数式を使って説明をしたのですが、このくらいだったら大丈夫だろう、という感じだったのですが、参加されたみなさんがどう感じられたのかはわからないのでちょっと不安です。

次回はこの続きで、パーセプトロンの学習方法を再確認して、そのアルゴリズムを実装したいと思います。
また、バックプロパゲーションへの入り口として、活性化関数をシグモイドやReLUにして1段だけのパーセプトロン(活性化関数が階段関数以外のものはパーセプトロンとは呼んじゃダメなのかな?)に拡張するところまでやりたいと思います。

長野ディープラーニング同好会 #8

ちなみにもう年明けてしまって、1/7になってこのエントリ書いてます。

ディープラーニング同好会8回め開催しました。

長野ディープラーニング同好会 #8

第7回に引き続きで来ていただいた方が多く、ニューラルネットディープラーニングそのものについての解説をしたほうがよさそう、ということを考えて、急遽、以前ディープラーニングハンズオンで説明したような内容を圧縮して説明する、ということをしました。
パーセプトロンの仕組みと学習の方法、あとバックプロパゲーションにつなぐため、ネットワーク全体の重みWを変数としたときに誤差を減らしていく=学習、ということや誤差を減らすために微分して減る方向へWを動かす、ということなんかを説明させていただきました。

次回はこの続きで、多層ネットワークでも関数の組み合わせで表現可能であることから、バックプロパゲーションの手法が複雑なネットワークやBatch Normalizationのような手法でもそのまま利用できること、なんかを説明できたらいいなと思っています。

身に覚えのないDNSBL登録の理由

これは「メール Advent Calendar 2018」のために書かれたエントリです。

スパムが出てないのにDNSBLに登録されてしまう

DNSBLというDNSを用いた公開ブラックリストサービスがあります。SORBSやSpamCopあたりが有名です。
DNSBLは、正しくはスパマーの使っているbot等のIPアドレスだけが登録されているべきなのですが、誤って通常のメールサーバがDNSBLに登録されてしまう場合があります。
最近では、サブミッションスパムによりそのメールサーバから大量スパムメールが出されて、登録されてしまう場合が多いです。

しかし時々、全くそのような大量スパムメールが出されたわけではないのにDNSBLに登録されてしまう場合がありました。

そういうなにもしていないのに登録されている場合、近隣のIPでスパムを出したサーバがあったとき、IPアドレス帯でまきこまれて登録されてしまうことが多いです。

DNSBLではたいてい、そのIPアドレスブラックリストに登録されているか確認出来るようになっています。
その情報を確認すると、IPアドレス帯で登録されたわけではなく、確かにそのメールサーバから出されたメールが原因で登録されたものでした。

届いたスパムをエラーメールで返したもので登録されている

DNSBLによっては、どのメールが引き金となって登録されたのか確認出来るようになっています。

またDNSBLでは、ハニーポットという「おとり」のメールアドレスを使って、そこにメールが届いた場合、その発信元IPをブラックリストに入れてしまうものがあります。
ハニーポットのメールアドレスがスパマーにバレてしまうと、そのメールアドレスを避けて送るようにされてしまう可能性があるため、どのメールアドレスかは秘匿して運用されています。
そのため、どのメールにより登録されたかという情報は、日時を範囲にしたり、メールアドレスは一部をマスクしたりして、ハニーポットのメールアドレスがわからないように提示されています。

該当のブラックリスト登録情報を確認したところ、日時は前後5分内ということでぼかされており、メールアドレスは下記のようにマスクされていました。

dov**********************-0@************

ただ、非常に特徴的なメールアドレスだったため、ログから確認すると、宛先のスプールがいっぱいのため dovecot がエラーメールを返したものだと確定することが出来ました。

また、そのエラーメールの元となったメールのfromメールアドレスを確認すると、下記のようなメールアドレスでした。(一部マスクしています)

yvfks****+err22****139@ksulde.com

このドメインでぐぐってみたところ、下記のような日本語スパムであることがわかりました。

【本日限り】2択クイズ正解で総額1億円プレゼント
⇒ http : //ksulde.com/qow/swmc8.php?tb=****

いつもメールをお読みくださりありがとうございます。

今日は、いつも仲良くさせて頂いているGive to Win運営事務局の馬場さんから
スペシャルなプレゼント企画がある」ということで、ご案内を頂きました。
(以下略)

【誰でも1億円!】ミリオネアクイズ開催中!???: 気まぐれ日記

つまり、届いた日本語スパムをエラーメールで返したところ、それを理由としてDNSBLに登録されてしまった、ということになります。

(itochanさんのブックマークコメントいただいた件で補足追記)

このスパムは、日本語スパムでよくある、適当なドメインを大量取得して、そのドメインでWebとメールサーバとを動かしているタイプのものです。
なのでスパムに対して返信するとちゃんとメールが届くようになっています。
fromメールアドレスにはシリアル値が付加されているため、どのメールアドレスに送った返事なのかもわかるようになっていると考えられます。

スパマーDNSBLへ通報されている

そこで、なぜdovecotのエラーメールでブラックリスト登録されてしまうのか、考えてみました。

  1. エラーメールの返した先がDNSBLハニーポットだった
  2. エラーメールを受け取ったところがスパム判定してDNSBLに通報した

最初、届いていたスパムが日本語スパムだと気が付かなかったので、【1】のbotDNSBLハニーポットのメールアドレスを騙ってきているのでは、と考えました。なんていやらしいことしてくるんだ、と。

が、日本語スパムの場合、そんな手の込んだことをしてくるとは思えず、そうすると【2】のエラーメールが返ってきたものを、スパムフィルタにより自動でDNSBLへ通報してしまったのではないか、と考えました。
例えばSpamAssassinだと、スパム判定したものを自動でSpamCopにレポートするプラグインがあります。
Mail::SpamAssassin::Plugin::SpamCop - perform SpamCop reporting of messages

たぶんこちらのほうがありそうでしょう。
出会い系などの日本語スパムは、スパムに返信されてきたら人力でテンプレの返答を返して、ユーザ登録なりなんらかの振り込みをさせるよう誘導します。
でも当然大量にエラーメール等も届くはずで、それをなんらかのフィルタで選り分けている可能性は高いと思います。
そこでスパムフィルタが効いていると、自分が送ったメールの内容でスパム判定され、そのエラーメールの送り元=スパムの送り先メールサーバを自動通報してしまっている、というわけです。

非常にげんなりしてしまう話ですが、まったく身に覚えのないDNSBL登録にあったら、この可能性も考えてみるといいでしょう。

サブミッションスパムの手法変遷

これは「メール Advent Calendar 2018」のために書かれたエントリです。

また元ネタは今年の6月に開かれたNSEGという長野の勉強会で発表した内容の後半にあります。

NSEG 勉強会 #101 / メールとコミュニケーションツール - connpass
スパム対策お焚き上げ

今北産業

  • サブミッションスパムはここ2,3年ですごい増えた
  • アカウントはサブミッションポートへの辞書攻撃で取られるようになった
  • ばれないようにちょっとづつ送ったりするようにもなった

はじめに

今から6年半前の2012/5頃に、サブミッションスパムというあたらしいタイプのスパム送信方法で送られたスパムにより、各ISPのメールサーバに障害起きたりする事例がありました。

「サブミッションスパム」による5/15〜16のメール障害の解説と対策

これは、クラックしたアカウントを使い、サブミッションポートでユーザ認証したアカウントからスパムを出されたことから、そう名前を付けたものです。

その後自分は、tarpittingを利用したサブミッションスパムへの対策方法などのエントリも書いたりしています。

Postfixでのサブミッションスパムの簡易対策方法

一時は下火となっていたサブミッションスパムでしたが、ここ2,3年くらいで再度増えてきており、その手法が細かなところで違ってきているため、その説明をします。

アカウントの取得方法の変化

2012/5当時のエントリーでは

どうやってアカウントを取得したか
どうやってユーザのアカウントを取得したかは、具体的な証拠はありませんが、状況からみて以前に該当ユーザのPCにウイルスを感染させて取得した可能性が高いと考えられます。

「サブミッションスパム」による5/15〜16のメール障害の解説と対策

と書いていました。

これは使われたアカウントがバラバラでパスワードも脆弱とは考えにくいもので、またPOP3やSubmissionポートへの辞書攻撃らしいアクセスも残っていなかったためでした。

最近サブミッションスパムでやられているアカウントを調査すると、サブミッションポートに対して辞書攻撃が行われているようで、同一アカウントに対して複数の海外IPから認証が行われ、パスワードのエラーが起きていることが確認できます。
そしてそのIPからの認証が通ってしまうと、数時間後に別のIPからサブミッションでの認証が行われ、スパムの大量送信が行われます。ちなみにこの送信時には、動的IPではなくてクラウドサーバが使われていることが多いようです。

サブミッションポートに対してのエラー数をカウントしてみました。

f:id:stealthinu:20181211154252p:plain

ここ数年で急激にサブミッションポートに対しての辞書攻撃が増えていることがわかります。

これはサブミッションでなくPOP3などでもよいはずですが、サブミッションのほうが狙われているようです。
この手のブルートフォースに対してPOP3よりサブミッションのほうが対策されていない可能性が高いからでは、と推測しています。

こっそり送る

クラックされたアカウントを事前に検知できないか調査していて、おもしろいことに気が付きました。

サブミッションスパム送信元と同じクラウドサーバのIPから送信が行われているのに、大量メール送信ではなくてちょっとづつ(10件程度とか)をときどき送信しているものがあるのです。
送信しているメールの内容を確認できないため、スパムが送られているのかどうかはわかりませんが、送信先などから考えてもほぼ間違いなくスパムが送られていると考えられました。

これまでサブミッションスパムは、クラックしたアカウントで一気に大量のスパムを出して、メールサーバ管理者に見つかってアカウントを止められる、という運用のされ方でした。
それが、監視ツールのアラートが上がらない程度に「こっそり」と送ることで、息が長くアカウントを使えるようにしているものもある、ということです。

サブミッションスパムはつらい

サブミッションスパムによる大量スパム送信はサーバに負荷がかかります。
メールスプールに大量にメールが溜まったり、エラーメールが大量に返ってきたりするためです。
一番つらいのがDNSBLへ登録されてエラーで弾かれるようになって、他のユーザからメールが届かなくなったと言わることです。
先日の迷惑メールカンファレンスでもサブミッションスパムの件がよくネタに出てきていました。ほんとなんとかならんもんでしょうかね。

長野ディープラーニング同好会 #7

ディープラーニング同好会7回め開催しました。

長野ディープラーニング同好会 #7 https://nseg.connpass.com/event/111342/

今回は結構人数が多く6人で、今回はじめて参加された方が3人いらしたので、Colabの使い方とか簡単なネットワークの書き方とかのおさらいをしました。
Colabがすごい便利で、TPUがめっちゃ速い!ということをみんなで体感できたのでよかったです。

なんやかやで結構もりあがりました。
やはりこのくらい人数いたほうがいいなあ、と思います。というかこのくらいだとちょうどいい感じ。

次回、続きみたいな感じになるなら、最初にColab使ってディープラーニング試しはじめる感じのノートを準備しておかないとな、と思いました。
今あるやつはちょっと古くて、TPU動かすようになっていなかったり、Sequentialだけで書いてあったりするので。

やっぱ、初顔合わせの方が居た時に簡単に自己紹介をするようにしたのはよかったと思います。
あと、最後クロージングで今回の感想とか次こんなのしたい、みたいなの言ってもらうようにしてみたんですが、これもよかったように思います。

botからのスパム送信の推移とSMTPセッションフィルタの終焉

これは「メール Advent Calendar 2018」のために書かれたエントリです。

元ネタは今年の6月に開かれたNSEGという長野の勉強会で発表した内容です。
勉強会の動画も上がってますので興味持たれた方はこちらもぜひ。

NSEG 勉強会 #101 / メールとコミュニケーションツール - connpass
スパム対策お焚き上げ

今北産業

  • botnetから送られるスパムが激減した
  • SMTPセッションフィルタでのスパム対策は不要になりつつある
  • 諸行無常

はじめに

自分は2006年頃から taRgrey というスパム対策手法を提案しています。

taRgrey - S25R + tarpitting + greylisting (tarpit + greylist policy server)

これはSMTPセッション中のクライアントの特徴を利用するフィルタをいくつか組み合わせた手法で、 S25Rtarpittinggreylisting を組み合わせて、誤検出や副作用をなるべく少なくすることを狙ったものです。

ただ、近年スパムの数も徐々に減ってきており、また徐々に効果が少なくなってきたと感じていました。

そこでSMTPセッションフィルタがどの程度効果が出ているのか、2010年から2018年にかけての推移を確認しました。

2010年当時のスパム状況

2010年当時はまだスパム全盛期でまだ増えていく感じがありました。
特にbotnetというウイルスに感染したPCを大量に遠隔で操作し、そこから大量にスパムを出すのが主な手法でした。
ただ、OP25Bの広まりやSNS等の他の連絡手段の普及もあり、徐々に変化が起こりつつあった状況でした。

  • スパム率70%~80%程度という感じで年々増えていた
  • 97%前後がbotnetから出されたスパムだった
  • 日本発のスパムはOP25Bにより激減していた

下記表は、2010年当時の実測スパム比率と、S25Rのマッチ率≒botからのスパム送信率、tarpitting(遅延)を掛けた場合のスパム駆除(あきらめて切断される)率、同taRgreyでの駆除率です。
9割以上がbotから出されており、そのためbotに対してのスパム判定がうまくいけば高い比率で対策となっていたことがわかります。

スパム率 69%
S25Rのスパムマッチ率 93%
tarpittingでの駆除率 91%
taRgreyでの駆除率 85%

2012~2018年の状況推移

あるメールサーバで、メールの受信数や各スパムフィルタでのスパム判定数から、botからのスパムメール送信数推移を定点観測しました。

メール総数とスパム数

まず基本となるメール総数とスパム数の推移です。1メールアドレスあたりの月平均受信数です。
スパムが減っているため、メール総数が減っていることがわかります。

アカウントあたり 2014年まで 2018年現在
メール数 2,500通/月ほど 1,000通/月弱
スパム数 2,000通/月ほど 500通/月ほど

f:id:stealthinu:20181204160446p:plain

スパム率

スパム比率の推移をグラフにしました。
ここ数年で一気にスパム比率が少なくなったことがわかります。(と言ってもまだ半分がスパムですが)

f:id:stealthinu:20181204160459p:plain

  • 2014年くらいまでずっと75%くらいだった
  • その後徐々に低下し2018年には50%を切る

メール総数とハム数

正常なメール(ハム)の数は意外に減っておらず、横ばいでほぼ変わっていないことがわかります。
メールマガジンなど、DMの需要はまだ減っていないのだろうと思われます。

f:id:stealthinu:20181204160441p:plain

減ったスパムの種類

スパムはここ3,4年で大きく減っており、意外に普通のメール流量は減っていないことがわかりました。

それではどんなスパムが減ったのでしょうか。

動的IPからと推測される接続推移

S25Rに引っかかるような、逆引き名が動的IPっぽい接続はbotからである可能性が高いと推測でき、それらbotからと思われる接続はここ数年で激減していることがわかります。
またtarpittingで切断された件数も同様に減少しています。

f:id:stealthinu:20181205180721p:plain

  • S25Rに掛かる接続元は70%減程度に激減
  • tarpittingで切断されたメール数も合わせて減少

tarpittingでの切断率推移

動的IPからと思われる接続でtarpittingで切断された率も急激に減少しています。

f:id:stealthinu:20181204155731p:plain

  • 2014年くらいまでずっと80%程度だった
  • その後2018年には30%にまで急激に低下

S25Rに引っかかるものすべてがbotなわけではなく、メールマガジンの大量発信やクラウドサーバから出されているものが誤検出している場合があります。
それらはtarpittingを抜けるため、botが減ったことで相対的にそちらの比率があがり、切断率が下がったのではないかと考えられます。

tarpittingを抜けれなかったものだけがbotと考えると、botからの接続は最盛期より10%程度にまで減ったと考えられます。

SMTPセッションフィルタの有効度推移

このサーバではメールの中身で判定するコンテンツフィルタも利用でき、その場合はSMTPセッションフィルタを抜けてきたものをフィルタしています。
どちらのフィルタでどれだけスパムが落とされたかで、各フィルタの有効性がどう推移してきたかを見てみます。

コンテンツフィルタとSMTPセッションフィルタの効果推移

f:id:stealthinu:20181204160503p:plain

  • コンテンツフィルタは30%減程
  • tarpittingは85%も激減

tarpittingの1次フィルタの効果

f:id:stealthinu:20181204160510p:plain

  • 2015年頃まではずっと70%~80%維持
  • 以降急激に低下しついに30%程度に

SMTPセッションレベルでのフィルタの効果が減少してあまり意味をなさなくなっていることがわかります。

結論

botnetからの送信が大幅に減ったため、botのクセを利用してスパムを排除するSMTPセッションフィルタも効果をなさなくなりつつあることがわかりました。
スパム(botnet)はすでにメールではなく、より効果の高いSNSなどを狙ったり、メールを使う場合でもより効率の高いフィッシングなどに使われるようになったと考えられます。

このことから、taRgreyはもう導入する意味がないといえます。これはgreylistingなど他のSMTPセッションフィルタも同様です。
考案者としては複雑な心境ですが、そもそもスパムがなければスパムフィルタは不要なわけで、だから喜ぶべき話だと思います。

はてなブログへの移行

長らくはてなダイアリーで書いてきましたが、とうとうはてなブログへの移行を行いました。

移行者が多かったみたいでインポートができないという問題がありましたが、今日やったところ無事に移行できました。

最近書くものは、例えば手順書だったりプレゼン資料だったり、なるべくmarkdownで書くようにしていて、逆にmarkdownで欠けなかったはてなダイアリーの内容は後から手直ししていたため、そこは便利になる感じです。

長野ディープラーニング同好会 #6

ディープラーニング同好会6回め開催しました。

長野ディープラーニング同好会 #6 - connpass https://nseg.connpass.com/event/109608/


今回は初参加の方EijiUnoharaさんがいらしたのですが、ご自分でVGG使った転移学習で猫認識とかされてたりして、色々と参考になるお話を聞けたりしました。

あと、塩尻MLもくもく会(塩尻MLもくもく会 #12)主催されてるalaskaさんにも来ていただけました。
alaskaさんがどなたかわかってなかったのですが、お会いしてやっと顔とアカウントが合致したというか、あ、alaskaさんだったんだ、というのがわかりました。


ということで、当初第6回でやろうと思ってたことはやらず、ずっとディープラーニング系のよもやま話をして過ごしてしまいました。
が、僕的にはそういう話ができてとても楽しかったです。


塩尻MLもくもく会の進め方の話を聞いて、最初にこんなネタで今日は進めよう、というのだけやって終わりにみんなでちょこっと発表、みたいなのもいいかなと思いました。


まあこじんまりとやってるので、まあその時の感じで柔軟に進めるしかないかなと思いますが。

長野ディープラーニング同好会 #5

ディープラーニング同好会5回め開催しました。

長野ディープラーニング同好会 #5 - connpass


今回は、自分が告知するのがだいぶ遅かったため、人が集まらずに2人だけでやりました。


前回の続きで、CNNで大きく位置ずれやサイズの違いがあった場合にどうやれば認識率をあげられるかを試しました。


今回は、位置ずれやスケーリングした教師画像をプログラム的に作って大量に学習させる方法を試しました。

実は前回あまりうまく行かなかったため、絶対にこれでうまくいくだろう、と思っていた方法を試したのですが… 確かにだいぶ良くはなるのですが、MNISTのような簡単な問題で、ある程度の大きさのCNNで大量の自動生成データで試しているにもかかわらず、せいぜい90%程度となってしまいました。


だいぶ負けた気分です。

が、まあたぶんこの方法でちゃんと詰めていけば、99%とかまで持っていけそうな感じはしました。


ただ、それで詰めていってもあまりおもしろくはないと思うので、次回は方針を変えて、AEを作って、その中間層に次元削減されてできた出力を使って、そこから判定してみる、というのを試してみようと思います。