Am Sonntag, den 16.12.2018, 21:28 +0100 schrieb Peter Müller:
Hello Stefan,
to be a bit more precise about the NAT issue:
My setup is the IPFire Suricata test VM running in KVM, with two clients (Debian and OpenBSD) directly attached to it.
The Debian machine is located in GREEN, OpenBSD in ORANGE. RED interface is connected via bridge to my actual testing LAN; for the first testing, any outgoing traffic to the internet was allowed (I will test upstream proxy behaviour later).
While GREEN was using IPv4 range 192.168.100.0/24, with IPFire as 192.168.100.1, enabling Suricata caused packets coming from GREEN not to be NATted anymore: Instead of using the firewall's RED IP for destination, it was the internal GREEN IP.
Let me know whether is is useful or not. :-)
Thanks, and best regards, Peter Müller
Hello Stefan,
back again. :-)
The new IDS WebUI looks quite good so far - enabling/disabling Suricata works as well as selecting the rule source and the operation mode (IDS/IPS).
I was also able to download the "Snort/VRT Community" ruleset. Trying to switch to the "Emerging Threats" ruleset is possible, but downloading its ruleset afterwards is not: The GUI simply stalls, printing a message that "Snort (!) is performing a task".
The WebUI services page still shows IDS status for each interface, which does not seem to work anymore (everything is stopped, but Suricata was active on RED and GREEN).
Further, a client located in GREEN behind the test firewall instance is unable to browse the internet as soon as Suricata is enabled. If disabled, downloading ET rulesets work as well as internet traffic. At the moment, I am flying blind here, but it looks like packets are not NATted anymore if Suricata is active.
Any outgoing connection is in state "SYN_SENT" if Suricata is active.
A portscan against the firewall (GREEN interface) is not detected, even though ET SCAN ruleset is enabled (used nmap with NSE active).
Especially the outgoing connection/NAT/? issue mentioned above breaks things in my scenario. Anything else are minor issues (of course, a portscan should be detected, this needs further investigation indeed). WebUI works fine so far.
Thanks again for your work; I hope the feedback can appreciate it somehow. :-)
Let me know if there are questions.
Thanks, and best regards, Peter Müller
Hello Peter,
thanks for testing and your feedback.
I've setup a test environment and was able to re-produce your NAT issue very easy. After some research and help of Michael, we were able to find the real issue.
It was located in a identical mark on the packets which already have been scanned by suricata and packets which should be modified for SNAT in the "Mangle" table of the routing logic by the kernel.
The changes can be found in my git repository:
https://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=f5ad510e3c...
I'll upload a fixed image very soon - please keep on testing.
Best regards,
-Stefan