StellarTech Blog

I recently had a problem setting up OpenVPN for a residential customer trying to connect to his office network. Everything looked great and should have been working without issue. The TAP adapter would grab the expected /30 bit subnet without issue, pushed settings were applied, and the VPN logs had nothing but good report. Unfortunately something sinister was indeed going on.

Taking a quick look in WireShark I noticed that the UDP packets were being dropped. This baffled me as I had already disabled all firewalls on the machine in order to trouble shoot. Including the packaged pinche basura firewall that comes with the McAfee Internet Security Suite bloatware jamboree.

After uninstalling McAfee all problems with connecting vanished, drives were mapped, and databases were connected to.

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.

One of my favorite and most often used services is openSSH. While openSSH is generally known as being secure it never hurts to tweak a few extra settings.

Here are a few changes I generally do to help ensure openSSH is in tip top shape.

1. Use a strong password. My preference is to use randomly generated passwords of 20 plus alphanumeric characters with their own special blend of special characters. That should thwart most password crackers.
2. Change the port sshd listens on. Using port 22 hangs a sign out on your server saying I use sshd. While changing the port won’t stop anyone from figuring out you are running the service it will make them work harder. You can do this by changing the following in /etc/ssh/sshd_config:

   Port 1234

3. Get rid of root logins. There is absolutely no reason to log in as root when you can use ’sudo’ or ’su’ to elevate a wheel user to root privileges. To set this change the following line in /etc/ssh/sshd_config:

   PermitRootLogin no

4. Disable the antiquated Protocol 1 by changing to the Protocol line in /etc/ssh/sshd_config from ‘Protocol 1,2′ to the following:

   Protocol 2

5. Another option would be to block lame dictionary attacks with denyhosts or ConfigServer Firewall/Login Failure Dameon. ConfigServer firewall has the added benefit of adding a friendly interface to help managing IPtables. Blocking login failures can sometimes be overkill if you are already have other restrictions in place like using keys only or using the AllowUsers directive in your /etc/ssh/sshd_config
6. If you prefer to use keys instead of password the following changes to /etc/ssh/sshd_config are a good start in tightening things up. If you are going to have any accounts that use password authentication you’ll be locked out of the server making these changes. So only do so if you are using keys to log in:
   
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no

7. If you prefer to leave password authentication on then the AllowUser directive is for you. Below are a few examples this directive in play.
   
AllowUsers iizwheel@*
AllowUsers fjones@*
AllowUsers *@123.456.7.8
AllowUsers *@222.333.444.*


If anyone has further suggestions on securing openSSH please let me know.

Later I plan on doing posts on creating and using ssh keys, setting up DenyHosts, and setting up ConfigServer Firewall in future.

Having intermittent problems hitting your favorite UNC path over openvpn? Does your Domain Controller turn it’s back on you randomly over the tunnel asking for authentication as if it no longer knows who you are?

If you have been plagued by any of the above anomalies you are not alone! Unfortunately hair loss products, Viagra, those vitamins you bought from GNC, or any other magical elixir of some unknown origin will not help.


You may even find yourself going down the same foolhardy path as yours truly. Thinking that editing %SystemRoot%\System32\Drivers\etc\hosts with the FQDN and NetBIOS names of all your favorite hosts will suffice only to be greeted with the grotesqueness of an authentication prompt repeatedly prompting you for information it should already know until you become mad. Finding yourself breaking out those emergency cyanide pills and washing them down with a flask of hemlock.

Wait friend! No need for such drastic measures yet. Simply edit your servers config file to include the following:
push "dhcp-option DNS ip.of.dc"

Make sure your client config allows pushing by having the following cleverly named setting of:
pull

Now once you’ve restarted your server and client you should see your DC IP set as the default name server when typing ‘nslookup’ at the command line.

Yes a simply fix but still worthy enough to stop any self mutilation.