Email. Practically everyone connected to the Internet has at least one email address. Not surprisingly: If you get connected to the Internet, one of the first things to do is inform your friends and family on how to reach you… by email. As soon as you start to receive spam, you know that at least someone got the message 😉
Once upon a time, I was given the opportunity to rethink, build, test and migrate the network gateway infrastructure and servers handling email for roughly 45000+ email accounts. Email is technically very diverse, but at its hart uses two protocols: The Domain Name System (DNS) and the Simple Mail Transfer Protocol (SMTP). Since email fulfills such a basic need in communication across the entire Internet, most people tend to think of it as “always there”, and “available” whenever needed. Migrating email related equipment from one to the other is not something to do without extensive preparation. This post is a high level summary. It’s here in case I need to refresh my memory, or just spread ideas about the subject.
I found it easiest to think of email as a two lane highway: One inbound and one outbound. Which is the first hurdle: If there is ‘inbound’, then there must be an ‘inside’. The same goes for outbound. In order to migrate everyone to a new highway, you need to know your network’s boundaries. And if there are trusted parties, what kind of information is used on either side. An email gateway should be part of that boundary, effectively separating the Internet from the internal network and its users. Make sure you identify users within your email domain… on both ends of the boundary; it is very easy to overlook special cases where an ‘internal’ user is on the ‘external’ Internet. These border cases can make email policies a headache to implement.
Every highway has roadsigns to tell drivers where to go. The same goes for email. On the Internet, email destinations are part of the Domain name system in the form of Mail eXchange (MX) records. These tell the system sending email addressed to ‘email@example.com’, where the destination for ‘example.com‘ is. The receiving server for ‘example.com’ should be able to deliver the email to ‘user’, or refuse or even bounce the email back to the sending party if it turns out there are problems with that email account. The sending system should be capable to handle such exceptions gracefully and retry as often as necessary, and may even inform the user sending the email, about difficulties it encountered. An email is considered ‘deliverable’ when the receiving server has accepted the email and reports it as ‘queued’ to the sending system. If anything goes wrong from there, the receiving server may try to bounce the email back to the sender(!)
If you’ve read this last paragraph carefully, you might have noticed a few security loopholes.
SMTP is notoriously insecure when it comes to integrity of both sender and receiver: Anyone can post a message claiming to be anybody, there is no one authority to verify that before delivery. If you really sit down for this, you could write full tests for every path an email can possibly take across your gateway. I highly recommend you do so. Failing to deliver email is a nuisance, but relaying email for unauthorized users will very likely lead to abuse, such as spam-runs from and to your domains. So also add tests that should fail, and make double sure you do not configure the gateway as an open relay. Since this last part is such a strict requirement, as open relays get blacklisted really fast these days, I wrote a small Perl script to test the most common SMTP gateway abuses. You can find that here.
It has a built-in manual page, so using it shouldn’t be too difficult. You can override it’s default tests with a configuration file. There is one option that I’ve not fully documented so I’d like to explain it a bit more (better late than never):
Nearly every system administrator has email from internal services. Unix’ cron for example. These are generally injected from the local machine into the flow of email and are very likely to come from a special domain or ip-address. This last case can only be abused if you know the internal addressing of the network. Internal networks in IPv4-land are often numbered as described in RFC1918, which still leaves plenty possibilities to test, but are generally recorded in the email itself in the form of a so called received header. So if you were to look at the source of an email and study its headers, you could figure out what path it took to get to you as every system handling it adds it’s own address, time, email identifier and software version. Put all these ingredients together and you have a recipe to mimic an internal server! I won’t go into details on how to stage a ‘test’ like that, but it is easy enough if you have a lab and software.
As you might have figured out: SMTP is a service without authentication. By default, anyone can post an email and the system will try to deliver it. Second: there is no form of identification. Anyone can claim to be anybody. And this is only the email addressing-part! The email body is another can of worms! Restrict relaying (outbound email) for internal users only, and receive only (inbound email) for domains for which you are responsible. Nmap can also test for open relays, and there is a web service that can do just about the same.
…and although I know it is frowned upon: I do recommend you strip email headers from internal network information. Don’t throw it away entirely – it’s there for a good reason – just cut out network and software related information. There simply is no need for others to know that, unless you are trying to solve a problem with them. Some refer to this as security by obscurity, I think of it as “need to know” information. It isn’t a secret, but it sure is sensitive information that might give an attacker a hint on where to strike; don’t hand it to them, leave them guessing!
Last but not least, never rely on a single defense barrier, use at least three different anti-virus products: one on the email gateway, one on the internal mail server and one the user’s desktop. The same goes for anti-spyware and spam software.