[Oisf-users] suricata sensor_id -> barnyard2 : config alert_with_interface_name

[Mark Ashley]

If your suricata monitors more than one interface (7 in my case), the
single, static interface you are supposed to hardcod into the
barnyard2.conf file doesn't make much sense. barnyard is using a unique
sensor name of hostname:NULL if you don't give it the interface.

barnyard2 looks to be low on the author's radar, it hasn't been worked on
for 7 months. It assumes the use of snort, no mention is made of suricata.
It could be forked and new stuff added to make it suricata-aware. Maybe the
author would get enthused enough to merge the mods back to the main tree.

The barnyard2 code also assumes only one interface is being snooped, but
could be extended to handle multiple interfaces (and report on them) if the
unified2 format supported interface reporting. There is a 'sensor_id' field
of four bytes (uint32_t) which suricata could adjust for each alert,
indicating where the alert was seen. (It's worse if you realise attacks are
being seen on $HOMENET interfaces etc).

Issues with this include if a flow/stream is reassembled from multiple
interfaces. Most firewalls have a primary/secondary router config, and
might load balance across them. Which interface do you pick and display?
The one with the first packet of the flow might be enough for most people.

This suricata feature request added a per machine sensor_id
https://redmine.openinfosecfoundation.org/issues/667

Is it a good idea to have a per-interface sensor_id field in the unified2
output? The yaml for each interface can include a sensor_id tag and value
so the admins can lock down a value they can hardcode into the
barnyard2.conf as well... so both pgms can grok the unifed2 files properly.
In the case of load balanced networks, the same sensor_id can be used for
multiple interfaces.

Snorby can be enhanced then to show all alerts on each subnet etc, so you
can find what's bad inside the firewalls (usually amounts to fixing dodgy
configs) and what's hammering on the front door.

ta,
Mark.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20131220/4a82009a/attachment.html>