メッセージ

2017年10月07日の記事

2017/10/07(土)メールサーバへの攻撃事情

この1週間で「電子メールが送れない・受け取れない」という障害報告が4件ありました。
こういう障害は20年運用していて初めてのことでして・・・

どうも直接の原因は、これです。IPアドレスも晒します。 ↓
20171007_1.png

52.166. 系のIPアドレスの登録上の使用者は、皆が誰でも知っている企業です。
調べればすぐ判るので、ここでは敢えて言及しません。

なんと、概ね 10秒毎にSMTP認証を失敗しては繰り返しています。
文字列 'UGFzc3dvcmQ6' は、'Password:' を Base64エンコードして得られる文字列です。
SMTP認証も現在は数種類あって、これはセキュリティレベルが低いとされている LOGIN 認証と言われる種別。

サーバ負荷をこのようにして意図的に高くし、サーバ障害やサーバダウンを引き起こそうとする愉快犯か、何等かの意図を持っている連中の仕業です。

10/5 の 21:00 頃に、現在一緒に仕事をしている同業者がこのログを見て、 Twitter で呟いたそうです。
『○○社のネットワークから、メールサーバへの攻撃を受けている』と。
そうしたら、52.166. 系からの攻撃は「ピタッ」と止まりました。
これには余りの素早さに笑ってしまいましたね。勿論、対応された方々には感謝申し上げます。確信犯的にやっていたのであれば、逆に許せないですが。

で、今の攻撃主体はどうやら ↓ の模様。これもIPアドレスを晒しておきます。
20171007_2.png

間隔は4分毎ですが、攻撃と言えるレベルです。
時折「セキュリティ対策業者がセキュリティホール探しのためにやっている」なんていう話をする奴がいますが、ならサーバ負荷を意図的に上げるような行為を何故やる? という 疑問が必然的に湧きますね。

SMTP サーバ自体の接続拒否機能は、SMTP認証処理成功後に機能するようで、認証前にIPアドレスや接続元ドメインなどで強制切断するようにはなっていないようです。
これをするには、ファイアウォールを使わないと駄目ですね。
この手の設定は、微々たるものだとしても傘下ネットワーク全体のパフォーマンス低下を招くので、出来れば余計なことはしたくない。

SMTP サーバ単体で、接続そのもの自体を拒否できる機能が欲しいと考えるのは自分だけでしょうか。
ま、発信元で犯人の処分をしてくれるのが最も有益なわけですが・・・
OK キャンセル 確認 その他