FreeBSD Sendmail Setup パート９

これまでに８回の長きにわたり sendmail を実用に耐えるようにしてきましたが、その後もしばらく使用し続けていますので、どうなったかをお知らせしたいと思い、sendmail のパート９をお届けすることにしました。その前にこれまでのおさらいをしておきたいと思います。

これまでで、家庭内の Windows PC でメールを普通に扱えるようになりましたし、iPhone では家庭内 WiFi に限らず、外でも普通に 4G 回線経由でメールの送受信ができます。Windows でのメールクライアントは Thunderbird を使わせてもらいました。どうしても M$ Outlook は好きになれません 🙂

iPhone では、iOS 標準のメールクライアントを使いました。sendmail+starttls でお困りの方がいらっしゃるようですね 🙂

今回は普通に遊びで使っている間にいろいろ面白いことがありましたので、それらの傾向と対策みたいなことをしてみたいと思います。

port scanners
ratecontrol
spamassassin milter

port scanners

まず、ISP ルータでポート転送を行い始めた直後から起こり始めたのですが、たぶんポートスキャナのロボットが巡回してきまして、smtp ポートが開いていることを認識したようで、その後から途切れることなく smtp ポートで遊んでいるようです。ipfw や pf でブロックすれば済むことなのですが、ファイアウォール関係の記事にするか、sendmail の記事にするかを考えた場合、sendmail の記事にしてどのように遊んでいるかを書いた方が面白いかなと思いましたので、sendmail パート９となってしまいました 🙂 ネットワーク管理者としての立場からサーバ側でファイアウォールをいじくりまわすのはあまり好きではなく、専用のセキュリティアプライアンスを使いたくなる方ですので、申し訳ありません。

さて、smtp ポートがどのような状態かというと、メールログの一部をご紹介します。

なかなかにぎやかな状況です。最初のうちは遊びに来るアドレスも１つか２つで、tcpdump などでトラフィックの中身を見て、やってるやってる 🙂 と楽しんでいたのですが、普通に使い始めてから結構日にちも経ったことから、遊びに来るアドレスが数十を超えてしまいました。特殊詐欺の名簿のように一旦アドレスが出回るとあちこちに共有されるのでしょうか 🙁

SMTP ポートで何をしているかというと、SMTP AUTH で使用できるユーザ名とパスワードを力技で見つけようとしていることがログからわかります。こんな感じでレポートもメールされてきます。

ですので、現状世間様にご迷惑をかけていないことから sendmail の動きを遅くしているだけです。具体的には /etc/mail/access ファイルを使って、smtp セッションが張られたときのグリーティングメッセージを表示するまでの時間を長くしています。あまり長ーーーくしすぎると、遊んでくれなくなるかもしれませんので、３０秒としました。

ratecontrol

まぁ、同じことをしている間は客人の数が３０人程度までなら手動で対処できるので grep や sort, uniq, awk の使い方を忘れないための良い運動かと思っていましたが、徐々にめんどくさくなってきたので、ログを定期的にチェックして access ファイルを自動で作るスクリプトを書こうかとも思ったのですが、通りすがりの遊び人のために時間を割くのも馬鹿らしいので、学習がてらに sendmail の README を読み直してみました。このファイルの CONNECTION CONTROL の部分から家庭のメールサーバにちょうどよい対策を見つけましたので、その実現を行うところをご紹介します。README ファイルの 63% あたりにあります。一定時間 ( デフォルトで６０秒 ) での smtp 接続の頻度が指定した回数以上にあるようであれば、エラー 421 の “Connection rate limit exceeded” のエラーで接続拒否を行うようにしてみました。この機能を使用するためには２か所の変更が必要になります。まず、sendmail.cf の元ファイルの mc ファイル、dhcp さんの場合は jf3vqb.mc ファイルです。こんな感じになります。

この変更を行ってこれを元に sendmail.cf を作り直して sendmail を再起動します。次に変更しないといけないのが、access ファイルです。全ての GreetPause を削除して、１行で置き換えます。

１分間に３回以上の接続があると、421 エラーで接続が拒否されます。変更直後のログはこんな感じです。

まぁ、メールトラフィックの多いプロバイダさんでは使用できない方法ですが、家庭の私設のメールサーバーなので、同じ IP アドレスから大量にメールが届くことはありません。もし、そのようなメールが記録されるようなら、例外を定義することになると思います。もし間抜けなロボットではなく、AI で動いているものであったり、人が介在しているものであれば頻度の調整が入るかもしれません。でも設定では１分間に３回以上だとブロックされます。一体何回にするのでしょうか？力技でパスワードを得ることができる頃には私は生きていないかもしれません 🙂 どうなるかは乞うご期待 🙂 と思っていたのですが、速攻でかいくぐってくる来る輩がいました。

