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:

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