exim での辞書攻撃の遅延

exim での辞書攻撃の遅延

私のEximサーバーに対して攻撃が続いています。次のACLで攻撃を遅らせようとしています。

  deny    condition     = ${if and {\
                        {>{$rcpt_count}{10}}\
                        {<{$recipients_count}{${eval:$rcpt_count/2}}} }}
          delay         = 5s
          message       = Rejected for too many bad recipients
          logwrite      = REJECT [$sender_host_address]: bad recipient count high [${eval:$rcpt_count-$recipients_count}]
         .endif

最初の 10 回の試行後、1 回遅延します。

2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:34 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Unrouteable address
2023-09-10 12:14:39 REJECT [212.164.218.15]: bad recipient count high [11]
2023-09-10 12:14:39 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Rejected for too many bad recipients
2023-09-10 12:14:39 REJECT [212.164.218.15]: bad recipient count high [12]
2023-09-10 12:14:39 H=([212.164.218.15]) [212.164.218.15] F=<[email protected]> rejected RCPT <[email protected]>: Rejected for too many bad recipients

代わりに、後続の各試行を遅らせたいのですが、どうすれば実現できますか?

答え1

私も同じ問題/質問に遭遇し、調査とテストを行いました。

まず最初に知っておくべきことは、SMTPはもともと厳密にコマンドと応答に基づいていたということです。つまり、クライアントはサーバーに1つのコマンドだけを送信し、応答を待ってから次のコマンドを送信する必要があります。このやり取りには毎回かなりの待ち時間が必要で、遅延が発生します。RFC 2920後に「SMTP パイプライン」が導入されました。これにより、クライアントは複数のコマンドを 1 つのバッチでサーバーに送信し、サーバーはそれを処理して応答を送り返すことができます。exim では、「SMTP パイプライン」の可用性はオプションによって制御できpipelining_advertise_hosts、デフォルトではすべてのユーザーに対して有効になっています。これは、あなたの構成にも当てはまると思います。

あなたのケースで起こったことは、クライアント(スパマー)があなたのeximサーバーに接続し、「SMTPパイプライン」をサポートしていると伝えられ、100個のコマンドのバッチを送信したということだと思いますRCPT TO:。サーバーはそれを受け取り、acl_smtp_rcpt各受信者のACLを実行して処理を開始しました。最初の10個のコマンドは550 Unrouteable addressそれぞれ応答を返し、550RFC5321 エラーコード意味Requested action not takenの後に人間が読める理由が続きます。その理由は、exim でディレクティブを使用して設定できmessage、ログのコロンの後に出力されます。クライアントはおそらくそれらを無視しただけでしょう。結局、有効な受信者を探しているのです。

11 番目のコマンド/受信者を処理するときに、ルールの条件がdenytrue と評価され、exim は 5 秒間遅延 (スリープ) します。これが、表示される遅延の 1 つです。その後、応答を550 Rejected for too many bad recipientsクライアントに送信します。含まれている (よく知られている) 理由により、クライアントは一線を越えたことを検出し、有効な受信者を見つけるチャンスはもうありません。後続のすべてのコマンドも拒否されます。期待/取得する価値のあるものがもうないため、残りの応答を待たずに接続を終了します (そして、おそらくすぐに次の犠牲者に向かいます)。サーバーはこれに気付いていますが (TCP が使用されているため)、コマンド バッチの処理を続行します。ただし、クライアントへの SMTP 接続はすでに終了しているため、これ以上遅延する意味はありません。遅延するのはサーバー自身だけです。したがって、遅延は無視され、サーバーはバッチ全体が完了するまでコマンドを実行します。

クライアントが接続を終了しない場合は、期待どおりに動作します。10 番目以降の受信者ごとに 5 秒の遅延が適用されます。

上記が正しいと仮定すると、私が思いつく最善の解決策は、デフォルトの理由/メッセージを削除することです。サーバーが単に のような応答を続けると550 Unrouteable address、クライアントはそれが限度を超えたことを知る方法がなく、回避できません。クライアントの動作によっては、特別に処理されないように、デフォルトとは異なるものに変更/言い換えるだけで十分な場合があります。

あるいは、上記のオプションを使用して、サーバーの「SMTP パイプライン」を無効にすることもできます。クライアントは、おそらく、明らかな理由を示す 11 番目の応答を確認した後に中止し、サーバーは 1 回だけ遅延しますが、少なくとも、ログに他の 89 人の失敗した受信者が記録されることはありません。明らかな欠点は、すべてのクライアントが「遅くなる」ことですが、選択した「既知の良好な」クライアントに対してのみ「SMTP パイプライン」を有効にすることで、この速度をいくらか向上させることができます。

補足として、遅延は静的な値である必要はなく、式にすることもできます。これにより、無効な受信者が増えるごとに遅延が長くなる漸進的な遅延を実装できます。メール交換機のスパムフィルタリングHowTo にこの例があります。

関連情報