これらの「シングルドット」SMTP 接続エラーはどこから発生するのでしょうか?

これらの「シングルドット」SMTP 接続エラーはどこから発生するのでしょうか?

私は postfix ベースのメールサーバーを運用しています。次のような接続エラーが頻繁に発生します。

Transcript of session follows.

Out: 220 hostname.tld ESMTP Postfix
In:  .
Out: 502 5.5.2 Error: command not recognized
In:
Out: 500 5.5.2 Error: bad syntax

Session aborted, reason: lost connection

これらの接続は異なる IP から行われますが、ほとんどの場合、IP ごとに数十回から数百回の試行が一括して行われます。

これらの接続の原因は何でしょうか? これが「ドアをノックしている」ウイルス、ワーム、またはボットネットである場合、なぜホストごとにこれほど多くの回数が繰り返されるのでしょうか? または、単一のドットを送信することは何らかの機能テストであり、サーバーが誤った方法で反応するのでしょうか? 繰り返しますが、複数回の試行は意味がありません。また、これは DoS の規模からは程遠いものです。

皆さんの中には、そこで何が起こっているのか知っている人もいるかもしれませんね。

答え1

SMTP プロトコルでは、ドットは電子メールのメッセージを終了させるために使用されます。つまり、空行 (CR、LF) の後に 1 つのドットが続き、再び CR と LF を含む改行が続きます。しかし、ここでは明らかにそうではありません。

これらの SMTP クライアントが単なるボットネットなのか、正当な送信者なのかを確認するには、IP の PTR を確認します。どちらもログに記録されます。PTR がプロバイダーからの一般的な PTR ( など) である場合は、192-0-2-1.broadband.customers.example.comそれを無視して fail2ban を使用してブロックすることができます。

HELO は PTR と少なくとも一致している必要があります。これがベスト プラクティスです。ただし、類似していない場合は、やはりボットネットである可能性があります。

もう一つのケースでは、誰かがサーバーをスキャンして、TLS プロトコルと暗号を調査している可能性があります。


このようなリクエストの後にクライアントを禁止するには、fail2ban を使用できます。fail2ban は、不正なリクエストが多すぎる場合に IP を一時的にブロックします。

filter.d/postfix-syntax.conf

[INCLUDES]
before = common.conf

[Definition]
failregex = reject: RCPT from (.*)\[<HOST>\]: 502 5.5.2
            reject: RCPT from (.*)\[<HOST>\]: 500 5.5.2
ignoreregex =

これをあなたの に追加しますjail.conf:

[postfix-syntax]
enabled  = true
port     = smtp,ssmtp,submission
filter   = postfix-syntax
logpath  = /var/log/mail.log
maxretry = 10

答え2

メール サーバーをインターネットに公開している場合は、接続のほとんどがスパムボットやその他の不正な送信者からのものであることを想定してください。

fail2ban のエラーについては、拒否を一致させることだけを検討します。正当な送信者がエラーを生成することはめったになく、禁止された場合でも後で再試行します。私はスパマーの疑いのある人に対してはひどいことをしますが、正当な送信者が配信遅延以外の問題を抱えたのは何年も前のことです。

送信者の正当性を確認するために、いくつかのテストを使用します。

  • IP は にリストされていませんzen.spamhaus.org。(幅広い動的 IP の選択肢が含まれます。)
  • IP には rDNS を通過する DNS がありますPTR。正当なメールに記録がないことはほとんどなくPTRrDNSIP アドレスの場合はほぼ常に通過します。
  • HELO/EHLO コマンド内の名前は、rDNS を通過する完全修飾ドメイン名 (FQDN) です。1 つの大企業を除いて、これはほぼ常に通過します。通常、この名前は IP アドレスに使用される名前と同じです。
  • PTR レコードと HELO コマンドからの名前は、直接または親ドメインに対して SPF HELO 検証に合格します。SPF レコードのないドメインも合格しますが、信頼性は得られません。これにより、大規模な組織のドメインを使用して身元を特定するスパムボットがブロックされます。

DKIM を使用して検証したいのですが、送信者の多くが DNS で公開鍵を適切に公開していません。

これらのテストを実行できない場合は、接続がまだ開いている間に、送信者が偽装されていないことを確認できない限り、メッセージを返送しないでください。(FBI、国連、銀行などからの資金援助の申し出には感謝していますが、まだ届いていません。)

関連情報