fail2banは有名なソフトで攻撃してきたサービスの吐き出すログをベースにほぼリアルタイムで悪い輩のアクセスIPを記憶してFirewallでブロックしてくれるサービス。

一般的にsshdやhttpd等はお決まりのサービスを使用するケースがあるためデフォルトでブロックを有効にすればたちまちにBANしてくれる優秀なfirewallの補完ツールだ。でも逆を言ってしまうと既定でないサービスはうまくフィルターが効かない。

今回、管理しているサイトでPostfixAdmin構成でDovecotを使用していたサイトが非常に煩いDovecot DDos攻撃のジェネレーションアタックがあり、rejectではおっつかない状況に陥り、fail2banを使おうと思った。しかしPostfixAdminの吐き出すdovecotのログパターンが通常とは違っていたのでfilterをちょろちょろ書き直した。おかげで２日で攻撃者が消えた。

/etc/fail2ban/filter.d/dovecot.confの書き換え

昔よりも更に複雑になったと思うサーバの種類にメールシステム(smtpサーバ:MTA)がある。振り返ってみると２０年くらい前はデフォルトで作ったメールサーバでもすぐにインターネット上で使えましたが、今は兎に角セキュリティが厳しいので単純な設定ではまともに動かない。ガチガチだなーと感じる。時折サーバ講義の仕事をすると一番厄介なのがメールサーバの解説。正直言って１週間勉強した程度で理解できるのは初心者程度の知識だと思う。アンチSPAMの仕組みについては年々高度になっている。油断しているとおいて行かれるので定期的に情報に目を通さなければならないが、最近の技術の中ではDMARCはさすが効果あるね！と実感できる仕組み。この機能はSMTP通信におけるなりすましを確実にブロックしてくれる。単純ななりすましなら１００％ブロックできるだろう。送信サーバがスパイウェアに感染していたら駄目だと思うが、そうなっていない限り大変安全な仕組みと思う。

DMARCを使用してよかった事

以前は、時折自分のメールアドレスFromで数は多くはなかったが１年に２，３回程度送信されてくることがあったがDMARCを導入してからはピタリと止まった。更に嬉しいことに偽メールを送られた受信メールサーバからレポートがxmlで送られてくるので実態が掴める。殆どがgmailとyahooメールからのものだが、これだけ人の名前とメールアドレスを騙って送る輩がいたのだと気付かされる。つまり実際にはもっと沢山偽メールが横行していたと考えられる。もちろんDMARCを実装しているメールサーバでなければこのようなやり取りはできないが、今後必須のシステムになってきそうだと思います。特にビジネスで利用されている企業は共有ホスティングのおまけでついてくるメールは使ってはいけないと私は思います。

DMARCの導入は難しい？

メールサーバの導入になれている人なら１，２時間の学習でDMARCは導入できると思います。DKIM,SPFを入れた経験があるならすぐに理解できると思います。少しDKIM,SPFでやったような作業がつきまといますが非常に難易度の高いものではありません。作業の中にDNSのレコードを操作する箇所があるのでDNSを知らない人は大変かもしれませんがぜひチャレンジしてみてください。CentOSでやるよりもUbuntuのほうがハードルが低そうです。

DNSBLの信頼性

DNSBLシステムは世界に点在しブラックリスト情報を収集して無料で使えるメールSPAM対策サービスが幾つかある。このサービスはDNSの仕組みを利用したレピュテーションサービス（ブラックリストの判定を返す）だが運営組織が何しろ非営利な組織だから出来ては消えての繰り返し。日本ではRBL.JPという日本のスパムデータ・ベースもあったが廃止されており、現在はほとんど海外のサービスを利用するのが多くなった。厄介なのは昨今のIPアドレス汚染だ。プロバイダーの持っているIPアドレスはリサイクルされるため、過去にブラックだったIPだとかなり厄介になることがあります。というのはDNSBLやWEBのブラックQUERYサービスの中にはネットワークブロックで設定しているケースが少なからずあるからだ。そうするとホワイトなIPアドレスでもブラック扱いにされてしまう可能性が十分にありえます。誤判定の多くは過去のIP悪さが起因するのもあるけれど、このようにネットワークマスクの縛りが原因でなってしまう場合もあります。IPアドレスのご判定は殆どが申請で取り消せるようになっていますがネットワークブロックで管理している場合は無理な時もあります。その意味でサーバを借りるときは必ずIPアドレスのチェックを行うことと、IPアドレスの再割り当てができるホスティングがベストです。

SPAM対策用のmain.cfの一部抜粋

reject_rbl_client が記述されているあたりがDNSBLのサーバエントリー。お付き合いしている会社により効きすぎたり、効かなすぎたりあるため使いながら外したりして調整を行う。

共有サーバは勘違い判定の巣窟になる。

