Abstract
Last week we introduced the spamtrap. This week, we’ll discuss a very important part of keeping a spamtrap in good health: keeping it confidential.
In my experience and the experience of other spamtrap operators, when a spamtrap is “blown” (revealed to be a trap) the quantity and type of email sent to that trap changes. These changes can be dramatic. When the sender is aware that they are being observed, their behavior changes. As such, keeping a spamtrap “under wraps” requires vigilance in several areas. Each is discussed below.
Camouflage
First, you will want to ensure your trap doesn’t look like a trap to the outside world. Be aware that given enough time and financial resources, a determined attacker can still find the true owner of any spamtrap. As such, if it would be disastrous for you to be outed as the operator of a spamtrap, then I suggest that you do not run one in the first place. With that said, here are some good ways to protect a spamtrap:
Register the spamtrap domain under an assumed name, a variant on your real name, a friend’s name (with their permission!) or a business name. This does not mean you must be unreachable. Set up role accounts, and read that email. Use a burner phone for your phone number, and a PO Box or private mailbox service for postal mail. If you are feeling very sneaky, set up a private mailbox while you’re on a business trip or vacation, and have postal mail forwarded to your home or office.
Don’t give away too much information about your “users”. Either turn off
VRFYentirely or useVRFYwith all addresses.Don’t make your domain look too professional. It’s okay to not have an
MXrecord and just use anArecord, for example. It’s okay to have your server look like it’s administered by a moderately competent hobbyist rather than by the consummate email professional you are. As an aside, is not okay to fail to upgrade or patch your systems regularly. Don’t inadvertently make more spam by way of a system compromise.
Non-Interaction
Second, unless you have a compelling reason to do so and have put a great deal of thought into the matter, do not respond to or in any way interact with spam. I generally read email to spamtraps using mutt or pine in a shell, because then I’m sure I won’t trigger a web-based bug nor will I accidentally click on a link in one of the emails. If you are very paranoid, manually copy spamtrap email to another system for subsequent analysis.
Sharing
Third, you will need to keep the spamtrap data in the right hands. Sharing spamtrap data can be useful and productive for many security-minded folk, if you are careful. So, the question becomes, how can you protect your data when you share it?
Demand non-disclosure agreements. These are sometimes burdensome to obtain, especially in large organizations, but very important nonetheless. A high-volume, well-maintained spamtrap can be a corporate asset of great value, so it is worth protecting legally. Be willing to sign an NDA yourself as well.
Consider carefully what data will you release and what you will not. If you use a spamtrap to feed a reputation system, you may wish to share some spamtrap information to assist those affected by listings. In this case, consider munging the messages you release. Be careful! There are many parts of an email that can reveal the recipient. If you not are absolutely certain that you have not leaked information in your munged copy, have someone else review it. If you ARE absolutely certain that you have not leaked information, have someone else you trust review it anyway. Then review it again. Then one more time wouldn’t hurt. Then maybe find someone else to look at it. At one time in my career, I closely examined the headers and bodies of at least two hundred messages per day, to make sure they’d been properly parsed. When I needed to redact a header by hand, I still asked several colleagues to check my work. It’s simply that important. On the other hand, aggregate data (how many individual messages were received from an IP in the past 24 hours, overall connection and volume data) are generally safe to share without modification.
Watch your spamtrap closely. If the “profile” of the email the spamtrap receives changes (ratio of malware spam to marketing spam, email to many new recipients all at one time, and/or many confirmation requests), consider that suspicious and possibly indicative of a leak.
Vet your partners carefully. Have they been using spamtrap data long? How do they use it? Do others find them trustworthy and are they willing to vouch for them? Does the data they propose to share with you look to be of good quality? Are they willing to sign an NDA or do they hesitate? Will they reveal how they intend to use the data they receive from you? Is it easy to get in touch with them if there’s a technical issue? All these are good questions to ask yourself before you agree to share data.
Conclusion
Even if you are diligent in obeying the above guidelines, there will eventually come a day when one, some, or all fail and your spamtrap is outed. Consider this part of the spamtrap life-cycle. The best countermeasure here is to have many spamtraps and anticipate that you will need to replace them from time to time. Build new spamtraps regularly so you’ll have replacements on hand.
In the next installment, we’ll talk about a way to build new traps as well as grow mature traps by seeding addresses.
Kelly Molloy is a Senior Program Manager for Farsight Security, Inc.
Read the next part in this series: Spamtraps: Creating and Seeding
