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: Sun, 17 Feb 2019 20:57:43 +0100 Message-ID: <5e337fe8b5f9b059de6b7510aa897635a6cbf5d9.camel@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6647332293971665853==" List-Id: --===============6647332293971665853== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, thanks for your feedback. > Hello Suricata Testing Community, > Hello Stefan, >=20 > I just installed the =E2=80=9Crc2=E2=80=9D image on my production system on= my desk. >=20 > I am afraid that I can confirm that no new connections are possible > any more after Suricata is being started. I suppose this is due to > some of the latest changes to the suricata configuration file. The > iptables chains look fine and some other traffic continues to pass. >=20 > Not sure what I can do about this now. Finally I figured out, why this happened to you and Wayne (which also reported this issue) and I was not able to reproduce that. During development we have got this issue one, because of SNAT used the default mark of "1" to mark it's packets. This internal mark will be increased by each interface, so if you are using blue or orange too, the mark "2" (which currently is used by suricata) also is in use. If all 4 possible interfaces are present, the mark "3" also is in use for SNAT. Snip from "iptables -L -v -n -t nat" Chain NAT_DESTINATION_FIX (1 references) pkts bytes target prot opt in out source destination =20 0 0 SNAT all =20 -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x1 to:192.168.xxx.xxx 728 83711 SNAT all =20 -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x2 to:192.168.xxx.xxx 0 0 SNAT all =20 -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x3 to:192.168.xxx.xxx So we have at least to use "4" to mark the packets which are inspected by suricata - which worked on the testmachine with full interface configuration. But what happened if OpenVPN or IPsec is also in use and clients are connected ? Will there be spawned any additional rules with marks and we ran into the same issue again ? What would be a good mark default for suricata to prevent from this ? Thanks in advance, -Stefan >=20 > I found that this is a bug:=20 > https://bugzilla.ipfire.org/show_bug.cgi?id=3D12002 >=20 > -Michael >=20 > > On 17 Feb 2019, at 11:58, Stefan Schantl > > wrote: > >=20 > > Hello list, > >=20 > > a short note from suricata development. I've uploaded the second > > release candidate, which fixes several issues and bugs. > >=20 > > Now, the "services.cgi" will correctly show the IPS as running, and > > logrotate and collectd will handle the correct service. > >=20 > > The new tarball (i586 for 32bit-systems, and x86_64) can be found > > here: > >=20 > > https://people.ipfire.org/~stevee/suricata/ > >=20 > > To start testing download the tarball and place it on your IPFire > > system. Extract the tarball and launch the install (install.sh) > > script. > >=20 > > If you already have installed a previous test version or image, > > with > > the same steps as noted above you can update the the new version. > >=20 > > As always, if you prefer a fresh installation, the latest image can > > be > > grabbed > > from here: > >=20 > > https://nightly.ipfire.org/next-suricata/latest/x86_64/ > >=20 > > Direct link for downloading the ISO image: > >=20 > > https://nightly.ipfire.org/next-suricata/latest/x86_64/ipfire-2.21.x86_64= -full-core128.iso > >=20 > > Thanks for downloading and testing. There are no known bugs so far, > > as > > usual please file any bugs to our bugtracker ( > > https://bugzilla.ipfire.org) and share your feedback on the list. > >=20 > > Best regards, > >=20 > > -Stefan --===============6647332293971665853== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUFCQ2dBZEZpRUVXTzBOWHRTcnZo YXN5dERuVHRkT0ZZK1RzdDRGQWx4cHZMZ0FDZ2tRVHRkT0ZZK1QKc3Q1aXJ3Ly9mYVp5TkJ2bWNk TENHNFlRaGZOQ3NYOVkxNkhxYjNsalZIQ0ZhcEtJOVVzK3pNR3lHTXk3QnhaRwpVRXBRVWZMaXV0 ZENuMTdKTy9zTlptdDR1d2lDOXJEb0dOSis0YUszQTBEQTkrb3lrVm1tZmdJTTFjZUtoYzNkClAz cjBvOUhwUzdQUEppeEgxVklZRHVwQjBlNUUrMGRrcDd0ZFVKS2JpZTAwVFhmQUgwNDZZdGppZUpX czNvdnYKVFZYc0N2K3g2VUN1Ujl6Z1FqUG1aUFBXYUZsSVJtTFlDZ0dEWHVTbldZT3BVSlV6N3NZ TjAyMXduRnFKSDFHawo2VTFOZVBZRGthbGE3K0U4c1ZncE5QV3J2VmFWMVJNQiszbGlzaC9UNThI cUx2cEFoejYyZmEvaVdmZkdndFFECkE3S2M4TzBtbmJMQnhzcjJFZmVBZHY4N2ZBZmQyQkNHUzl4 VkZGZWt3TXB6MW5odW5xZGhsRDFweXRMVXFnMlAKWmNQMll4eHkzMjZaL0RMTkVScHVjRlR4THRq bm1LcnhrTlJHd0tQZE5PZGkwYktTUHlEOXg2MlVoc05zTWl3TwpnTHVLU1l2RnREdTh6VUgxK3NN cUlTSmI3YzdidGJxaWFvMHRNRkNKSXpVWDlGd2lvTzNuWjRhZFgxOXVKWXZOCjVpSTVHdjRuaW1L c0FJdjQ1bmUyK1VrL0xYVzhXakNRd0pzVURXTjUxVHYxSmxRalhPUFZJbGV4bDVSZm1rVDkKWkFy RUs0QS9zNGxUR0J1S0dLNWMwN0tiVWlYQnFxU2dkSzZsYU5yQ2k2eWQ4OCtaQVlqNnNVcU1EY3Rq NEs1MAp3MWtoVVlXZm84T0ZDWWswQVE0b3d5VE84UDFDc0wxa2hvS3I3d0QrM2tkS1FITS9FcFE9 Cj1aYlFqCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============6647332293971665853==--