Slashdot Mirror
Spamholes Fighting Spammers
mike9010 writes "A person named I)ruid has come up with an ingenious way to combat those spammers. His program, spamhole, creates a false 'open relay' that the spammer thinks he/she can send messages through. The messages then get sent nowhere, and the spammer has no idea.
"spamhole is an open project. Hopefully, through user's and developer's contributions, we will amass a collection of spamhole implementations spanning all commonly used platforms, programming languages, etc. Ease of configuration and use are the primary objectives, for the easier to use by the non-techical layperson the implementations are, the more widely adopted and used spamhole will become.""
As the article says
When an SMTP client connects to our spamhole, we note the number of times it has connected before. If this number is below a configurable threshold, we simply redirect it's connection through the spamhole to a real SMTP server and allow it an unmodified session. This provides for any potential 'test' email the spammer may attempt to send through the 'open relay' to verify successful delivery to successfuly pass through the system and be delivered. Many spammers do this to validate their open relays prior to attempting bulk mailings. The downside to this is that a few SPAM emails may actually be delivered by your spamhole. Such is the price to pay for tricking the spammer into continued use of your 'open relay'.
So it's not quite just a dumb smtp receiver, but acts as a real one until the spam starts being sent.
OpenBSD's spamd actually tarpits the spammer down, then after a looooong held connection sends a 450 (by default) to the spammer to have the spammer-machine retry. I have it running with various autoupdated blackhole lists and very little spam sees my server anymore.
Trolling is a art,
It won't work.
On a small scale it has no impact.
On a large scale the spammer will just send a few 'test' messages through your system and move on to the next. With a million spamholes, a spammer can send a million mails at the least. Great.
Also, you'll get yourself blocklisted by every major DNSBL very soon. They scan for open relays too...
This is your sig. There are thousands more, but this one is yours.
Slashdot, on the cutting edge of last year.
Don't they test that the relayed mail is actually delivered? ORDB does:
http://www.ordb.org/faq/#mail_accepted
Any tester that doesn't isn't very intelligent...
Trouble making decisions? Just flip for it.
> only until it all goes offshore.
It already is. I live in the UK and the majority of junk emails I receive come from the US, or contain 'offers' from US based companies.
The RBL's might, but having worked for some ISP's (*koff*@home*koff*), I know that they only scan for the open port on 25, they don't actually bother to check the SMTP functionality of the relay.
"Kinky sex involves the use of duck feathers. Perverted sex involves the whole duck." - Lewis Grizzard
His program delivers the first relay attempt to fool the spammer. That means that an open relay test might identify your machine as a spam source.
That may not be a big deal since you wouldn't run this on your actual email server anyway. Most blackholes only list specific IP's and not entire blocks (at least the reliable blackholes don't list entire blocks) just because one IP in the range runs an open relay.
"We make our world significant by the courage of our questions and by the depth of our answers." Carl Sagan
Well, here's what I've done and it hasn't gotten me on any black lists for running an open relay because I don't.
First, my mailserver runs OpenBSD, this allows me to use pf for my port filtering software. Then each user on the server has a copy of CRM114 installed. This is a very powerful and extremely accurate bayesian classifier. I've gotten 1 piece of spam in the last three months, 0 false positives and it blocks about 150 pieces of spam a day (for my account alone).
For each piece of mail that I receive, the relays involved are entered into relaydb. This wonderful little program logs each mail relay listed in the message. When a relay has 3 times as many bad messages as good messages it is added to the black list. Because I'm using pf, this blacklist is updated in real time to the mail server's pf configuration, which causes spamming hosts to be sent to the tar pits.
I'd estimate the total accuracy rate (defined as non-Type I and non-Type II errors) to be somewhere around 99.95%. User interaction is zero for most of the time, I've got a nice corpus that I train the accounts with. On the off hand that there is an error the user mails the message to themselves and it gets fixed.
So, to summarize:
This idea won't work, you'll get your host marked as an open relay.
This is what I did to kill spam and it does work.
My Slashdot account is old enough to drink...
It lets you set up a temporary forwarding address, which can be very useful for those "free registration" things that just scream "SPAM!".
Some ISPs are very vigilant. They have a take-no-shit attitude towards SPAM and/or hacking. They'll actively watch for it, shut people down, respond to abuse complaints, etc. Some just don't give a fuck, and won't stop it unless it interferes with their network or someone comes after them with a big enough stick.
So just because you've dealt with an ISP that is in the "don't give a shit" category, doesn't mean there aren't other ones that will be very responsive.
This system will only increase the number of open relays out there.
/24. It was horrible, we have hundreds of customers who could not get email from us or their clients.
Plus, for some of the more nazi-esque spam block lists, it can cause MAJOR havoc for your network. I can tell you that this will not be implemented on our network. We've delt with this already... One computer on our network had an open relay for a couple of days, and it caused *.rr.com (road runner cable, HUGE ISP on the right coast) to block ALL MAIL from our
And it was pulling teeth to get us off of that block list. Send email, get response "contact your ISP", sent email explaining we were the ISP, got email "contact your ISP", sent email madly declaring that we can fix it if they'd tell us what was wrong, but with more than 100 computers in that IP range, it was kind of hard to tell who was in trouble, got email "contact your ISP"... etc.
I'm NOT going to put anything on the network that deliberately sends spam, or even looks like an open relay. My business is too important to me.
Thanks, but, no thanks.
~Will
sig?
Just last weekend... this mea culpa might save someone in /. land some pain.
/. folks, I'd like to pass along some tips based on my experience.
Had a form.pl script handling all form submissions on our web site. The form submitted its info via sendmail, as well as logging to text files. While the address checking was pretty robust, someone figured out how to overload the contents in a manner that fooled the sendmail into thinking that the contents contained BCC: data.
Fortunately I caught it within about five minutes, thanks to the fact that all submissions are CC:'d to a real address, thus starting a flood of mail. I saw the classic pattern: a test message, a couple revisions, a final draft test message, then the flood of "real" messages. Since I saw it start, I was able to shut down the script (I just killed the Execute permissions).
After the initial test messages, I saw submissions from dozens of different IPs - I assume zombied PCs. It seems that the zombies were programmed to relay form POST submissions, instead of trying to relay mail directly. Smart, since that puts the mail load on a fast server, not a slow dialup PC.
But the really interesting thing was, even after shutting down the script, the flood of submissions continued. I tweaked the form.pl to bounce the requests to another page but the bounce was never followed - indicating to me that the program didn't bother to check the server response to the submission, even for a 404 or 302 response! This continued for around 14 hours, at a rate of about 20-40 hits per minute. Based on the first messages that got through, several hundred addresses were included in each BCC: field.
Suddenly at about T+14 hours, it simply stopped - cold. For the next several hours a few sporadic hits popped up. Haven't seen any since about T+18 hours.
Apparently the spammer assumed his script would succeed once it was successfully started (it WOULD have unless I'd been at the PC). He obviously ran through his entire mailing list "blind". I'm happy to say 13.8 of those 14 hours were wasted, preventing about 7 million spams (14 hrs, 40/minute, 200 addresses each).
As lessons learned, although I'm sure this is old news to most of the
1) The spammer used our web site's form to build his attack, but then took it to another machine. All subsequent submissions were using a POST method but not from our site's page. No surprise there, but simply checking $ENV{'HTTP_REFERER'} could have prevented 99% of this attack - if not making it pointless to begin with.
2) Sendmail can be fooled into reading BCC: addresses from information after the start of the message body. I don't understand the details, but an obvious preventative is to =~ s/bcc://gi on the message before sendmail gets it. Probably wouldn't hurt to do the same to To: and CC:.
3) Sendmail can be fooled into sending encoded text from an otherwise text-only form. Filter out "Content-Type:" or "Content-Transfer-Encoding:" or "multipart/mixed" or "text/html" before sendmail gets it.
4) If you're watching for abuse, don't rely on looking for multiple hits from one IP - it seems that once you become a target you will likely get a distributed attack.
5) Consider replacing all @ signs... do a s/@/-at-/g on all message fields before sending to sendmail (except of course whatever hard-coded To: is at the start of the message). If all other measures fail, at least you won't get blacklisted, although you might get 7 million "undeliverable" replies.
--Brandon / Split Infinity Music
try Enkoder (also available as an OS X app), which converts your mailto: link to a javascript thingy which works correctly but cannot be read by bots. It's free.
Science fiction for grown-ups...
Now you have a really popular tricksy and you have 50,000 spamholes on the internet. This will delivery 50,000 X 2 free test emails. Why not just use that free 100,000 emails to deliver spam instead.
Because to send each of those two 'free' emails from each of the 50,000 spam holes, you have to bring up 50,000 separate SMTP connections and send the email text 50,000 times, thus completely maxing out your connection. This is not the way spammers want to work.
Instead, they find high bandwidth open relays, and send a few spams with huge To: lists. It is the open relay which then multiplexes the spams to the multitude of recipients, not the spammer.
To summarize, the 2 (or however many, as long as it remains a small number) 'free' emails permitted by spam hole will be of very little use to spammers, since to reach millions of recipients, they will have to connect to thousands of spam holes, which is too slow to be economical. Spam hole will not create a new spam problem in itself. Whether it will cure the present spam problem is another matter.
Tubal-Cain smokes the white owl.
I've written before about writing a fake formmail. Right now I've got my web server set up so that all requests for formmail (m/formmail/i) get directed to the script; as you can see, I still get hit about once or twice a week. I'd really like to figure out how to tarpit them, but I'm not sure I can do that on a running webserver.
Carousel is a lie!
Google for 'honeypot' or 'proxypot.' In fact, Security Focus ran a series of comprehensive articles on honeypots, one of which is here. There's also a huge web site devoted to nothing but honeypots at this link.
Proxypots are a variation of the honeypot idea. A proxypot pretends to be an open proxy server which, instead of actually passing traffic sent to it, simply logs what's going on and sends the actual traffic to a specific destination specified by the proxypot operator. This can be Dave Null's in-box or anywhere else said operator wants.
Details of proxypots may be found here, and here, just to name a couple.
Keep the peace(es).
Bruce Lane, KC7GR,
Blue Feather Technologies
I have a web-form and use a simple PHP script that is hard coded to go through my mail server and my mail server requires a valid POP3 login from the username you plan to send e-mails with prior to being able to send e-mails with it. You get a short window of time once validated and even then you must send the e-mails from the same IP that validated the user name. So you can't figure out what e-mail address is being used, send a message from the form and then spam away with that e-mail address remotely.
And on top of that the function that sends the e-mail is seperate of the pop3 function so even if you managed to figure out how the script works, you still couldn't abuse it in any way shape or form. All the security depends on the mail server itself.
And then from my form the script that uses the SMTP/POP3 script can only send messages to a single hardcoded address. It also can't do BCC or CC's. I'm considering doing an anonymous e-mailer with it but I need to work out details before jumping off that cliff.
"that was an extra the customer had to pay for"
That should be an extra the customer has to pay to get ACCESS to. You should be logging regardless. It's just diskspace and if the customer isn't paying you can clear the old logs on a X day basis if nothing exciting is happening.
Setting up a secure form mailer is rediculously easy. And with PHP I can use my script anywhere. I don't need to set up funky permissions. I don't know what formmail is doing that could possibly allow it to be hacked in such a way that an attacker couldn't just go right to the mail server and accomplish.
Currently, my log analizer is custom made and logs all formmail attempts sorted by IP. It used to be pretty bad. So much so that I reported a number of people. That's died down now though since they've finally realized I don't have formmail on my server in any form. I don't even have Perl installed on my server anymore. PHP only.
Ben
Work Safe Porn
1. How to identify a spam (People are proven to be far better at pattern recognition than Bayesian models).
2. How not to click on a spam.
3. How to delete a spam.
Add to that 4. How not to give your email address to spammers.
We have to protect our email addresses. The email-obscuring feature on Slashdot is one way to do so. Another is to teach users that not all websites which request your email aren't going to use it to send spam.
For further reading, "Why Am I Getting All This Spam?"
No, that's a terrible idea. I'd wager 99% of the {From,Reply-To,Return-Path} email addresses in spam are fake. I know this because my address has been used as the From: address in several spam mailings. I typically find out about it when I get a deluge of NDNs from yahoo.co.kr or something. Encouraging bounces like this would only increase the proportion of SMTP bandwidth used up in relation to spam. It's far better to just /dev/null the spam than to bounce it.
Gates' Law: Every 18 months, the speed of software halves.