パケットと他のすべてのエントリのみを許可すると、RELATEDファイアウォールルールは問題なくうまく動作します。ESTABLISHEDDROP
### VARIANT A
-A INPUT -i wlan0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i wlan0 -j DROP
IPしかし、私はさらに一歩進んで、私に送信されたすべての「不要な」パケットをブラックリストに追加したいと思います。ルールを修正しました。
### VARIANT B
-A INPUT -i wlan0 -m recent --name PORTSCAN --update --seconds 3600 -j DROP
-A INPUT -i wlan0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i wlan0 -m recent --name PORTSCAN --set -j DROP
ルールがどのように機能するかは次のとおりです。
Rule 1: checks whether IP address is already blacklisted and drops it if yes
Rule 2: allows RELATED,ESTABLISHED packets
Rule 3: all other packets which fail RELATED,ESTABLISHED test are blacklisted
これらのルールは99.9％期待どおりに機能しますが、少数のサイトにのみ問題があります。 Stack Exchange Webサイトはそのような例の1つです。 stackexchange.comが私にパケットを送信しているようですが、モジュールconntrackはそのパケットを関連性があるか確立されていると認識していないようです。したがって、これらのパケットは通過せず、rule 2ブラックリストに追加されますrule 3。
これは通常、編集モードの場合に発生します（質問や既存の質問を編集するなど）。
この場合、ブラックリストを更新する必要があります。
echo / >/proc/net/xt_recent/PORTSCAN
それからすべてが正常に戻った。
この問題の2つの可能な説明があります。
a) the conntrack module is deficient, in that it does not recognize
legitimate packets as being RELATED/ESTABLISHED
b) SE websites are indeed sending unsolicited packets
b私は次の推論のためにこれが正しい可能性が高いと思います。
私のiptablesルールのバリアントAは、認識されていないすべてのパケットを破棄しますRELATED/ESTABLISHED。すべてがうまく動作しているので、これらのパケットは私のセッションには必要ありません。これは本当に不要なパケットなので、最初から私に送信してはいけません。
私のiptablesルールのバリアントBはさらに一歩進んで違反を「罰」し、IPそれをブラックリストに追加します。
Q：SEサイトにも適用されるようにiptablesルールをどのように変更しますか？
問題分析へのコメントもありがとうございます。
Meta.unix.stackexchange.comに関する私の関連記事は次のとおりです。 stackexchange.comは不要なパケットを送信します（したがってファイアウォールによってブロックされます）。