[ale] Spam fighting strategies

Thu Oct 4 16:46:06 EDT 2007

On Thu, 2007-10-04 at 16:27 -0400, Jeff Lightner wrote:
> Thanks guys.
> 
> We actually implemented the DNS MX change yesterday because as you say
> it was trivial to do so.   We saw an immediate drop off.

> However, today we see it building up again since noon so we're looking
> into other options.   In case it helps anyone - One thing done today was
> to split our back end and front end so that the delay only affects
> inbound from the internet and not outbound to the internet.

	If you are using sendmail with greet_pause to do this, you can do this
in your access database like this:

GreetPause:localhost            0
GreetPause:130.205              0
GreetPause:66.23.227            0
GreetPause:IPv6:2001:4830:3000  0
GreetPause:wittsend.com         0
GreetPause:ibm.com              0
GreetPause:iss.net              0

	Just define the addresses or domains you want and the delay time (0 for
no delay).

> I've passed this information on to one of my coworkers who has been
> tasked with looking at putting the Sendmail/Linux server together.   

	Mike

> -----Original Message-----
> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of
> Michael H. Warfield
> Sent: Thursday, October 04, 2007 3:14 PM
> To: transam at verysecurelinux.com; Atlanta Linux Enthusiasts
> Cc: mhw at WittsEnd.com
> Subject: Re: [ale] Spam fighting strategies
> 
> Hey Bob,
> 
> On Thu, 2007-10-04 at 14:50 -0400, Bob Toxen wrote:
> > On Wed, Oct 03, 2007 at 03:53:18PM -0400, Jeff Lightner wrote:
> > > The other night in the AUUG meeting it was mentioned  by one person
> that
> > > they had turned on a "read delay" in email (Postfix I think) and
> that
> > > this had eliminated about 80% of the spam because the bots would
> > > disconnect.   
> 
> > > Unfortunately I didn't have a chance to follow up then but mentioned
> it
> > > to our Exchange admin because they've been fighting an increase seen
> > > recently in connection attempts.  It sounds as if Exchange can't do
> this
> > > natively.
> 
> > > I'm wondering if anyone has done this on Postfix/Sendmail or some
> other
> > > OSS MTA and would be willing to provide details?   
> 
> > > My coworker found something called "Greeting Delay" that sounds like
> > > what I heard as "Read Delay" so it may be this but apparently that
> has a
> > > problem with people that do call back to check whether email is
> coming
> > > from a valid site.
> > Yes, the person mentioning "read delay" probably means the "Greeting
> > Delay" technique.  Yes, this is quite effective.  Most spammers will
> > assume that there is something wrong with the recipient, drop the
> > connection, and go on to the next as being more efficient.
> 
> 	I was that person and I mentioned Greet Delay (actually, it's
> "greet_pause" in the sendmail.mc configuration) in sendmail.
> 
> > Most spammers also blast their entire dialog and message, once the
> TCP/IP
> > connection is established, without bothering to follow the proper SMTP
> > protocol of waiting for a response to each phase before going on to
> > the next.  A spam filter technique is to detect such output before our
> > side sends its reply and then treating the email as spam (because it's
> > violating SMTP specifications.)
> 
> 	Actually, Greet Delay implements this as well.  While sendmail
> is
> waiting out the time period before it sends its banner, if data comes
> down the channel, it dumps the connection right then and there.  So you
> get both effects...  Some spammers give up and disconnect, and others
> force the data down the connection and get disconnected.
> 
> 	An extension to the "Greet Delay" is the tarpit option.  With a
> tarpit
> option, each command "EHLO, RCTP, FROM, etc" in smtp is delayed slowing
> down the initial handshake up to the DATA part.  I haven't tried this,
> and I don't believe it's in stock sendmail or postfix, but some people
> have claimed success.  I'm not sure if I would see much more success
> over the simple Delay Greet option.
> 
> 	I had not heard that there was a problem with people that do
> call back
> to check whether email is coming from a valid side or not but that's
> highly broken behavior since the outgoing mail server may be different
> from the incoming mail server and may, in fact, legitimately not
> reachable.  IAC, there is a whitelisting feature in Delay Greet and you
> can set those legitimate sites to not get a delay.  In fact, you want to
> do this for all your internal addresses, to avoid unduly delaying them.
> So, it's an easy fix for their broken behavior.
> 
> > These two techniques currently are being added to my SpamCracker(tm)
> > spam filter that I offer.  (It happily will work in front of Exchange
> > as well as any other mail server.)
> > 
> > > Also he found doing bogus MX records in DNS - the idea being you put
> > > your first and final MX records to dead IPs as most spam bots only
> check
> > > the first or final and not the intervening real ones.   Has anyone
> tried
> > > this and if so what results did you have?
> > This also is quite effective and trivial to implement with no loss of
> > legitimate email.
> 
> 	Yup, another technique I've used successfully.
> 
> > > Essentially we're looking at putting in a Linux server as if it were
> an
> > > SMTP gateway to the Exchange server which will continue to be the
> > > primary mail server for the company.   Any other ideas (other than
> > > getting rid of Exchange which won't happen) would be appreciated.
> > While those techniques will eliminate a substantial percentage of
> spam,
> > they will not solve the problem.  The solution requires a good spam
> > filter such as ours that has 12 additional filtering steps, including
> > a number of anti-spoofing steps and steps that detect senders trying
> > to evade spam filtering techinques.  It blocks about 97% of spam with
> > a very low false-positive rate.
> 
> 	Check out the latest version of MailScanner,
> www.mailscanner.info.  It
> includes techniques for watermarking outbound messages, bayesian
> filtering, CRM114, SpamAssassin, and, now, a dynamic list of phishing
> sites as well as hooks for a variety of AV products.  Drops in on
> Sendmail or Postfix with or without the above techniques.
> 
> > Bob Toxen
> > bob at verysecurelinux.com               [Please use for email to me]
> > http://www.verysecurelinux.com        [Network&Linux/Unix security
> consulting]
> > http://www.realworldlinuxsecurity.com [My book:"Real World Linux
> Security 2/e"]
> > Quality Linux & UNIX security and SysAdmin & software consulting since
> 1990.
> > Quality spam and virus filters.
> > 
> > "Microsoft: Unsafe at any clock speed!"
> >    -- Bob Toxen 10/03/2002
> 
> 	Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part