[Oisf-users] Fwsam Functionality

[Chris Gathright]

Hi Champ,

We're doing something very similar where an EVE file tailer publishes
messages to ZeroMQ topics (e.g alert, dns, http, tls events) and one of the
consumers for alert messages handles blocking. Now that Suricata is logging
more info in the EVE format, the possibilities are endless and our rule
processor adds specific metadata keys/values to rules based on other
criteria. As Eric pointed out, there are some issues with sub-optimal rules
not using target keywords or HOME/EXT vars but lots of progress has been
made here and I think this is the best way moving forward to do on-sensor
processing and event response automation.

--
Chris Gathright
Sentinel IPS


On Mon, Jul 15, 2019 at 1:32 PM Champ Clark III <cclark at quadrantsec.com>
wrote:

>
> > I've not aware of any attempts to port fwsam to another tool. Maybe it's
> > something for your 'meer' tool?
>
>
> Hello Victor,
>
> I 100% agree.  This isn't something that needs to be in Suricata.
> Snortsam is pretty old and not actively maintained.
>
> Here's what I choose to do.
>
> Rather than making a Snortsam plugin,  we've made a "external" plugin for
> Meer.  This allows Meer to execute a command when a signature is hit.
> While its a bit more expensive to call execl() in Meer, it allows the user
> to not only call the "snortsam" command line tool, but execute
> Perl/Python/iptables/mysql/whatever scripts.
>
> Meer hands the "external" program the Suricata EVE data.  It's up to the
> user to decode that and do whatever action they want.
>
> One issue we ran into was telling Meer "what" signatures we want to
> execute the external program on.  At first,  we thought we might be able to
> use the rules "action" (alert/drop/reject/etc).  However,  it appears that
> when Suricata is not in an inline IPS mode and a rule is set to "drop" the
> EVE action still reports "allowed".  Even if that had worked,  this
> solution would not have indicated what (ip_src, ip_dest) to drop?
>
> To get around this,  we have Meer look into the rules "msg" field for a
> drop indicator.  For rules we want Meer to drop (execute an "external"
> progam on),  we add to the "msg" field the word "FIREWALL".   This
> accomplishes two things.   It informs the user that the rule should have
> been "firewalled" via Meer.   This was something that was annoying about
> Snortsam.  There was no indication,  other than manually looking at the
> rule,  that the rule had Snortsam keywords or not.
>
> Secondly, by making the "msg" field "FIREWALL SRC" or "FIREWALL DST",  we
> can have the external program called by Meer direct what direction to
> firewall.
>
> I think this is a much better solution then supporting Snortsam.  I'm
> still working on some example scripts and will hopefully have it pushed to
> the Meer repo today or tomorrow.
>
> This was the best way to deal with this situation that I came up with.  I
> would love to hear anyone elses ideas/thoughts on the matter.
>
> Thank you!
>
>
> --
> _______________________________________________
> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>
> Conference: https://suricon.net
> Trainings: https://suricata-ids.org/training/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20190715/9797753c/attachment.html>