OPNsense Forum
English Forums => Intrusion Detection and Prevention => Topic started by: dcol on November 20, 2017, 04:06:52 pm
-
I just realized that OPNsense has a set time to release a block for IDS. What is this time period and is it possible to make it adjustable or change the value from the shell?
Here is a screenshot from the console, but not sure if this is IDS related. If not, then what does this message mean?
-
SEGVGUARD is an exploit mechanism in HardenedBSD that will prevent brute force attacks against services: it will prevent services from restarting when (being) crashed too many times, which can be a symptom of someone trying to attack your system remotely trying to execute arbitrary code. IT can also be a problem with persistent crashes of daemons due to misconfiguration or software bugs that are not exploitable.
Long story short, something is causing your syslogd to crash, either due to configuration or a bad system state or otherwise.
Cheers,
Franco
-
What about the IDS block release time? How long does OPNsense allow to pass before it releases an IDS block, If ever. Also, where can I see a list of currently blocked IP's?
-
Blocks are inline per flow once drop kicks in via rule, not based on IP. I don't think we have a blacklist feature for offending IPs. But I could be wrong.
Cheers,
Franco
-
Blocks aren't inline unless you turn on IPS. When an IDS block is triggered, is the offender placed in a block table then managed by the firewall? This is how I have the pf box setup.
-
IDS has two modes on pfsense. Legacy and inline.
Legacy blocks an IP for a specified period of time if any rule is triggered.
Inline blocks each offense as it occurs without considering the IP unless the IP itself is the trigger...
Legacy blocks by IP.
Inline drops by offended rule.
Blocking by IP is not optimal.
-
That leads me back to the original question. What is that specified period of time, and is it adjustable?
-
Inline? On opnsense or pfsense?
Either way, there is no time since no IP is placed on a block.
Each packet/connection is evaluated each time to see if it violates a rule. If so, it alerts or drops.
If you are in inline mode on pfsense and have a time set, that setting isn't doing anything.
-
Not inline. Right now inline/IPS does not work for me. The link keeps going down when IPS is on the WAN.
My question is for legacy mode in OPNsense
-
In that case the block is per IP. Yes. It would have to be.
Not sure about setting times. I need another day or so to dig into the feature in opnsense.
-
Thanks, that would be good to know. Also if it is changeable in a file somewhere.
-
Inline IDS is such a great feature. I'm really only now getting used to it myself. I will take a closer look in the next day or two. I've been busy with a little work and fighting with a hypervisor.
-
I still don't think IDS mode does anything but alert how it's supposed to in general. :)
Cheers,
Franco
-
You think IDS on opnsense only alerts? Even if a rule stipulates drop?
Well... I suppose that is the D in IDS. Not super useful for most people if that is true, but I'm going to test it.
-
Hmm, did not expect levelling expectations here using https://en.wikipedia.org/wiki/Intrusion_detection_system and specifically:
"Some IDS have the ability to respond to detected intrusions. Systems with response capabilities are typically referred to as an intrusion prevention system."
or...
"A system that terminates connections is called an intrusion prevention system, and is another form of an application layer firewall."
... but here we are. :)
Cheers,
Franco
-
PS: IDS more or less came from tap-based network scenarios, so there was no way to respond either way as hardware was not capable of doing inline analysis yet and that is how the industry treats the IDS / IPS split until today although hardware and software has caught up.
-
That wasn't a snipe. Perhaps I need to work on my diplomacy.
-
No, I'm not trying to defend anything here, I'm just trying to say what we have and why we have it aside from the fact that other projects may differ in philosophy and implementational details. :)
Cheers,
Franco
-
Since inline captures before firewall inspection, there is no need to keep offending IP's. That was a necessity with Snort which used tables to keep a history of offending IP's for the firewall to handle on repeat offenders. But the biggest downside of Legacy is the first packets do make it inside the network before the firewall has a chance to drop it. Really not a 'true' firewall. Like blocking the fire but letting the sparks in.
So building a system around Suricata inline and abandoning Snort IDS makes for the most hardened firewall you can have. This is what hooked me with OPNsense which I consider the best open source firewall available. Now as a user I need to just concentrate on the IDS rules to get the maximum protection. This is where OPNsense needs to concentrate its resources. Rules management.