[ale] Spam fighting strategies

Thu Oct 4 16:28:10 EDT 2007

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.

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

-----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!
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------