postfixを更に堅牢に

postfixのsmtp（port 25）への攻撃はだいぶ減ったけれど、それに対してsubmission（port 587）への攻撃が浮き上がってきた。
なのでこれへの対応を行うことにする。

先ずはログから。

たった3行だけれども、これはsmtp（port 25）を通さずにsubmissionを叩きにきているのよ。
postfix/smtpdがconnect from unknown[128.1.49.46]とねconnectされているのがその理由。
普通は25番の担当postscreenがこの（connect from）反応を示すのだわ。
それで、「直接submissionを叩きにきている（つまりはpostscreen回避）している奴がいるわ」と、気が付いた。
これだとmain.cfでいくらチェックを強化しても、「単にportが開いているかのチェックしているだけ」だからすぐに帰っちゃう。
だから、submission（smtpd）が返事しようとして「lost connection after EHLO」になる。
最初に向こうから「EHLO」が届いたけれど、それに応えようとしたら切れてたよ。ってこと。
それでも、きっちりと「disconnect from unknown[128.1.49.46]」と報告しているsmtpdは健気だね。

さて、これってサーチャーとかって言うのかな。
Geminiさんに聞いたら「ポートスキャナー」とか単に「スキャナー」とか言うそうだ。
意味的に似ているからサーチャーでも可かも知れない。

閑話休題。
これって、いくら邪魔でもpostfixの環境を弄っても排除できない。
そりゃそうだよね、門前で帰っちゃうだけだもの。
言ってみれば「門の前での覗き見野郎」ってことだわ。

そこでPacket Filter（PF）の出番です。
ようやくココまで来た。

こんなコードを組んでみた。

これはGeminiさんとの共同制作。
今回は私も参加した。（ホントだよ？
これだと、上のログ1行目に反応する。
見てわかる通り、最初のgrepでsmtpdを抽出、二番目でsubmissionを直接叩きに来た者を抽出、三番目は意味が判らないGeminiさん作のip抽出部分、四番目のsortが重複を削除。
そこまでしたところでpfctlに追加登録している。-Tで登録されてたものはスキップするのだそうだ。
実際2回繰り返しこのスクリプトを走らせたら、2回目は0件の登録でエラーにはならなかった。

これのコメントに「適応する時期は次のpfを更新するまでの1〜3日間」とある。
こっちも書いておこうと思う。

これもGeminiさん作。
私にはshell scriptなんぞ組めません。(^_^;;
これって、www.ipdeny.comに国別で登録してあるip rangeの一覧を引っ張ってきて、pfctlに渡しているだけ。
最初のflushでクリア、その後、追加更新って手順になっている。
これは中国嫌いって弾いたけれど、例えば「中国が手放して日本の所有になってもアクセス拒否のまま」であることを回避するためですね。
これをcrontabで3日おきに動かしているから。

だから、今日登録しても消えちゃうよってこと。
だけど、resetIP.shの後ろにくっつけちゃったから、その後も弾き続けるようになった。
そう言う経緯がある。
何故一つに纏めなかったのか、それはログ見てウザイと思えばその場でadd_pf.sh叩けば良いのだ。その後出なくなる。
resetIP.sh >/dev/null 2>&1の理由は簡単。pfctlが無茶喋るから邪魔なんだわ。
実際、command lineでつけないで動かすと延々出てくる。

こんなのが登録し国分だけ流れ続ける。
殆どが余計にお世話なワーニング。イヤだよねこんなの見るの。
で無くしている。

つまり、postfixのsubmissionに直接アタックしてくる無礼者は、PFで元から断つ。
ってやり方で強化したって訳。
今回はこの辺で。