<div dir="ltr"><div><div><div><div><div><div><br></div>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.<br>


<br></div>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.<br>


<br>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).<br>


<br></div>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.<br>

<br></div><div>This suricata feature request added a per machine sensor_id<br><a href="https://redmine.openinfosecfoundation.org/issues/667">https://redmine.openinfosecfoundation.org/issues/667</a><br><br></div>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.<br>

<br></div>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.<br><br>

</div>ta,<br>Mark.<br>
</div>