Slowly Slowly..Catchy Monkey… Or, How to Catch a Hacker..
January 23, 2011 8 Comments
The small business IT consultant may overlook one or two details day to day that our enterprise level counterparts have teams of people devoted to checking day in day out…
Checking the security log of your clients servers however, should be a task you do not overlook. Ever.
We may employ the use of monitoring software to help us, for example we manage somewhere in the region of 200+ servers for our client base, and with a small team it would not be possible to keep track of, or check, every single log file every single day.
Our current monitoring software is provided by GFI, formerly HoundDog and now part of the GFI MAX offering. I mention this only to set the scene, Friday morning, a hacker check fails at a client site.. not in itself an odd occurrence (hacker check will poll for X amount of failed logons in a given time) today was different.
Some 30,000 failed logons. Hmm I think i better check that out.
As it happens this occurred on a clients Exchange server, which led me astray for a while.
It is quite common to see multiple failed logon attempts on an SMTP server that is public facing (you may see botnets attempt to authenticate to send their spam when a server is not an open relay), most of the time these can be safely ignored, but i do take action for repeated attempts – 30,000 counts as repeated ;o)
So this client has their email delivered directly to the server by smtp, not filtered before arriving at the server, as some do. These services are becoming more popular, like Mail Labs, or Trend Micro’s IMHS which can help to secure a server because you can close your firewall and accept mail connections (smtp, tcp port 25) from only your partners servers.
Not using these services can make things more tricky when facing this type of problem because you can only act after the fact, and potentially that could be too late.
So as i say i receive an email alert about 30,000 failed logon attempts, my immediate thoughts are – SMTP relay attempts. I logon to the server and check the security log, and sure enough it is full of failures. All with predictable enough usernames, Admin, Administrator, Adrian, clearly the start of a long script of potential names.
Immediately i set about trying to ascertain if that attack is still in progress.
Switching to a CMD prompt, i run a NETSTAT –F command, the –F will show me the full FQDN of connected machines, rather than a shortened version. I look for current SMTP connections, and don’t see any that look suspicious, but the log is still filling up.
Let’s try and slow them down at least..
Next i think about Exchange 2007 and it’s ability to help protect from this type of attack. I wonder if Tarpitting is enabled.
Switch to the Exchange shell and i run,
Get-ReceiveConnector |Select name, tarpitinterval
This command will list all of our receive connectors, show the name and their tarpit interval.
The default on Exchange 2007 is that all connectors are set at 5 seconds, more on that here this was obviously not high enough so i wanted to increase it (looking back this could have led me to the actual solution a little quicker but i was a bit blinkered here)
So let’s ramp this up to 15 seconds i said.
Set-ReceiveConnector “Receive Connector Name” -tarpitinterval 00:00:15
Now to test. I set up an Outlook profile to try and relay some email, and hit send a bunch of times.
Hmm, my attempts are not showing up and the log is still filling up. What next?
Perhaps it is not SMTP relay after all i muse, perhaps it is an RDP or OWA attack?
On this server RDP is available by a non default port, not a best practice but something forced upon us in this case (don’t get me started on that)
I try a few quick attempts with false passwords, again, they don’t show up.
Switching to OWA, i try the same thing – no change, i don’t even see my attempts hit the log.
I switch back to my NETSTAT and rerun it.
Something in the back of my mind from the first run leaped forward – FTP!
Luckily i had dumped the output of the first NETSTAT to notepad, and i could see that yes, the same client connected by FTP was still connected.
This company require FTP services, so not wishing to disrupt them, i switched to my FTP Client and tried a few false passwords. Sure enough they showed up in the log – identical to the others.
Bingo.
Stopping the FTP site, i use tracert on the offending IP and also a WHOIS by IP.
Now i know who they are, or at least where they are and i can set about blocking their access.
Switching back to the server I open up the windows firewall properties, and add a new rule to block connections from the identified IP address. I confirm the IP from my NETSTAT window, and confirm that my rule will DENY them access.
I restart the FTP service, and attempt to connect my FTP client. It is successful, i switch back to the security log and i can see that the failures have now stopped.
How to add a new Deny entry to Windows Firewall
Under Windows Firewall, With Advanced Security, Right click on Inbound Rules, click New Rule.
On the new rule page, choose the type of rule you would like to create, Since it is FTP i want to block i choose a port rule. Click Next.
I want to use TCP and specify port 21. Click Next.
I want to Block the connection. Click Next.
I want this to apply to all profiles, Click Next.
Enter a Name for the rule, and if you want to, a Description (it might help others identify why the rule was created)
Click Finish when you’re happy with the naming.
You will now see your rule is top of the list. But wait, if we leave things as they are ALL FTP connections will be denied.. We need to be more specific.
Right click your new rule, and click Properties.
Go to the Scope tab.
Under ‘Remote IP Address ’ Click ‘These IP Addresses’
Click Add. Enter the IP address you would like to block, or alternatively an entire range. (If you find out which ISP an IP Address belongs to you can block their entire IP allocation, this may be useful if your attacker is on a dynamic IP)
Click OK when you’re done, and click OK to confirm.
You will need to monitor the security log to ensure no more attacks take place, but you can be pleased that it will be a great deal harder for this guy to attempt to logon to your services again!
Title (Required) 