After installing Suricata missing standard fuctionality behind

RobertS 0

After installing Suricata I miss some standard fuctionality behind pfsense**.

Incomming mail - The password confirmation mail for the netgate forum from the google mail servers got blocked SURICATA Applayer Detect protocol only one direction
debian/ubuntu system update - apt upgrade on debian/ubuntu systems is not working anymore (different source servers). The message ist here SURICATA STREAM ESTABLISHED invalid ack

Does abybody has a solution/hint how to resolv these issues?
After all, it can't be the point of an IDS/IPS that you have to check all standard services for their correct function after installation and whitelist individual servers with which you want to communicate or switch off entire sets of checks

bmeeks

You need to study up on false positives with IDS/IPS and learn about suppressing alerts or disabling rules.

An IDS/IPS package like Suricata or Snort is NOT like an anti-virus package that you can just click a few checkboxes and forget about it. It takes a lot of knowledge about malware threats, the attack surfaces exposed in your internal networks, and a fair amount of experience to administer an IDS/IPS.

The job of an IPS is to block stuff, so that means the admin must carefully research which rules to enable for blocking based on the security exposures in the protected networks. You don't just go enable everything -- unless you enjoy nothing in the network working properly anymore ... .

Run Suricata in non-blocking mode for several weeks in order to get a feel for the types of alerts that your network traffic generates. Check the ALERTS tab frequently and research each triggered rule to determine if it represents a true security event, or if it is a false positve. For repeat false positives, you likely want to disable that rule in your environment.

SteveITS

@roberts-0 Actually the general advice here is to run it without blocking for a while, to review the alerts.

Our install notes for Suricata say "disable ALL stream-events.rules or it will block lots of traffic on false positives." Also "check 'Disable hardware checksum offload' in (System->Advanced->Networking)."

RobertS 0

@steveits
Thank you for your hints, they have helped me a lot...

What I've done:

I've checked "Disable hardware checksum offload". I don't know if that helped, but in a virtualized environment, I trust network stacks to do anything
I removed an interface from the Suricata configuration. I now only scan on the outermost interface and ignore the underlying networks with public IP addresses. That was probably too much of a good thing and makes no sense.
Now the situation looks much better and, above all, more understandable. As an example, I have now eliminated the SMTP problem by disabling the rule "SURICATA Appplayer Detect protocol only one direction". No more blocked traffic, but still the display in the alert report (which is what I want)
But what surprises me is the following:
The rule "SURICATA Appplayer Mismatch protocol both directions" produces an alert and also a blockage, although only ALERT is mentioned as an action in the alerts log. Shouldn't it say BLOCK here? Or does the blockage come from another rule that I haven't understood yet?

RobertS 0

@steveits
Or comes the blocking from the setting "block offenders" in the interface tab?
Each alert results in a block. If I remove the "block offenders" setting, I have to change the rule where I want a "blocking" if the rule matches. Right?

bmeeks

@roberts-0 said in After installing Suricata missing standard fuctionality behind:

@steveits
Or comes the blocking from the setting "block offenders" in the interface tab?
Each alert results in a block. If I remove the "block offenders" setting, I have to change the rule where I want a "blocking" if the rule matches. Right?

Go read these two Sticky Posts I created some time back, and your questions should get answered:

The first one describes how to use "Block on DROP" instead of the default where all alerts result in blocks. The second link describes how to use the SID MGMT feature to selectively change the action of particluar SIDs from ALERT to DROP.

If your NIC hardware is supported, and you are not using VLANs, you will find Inline IPS Mode to be a better method for blocking. It can be much more selective about which types of traffic are blocked without blocking a host entirely by blocking its IP address. Of course with Inline IPS Mode, use of SID MGMT is just about mandatory because you will need to change the action to DROP for those rules that you wish to actually block traffic. Otherwise the action stays at the default of ALERT, and you would have nothing blocked.

SteveITS

@roberts-0 said in After installing Suricata missing standard fuctionality behind:

now only scan on the outermost interface

Suricata runs "outside" the firewall so consider running in on LAN interfaces instead of WAN. Otherwise it will scan packets the firewall will drop.

RobertS 0

@steveits
Seems to be a Question of definition what is LAN and WAN...
I've some official public /24 networks with outsinde reachable systems in it and one private /24 network for internal systems.
In front of all these networks is a /27 network. You may call it "border network". Most of filtering and firewalling is done on that "very" external interface even if the rules are pointing on systems in one of the official /24 nets.
I've choosen now to let suricata just scan on the outside-outside gateway interface of the /27 net.
This also has the advantage I've just to maintain one interface.

RobertS 0

@bmeeks
This looks quite cool...
I'll try some things out tomorrow during office hours - so I can have a look on the results more or less in livetime.
Keep you informed