From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Schantl To: development@lists.ipfire.org Subject: Re: IPFire meets Suricata - Call for tester Date: Mon, 17 Dec 2018 20:08:50 +0100 Message-ID: <1f2821bc88afa25b10917a144d82ab19fefe3557.camel@ipfire.org> In-Reply-To: <8F49EFF1-9FF8-489D-84BE-085756C89C67@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4226541243256574386==" List-Id: --===============4226541243256574386== 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 of one, because that will again conflict with the SNAT fix > rule. >=20 > Best, > -Michael >=20 Hello Michael, taken from the official suricata.yaml documentation: bypass mark and mask can be used to implement NFQ bypass. If bypass mark is set then the NFQ bypass is activated. Suricata will set the bypass mark/mask on packet of a flow that need to be bypassed. The Nefilter ruleset has to directly accept all packets of a flow once a packet has been marked. In my commit, I've disabled the bypass options to exactly prevent from any issuse again with the SNAT packet mark. Best regards, -Stefan > > On 17 Dec 2018, at 14:21, Stefan Schantl > > wrote: > >=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=3Df= 5ad510e3c0f416a1507999f5ad20ab171df9c07 > >=20 > > I'll upload a fixed image very soon - please keep on testing. > >=20 > > Best regards, > >=20 > > -Stefan --===============4226541243256574386== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ2dBZEZpRUVXTzBOWHRTcnZo YXN5dERuVHRkT0ZZK1RzdDRGQWx3WDlFSUFDZ2tRVHRkT0ZZK1QKc3Q3TThCQUFxYm1IenQ0dmQ0 Zm5XVXpxUmFGTk5pT1o3eVFoS3laT3I2OFZOSG9mRXpDcVRxR0l1TDRNL3p6NQpBS0Q4MzdZZ1hI YmxYWTQrQ3pZbktCT2ZFODV5cUdzWGQvdnc0TkthNjRQdXVPOGRRUjludU8zTkp5dllsR0V4CmJt VUtlQ1Q3cFVZcHJYWUZNSFM2MzJqZUxNYUh0Z2lqbTkxR3VOMHVHOTJnaWlEMWRlNkRBandDV1Y0 U2ZjTjkKbHlBalRzY0U1dURqLzZqamlWL2JUVzFIWC9ueDRrV2dlZDJlNmJnV1V5bE50cXhvUVo3 K2JkOWw2emdvYmRaVwo4cWZYRm1jeGZnT1d4c0hhVTFSdjlmZFRROFJBM2VwR0Nzam1lKzJRV0Nx MCtjMWs4ZEREd0J4WWRZd1ZmekhlCjRkOWovYkFOMXBLUU8zdFJhbHVEMVVsVUoybGZmWVhPV1Vh R0xHTldKRlFKVC9OeHZRUDZsWXMwUXBiWDFQWmsKRWFuMHg1VVRzTjVaa2JHSVhzcnREeUNKZ0M2 YWxOTFM4WDdmVUw3K3QxNmFZbk1XV0pMQmQvN1hsSGJuTmpOZQo5VGNIT284Nkt2NUxWV0prZS9Q bko3emdQS2QvNk9ZTS9UaTJ2MDl1YmFpWTZ5NHVrUlcwNk5aSlZPYnpoM2dJCjJ3RWRxek1ydjZn bE1lYTc4Y2lNM3kzL001Z21PeTZCTkdPd3RuZFRUK1VFUzQza3ZYZFQ1L1JDWkwwSEgzNVoKOEVl QjZyV2tJOE1MYmdlQU0wOG1yYkFiYXNTN2VRN0V2Q01iK1pNTERCdmRSbXdaS3BhT1lqMnBnMDZL YjFGOAp2aFNCelVZekVYOEY3NmpickhBNCtiRU8yK2owNjY0TGptVW1jK0xvNm04Y1ZyV2ZVVmM9 Cj16UHVICi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============4226541243256574386==--