From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: IPFire meets Suricata - Call for tester
Date: Mon, 17 Dec 2018 17:05:28 +0000
Message-ID: <8F49EFF1-9FF8-489D-84BE-085756C89C67@ipfire.org>
In-Reply-To: <15c82e54a0f940be69a82dcf3ae84d14bbbd146e.camel@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7613917463458767643=="
List-Id: <development.lists.ipfire.org>

--===============7613917463458767643==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

What is the bypass mark for? At least that should be set to nothing instead o=
f one, because that will again conflict with the SNAT fix rule.

Best,
-Michael

> On 17 Dec 2018, at 14:21, Stefan Schantl <stefan.schantl(a)ipfire.org> wrot=
e:
>=20
> Am Sonntag, den 16.12.2018, 21:28 +0100 schrieb Peter M=C3=BCller:
>> Hello Stefan,
>>=20
>> to be a bit more precise about the NAT issue:
>>=20
>> My setup is the IPFire Suricata test VM running in KVM, with
>> two clients (Debian and OpenBSD) directly attached to it.
>>=20
>> 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).
>>=20
>> 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.
>>=20
>> Let me know whether is is useful or not. :-)
>>=20
>> Thanks, and best regards,
>> Peter M=C3=BCller
>>=20
>>> Hello Stefan,
>>>=20
>>> back again. :-)
>>>=20
>>> 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).
>>>=20
>>> 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".
>>>=20
>>> 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).
>>>=20
>>> 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.
>>>=20
>>> Any outgoing connection is in state "SYN_SENT" if Suricata is
>>> active.
>>>=20
>>> A portscan against the firewall (GREEN interface) is not detected,
>>> even though ET SCAN ruleset is enabled (used nmap with NSE active).
>>>=20
>>> 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.
>>>=20
>>> Thanks again for your work; I hope the feedback can appreciate it
>>> somehow. :-)
>>>=20
>>> Let me know if there are questions.
>>>=20
>>> Thanks, and best regards,
>>> Peter M=C3=BCller
>>>=20
> Hello Peter,
>=20
> thanks for testing and your feedback.
>=20
> 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.
>=20
> 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.
>=20
> The changes can be found in my git repository:
>=20
> https://git.ipfire.org/?p=3Dpeople/stevee/ipfire-2.x.git;a=3Dcommit;h=3Df5a=
d510e3c0f416a1507999f5ad20ab171df9c07
>=20
> I'll upload a fixed image very soon - please keep on testing.
>=20
> Best regards,
>=20
> -Stefan


--===============7613917463458767643==--