SQL Slammer Clean-up: Picking up the Phone

Published: 2010-10-19
Last Updated: 2010-10-19 17:59:48 UTC
by Kevin Liston (Version: 1)
5 comment(s)

Last time, we took the reporting up a level (http://isc.sans.edu/diary.html?storyid=9712) this time we need to take it up a notch. We’ve been using scripts and email to limit the impact of abuse reporting on your time, and you’ve seen the results: it’s not having much of an effect on the number of attacks hitting your perimeter. This is not unexpected, since the normal abuse-reporting process hasn’t cleaned these systems up already. It’s time to roll up our sleeves and pick up the phone.

I know it is scary to pick up the phone and talk to human beings-- I don’t like it myself. If we were people-people, most of us wouldn’t be into computers.

I’d like to split you up into two groups: people who are reporting attacks on your perimeter, and people who are carrying traffic from infected machines (in other words, the ISPs.)

If you’re responding to attacks I’d like you to identify the attacker that’s closest to you. Most of the IPs hitting my perimeter are China and the US, so in my case, I’d pick a US source. Look for IPs that have businesses or organizations identified in the contact information instead of large ISPs (we’ll deal with them below.) Next, do a little detective work, and research the contact information for that business. Give them a call, and ask for the computer or security person. Introduce yourself and the program. Try not to scare them too much; you’re trying to build community here. Be helpful, because they really need it.

For the ISPs, I understand the common-carrier issue, but that shouldn’t keep you from informing your customer that they have a pretty significant security issue. I’m not asking that you roll out a full-blow user-notification process. With the volumes that I’m seeing this is definitely a one-off process. You’re probably sitting in a pretty good position to not only contact the affected user, but also know their IT staff contacts already. Give them a friendly call and help them out. You might even get more business out of it.

Keep up the effort.

Keywords: slammercleanup
5 comment(s)


Another thing you can to do combat SQL Slammer is to TCP tarpit any MSSQL traffic at your boundary:


I do this on my hosted server, but I haven't seen any MSSQL traffic in quite a while so I was surprised to hear that Slammer was still active. Perhaps my hosting provider is blocking it at their boundary...

What I do see a lot of is RDP scanning:

MSSQL: 0 host(s), 0 connection(s)
23/tcp: 1 host(s), 1 connection(s)
25/tcp: 1 host(s), 4 connection(s)
2967/tcp: 2 host(s), 2 connection(s)
3389/tcp: 7 host(s), 19 connection(s)
4899/tcp: 3 host(s), 4 connection(s)
5900/tcp: 1 host(s), 1 connection(s)
8080/tcp: 1 host(s), 1 connection(s)

I also tarpit repeat spammers and PHP vulnerability scanners.
John: MSSQL is UDP.
Oh? http://msdn.microsoft.com/en-us/library/ms177440.aspx

I suspect you're thinking of the MSSQL Browser service: http://msdn.microsoft.com/en-us/library/ms181087.aspx

However, thanks for saying that; it prompted me to review my tarpit configs and I just noticed that at some point in the past I unintentionally dropped port 1433 from my tarpit list (d'oh!). I've added it back, so we'll see if a bunch of slammers get stuck now...
Well, a few are poking around:

MSSQL: 3 host(s), 42 connection(s)
23/tcp: 1 host(s), 1 connection(s)
2967/tcp: 3 host(s), 6 connection(s)
3389/tcp: 6 host(s), 22 connection(s)
4899/tcp: 4 host(s), 4 connection(s)
7212/tcp: 1 host(s), 3 connection(s)
8080/tcp: 2 host(s), 2 connection(s)
Umm... holy cow!

MSSQL: 5 host(s), 2653 connection(s)
23/tcp: 1 host(s), 1 connection(s)
1080/tcp: 1 host(s), 1 connection(s)
2967/tcp: 2 host(s), 5 connection(s)
3389/tcp: 3 host(s), 10 connection(s)
8081/tcp: 1 host(s), 5 connection(s)

Diary Archives