web-dev-qa-db-ja.com

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

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

エラーメッセージ：

_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" <[email protected]>
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エントリ（mail.lotsearch。 de）私のIPアドレス。したがって、rDNSを正しく理解している場合、受信メールサーバーは送信者IPにrDNSエントリを照会します（94.130.34.42 =>は=> mail.lotsearch.deに解​​決する必要があります。 _$ Host 94.130.34.42_）。

RDNSを偽装することはどのように可能ですか？これが技術的にどのように機能するかは想像できません（受信メールサーバーとサーバーの間のインフラストラクチャのどこかにman-in-the-middle攻撃がある場合のみ）。

プロバイダーはまた、「私の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_に正しく設定されています。
  • すべてのメールアカウントのパスワードを変更
  • シェルアクセスの公開鍵を変更

より重要：ログに_[email protected]_に関する情報がありませんでした。したがって、私のメールサーバーがスパマーによって誤用された場合（たとえば、メールアカウントのいずれかのsmtp資格情報が漏洩したため）、ログファイルにそれが表示されます。

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

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

送信ポート25を監視するだけでは効果がありません。これは、Postfix経由で送信される不規則なメールをトラップするだけで、マルウェア感染の可能性が原因のメールトラフィックはトラップしないためです（マルウェアがメールの直接送信や受信者のメールサーバーとの通信に25以外のポートを使用している場合）。 。すべてのポートで送信トラフィックを監視すると、疑わしいアクティビティを効率的に検索できない巨大なログファイルにアクセスできます。

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

_$ telnet mail.lotsearch.de 25
$ HELO [email protected]
250 mail.lotsearch.de
$ MAIL FROM: [email protected]
250 2.1.0 Ok
$ RCPT TO:<[email protected]>
454 4.7.1 <[email protected]>: Relay access denied
_

編集-webappsの実行

postfixsmtpmonitoringspamreverse-dns
12
mfuesslin

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

 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レコードが含まれているため、IPアドレスが検索されなかったか、一時的なDNSエラーが発生した可能性があります。

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

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

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

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

13
Michael Hampton

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

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

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

  • ログは最低でも数週間、そしてより良い月には保持します。ですから、何かが起こったときはいつでも研究します。

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

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

7
Francisco1844