DotW: リセットサーバ、リセットクライアントまたはサイレントドロップ
Resolution
今週のトピックの議論は、パロアルトネットワークファイアウォールからの負のアクションは、サイレントまたは通知が送信されるべきかどうかを決定する方法について Sly_Cooper によって求められ、誰が通知を受け取る必要があります。
ベテランのコミュニティメンバー Brandon_Wertz はすぐにいくつかのシナリオとは、フェンスの両側に管理者を設定すると考えの学校があるという彼の発言で頭の上に釘を打つ。
適切な戦略を deside するには、組織の出入りの流れごとに利用できるすべてのオプションの長所と短所を一覧表示することが重要です。 内部サーバーへのブロックされた接続が、アプリケーションの応答性を向上させ、サーバー上の開いているソケットをすばやく閉じるために、内部クライアントとサーバーに通知することが有益な場合があります。ローカルにホストされたパブリックサーバーは、接続が終了したときにリセットパケットの恩恵を受けることもありますが、外部クライアントは portscanning の使用による逆マッピングを防ぐためにこの通知を必要としません。
インターネット上のクライアントにリセットパケットを送信しないと、悪意のあるクライアントがそのソースアドレスを偽装して、セカンダリの被害者の IP にリセットパケットを送信するように試みることで、スキャンの試行を防ぎ、またはリフレクション攻撃を防ぐことができます、これは明らかなソースです。
一方、サイレントドロップは、ファイアウォールは、より経験豊富な攻撃者のためのポートをブロックしている死者の景品かもしれません。拒否されたセッションで ICMP タイプ3メッセージを送信すると同時に、ゾーン保護などのスキャンのためのより複雑な保護方法を有効にすると、外部ユーザーにとってより頂きな操作性が得られます。これらのユーザーは、セッションが拒否された直後に通知され、スキャンの試行は阻止され、保護メカニズムが活用されます。
要は：
- サイレントドロップは、あいまいさが好まれる場合に便利です。
- リセット-クライアントは、ユーザーの利便性が重要である場合に便利です、アプリケーションはすぐにユーザーが接続が利用できないことを知らせることができるようになります。
- reset-server は、ハーフオープンソケットによる過度のリソース消費から内部リソースを保護する必要がある場合に便利です。
- reset-両方とも最高のユーザーエクスペリエンスを提供し、サーバーのリソースを保護しますが、悪意のある使用を促進する可能性があります。
- ゾーンの保護は、まだ虐待から保護しながら、より頂き経験を可能にする保護機構を追加します。
あなたは元の議論に従うことができますここでリセット- クライアント対リセット-サーバー
このトピックに関するその他のリソース
サーバーをセキュリティで保護するための効果的なファイアウォールポリシーを選択する方法
お気軽に自分の洞察力を以下のコメントを残してお気軽に。
敬具します。
トム