Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: The Art of Logging SANS ISC InfoSec Forums

Watch ISC TV. Great for NOCs, SOCs and Living Rooms: https://isctv.sans.edu

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
The Art of Logging

[This is a Guest Diary by Xavier Mertens]

Handling log files is not a new topic. For a long time, people should know that taking care of your logs is a must have. They are very valuable when you need to investigate an incident. But, if collecting events and storing them for later processing is one point, events must be properly generated to be able to investigate suspicious activities! Let's take by example a firewall... Logging all the accepted traffic is one step but what's really important is to log all the rejected traffic. Most of the modern security devices (IDS, firewalls, web application firewalls, ...) can integrate dynamic blocklists maintained by external organizations. They are plenty of useful blocklists on the internet with IP addresses, domain names, etc... It's quite easy to add a rule on top of your security policy which says:

if (source_ip in blocklist):
   drop_traffic()

With the "blocklist" table being populated by an external process. Usually, this rule is defined at the beginning of the security policy for performance reason. Very efficient, but is it the right place?

Let's assume a web application firewall which has this kind of feature. It will drop all connections from a (reported as) suspicious IP address from the beginning without more details. Let's put the blocklist rule at the end of the policy of our WAF. We have now something like this:

if (detected_attack(pattern1)):
   drop_traffic()
elif (detected_attack(pattern2)):
  drop_traffic()
elif (detected_attack(pattern3)):
 drop_traffic()
elif  (source_ip in blocklist):
 drop_traffic()

If we block the malicious IP addresses at the beginning of the policy, we'll never know which kind of attack has been tried. By blocking our malicious IP addresses at the end, we know that if one IP is blocked, our policy was not effective enough to block the attack! Maybe a new type of attack was tried and we need to add a new pattern. Blocking attackers is good but it's more valuable to know why they were blocked…

I will be teaching next: Intrusion Detection In-Depth - SANS San Diego Fall 2020

Johannes

3976 Posts
ISC Handler
May 7th 2015
I agree with the sentiment of knowing why an attacker was blocked as being very useful - it is always good to know why something is being done.

For whitelists that were generated at one organisation that I worked for, the comments field in the database indicated why an attacker was blocked.

Depending on the type of attack, the capacity of your infrastructure, and other factors, top of list blocks may be required for those attackers that would otherwise exhaust resources of the WAF and/or Event Logging / Processing systems. Fortunately these aren't needed that often.
Anonymous

Sign Up for Free or Log In to start participating in the conversation!