Introduction

The Internet sucks. It’s a horrible, nasty place where people try to do unspeakable things to each other, and that’s just craigslist. Seriously, though, there are some pretty nasty things going on every second of every day. Viruses, worms, script-kiddies and other threats are constantly trying to get past defensive barriers, and more times than not it’s through email that these attacks are launched.

There are many ways to attempt to keep these things from affecting your users, some good, some bad. But how are you to know which is which? Who polices this sort of thing?

The good and the bad news is: nobody does. It’s the wild west, and you’re expected to be Clint Eastwood. How cool is that? Grab a cigar, throw on a colorful Mexican poncho and load up your 6 shooters ‘cause we’re going spammer hunting.

What the layperson, and the budding admin, usually fails to understand is that the Internet is a co-operative. Things work because we have all decided on inter-operable standards, and the reward for not complying is loss of connectivity.

There are documents that describe these standards and they attempt to tame the wilds of the Internet. These documents are called RFCs, which stands for “Request for Comments” and have been how the Internet has been administered for several decades. (The first RFC, “RFC 1 - Host Software” was written on April 7th, 1969 by Steve Crocker.)

Unfortunately, RFCs are sometimes vague (usually this is intentional – it allows for flexibility and creativity) on the details in certain areas. Areas such as e-mail virus warning messages, bouncing viruses and spam, SPF records and more. So it is up to the individual administrator to interpret these RFCs and come to a conclusion as to how to implement a certain feature or function. The course to follow is of course “the best one” – but how do you know which one is the best one? Why, that’s what this page is for. We’ll just tell ‘ya, how does that sound? Remember that most things on this page are interpretations of what the “best practice” is, and in some cases there is vehement debate. This is just what the MailScanner community has determined to be the best practice in regards to e-mail administration – or at least the best practice according to the last person to edit the Wiki. :)

Have Valid RFC Contact Email Addresses

Have valid, case insensitive postmaster@ and abuse@ addresses. This is not a suggestion; this is a requirement to be RFC compliant (RFC 2142.) These addresses must not point to /dev/null and mail sent to these addresses must be read periodically. You can have an autoresponder, but that autoresponder may only make suggestions like “Your request will be processed, but for faster response use blah@blah.com for correspondence in the future.” You may not say “Please mail blah@blah.com for a response” since that does not make it clear that the issue will be dealt with. See RFC 3834 for specific recommendations on autoresponders.

These addresses are used by other admins to contact a responsible party. It is highly irritating to get a bounce to a postmaster@ address, it immediately screams “the admin of this domain needs a helmet to go up and down stairs.” Don’t be that guy.

RFC 2142 defines other standard addresses that you may or may not want to implement, depending on the services offered by your domain. For example, “hostmaster@” is required if you run a DNS server and “webmaster” is required if you run a web server. Please read RFC 2142 for more information.

It is also a good idea to register your abuse@ address

Do Not Send Virus Warning Email

For the love of whatever you hold personally dear, do not configure your system to send email virus warnings by default.

“Why?” I hear someone asking. Let me tell you why: it’s part of the problem, not the solution. Out of the huge volume of viruses that are going to be hitting your mail server, 99.9999999% of them are going to be viruses that forge the senders email address. So your warning is going to go to the wrong person.

Some person who isn’t infected is going to get a warning going something like this:

PANIC! PANIC! PANIC!!!!11

You sent us a virus! Call your administrator who’s at
home sleeping RIGHT NOW so that he can scan everything
on your network! Don’t let him hang up until you’re

sure he’s awake and dressed and ready to come in and
put out this fire ohgodrightnoworwe’reallgonnadie!

We could easily give useful information here, but
we’re not, just so your administrator has a challenge
proving that whatever the hell it was that generated
this message, it didn’t come from your network!

Also, since you receive so many of these misdirected
warnings, you are now expected to ignore all of them!
Even the ones that may indicate a legitimate problem!
There’s no way for you to know which are legitimate
and which are not! Either way, you have no good
course of action!

PANIC! PANIC! PANIC!!!111111one

This message brought to you by False Alarm Anti-Virus
www.falsealarmav.com__
Call us today for a
free quote!
www.falsealarmav.com__


PANIC!!!! TODAY!

So, you can see why this might be a bad idea. There are so few non-forged viruses going around these days that it’s a trivial matter to keep a list of the viruses that don’t forget and notify only those senders. Anything else is a waste. If you feel so inclined, feel free to send notices to yourself, then you can track down the IP of the infected machine and inform the responsible party at the ISP or corporation that owns the IP. I do this all the time, and it’s a great way to find people who aren’t RFC compliant.

