StellarTech Blog

So you get the call from a client that their MS Windows server isn’t responding and it’s been randomly crashing as of late. If you are not seeing anything in eventvwr.msc your first instinct might be to grab a few sticks of RAM and a couple of diagnostic disks. Wait! Don’t forget to check for a DDoS/DoS attack. I’ve seen many cases where customers and clients have missed diagnosed a denial of service attack for a hardware problem when confirmation is just a netstat command away.

If you don’t have any network graphs available and surmising that the machine is available either through IP-over-KVM or you have physical access you can run the following command:
C:\> netstat -an | sort /+33

This will sort connections by the connecting IP. If you see a hundreds of concurrent connections from one IP and and the connections statuses are all syn_received, fin_wait, or time_wait then you probably have a denial of service going on.

As you can see MSSQL port 1433 is getting hammered. It’s always wise to firewall off ports like 1433 so that they are not exposed to the world.

Another fun way to verify a DoS attack, assuming you have a monitor/crash cart on the server, is to simple unplug the network cable. If the server instantly recovers and becomes responsive you’ve found the problem. Now it’s time to use you’re firewall kung-fu and deny the IP from further access.

Below are a few other helpful information gathering commands.

Find out what IPs are sending syn_received flags to your server on http 80. Any flag can go here.
C:\> netstat -an | findstr /i ":80.*syn_received$"

Get a count of how many times 111.222.333.444 is connecting to smtp 25.
C:\> netstat -an | find ":25 " | find /c "111.222.333.444"

It never hurts to do a little prevention by firewalling off any service that doesn’t need to touch the Internet and harden that TCP/IP stack.