Re: IPFire meets Suricata - Call for tester

[Michael Tremer <michael.tremer@ipfire.org>]

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

Can confirm that this works now for me...

> On 17 Feb 2019, at 19:57, Stefan Schantl <stefan.schantl(a)ipfire.org> wrote:
> 
> 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