pfSenseとSnort：インターフェイスでの予期しないポートスキャントラフィック
公開ルーターおよびステートフルファイアウォールとして機能するpfSenseボックスがあります。
NATの背後にプライベートIPを使用する1つのWANインターフェイスといくつかのLANインターフェイスがあります。
WANインターフェイスでSnortを使用して、ポートスキャンまたはあらゆる種類のものを確認することを期待しています。
LANインターフェイスの1つでこのSNORTアラートが表示されるとは思わない。
Attempted Information Leak
PSNG_UDP_PORTSCAN
SRC: 165.98.148.2 (some Nicaraguan IP)
DST: 192.168.5.15 (a linux file sever on the LAN)
192.168.5.15へのポート転送がありません。実際、pfSenseボックスには、その内部アドレスに何かを転送/ルーティング/ NATing/PATするものは何もありません。
内部マシンがニカラグアのIPと通信しているかどうかは理解できましたが、UDPデータグラムがWANインターフェイスから転送なしでLANインターフェイスにどのように通信するのでしょうか？
ですから、ここで起こっていることがいくつかあり、混乱を引き起こしていると思います。
まず、Snortがソースと宛先によって何を意味するか。 Snortには、ステートフルインスペクション（フロービットと呼ばれる）のためにいくつかの状態情報を保持する機能がありますが、署名は個々のパケットに対して処理されます。これは、送信元と宛先がクライアントとサーバーにマップされず、IPヘッダーの送信元と宛先のアドレスフィールドに直接マップされることを意味します。つまり、このルールを起動させた特定のパケットの宛先アドレスは192.168.5.15、送信元アドレスは165.98.148.2でした。ここでは単一のパケットについて話しているので、誰がセッションを開始したかとは関係ありません。
第二に、あなたのNATデバイスはあなたが思っているよりもUDPでより多くのことをしています。TCPは簡単です。それはコネクション型プロトコルです。全体の設計はあなたです通信セッションをネゴシエートし、しばらくチャットしてから、さようならを言います。プロセス全体が非常に明確に定義されており、NATデバイスはこれらの標準に従います。SYNが送信され、エントリが追加されるのを確認します。 xlateテーブルに移動すると、FIN + ACKが戻ってきたとき、FIN + RSTが消えたとき、または十分な時間が経過したときに、xlateエントリが削除されます。
コネクションレス型のUDPは、ただの発火で忘れてしまいます。全体的な考え方は、アプリケーションが独自のハンドシェイクおよび/または再送信システムを実装するか、それらを必要としないということです。したがって、ファイアウォールはUDPパケットの送信を許可すると想定しますが、応答はすべてブロックされます。そうでないことを除いて。あなたのNATデバイスは、UDPのようなコネクションレス型プロトコルでさえ頻繁に双方向通信を行うことを知っています。そのため、TCPと同じように発信UDPトラフィックのxlateエントリを挿入します。ルールは少し異なります。たとえば、エントリは別の間隔でタイムアウトし、タイムアウトしたときにのみ削除されると思います。
第三に、このアラートはおそらく SnortのsfPortscanプリプロセッサによってトリガーされます。厳しく制限された環境では、それが非常に役立つことがわかります。そうしないと、かなりうるさくなる可能性があります。問題は、実行する検出の種類にあります
- 1つのホストが1つのホストと通信し、多くのポートにアクセスするTCP/UDPトラフィック
- 多くのホストが1つのホストと通信し、多くのポートに到達するTCP/UDPトラフィック
- 1つのホストが1つのポートで多数のホストと通信するTCP/UDP/ICMPトラフィック
主に＃3のため、このアラートは、実際にサービスを提供しているほぼすべてのシステムによってトリガーされる可能性があります。何らかの理由で、Windows SMBファイルサーバーは、誤検知の最悪の犯罪者のようです。
ここで物事が楽しくなります。構成（サーバー、ネットワーク、ファイアウォール）がすべて適切であると仮定しましょう。その場合、ファイルサーバーが外部IPとの通信を開始した可能性があります。次に、リターン通信がsfPortscanプリプロセッサをトリガーし、pfSenseがアラートを表示しました。これはおそらく悪いことです。私があなただったら、ファイルサーバーと外部アドレスとの間で何でもパケットキャプチャを開始します。次に、パケットキャプチャの確認を開始し、何が起こっているのかを把握してみてください。
UDP src/destは、Snortによって簡単に間違えられる可能性があります。トラフィックが何であるかについてもっと知らなければ、言うのは難しいです。そのUDPポートスキャンルールは、VoIPトラフィック、DNS要求、およびその他のもので常に失火します。その内部IPへのポート転送または1：1 NATがない場合、リモートIPからのトラフィックではなく、ローカルIPからのトラフィックです。