偽のMXレコードを使用してスパムに対抗する


14

大量のスパムを受信して​​いるクライアントがいます。月の15日で、POP3の帯域幅はほぼ100 GBです。このドメインには7つの電子メールアカウントしかありません。SpamAssassinをインストールして5に設定し、10〜20個のフィルターを設定してほとんどのジャンクを拒否しました。POP3帯域幅に大きな変化は見られません。間違っている場合、サーバーは帯域幅を使い切ってメッセージを受信し、分析してスパムスコアを決定します。

気付かないうちに、MXレコードの偽造に出くわしました。基本的に、偽のサーバーを最低および最高のMXレコードとして設定し、作業サーバーのMXレコードを中央に設定します。

例えば:

fake.example.com    1
realmx.example.com  2
fake2.example.com   3

理論は、スパムの大半はWindowsベースのゾンビから生成され、通常はスパムをフィルタリングしないバックアップサーバーであるため、スパムに対する最高のMXレコードを照会するものが非常に多いためです。最も低い偽のMXレコードは、残りのスパマー向けです。一般的に、スパマーは失敗後に再試行しません。

誰もこれを試しましたか?それは役立ちますか?メールの配信に遅延や問題が発生しますか?他の誰かがより良い解決策を持っていますか?

回答:


15

ご自身でお願いし、Postiniなどのゲートウェイスパム対策サービスを設定してください。1か月あたりメールボックスあたり数ドルで、そうする理由はまったくありません。スパムの99%を排除するだけでなく、スプールサービス(スケジュールされたまたは予定外のダウンタイムに便利)にアクセスすることもできます。ネットワークの端に到達する前に他の誰かがそのすべてのスパムを受信して​​処理できるようにすることで帯域幅の節約に言及します。

Postiniの従業員ではなく、幸せなユーザーであり、多数のクライアントを設定しています。


提案のおかげで、それはプランBです(プランCは電子メールアドレスの名前を変更しています
..lol)

私が聞きたかった答えですが、クライアントはGoogle Postiniを使用しましたが、SPAMは制御不能で、ルートアクセスなしが唯一のオプションのように思えました。
Mikey1980

あなたはそれを愛します男。真剣に:サーバーで作業しているときにスプーリングをオンにできるのは素晴らしいことです。また、それらをアップストリームスマートホストとして使用し、それに応じてファイアウォールをロックダウンするため、ネットワーク(メールサーバーを含む)で所有されているボックスに関係なく、送信フィルタリングを行うPostiniのSMTPサーバーとのみ通信できます同様に。
gravyface

Postini ...ハァッ、Gmailを使ってみませんか?;-P
poige

@poige:ゲートウェイサービスでメールサーバーを実行することは、メールをGoogle Apps(gmail)でホストすることとは異なります。
-gravyface

12

私はこれを試してみましたが、それをしないでください!当時は良いアイデアのように思えましたが、さまざまな送信者からのメールが消え始めた後、私はそれが間違いであることに気付きました。私が気づかなかったのは、たくさんのひどく書かれたSMTPサーバーがあり、仕様に従っておらず、エラーの処理がかなり苦手であり、人々が知らないか気にしないということです。 、それはあなたでなければなりません」。

SPAMを処理するためのその他の提案のいくつかを次に示します。Postiniは優れたサービスであり、無料のGoogleアプリに組み込まれているスパム対策も悪くありません。さらに制御したい場合は、IronPortまたは他のデバイスを購入するか、独自のデバイスをロールバックできます。


1
ジェッド、私がまさに望んでいたことに感謝します。SMTPの問題については考えもせず、受信+1に集中しすぎた
Mikey1980

1
私はスパム対策会社(Red Condor)で働いており、ブラックホールアドレスに設定されているほとんどの顧客の優先度が最も高いレコードを持っています。しかし、愚かな人々がそのアドレスだけを爆撃する合法的なメールサーバーを書くため、一部の顧客はそれを削除しています。ただし、SaaSホストプロバイダーを使用すると、帯域幅の負荷を安価にオフロードできます。
ライアングーラー

@ライアン-ありがとう!「ブラックホール」の報告server-busyはありますか、それとも完全に死んでいますか?
Mikey1980

6

この方法を聞いたことはなく、正当なメールが数時間遅れる可能性があると想像できます。結局のところ、smtpプロトコルは正当なメールを配信する必要があります。有効なサーバーは、偽のmxレコードにヒットし、そのサーバーに配信しようとします。

