SIEM Question: Excessive Firewall Denies / Rule Edit Question

Question

We have a SIEM in our environment that we're currently tuning and part of that process is reducing the noise in our console.

One offense I've been working on is: Excessive Firewall Denies Between Hosts containing Session Denied.

The rule that is triggering from the traffic and generating the offense is: Anomaly: Excessive Firewall Denies from a Single Source. The rule is constructed as follows:

- and when any of these BB:CategoryDefinition: Firewall or ACL Denies with the same source IP more than 400 times, across exactly 1 destination IP within 10 minutes

I took a sample of 10/20 offenses and looked at the traffic and confirmed the traffic is hitting our external interface in the DMZ and it is being denied by our firewalls. No allows.

Since we are generating a lot of noise in our console, I raised the timing threshold in the rule from 10 minutes to 15 minutes which was still triggering offenses. I then upped it from 15 minutes to 30 minutes. + My question is, since the denies we are seeing are legitimate denies, should I increase the threshold of time and/or instances for the rule to trigger an offense so I only see a sustained attack to our public facing IP's? What risks would incur if I made this change, if any?

Thanks for the assistance!

Answer 1

This looks like a QRadar rule. It would be good to ask the question on the IBM developer forums as you will have more QRadar administrator eyes on it.

That being said, firewall denies are inevitable if you have a DMZ. The flaw is that many people look at just firewall denies, but do not look at firewall permits. Denies are only affirming what you hope to see. The permits are where the real danger lies.

For misconfigured services:

If the denies are related misconfigurations or known services, either fix the services or add them to the false positives list.

For any non-legitimate services or malicious network scanner:

Create a rule that catches more than X number of firewall denies in X minutes (These are numbers that you should be comfortable with). Then use that rule to add offending source IP to a reference set (For example, call it: Reference Set: Malicious Scanner). Finally, create another rule that checks for BB:CategoryDefinition: Firewall or ACL Accept (assuming you are logging permits) and checks against the Reference Set: Malicious Scanner. When a firewall permit is logged from an IP in the Reference Set: Malicious Scanner, a new offense should fire. This way, you are catching when a known-suspicious IP address manages to successfully get past the firewall.

If you are not logging permits, but are using netflow data, create a flow rule that checks against the Reference Set: Malicious Scanner for any traffic that does not hit the DMZ network. This may help you identify if an IP manages to bypass the firewall. Netflow data is not as accurate as logs.

Answer 2

I believe you are using Qradar SIEM. That's just a normal event if your firewall is placed on the DMZ. But it depends on your analysis, if the offending IP queries multiple ports on 100 times that is clearly a port scan. But if it just involves 1 or 2 ports then you might have a misconfiguration on your firewall.

My rule is Firewall or ACL Denies with the same source IP more than 100 times, across exactly 1 destination IP within 5 minutes.

I think there are no risks if it is all Firewall Deny, it has been mitigated already. Attacker can't bypass that, but you should also make sure that you can detect exploit attempts from your IPS/WAF. That's when you should block the offending IP on the firewall end.

Perimeter Attacks are easy to contain since you only specify the allowed ports on your DMZ Firewall such as 80 or 443 only. It's better if you have also monitoring on your DMZ servers/endpoint by deploying EDR / Endpoint protection. (Defense-in-depth / Layered Protection)

Answer 3

I think instead of increasing the time Frame it would be better if u increase the no of hits towards ur public facing IP. In that way u can get a sustainable offenses .

And later u can create a reference set as suggested before for malicious IP and can create a rule to check if any of ur internal IP's are trying to communicate with them.