For many years, I managed email servers for various companies. One of my first challenge was to configure anti-spam filters to block a maximum amount of spams, while allowing legitimate emails. That wasn’t easy as spammers changed their strategies monthly. But I managed to keep up.
The problem with managing anti-spam servers 20 years ago, was the numerous tools used to help with that battle. Content filters, blacklists, anti-virus, ip reputation , DNSBL and home blew techniques. I could achieve over 98% spam filtering, but at the cost of spending a high percentage of my work time analyzing spams and adjusting the filters.
One day, I acquired an anti-spam appliance called “Ironport”. That was also the name of the company before it was acquired by Cisco. The ironport appliance had the same type of filters I used to managed, but the heavy lifting was done by Ironport and the appliance had access to their filter updates thru a subscription service. It was a brillant appliance and eliminated a high number of spams.
Over time, spam emails slowly transforment into security threats. Instead of selling “Viagra”, incoming spams tried to trick users into opening attachment files containing trojans, or tried to convince a user to click on a link to some nefarious website which would exploit your browser’s weakness to install a backdoor.
Although the Ironport did a relative good job at blocking the new attacks, I discovered that this appliance had a powerful SMTP control-set which allowed me to manipulate the SMTP header of any incoming or outgoing emails. That is when I started creating my own filters.
Outgoing Email
The first thing I did with this SMTP command tool was to strip non-required header information of all outgoing emails. Since we had multiple Outlook servers inside, which added their information to the SMTP header before relaying outbound emails to the Ironport, I stripped all that information from the headers before allowing the email to be delivered. This protected the inside network information, like the Exchange Sever’s IP addresses, names, version etc. I also forced all SMTP communications to use secured SMTP first, to protect the email content from man in the middle sniffers.
If you have ever worked with software developers, you will find that they are pretty lazy the it comes to security. Ours developers would deploy a server somewhere and send the client a login username and password. Most of the time, the password was the name of the company + “123”. Yes, pretty bad practice. So, I use the ironport’s filtering capability to intercept these weak passwords, bounce the email back to the developper and attach a notice about our password management policies. Yes, the developers complained and I didn’t make any friends, but I certainly made things more secure.
Also, some developers were ignorant enough to create SMTP relays within their Web servers, and relay outbound emails to bogus domain names like “test.domain”. I can’t tell you how much junk got stuck in the outgoing SMTP queue specially when 100 thousand test emails were sent. To teach those developers a lesson, I traced back the developper who configured this web servers, and created a filter to bounce back ALL test emails to his personal outlook inbox, and attached a notice in regards to his bad practice and company resource abuse.
At some point, I had to whitelist all allowed relay IP to block any new web servers that may appears on our network and would relay test emails thru our corporate email servers. That put a stop to the developer’s shenanigan. Now that Outgoing emails got throughly cleansed, I had to focus on incoming emails.
Becoming agile and knowing your network infrastructure is the key to successfully secure it. No security appliance is sophisticated enough to outperform someone who really understands the network he’s managing and can become creative with the tools he has.
Incoming Emails
The ironport appliance had multiple anti-virus engines, ip reputation and spam content filters, all managed by the subscription service. But to make things more secure, I had to reorganize the SMTP network flow to take full advantage of all the security scan tools.
For example, I forced Secured SMTP to be used on all incoming connections, and defaulted back to insecure SMTP when the senders didn’t support a secure communication. Before relaying those incoming emails to our exchange servers, I re-routed these smtp communications them thru a UTM firewall capable of scanning in realtime SMTP communications and look for viruses and trojans. You would be surprised by the amount of infected emails which didn’t get detected first by the ironport built-in anti-virus, but got flagged and blocked by the firewall.
Then, I tighten the attachment allowed types to block any macro virus which might fly under the radar, and instructed the staff to use an FTP server to exchange files with their clients. That took care of rogue incoming macro-infected emails. I also configured a bypass filter which allowed someone to receive an email from a trusted client, which bypassed all the blocking filters, but needed a KEY added to the subject to be allowed. Example Subject: Files for the web server FF9A022BC918. The word “FF9A022BC918” was the key required to bypass the tight security in regards to attachments. I rotated this key monthly and make it available to the staff on the company’s portal. In reality, only a few people needed this feature, such as the CFO, which traded Excel and Word documents truffled with macros.
What about links? When a links was detected in the message body, I had a filter which converted the email message content encoding to reduce the text content to ascii only text, removing the user’s capability to simply “click” on the link to launch his browser. The user had to willingly copy the link URL, and paste it in a browser to visit the site. That made things just a tad more secure.
Email for Business Only
If it was up to me, I would create a whitelist of known domains the company does business with, and block everyone else. Period. Except, that Subjects contains the passthru key “FF9A022BC918” would be allowed in. That would certainly take care of ALL the cyberthreats coming in thru the email system.
What about Bob’s wife who wants to send Bob an email about the kids? Bob has several options here to receive email from his wife. 1) He can share the “FF9A022BC918” key with her, 2) He can ask his wife to use the Email portal provided on our company website, 3) Bob can ask IT Security to add the domain of Bob’s wife to the whitelist. Obviously, the third option would be at the discretion of the security governance. @gmail would certainly be refused automatically, but a @gc.ca could be trusted and allowed thru. But in this case, Bob’s wife would probably send BOB a SMS instead. Compagnies who value security over convenience can impose this in their usage policies.
Technology is as efficient as its operators. Most security systems may offer basic protection, but the administrator/operator needs to be creative and come up with the rest of the recipe to make things more secure.
The problem with securing email communication is that user have too many alternative solutions to transfer data to another user; iMessage, SMS, discourt, Webmail, USB fob, Airdrop, and so on. There are no perfect SMTP server solutions, but a creative operator can certainly make a pretty secure one at little cost.
The real problem is that companies are always open to innovations which help their bottom line and can make their life just a bit easier, but are also often totally blind to the nefarious effects of adopting these new technologies.
This was my view.
Cheers & Beers.
