os:freebsd:blacklistd
差分
このページの2つのバージョン間の差分を表示します。
両方とも前のリビジョン前のリビジョン次のリビジョン | 前のリビジョン | ||
os:freebsd:blacklistd [2024/07/02 04:00] – [blacklistd] seirios | os:freebsd:blacklistd [2024/07/02 04:32] (現在) – [blacklistdに関連するpfctlのコマンド] seirios | ||
---|---|---|---|
行 13: | 行 13: | ||
- 外出してて、友達と晩飯食ってる最中だったので、logの解析すらできず、取り急ぎ、smtpサーバー止める。結果的に4時間smtpサーバー止めた | - 外出してて、友達と晩飯食ってる最中だったので、logの解析すらできず、取り急ぎ、smtpサーバー止める。結果的に4時間smtpサーバー止めた | ||
- 帰宅して解析開始。この段階でspamの配信元になりそうになってたことに気づき焦ったが、全てError Mailになっていたことに気づき、ちょっと安心 | - 帰宅して解析開始。この段階でspamの配信元になりそうになってたことに気づき焦ったが、全てError Mailになっていたことに気づき、ちょっと安心 | ||
+ | * 結局、このエラーメールを送信するちょっと(大体3時間程度)前にパスワードが破られたことが判明 | ||
- logから、SMTP AUTHで使われる「メールアドレスとパスワード」が抜かれて、SPAMを転送としようとしていることが判明。パスワードを強制変更 | - logから、SMTP AUTHで使われる「メールアドレスとパスワード」が抜かれて、SPAMを転送としようとしていることが判明。パスワードを強制変更 | ||
- SMTP AUTHの認証を確認してSMTPサーバー復旧 | - SMTP AUTHの認証を確認してSMTPサーバー復旧 | ||
- | 今回は「転送失敗」メールが88件、転送成功メールは0件で、他人に被害出さなくて済んだから良かったけどちょっと怖い思いをした。 | + | 今回は「転送失敗」メールが88件、転送成功メールは0件で、他人に被害出さなくて済んだから良かったけどちょっと怖い思いをした。なお、転送に失敗していたのは、受信側の「携帯キャリア」のMail ServerがSMTPUTF8拡張をサポートしていなかったからだった。正直運良く転送されなかっただけで、一歩間違えたら大惨事(88通は決して少なくない)だった。 |
- | 新しいパスワードは、強制的に16桁にしたから、しばらくは大丈夫。大丈夫だと思う。大丈であって欲しい。 | + | というわけで、せめてもの被害軽減策としてblacklistdを導入して、SMTPAUTHとIMAPへの接続を監視し、パスワードチェック攻撃を少しでもreduceしようとしてみた。パスワード破られたら、DKIMもDMARKもSPFも関係なく全部送れてしまうわけで... |
- | (元のパスワード、6桁だったらしい。よく10年以上抜かれなかったなぁ...) | + | |
- | せめてもの被害軽減策としてblacklistdを導入して、SMTPAUTHとIMAPへの接続を監視し、パスワードチェック攻撃を少しでもreduceしようとしてみた。 | + | なお、新しいパスワードは、強制的に16桁にしたから、しばらくは大丈夫。大丈夫だと思う。大丈であって欲しい。 |
+ | (元のパスワード、6桁だったらしい。よく10年以上抜かれなかったなぁ...) | ||
(Event Driven...) | (Event Driven...) | ||
行 39: | 行 40: | ||
という考察をした。もちろん、blacklistdで対応できる範囲はそれほど大きくないが、それでも何もしないよりは大きく改善することが期待できる。 | という考察をした。もちろん、blacklistdで対応できる範囲はそれほど大きくないが、それでも何もしないよりは大きく改善することが期待できる。 | ||
- | ===== 準備 | + | ===== blacklistdの導入 |
FreeBSDだと、portsを使ってPostfixをCompileして導入すればblacklistdに対応できる。Option設定画面でblacklistdをOnにしておくこと。 | FreeBSDだと、portsを使ってPostfixをCompileして導入すればblacklistdに対応できる。Option設定画面でblacklistdをOnにしておくこと。 | ||
行 99: | 行 100: | ||
* Interface $IFextn (xn1)において、 | * Interface $IFextn (xn1)において、 | ||
* Incomming(外から入ってくる通信)に対して、 | * Incomming(外から入ってくる通信)に対して、 | ||
- | * blacklistdが作成するAnchorデータを適用する | + | * blacklistdが作成するAnchorルールを適用する |
ということになる。 | ということになる。 | ||
行 139: | 行 140: | ||
# WhiteLists | # WhiteLists | ||
- | # adr/ | + | # adr/ |
[remote] | [remote] | ||
- | # Never block 10.1.0.0/16 | + | # Never block localhost |
- | 127.0.0.1/ | + | 127.0.0.1/ |
+ | [:: | ||
</ | </ | ||
行 154: | 行 156: | ||
</ | </ | ||
* -rは、最後にblacklistdを修了した時のBlacklistデータを読み込む | * -rは、最後にblacklistdを修了した時のBlacklistデータを読み込む | ||
- | * -t [数値]は、登録されたIP Address情報をDBと比較して必要な更新を行うInterval time | + | * -t [数値]は、登録されたIP Address情報をDBと比較して必要な更新を行うInterval time |
* このInterval timeはあくまでもDBとメモリー情報を同期するものであって、fail 回数を初期化するものではないことに注意 | * このInterval timeはあくまでもDBとメモリー情報を同期するものであって、fail 回数を初期化するものではないことに注意 | ||
* -fを起動時引数に与えると、DBを初期化してから起動する | * -fを起動時引数に与えると、DBを初期化してから起動する | ||
行 170: | 行 172: | ||
* '' | * '' | ||
* Rulesetに記載された全てのAnchorを含むRulesetを確認 | * Rulesetに記載された全てのAnchorを含むRulesetを確認 | ||
- | * Anchor業が展開される | + | * Anchor行が展開される |
* < | * < | ||
anchor " | anchor " | ||
行 188: | 行 190: | ||
# pfctl -a " | # pfctl -a " | ||
block drop in quick proto tcp from < | block drop in quick proto tcp from < | ||
+ | </ | ||
* それぞれのTableを確認 | * それぞれのTableを確認 | ||
* Configを見れば自明だが、一応コマンドで取得 | * Configを見れば自明だが、一応コマンドで取得 | ||
行 242: | 行 245: | ||
</ | </ | ||
* '' | * '' | ||
- | * Blacklistに載っている「まだfailではない」リストを表示 | + | * Blacklistに載っている「まだblockするほどではない」リストを表示 |
* < | * < | ||
# blacklistctl dump -r | # blacklistctl dump -r | ||
行 271: | 行 274: | ||
</ | </ | ||
- | === 落穂拾い === | + | ===== 落穂拾い |
<WRAP round info> | <WRAP round info> | ||
- | === name === | + | ==== name ==== |
nameフィールドは、使用するパケットフィルタールールの名前である。 | nameフィールドは、使用するパケットフィルタールールの名前である。 | ||
行 285: | 行 288: | ||
<WRAP round info> | <WRAP round info> | ||
- | === disable / duration === | + | ==== disable / duration |
このフィールドには '' | このフィールドには '' | ||
行 304: | 行 307: | ||
<WRAP round tip> | <WRAP round tip> | ||
- | === 自分の接続元IPアドレスがblacklistに登録された === | + | ==== 自分の接続元IPアドレスがblacklistに登録された |
現在 blocklistctl には登録されているアドレスを削除する機能が無い。(というよりdumpしかできない) | 現在 blocklistctl には登録されているアドレスを削除する機能が無い。(というよりdumpしかできない) | ||
行 313: | 行 316: | ||
<WRAP round info> | <WRAP round info> | ||
- | === どうやって過去のAddressデータを保存しているのか? === | + | ==== どうやって過去のAddressデータを保存しているのか? |
blacklistdは、''/ | blacklistdは、''/ | ||
行 321: | 行 324: | ||
<WRAP round Alert> | <WRAP round Alert> | ||
- | === blacklistdのデータを複数台で共有 === | + | ==== blacklistdのデータを複数台で共有 |
Blacklistdは、sourcecodeを見る限り、DBファイルに対してLockなどの操作を行っていないように見える。 | Blacklistdは、sourcecodeを見る限り、DBファイルに対してLockなどの操作を行っていないように見える。 | ||
したがって、これを見る限りでは、このDBのデータファイルを複数台のマシンで共有すると、Dataを破損する可能性があると考えられる。 | したがって、これを見る限りでは、このDBのデータファイルを複数台のマシンで共有すると、Dataを破損する可能性があると考えられる。 | ||
</ | </ | ||
+ | |||
+ | ===== 末尾に追加でおまけ ===== | ||
+ | 本文中におまけはあるんだけど、こっちにやられた時の顛末とかのおまけを記載します。 | ||
+ | |||
+ | ==== 解析した内容 ==== | ||
+ | 全てはmaillogからの解析。 | ||
+ | * 攻撃は、常に、定常的に、いろいろなIP Addressから来ている。 | ||
+ | * ここ3ヶ月くらいのmaillog見る限り、毎日150回くらいのSMTP AUTH認証失敗logがある。 | ||
+ | * SRC IP Addressは割とバラバラ。みた感じ1画面に収まらなかったから、少なくとも50以上は攻撃元がある。 | ||
+ | * 1発SMTP AUTHに成功したら、outlook.comに試験メールを送信し、メール転送に成功することを確認。 | ||
+ | * 3時間後、10秒間で10通メールを転送しようとして弾かれる | ||
+ | * その30分後、2分間で21通メールを転送しようとして弾かれる | ||
+ | * さらにその20分後、2分間で21通メール転送しようとして弾かれる | ||
+ | * 繰り返し | ||
+ | という挙動だった | ||
+ | |||
+ | ==== 雑感 ==== | ||
+ | 今回は、送付先のメールサーバーがSMTPUTF8受け付けなかったからエラーメールになって帰ってきて、だから気づけたけど、はっきり言って、これは運がよかっただけ。 | ||
+ | 転送失敗してなかったら気づかなかったまであるわけで。 | ||
+ | |||
+ | 問題は、 | ||
+ | * 攻撃者は、長めの間隔で攻撃してくるから、見つけにくいし止めにくい | ||
+ | * spam送信も30分程度に20通程度送るだけだから、弾かれにくい | ||
+ | * ある程度(3時間程度か?)の間隔でmaillog解析して挙動確認しないとやられても気づけない | ||
+ | * パスワードでの認証は何らかのきっかけで突破される | ||
+ | * SMTP AUTHレベルで突破されたら、DKIMやらDMARCやらでは止められない | ||
+ | というあたりにある。 | ||
+ | |||
+ | 結局、DKIMやDMARC、SPFは、いわゆるOpenRelayに近いメールへの対策としてはそれなりに効果はあるんだろうけど、パスワード抜かれたら終わりというのは変わらない。まぁ、パスワード認証を利用する限りそうなるのは自明なんだけど...。SMTP捨てられればいいんだけど、なかなかそういうわけにも行かないし。 | ||
+ | |||
+ | パスワード認証の代わりに個人証明書を使うといのはないわけじゃない。設定や利用に関しては、まぁ、面倒なだけでやれなくはないし。 | ||
+ | ただ、この手を採用した場合の問題は、「個人証明書の発行」にある。 | ||
+ | 今時オレオレ証明書ってのは面倒が過ぎる(client側の設定も鯖側の設定も面倒)だし、自分がsubsidiary CAになるのは大変が過ぎるし... | ||
+ | でもまぁ、いうて、弱いパスワードが何よりも悪いのは事実だな。こいつをまず何とかするか。 | ||
+ | |||
+ | === ちょっとだけ愚痴 === | ||
+ | 今回blacklistdを導入するにあたって、pfで対応するサンプルが非常に少なかった。なので、結局source codeまで見ないとわからないところがたくさんあった。 | ||
+ | |||
+ | FreeBSDにおけるFirewall実装を選ぶなら、スピードの点でipfwが一番良い。特にCiscoとかの昔ながらRouterでFirewall設定したことがある人はipfwの方がわかりやすいとおもう。ただ、筆者は今時のPacket Filter Firewallでは設定はある程度抽象化されていて欲しい。その意味で、OpenBSD由来のpfは非常に気に入っている。 | ||
+ | |||
+ | ただ、FreeBSDに移植されているpfは、OpenBSDのpfよりも常に古いのがやはり辛い。NAT64はOpenBSDならpfでできるんだけど、FreeBSDだとipfwでやるしか今のところないし。 | ||
+ | |||
+ | うーん、やっぱり色々難しいなぁ... | ||
+ | |||
+ | |||
os/freebsd/blacklistd.1719860409.txt.gz · 最終更新: by seirios