Sanity check on suppressing alerts

darkphox

Hi folks,

I've been learning and tinkering with pfSense for just a couple of years, and I think I misunderstood how suppression works based on older forum posts I read during my initial setup, like this one. It's quite old and others I remember are even older. Based on my re-read of the latest documentation, suppressing an alert means the action (alert, drop, or reject) STILL HAPPENS, but it just doesn't show a record of it in the "alerts" tab. Is that accurate?

I can be quite dumb and am asking because I think I figured it out the hard way this weekend. "Arduino.cc" was inaccessible, but I wasn't seeing any alerts. Turns out, I had suppressed the rule that dropped connections to ".cc" domains at some point in time, thinking it would permit the traffic as sort of a 'soft disabling' of the rule. Instead, it was still dropping connection attempts to .cc domains AND hiding alerts that it was doing so.

I believe everything is working as intended and just want to make sure I'm no longer confused before I start suppressing rules I still want in place but just don't care to see.

bmeeks

Need some additional information before providing any suggestions.

Are you running Snort or Suricata? I am assuming you are running one of the IDS/IPS package since you posted your query in the IDS/IPS sub-forum.
Are you using Legacy Blocking Mode or Inline IPS Mode with the installed package?

When you suppress an alert, that prevents it from creating a log entry when the rule associated with that event is evaluated. For Legacy Blocking Mode, no log entry event equals no block of the traffic.

Disabling a rule completely removes that rule from memory and no traffic is evaluated against that rule. Normally rule suppression is used to prevent a rule from triggering for a particular IP address. If you suppress a rule solely by GID:SID for all IP addresses, then you are better off in terms of resources by disabling that GID:SID.

darkphox

Thanks for the response @bmeeks

I have a few specific rules that alert very frequently. I'd like them to continue functioning (drop connections) without spamming my alerts tab, if possible.

I'm using Suricata (with Snort rules)

2a. I'm using Inline for a physical LAN interface.

2b. I was using legacy mode on a virtual VPN interface, but disabled it recently. After about a year of functioning normally, it began blocking my internal device IP when a rule triggered (when using either the default or a custom passlist). I haven't had a chance to explore this issue yet, but I've got one or more threads on this forum that I need to catch up on that may provide some insight.

Unrelated: Nice profile pic. I prefer the Federation myself, but have a Klingon translation of Sun Tzu's Art of War at work that I reference at every opportunity.

bmeeks

@darkphox said in Sanity check on suppressing alerts:

I have a few specific rules that alert very frequently. I'd like them to continue functioning (drop connections) without spamming my alerts tab, if possible.

Hmm... no way to do that directly in the GUI on pfSense. You could perhaps custom modify those particular rules to try adding the noalert option to the actual rule text.

@darkphox said in Sanity check on suppressing alerts:

After about a year of functioning normally, it began blocking my internal device IP when a rule triggered (when using either the default or a custom passlist).

I've been trying to chase this down. Unfortunately I have never been able to replicate the problem in my test environment. Not being able to replicate the issue makes troubleshooting it and finding a solution very difficult. I'm relegated to bascially guessing for potential causes. So far my guesses have not found the true issue as random users experience random blocks of pass list hosts.