web-dev-qa-db-ja.com

パケットが「iptables」によって無効と見なされた理由を理解するにはどうすればよいですか？

いくつかのiptablesルールを設定して、無効なパケットをログに記録してドロップするようにしました（--state INVALID）。ログを読んで、パケットが無効と見なされた理由を理解するにはどうすればよいですか？たとえば、次のとおりです。

Nov 29 22:59:13 htpc-router kernel: [6550193.790402] ::IPT::DROP:: IN=ppp0 OUT= MAC= SRC=31.13.72.7 DST=136.169.151.82 LEN=40 TOS=0x00 PREC=0x00 TTL=242 ID=5104 DF PROTO=TCP SPT=80 DPT=61597 WINDOW=0 RES=0x00 ACK RST URGP=0
linuxiptablesfirewall
11
mbaitoff

ステートフルパケットインスペクションを使用すると、パケットはさまざまな状態になる可能性があります。

  • 新規：パケットは既知のフローまたはソケットの一部ではなく、TCPフラグはSYNビットがオンになっています。
  • Established：パケットは、CONNTRACKによって追跡されるフローまたはソケットと一致し、TCPフラグを持っています。最初のTCPハンドシェイクが完了した後、パケットが確立された状態になるには、SYNビットをオフにする必要があります。
  • Related：パケットは既知のフローまたはソケットと一致しませんが、パケットを予測する既存のソケットがあるため、パケットは予期されます（この例はポート21に既存のFTPセッションがある場合のポート20のデータ、またはSIPポート5060の既存のTCP接続のUDPデータ。これには、関連付けられたALGが必要です。
  • Invalid：以前の状態のいずれにも該当しない場合、パケットはINVALIDです。これは、さまざまなタイプのステルスネットワークプローブが原因であるか、CONNTRACKエントリが不足していることを意味している可能性があります（ログにも記載されているはずです）。または、単に完全に無害な場合もあります。

あなたの場合、引用したパケットは、TCPフラグがACKとRSTであること、および送信元ポートが80であることを示しています。つまり、31.13.72.7（たまたまFacebook）のWebサーバーがリセットパケットを送信したということです。その前に来たパケット（もしあれば）を見ずに理由を言うことは完全に不可能です。しかし、ほとんどの場合、コンピュータが無効であると考えるのと同じ理由でリセットを送信しています。

25
bahamat