共有サーバは１台のサーバに多数のサイトが運営されるサーバですが、このサイトの中に詐欺サイトやマルウェア感染原因のサイトがあるとどうなるかご存知でしょうか？プロバイダーが認識した場合はプロバイダーから改善通知や停止を言われますが、実際のところ運営者も気づいていないものもかなりあると思います。私も自分のお客様で幾つかこの様な例を経験しましたが、結論はGoogleやYahooの検索結果に出てこなくなりました。イメージ的にはGoogleのインデックスには残っているのでしょうが、一時的にマスクされているように思えます。ブラック発見は無料のbaraccudacntral.orgのサービスでチェックし、その後別のプライベートホスティングに移設しDNSを切り替えたところ５分で検索結果にTOP5で表示されるようになりました。この経験でGoogleが如何に様々な詐欺行為のサイトを抑え込むチェックを行ってるかがわかりました。ビジネスで本気勝負をかけて集客、販売する会社は共有サーバ使ってはいけませんね。

皆さんの周りに会社間の取引で見積りや重要書類を送るときにメールを２回送って、１回目はZIPパスワード付き書類で２回目はパスワードを送るという方法でやっている会社が非常に多くありませんか？

これ、実はとんでもない大きな誤りなのです。全く安全ではありません。

メールのヘッダーはSMTPコネクションで相互に交換する際に暗号化されませんしスニファー機能があるソフトで簡単にトラッキングできます。メールで暗号化されるのはメールクライアントとメールサーバ間だけであり、メールサーバから宛先のメールサーバ間は必ずしも暗号化されていません。暗号化には送信側と受信側の両方が暗号化通信に対応している条件が整っていなければただの平文が流れていると思ってください。

FromアドレスとToアドレスがネット上の通信パケットでテキストで読めるのですから例えばWireShark等のネットキャプチャーソフトでフィルターかけてトラッキングすれば簡単にわかります。
でも一般の方はこの事知られていないし、固くそれが安全だと信じています。

この方法の場合、少しやり方を変えて、最初のメールを送るまではOKです。2回目のメールのパスワードを送る箇所を別の方法に変えるとかなり安全になります。

• パスワードはビジネス用SNSで送る。
• または電話で相手に伝える。
• SMSで送る

上記のように何れかの方法にするとかなり安全になります。しかし、最初のZIPパスワード付きなのですが、これは１００％パスワード解読ではありませんがクラッカーの世界では解読するソフトが流通しています。完全に安全とは言えません。

少々乱暴ですが、Facebookのメッセンジャーやビジネスチャット等で添付して送るほうが何倍も安全です。Lineやfacebookの乗っ取りや事故は多くがセキュリティに疎いユーザがわかりやすいパスワードを付けたり、第三者にわかるようにパスワードを晒したり、スパイウェアをパソコンやスマホの中に感染してしまって起きているものであり、仕組みそのものが全く安全でないということではありません。

メールサーバは暗号化通信においてメールボディを暗号化して送受信を行う技術は確立されていますが、メールを送る先とメールを受け取る先が同じ規格でメールの通信する環境を作っていないと完全なる暗号化の相互受信はできません。
つまり、メールサーバやメールクライアントはその会社、プロバイダー、個人ごとに仕様がまちまちで、お互いに相互受信しようと思ったらノーマルのテキスト通信が一番問題なくメール交換が出来るのです。そりゃそうですよね～相手のメールが暗号化されても自分のメールクライアントが暗号化に対応してなければ受け取っても読めないですから。

ホームページからメールを送信する仕組みを作る場合、専用サーバで構築するとよくありがちなissueは、「permission denied」が出ること。つまりsmtp送信非許可ということなのですが、通常このようなエラーはsmtpプロトコルでは発生しません。これがでたらセキュリティの何かに引っかかる問題があるということが推測できたら正解です。ずばりインストール直後のLinuxはSELINUXが有効になっているはずで、望ましいのはこれを有効にしたまま許可を出す設定をする事です。SELINUXではWEBサーバからメールを送信する処理に制限がデフォルト値OFFで入っています。

例えばWORDPRESSやフレームワークで送信用プラグインを導入しコンタクトフォームを作ろうと思った時に直接のローカルサーバのSMTPではなく外部のメール送信サーバを使うような場合はこの問題に遭遇するかもしれません。

エラーの例

ターミナルからrootで下記を実行しOFF設定になっていたらONになるようフラグを立ててください。

以上で再度試行して頂ければ動作するはずです。めでたしめでたし！

マックを使用していると、受け取った側がメールが文字化けしてる！

とよく怒られますよね。これはUTF-8という文字コードがデフォルト設定になっているからなんです。 日本では、まだメールソフトによってはこれに対応していないものもあるので文字化けしてしまう。

これを修正するのは、実はそれほど難しくないのです。

iso-2022-jpの文字コードを使って送信するようにしてあげることで、受け取った側が文字化けなく読むことができます。

1. こちらはメールソフトのプラグインとして導入し対応する方法。（簡単）
   http://sourceforge.jp/projects/letter-fix/
2. 通常GUIで修正できないシステム設定から文字コードを変更する方法（簡単だけど、ターミナル慣れてない人には１番が簡単）
   アプリケーションからユーティリティへ行きそしてターミナルを開いて、下記のコマンドを投入します。
   $ defaults write com.apple.mail NSPreferredMailCharset “ISO-2022-JP”

※これで、送付先から文句言われません。