nf_conntrack：テーブルがいっぱいで、パケットをドロップしています
Linuxサーバーの/ var/log/messagesにこれらのメッセージがたくさん表示されます
kernel: nf_conntrack: table full, dropping packet.
kernel: __ratelimit: 15812 callbacks suppresse
サーバーがDoS攻撃を受けているが、メモリがまだ飽和していない。メッセージの重要性と、考えられるセキュリティへの影響にどのように対処するかについて疑問に思っています。
メッセージは、接続追跡テーブルがいっぱいであることを意味します。 DoS以外のセキュリティへの影響はありません。追跡される接続の最大数を増やしたり、追跡タイムアウトを減らしたり、接続追跡を無効にしたりすることで、これを部分的に軽減できます。これは、NATルーターではできません）後者は機能しなくなります。
sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=54000
sysctl -w net.netfilter.nf_conntrack_generic_timeout=120
sysctl -w net.ipv4.netfilter.ip_conntrack_max=<more than currently set>
これは主題を扱った素晴らしい記事です。基本的には、IPテーブル（APFまたはその他のソリューションを使用）が永続的な接続を格納するために使用するテーブルがいっぱいであることを意味します。メモリを犠牲にしてそれを増やすことができます。
ファイアウォールルールをドロップするのではなく拒否するように設定することもお勧めします
Iptablesを保持する必要がある場合は一時的に修正してくださいNATルールは次のとおりです：
linux:~# sysctl -w net.netfilter.nf_conntrack_max=131072
一時的なものですが、nf_conntrack_maxの引き上げは保証されないため、今後はスムーズに進みます。ただし、それほど多くのトラフィックがロードされていない多くのサーバーでは、net.netfilter.nf_conntrack_max=131072を十分に高い値に上げるだけで、面倒を解決できます。
– nf_conntrackハッシュテーブルのサイズを増やす
Net.netfilter.nf_conntrack_maxが発生するたびに、conntrack-entriesのリストを格納するハッシュテーブルのハッシュサイズ値を適切に増やす必要があります。
linux:~# echo 32768 > /sys/module/nf_conntrack/parameters/hashsize
設定する正しい値を計算するルールは次のとおりです。
hashsize = nf_conntrack_max / 4
–加えられた変更を永続的に保存するには; a）/etc/sysctl.confに入れます：
linux:~# echo 'net.netfilter.nf_conntrack_count = 131072' >> /etc/sysctl.conf
linux:~# /sbin/sysct -p
b）/etc/rc.localを入力します（出口0行の前）：
echo 32768 > /sys/module/nf_conntrack/parameters/hashsize
注：この変数に注意してください。私の経験によれば、値を高くしすぎると（特にXENパッチを適用したカーネルでは）、システムがフリーズする可能性があります。また、値を大きくしすぎると、古いハードウェアで実行されている通常のLinuxサーバーがフリーズする可能性があります。
– nf_conntrackの診断には、次のものがあります。
/proc/sys/net/netfilterカーネルメモリ格納ディレクトリ。そこでは、動的に格納されたいくつかの値が見つかり、nf_conntrack操作に関する情報が「リアルタイム」で提供されます。
linux:~# cd /proc/sys/net/netfilter linux:/proc/sys/net/netfilter# ls
-al nf_log/ total 0 dr-xr-xr-x 0 root root 0 Mar 23 23:02 ./ dr-xr-xr-x 0 root root 0 Mar 23 23:02 ../
-rw-r--r-- 1 root root 0 Mar 23 23:02 0
-rw-r--r-- 1 root root 0 Mar 23 23:02 1
-rw-r--r-- 1 root root 0 Mar 23 23:02 10
-rw-r--r-- 1 root root 0 Mar 23 23:02 11
-rw-r--r-- 1 root root 0 Mar 23 23:02 12
-rw-r--r-- 1 root root 0 Mar 23 23:02 2
-rw-r--r-- 1 root root 0 Mar 23 23:02 3
-rw-r--r-- 1 root root 0 Mar 23 23:02 4
-rw-r--r-- 1 root root 0 Mar 23 23:02 5
-rw-r--r-- 1 root root 0 Mar 23 23:02 6
-rw-r--r-- 1 root root 0 Mar 23 23:02 7
-rw-r--r-- 1 root root 0 Mar 23 23:02 8
-rw-r--r-- 1 root root 0 Mar 23 23:02 9
IV。他のnf_conntrack NATタイムアウト値を減らして、サーバーがDoS攻撃を防ぐのを防ぎます
通常、nf_conntrack_*タイムアウトのデフォルト値は（不必要に）大きいです。
そのため、nf_conntrack_maxを増やしてもトラフィックのフローが大きい場合でも、nf_conntrackオーバーフローテーブルを取得すると、サーバー接続が切断される可能性があります。これが起こらないようにするには、他のnf_conntrackタイムアウト接続追跡値を確認して減らします。
linux:~# sysctl -a | grep conntrack | grep timeout
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.ipv4.netfilter.ip_conntrack_generic_timeout = 600
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent2 = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 432000
net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60
net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30
net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120
net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10
net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300
net.ipv4.netfilter.ip_conntrack_udp_timeout = 30
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 180
net.ipv4.netfilter.ip_conntrack_icmp_timeout = 30
すべてのタイムアウトは秒単位です。 net.netfilter.nf_conntrack_generic_timeoutはかなり高い– 600秒=（10分）。この種類の値は、応答しないNAT接続が10分間ハングしたままになる可能性があることを意味します。
値net.netfilter.nf_conntrack_tcp_timeout_established = 432000も非常に高い（5日間！）この値を下げない場合、サーバーは過剰な接続でフラッディングしたい人にとって簡単なターゲットになります。これが発生すると、サーバーはすぐに到達しますnet.nf_conntrack_maxの値を上げても、最初の接続のドロップが再び発生します…
以上のことから、NATの後ろにある悪意のあるユーザーからのサーバーを防ぐために、サービス拒否攻撃に悩まされています。
net.ipv4.netfilter.ip_conntrack_generic_timeoutを60〜120秒に、net.ipv4.netfilter.ip_conntrack_tcp_timeout_establishedを54000などに下げます。
linux:~# sysctl -w net.ipv4.netfilter.ip_conntrack_generic_timeout = 120
linux:~# sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 54000
このタイムアウトは、通常のNATユーザーの中断を作成せずにルーターで正常に機能するはずです。値を変更して少なくとも数日間監視した後、/etc/sysctl.confに追加して変更を永続的にします
linux:~# echo 'net.ipv4.netfilter.ip_conntrack_generic_timeout = 120' >> /etc/sysctl.conf
linux:~# echo 'net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 54000' >> /etc/sysctl.conf
http://pc-freak.net/blog/resolving-nf_conntrack-table-full-dropping-packet-flood-message-in-dmesg-linux-kernel-log/ の素晴らしい記事によると=