As if that wasn’t enough of a reason, consider that over half of the traffic on any given Internet backbone is email, then consider that more than half of that email traffic is unwanted spam and viruses. If you’re sending invalid warnings you are contributing to all that unwanted email. Couple that with the fact that most of these warnings have a reference to the AV product used and guess what? You’ve just become a spammer, Spammy Spammerson. Now you’re on my “list”.

Lastly, RFC 3834 states in part that “In general, care should be taken to avoid sending useless or redundant responses....” I’d say that virus warnings that you know are going to the wrong person are rather useless. So don’t do it.

Have a reverse lookup that matches your HELO/EHLO.

Many of these policies stem from the fact that spammers will forge addresses. When you send mail to a system that doesn’t know you, you’ve become a potential spammer. You must show that you can be trusted before you will be trusted, and one way of doing that is to have a reverse lookup that matches what your system says it is. Unfortunately, this may be a problem in virtual hosting situations. At the very least make sure that your MX is listed in DNS as the name that will respond to the HELO. See RFC 2821 for more information on the SMTP command HELO.

If using a mail gateway, firewall your destination.

If you have a system where one machine receives and scans the mail, then forwards it to another server for delivery, make sure that the delivery server will only accept connections from trusted hosts, ideally only the final scanner machine. It wouldn’t do you much good to go through the trouble of scanning your mail for viruses and spam, only to have a bunch of crap sent directly to your delivery server by some jerk. Spammers don’t follow the rules, and your MX priority means nothing to them.

You should only expose the services that you need to expose. While it may be nice to have ssh open on your mail server, you should at least firewall it to only allow connections from specific known addresses.

Use SPF Records

These have nothing to do with UV protection. Just so you know. The “official” acronym expansion for SPF is “Sender Policy Framework” but they are really “Sender Permitted From” records to many of us. They are nothing more, really, than a TXT DNS record for your domain that says “if email is being sent and it says it’s from me, it must come from one of these hosts”. This framework will allow domains to publish who is allowed to send mail, making joe-job attacks and forged viruses a thing of the past. First, however, there must be a decent amount of domain admins implementing this feature, so get cracking, bucko. Once you’ve set them up and allowed time for DNS to propagate, you can test your SPF records at dnsstuff.com.

Use SMTP-AUTH for Roaming Clients / Don't be an Open Relay

Got people in the field who need to send and receive email? If they must do it from a client program like Outlook, Outlook Express, Evolution, Thunderbird, or whatever, make sure that you’ve set up SMTP-AUTH or some other way of keeping your MX from being an open relay. You could also set up some sort of web mail solution like SquirrelMail, or set up a VPN and only allow senders from inside your IP space. But make sure the only people who can send mail from your mail servers are people you’ve explicitly allowed. Anything else and you’re an “open relay” which means anyone can send mail through you. If you don’t understand why this is a bad thing, leave your credit cards and keys in plain sight in your unlocked car and marvel at how crappy human behavior can be.

You can also set up SMTPS/TLS and MSA for external users that use ISP‘s that have blocked off port 25. SMTP/TLS Howto for Sendmail MSA on Sendmail, and SMTPS/TLS and MSA for Postfix. However, you should note that if an ISP has blocked port 25 then they probably have a policy against sending mail to mail servers outside of their control – you may want to ask them for a policy exception, just to be nice.

Compartmentalize Your Servers

You know those all-in-one server packages that put a file server, database server, web server, mail server, dns server, usenet server, print server, server server and other servers all on one machine? They are a really bad idea.

One reason being that if the hardware fails, you’ve lost your entire network instead of just a subset. That’s never a good thing. The other being that it’s impossible to seperate internal services from external services. You need to be able to do that for security purposes. If you have a single machine exposed to the Internet with multiple services running, that greately increases the chance that someone will exploit a vulnerability, compromising all your network services.

The solution is to comparmentalize as much as is practical. Ideally you’d have one server per service, but in most places that’s just not practical. At the very least, you should have one server for external services (mail, web, dns, etc) and another for internal services (file and print serving, internal instant messaging, database, etc.) Limit your internal connections and there’s less chance that your internal servers will be compromised.

A lot of companies use a groupware server like Microsoft Exchange or Lotus Notes. You can safely keep those machines inside your firewall and put an SMTP server outside (running MailScanner, of course) the firewall, then forward your mail to your groupware server. Childish accusations of stability aside, Exchange and Lotus Notes are very complex software packages. The more complexity in a piece of software the more vulnerabilities it will have, the software being written by Microsoft or not – the same could be said of an open source group-ware package. Regardless, it’s important to only expose the absolute minimim of services to the outside world.

Please note that every place “outside the firewall” is mentioned the phrase “outside your internal firewall but inside your DMZ” is implied. This was necessary to avoid redundant typing.

FIXME Add links to articles supporting compartmentalization and explaining modularity in more detail. Add links to MS, IBM, MailScanner, “script kiddies.”

Don't Bounce Spam or Viruses

