SEMblog

Last year I wrote about how I was caught out with detecting Vista in login scripts (http://blog.sembee.co.uk/archive/2007/01/06/31.aspx).

Following the release of Service Pack 1 for Windows Vista, I was caught out again as the version number has changed. In my login scripts I use the output of the command "ver" to detect the operating system.

With Windows Vista RTM it was 6.0.6000. With Windows Vista SP1 it is 6.0.6001. Therefore any login scripts that detect Vista need to be updated to include both version types.

This is easily done and should not mean too much additional code.
If you have used the method in my examples and put the script commands in to sections, you simply need to add a line to the detect the later version:

findstr "6000" %systemdrive%\ver.txt
if not errorlevel 1 goto vista
findstr "6001" %systemdrive%\ver.txt
if not errorlevel 1 goto vista

:vista
rem vista commands here

By grouping them together the same commands can be used for both RTM and SP1 versions of Vista, unless you need to use different commands for the different versions.

One of the worst experiences for an Exchange administrator is to come in one morning and find that either email is being blocked, the queues are long or the users are getting NDRs saying that the server is blacklisted.

This seems to result in confusion amongst administrators who then go looking for advice only to get conflicting answers on what the problem might be.
I am going to try and clear up some of that confusion which should help Exchange administrators find the source of the problem.

There are two main issues that Exchange administrators seem to see and fail to understand.

1. There are a large numbers of messages in the queues.
2. The IP address of the server has been blacklisted.

In both of these occasions many administrators seem to think that a client machine on their network has been compromised and is sending email through the Exchange server.

This is not the case.

To abuse an Exchange server in this way, a BOT writer would need to

1. get the BOT inside the network
2. infect the machine
3. realise that it is on a corporate network where there is an Exchange server
4. find the Exchange server
5. send the message.

The above, is not going to happen - at least not at the moment. Too much like hard work. The first two are the most difficult - if the network security has been configured correctly and the users trained to recognise potential suspect emails or web sites.

Then sending the message requires either a MAPI interface or SMTP to be configured on the Exchange server to allow users to relay through the server. While this is default, if you do not have any users who need to relay through the server (Outlook, OWA and Windows Mobile/Blackberry BES users do not need to) then you should disable it.

Then for a successful infection and abuse, the above is also presuming that the user is an administrator and the network admin will not notice the infection!

What the BOT writer is really looking to do is infect clueless home users who are not keeping their machines patched, not using security software and are running as a local admin. Much higher chance of success there involving simpler techniques.

Therefore with the target in mind, the BOT will usually have its own SMTP engine and will be sending out email directly to the internet.

So what has happened?

If you have been blacklisted but the queues are clear, then a client machine has probably been compromised. This is often the case when you have a single IP address on the Internet which is shared among all machines on your LAN.

However to further complicate things - if you are using a smart host - such as your ISPs SMTP server - then your queues could be clear but the server is still being abused. However in that scenario it is likely that your server would not be blacklisted on public lists, but your ISP may have noticed and not be very happy with you. If messages are not being delivered to the smart host then phone your ISP and ask - or they may phone you. Often ISPs will block first and ask questions later.

Finding the Source - Compromised workstation

A quick and dirty method to find the compromised machine is to simply stop Exchange from sending any messages by freezing the outbound traffic, and then block port 25 on the firewall and wait. A compromised machine will quickly show on the logs when it cannot connect. You can then go and find the machine and deal with it.

Having up to date Antivirus is not enough. Once the BOT is on the machine, it is no longer your machine. The only way to ensure that it is clean is to wipe the machine. BOTs are very good at hanging around and they will update themselves regularly.

There is a complication on this as well - if you have been foolish enough to browse from the Exchange server then the server itself may have a BOT and be sending out messages. However those messages would still not show in the queues. If you don't browse from the Exchange server then that shouldn't be the cause of your problems.

Finding the Source - Large Number Of Messages in the Queues

If you have a large number of messages in the queues, then those will be coming from outside your network. That does not mean you are an open relay, there are other ways that the spammer can abuse your server.

The two most common are authenticated relaying and the NDR attack.
I have discussed these in more detail in my spam cleanup article on amset.info - http://www.amset.info/exchange/spam-cleanup.asp .

However in short, authenticated relay is where the spammer has attacked your SMTP port trying to break a password - usually the administrator account. Once broken, the account is used to relay email. Authenticated relaying is enabled by default.

An NDR attack is where messages are sent to your server to non-existent users on purpose. Either as a directory harvest attack (to see what users are valid) or to get your server to bounce the messages to the "sender". The sender is spoofed and is the actual target.
Exchange 2000 is unable to defend itself against these kinds of attack without third party support. Exchange 2003 and higher has features built in to deal with this kind of threat, however if you have Exchange 2003 on Windows 2000 then you should not use them as Windows 2000 is unable to defend itself against a directory harvest.

So what do you do?

When you first notice there is a problem, you need to verify whether it is the result of an attack or compromised machine, or the result of a configuration error or change. Do not presume one or the other.
Once you know which it is then you can look further.

If you are dealing with an ongoing problem then pull the plug on the internet connection. That will stop messages going out and if the spammer is abusing your server will stop the messages from piling up. This will give you some breathing space to clean up and see what is going on.

If your IP address has been blacklisted, then use your ISPs SMTP server to send email through.

Ideally you should have at least two IP addresses so that the Exchange server can have its own address. If a workstation is then abused it does not result in your email IP address getting blacklisted.

Remember, any SMTP server is a target for a spammer. They don't want to use their own resources, they want to use those that belong to someone else so that they can hide.

On my technical site amset.info I have an article on how to detect the operating system in a login script.
The method that I use is to dump the results of ver out to a text file, then find the version number in those results.
Here is a code snippet based on what is on that page, for detecting Windows XP. (http://www.amset.info/loginscripts/os-id.asp)

 ver >"%userprofile%"\ver.txt
 
 Rem now find the operating system and act accordingly
 
 findstr 5.2 "%userprofile%"\ver.txt
 if errorlevel 1 goto XP
 
 :notxp
 echo not XP
 
 goto end
 
 :xp
 echo XP
 
 goto end
 
 :end
 echo end

When Vista was released, I decided to update the page to include Vista as an example.
I therefore added the following line:

 findstr 6.0 "%userprofile%"\ver.txt
 if errorlevel 1 goto Vista

However this was based on theory, and wasn't something that I had time to test before I uploaded the new page.

Needing to use it for a client who has a couple of Vista machines and part of the login script wasn't required for Vista, I tried using my own code to skip that section.
If failed to work correctly and I couldn't understand why it wouldn't skip the section I wanted, but worked for older versions of Windows.

The answer I found was in the results of the ver:

XP: Microsoft Windows XP [Version 5.1.2600]
Vista: Microsoft Windows [Version 6.0.6000]

It appears that findstr command ignores the "." in the string. So it was looking for 60 and was finding it in the XP ver results.

The solution is to change the string to search for to 6000 which results in a positive detection.

Update March 2008: With the release of Vista Sp1 the detection fails because Microsoft changed the version string, again. The updated commands required are here: http://blog.sembee.co.uk/archive/2008/03/17/74.aspx

I have heard from many sources that grey listing can be an effective weapon for fighting spam, yet hadn't had an opportunity to try it out.

However one of my clients was being hammered hard with spam, with 700+ messages a day being filtered by Intelligent Message Filter, and lots of messages getting past "I Hate Spam" from Sunbelt Software. Therefore I thought they would be a good site to test the method with.

I installed Vamsoft's ORF (http://www.shareit.com/product.html?productid=169362&affiliateid=200023740) on to the gateway machine and left it to get on with it, enabling just the grey listing and the automatic white list* feature.

* The automatic white list is built by watching outbound email and recording the email address used. When the external recipient replies, the message comes straight back in as the server then knows that the email address is legitimate.

The effect was immediate and noticeable. I watched the logs of the application very carefully to ensure that no legitimate email was being blocked. The amount of spam that was blocked by the application was considerable. After a running a week, the application reported that over 85% of all email that was being received was spam.

That doesn't count messages that were dropped by the filter on unknown users (http://www.amset.info/exchange/filter-unknown.asp).

The process isn't 100% effective, IMF was still catching some messages - but this was down to 20 or 30 a day, a massive reduction in the pre-grey listing number.
Users were also reporting that a few items were reaching their inboxes, but nothing like the level they had been receiving.

I have since deployed the application on four other sites, including my own Exchange server and seen similar significant drops in the number of spam messages being received.

As with user filtering, this technique also saves the bandwidth, as the messages are not even delivered to your server, so don't have to be processed.

The Vamsoft product works with any IIS SMTP mail server, so if you have Exchange 2000 then you can use it as well. It also features Active Directory filtering, which Exchange 2003 has built in, allowing users of the older version of Exchange to benefit.

How Does It Work?

Grey Listing is very simple idea.

A server attempts to deliver the message to the server. If the server hasn't received an email from that sender before, then it rejects the message with a temporary failure.

The systems that spammers use don't care about failure messages. They aren't interested in the failure and will therefore not try again. Spammers want to drop and run, before any system blocks the IP address that they are sending their email messages from.

However a legitimate email server will try again. Most email servers will try again for up to 48 hours, so you will get the email message eventually.

Are there any risks?

Any anti spam technique comes with risks. Unless you have a human looking at every message, you are relying on the computer making the decision whether the message is spam or not.

This technique will introduce a delay for new email messages - I have seen the delay as short as 90 seconds up to 20 minutes or more. If your business cannot tolerate any delay in email message delivery then this technique is not for you.

I have also seen a few email messages fail to be delivered from some sites that generate large amounts of email - such as eBay and a few ISPs. This is because each message appears to come from a different IP address in their server cluster.
With eBay, white listing their domain isn't advised as that will also allow in phishing emails.

Conclusion

While spammers don't comply with the RFC on SMTP email delivery and try just the once to deliver their email messages, this technique will be an effective first strike weapon in the war on spam. It shouldn't be considered the only weapon, but combined with other techniques can make spam more manageable.

One of the tactics I have been using with my clients for many years is something I call internet service separation.
This is where I use different providers for different aspects of the internet service that the client needs. 
This doesn't go down well with many internet companies (whether this is Internet service providers, web hosts etc). They like to have control over everything, get you to use their service for everything etc.
This isn't for your benefit despite what they may say in their sales brochures. It is for their benefit as it makes it much more difficult to leave them. You have to juggle all of the services being disconnected at the same time. For many people, especially those who don't understand how the internet works, they will not want the hassle. It is that reluctance to move that allows companies to get away with poor service.
You should have different companies for the following tasks:

• Domain Registration.
  Use a specialist such as 123-reg.co.uk here in the UK, or Go Daddy or register.com in the US. Don't use them for anything else (despite what they might tempt you with).
  Use a big provider, which limits the chances of them going down. Although most of the domain name registrars are actually using the services of one of the others, so in the event of a failure you may be able to rescue the domain name. 
• Internet connection.
  This should come from a service provider who gives you the best deal. Unless you are on a managed service, use your own kit. Routers etc, so that you have control.
  The only thing they should be giving you is IP addresses. Everything else should come from other suppliers
• Web Hosting.
  This should be with a dedicated host. The web hosting market is so competitive that the choice is endless.
  Try to steer clear from free web hosts - the old adage of "get what you pay for".
  However you don't have to pay over the odds for hosting - especially if the site is a simple static brochure type site. 
• Email.
  Ideally you should be using your own email server. I am an Exchange specialist and this posting is from an Exchange server point of view. 
  Although, if you have more than five or six staff, you are getting to the point where you can justify your own server. This doesn't have to be Exchange - there are many low end options that will provide you with in-house email services without the complexity of Exchange.  

Your Domain Name
The thing that internet service companies all want is to get control of domain name. Preferably transferred to their own domain name registrar, or in to the master account at their pet domain name registrar if they aren't one already.
As that is your company identity, you don't want to loose it. Once they have control over the domain name, they can effectively hold you to ransom.
Resisting attempts to gain control over your domain name is very difficult, and trying to get hosting companies to comply with something else can be a challenge. They can do it - they just don't want to - as there is nothing in it for them.
I have even had companies say that they cannot do what I need them to do - which is a outright lie. Very shortly afterwards they will usually lose the business. For one UK ISP this meant a loss of over £20k in annual revenue as I took a large number of home user accounts, a leased line and other services away as well - I actually had an account manager on the phone begging to be given another chance and crying when they found out.

Despite what any web hosting company, ISP or whoever states - you do NOT have to transfer your domain name to them to use their service.

A domain name transfer is just a way of getting control and also earning themselves some more money from the transfer fee. 
All you need to do is ask them for their name servers, ask them to put your domain name in to their name servers, then enter the name servers in to the relevant option at the domain name registrar.
You have maintain complete control. In the event that you want to move your web site to another host, then you just need to change the name servers. The hosting company doesn't need to know anything about it. I have changed hosts many times, and the first the old company knows about it is when I ask to terminate their service. At that point I am not using them for anything, so if they cut me off immediately, it doesn't impact my web sites in any way.
If you do change the name servers, then you need to use the web hosting company to manage your DNS. Make sure that you have the correct entries in place first.

A better option is not even use their name servers.

Ask for the IP address of the web site and enter that in to your DNS at your domain name registrar. This is often a good idea when you are hosting your own email, as it is not uncommon for web hosts or ISPs to "reset" their DNS records which set the MX records back to their email servers rather than yours.
Protect the domain name like you would any other asset of the company. Make sure that you do whatever it takes to ensure that it remains under your control at all times.