外部でメールをホストするユーザーとの共有ホスティングオペレーターとしてのスパムスクリプトの処理
次の設定を想定しています。
- 単一のIPを多数の小さなWebサイトと共有する共有ホスティングサーバー。
- Webサイトのセットのサブセットは、電子メールを送信しています。これらの電子メールの一部は、独自のドメイン宛である可能性があります。
- 一連のWebサイトの別のサブセットは、別のプラットフォームでメールをホストしています。
- ホストがリモートコード実行の脆弱性に対して脆弱である3番目のサブセット。
- サブセット（2）、（3）、（4）のベン図では、どの部分も空ではない可能性があると仮定します。
設置されたセキュリティ対策を回避することにスパマーがますます有能になるという問題があります。完全なコード実行アクセスにより、ハッカーは通常のLinuxメーリングスタックを回避し、代わりに独自の電子メールサーバーを実装し、ソケットコードを介して外部メールサーバーに直接通信し、大量のスパムを送信できます。
サーバーは非常に強力なマシンであるため、そのようなフリーローミングコードは、MicrosoftやGoogleなどのビッグボーイのレーダーに乗るのに十分な量のスパムを送信する可能性があります。これらの企業には、IPに基づいてブロックする傾向がある独自の難読化された独自の独自システムがあります。これは愚かなことです。IPは一意のマシンとは異なります。明らかに、小規模なホスティングプロバイダーはこれらの大企業のポリシーについてほとんど何もできません。それらも無視できません。多くの消費者（たとえば、プラットフォーム上のWebサイトのユーザー）は、大手プロバイダーのプラットフォーム上に電子メールアドレスを持っています。
関連する秘密の要素もあります。大企業はスパマーボットネットとの戦いに積極的に取り組んでいるため、ブロックに関する詳細情報をまったく提供しないか、最小限に抑えて、スパマーがこの情報を使用できないようにします。 「署名された」スパムを送信することにより、特定のボットネットを特定し、ホスティングサーバーをサイバー犯罪の疑いのあるツールとしてマークした可能性があります。それは、サーバーがその時点で使用されているものであるため、完全に不合理ではありません。
IPv4アドレスの枯渇は、非共有ホスティングがこれらの小さなWebサイトの単なる選択肢ではないことを意味します。財政的には達成不可能です。
注意;常に脆弱なサイトがいくつかあると想定します。これは共有プラットフォームの本質的な弱点であり、すべての顧客がコードを同等に安全にするわけではありません。
ハッキングされると、顧客にはもちろん通知されます。標準的な手順は、サイトをオフラインにしてクリーンなバージョンに戻し、開発者にその前にセキュリティの問題を修正することを要求することです。
それでも、かなり大きな問題が残っています。多くのWebサイトのうちの1つに小さな間違いがあれば、サーバー全体の電子メールが事実上シャットダウンされます。また、すべてのデータを元に戻すには、この種の問題を防ぐのではなく、解決するまでに数日かかる場合があります。サイトが古くなり、同じIPを使用するサイトが増え、スパマーがより有能になるにつれて、状況は時間とともにますます悪化します。
私はいくつかの部分的なソリューションを考えることができますが、これまでのところ、私たちが提供しているすべての機能セットを維持することはできません。たとえば、ルートと信頼された電子メールユーザーを除くすべてのユーザーに対して、サーバーのファイアウォールを介して標準の電子メールポート（25）経由の送信トラフィックをブロックしようとしました。これにより、ウェブサイトで標準スタックを使用する必要があり、この標準スタックで送信メールのレート制限やスパムフィルターなどを簡単に設定できるため、スパムの問題を完全に防止できます。
それでも通過できる少量のスパムは、これらの秘密のIPブロッキングリストには入れません。
これはほとんどのWebサイトで機能します。すべてではありません。サブセット（3）は、レンチ（2）と組み合わせると、作業にレンチを投入します。説明しましょう：
私たちのホスト（IP = H）は、メールサーバーを介してMicrosoftホスト（IP = M）にメッセージを送信することになっています。 「[email protected]」から「[email protected]」に送信するとします。このメッセージが直接送信される場合、すべてが機能します。ただし、メールサーバー経由で送信する場合は、DNSレコードが必要です。しかし、それはlocalhost（H）に送信しようとしますが、これは失敗します。これは、（H）に「連絡先」というメールボックスがないため、Microsoftホストにのみ存在するはずです...
さらに、そのようなすべてを単純にブロックしても、すべてのWebサイトで機能するとは限りません。中には独自のメールエンジンを備えているものもありますが、上記の問題をいじくり回して問題を解決できれば、正しいメールプログラムを使用するようにソフトウェアを修正するようにこれらの人々に言うのは公平ではありません。
私はこの難問に対処する賢い方法についての意見に興味があります。
これは長くて複雑なトピックですが、できる限り簡潔に答えたいと思います。
基本的に、ここでは3種類の問題が混在しています。
- サーバーが提供する正当な電子メール送信機能の悪用;
- Webサーバー上で悪意のあるコードが実行され、外部の受信者に自分自身で、つまり正当なローカル機能を使用せずに電子メールが送信される可能性があります。
- DNSレコードの適切な構成。
後者では答えが長くなりすぎるので、最初の2種類の問題に焦点を当てるので、後者は省略します。
物事を分離するために手元にあるマシンとIPアドレスの数については何も言っていませんが、合理的なリソースがあれば、長年の実践からの私のアドバイスは防御の第一線になります。
ウェブサーバーが、あなたが所有および管理し、侵害された場合にウェブサーバーとは別のSMTPリレーサーバー以外の場所に電子メールを送信することを許可しないでください。 anyを防止する外部ファイアウォールをWebサーバーマシンに設置します== SMTPリレーサーバー以外のサーバーのポート25へのWebサーバーからのIP接続。 （Webサーバーからポート25への接続だけでなく、可能なすべてのポートへの接続を防ぐように指示する人もいます。Webサーバーは理論的にはリクエストに応答し、リクエスト自体は開始しないためです。残念ながら、これにより、たとえば、たとえば、その拡張リポジトリとやり取りしたいCMSを実行します。これについては、別途説明します）。
WebサーバーとSMTPリレーサーバー間の接続では、必ず何らかの認証を使用してください。必要に応じて、SMTPリレーサーバーの各Webサイトにユーザーを作成し、メールを送信するためにWebサーバーにSMTPリレーサーバーへの認証を要求します。これにより、特定の1つのWebサイトのみの電子メール送信をオフにすることが非常に簡単になります。
SMTPリレーサーバーで、スパムを防ぐための適切な手法を実装します。通常、レート制限とおそらくコンテンツスキャンの組み合わせ（Spamassassinを考えてください）でフィルターをかけるだけですveryハイスコアが役立つはずです。
SMTPリレーサーバーで新たなスパムの大規模感染が検出されると、送信Webサイトに属しているユーザーが損傷を防ぐために自動的にブロックされます。
結局のところ、2番目と3番目のSMTPリレーサーバーをコールドスタンバイにして、異なるパブリックIPアドレスを使用し、可能であれば異なるASNを使用します。対策が失敗し、最初のSMTPリレーサーバーのIPアドレスが「焼き付けられた」場合は、すぐに「まだ不明な」サーバーの1つに切り替えて、適切な送信電子メール配信を確保できます。
注：これを実装するときは、DKIMやSPFなどを正しく理解し、適切なレコードを設定してください。その後、それはうまくいきます。一部のブロッキングリストに登録したサーバーの電源を切る必要がある場合（ほとんどの場合、それらは秘密にされていません）、通常はしばらくして（数時間ではなく数週間と考えて）リストから除外され、そのIPが利用可能になります再び、ある種のラウンドロビンについて。
ThorstenSの答えは（+1 from me）にあります。これらのWebサイトが送信する電子メールを制御するには、独自のサーバーで実行する必要があります。
しかし、私はいくつかの詳細に同意しません-共有ホスティングでこれらの小さなウェブサイトについて話すとき、顧客は通常、技術的な知識がまったくない小さな友人であり、友人、インターン、または小さなウェブデザイン会社に協力してもらいました数年前のWebサイトで、「これを使用するようにソフトウェアを構成し、これだけをメールサーバーにする」、または「ソフトウェアがメールサーバーに対して認証することを確認する」は、その能力をはるかに超えています。
つまり、ポートをブロックするのではなく、自分のメールサーバーにリダイレクトします。 Linuxホストを使用している場合、これはiptablesを使用すると非常に簡単です。この例は ServerFault にあります。これはユーザーに対して透過的であるため、誰も何も再構成する必要はありません。また、必要が生じた場合、誰にも言わずに宛先を変更できます。
次に、ユーザーによるレート制限-これには、認証を必要としない2つ（3つ）のアプローチがあります。どちらかで、SYNパケットにユーザー依存のタグを付け、iptablesのレートリミッターを使用します。または、そのタグを使用してメールサーバーの異なるポートにリダイレクトし、メールサーバーソフトウェアにそれぞれのポートをリッスンさせ、ポートを使用してユーザーを区別します。または、おそらく最も堅牢な（そしてパフォーマンスが最も低い）ソリューションです。tcp接続がメールサーバーに着信したときに、リモートポート番号を取得し、netstat -ntpまたはlsofなどを呼び出します。所有者を取得し、それを使用してレート制限を行うWebサーバー。
ユーザーが特定のメールサーバーを使用する必要があると主張した場合（たとえば、テストサイトでmailtrap.ioを使用している場合）、そのアドレスへのポートを開く（アドレスがターゲットを移動するのは面倒かもしれません）、またはレート制限を行い、実際のターゲットをフォワーダーとして持つメールサーバー上の別の構成にリダイレクトするだけです。