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.

Recently I started to have issues with my snort rules not wanting to update and the snort service not wanting to stay running on my pfsense box. Taking a quick look at the forums I found several other with this problem and many different solutions the most prominent being to edit /etc/inc/system.inc. This fix seems to be hit and miss. Personally I did not want to edit unless I just needed to so I took the following approach.

Using the web UI it appears that snort would hang for a while before it would error out all together.

My first approach was to look into the logs. After finding nothing useful there I secure shelled into the machine and decided to launch snort from the command line to pinpoint exactly what was causing the problem.

Here is the command I used to launch snort:
snort -c /usr/local/etc/snort/snort.conf -l /var/log/snort -i ng0 -A full

Snort died instantly because it could not open /usr/local/etc/snort/rules/attack-responses.rules which means either the directory rules was missing or there might be a permissions problem. After running “ls -al /usr/local/etc/snort | grep rules” I found out that the rules directory was indeed missing. I recreated, chmod 755, and reran the snort update process. Everything worked afterwards.

Have you ever setup a cool /etc/motd on your Ubuntu installation just to see it vanish after a reboot? We don’t need Scooby and the gang to solve this mystery since it’s obviously a start-up script.

Here some cli medicine to make things all better:
touch /etc/motd.static && rm -f /etc/motd; ln -s /etc/motd.static /etc/motd

By default /etc/motd is symlinked to /var/run/motd which is rebuilt by /etc/init.d/bootmisc.sh every time you reboot.

It is fairly common knowledge among IT professionals that the Windows command line is fairly weak. While PowerShell looks promising it will not be installed by default until Windows Server 08 R2.

It’s alright though since the CLI in Windows isn’t as shabby as it is obscure. Take for example findstr and find. While not as powerful as it’s nix big brother ‘grep’, findstr does a fairly good job and even support regexp. Here are a few handy examples of both commands in action:

finding possible ddos attack to port 80:
netstat -ano | sort /+33 | find ":80 " | more