Re: IPFire meets Suricata - Call for tester

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

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

Hello Michael,

thanks for your feedback.
> Hello Suricata Testing Community,
> Hello Stefan,
> 
> I just installed the “rc2” image on my production system on my desk.
> 
> 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.
> 
> 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         
    0     0 SNAT       all  
--  *      *       0.0.0.0/0            0.0.0.0/0            mark match
0x1 to:192.168.xxx.xxx
  728 83711 SNAT       all  
--  *      *       0.0.0.0/0            0.0.0.0/0            mark match
0x2 to:192.168.xxx.xxx
    0     0 SNAT       all  
--  *      *       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

> 
> I found that this is a bug: 
> https://bugzilla.ipfire.org/show_bug.cgi?id=12002
> 
> -Michael
> 
> > On 17 Feb 2019, at 11:58, Stefan Schantl <stefan.schantl(a)ipfire.org
> > > wrote:
> > 
> > Hello list,
> > 
> > a short note from suricata development. I've uploaded the second
> > release candidate, which fixes several issues and bugs.
> > 
> > Now, the "services.cgi" will correctly show the IPS as running, and
> > logrotate and collectd will handle the correct service.
> > 
> > The new tarball (i586 for 32bit-systems, and x86_64) can be found
> > here:
> > 
> > https://people.ipfire.org/~stevee/suricata/
> > 
> > To start testing download the tarball and place it on your IPFire
> > system. Extract the tarball and launch the install (install.sh)
> > script.
> > 
> > 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.
> > 
> > As always, if you prefer a fresh installation, the latest image can
> > be
> > grabbed
> > from here:
> > 
> > https://nightly.ipfire.org/next-suricata/latest/x86_64/
> > 
> > Direct link for downloading the ISO image:
> > 
> > https://nightly.ipfire.org/next-suricata/latest/x86_64/ipfire-2.21.x86_64-full-core128.iso
> > 
> > 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.
> > 
> > Best regards,
> > 
> > -Stefan

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