Messages

IPS on layer 2 only works if the host can actually intercept the traffic "in line", meaning there is a transparent filtering bridge configuration.

Thanks. I suspected that a filtering bridge with two physical network interfaces would be necessary. I will put it behind my perimeter OPNsense firewall so that the Suricata bridge is the first in-line feeding the DMZ network where the publicly accessible services are located. The internal OPNsense firewall/router will be next with the ELK stack located on one of it's internal networks.

I am not certain at the moment if it is worth having a third interface on the Suricata IPS to isolate logstash traffic. I keep all my IPMI, SNMP and syslog on an isolated VLAN that has no internet connectivity.

Just note suricata is not a firewall at present.

I use OPNsense for firewalling.

I found what I was looking for in the Suricata documentation, 23.2.2 Setting up IPS at Layer 2, sections 23.2.2.1 and 23.2.2.2
https://docs.suricata.io/en/latest/ips/setting-up-ipsinline-for-linux.html

This guide helps me achieve the second goal:
https://www.criticaldesign.net/post/how-to-setup-a-suricata-ips-elk-stack

It would be nice if I could configure a third OPNsense machine as a dedicated Suricata IPS, but I will follow the Linux documentation first to get a working system. I will take a look afterwards to find out what OPNsense config would be necessary to achieve similar functionality, or use a FreeBSD host. I am interested to compare performance between bot OS on the same hardware.

I have only ever used Suricata and Snort on a firewall device, but I am intrigued about using it on a dedicated host and removing that processing overhead from the firewall(s). My network has a classic two firewall and DMZ setup. One firewall is a perimeter firewall with internet on one side, DMZ on the other. The second firewall is a firewall/router that has DMZ on one side and separate internal networks on the other. I would like to locate a dedicated Suricata box in the DMZ as a sensor. I understand how this would work as an IDS with one interface, but I don't know how exactly I could get a dedicated Suricata host to act as an IPS without running two interfaces as a filtering bridge. All of my managed switches are layer 2. Can anyone point me to a howto for this type of setup? I am interested in using the full scope of Suricata features for packet capture and trend analysis with an ELK stack.

It worked for me too, until it didn't.

One thing that I have done between creating DNS hostname aliases and upgrading to 24.7 is restoring from a config backup. I don't know if that is a factor in this problem or not. I have a spare machine that I can build from scratch without using a config restore. If that works, I will do a backup and restore to see if that stops aliases from being visible.

I had a look for the relevant code and found this:

https://github.com/opnsense/core/blob/master/src/opnsense/mvc/app/views/OPNsense/Unbound/overrides.volt

I think it is 'Bootstrap' code but I am no Javascript expert and the author didn't think it was necessary to add dependency info in a comment. I don't think it is Bootstrap 5 as 'overrides.volt' appears to use jquery. Bootstrap 5 is vanilla Javascript without jquery.

TIP: It does help others that are not familiar with your code to state in the comment header the library dependencies even if that is just a reference to a README where all the info needed to get someone up to speed when debugging can be found. All the relevant info may be obvious to the author but leaving it out is just another obstacle to discourage someone else taking a look at the code to fix it.

Line 255 of overrides.volt says that the table ID is 'grid-aliases'. There should be some Javascript code to populate the area of the table between the tbody tags on line 266-267. I couldn't find the methods for grid-alias-wrapper so I gave up.

Sadly, debugging this is beyond me. My workaround is to empty the Unbound config on OPNsense and run a separate resolver in a jail on another FreeBSD host configured using a text editor. If the GUI is broken and no longer provides any advantage then it is more secure to have a known good config in something that can be maintained than in a GUI that makes it invisible.

Just to be certain that it wasn't a browser fault, I tried adding aliases using Firefox and Chromium on FreeBSD 14.0 and Firefox and Edge on Windows 10. All four had the same result.

Hopefully, someone with much better Javascript skills than me will fix this.

Oh dear, I have also become victim to this bug after upgrading to 24.7 . However, I had five DNS host aliases already defined but now only one shows up in the GUI. All are in the config.xml and resolve OK.

I can create new entries in the GUI form but they don't show up in the GUI list of host aliases, only the first one that I defined some time ago is displayed. When I download a backup and examine the XML, all of the aliases are present including the new entries. When that backup config file is used in a restore, the new hostname aliases are active but they still fail to show up in the GUI.

I accept what you are saying.

I suspect that v2.5 of the other product will push quite a few like me to migrate to OPNsense. Their soon to be mandatory AES-NI requirement has brought me here.

Each migrator will evaluate OPNsense according to their own use case priorities. The importance of 'easy rules' will be different for everyone. I didn't realise how much I use this feature in my rule development process until now.

I look forward to seeing the return of easy rules to OPNsense.

I hope the 'easy rule' feature reappears before the competition releases v2.5 . I use this feature a lot and it's a show stopper for migration.

No woes? No complaints? No wishes?

Actually one show stopper for me.

I don't use modern hardware with AES-NI, but I do have quad core Xeon machines each with two Broadcom 5823 Crypto Accelerators inside. They work really well with the ubsec driver and cryptodev.
http://www.broadcom.com/products/Security/Encryption-Coprocessors/BCM5823

Sadly, the LibreSSL people don't like old kit and have cut out all the hardware crypto card support that is still in OpenSSL. This pretty much means that I have a substantial performance advantage staying with OpenSSL. Consequently, although I am interested in testing OPNsense, replacing OpenSSL with LibreSSL pretty much makes it pointless for me to participate.