適切なサーバーは、メールが配信されるまでMXレコードを試行し続けます。スパマーはより賢くなる傾向があり、これが現在一部のスパムソフトウェアで機能する場合、私はそれが長い間機能することを疑います。お勧めできません。

代わりに、既存のスパムフィルターに加えてsmtp tarpitを使用することをお勧めします。現在、これらの多くが利用可能です。偽のmx recordメソッドよりもはるかに効果的であることがわかると思います。

このようなターピットは、BSDのsmtpdに付属しています。sendmail 8.13には、いくつかのターピット機能もあります。

基本的に、ターピットはスパムサーバーリソースを拘束することで機能します。彼らは、彼らが得る応答を遅らせることによってそれをします。たとえば、スパムサーバーが接続し、1秒あたり約1バイトを受信します。
一部のターピットサーバーはスパムパターンを探し、スパムサーバーを認識できます。正当なサーバーは、遅い応答を待つ準備ができています。一部のターピットサーバーでは、正当に認識されたサーバーを自動的にホワイトリストに移動するため、将来の遅延はありません。

Google SMTP Tarpitをご覧ください。


提案に感謝しますが、私のクライアントは共有ホストで何百もの低トラフィックサイトを実行しているWebデザイン会社です(クライアントが問題を抱えています)。また、WHMにはルートアクセスまたはSSHがありません。交換です。これが明確でない場合はご容赦ください。私の苦労はプログラミングです。恐らく恐ろしいシステム管理者を作るでしょう!
Mikey1980

私もプログラマーですが、昔の会社のfreebsdサーバーをあらゆる方法で実行するのにかなりの時間を費やしました。
マット

5

言及しなかったので、DNSBLを使用していない理由はありますか?

編集:SpamAssassinにそれらのいくつかのサポート含まれています-それらがなければ、スパムを分析する多くのCPUサイクルを浪費することになります。


Webalizerのに応じて、SpamAssassinのを有効にすると、最後の12時間で、帯域幅に影響を与えずに次にしたもう一つの大きな提案、私のクライアントは、WHMはルートではありませんので、しかし、私は本当に限られています。..
Mikey1980

1
...最善の策は、すべてのメールサービスをGoogle Apps経由でプッシュする、クライアントのホスティングプロバイダーがSpamAssassinの設定をいじるつもりがない場合は、別のサードパーティサービスを使用してスパムを軽減することです。
ダンルフリー

DNSBLまたはRBLがdeafultによって有効にされている場合、何か考えはありますか?あなたは彼らがいると思うでしょう。同意します。フロントエンドMXフィルタリングが唯一の解決策になると考え始めています。
Mikey1980

@ Mikey1980-「DNSBLまたはRBLがdeafultによって有効にされている場合のアイデアは?」申し訳ありませんが、言うことはできません-独自の構成を適用する可能性があるため、いずれにしてもプロバイダーに直接問い合わせることをお勧めします。
ダンルフリー

メールサーバーがDNSBLに基づいてスパムをフィルタリングするかどうかを確認できます:spamhaus.org/faq/answers.lasso
section=

4

私はこれをこの偽のMX(nolistingの変形)を使用し、非常にうまく機能します。

私はすべての通常のフィルターでpostfix MXを使用し、いくつかのスパムボットがサーバーを2〜3回過負荷にした後、試してみることにしました...ここに結果があります: fake-mx、前後

fake-mxをいつ実装したかを推測してみてください!8)

結果はpostgreyと同じですが、postgreyとは異なり、メールサーバーを変更する必要はありません

スパムボットは、高MXまたは低MXのいずれかを試して、実際のMXをフィルタリングしようとする負荷から解放し(DNSBLを使用しても、負荷は高かった)、実際の電子メールは最小限の遅延で到着します。

