As botnets and other automated tools are hammering at websites trying to exploit SQL injection vulnerabilities, site operators are trying hard at defending their websites.  ASProx and other botnets were hitting hard at the ASP + MS SQL platform, millions of websites fell victims to the SQL injection vulnerabilities already. Although there has been a decline of wild SQL scanning by ASPRox type of botnet, we are still not in the clear yet. The unauthenticated portion of some sites might be secure, but the authenticated portion might be totally vulnerable. Since most scans only target what can be seen by Googlebots, there are still tons of web pages out there vulnerable waiting for exploitation.

If you have tons of vulnerabilities on your site, you likely will take some time to fix all of it as fixing code isn't the easiest and fastest thing to be done. A short term remediation to SQL injection can be web application firewall. Web application firewall (WAF)  is similar to a network firewall except it also inspect the application layer information, such as cookies, form fields and HTTP headers. With Microsoft IIS as web server, one of the quickest and easiest WAF solution maybe Microsoft's Urlscan, it is an addon to IIS5 and built-in for later versions of IIS. Urlscan runs as an ISAPI filter, so it can be easily deployed and removed. Since version 3.0 of Urlscan, there are decent level of coverage on SQL Injection capabilities. The biggest complaint is that Urlscan do not inspect HTTP request body (POST data), so it could be missing attacks that are submitted using POST.

I have recently played with another free WAF product on IIS called Webknight and found it to be easy to config and full of nice features. The default configuration file is reasonably tight. In most cases, you would probably want to loosen things up so Webknight won't break your site with false positives. It inspects SQL injection in header, cookies, URL and in POST data. The detection is based on hitting two of the preset SQL keywords. For most cases, this generally works well. It may render false positives with some more complex textarea field that expect various text. Overall, Webknight is a good WAF that can fulfill basic protection needs.

Remember that WAF products are meant to be an extra layer of defense and/or a very short term mitigation until you fix up all the code. For mitigation, you are really just buying yourself more time before a compromise happens. While WAF do a good job at making the site harder to compromise, they have various limitation, the most effective long term mitigation is still fixing up the code.

-------
Jason Lam, author of SANS web app courses - 319, 422, 538

The incident handling cheat sheets in an earlier diary applied to many types of security incidents. Some incidents, such as DDoS attacks, can benefit from specialized guidelines. As suggested by one of our readers, we'd like to create a cheat sheet that helps organizations during a DDoS attack. We would love for you to contribute.

If you have handled a DDoS attack, send us your advice on dealing with such incidents faster and more effectively. The tips should assume that the organization is reactive, and has not had much time to prepare for the incident in advance. We're looking for suggestions arelated to all stages of the DDoS incident, including detection, analysis, and mitigation.

Update: Here's my attempt at organizing the tips we received so far. (Thanks, Chris, Daniel, Donald and Peter!) It's still a work in progress:

Prepare

These steps can greatly assist if your attacked. If you haven't done this and you get attacked you will spend the first few hours trying to get some of these steps done.

• Contact your ISP to learn what DDoS mitigation support they offer for free and for a fee.
• Create a whitelist of the source IPs you must allow if you need to prioritize traffic during an attack. (Include your big customers or critical partners, etc.)
• Confirm DNS Time-to-Live (TTL) settings for the systems that might be attacked. Lower the TTLs, if necessary, to facilitate DNS redirection if the original system IPs get attacked.
• Make sure you have contacts for your ISP, IDS team, firewall team, DNS provider, 3rd party security teams etc...
• Document your network information, including IP addresses and circuit IDs. Prepare an asset inventory and a topology diagram.
• Collaborate with your BCP/DR planning team, to understand their perspective on effects of a DDoS event.

Analyze

Detect the incident and assess its scope. Which infrastructure components are affected, and what is the logical flow of the attack? Understand the nature of the attack.

• Review the load status of servers, routers, firewalls, and other affected infrastructure components.
• If possible, use a network sniffer (e.g. tcpdump, ntop) to review the traffic flowing to the affected infrastructure.
• Contact your ISP and internal teams to learn about their visibility into the attack, and to ask for help.
• Find out whether the company received a ransom demand as a precursor to the attack.
• If possible, create a NIDS signature to focus to differentiate between benign and malicious traffic.
• Get the your company's executive and legal teams involved. Consider involving law enforcement.
• Identify what aspects of the offending traffic differentiate it from benign traffic (e.g., specific source IPs, destination ports, URIs, TCP flags, etc.)

Mitigate

DDoS attacks often take the form of flooding the network with unwanted traffic, in which case it will be very difficult to defend against the attack without specialized equipment or your ISP's help. There are steps you can take to mitigate the effect of some DDoS attacks, though.

• Attempt to throttle or block the offending traffic as close to the network's "cloud" as possible using a router, firewall, load balancer, web server configuration, etc.
• If possible, switch using DNS or another mechanism to an alternate site with more network or computing resources. Blackhole the traffic targeting the original IPs.
• If the bottle neck is on the server side, tune the systems' TCP/IP parameters to improve efficiency.
• If the bottle neck is particular features of an application, temporarily disable those features.
• If possible, add servers or network bandwidth to handle the load. (This is an arms race, though.)
• If possible, route traffic through a traffic-scrubbing service or product via DNS or routing changes.

Additional Tips

• In an incident, there's a tendency for too many people getting involved in fighting the fire. (Too many cooks in the kitchen.) The more people accessing systems the harder it is to gather data.
• Make changes one at a time, don't be in the position where the issue gets resolved, but two separate changes occurred at the same time, so you don't know what fixed it.
• Humans get tired! If the incident goes on for a lengthy period consider how you will continue to operate and fight the incident the following day.
• You can never have too much data, logs are king when analyzing an incident.

What do you think? Any corrections or additions? Pointers to useful resources? Let us know.

-- Lenny

Lenny Zeltser
Security Consulting - SAVVIS, Inc.

Lenny teaches a SANS course on analyzing malware.

The oldfashioned way to launch a network DDoS attack involved building one's own bot network that would flood the victim with unwanted traffic. However, the illicit marketplace for such services has matured, allowing a person to purchase DDoS services on demand, effectively renting a botnet for the event.

Here's one ad for such services. It's in Russian; the translation follows.

The ad scrolls through several messages, including:

"Will eliminate competition: high-quality, reliable, anonymous."
"Flooding of stationary and mobile phones."
"Pleasant prices: 24-hours start at $80. Regular clients receive significant discounts."
"Complete paralysis of your competitor/foe."

Perhaps the most interesting aspect of the advertised service is the offer to flood the victim's phones. We often think of network-based DDoS attacks, but phone-based DDoS could be as devastating. If the service can, indeed, target stationary (landline) phones, then we're not just talking about SMS-based floods. These would probably be actual phone calls, probably initiated using VoIP, maybe via stolen Skype accounts with dial-out credits. Anyone knows more about such phone attacks?

-- Lenny

Lenny Zeltser
Security Consulting - SAVVIS, Inc.

Lenny teaches a SANS course on analyzing malware.