Is Suricata Really Worth the Trouble

[EddieA (Eddie Atherton)]

This is more of a general musing and rant, but anyone can feel free to throw in their 2 pence along the way.

The first time I tried Suricata was on a VM testing out a new version of Zentyal, which is what I ran then as my edge/firewall machine, before they started dropping components like hot potatoes. Shortly after starting it I wondered why repsonse times seemed sluggish. I guess the solid 100% CPU it was using might be causing that. A couple of attempts at tweaking it didn’t seem to do anything, so it soon was dropped from the installed list.

After switching to NS from Zentyal, the flavour of the month for IPS was snort. This I ran until I found that it was throttling my internet connection down from 200 Mbit/s down to around 85 Mbit/s. So that got turned off.

Sometime after NS switched from Snort to Suricata, I thought I’d give it a try again, despite my experiences with Zentyal. Happily the massive CPU hit didn’t materialise again. So, I was a happy camper, at least for a while, although I did notice that copying files from my internal LAN to a Samba shared hosted on NS did run like a snail was hand carrying the bytes one-by-one, accompanied by a massive CPU hit. But as most of the time that was happening was during the early hours, when my backups were running, I could live with it.

Then at the beginning of the year, there was a change in some of the rules that bit me hard by blocking a huge number of websites and VPNs, and judging by some of the posts here, I wasn’t the only one. At the time, it was pointed out that I should be selective about the rules used and the actions taken for each rule. Like anyone, other than the developers of the rules, really understands every nuance about what rules to use with what actions. So, again, I turned off IPS.

As part of the responses to my, ond other, post, both Filippo and Giacomo suggested the rule set that NS itself was using. So, a couple of weeks ago I restarted Suricata using that rule set.

After a couple of days, I noticed that a Microsoft automatic update, for the Office products, was being blocked. Maybe that’s not a bad thing, as some folks do think that this is a form of virus/malware anyway. Then last week, I noticed that my daily backup from my RedHat laptop to a share on NS had stopped working. While investigating this, I found I could no longer connect to a Samba share on NS from either my RH laptop, or a Slackware VM. The CIFS mount command was accepted, but never completes. Further digging revealed that, yes, yet again, Suricate was the issue by blocking part of the connection.

I guess that was the last straw and now Suricata if off for good. Unless anyone can convice me otherwise that it does more good that the hassles it causes.

Oh, and by the way, it also throws this out as well:

254 is NS, and 253 is the Samba DC. So it’s getting it’s sticky little fingers in the way there as well.

</Rant>

Cheers.

[filippo_carletti]

Running an IPS on the border, on a system which is a firewall with no services is “easier”.
Personally, I have the habit to check evebox when I see something strange in network connections.

I agree that Intrusion Prevention is hard, both for us (as users) and for rules writers.

[Zer0Cool (cb)]

The answer to if you use an IPS or not really depends on how much of a target your network/devices are to the outside world. If your not worried about it (hopefully because you have taken other strong security measures) then you may do more harm than good implementing an IPS. On the otherhand if your network is getting hammered and its security is #1 then you should likely work out the kinks.

If you do use an IPS, think of it similar to a firewall in that its only as effective and accurate as the rules defined for it. To get to the sweet spot of allowing wanted traffic through and preventing unwanted traffic takes work.

Some people like to go with everything on, strict rules applied and then peel back to allow only the things they need through (deny by default, explicitly allow). Others like to first monitor things (IDS instead of IPS) and then apply rules matching an observable pattern of the traffic.

I am considering implementing IPS on Nethserver at home. My router currently has an IPS built in to it, and while likely not the best IPS, its better than nothing. However what that IPS has shown me, is its catching attempts on a regular basis. I would say it records roughly 1-5 events per day. I think after a 3 month period I cleared it out at around ~200 records.

While I do not have anything critically private/sensitive on my home network, that doesnt mean I dont want to take measures to protect myself. It’d kind of be like leaving your door unlocked because you live in a good neighborhood. Sure its unlikely you will get robbed, but why make it easy for them when you can take simple precautions. I am still deciding if a full blown IPS qualifies as “simple”.

[ForgottenBeast]

I’m a bit late to the battle but I’m going to chime in anyway.

Yes setting up an IPS (suricata or snort) can be a major PITA. Sure enough it can make you lose productivity and access to critical services when false positive happen (and they will happen, that’s why you should NEVER deploy an IPS in an industrial network).

An I(D|P)S isn’t the alpha and the omega of network defense and the pain of setting it up + tuning it can be greatly reduced if you have done your homework on other aspects such as the network design, firewall configuration and so on.

Now for the methodology. After getting bitten recently by too cavalier an attitude regarding turning on blocking mode I’m back to my usual cautious self:

1. Configure the firewall (default deny between all networks, then open whatever is needed).
2. Configure some network monitoring tool (ntopng is a personal favorite).
3. Start suricata in IDS mode (no blocking) and make a first choice among the lists of rules: what is really needed for your network (eg: I don’t care about chat rules for a home network).

Now, since the firewall will already block a lot of junk suricata will see everything that actually passes through, thus drastically reducing the number of possible alerts. With your trusty network monitoring tool you can then get a pretty accurate image of what your network really is about (most traffic goes to such and such critical services and so on). After a week or so of doing more triage amongst the IDS alerts you should have reduced their number to a manageable subset.

Two tools to do that:

1. Disable sids: completely disable this specific rule.
2. Suppress sid: disable this rule when src/dst IP is matched.

I advocate the use of disable sids as only a last resort: if you don’t care about dropbox policy alerts on your wifi network you still want to get an alert if it gets triggered on an unrelated network (say storage/backup or web production where there are no human manned terminals). So you should create a suppress list saying that ips from the wifi subnet shouldn’t trigger the alert.

Last, there is always the possibility of manually fixing the rule so it does not trigger on the false positive.

To sum it up: be selective when first selecting rulesets, then be wary whenever you suppress/block alerts.

Once you are satisfied with the number of false positives and the suppress lists you have set up THEN you can turn on IPS mode and start actively blocking threats.

“But what about the time before that?” you may ask? Well that’s where HIDS come into play: you might still be tuning your network based defense system but you can already have some protection from a host based I(D|P)S.