我在 NFQUEUE 模式下使用 Suricata IDS:
iptables -A PREROUTING -m mark ! --mark 0x1/0x1 -m comment --comment "Suricata NFQUEUE handler" -j NFQUEUE --queue-num 0 --queue-bypass
今天服务器端口一段时间不可用,此消息出现在kern.log
:
18:51:53 up02-lb kernel: nf_queue: full at 4096 entries, dropping packets(s)
我怎样才能增加它?它不受任何 sysctl 参数控制,我在/proc/net/netfilter/nfnetlink_queue
.我增加max-pending-packets
了suricata.yaml
,但我不确定这有帮助。
答案1
该值由 Suricata 设置。它使用 suricata.yaml 中的“max-pending-packets”并将其乘以 4
int r = NFQInitThread(ntv, (max_pending_packets * NFQ_BURST_FACTOR));
if (r != TM_ECODE_OK) {
其中 NFQ_BURST_FACTOR 为 4。请参见https://github.com/inliniac/suricata/blob/71a3c4caac22b475c09ee2f082f11d443dc02cc0/src/source-nfq.c#L712
您可以增加 suricata.yaml 中的值。如果将 max-pending-packets 设置为 4096,您应该得到类似以下内容的输出:
[6146] 7/6/2016 -- 20:31:12 - <Info> -- binding this thread 0 to queue '0'
[6146] 7/6/2016 -- 20:31:12 - <Info> -- setting queue length to 16384
您可以尝试的另一件事是启用“失败打开”支持。这意味着在内核端,当 Suricata 无法跟上时,NFQ 正在传递数据包。但这会导致安全风险,因为某些数据包不会被检查。
来自 suricata.yaml:
# On linux >= 3.6, you can set the fail-open option to yes to have the kernel
# accept the packet if suricata is not able to keep pace.
nfq:
# mode: accept
# repeat-mark: 1
# repeat-mask: 1
# route-queue: 2
# batchcount: 20
# fail-open: yes
如果取消最后一个打开的注释,将启用故障打开支持。
我绝对建议在启用故障打开之前增加队列长度。