Threat Level: green Handler on Duty: Chris Mohan

SANS ISC Internet Storm Center


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Latest Diaries

The Art of Logging

Published: 2015-05-07
Last Updated: 2015-05-07 02:38:25 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)

[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 blacklists maintained by external organizations. They are plenty of useful blacklists 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 blacklist):
   drop_traffic()

With the "blacklist" 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 blacklist 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 blacklist):
 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…

Keywords:
0 comment(s)
Meet Johannes Ullrich at SANSFIRE!

If you have more information or corrections regarding our diary, please share.

Recent Diaries

Upatre/Dyre - the daily grind of botnet-based malspam
2 days ago by Brad Duncan (3 comments)

Traffic pattern change noted in Fiesta exploit kit
2 days ago by Brad Duncan (0 comments)

VolDiff, for memory image differential analysis
3 days ago by Russ McRee (0 comments)

Massive malware spam campain to corporate domains in Colombia
5 days ago by Manuel Humberto Santander Pelaacuteez (6 comments)

Dalexis/CTB-Locker malspam campaign
1 week ago by Brad Duncan (1 comment)

View All Diaries →

Latest Discussions

Dridex seen spoofing referer from social media and search engine sites such as facebook, twitter,google, msn, bing
created 6 days ago by Mostropi (1 reply)

No patch for remote code-execution bug in D-Link and Trendnet routers
created 1 week ago by Brad Duncan (0 replies)

Need help with Framing and masking
created 1 week ago by Anonymous (0 replies)

Packet numbers different in various Dshield reports
created 2 weeks ago by Telserv (1 reply)

Disruption of Simda botnet
created 3 weeks ago by Brad Duncan (0 replies)

View All Forums →

Latest News

View All News →