NmapのSYNスキャンについて読んでいて、Nmapはサーバーがハンドシェイクの確立を試みた直後にRSTを送信することを示しています。
私の質問は-なぜRSTに悩むのか?サーバーがチェックされたすべてのポートで再接続を試み、スキャンマシンへの不要な受信トラフィックを作成するのを防ぐためですか?そのトラフィックはスキャンを大幅に遅くしますか?
そのパターンのSYN、RSTはIDSで簡単に「読み取る」ことができると思いますが、そもそもなぜそこにあるのかはわかりません。応答を登録して続行しませんか?
接続をsyn_rcvd状態のままにすると、フラグが立てられます。これは一般的なサービス拒否攻撃です。
RSTを送信しない場合、サーバーは最大60秒間syn_rcv状態を維持し、SYN ACKを最大5倍まで再送信します。これは、スキャンしているネットワーク上のリソースを浪費し、(スキャンの速度と成功に応じて)大量の再送信されたSYN ACKを送り返します。
60秒と5回の再試行はLinuxのデフォルトです-これらの値は異なります。
これは技術的には誤りです:Nmapは、ハーフオープンSYNスキャンのどの時点でもRSTを送信しません。代わりに、スキャンマシンのOSに依存して、カーネルに応答してRSTパケットを送信します未承諾SYN-ACKパケットと見なします。これは NmapのACKスキャン(-sA
) ファイアウォールルールをマッピングします。もちろん、これは、スキャンシステムにファイアウォールがある場合、RSTで応答するのではなく、一方的なSYN-ACKパケットをドロップする可能性が非常に高いため、SYNフラッド状態が発生する可能性があることを意味します。ターゲットに負担をかけないように、大規模なスキャンを実行する場合は、このようなルールをオフにするか、明示的なルールを追加してRSTの送信を許可することをお勧めします。
ステルスに関しては、あなたの歴史を知ることが重要です。 Nmapは1997年にリリースされ、BlackICE、Snort、およびBro(すべて1998年に作成された)より前のバージョンです。 "ステルスSYNスキャン"がそのように名付けられたとき、侵入検知システムは失敗した接続試行がないかログを確認します。SYNスキャンがTCPハンドシェイクを完了することはないため、アプリケーションに通知されることはありません。イベントはカーネルで停止し、アプリケーションログには何も問題がなかったことを示すものはありません。 。ただし、最近では状況はほぼ逆転しており、組織は適切に構成されたSIEM/UTM /よりもnetworkIDS/IPSを持っている可能性がはるかに高いログ分析機能。