From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefan Schantl <stefan.schantl@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: IPFire meets Suricata - Call for tester
Date: Mon, 17 Dec 2018 15:21:55 +0100
Message-ID: <15c82e54a0f940be69a82dcf3ae84d14bbbd146e.camel@ipfire.org>
In-Reply-To: <0c384081-dcdf-e4d4-763e-c7c73a1db34b@link38.eu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4673910679386546645=="
List-Id: <development.lists.ipfire.org>

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

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,

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=3Dpeople/stevee/ipfire-2.x.git;a=3Dcommit;h=3Df5ad5=
10e3c0f416a1507999f5ad20ab171df9c07

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

Best regards,

-Stefan

--===============4673910679386546645==
Content-Type: application/pgp-signature
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="signature.asc"
MIME-Version: 1.0

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ2dBZEZpRUVXTzBOWHRTcnZo
YXN5dERuVHRkT0ZZK1RzdDRGQWx3WHNRTUFDZ2tRVHRkT0ZZK1QKc3Q0ZCt3LytPVG16NGFRNWps
L1RKRFovRmZXSmR6R0U0SFFIV0xrYng3bXVCcDFlc2ZndUt6ZzdWNWRWOEc3KwpLcUU2eHY2cTRY
YjB6c2liL2dHQ0RVbGYwQlcxUis4MGpPQ1Z3ZHd5QVRnTUI2NW00UkdzL1BHK3dIRmxqeVhjCmdF
VTU2S2Rvc1h2NFp2QWN4NXVIU09zTVZPNGlFZVlTNmc3TjZXRG9RNzl4V2lDUjg2clNlci9Uekla
aE5idmoKejJyc2x6U1hFZUgxb2tKSDh6Z3NvRG5wRXhkSCt4VHREUjR3eG54RkVNaTBLajQrK2Nx
c0lFdThzNG9QZDBrSApnejIvZE4rT21zdEdXZEdZaDA0WHR2Z1JVVlkwbUF0U01VUUgrQzFKK3F5
dmF5cG83dDF1RUdjSHI2NjlBNEQ5ClJxQ1QxaXYrVkQ1amRONmN4c0p3cll2eVBqK1RiYmZjSWZQ
Q1Y4NjhaOHJCTDI3d2NUQWJXWWE2ZkFwMFlNUzUKZlBmSnpNcFRrSEVURkZmL2FCWlVsMW5sQ0cy
K1RMVnoyNitLdyttOTRFamVUQzUzM1hFeTFnOUFjUVFKbzZOUQo4UzBkd08xd0xTV3A4V3pycHdF
WVU3UmRhMEFycy9iSWRNdks2RTFSWlRtSTd3QlFWNWdiT0dXQWkvYlg0cENkCkFVVE9GcTZjNHN0
aU9RWTFwY04wUWVBM1JtM0lPaFdvWGxBYmg3ZTlRV2wvU0xNK0xxUkgzeXJCTlI2NEZkY0QKKzk2
WDBHUTV2U0FyNUlCangzZmtaTXFzMW1LUU5FK0ZCeW84TWlPc09kRTFZdjRLVW0xRGNjS25ROXk5
eXcwdQp3dE5pT0VOd1BuaFJYTTllMWJLSndZVmJ4b0toMkxPU3FTT244MUE2bWl4Y2IvaldvKzg9
Cj1jODZqCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo=

--===============4673910679386546645==--