しかし、注意してください、リスクがあります:

  • サーバーによっては、再試行時間が長くなる場合があります。ほとんどのサーバーは最初のタイムアウト後に次のMXを再試行し、他のサーバーは次の数分で再試行しますが、1時間または1日後にのみ再試行するサーバーを既に見ました。彼らは非常にまれであり、私はそれを見つけることができたものにとっては悪い設定でした。他のポストマスターと話すことで問題が解決します

  • すべてのメールには遅延があります。実際、遅延はまったくありません。実際のメールサーバーのほとんどは、最初のタイムアウト後に次のMXに再試行するため、30秒の遅延について話します。彼らは通常、少なくとも3 MXを試行してから、より長い遅延のためにメッセージをキューに入れます。しかし、破損したメールサーバーと連絡を取り、これを行わずにすべてのメッセージを数分間遅延させる可能性があります。したがって、これは、このソリューションを展開するときに監視するものです。

  • 壊れたサイト。一部のWebサーバーは、パスワードや通知などのメールを送信し、内部の実際のメールサーバーに配信する代わりに、「偽の」メールサーバーになり、直接配信しようとします。ウェブサーバーであるため、再試行することはなく、電子メールは失われます。繰り返しになりますが、実際のメールサーバーのみがメールを送信する必要があるため、ウェブマスター/ウェブ開発者の設定は不適切です。この問題を見つけるたびに、ウェブマスターと問題について話します。通常、問題は修正されます。

  • ログなし。接続されていないIPへの偽のMXポーイングとして、配信しようとしたもののログはありません。誰かが文句を言ったときに何かがうまくいかなかったことを知っているだけです。しかし、これも良いです。いつでもメールを配信しようとしていないと主張できるため、これはリモートの問題です。反対側はログを確認し、問題を解決する必要があります。実サーバーとの接続がまったくないことを証明でき、問題を解決するというプレッシャーを反対側に移します。反対側が問題を解決できない場合、信頼できず、信頼できないように見えました。

  • ホワイトリストはありません。これはdns経由ですべてのサーバーに適用されるため、1つのサーバーをホワイトリストに登録することはできません...実際には半分だけですが、より困難です。ホワイトリストソリューションでは、最下位のMXはsmtpが実行されているIPを指しますが、すべてのユーザーに対してファイアウォールでフィルタリングされます。リストに載せたいサーバは、ファイアウォールで許可される必要があります。これにより、すべてのサーバーがファイアウォールによって拒否され、ホワイトリストに登録されたサーバーがメールサーバーに配信できるようになります。動作しますが、IPホワイトリストのみで、電子メールホワイトリストでは使用できません。

リモート送信者が「拒否された」配信のログを持っている(そして問題として私たちを指すことができる)postgreyとは異なり、fake-MXはWebサーバーが接続できず再試行しなかったことを示します。問題に関するリモート側のために。失敗したMXは、「ルーティングの問題を常に主張できるが、バックアップMXは正常に機能しており、他のすべての電子メールを受け取る」ため、ポストグレーよりも適切に受け入れられます。

そうは言っても、苦情はほとんどありません(3か月に1回程度)ので、十分に安全であると考えています(すべてのスパムフィルターにはリスクがあります)。

私はすべてのMXに有効なipv4アドレスを使用しますが、偽のIPアドレスには使用していないIPを使用することに注意してください(したがって、どの接続でもタイムアウト/ホストに到達できません)。これを使用しない場合でも、このルールが適用されます。電子メールが機能するために完全に有効なdns設定を必要とするdnsおよびsmtpサーバーがあります。偽のMXも有効である必要がありますが、到達可能ではないはずです。

プライベートIPまたは偽のMXに対して制御しないIPを使用しないでください(ipv6アドレスを追加する場合は、ipv4アドレスも追加してください)。これにより、壊れたDNSとメールサーバーの問題や、他のユーザーが電子メールを取得するという驚きを回避できます(制御していないIPにsmtpサーバーをインストールすることにより)。また、CNAMEはMXで禁止されているため、使用しないでください。単なるAレコードです

最後に、偽のMXに対してtcp-resetを送信して、(パケットをドロップすることで)単純なタイムアウトの代わりにパフォーマンス(ホストまたはポートに到達できない)を改善する必要があるため、ファイアウォールに追加することをお勧めします。

とにかく、私はまだそれを使用するだけでなく、誰もがそれを使用することをお勧めするので


これ nolistingであり、単なるバリアントではありません。確かに機能しますが、偽のサーバーのデータをブラックホール化しているため、測定が困難です(上のグラフは単なる逸話です!)。ポート25を閉じた実サーバー(制御する!)の高優先サーバーをお勧めします(ただし、ドロップしないで、非常に高速な障害が必要です)、および低優先サーバー(制御するIPスペース内)それはアップしていないか、そのポートの接続を透過的にドロップします。
アダム・カッツ

