ファイアウォールがNATパケットをブロックするという奇妙な問題
私のSIEMから、（FWを所有していない）Cisco ASAが内部ネットワーク（NAT後）宛てのパケットをブロックしていることがわかりました。これが私が見ているものです（IPアドレスはセキュリティのために偽造されています）
170.100.1.1外部ホスト（A）
ファイアウォール
192.168.1.1内部ホスト（A） 192.168.1.2内部ホスト（B） 192.168.1.3内部ホスト（C）
SIEMレポート/ファイアウォール拒否の例
"Deny udp src outside：170.100.1.1/3478 dst inside :(任意の内部ホスト）/ 5219by access-group" outside_access_in ""
FWを所有しておらず、ログも表示できないため、少し困惑しています。そのため、特定のルールも特定のパケットも表示されません。
外部ソースがまだホストと接続していない場合、外部ソースはどのようにして内部ホストのプライベートアドレスを知ることができますか？つまり、ファイアウォールがパケットをランダムにブロックするのはなぜですか？
ポートは完全にランダムで、すべてエンフェラルであり、割り当てられたポート範囲内にはありません。
助けが必要です!!!
ファイアウォールがパケットをランダムに拒否しているわけではなく、バグが原因でパケットがドロップされる可能性はほとんどありません。おそらく、ファイアウォールが実行するようにポリシーが指示しているため、パケットはドロップされています。ポート3478はSTUNであり、UDPがNATトラバーサルに使用するプロトコルです。いくつかの可能性があります。
- トラフィックは本物であり、トラフィックはファイアウォールルールによって誤ってブロックされています。この場合、FW管理者はトラフィックをブロックするルールを修正する必要があります
- トラフィックは本物であり、正当な理由でブロックされています。その場合、何もする必要はありません。
- トラフィックは攻撃です。細工されたSTUNパケットを使用して内部ネットワークにアクセスしようとしている外部の関係者である可能性があります。この場合、ファイアウォールはファイアウォールをブロックすることで完全に機能し、SIEMは攻撃を通知することで完全に機能します。その場合は、満足してください。そのため、SIEMを購入します。
これらのどれであるかは、システムのいずれかがSTUNを使用して外部ホストAに接続しようとしたかどうかによって異なります。あなたまたはあなたが一緒に働いている誰かが内部ホストA、B、およびCにアクセスできる場合があります。これらのシステムが外部ホストAに接続しようとしているかどうかを確認するように依頼してください。また、組織が料金を支払っている可能性もあります。ファイアウォールを管理するアウトソーシング業者。その場合は、ファイアウォールを呼び出して、エントリについて話し合います。