Mostly this is in the “don’t be part of the problem” camp. Bouncing spam and viruses contributes to the joe-job problem, wastes bandwidth on delivery failure messages that will never reach a valid recipient and generally irritates people who receive the bounce but never sent a message. Don’t do it. By the time you’ve processed a peice of mail and determined that it’s either spam or a virus, you’ve determined that it’s either spam or a virus. Why would you then send that garbage on? Just dump it to /dev/null and get on with things. The chances of a false positive are very low, especially on viruses. If you’re worried, you can always have a set of rules that will bounce on, say, filename rule triggers, but still junk any virus message as determined by your virus scanners. Once again RFC 3834 may be referenced in regards to this. A bounce is nothing more than an autoresponder – and these sorts of bounces are useless. If you must bounce this sort of content, do not bounce the attachments. You will most likely get onto a blacklist very quickly.

Use Multiple Virus Scanners

If your budget allows one virus scanner you can afford at least three, since ClamAV and BitDefender are free. There’s no reason not to use multiple scanners. If one scanner misses something or is temporarily not working, you’ve got more chances, plus your basic rules should catch any executable and stop it before it enters, whether it’s caught by your scanners or not.

Keep your software/your knowledge up to date.

It’s been said many times, but in case you’re one of the three people on the planet who’s never heard it: Security is a process, not a product. You can’t set this stuff up and let it rot. Spammers and virus writers are constantly coming up with new tricks to get past your defenses. A year old MailScanner setup, while still effective for old stuff, is vulnerable to new attacks. Keep things up to date. This doesn’t mean that you must be bleeding-edge constantly, but once a month or so check your versions and upgrade if need be.

It should go without saying that you should keep the rest of your system up to date as well. The last thing you want happening is to spend a week setting up the perfect mail filter, only to have someone compromise your box with an ssh exploit. Please see your vendor or system documentation for solutions – there are many automated solutions for all relevant versions of Unix and Unix derivatives.

Your brain is almost as important as your software. You must keep yourself abreast of changes in the industry, new vulnerabilities, new exploits and new tools. One great way of doing this is to join the MailScanner mailing list where we cover so much ground we occasionally discuss overpriced ergonomic chairs. You should also join other more security oriented mailing lists, and take advantage of any notifications that your vendors may make available.

Test your setup frequently.

Almost a continuation of the previous topic: test your stuff. You’ve spent hours setting up spam and virus blockers, you’d better make sure it works before you accidentally send your bosses “How to Irritate your Employees” monthly e-newsletter to the bit bucket. There are a few places you can go to test:

How to test your setup with telnet
http://www.dnsreport.com
http://www.dnsstuff.com
http://www.samspade.com
http://www.abuse.net/relay.html
http://www.webmail.us/testvirus

One more open relay test you could perform from a shell on your local machine:
telnet relay-test.mail-abuse.org

Please note that the testvirus site is for testing only. The only “virus” sent is the Eicar test virus, which may or may not be caught by your virus scanner. Eicar is a safe piece of code that many AV companies have decided to catch for testing purposes.

Confidentiality Disclaimers are Annoying

This is probably the most controversial topic on this page, but I think it needs to be said: confidentiality disclaimers are dumb, especially when they’re sent to mailing lists. They’re not legally binding in any country that I know of, and they just make a lot of noise. First of all, if you’re sending unencrypted messages across the Internet and you’re under the delusion that your messages are safe from prying eyes, you need a reality check – fast. Your message is available for anyone with a packet sniffer to see, at any point across the path that the message takes. If you want confidentiality, look into a public key encryption program like gpg.

If your boss or legal department has required that you set this up then there’s nothing you can do about it, and I feel for you. However, you should at least point the responsible party to the following sentence, so that they may be educated. People are laughing at your precious disclaimer.

Buy the MailScanner Book

Every admin worth anything will buy the MailScanner book. Even if they don’t run MailScanner they enjoy reading about it, since it’s so cool. All your friends are buying the MailScanner book. Don’t you want to be like all the cool kids? They’re buying the MailScanner book. When Tom Cruise was cool, he bought the MailScanner book. Now that’s he’s gone all loony he’s never been near the MailScanner book. If you don’t buy the MailScanner book, everyone will talk about you behind your back. The MailScanner book is better than Gone With the Wind and shorter than War and Peace. The MailScanner book might be capable of curing cancer. The MailScanner book can be used to locate water, oil, precious gems, minerals and metals. Reading the MailScanner book is better than sex. In an emergency the MailScanner book can be used as a blanket, pillow, flotation device, kindling, or as a source of fiber. The MailScanner book makes a handy personal defense device. Clinical trials say that the MailScanner book can ease the symptoms of acid reflux disease and may even heal leprosy.

 
best_practices.txt · Last modified: 2006/02/09 15:49 by glenn
 
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki