www.tartoos.com Preventing IIS SMTP 'spam relaying'

Spam is not funny. Spammers resort to all sorts of underhand tactics to get out their message, inlcuding hijacking insecure SMTP servers. This article explains how to stop these scumbags using your IIS box as a launch pad for mass-mailingswww.tartoos.com

It's nice to have an SMTP server. I really couldn't go without one these days. I use my IIS SMTP box to send email from Outlook, from ASP and from WSH. My office's SMTP box is used by my colleagues to send their SMTP mail without needing a round-trip to our Exchange server in our New York office. However, IIS SMTP boxes can be vulerable to abuse by third parties if incorrectly configured. To demonstrate this I'll tell you a little story.www.tartoos.com

When I started my current job, I set about building a more capable web development department. Before I joined the company didn't have a development server, so the first thing I did was to get hold of a machine and the software I needed to get it going. About two weeks after I installed my development box I got a phone call from a sysadmin in Melbourne.

"Are you the administrator of xxx.xxx.xxx.xxx?", he asked? (ip hidden, of course).www.tartoos.com

"Are you sending out mass mail?" The answer of course, was no. Then I twigged. Someone had hijacked my SMTP server. A mad rush across the room and the network cable was out of the box. I thanked my informant and apologised for the hassle. I was sure I'd set it up correctly, and of course, first time around I had. But I'd re-formatted the machine to set up a better partition scheme and forgotten to re-configure IIS's SMTP service. A simple mistake, and it'd been rooted out by a spammer inside of two weeks.

This happened because IIS's default settings allow relaying through the SMTP service by default. If this is the case, you could be in big trouble very quickly. This article should explain how to lock down your SMTP service and prevent you becoming a spammer tool.

Now, the obvious way to do this is to disallow anonymous access, however if you do this, you'll have trouble sending mail from ASP scripts on anonymous sites. This isn't desirable from my point of view, so what I needed to do was to head to the 'relaying' section of the SMTP properties dialog and disallow relaying for all machines. Of course, this causes trouble when sending from Oulook. So we allow all machines who successfully authenticate to relay.www.tartoos.com

Now you'll be reasonably safe from the spammer scourge, unless of course they get hold of the account details required to send mail. This should be dealt with by your security policy.www.tartoos.com

Now, of course, with the release of ASP.NET a further problem loomed out of the mist. ASP.NET uses TCP-IP to send its mail, rather than the CDONTS method of simply writing to the queue folder. And it requires the ability to relay. Damn. You can cure this simply be allowing 127.0.0.1 (or your local IP) to relay.

It's also a damn good idea to test your server - a number of anti-spam sites provide a relay testing service, and also to enable logging, so that if someone should get through and blast a few thousand emails from your system you'll be able to track them down to their ISP and initiate action against them. It's often said if you're not part of the solution you're part of the problem - this can be a harsh truth if you run an insecure SMTP server.

Keeping your web server secure from prying eyes is essential for many reasons. this article runs new IIS users through the basics of IIS authentication schemes.www.tartoos.com

IIS provides several authentication schemes to keep your content safe. Unlike some other web servers, though, IIS's authentication system is inherently tied to Windows NT/200/XP's inbuilt file security system, meaning managing IIS access is similar to managing accounts on the server itself.

A secure IIS server should be running on a filesystem using NTFS, since the security scheme is more sophisticated than simple FAT filesystems, allowing as it does complex ACLs (Access Control Lists) on a per-file basis.

IIS allows three types of access control via the IIS service manager. Anonymous Access is the first, which doesn't really allow anonymous access, but that's just semantics. What this scheme does is to allow users to access resources on the server under the security context of the IUSR_<machine_name> account, in my case, IUSR_Lycosa. Evryone who hits an anonymous server like this effectively becomes that user. SO, for instance, if you added IUSR to the Administrators user group, every single user hitting your machine would be running under the context of an administrator - not really a good idea.

To disallow particular files to a user when anonymous, you can simple use Windows Explorer's properties->security dialog to remove the IUSR account. When the user hits these, they'll simply be refused access with a 401 error. Vice versa, you'll need to add permissions for the IUSR account to any files you need folks to access. The now legendary "Operation must use an updateable query" error when using Access is intimately related to this fact - usually the IUSR account doesn't have sufficient permissions on the directory to create Access's locking (.ldb) files.www.tartoos.com

So above this level, how do you allow anonymous users to access some files, but conversely only allow known users to access others? Well, we enable either Basic Authentication or Challenge/Response (now called Integrated Authentication, but reffered to here as C/R), and set the appropriate NTFS permissions. IIS will handle the rest, and will prompt users for a password when accessing secured files.

Which brings us to a description of the differences between Basic and C/R authentication. Basic Authentication is the standard method of transmitting authentication information over HTTP. It sends the information from the client to the server in plain text form, unencrypted, so it is vulnerable to a determined packet-sniffer, though in practical terms it would be difficult to intercept these packets. This method works with all browsers and through all proxy servers. C/R, on the other hand, is only supported by Internet Explorer and can cause problems with some proxy configurations, but has the advantage of being encrypted in transmission via a public/private key system. So it can't be intercepted, but likewise can't be used in non-Microsoft environments. The choice of what you use is entirely yours.www.tartoos.com

To add a new account for access to IIS resources, you use the User Manager or the Computer Management interface in more recetn versions. Simply add a new account to the manager and set the appropriate permissions in NTFS - IIS will handle the rest for you.

So as you can see, IIS security really is tied to windows security, and the two work in harmony - with security 'cascading' down. If the anonymous user has access, allow it, if not, and authentication is enabled, prompt for password and check against NTFS ACLs. If only anonymous is enabled, simply deny access. Fairly simple. I'd encourage you to play around with it a bit in a safe environment to get familiar, then you'll be on your way to having a more secure server. As for policies and using groups, we'll deal with some suggestions in a separate article, and for further reading, I'd suggest MSDN or Chris Crowe's IISFAQ.