Re: IPFire meets Suricata - Call for tester

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

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

> > On 21 Feb 2019, at 21:56, Mentalic <mentalic(a)cox.net> wrote:
> > 
> > Made an attempt at importing the suricata tarball into current
> > release core127 with guardian installed but no luck. Tar command
> > exits with "This does not look like a tar archive". Had used "tar
> > -xvf" to extract... Could be doing something wrong here?
> 
> Good point actually.
> 
> @Stevee: What is the migration path away from Guardian? This kind of
> needs to be uninstalled or the CGI needs to be stripped to remove all
> IPS features from it.

I did not think much about this until yet. There are two possible
solutions:

1.) Keep guardian, and remove the option so monitor the snort events,
which limits guardian to be a simple brute-force detection tool against
SSH and the WUI-login on IPFire.

2.) Entirely drop guardian.

What do you think? 

@All Any comments ?

Best regards,

-Stefan

> 
> -Michael
> 
> > Regards
> > Wayne
> > 
> > 
> > -----Original Message-----
> > From: Development [mailto:development-bounces(a)lists.ipfire.org] On
> > Behalf Of Stefan Schantl
> > Sent: Wednesday, February 20, 2019 1:55 AM
> > To: development(a)lists.ipfire.org
> > Subject: Re: IPFire meets Suricata - Call for tester
> > 
> > Hello again and thanks for the feedback.
> > > Exposed my test setup directly to my cable modem and noticed a
> > > couple 
> > > of things.
> > > 
> > > -The Firewall log seems to only list items that match my
> > > firewall 
> > > rules. Gone was the typical several a minute "drop_input" entry
> > > noise, 
> > > there was zero drop_input's in 15min or so. Possible logging
> > > issue?
> > 
> > The IDS/IPS events are not logged to the firewall log. They only
> > can be accessed in the "Logs"->"IPS Logs" section.
> > 
> > > -Suricata placed entries into IPS log, but what is done with
> > > them?
> > > Don't see a block list like Guardian generated.
> > 
> > Thats exactly how suricata works and the main benefit why we choose
> > to switch to suricata.
> > 
> > The old snort/guardian solution worked like this:
> > 
> > Snort detected (based on it's ruleset) an event and logged it to
> > it's logfile. Guardian read this event from the file, parsed it
> > again and if the configured block count for the matching IP-address 
> > was reached, the host was blocked by an iptables rule (block list).
> > 
> > The new suricata-based solution works like this:
> > 
> > Suricata detects (also based on the ruleset) an event and directly
> > drops the bad package. There is no additional software involved
> > anymore .
> > 
> > So one of the benefits of the new approach is to reduce the amount
> > of time an attack has been recognized until it's blocked
> > immediately.
> > 
> > > -Are there any incompatibility issues with using the backup
> > > function 
> > > to restore to this version? I had made a backup from my core 127 
> > > system with the old intrusion detection/guardian not active just
> > > in 
> > > case.
> > 
> > There is a converter-script available, which will move the old
> > snort/guardian and rules settings to be used by suricata. This
> > script automatically will be called if a backup gets restored,
> > which contains such settings files.
> > 
> > Therefore I would ask you to test this feature by restoring such a
> > backup on a fresh installed nightly machine and if possible to
> > install the "update tarball" on a regular machine with configured
> > snort and/or guardian.
> > 
> > In both ways, all your taken settings should be the same for
> > suricata as before for snort.
> > 
> > A big thanks in advance and best regards,
> > 
> > -Stefan 
> > 
> > > Regards
> > > Wayne
> > > 
> > > -----Original Message-----
> > > From: Development [mailto:development-bounces(a)lists.ipfire.org]
> > > On 
> > > Behalf Of Mentalic
> > > Sent: Tuesday, February 19, 2019 4:12 PM
> > > To: 'Stefan Schantl'; development(a)lists.ipfire.org
> > > Subject: RE: IPFire meets Suricata - Call for tester
> > > 
> > > Stefan
> > > 
> > > Yep I had downloaded the nightly and suspected is was not
> > > current, and 
> > > so posted the build number.
> > > 
> > > With the 5d7d8749 loaded I have not seen any of the previous
> > > issues 
> > > nor any others thus far.
> > > 
> > > Regards
> > > Wayne
> > > 
> > > -----Original Message-----
> > > From: Development [mailto:development-bounces(a)lists.ipfire.org]
> > > On 
> > > Behalf Of Stefan Schantl
> > > Sent: Tuesday, February 19, 2019 5:34 AM
> > > To: development(a)lists.ipfire.org
> > > Subject: Re: IPFire meets Suricata - Call for tester
> > > 
> > > Hello Wayne,
> > > 
> > > it seems you accidentally downloaded and tested the wrong image.
> > > 
> > > The latest one is 5d7d8749 were you downloaded one is an older 
> > > release.
> > > 
> > > Sadly the nightly build service and therefore the images are one
> > > day 
> > > later than the upgrade tarballs....
> > > 
> > > You simply can update to this release by using the RC3 tarball
> > > or 
> > > download the available "5d7d8749" ISO.
> > > 
> > > Best regards,
> > > 
> > > -Stefan
> > > > Loaded the new iso, reports build 77c07352. Still having
> > > > connection 
> > > > issues with suricata as soon as its activated where existing 
> > > > connections would continue to work, no new connections were 
> > > > possible.
> > > > Reboot results in no connection timeouts. Disable suricata,
> > > > reboot, 
> > > > connections work.
> > > > 
> > > > Any graphical data trend under Status tab reports errors and
> > > > remains 
> > > > blank. Typically on new installs the trends at least show the
> > > > chart 
> > > > even though data had not been collected.
> > > > 
> > > > Configured options:
> > > > Geoip
> > > > Proxy on green and blue
> > > > URL filter
> > > > suricata on red/blue Running a number of emerging threats rule
> > > > sets.
> > > > 
> > > > Regards
> > > > Wayne
> > > > 
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Development [mailto:development-bounces(a)lists.ipfire.org]
> > > > On 
> > > > Behalf Of Stefan Schantl
> > > > Sent: Monday, February 18, 2019 7:16 AM
> > > > To: development(a)lists.ipfire.org
> > > > Subject: Re: IPFire meets Suricata - Call for tester
> > > > 
> > > > Hello list,
> > > > 
> > > > I've uploaded the third release candidate, which hopefully
> > > > would be 
> > > > the last one.
> > > > 
> > > > It fixes the issue that no traffic could be passed through the 
> > > > firewall when suricata was running on some machines and no
> > > > graphs 
> > > > could be displayed anymore. Thanks to Wayne for reporting and 
> > > > Michael Tremer for testing and fixing.
> > > > 
> > > > 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.x
> > > > 86
> > > > _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 --]