When an Attack isn't an Attack
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
Network Monitoring and Threat Detection In-Depth | Singapore | Nov 18th - Nov 23rd 2024 |
Comments
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.
Phooey.
Anonymous
Feb 3rd 2014
1 decade ago
Anonymous
Feb 4th 2014
1 decade ago
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...
Anonymous
Feb 4th 2014
1 decade ago