manual.snort.org によれば、TCP ポートスキャンは 1 台のコンピュータから別のコンピュータに渡されますが、snort/snorby の TCP ポートスキャン アラートを見ると、次のことがわかります。
一方: 送信元: 136.238.4.165 送信先: 10.19.0.5
一方：Priority.Count:.5.Connection.Count:.18.IP.Count:.1。スキャナー.IP.範囲:.10.10.28.88:136.238.78.44.ポート/プロトコル.カウント:.6.ポート/プロトコル.範囲:.199:58891.
つまり、一方ではソースと宛先のフィールドがあり、マシン 10.19.0.5 が 136.238.4.165 からスキャンされたことを示しています。他方では、スキャナ IP 範囲は 10.10.28.88 から 136.238.78.44 までが 10.19.0.5 にスキャンされたことを示しています。
この情報をどのように理解すればよいですか? スキャンを開始したデバイスはどれですか?
答え1
あなたは TCP 接続の用語と、それが Snort のソースと宛先の意味とどのように関係するかということにこだわりすぎていると思います。
Snort にはステートフル インスペクション (フロービットと呼ばれる) 用の状態情報を保持する機能がありますが、署名は個々のパケットに対して処理されます。つまり、送信元と送信先はクライアントとサーバーにマップされず、IP ヘッダーの送信元と送信先のアドレス フィールドに直接マップされます。つまり、このルールが発動した特定のパケットの送信先アドレス フィールドには 10.19.0.5、送信元アドレス フィールドには 136.238.4.165 が含まれていたことになります。ここでは単一のパケットについて話しているだけで、セッションを開始した人とは関係ありません。
また、sfPortscan プリプロセッサがどのように動作するかにも留意してください。その検出アルゴリズムは、実際には 3 つのパターンをチェックするだけです。
- 1つのホストが1つのホストと通信し、多数のポートにアクセスするTCP/UDPトラフィック
- 多数のホストが1つのホストと通信し、多数のポートにアクセスするTCP/UDPトラフィック
- 1つのホストが1つのポートで複数のホストと通信するTCP/UDP/ICMPトラフィック
主に #3 が原因で、このアラートは実際にサービスを提供しているほぼすべてのシステムによってトリガーされる可能性があります。何らかの理由で、Windows SMB ファイルサーバーは誤検知が最も多いようです。これにより、sfPortscan プリプロセッサは非常にノイズが多くなります。実際、非常にノイズが多いため、ネットワークが厳しく制限されており、出力を大幅に調整する専門知識がない限り、このプリプロセッサを有効にする価値はほとんどありません。