Protect sendmail from DoS

Rhugga Harper rhugga at gmail.com
Mon Nov 7 20:57:32 UTC 2005


A trick I used back when I was working for an anti-spam/mail filtering
company is to write monitoring scripts that check your mail servers for
whatever anonmaly you desire, then using expect, update your access control
lists on your border routers (to block that IP). However, the larger your
access list, the more overhead its costs to route each packet. (also, doing
it this way, if the spammer has a boatload of IP's, which most serious spam
organizations do, they can do a quasi-DOS attack against your routers now.
However, its hard to determine if you are using access lists from their
point of view)

Your scripts can trigger a block on any logable event: ie: # of messages
sent from IP, content of messages sent from IP, etc...

If your blessed with over-sized border routers, this may be an option for
you. Of course, if you or your customers don't deal with businesses in
China, just block every subnet orignating there. (Check the anti-spam sites,
they keep up to date blacklists that will have all this information.
Eliminating China eliminates a very significant portion of spam) Of course,
I'm basing this on my experience 3 years ago, so things could have changed.

-CC


On 11/7/05, Ed Wilts <ewilts at ewilts.org> wrote:
>
> On Tue, Nov 01, 2005 at 08:08:13PM -0500, Devon Harding wrote:
> > Is there some way of using something like IPTABLES to block if it sees a
> > certain amount of connections from a particualar IP? I know Ciphertrust
> > Ironmail does this.
>
> The one you can't easily protect yourself from happens if somebody does
> a wide-area spam using one of your domain names. The bounces come back
> from a large amount of perfectly legitimate servers that you can't (and
> shouldn't) block. Those bouncers were victims of the spams, as are you.
>
> I've seen tens of thousands of bounce messages come in a very short
> period of time, taking out both of my mail servers. It wasn't a pretty
> sight to deal with at 1am.
>
> As somebody else said, if somebody wants you dead, you'll be dead unless
> you have deep pockets to protect yourself from this.
>
> .../Ed
>
> >
> > On 11/1/05, Steven Jones <Steven.Jones at vuw.ac.nz> wrote:
> > >
> > > Sendmail has some protection in terms of load limiting, these are a
> bit
> > > high so you can set them lower so the server recovers sooner. This
> will
> > > save your server but in effect it allows DoS sooner.
> > >
> > > Possibly you do not understand what a DoS is. DoS is a function of
> your
> > > attacker overloading your network or server's capacity to handle
> network
> > > traffic sent at it.
> > >
> > > These days unless you are a big organisation with huge pipes, big
> > > multiple servers and deep pockets, and someone wants you dead, your
> > > dead.
> > >
> > > If someone wants to take your server out they can, it is simply a
> matter
> > > of logistics, they control 30 or 300 or 3000 or 30000 spam drones of
> > > hacked broadband connections and the volume these generate is amazing.
> > >
> > > I was Dos'd a while back, I was sent 5+gig of volume in 2~3 minutes,
> my
> > > 512k cable modem could not cope so in effect the DoS happened at the
> > > ISP's end of my pipe, totally outside of my control.
> > >
> > > Modern machines, even desktop ones should be able to handle a lot of
> > > mail, if you are having issues with DoS's then maybe it is something
> > > else.
> > >
> > > Regards
> > >
> > > Thing
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Devon Harding [mailto:devonharding at gmail.com]
> > > Sent: Wednesday, 2 November 2005 10:43 a.m.
> > > To: General Red Hat Linux discussion list
> > > Subject: Protect sendmail from DoS
> > >
> > > How can I protect my sendmail server against DoS attacks?
>
> --
> Ed Wilts, RHCE
> Mounds View, MN, USA
> mailto:ewilts at ewilts.org
> Member #1, Red Hat Community Ambassador Program
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>



More information about the redhat-list mailing list