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} ->

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

Keywords: false positives ids
3 comment(s)


One of my favorites was a snort rule looking for suspect UserAgent strings in an HTTP session. If memory serves it was looking for any UserAgent containing the word "rogue" which might've seemed like a good idea sometime but now triggers on a tool called RogueKiller which is apparently some anti-malware tool. Whoops.

And it seems there's a bunch of snort rules that cause false positives based on UserAgents - IM clients or other tools that use once legit UserAgent strings that are now flagged as "ancient/decrepit browser in desperate need of upgrading", or browsers on android devices setup to pretend to be iOS for dopey websites that work well on iPhones but not android, but which cause snort alerts because it's masquerading as an old, insecure version of the iPhone browser.

My favorite is snort's "Shellcode" which gets applied to a quarter of downloads from Akamai and a few from AV updates.
An oldie but goldie are complaints about "attacks on port 53/UDP". These are not caused by DNS amplification attacks, but rather the answers to queries the user's systems sent in the first place.

Another frequent problem here in Germany is the P2P afterglow. Most broadband lines are DSL where the connection is torn down by the provider once every 24 hours. The reconnection will result in a new public IP being assigned, and if the previous owner of the IP was doing P2P, there will be a large amount of connection attempts from systems that had P2P connection to the old user. And this may lead to legal issues...

Diary Archives