Re: IPFire meets Suricata - Call for tester

[Stefan Schantl <stefan.schantl@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 3309 bytes --]

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=f5ad510e3c0f416a1507999f5ad20ab171df9c07

I'll upload a fixed image very soon - please keep on testing.

Best regards,

-Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]