1台のPCでDROPを介したREJECTの利点
最近、ファイアウォールでのDROPとREJECTの違いについて学びました。
DROPのようにタイムアウトを待つのではなく、接続をすぐに閉じるのでREJECTがより良いことを理解しています。また、トラブルシューティングにも優れています。
これは、多くの接続を処理するサーバーにはメリットがあると思いますが、パーソナルコンピュータはどうでしょうか。 PCでDROPではなくREJECTを使用するメリットはありますか？
REJECTは他の人にとってより良い方法です。接続が正直な間違い（構成エラー）の結果である場合、接続を開始しようとした人はだれもそのポートでリッスンしていないという標準承認の応答を受け取ります。 DROPでは何も返されないため、接続しようとしている人は退屈するまで待機します。
REJECTはトラブルシューティングには優れているように見えますが、バグの追跡にDROPが実際にどのように優れているかについては、ケースを作成できます。実際、複数のサーバーに接続できるクライアントシステムを想像してみてください（DNSサーバーと同様の方法で）正常に応答するサーバーが見つかるまで。リストの最初のサーバーが正しく構成されていないが、REJECTが使用されている場合、人間のユーザーは何も気づきません。すべての試行はそのサーバーを試行し、エラーパケットで即座に応答され、クライアントシステムはすぐに2番目のサーバーに接続します。 。このような状況は、人間のユーザーが何も悪いことに気付かないため、長期間にわたって効力を持つ可能性があります。一方、DROPポリシーでは、構成の誤りがすべての要求のタイムアウト遅延として表示され、ユーザーが調査するように誘導されます。
実際、このような問題を定期的に調査する必要がある毎日の仕事（*）では、どこかに悪いDNS構成が原因で発生する遅延は、問題を特定するための非常に貴重なツールであることがよくあります。
パーソナルPCの場合、追加の技術的ポイントは非対称性です。つまり、インターネットにアクセスできるホームPCは通常、アップロードよりもダウンロード帯域幅がはるかに多くなります（ [〜＃〜] adsl [〜＃〜] の「A」）。接続試行（a TCP SYN）がPCに送信されると、ダウンロード帯域幅のごく一部が使用されます。ただし、PCが拒否で応答した場合（a TCP RST）の場合、この応答はupload帯域幅のビットを使用します。これにより、簡単な DoS攻撃の可能性が開かれます ：10 Mbsのダウンロード帯域幅と1 Mbsのアップロード帯域幅があり、 "Nice" REJECTを使用している場合、攻撃者はネットワークを飽和させるために約1 Mbs SYNパケットを送信するだけで済みます。落とすと10倍送れます。
その意味で、少なくとも家庭用PCの場合、DROPは一般的にREJECTよりもおそらく優れています。または、さらに良いかもしれませんが、あるしきい値までREJECTのように動作し、その後DROPするレート制限ポリシー（たとえば、1秒あたりに返されるRSTパケットが10以下）。 iptablesがそのように簡単に設定できるかどうかはわかりません。
（*）名目上私はいくつかの毛深いPKI関連システムの設計を手伝うことになっていますが、実際には多くの時間 これを行う を費やしています。
以前は、ポート113（ident）でREJECTを使用することをお勧めしました。これは、一部のサービスがidentポートに接続しようとするためです。 113でDROPを使用した場合、サーバーが接続を試みてタイムアウトを待機する間、通常30秒の苛立たしい遅延が発生します。現在、サーバーが逆IDを実行することは非常にまれであるため、このアドバイスは現在それほど重要ではありません。
それ以外の場合、特にワークステーションでは、一般的にDROPを使用する方が適切です。これにより、完全に非表示にできるため、誰かがあなたをポートスキャンしても、マシンがあなたのIPアドレスでアクティブであることを彼らは見ることさえできません。