Newest KB Articles

chkdsk

Sat, 21 Apr 2012 04:43:10 GMT

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

TCP and UDP Ports required to access vCenter Server, ESX hosts, and other network components

Mon, 06 Feb 2012 02:41:10 GMT

http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1012382

Increase in Hacker attempts on Windows / Exchange Servers – One Way to Slow Them Down!

Mon, 16 Jan 2012 12:01:49 GMT

Posted on December 1, 2010 by Alan Hardisty

In an earlier post I advised about an increase in hacking attempts that I had been seeing on Experts Exchange and also on the servers that we support for our customers.

My Earlier Post:
http://alanhardisty.wordpress.com/2010/09/28/increase-in-frequency-of-security-alerts-on-servers-from-hackers-trying-brute-force-password-programs/

Having recently been alerted to yet another round of sustained attacks on a couple of servers we receive daily alerts for, I started to dig a little deeper and came up with an interesting thought. A lot of the hackers seems to be passing random usernames such as 1234 / 123 / Claire etc and because these users don’t exist on any of our servers, the Account Lockout Policy does not kick in after x many invalid login attempts. As a result – they just keep on trying in vain!

So – what to do?

Well – it seems that lots of the hackers seem to be trying to use SMTP to attempt to hack a username / password, so I got thinking. On the majority of servers, the SMTP Virtual Server / Receive Connector has Anonymous Authentication / Basic Authentication / Integrated Windows Authentication enabled.

Anonymous Authentication is required if you want to receive emails from other servers around the world, so disabling that is not an option because you would not receive any email at all!

Basic Authentication is required if you want users to send mail with Usernames / Passwords but don’t want to send them securely (why would you?)

Integrated Windows Authentication is required if you want your domain users to to be able to use SMTP and supply their credentials from their Windows accounts to verify access to the server.

As the vast majority of our Server we manage have RPC over HTTPS / Outlook Anywhere configured on them – the Basic / Integrated Windows Authentication is not required in the slightest, so I disabled them both on the servers that were receiving unwanted attention.

Two days later – no more hacker attempts are being reported / logged in the Security Event Logs!

So – if you want a more secure server and don’t have users with SMTP / POP3 accounts sending via your own Exchange Server and have not already disabled Basic & Integrated Windows Authentication on your SMTP Virtual Server / Receive Connector – what are you waiting for?

One less point of attack for hackers is good news in my books.

Increase in frequency of security alerts on servers from hackers trying brute force password programs

Mon, 16 Jan 2012 12:01:10 GMT

Over the past few months I have seen a noticeable increase in the number of servers that I look after that have alerts raised due to large number of Hacker Attempts trying to pass Usernames and Passwords to the server in the vague hope of eventually finding a combination that actually works.

Once a combination of Username and Password is successfully found, the server will invariably be used to send out vast amounts of spam, which will ultimately result in the innocent victim having problems sending mail because the fixed IP Address that they have will be listed on one or more Blacklist websites.

One such server that I was called to that had suffered from such an attack had been sent about 380,000 spam emails to send out in a very short space of time. Identifying the problem account and cleaning up the mess caused can be a tricky process, but with the right information to hand, an understanding of why this has happened and the optional use of software such as Vamsoft ORF which has excellent logging capabilities, the problem can quickly and easily be identified, the account being used either disabled or the password changed and the SMTP service restarted.

What can you do to prevent such an attack from hitting your server?

Well, there are several preventative measures that you can take to reduce the risk:

