Snort is a registered trademark of Sourcefire, Inc
Sourcefire has been busy as ever keeping their second-to-none Snort® IDS/IPS system at the forefront of network security technology. Yesterday they released an update to the 2.8 family of Snort®, bringing it to version 2.8.6.1. It brings some fixes to the installer package, fixing some issues with detecting false-positives in pattern matching & FTP string format verification, and incorrect handling of empty FTP response codes to data transfer commands commands.
Snort® 2.9 has officially gone Beta. 2.9 includes a myriad of new features such as a robust IPS mode for inline deployments, a new common API for all active response, a new response module that is backward-compatible with resp and resp2 syntax, a new preprocessor for inline deployments to interpret packets the same way a host would, and a new Data Acquisition API that supports multiple packet access methods for better & easier integration with existing infrastructure, updated HTTP Inspect, updated & more robust SMTP preprocessor, the ability to test drop rules for inline mode before implementation, and greatly improved overall IPv6 support. Also new is integration with Intel’s Quick Assist technology.
A new tool exploiting a quite-clever and very tricky to fix issue with ALL versions of Apache Web Server and Squid as well has been published into the wild yesterday. There’s no paper outlining the exact exploit, but there doesn’t really need to be one. As described by Bojan Zdrnja of SANS ISC, the DoS is carried out basically by telling the server to “hold on, I’m sending more header data,” yet never does:
…the server will open the connection and wait for the complete header to be received. However, the client (the DoS tool) will not send it and will instead keep sending bogus header lines which will keep the connection allocated.
The initial part of the HTTP request is completely legitimate:GET / HTTP/1.1\r\n
Host: host\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n
Content-Length: 42\r\n
After sending this the client waits for certain time – notice that it is missing one CRLF to finish the header which is otherwise completely legitimate. The bogus header line the tools sends is currently:X-a: b\r\n
Which obviously doesn’t mean anything to the server so it keeps waiting for the rest of the header to arrive
Essentially the attacker sends a partial legitimate browser UA string, albeit incomplete with intentions to send the rest of the data to complete the string, yet never does. This in turn holds the session open on the server end, quickly maxing the server’s connection table waiting for “clients” to complete the request.
This attack requires a very small amount of bandwidth to bring a server to its knees. There is no known workaround or patch yet, but can be stopped by including the signature for this type of attack in your IDS (if you have one in front of the web server.)
I recall Check Point VPN-1 R65 introducing a DoS protection technique that could possibly reduce the impact of such type of DoS attack. To keep the firewall’s connections table from becoming saturated in the event of a Denial-of-Service attack, a three-way session verification would take place. When a connection request it is initiated, the firewall would send back an acknowledgment to go ahead and start sending traffic (if the specific connection was allowed in the rulebase), but only keep the connection record in memory, not committing it to the actual connections table on the firewall. If no traffic was returned by the requestor, then the connection would be ignored and purged from memory. This kept the connections table clean of any “dummy” connections and thus would not become saturated and cause traffic-flow to come to a grinding halt. Maybe the fix could be to do something on an HTTP session scale with Apache.
