iptables、nftablesの設定は「すでに確立した通信(established)および関連したパケット(related)を許可する」ルールを必ずいれます。
nftablesの場合は
add rule ip filter INPUT ct state related,established  counter accept
iptablesの場合は
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
のようになります。
いろいろな書き方がありますが、Webサーバーの場合は
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport 443 -j ACCEPT
と書いて、このあとすべてDROPのルールをいれるか、INPUTのpolicyをDROPにしておくかして、ルールにマッチしないパケットはDROPします。

さて、上記のルールにWebサーバーにアクセスしてほしくないネットワークを追加したいと思ったとき、次の①と②のどちらに追加した方がいいでしょうか。
①
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT
②
-A INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
-A INPUT -m state –state NEW -m tcp -p tcp –dport 443 -j ACCEPT
ErogameScapeでは…理由はすでに覚えていないのですが(理由はなかったのかもしれません…)①の位置にDROPするルールを追加していました。
-A INPUT -s XXX.XXX.XXX.XXX/24 -j DROP
-A INPUT -s YYY.YYY.YYY.YYY/24 -j DROP
-A INPUT -m state –state ESTABLISHED,RELATED -j ACCEPT -A INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT -A INPUT -m state –state NEW -m tcp -p tcp –dport 443 -j ACCEPT
おかしなアクセスを発見するたびに、DROPするルールを追加しており、今では3000行程度になっています。
①の位置にDROP追加すると困ったことがあります。
それは、内側からのパケットの応答をDROPしてしまうことです。
例えば、yum updateしようとしたら、リポジトリがブロックしたネットワークに存在していたため、パッケージをupdateできない…というようなことが起きます。
※ちなみにいちいちiptablesを外す…ということをしていました。

おそらく②の位置でも問題ない…と思ったので、②の位置に変更しました。
※何か問題があったら教えてほしいです。

10年以上、①の位置で運用していて、②の位置に変更したら、CPU使用率が劇的に下がりました。
以下のmuninのCPU usageのグラフのとおり、systemとsoftirqの値が劇的に下がっています。
cpu_usage

softirqの値が大きいのはなぜだろう…と思ってsoftirqについて調べるも全然わからなかったのですが、パケットを受信するたびに3000程度のルールとのマッチングをしていたので、CPUを酷使していたようでした。