Using Exchange to prevent information leakage by your idiot staff who can’t type
Wired published an interesting article this week about the use of what they call ‘doppelgänger domains’ that collected email sent to misspellings of the domains of a number of large companies. The headline of their report?
The intercepted correspondence included employee usernames and passwords, sensitive security information about the configuration of corporate network architecture that would be useful to hackers, affidavits and other documents related to litigation in which the companies were embroiled, and trade secrets, such as contracts for business transactions.
“Twenty gigs of data is a lot of data in six months of really doing nothing,” said researcher Peter Kim from the Godai Group. “And nobody knows this is happening.”
The best part is that their 120,000-strong haul of misaddressed emails, over 6 months, came from only 30 dummy domains (though probably carefully-chosen ones).
This had never really occurred to me before, but I immediately got to thinking about the bad typists in my own school. I imagine you have at least as many in yours. These are people who routinely share passwords with one another, dismiss Data Protection as nothing but red tape, wouldn’t hesitate to put login details in an email, and have fatter fingers than the Stay Puft Marshmallow Man.
I then checked a few common typos of our school’s domain name. All the ones I picked were registered by typo squatters. I fired off some emails to headmaster@ for each one. 1 bounced. The others disappeared, possibly to a black hole, possibly to a catch-all. The point is, I have no way of knowing.
This is a problem.
When you can’t register the typo domains yourself, the Wired article recommends that admins “configure their networks to block DNS and internal e-mails sent by employees that might get incorrectly addressed”. I wanted to do something a little more graceful than a bogus MX record, so I started looking at Exchange Transport Rules. What I found was that I could very easily block any misspellings that tried to leave the school mail server, and bounce the message back to the sender with clear instructions about what went wrong (unlike pretty much every other bounce message in the history of email).
Rejecting messages in Exchange 2010 with Transport Rules
As is typical with Exchange 2010, you can only do half of these steps in the GUI; the other half can only be done via the Exchange Management Shell using PowerShell script, because the GUI team are lazy gits. I’ll just show you the whole thing in PowerShell, since we have to use it anyway.
First, you need to set up the Delivery Status Notification (DSN) message you want to return. You need to pick a DSN code to associate it with; for custom DSNs, valid codes are 5.7.10 through 5.7.999. I’ve picked 5.7.10 for simplicity.
New-SystemMessage -DsnCode 5.7.10 -Language En -Internal $True -Text 'You have misspelled ''myschool'' in the above address, you muppet. Learn to type and try again with the correct address. Please note that if there were other recipients listed in your email, they will have received the message OK; don''t annoy them by resending to everyone.'
If like me you ironically manage to misspell your DSN message that tells people about misspellings, you first need to find out what its referred to internally:
Which will spit out something like en\Internal\5.7.10 along with the text you defined. That first bit is what you need in order to edit the existing DSN message:
Set-SystemMessage -Identity en\Internal\5.7.10 -Text 'Correctly spelled DSN message.'
Now you can create a transport rule that uses this message. The following rule will bounce any message sent to domains “@myscool.com” or “@myskool.com“.
New-TransportRule -Name 'Fat Finger Guard' -Comments '' -Priority '0' -Enabled $true -RecipientAddressMatchesPatterns '@myscool.com$','@myskool.com$' -RejectMessageReasonText 'Sender has fat fingers. Bounced by transport rule to prevent information leakage.' -RejectMessageEnhancedStatusCode '5.7.10'
If you love PowerShell you can of course modify this to be a much more complex rule, but if you have real work to do instead of just wasting your time figuring out syntax, use the Exchange Management Console to modify the above rule once it’s created.
The end result is a message like this when your staff screw up:
Of course, you may want to alter the wording slightly. Or not, for added fun. For bonus points, you could also set up similar rules for other schools’ domains that your staff regularly communicate with. After all, you just know the front office are sending unencrypted personal records to a pupil’s new school the moment your back is turned.