Support #388
closedSuricata Support in VMs and NFQUEUE Mode
Description
Hi all,
I have successfully setup Suricata on my Centos dedicated server and it appears to be working. However, using the same setup on a Centos VPS , I get IPtables errors when I attempt to run the following command:
iptables -I FORWARD -j NFQUEUE
iptables: Unknown error 4294967295
From my research, NFQUEUE requires 2.6.14 kernel with nfnetlink_queue and nfnetlink modules enabled on IPtables.
The VM provider has indeed confirmed that the VM kernel meets the requirements and that these modules are loaded but for some reasons, I still get the above error when I run the command.
Also I have observed that when running Suricata on the Centos dedicated server with NFQUEUE mode, I get alerts on the fast.log. But on checking the drop.log file, I see no logs there. Please see the output of : iptables -vnL
[root@centos5 ~]# iptables -vnL
Chain INPUT (policy ACCEPT 53M packets, 31G bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 30M packets, 19G bytes)
pkts bytes target prot opt in out source destination
1629K 1273M NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 0
67M 43G NFQUEUE all -- * * 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 0
0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
Chain OUTPUT (policy ACCEPT 57M packets, 53G bytes)
pkts bytes target prot opt in out source destination
1000 59956 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
Chain STALLONE-NATPMD (0 references)
pkts bytes target prot opt in out source destination
[root@centos5 ~]#
A sample of the fast.log is shown below:
Priority: 1] {UDP} 10.80.0.14:4310 -> XXX.XXX.XXX.XXX:52984
12/24/2011-12:01:20.584424 [**] [1:2010140:5] ET P2P Vuze BT UDP Connection [**] [Classification: Potential Corporate Privacy Violation] [
Priority: 1] {UDP} 10.80.0.14:4310 -> XXX.XXX.XXX.XXX:63000
12/24/2011-12:01:20.638323 [**] [1:2010140:5] ET P2P Vuze BT UDP Connection [**] [Classification: Potential Corporate Privacy Violation] [
Priority: 1] {UDP} 10.80.0.14:4310 -> XXX.XXX.XXX.XXX:56470
12/24/2011-12:01:20.792278 [**] [1:2010140:5] ET P2P Vuze BT UDP Connection [**] [Classification: Potential Corporate Privacy Violation] [
Priority: 1] {UDP} 10.80.0.14:4310 -> :13519
12/24/2011-12:01:21.003757 [**] [1:2011706:4] ET P2P Bittorrent P2P Client User-Agent (uTorrent) [**] [Classification: Potential Corporate
Privacy Violation] [Priority: 1] {TCP} 10.80.0.10:52510 -> XXX.XXX.XXX.XXX:80
12/24/2011-12:01:21.806950 [**] [1:2011706:4] ET P2P Bittorrent P2P Client User-Agent (uTorrent) [**] [Classification: Potential Corporate
Privacy Violation] [Priority: 1] {TCP} 10.80.0.10:52942 -> 184.22.108.14:80
12/24/2011-12:01:21.806906 [**] [1:2011706:4] ET P2P Bittorrent P2P Client User-Agent (uTorrent) [**] [Classification: Potential Corporate
Privacy Violation] [Priority: 1] {TCP} 10.80.0.10:52943 -> XXX.XXX.XXX.XXX:80
12/24/2011-12:01:21.808770 [**] [1:2010144:5] ET P2P Vuze BT UDP Connection (5) [**] [Classification: Potential Corporate Privacy Violatio
n] [Priority: 1] {UDP} 10.80.0.10:20625 -> XXX.XXX.XXX.XXX:80
12/24/2011-12:01:22.003710 [**] [1:2011706:4] ET P2P Bittorrent P2P Client User-Agent (uTorrent) [**] [Classification: Potential Corporate
Privacy Violation] [Priority: 1] {TCP} 10.80.0.10:52512 -> XXX.XXX.XXX.XXX:80
12/24/2011-12:01:22.542121 [**] [1:2010140:5] ET P2P Vuze BT UDP Connection [**] [Classification: Potential Corporate Privacy Violation] [
Priority: 1] {UDP} 10.80.0.14:4310 -> XXX.XXX.XXX.XXX:17029
12/24/2011-12:01:22.598426 [**] [1:2010140:5] ET P2P Vuze BT UDP Connection [**] [Classification: Potential Corporate Privacy Violation] [
Priority: 1] {UDP} 10.80.0.14:4310 -> XXX.XXX.XXX.XXX:19794
12/24/2011-12:01:22.598411 [**] [1:2010140:5] ET P2P Vuze BT UDP Connection [**] [Classification: Potential Corporate Privacy Violation] [
I need the Suricata setup to detect and block the bad traffic but I don't know how to see if this is working correctly.
Please help.
Thanks
Updated by Lambert Osas almost 13 years ago
I forgot to mention that I'm using Suricata 1.1.1
Updated by Victor Julien almost 13 years ago
- Status changed from New to Rejected
- Priority changed from High to Low
This problem is not a Suricata problem. There is obviously something not right in the kernel-iptables setup, no matter what your vm provider says. If you google for the iptables error you get thousands of results, so my suggestion is having a look at those to solve this issue.
Updated by Lambert Osas almost 13 years ago
OK. Thanks for the clarification.
However, regarding the other issue, how do I use the Suricata as IPS using the NFQUEUE mode to drop traffic.
I have setup the Suricata in IPS mode according to the guide here:
https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Setting_up_IPSinline_for_Linux
Like I said, I do not see any logs in the drop.log file that indicates that the traffic are being dropped. I don't know if I setup correctly.Please help
Updated by Victor Julien almost 13 years ago
Did you change the rules to "drop"?
Updated by Lambert Osas almost 13 years ago
Please guide me. How do I change the rules to drop?
I just followed that guide there
Updated by Victor Julien almost 13 years ago
Individual rules that start with "alert" can be edited, replacing the "alert" with "drop". This is tedious of course, so I recommend using oinkmaster to do so. See https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Rule_Management_with_Oinkmaster (the part about changing alert to drop is near the bottom).
Updated by Lambert Osas almost 13 years ago
Thank you very much. It is now working fine. I can see the dropped traffic logs now after changing the rules to "drop"
Updated by Lambert Osas almost 13 years ago
One final question regarding the NFQUEUE issue on VM. Is there any alternative to NFQUEUE that can work with Suricata in IPS mode? It appears getting VMs to work with NFQUEUE in Iptables is hard.
Updated by Victor Julien almost 13 years ago
I've successfully worked with nfqueue+suricata in vm's so it's definitely possible. I think the trick with your error is that the iptables and kernel version need to be in sync somehow.
Anyway, the nfqueue mode is the only true IPS mode we have for Linux. You could try FreeBSD with ipfw inline support. Alternatively, IDS mode with active responses (sending out RST's) could be an option, but it's not as reliable in blocking/stopping attacks.
Updated by Lambert Osas almost 13 years ago
Thank you very much for the suggestion. I was thinking in the same direction that the kernel and Iptables version needs to be in sync somehow.
My VM specs are as follows:
OS: Centos 5 (32 bits)
Virtualization: OpenVZ
Kernel: 2.6.18
Iptables Version: 1.4.3
Please will you be kind to offer any suggestion on the IPTables and kernel version and also please can you give me the VM specifications you have successfully used for Suricata.
I really need to run Suricata on VMs due to costs issues.
Thanks
Updated by Victor Julien almost 13 years ago
I have no experience with OpenVZ, so can't help there.
The OS seems terribly old though, if you have the option please use something more recent.
Updated by Lambert Osas almost 13 years ago
Just an update.
It appears there is a bug with OpenVZ based VPS that makes running NFQUEUE imposisble.
I tried XEN based VM and I was able to run NFQUEUE with it without any sweat.
So XEN based VPS is working fine now with Suricata