1
@AdamKatz Nolistingは最高の優先度のMXのためだけのもので、この亜種は最低の優先度の偽サーバーも持っています...それが違いです!また、私の最後のいくつかの段落を読むと、あなたが書いたことを正確に言っていることがわかります!:)
higuita

2

メールのフィルタリングに関しては、Spamassasinとpolicyd-weightの組み合わせに満足しています。SMTP接続中に送信者のホスト名とブロックリストをチェックします。それは2つの理由で素晴らしいことです:

  1. 拒否された電子メールをspamassasinで処理する必要はありません。システムリソース(ベイジアン分析には時間がかかります)と帯域幅を節約します
  2. 送信者ホストは拒否されるため、正当な電子メールをブロックすることはほとんどありませんが、送信者は配信エラー通知を受け取ります

私はPostfixでセットアップを使用していますが、おそらくEximでpolicyd-weightインストールする方法があります。


1

正直なところ、私は完全にそのアイデアを思いつきませんでした。

さて、私のメインのメールサーバーは偽物だと言っています。それで?それはまったく存在しないのですか?(いずれにせよ、SPAMersの一部を最後にカットしたとしましょう。)「生存者」はセカンダリを使用します。しかし、このセットアップに3番目のサーバーがあるのはなぜですか?


これは質問ではなく私の答えであるはずなので、私はそう結論付けます。それは病気で、グレイリストの淡い影です。実際の効果を確認したい場合は、Greylistingを使用してみてください


並外れた言葉遣いですが、あなたはかなり正しいです。グレーリストは適切なソリューションです(まともな本格的なアンチスパムフィルタリングシステム以外)。すべての欠点なしに、偽のMXレコードと同じくらい効果的に機能します。
ジョンガーデニアーズ

1

ホストへの接続がSpamhausのzenリストにリストされるのを遅らせることで、ほとんどのスパムをドロップします。Spambotsは遅延が好きではありません。HELOコマンドで明らかなサーバー偽造を検出すると、多くのスパムもクリアされます。サーバー偽造を示すことがわかった条件には次のものがあります。

  • ホスト名またはIPアドレスを使用します。
  • 非修飾ホスト名を使用します。
  • FQDNの代わりにドメインリテラル([192.0.2.15])を使用します。(はい、RFCで要求されていますが、最近ではインターネットメールサーバーで使用されていません。)
  • メールではなくHELO名のSPFに失敗します(失敗、ソフトフェイル、ニュートラルでブロックします)。

自動化されたメールやマーケティングメールを重視する場合は、機能しないHELOコマンドをチェックしてください。私の経験では、他のすべてのメールはこれらの条件を満たします。

  • ホストのFQDNではなく、第2レベルのドメイン名を使用します。
  • rDNSを確認するためにIPまたはHELO名を要求します。
  • FQDNに有効な第2レベルドメインを要求します。(ローカルは有効なドメインでもローカルドメインでもありません。)

リターンパスに署名すると、スパムをブロックできます。最近では、偽のバウンスがはるかに少なくなっています。

残念ながら、正当な自動メールまたはマーケティングメールの多くがリターンパスを偽造しています。多くの場合、これらのホストには有効なポストマスターアドレスもありません。リターンパスに有効なドメインを要求することは実行可能であることがわかりました。正当な電子メールでは、スパムよりもはるかに多くのSPF失敗応答が返されます。

最近、Eximでスパムをブロックした経験を投稿しました


0

壊れたゲートウェイを持つ正当な人々からの失われた電子メールに加えて、それはかなり前に(15年前のように+/-)試みられ、スパマーはほとんどすぐにそれに適応しました。スパムへの影響はほとんどありませんが、電子メールの信頼性を損なうことになると思われます。ただし、試してみてください、結果を送ってください!


0

残念ながら、最初のMXレコードに到達できない場合にメールを送信しない特定のキャリアがあります。私は最近、これに関する私の経験をブログのエントリに書いたので、ここでは繰り返しません。要約すると、最初のMXレコードは実際にはIPv6のみのMXレコードでした。スパマーはIPv6を(まだ)使用していないと考えたためです。残念ながら、これにより問題が発生し、最終的にはゾーンの最初のMXレコードにIPv4アドレスを追加する必要がありました。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.