Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - erioshi

#1
Just revisiting this after some time away.

I ended up moving back to pfSense for quite a while because of Snort and just lived with needing to bring down pfSense on the Proxmox host for the primary router when I wanted up date that Proxmox host.  Everything else works fine.

So why is Snort such a big deal with me?

There are a coupe of reasons.

1) Snort's AppID functionality is incredibly useful and easy to support and use from an IDS/IPS perspective.
2) Suricata only allows me turn a rule on or off.  Snort allows me to except rules by IP address.  This lets me do things like allow my repository mirror to pull repository updates from the outside world, but alert me if other servers are trying to do the same thing.

It is a simple example, but that kind of functionality is really important if I want to be able to bring OPNsense from my home lab into the company test lab.  As it is, OPNsense wouldn't meet the operational requirements for my work environment, even for our test lab, and I need to use another product.

This also means that I cannot look to purchase OPNsense products or support offerings at work.  This literally means I cannot give you corporate money even though I would like to.

Overall I find I much prefer working with OPNsense over pfSense.  I also strongly dislike the anti-community sentiments being given off by the parent organization of pfSense.  Unfortunately Snort, Cisco Firepower, or an equivalent become a requirement once you reach a certain size.  Suricata doesn't really hold up when compared to those tools.
#2
Thank you for your quick response, I will dig into the linked thread when I have a bit of time.

I can snapshot and test, so  I don't mind trying out the new nmap driver and reporting back.

As an aside, I do understand there are significant differences between Snort and Suricata, but I would think having both options available would only grow the appeal of OPNsense within the potential community.  Just my thoughts, I'm done now.
#3
I am having a problem that consists of a full OPNsense crash and kernel panic when I enable the blocking feature within Suricata.  This crash is severe enough that normal reboots end up with OPNsense going straight back into a crashed and locked state.

I am currently running OPNsense 19.1.4, but this also happened with some earlier versions of OPNsense for me.  I do not have a list of the specific versions that have failed, my OPNsense experience has been off-and-on as I keep flipping between OPNsense and pfSense.

I am running OPNsense in CARP/HA failover on two different Proxmox nodes using OpenVswitch to provide the LAN and sever other interfaces to OPNsense.  The OPNsense VMs have plenty of resources.  The only interface currently set within is the LAN interface.

Every time I enable the block option, the OPNsense VM will crash and fully lock up within about 30 seconds.  Once it reaches the crach state it becomes completely unresponsive.  The only remedy is to shut the VN off externally.  If allowed to reboot it will follow the normal boot process until it again crashes and hard-locks.

If left in just reporting mode, Suricata appears to function and generate alerts.

I'm new to Suricata so the correct rule sets, etc. are something I'm just getting to know.  I have a lot of experience with Snort (any chance of bringing that to OPNsense?  I really miss Snort.) so an not a total newb to IDS/IPS.

How do I get this working?

I could roll back to pfSense, but that product has an issue with OpenVswitch as LAN.  I work with Nutanix by day which does use OpenVswitch so I would prefer to keep OPNsense part of my home lab.