サーバー上のスパマーを検出する

私は最近Undelivered Mail Returned to Sender、1500人の顧客の1人にニュースレターを送信中に1つを受け取りました。私のウェブサイトはダブルオプトイン手順を使用して、ユーザーがニュースレターを明示的に受け取りたいことを確認しています。

エラーメッセージ：

smtp; 554 ...
    Swisscom AG IP: 94.130.34.42, You are not allowed to send us mail. Please
    refer to xyz.com if you feel this is in error.

（受信メールサーバーのメールプロバイダーから）スパムメールの例を受け取りました：

Received: from mail.com ([94.130.34.42])
        by smtp-27.iol.local with SMTP
        id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100
From: "Servizi online - Poste Italiane" <posteitaliane@test123.it>
Subject: Abbiamo ricevuto una segnalazione di accredito
Date: Mon, 12 Feb 2018 11:32:03 -0500

プロバイダーはまた、私のサーバーがハッキングされているようだと述べました。彼はさらに、「この場合、受信側のメールサーバーは単に接続IPによって提示されたrDNSを記録しただけです」と述べましたmail.com ([94.130.34.42])。したがって、rDNSを正しく理解している場合、受信側のメールサーバーはrDNSエントリの送信者IPを照会します（94.130.34.42 =>に解決する必要があります=> mail.lotsearch.de。$ host 94.130.34.42）。

rDNSをスプーフィングする方法を教えてください。これが技術的にどのように機能するか想像することはできません（受信メールサーバーとサーバー間のインフラストラクチャのどこかで中間者攻撃が行われた場合のみ）。

プロバイダーは、「私のIPから接続しているマシンが危険にさらされており、受信者メールサーバーへの直接接続を介してこれらのメッセージを送信している可能性があります（ダイレクトMXとも呼ばれます）どういうdirect MX意味ですか？誰かが私のメールアカウントの1つに漏洩したメール認証情報を盗んだり、メール送信に使用したりしましたか？

サーバーがハッキングされない/ハッキングされないことを確認するためにこれまでに行ったこと：

• メールログを検索しました（var/log/mail*）：特別なものはありません
• sshログインログ（last、lastb）を確認しました：異常なし
• postfixが中継を行うかどうかをチェックします：いいえ（telnetを介してチェックします）
• clamavでマルウェアをチェック：結果なし
• ssh、postfix、dovecotのfail2banをインストールおよび設定しました
• Ubuntu 16.04の最新のパッチ/アップデートをインストールしました（毎週そうしています）
• 私のIPアドレスがブラックリストに載っているかどうかをチェックしました。
• ホスティングプロバイダーの管理コンソールで確認されたrDNSエントリ：が正しく設定されていmail.lotsearch.deます。
• すべてのメールアカウントのパスワードの変更
• シェルアクセスの公開キーを変更

さらに重要：posteitaliane@test123.itログには情報がありませんでした。サーバーがスパマーに悪用された場合（メールアカウントの1つのsmtp資格情報の漏洩によりfe）、ログファイルにそのことが表示されます。

私が考えることができる最後の可能性は、侵入者がまだ見つけていない私のサーバーにマルウェアを置いたということです。

送信メールトラフィックを監視するにはどうすればよいですか（プロセスごとおよびポートごと）。

送信ポート25を監視するだけでは役に立ちません。これは、postfixを介して送信される不規則なメールをトラップするだけで、潜在的なマルウェア感染によるメールトラフィックはトラップしないためです（マルウェアが25以外のポートを使用してメールを直接送信/受信者メールサーバーと通信する場合） 。すべてのポートで発信トラフィックを監視すると、疑わしいアクティビティを効率的に検索できない巨大なログファイルにアクセスできます。

編集-オープンリレーのテストを追加しました：

$ telnet mail.lotsearch.de 25
$ HELO test@test.de
250 mail.lotsearch.de
$ MAIL FROM: test@test.com
250 2.1.0 Ok
$ RCPT TO:<realEmail@gmail.com>
454 4.7.1 <realEmail@gmail.com>: Relay access denied

編集-webappsの実行

• Zend Framework 3に基づくカスタムプラットフォーム（https://framework.zend.com/）
• Mediawiki（https://www.mediawiki.org/）
• Mantis Bug Tracker（https://www.mantisbt.org/）

私が提案する前に、あなたのプロバイダーがあなたに言ったことについて少しコメントしたいと思います。

 Received: from mail.com ([94.130.34.42])
        by smtp-27.iol.local with SMTP
        id itOWeYZ6O42IFitOWe35TR; Tue, 13 Feb 2018 03:54:09 +0100

これは、94.130.34.42のリバースDNSがmail.comであることを示していません。むしろ、SMTPクライアントmail.comがそのHELO（またはEHLO）行で送信したことを示します。（適切に設定されたメールサーバーはこの接続を完全に拒否しますが、それはあなたではなくSwisscomにあります...）この行は逆DNSエントリを示していません。存在する場合、括弧内に表示されます。例えば：

Received: from mail-io0-f197.google.com (mail-io0-f197.google.com [209.85.223.197])

この場合、最初のホスト名は、メールサーバーが自身をで識別したものEHLOです。2番目のホスト名は、接続が行われたときに記録されたリバースDNSです。

RFC 5321セクション4.4は、Received：行の形式を正式な文法とともに説明しています。

あなたの場合、リバースDNSは記録されていません。IPアドレスにはPTRレコードが含まれているため、これは検索されなかったか、一時的なDNS障害があった可能性があります。

現在、Webホスティングサービスを実行しており、多数のWebアプリを持っているようです。これらのいずれかが侵害されると、スパムの送信が開始される場合があります。これらは、多くの場合、ポート587または465でローカルメールスプールまたは認証されたメールサービスにメールを配信するのではなく、MXレコードを検索してポート25に接続することにより、リモートメールサーバーに直接接続します。正当なWebアプリのように。

これを止める1つの方法は、ユーザーがメールサーバーユーザーでない限り、ポート25での発信接続を防ぐファイアウォールルールを実装することです。例えば：

iptables -I OUTPUT -m owner ! --uid-owner postfix -m tcp -p tcp --dport 25 -j REJECT

Webアプリは、リモートSMTPサーバーに直接メールを配信できなくなりましたが、ローカルメールスプールまたは認証済みメールサービスを使用する必要があります。

今の時代、あなた自身のメールサーバーをしようとすることは、ほとんどの場合、負けた戦いであり、手頃な価格のサービスを見つける方が良いでしょう。そうは言っても..

• あなたをブロックしたプロバイダーへのログを見て、疑わしいものを見つけることができるかどうかを確認してください。誰かがあなたのニュースレターの購読を忘れて、あなたをスパムとしてマークする可能性があり、頻繁に起こります。プロバイダーによっては、何も間違ったことをしていなくても、プロバイダーのブラックリストに登録できます。

• 大量のメールを他のすべてのメールから2つのサーバーに分けます。

• 少なくとも数週間、より良い月でログを保管してください。そのため、何かが起こったときはいつでも調査します。

• プロバイダからの同様の状況について毎日ログを確認し、毎日、またはより高速に調べてください。ブロックされて送信しようとすると、さらに悪化する可能性があります。一時的なブロックから永続的なブロックに移動できます。ブラックリストに報告されるようになります。

• 彼らがそれをどのように実装するのかはわかりませんが、私が知っていることの1つは、多くのプロバイダーがアウトバウンドメールサービスで行うことの1つは、プロバイダー/ IPが電子メールをブロックし、他の電子メールが送信されないことです。理想的には、そのようなものが必要です。2番目のものはブロックされるため、さらに送信すると問題が悪化します。