Slashdot Mirror

← Back to Stories (view on slashdot.org)

When Spammers Attack?

Posted by Cliff on from the find-your-closest-flame-thrower dept.

Gothmolly asks: "After reading the recent spate of spam and anti-spam articles here on Slashdot, I decided to beef up the anti-spam security on my own domain. I run my own domain and mail server, running Qmail, along with rblsmptd. Mail that passes this gets hit with Spamassassin However, one particular spamhaus, Clickformail has particularly nasty servers, they try at least 2 SMTP connects/second, and I suspect that's only limited by my 384k DSL pipe. The impact on my box was non-zero, to say the least. I ended up putting a packet filter on their class C netblock to stop the barrage of log messages and increase in load (from 0.05 normal to 0.15). Has anyone else experienced such determined spammers, and what is the best way around it?"

16 comments

  1. Tarpitting by m0rph3us0 · · Score: 3, Insightful

    Just install the Qmail tarpitting patch, also you might want to look at rate limiting on at the firewall level to limit the amount of incoming connections per second from a given IP. In reality this is just a like a DoS attack against any other service.

  2. Not much todo... by cyb97 · · Score: 3, Interesting

    In the case of serious spamhouses (if they can be called 'serious') there isn't much one can do...
    If linespeed/cpu-load is such a problem that you need to block it on a higher level than application, go for packetfiltering (which you've done). I'd guess the next step would be blocking them at router-level, preferably on the other side of that 384k line... probably impossible as I guess it's an xDSL line from somebody who doesn't provide that kind of service?
    You could try hitting their ISPs abuse@, but it usually turns up blank or 'we already know and don't care' reply...

  3. Off topic, but still.. by Cpyder · · Score: 3, Informative
    Can't the editors remove the link+name of the spammer? I think it's best we don't give them any hits, as this will encourage them to continue their nasty business.

    Altough it would be nice to slashdot them off the net, off course :)

    1. Re:Off topic, but still.. by orangesquid · · Score: 3, Informative

      Just subscribe gil@clickformail.com and sales@clickformail.com to as many spam lists as you can find. In fact, see if you can get them on their own lists! Not that I'm advocating eye-for-an-eye, spam-for-a-spam, but...

      Not that I'm suggesting anything, of course.
      And---why not just block incoming TCP connections on port 25 from their subnet, rather than blocking their whole subnet (or is this what oyu did, and you were just vague?) (or does your firewall not support this?)

      --
      --TheOrangeSquid Is it any wonder things seem so awry? We swim in a sea of confusion and don't have to think to survive
  4. What's wrong with the packet filter? by yeti+(dn) · · Score: 3, Insightful

    Properly set up packet filter should consume negligible amount of CPU. Drop the packets, they don't deserve any ICMP response. Pretend you simply don't exist (for their domain).

    --
    Life is the slowest way to death.
  5. Court by Anonymous Coward · · Score: 0

    I'd go to court and try to get a restraining order against them that forbids them from attempting to send mail to your domain.

  6. Don't fool around! Hit 'em hard! by spoonist · · Score: 5, Interesting

    I dunno dude, but it sounds to me like you're the victim of a Denial of Service (DoS) attack. If I were you I would document each and every single occurance (time, size, IP addresses, etc) and attach a dollar value to each occurance (time spent, harddrive space filled up, bandwidth filled up, down time, new equipment bought to counter the threat, etc).

    Then give a call to the U. S. Secret Service Electronic Crimes Branch or the FBI National Computer Crime Squad or the National Infrastructure Protection Center.

    Note that each of these organizations has a dollar amount threshold. If the crime doesn't break the threshold (e.g. over $10k or something (I don't know the actual numbers, but I'm sure they can be found here)), then they won't investigate the crime.

  7. Simplest solution by njdj · · Score: 3, Informative

    Assuming you're running Linux with a 2.4 kernel or later, adding this to your iptables rules is probably the most effective:

    iptables -A INPUT -s 204.1.28.0/24 -j DROP

    Put it just before the first rule that accepts or logs anything. (I haven't tried it yet - if you're an iptables expert and see a mistake, please post a correction).

    1. Re:Simplest solution by muonzoo · · Score: 3, Interesting

      I think all the people proposing a rate limited iptables / packet filter solution are on the right track, but missing a bigger part of the problem
      .

      You want to be able to stop those packets from hitting your 384Kbps xDSL line. Otherwise, you are not only losing processing time dealing with the junk; you are having to give up a fraction of your bandwidth too.

      Admittedly, it isn't a large chunk of your bandwidth. Likely around 3/4 - 1.0 %. However, it won't take much to get out of control.

      This is where the real problem lies, and; xDSL service providers seldom are willing to route or modify the feeds they send clients. In fact, they frequently don't have the infrastructure for it at all.

  8. Delaying responses by DarkDust · · Score: 3, Insightful

    Well, one way to slow them down (and thus make those spam-bursts more bandwidth/load friendly to your server) is to delay the server responses: with Postfix you can delay those error messages like this:

    smtpd_error_sleep_time = 30

    which would take 30 seconds from the wrong/blocked SMTP command until Postfix gives an error message. With this easy measure you can seriously slow down those spam-bursts, especially when they try to send several spam mails within the same SMTP session.

    It's only disturbing when you try to debug your SMTP with telnet, but that's ok :-)

  9. Tantalus by ChiefArcher · · Score: 5, Informative

    I wrote a sendmail milter called Tantalus that stops spammers from guessing usernames... Basicly if they hit X wrong email addresses on your SMTP server in X amount of time, they are blocked for X number of minutes... It's really fun to watch them guess that 100 or so names they guess and hit the Xth wrong one and just be shut out... :)
    It basicly picks up where spamassassin and RBL stops.... It's kinda fun to watch it in debug mode.... and it's free.

    http://www.linuxmailmanager.com/tantalus.html

    ChiefArcher

  10. A solution.. by Anonymous Coward · · Score: 0

    DDOS!

    Yes I am just kidding.

  11. Re:Don't fool around! Hit 'em hard! by Anonymous Coward · · Score: 0
    "...attach a dollar value.. hard drive space ... "

    Anyone have a $10,000 5MB disk drive available for my log files?

  12. popfile... by zonker · · Score: 0

    popfile, it won't end your woes but it will help your users out...

    --

    Large print giveth, and the small print taketh away

  13. Five Days by Sir+Tristam · · Score: 2
    ClickForMail was spamming me for five days. When I received the first, I noted that they weren't using open relays/proxies, had a valid web presence, and seemed to be trying to be as reputable as it's possible for a spammer to be. So I sent my standard stop-it form letter to a standard set of addresses (abuse@, postmaster@, root@, etc. for the web site and mail server).

    Three days later I was still receiving from them, so I tracerouted and complained to the mail server's upstream provider (level3.net abuse). The next day I received another spam from them, but a different mail server. So I tracerouted that and complained to that mail server's upstream provider (bluehornet.com spamcomplaints).

    And that's the last I heard from ClickForMail since May 21 this year. So it seems to be possible, if you complain loudly enough, to turn the flow off at its source. If you do have to go to upstreams, make sure to mention (as somebody else has done) that they are effectively performing a DoS on your system.

    Chris Beckenbach