Suricata XMLRPC Sync with different interfaces
-
We have three pfsense boxes - one for each of our offices. While they are mostly configured the same, some differences have cropped up. For example, we have a named interface "VPNC" on each machine, but on one machine it maps to "opt7" and on another it maps to "opt4".
We are syncing our suricata configuration from one of the machines to the other two. This is not working right for the VPNC configuration. While you choose the name "VPNC" from the interface list, it gets recorded as "opt7" in the config.xml file and this gets synced to the remote machine where "VPNC" is really "opt4".
Is there any way around this? Could the suricata package be modified to store the "VPNC" interface name and then resolve it locally? Should I file a bug to request this?
Thanks! I've really appreciated having this package available all these years.
-
Suricata (and Snort) are both married very tightly to the physical interface, so that's why that value is recorded in the configuration stored in
config.xml
. The physical interface name is used on the binary command line when launching Suricata or Snort, it's used in naming the configuration sub-directory underneath '/usr/local/etc/suricata' and in naming the logging sub-directory underneath/var/log/suricata
.Just as with an HA firewall pair, the XMLRPC Sync functionality assumes the sync'd boxes are physically identical right down to the physical NIC interface assignments.
So there is no way to work around this in the package. You need to make the firewalls physically the same in terms of configuration if you want to use the XMRPC sync option.
Changing the package code in an attempt to support this would break all existing installations, so that is basically a non-starter.
-
@bmeeks Thanks for the reply.
But it's not really the physical (OS) interface that is recorded in the config file either - it's entry name in the pfsense interfaces config hash (e.g. "opt7"). So Suricata is already looking that up with get_real_interface() to find the OS interface name (e.g. "ovpns4"). The problem lies though in keeping things in sync - since you can change the interface description at any point, we really must use the interface value instead.
I could still imagine an option for the sync process to use the interface description somehow - but this would be much more complicated than the current process.