サーフェースベターだかトーストバターだか知りませんが、すり抜けてきています。たぶん元々非常に低い頻度でつないできていたのでしょう。IP アドレスから whois で何者か調べてみると、country code LT となっているようなので、リトアニアからの接続に見えます。別のアドレスレンジでのアクセスもあり、同じように whois でアドレスを調べてみると同様に country code LT となっています。接続の頻度が低いうえに、毎度異なる IP アドレスからの接続となり、ご丁寧にホスト名までバラバラにしています。

このようなことを専門に行う組織なのでしょうかねぇ。。。。ただ、このまま接続を許すのもシャクなので何とかしたいものですが、見る限りよさそうな機能はなさそうです。とりあえず接続は 141.98.10.0/23 と、185.36.81.0/24 からだけなので、元の Greeting Delay でも使っときましょうかねぇ。。。とりあえず、こんな感じでしばらく様子を見てみます。因みに、この類の連中からの接続に IPv6 は一度もないですね。いっそのこと SMTP ポートも IPv6 Only のサイトにしましょうかねぇ 🙂 メールクライアントが IPv6 アドレスを使えるのであれば何の問題もありませんし、IPv4 しか利用できなくても、Submission ポートにさえ IPv4 が使えたら困ることはないので 🙂 不思議なことに imap のポートも submission のポートも正規の接続しか記録されていません。ユーザ名やパスワードを盗み取るのが目的ならこれらのポートでも同じことが行えるのに 🙂

spamassassin milter

これまでの説明にはなかったのですが、SPAM フィルタも動くようにしました。たぶん普通に欲しくなる機能は網羅したと思います。いいんじゃないですか？

SPAM フィルタは SPAMASSASSIN です。セットアップ関係はここにまとまっておかれています。

全てデフォルトで動かしています。カスタマイズが必要な方はこれらのファイルを見ていただくとコメント部分にいろいろと書かれています。

たぶんこれが dhcp さんの限界で、少しだけスワップしています。

この dhcp さんは非常に古い 32bit PC で、メモリも１Gしかありません。以前の記事でもお話ししたようにウイルスチェッカを走らすと大変なことになってしまいました。ですので、Windows PC 上に VMware Player で動くようにした FreeBSD を仕立てて MILTER 経由でウイルスチェックを行っていました。私が普段使っている Windows PC は Windows 11 なのですが、勝手に再起動しないように Windows Update を止めて使っていました。が、Defender の定義ファイルのアップデートも止まってしまうので、仕方なく2台目の物理マシンを使うことにしました。会社でみんなが使うパソコンを管理しているのは IT support チームなのですが、古くて廃棄するパソコンチョーダイ！とお願いしてみたところ、1台腐りかけているパソコンをくれました。DELL Latitude E6400 でディスクも SSD ではなく、メモリも４Gしかありません。しかしながら dhcp さんよりはるかにましな 64ビット OS が動く PC です 🙂 最初は VMware ESXi 上に FreeBSD サーバを立てたのですが、CPU が古いことから ESXi 6.5 しか動かず、面白みに欠けるので直接 FreeBSD を動かすようにしました。このような理由からホスト名が esxi.home.jf3vqb.net となっています。これは単に DNS を書き換えるのがめんどくさかっただけで、 VMware ESXi が動いているのではなく FreeBSD のマシン名です 🙂

dhcp さんのプロセッサは1つしかありませんが、メールをパラパラ受け取るときに 50% 程度使用しますが、それ以外は SMTP ポートでのお遊びの相手をする程度なので、97-8% 程度 idle のようです。

esxi さんはというと、こちらもこれで限界のようです。とにかく clamav がリソースを大量に喰ってしまいます。

どちらのマシンも VMware ESXi にまとめて入れてしまえば美しいのですが、VMware ESXi が止まると全て止まることになるので、あえて物理マシンにしてあります。どちらも骨董品の部類に入るので、消費電力も馬鹿にはならないのじゃないかと思っていますが、これらが個別の物理マシンなので、実験環境はいくらでもスクラッチアンドビルドすることができます。加えて、家族からのクレームもありませんので 🙂 今回作ったメール環境は思いもよらず気に入ってしまいましたので、しばらくこのまま使用することとします。これで本当に sendmail 最終回のはずです。

以下広告