Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - When an Attack isn't an Attack InfoSec Handlers Diary Blog


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

When an Attack isn't an Attack

Published: 2014-02-03
Last Updated: 2014-02-03 13:47:31 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

I think I have seen it referred to as the "X-Files Effect". You just installed a new firewall or IDS, it is still all new and shiny and the logs are still fresh and interesting. Looking at your logs, it starts dawning at you: "They are out there to get me!". While many of these attacks are attacks, there are also quite a few false positives that typically show up in your logs. At this point, lets quickly define false positives: These are either benign traffic that is mistaken for an attack, or an attack, that just doesn't affect you (Famous SQL Slammer attack against a Linux host).

Lets look at a few examples we have come across lately:

 a.b.c.d is constantly sending DoS ACK replies to my network, I would like to report this abuse and learn how to report future abuse more easily in the future because this kind of thing happens all the time. 

Thank you for taking the time to read this. Below is the log for the incident.

[DoS Attack: ACK Scan] from source: a.b.c.d, port 80, Thursday, January 30,2014 14:10:02

This is an e-mail we receive about once a month. In most cases the source is a busy web server, sometimes a CDN (Content Delivery Network) like Akamai. The reason for these alerts is that most firewalls will consider a connection closed if no activity has been seen in a while. However, in this case, the connection is still open and the web server will eventually send another data packet that is then rejected. This is NOT the result of a SYN flood attack (more about that later) and I am not sure why this particular device labels it a DoS attack.

If someone is spoofing your IP address, and using it to launch a DoS attack, then you should see SYN ACK packets, not ACK packets. For example a slightly abbreviated iptables log:

SRC=a.b.c.d DST=v.x.y.z LEN=60 TOS=0x00 PREC=0x20 TTL=49 ID=0 DF PROTO=TCP SPT=80 DPT=62547 WINDOW=2896 RES=0x00 ACK SYN URGP=0

Typical for these logs: The source is a well known server port (80). Could also be 443, 6667 or other ports. The target port is a "random" ephemeral port.

But it isn't just firewalls. IDSs of course love to annoy us with false positives to beg us to properly configure them. But we don't because an IDS with all rules it possibly offers enabled is SO much safer! (sarcasm if you didn't spot it...)

Snort for example has a very neat feature, the "sensitive data" plugin. It can spot sensitive data like e-mail addresses or social security numbers being sent in the clear. Here is an example alert:

[138:5:1] SENSITIVE-DATA Email Addresses [Classification: Sensitive Data] [Priority: 2] {TCP} a.b.c.d:80 -> v.x.y.z:63715

An e-mail address was received from port 80. So in other words: you accessed a web page that contained an e-mail address. Probably not what I would consider a "leak", in particular if this web server was located outside of my control. I have seen this signature trigger a lot on FTP and of course SMTP traffic. Probably still a good reminder to not sure a legacy protocol like clear text ftp.

But lets look at a more tricky one:

Reset outside window [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 23.202.88.93:80 -> 70.91.145.11:59867

The traffic that triggered this alert:

a.80 > b59782: Flags [P.], seq 1886684918:1886685156, ack 659663868, win 7240, options [nop,nop,TS val 1132895224 ecr 605850989], length 238
a.80 > b.59782: Flags [F.], seq 1886685156, ack 659663869, win 7240, options [nop,nop,TS val 1132895245 ecr 605851009], length 0
a.80 > b.59782: Flags [R], seq 1886685157, win 0, length 0
 
As you can tell, the sequence number for the reset packet is actually right on. This was again more of a timed out connection. In this case, the web server was Akamai and they appear to like to send an extra reset, likely to make sure the connection is down and save them some resources. The connection itself was triggered by an AV tool's "update check".
 
Which gets me to another favorite firewall false-positive:
 
SRC=v.x.y.z DST=a.b.c.d LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=49424 DF PROTO=TCP SPT=80 DPT=52968 WINDOW=14600 RES=0x00 ACK FIN URGP=0
 
A "FIN-ACK" being blocked coming in this case from my web server to a (valid) client. iptables loves to block the final fin-ack as it considered the connection already closed.
 
Any good false positives you keep running into?

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: false positives ids
3 comment(s)
Diary Archives