1. Configure Passwords to be complex (to include Uppercase letters, Lowercase letters, Numbers and Special Characters e.g., !”£$%^&*()_+}{][#’@~?></.,)
2. Make sure passwords have a minimum length – the longer the better but at least 7 or 8 characters as a minimum.
3. Force passwords to be changed regularly (at least every 30 – 60 days)
4. Enable account lockouts after a low number of invalid login attempts (between 3 and 5 invalid attempts). Make sure the accounts are locked out for approx 15 minutes to slow down the hacker.
5. Make sure your firewall is configured to only allow the protocols that you need allowed through and close off any others that are not needed.
6. Regularly review your firewall settings to verify the open ports are needed.
7. Make sure your firewall logs all access to your systems so that you can track down the source IP Address that requests are coming from. The logs will be invaluable in determining the source of multiple login attempts.
8. When the firewall logs get full, make sure you have them emailed to you and keep them in a safe place.
9. Setup alerts for the Security Log and make sure you get notified of multiple invalid login attempts. The sooner you act, the less chance the hackers have to probe your security, usernames and passwords.
10. Make sure you don't have an account called Administrator on your server that is active. If you do, create a new Server Admin account, copying the Administrator account and then disable the Administrator account – it is an obvious target account and hackers will try this account almost every time.
11. Regularly review your user accounts and make sure you either disable or delete ones that are no longer needed.
12. Make sue that all your server user accounts are easily located in Active Directory, ideally in a single OU, so that you don't have to hunt around for accounts and thus can easily overlook and account that is located in an obscure OU that you never look at.

If you currently don't implement any form of password security, you may meet stiff resistance from staff to enforcing the above changes to passwords, but the first time you are hacked and suffer problems sending mail as a result of being hacked in this way, your users might actually understand why these settings are needed.

If you implement some or all of the above, you should limit the possibilites of being hacked and used as a spammers relay to spew forth their rubbish. If you don't – then you can't say I didn't warn you : )

Why are my outbound queues filling up with mail I didn't send

Mon, 16 Jan 2012 11:59:10 GMT

If your emails are building up on your Exchange 2003 server and you don’t recognise any of the destination address then you have got a problem and need to resolve it. To work out what your problem is, please double-click into one of the unknown domain name queues, then click on the Find Now button and then double-click into one of the messages that are returned.

Look at the sender of the message. If the sender is postmaster@yourdomain.com, you are suffering from a Non Delivery Attack. If the sender is a random user not in your organisation, then you are suffering from an Authenticated Relay attack.

Non Delivery Attack:

To prevent a Non-Delivery Attack, please turn on Recipient Filtering to reject recipients not in your organisation:

http://www.msexchange.org/tutorials/Sender-Recipient-Filtering.html

The reason for this is that you are currently accepting messages for anyone at your company, even made up names. If the recipient does not exist, your server is sending a Non-Delivery Report back to the sending email address and as spammers usually make up the sender address, the email message will not be able to go anywhere as the domain is invalid. Some of the email addresses that spammers use will be valid email addresses and thus some Non-Delivery report mail will get sent out to people who did not send an email to you in the first place and they will potentially report you as a spammer. Mail of this type is known as Backscatter and this can get you Blacklisted. Please see http://en.wikipedia.org/wiki/Backscatter_(e-mail) for more details.

If you also turn on Recipient Filtering, your server will reject recipients that are not setup on your server and the sending mail server will be responsible for sending a Non Delivery Report, not your server, thus shifting the problem back onto the spammer - http://www.msexchange.org/tutorials/Sender-Recipient-Filtering.html

Another tool that you can use to slow down spammers is to implement something called Tarpitting which forces a delay into the mail-flow process for anyone sending mail to an invalid address on your server. This means that anyone targetting your server will spend lots of time waiting for a response from your server, slowing them down - http://support.microsoft.com/kb/842851

Authenticated Relay Attack:

If the sender is not postmaster@yourdomain.com and is some random address, please Open Exchange System Manager and expand Servers> Right-click the Server Name and choose Properties> Select the Diagnostics Logging tab.

In the Services window, select MSExchangeTransport, and in the Categories window increase the logging level for Authentication to maximum. Once you have done this, keep an eye on your Application Event Logs looking for event ID 1708 and it should soon become apparent which account is being abused. Once you know which user account is being abused, change the password for that account and then stop and restart the Simple Mail Transfer Protocol Service and then cleanup your queues (The Administrator account is the usual target for spammers). Here is a good document to help you cleanup – http://www.amset.info/exchange/spam-cleanup.asp

Once you have cleaned up – please return the logging level back to None

User Comment

Author: mboppe Date: 04/08/2010 - 12:10PM EST

Great Article

User Comment

Author: mboppe Date: 04/08/2010 - 12:16PM EST

Is this applicable to exchange 2007 as well.

Author Comment

Author: alanhardisty Date: 04/08/2010 - 10:32PM EST

There are parts that are relevant to Exchange 2007, but not all of it.

The sender details (postmaster or random) and thus the NDR spam / Open or Authenticated Relay issues are relevant to all Exchange versions, but the solution for 2007 will be different.

User Comment

Author: SeanNij Date: 08/16/2010 - 04:19PM EST

Great!!!

User Comment

Author: Bran-Damage Date: 08/17/2010 - 12:20PM EST

Great article! Any reason why their would be nothing in the Event Viewer application log after doing the steps above for Authenticated Relay Attack?

Author Comment

Author: alanhardisty Date: 08/17/2010 - 06:17PM EST

@Bran-Damage - I presume you are referring to the Security Event Log?

If that is the case, then it may not be an Authenticated Relay Attack. You may have a virus on your network abusing your Exchange server. I have seen this at a customer's site before.

I would install a 30-day trial of Vamsoft ORF (in log mode only) and monitor the logs to see what is happening. That should help to narrow down an account if you are an Authenticated Realy, but if not, then check the Blacklists and see why you are listed. From there you can formulate a plan to stop the attack.

www.mxtoolbox.com/blacklists.aspx

Also - if you found the article useful - please don't forget to vote for it : )

User Comment

Author: ficose Date: 12/07/2010 - 11:18AM EST

Wish I had this article earlier. Now the next customer that gets hacked won't keep me up all night clearing the queuesso to keep the server up.

Author Comment

Author: alanhardisty Date: 12/07/2010 - 11:25AM EST

If you want to clear the queues very quickly - use aqadmcli.exe:

ftp://ftp.microsoft.com/pss/Tools/Exchange%20Support%20Tools/Aqadmcli/aqadmcli.exe

User Comment

Author: samiam41 Date: 04/27/2011 - 04:47AM EST

Had a hard time listening to your article over your awesomeness. Great work! I will save this article for the next Exchange battle I enter. Thanks!

Author Comment

Author: alanhardisty Date: 04/27/2011 - 05:56AM EST

Sorry! I'll try to crank up the article volume for you ;)

Alan

User Comment

Author: ficose Date: 04/29/2011 - 11:35AM EST

I have found the quickest way to delete the smtp queue is to create a batch file on the desktop with the following contents

===============================================
echo
echo delete the queue emails
net stop smtpsvc
d: <<<<<<< change to suite
cd "\program files"
cd exchsrvr\mailroot\vsi 1\queue
rem pause
del *.* <c:\yes.txt <<<<< need a file called yes.txt that contains y<CR> in root directory of C:

net start smtpsvc
rem pause
==========================================================

this is assuming the queue in on the D: drive. Change to suite. Also you need to create a file c:\yes.txt which contains y<CR> only.
If there are a lot of files in the queue the service may not stop. in this case bring up taskmgr and kill inetinfo.exe. Then run the patch file.

Author Comment

Author: alanhardisty Date: 05/03/2011 - 07:46AM EST

The problem with your option is that it may also delete valid emails. With the aqadmcli.exe tool, it allows you to quickly zap only the bogus emails and not the genuine ones.

User Comment

Author: andersonaraujo Date: 07/08/2011 - 04:06AM EST

This post is very useful and clear. It helped me a lot. Good job Alan Hardisty!!!

Author Comment

Author: alanhardisty Date: 07/08/2011 - 04:31AM EST

Excellent news - thanks for posting and I hope you keep clean.

Check out my blogs about things to do to prevent this from happening again:

http://alanhardisty.wordpress.com/2010/09/28/increase-in-frequency-of-security-alerts-on-servers-from-hackers-trying-brute-force-password-programs/

and

http://alanhardisty.wordpress.com/2010/12/01/increase-in-hacker-attempts-on-windows-exchange-servers-one-way-to-slow-them-down/

Alan