I just found this manual through slashdot. It's awsome! Even I understood it! :)
Fighting Relay Spam
Printable View
I just found this manual through slashdot. It's awsome! Even I understood it! :)
Fighting Relay Spam
Wow... Thanks a lot, Guus.... :) Ill give you some greenies when I can distribute them to you again ;)
I had read that, though I was hoping someone else would post it..
thanks Guus :)
Nice one.
Good manual
My name server seems not be able to find the adress :(. Can you check and see if the host still is up and maybe provide me with the IP to the server?Quote:
Originally posted here by Guus
I just found this manual through slashdot. It's awsome! Even I understood it! :)
Fighting Relay Spam
~micael
Ghe, no luck ... weird, something seems to be not working - ah well, I'll add the text in the next post, hidden.
Preface:Quote:
I'll not bother you by placing the entire text between quote-tags, but this entire text is ripped from http://frs.axisline.net. Enjoy.
I'd like to make some suggestions about fighting spam, in particular relay spam. The intent of these suggestions is to add to the current techniques in use to fight relay spam.
Relay spam can be fought at the source, at the destination, and at the relay. Various spam filter techniques exist at the destination. Honorable ISPs do not provide service to relay spammers, and cancel any accounts found to be engaged in relay spamming. The techniques in use at the destination and at the source are fairly complete.
Techniques exist for use at the relay, but are not often used. One approach is to configure a potential relay as a teergrube system (http://www.iks-jena.de/mitarb/lutz/u...rgrube.en.html). This works and you may wish to consider using it.
This approach of configuring sendmail to accept and then discard relay messages appears to be used infrequently.
A technique that is not recommended:
I have experience with configuring a mail server to filter incoming messages to identify and stop delivery of spam messages. One characteristic of relay spam messages is that they have multiple recipients. The technique I have used is to embargo all email messages with more than one recipient, and then subject these messages to a validation test. Those messages passing the validation test are delivered. The rest are held. These are reviewed periodically and the valid messages improperly held are delivered. Based on my experience I can say:
1. this works
2. I don't recommend it.
A technique that is recommended:
I don't recommend the mail filter approach outlined above because it is too complex and requires frequent attention. Instead I believe a simpler technique can be at least as effective. This technique can be expressed in its basic form in a single line:
sendmail -bd
Note: For sendmail versions 8.9 and newer the default is to not relay. You can turn on relay by including the line
FEATURE(`promiscuous_relay')dnl
in the configuration file.
This command runs sendmail as a daemon so that it accepts incoming email, but lacks the customary specification (such as -q5m) that specifies periodic examination of the queue and delivery of the accumulated mail. It should be obvious that this is not a technique for use on a mail server. It is usable and effective on any network-connected system that is not a mail server but is running Unix or Linux.
What happens when you run sendmail this way?
1. Normal email is not affected. If this is being run on a non-server there is no legitimate normal email that should be coming through the system. If there is normal email going to or coming from this system it will be affected unless you do something to facilitate delivery of this normal mail. If you don't know how to do this and cannot come up with an alternative don't run sendmail -bd.
2. The first (and perhaps only) email trapped will be relay test messages. It is obvious that spammers use open relays, it is obvious that they find open relays. It is almost as obvious that they do this in the simplest and most direct way possible: they scan the internet for open relays. If you create a system on the net that accepts but does not deliver relay email it is almost certain that this system will be the target of and will trap relay test messages.
What do you do when you trap a relay test message? First you congratulate yourself that you have done something that can help to defeat a spammer. Next you can do any of several things:
1. You can report the tester to the originating ISP. Scanning for open relays is a spam support operation. (There have been those who have scanned for open relays so that these can be listed. If this scan was done by someone on the anti-spam side you may choose to simply ignore the message. The trick is to determine the nature of the sender. Use the techniques you already know for this. Search dejanews for reports on the domain, for example.)
2. You can report the tester to the ISP of the valid addressees, if any, of the test message. Same as above: receiving a test message is a spam-support activity.
3. You can save a copy of the message and then cause it to be delivered. If you do this you are telling the spammer that your system is a relay. It isn't: you control what is or is not delivered. Having given your system the false identity of an open relay you can soon expect real spam to come its way. To deliver a message you probably will want to do this by recipient. Find the entry on the mail queue that is a test message (it probably is the only entry), identify the recipient, and then do sendmail -qRrecipient, where recipient is some unique string in the email address of the recipient. (Remember to first save a copy of the message.) You can create a directory for spam messages, call it /home/spam in this example, and then do cp /var/spool/mqueue/*AAwxyz /home/spam. The string AAwxyz should be replaced by the identifier you see when you do a mailq command. Note that if the only thing on your queue is the spam test message then you probably can simply do
cp /var/spool/mqueue/*AA* /home/spam.
If you set up a decoy you will find that there are various styles of relay test message. Note that a spammer may try to disguise his test message as being something else, or as a test message from an anti-spam organization. Do not be deceived by such tactics. If you have intercepted the message on a decoy it is nearly 100% certain that it is a test message. It is very probable that the test message is the work of a spammer or spam supporter.
What can you do with trapped spam?
1. Report the attempted relay to the originating ISP, if that seems fruitful, and to the upstream ISP. You are not merely reporting spam: you are reporting an attempted theft of service. Even if the spammer has a "pink contract" with his ISP he has no protection. ( "pink contract" is an agreement between an ISP and a customer that exempts the customer from the ISP's terms of service that forbid spam.) The ISP cannot by contract turn theft of service into a legitimate activity. You can suggest to the ISP that if he continues to ignore warnings such as the one you are sending he is making himself a co-conspirator in the criminal justice system and a co-defendant in the civil justice system. In the civil justice system he may be the co-defendant with the deepest pockets, so that if there ever is a class action suit on the behalf of those whose service has been stolen by relay spammers the ISP may end up owing a large judgment.
2. If the spammer is hitting you hard, trying to send a lot of spam through you, you can do something even more damaging to the spammer: throw it away (keeping enough as evidence) but let it continue. The spammer is wasting his bandwidth trying to send through you. You are wasting equivalent bandwidth. (Don't do this if you don't have the bandwidth to spare.) You may make a significant dent in his activity while he continues to try to send through you.
So far I've described this as an infrequent activity: only a few relay decoys in operation. What happens if this is done in a widespread manner? Answer: a large fraction of the supposed "open" relays are not actually open. This means that the relay tester gets a lower yield when he runs his tests, has more false positives. What happens if the relay tester is more clever, and checks the aged relay list on ORBS? Answer: who says you can't have your decoy system listed on ORBS? You can fake a relay spam message through your system and nominate it yourself. You want it to be on the ORBS list, if that's where the spammer checks. What happens if the spammer doesn't relay check, but simply uses the ORBS list? Answer: if he tries to relay through your system he fails, no matter how he discovered your system. What happens if the relay tester is selling lists of open relays? Answer: his customers will become angry with him because he is giving them bad information. What if these customers decide to stop paying and to just use the ORBS aged relay list? Answer: if the decoy systems are on the relay list they are just as bad off.
Running sendmail -bd should be very effective on systems that have in fact been used as real open relays. Simply switch the configuration so that the system stops delivering mail. For some time the spammer probably will continue to try to use the system. The system has been switched from being an open relay to being a spam trap.
Note also that spammers typically relay via IP number, not by name. What does this mean? Answer: you can simply switch IP numbers between an identified open relay and a spam trap and use the trap to absorb the spam. If the open relay system is not secured it may be discovered again and used again. If that happens its IP number can be switched again. (The best course is to close the relay, but even in this non-ideal scenario the spammer is still injured.)
Note also that currently there are three most-probable email states for an IP number:
1. The system with that IP number does not accept any email.
2. The system with that IP number accepts email but openly rejects relay.
3. The system with that IP number appears to be a relay and is a relay. (There may be more than 100,000 of these systems.)
The spammer is looking for systems in the third category. He is almost certain that any system that appears to be an open relay when it is tested is an open relay. He encounters almost no difficulty in his testing. He finds as many relays as he needs.
Running sendmail -bd (and then delivering identified test messages) takes this away from him, on a system-by-system basis. He either tries to send spam through the decoy systems or he must devise and use further tests to distinguish between open relays and decoy relays. He cannot hide these tests: they appear in the mail logs. Using the log entries you can notify his ISP of the relay scan activity. (Warn the ISP not to tell the relay tester anything that will identify the source of your report.) You also injure him when you shut down his relay test account.
What happens if the relay tester figures out that your system is a decoy? Answer: change its IP number and go again.
What happens if the relay tester decides your whole domain is suspect, that any relay he finds may be a decoy? Answer: that depends on the spammer. I'd like to think he simply crosses that domain off the list to be checked for open relays. Doesn't this end the usefulness of the decoys in that domain? Answer: Probably. Except that they still are useful as an example: make your domain hostile enough to the spammers and they will blacklist it. If other domains follow your example they will also be blacklisted by the spammers. The goal is to deny relay to the spammers. If they blacklist you that is just as good as if you had simply blocked relay in the first place. And you have the added benefit of all the trouble you have caused the spammer.
An important alert:
The description above is simple, but the world (and sendmail) aren't always as simple as one would like. Sendmail has a feature, ETRN, that must be dealt with if you use this technique. ETRN allows anyone to contact your sendmail (if it is running -bd, as suggested above) and cause it to run the queue (attempt to deliver messages) for a particular domain. So, for example, if the spammer filled your system with spam aimed at users at aol.com he could connect to your server and do etrn aol.com.
So, either turn the feature off or have your decoy sendmail configured so that it can't deliver. For example, set your smart host to something like nowhere.nodomain.com. If you have several decoys running (any Linux/Unix system with no legitimate or vital email function can be used as a decoy) you can have them all deliver to the same smart host, also running sendmail -bd. This also simplifies the task of looking at the queue to see what you've capture: simply log on to that system and do a mailq. Simpler yet, create a cron task that every n hours (your choice on n) does mailq | mail -v yourname@yourhost. The -v forces delivery. This may be a system that can connect within your domain but has no valid route to the rest of the world. If you want to deliver some or all of the relay tests you capture (so the spammer thinks you are an open relay) you can move them to another system's queue and then deliver them (sendmail -qRwhatever, etc.)
Note: I received this from a person who tried to set up a sendmail honeypot:
Also, I notice you suggest the "sendmail -qRrecipient" option
to force flushing the queue for that host, but later on you
really recommend turning off the ETRN option of extended SMTP.
Well, I turned off etrn, and now the queue flush you recommend
won't work. I'm using sendmail 8.12.1. So I flush the queue
with "sendmail -q -v".
I am not familiar with other popular MTAs, such as procmail, so I can give no advice on these. I assume they are no less simple to use. Your goal is to create a system that accepts relay messages but delivers only those you wish to deliver. Typically these would be relay test messages. When you deliver a relay test you falsely identify your system as a relay. You can expect spam soon.
What else?
I believe part of the key to defeating relay spam is to make the internet more hostile and more complex to the spammers. The complexity I seek is in the response of internet email systems to relay test messages. Running sendmail -bd is simply an example of a way to accomplish this. Creating decoy systems add a fourth category email state: the system appears to be a relay but is not a relay. Any other way to do the same thing is just as good, and the more ways there are the more difficult it is for a spammer to distinguish between true open relays and decoy systems.
Sendmail systems should mis-identify their sendmail version when connection is made. They should be intentionally configured to appear to be older versions, so that the spammer cannot reject relay from systems current enough so that they can have relay rejection built in.
Key features:
The key features of the decoy approach described here are:
1. If you run a honeypot you can intercept relay test messages sent by spammers. These will give you information about how the spammers test for relays that you can get in no other way. Remember there is no magic way to test for relays and there is no stealth way to test for relays.
2. No new or special software is required. If you are using an older system you do want to bring its sendmail up to date for general security reasons. The procedures are simple to setup and to use.
3. The spammers are the targets of your decoy.
4. The internet is made more hostile to the spammer without effect on legitimate users.
5. The relay tester identifies himself to you. You set up the decoy; he sends the test message. You do nothing which invades anyone's system.
6. Changing the IP numbers of systems disrupts the spammers map of the internet.
7. Changing open relays to decoys (rather than changing them to relay rejecters) allows you to trap and retain spam and to complain about the spam as theft of service.
8. Changing open relays which have been exploited to decoy relays partially compensates for the harm caused to others while they were being exploited.
9. If a spammer finds he has been decoyed several times by systems in your IP block he may finally give up on trying to use any system in your IP block. You may potentially protect your whole domain against relay tests and relay abuse by implementing only a few decoys.
10. A relay decoy uses the simplest filtering possible: email that comes to it it is spam or is spam related. You do not have to analyze headers, you do not have to analyze contents, you do not have to count recipients. The spammer has done the filtering for you. He's the only one who will try to relay through your system (he knows your system simply as an IP number in a block he is testing). Remember: the decoy is set up on a system that has no legitimate email function.
11. (Not mentioned above) When you characterize a relay test message you can pass its description on to any decoy allies you have so that they can configure their decoys to pass the test message almost instantly if they are tested. You pass relay test messages so that the spammer will conclude the system is an open relay.
DCC (Distributed Checksum *************)
I've not done it but a more powerful honeypot could probably be created using the DCC idea. See the link for further information.
Distributed Checksum *************
A final word:
Spam fighters should remember Bernard Baruch's observation: "To the man with a hammer everything looks like a nail." In the anti-spam context this can be taken as a caution against trying to fight spam with computer tools alone simply because it is computer tools you have. One good criminal or civil decision against one spammer can give pause to all spammers, or at least drive them offshore. One good new federal law can almost destroy them. In addition to doing what you can using the computers and the internet please also do whatever you can to bring the criminal and civil justice systems to bear on these individuals and organization and to educate your legislators about the nature and the magnitude of this problem. It is very possible that your congressman has a computer staff, and that someone on that staff is strongly anti-spam. This person is your ally.
I wish you well.
Brad Spencer
Note: I have been wrong more than once. If you see an error in anything above I'd be grateful if you would take the time to show me my error. If I have been unclear feel free to ask, particularly if your reason for asking is that you are interested in trying this technique. If you try these techniques and make an improvement in what is described above I'd be glad to add a link here to your page describing the improvement. The same holds true for techniques for creating decoys using mail transfer agents other than sendmail. Note also that there are sendmail experts in the world; I am not one of them. You would fare better if you consulted with one of them if you have questions touching on the intricacies of sendmail.
Thank you for reading this. I hope you will use the information and ideas to help eliminate relay spam..
Honeypot in photo by: Rita Spencer
Photo by: Rita Spencer
Last modified 13-Feb-2002
Thank you, I couldn't hit the site either. I'll save the transcript and pour over it later, I did scan over it briefly and it looks great, appreciate you sharing!
Thanks!
TC
Thanks !
Interesting reading !
good post guus.
So, did anyone sit this up, and if so, was it working? Catched you some spammers?