メール爆弾は、最も古いタイプのサイバー攻撃の XNUMX つです。 基本的には通常の DoS 攻撃に似ていますが、異なる IP アドレスからのリクエストの波の代わりに、電子メールの波がサーバーに送信され、電子メール アドレスの XNUMX つに大量に届きます。これにより、負荷が増加します。その上で大幅に増加します。 このような攻撃により、メールボックスが使用できなくなり、場合によってはサーバー全体の障害につながる可能性があります。 この種のサイバー攻撃の長い歴史は、システム管理者に多くのプラスおよびマイナスの影響をもたらしてきました。 ポジティブな要素としては、メール爆弾に関する十分な知識と、そのような攻撃から身を守る簡単な方法が利用できることが挙げられます。 マイナス要因には、この種の攻撃を実行するための多数の公的に入手可能なソフトウェア ソリューションと、攻撃者が検出から身を守る能力が含まれます。
このサイバー攻撃の重要な特徴は、営利目的での利用がほぼ不可能であることです。 攻撃者は、メールボックスの XNUMX つに大量の電子メールを送信しました。その人に通常の電子メールの使用を許可しませんでした。攻撃者は、誰かの会社の電子メールをハッキングして、GAL 全体に数千通の手紙を大量に送信し始めました。なぜサーバーがクラッシュしたか、速度が低下し始めて使用できなくなったのか、そして次に何が起こるのか? このようなサイバー犯罪を現実のお金に変えることはほぼ不可能であるため、単にメール爆弾が現在発生することはかなりまれであり、システム管理者がインフラストラクチャを設計するときに、そのようなサイバー攻撃から保護する必要性を単に覚えていない可能性があります。
ただし、電子メール爆弾攻撃自体は商業的な観点からはかなり無意味な行為ですが、多くの場合、他のより複雑で多段階のサイバー攻撃の一部です。 たとえば、メールをハッキングし、それを使用して公共サービスのアカウントをハイジャックする場合、攻撃者は多くの場合、意味のない文字で被害者のメールボックスを「爆撃」し、確認の手紙がストリームに紛れて気づかれないようにします。 メール爆撃は、企業に対する経済的圧力の手段としても使用される可能性があります。 したがって、クライアントからのリクエストを受け取る企業のパブリックメールボックスを積極的に攻撃すると、クライアントとの作業が大幅に複雑になり、その結果、機器のダウンタイム、注文の未履行、さらには評判の低下や利益の損失につながる可能性があります。
そのため、システム管理者は電子メール爆弾攻撃の可能性を忘れず、この脅威から保護するために常に必要な措置を講じる必要があります。 これはメール インフラストラクチャの構築段階で実行できること、またシステム管理者の時間と労力がほとんどかからないことを考慮すると、インフラストラクチャをメール ボム攻撃から保護しない客観的な理由はまったくありません。 このサイバー攻撃に対する保護が Zimbra Collaboration Suite オープンソース エディションでどのように実装されているかを見てみましょう。
Zimbra は、現在入手可能な最も信頼性が高く機能的なオープンソースのメール転送エージェントの XNUMX つである Postfix をベースにしています。 そして、そのオープン性の主な利点の XNUMX つは、機能を拡張するためにさまざまなサードパーティ ソリューションをサポートしていることです。 特に、Postfix はメールサーバーのサイバーセキュリティを確保するための高度なユーティリティである cbpolicyd を完全にサポートしています。 cbpolicyd を使用すると、スパム対策保護とホワイトリスト、ブラックリスト、グレーリストの作成に加えて、Zimbra 管理者が SPF 署名検証を設定したり、電子メールやデータの送受信に制限を設定したりすることができます。 どちらもスパムやフィッシングメールに対する信頼性の高い保護を提供し、メール爆弾からサーバーを保護します。
システム管理者が最初に要求することは、インフラストラクチャ MTA サーバー上の Zimbra Collaboration Suite OSE にプレインストールされている cbpolicyd モジュールをアクティブ化することです。 これは、コマンド zmprov ms `zmhostname` +zimbraServiceEnabled cbpolicyd を使用して行われます。 この後、cbpolicyd を快適に管理できるようにするために、Web インターフェイスをアクティブにする必要があります。 これを行うには、Web ポート番号 7780 での接続を許可し、次のコマンドを使用してシンボリック リンクを作成する必要があります。 ln -s /opt/zimbra/common/share/webui /opt/zimbra/data/httpd/htdocs/webui、nanoコマンドを使用して設定ファイルを編集します。 /opt/zimbra/data/httpd/htdocs/webui/includes/config.phpここで、次の行を記述する必要があります。
$DB_DSN="sqlite:/opt/zimbra/data/cbpolicyd/db/cbpolicyd.sqlitedb";
$DB_USER="ルート";
$DB_TABLE_PREFIX="";
この後は、zmcontrol restart コマンドと zmapachectl restart コマンドを使用して、Zimbra サービスと Zimbra Apache サービスを再起動するだけです。 この後、次の Web インターフェイスにアクセスできるようになります。 :7780/webui/index.php。 主なニュアンスは、この Web インターフェイスへの入り口はまだいかなる方法でも保護されていないため、権限のないユーザーがそこに入るのを防ぐために、Web インターフェイスへの入り口ごとにポート 7780 の接続を単に閉じることができるということです。
cbpolicyd のおかげで設定できる電子メール送信のクォータを使用することで、内部ネットワークから送信される大量の電子メールから身を守ることができます。 このようなクォータを使用すると、60 つのメールボックスから 80 単位時間内に送信できる文字の最大数に制限を設定できます。 たとえば、ビジネス マネージャーが 100 時間あたり平均 36 ～ XNUMX 件の電子メールを送信する場合、わずかなマージンを考慮して、XNUMX 時間あたり XNUMX 件の電子メールの割り当てを設定できます。 この割り当てを達成するには、マネージャーは XNUMX 秒ごとに XNUMX 通の電子メールを送信する必要があります。 これは十分に機能するのに十分な一方で、このような割り当てがあれば、マネージャーの XNUMX 人のメールにアクセスした攻撃者が企業に対してメール爆弾攻撃や大規模なスパム攻撃を開始することはありません。
このようなクォータを設定するには、Web インターフェイスで新しい電子メール送信制限ポリシーを作成し、ドメイン内で送信されるレターと外部アドレスに送信されるレターの両方に適用されることを指定する必要があります。 これは次のように行われます。
この後、レターの送信に関連する制限をより詳細に指定できます。特に、制限が更新されるまでの時間間隔や、制限を超えたユーザーが受信するメッセージを設定できます。 この後、レターの送信制限を設定できます。 送信文字数と送信情報のバイト数の両方として設定できます。 同時に、指定された制限を超えて送信された手紙については、別の方法で処理する必要があります。 したがって、たとえば、メッセージをすぐに削除したり、メッセージ送信制限が更新された直後に送信されるように保存したりすることができます。 XNUMX 番目のオプションは、従業員による電子メール送信の制限の最適な値を決定するときに使用できます。
cbpolicyd を使用すると、レターの送信に対する制限に加えて、レターの受信にも制限を設定できます。 このような制限は、一見したところ、メール爆撃を防ぐための優れた解決策のように見えますが、実際には、そのような制限を設定すると、それがたとえ大きなものであっても、特定の条件下では重要な手紙が届かない可能性があるという事実が伴います。 このため、受信メールに対する制限を有効にすることは強くお勧めできません。 ただし、それでもリスクを負う場合は、受信メッセージ制限の設定に特別な注意を払って取り組む必要があります。 たとえば、信頼できる取引相手からの受信メールの数を制限して、そのメール サーバーが侵害された場合にビジネスに対してスパム攻撃が開始されないようにすることができます。
メール爆撃中の受信メッセージの流入を防ぐには、システム管理者は単に受信メールを制限するだけではなく、より賢明な措置を講じる必要があります。 この解決策としては、グレー リストを使用することが考えられます。 その動作原理は、信頼できない送信者からメッセージを配信しようとする最初の試行時に、サーバーへの接続が突然中断され、そのためにレターの配信が失敗するというものです。 ただし、一定の期間に信頼できないサーバーが同じレターを再度送信しようとした場合、サーバーは接続を閉じず、その配信は成功します。
これらすべてのアクションのポイントは、大量の電子メールを自動的に送信するプログラムは通常、送信されたメッセージの配信の成功を確認せず、再度送信しようとしないのに対し、人は自分の手紙が次の宛先に送信されたかどうかを確実に確認するということです。住所かどうか。
cbpolicyd Web インターフェイスでグレーリストを有効にすることもできます。 すべてを機能させるには、サーバー上のユーザーに宛てられたすべての受信レターを含むポリシーを作成し、このポリシーに基づいて、cbpolicyd が待機する間隔を構成できるグレーリスト ルールを作成する必要があります。不明な送信者からの繰り返しの応答の場合。 通常は 4 ～ 5 分です。 同時に、グレー リストを構成して、さまざまな差出人からの手紙の配信の成功および失敗をすべて考慮し、その数に基づいて差出人をホワイト リストまたはブラック リストに自動的に追加するかどうかを決定することができます。
グレー リストの使用は最大限の責任を持って行われるべきであるという事実に注意を促します。 このテクノロジーの使用とホワイト リストとブラック リストの継続的なメンテナンスを併用して、企業にとって本当に重要な電子メールが失われる可能性を排除できれば最善です。
さらに、SPF、DMARC、DKIM チェックを追加すると、電子メール爆弾からの保護に役立ちます。 メール爆撃のプロセスを経て届く手紙は、そのようなチェックを通過しないことがよくあります。 これをどのように行うかが議論されました .
したがって、電子メール爆弾攻撃などの脅威から身を守ることは非常に簡単であり、企業向けの Zimbra インフラストラクチャを構築する段階でもこれを行うことができます。 ただし、そのような保護を使用するリスクが、得られるメリットを決して超えないようにすることが重要です。
出所： habr.com
