Horiffic SPAM

Horiffic SPAM

[Richard B. Johnson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 846 bytes --]

Hello all,

I took root@chaos.analogic.com off the linux-kernel list
for a few days so I can trap the spammers and write their
addresses to `ipchains`. I have been getting approximately
12,000 email messages per day on that system, making it
impossible to use. It's all about the servers spreading
the M$ email virus with the phony message to update to the
latest security patches, plus a few hundred "penis-patch" spam
messages per hour.

Anyway, I am trying to fight back. I have attached a
tar-file which contains the source-code I use to create
anti-spam entries for `ipchains`. It also automatically
ties up the spammers and sends them an email message
asking them to stop, plus it logs the connections.

Cheers,

Richard B. Johnson
Project Engineer
Analogic Corporation
Penguin : Linux version 2.2.15 on an i586 machine (330.14 BogoMips).


[-- Attachment #2: Type: APPLICATION/x-gzip, Size: 17572 bytes --]

Re: Horiffic SPAM

[Andrea Arcangeli]

On Tue, Sep 23, 2003 at 02:11:59PM -0400, Richard B. Johnson wrote:
> Hello all,
> 
> I took root@chaos.analogic.com off the linux-kernel list
> for a few days so I can trap the spammers and write their
> addresses to `ipchains`. I have been getting approximately
> 12,000 email messages per day on that system, making it
> impossible to use. It's all about the servers spreading
> the M$ email virus with the phony message to update to the

the baesyan algorithm learnt about them pretty quickly, so they don't
hurt me anymore (besides some wasted bandwidth).

I doubt answerning those messages will do any good besides generating
more traffic, but I don't know the detail of the virus so I could be
wrong.

Andrea - If you prefer relying on open source software, check these links:
	    rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
	    http://www.cobite.com/cvsps/
	    svn://svn.kernel.org/linux-2.[46]/trunk

Re: Horiffic SPAM

[Matt Heler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ive been living in a mail hole theese past few years.. Where does one get this 
baesyan algorithm ?? 

Matt H.

On Tuesday 23 September 2003 11:36 am, Andrea Arcangeli wrote:
> On Tue, Sep 23, 2003 at 02:11:59PM -0400, Richard B. Johnson wrote:
> > Hello all,
> >
> > I took root@chaos.analogic.com off the linux-kernel list
> > for a few days so I can trap the spammers and write their
> > addresses to `ipchains`. I have been getting approximately
> > 12,000 email messages per day on that system, making it
> > impossible to use. It's all about the servers spreading
> > the M$ email virus with the phony message to update to the
>
> the baesyan algorithm learnt about them pretty quickly, so they don't
> hurt me anymore (besides some wasted bandwidth).
>
> I doubt answerning those messages will do any good besides generating
> more traffic, but I don't know the detail of the virus so I could be
> wrong.
>
> Andrea - If you prefer relying on open source software, check these links:
> 	    rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
> 	    http://www.cobite.com/cvsps/
> 	    svn://svn.kernel.org/linux-2.[46]/trunk
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/cJaTleY/n9G/oZ8RAoPjAKCHtX9SsUNSjI+MsXlKwVbxRP5+SwCeIIHB
SdEfk80hkuGGV1tj3bnU5ns=
=+yr7
-----END PGP SIGNATURE-----

offtopic (Re: Horiffic SPAM)

[Andrea Arcangeli]

On Tue, Sep 23, 2003 at 11:53:04AM -0700, Matt Heler wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ive been living in a mail hole theese past few years.. Where does one get this 
> baesyan algorithm ?? 

www.spamassassin.org

~/bin/Mail-SpamAssassin-2.60/sa-learn --mbox --spam ~/mail/spam
~/bin/Mail-SpamAssassin-2.60/sa-learn --mbox --spam ~/mail/spam-bad

spam-bad is differentiated because it gets >15 marks, so it gets deleted
immediatly after learning. (see the docs in the package)

but make sure to teach the baesyan about your regular email first, the
number of "ham" must be >= "spam" or your risk losing legitmate email. I
use my inbox as "ham" (that's around 10000 messages).

this is the status of my db

0.000          0        688          0  non-token data: nspam
0.000          0       9722          0  non-token data: nham

see now what it returns for these >100k viruses (Bayesian spam
probability is 99 to 100%)

-------- cut and paste begin ---------
 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.1 HTML_MESSAGE           BODY: HTML included in message
 1.7 HTML_RELAYING_FRAME    BODY: Frame wanted to load outside URL
 5.4 BAYES_99               BODY: Bayesian spam probability is 99 to 100%
                            [score: 1.0000]
 0.3 MIME_HTML_ONLY         BODY: Message only has text/html MIME parts
 0.1 HTML_50_60             BODY: Message is 50% to 60% HTML
 5.6 IFRAME                 BODY: IFRAME virus
 3.0 MICROSOFT_EXECUTABLE   RAW: Message includes Microsoft executable program
 0.6 MIME_HTML_NO_CHARSET   RAW: Message text in HTML without charset
 0.1 MIME_SUSPECT_NAME      RAW: MIME filename does not match content
 1.1 MIME_HTML_ONLY_MULTI   Multipart message only has text/html MIME parts

The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam.  If you wish to view
it, it may be safer to save it to a file and open it with an editor.


[-- Attachment #2: original message before SpamAssassin --]
[-- Type: message/rfc822, Encoding: 8bit, Size: 142K --]

Date: Tue, 23 Sep 2003 13:30:38 -0500
From: "microsoft net message system" <mailerrobot@america.com>
To: "network recipient" <client@yourdomain.com>
SUBJECT: Bug Advice
X-Virus-Information: Please visit http://enap.wt.net for more
information
X-Virus-Scanner: Found to be clean

[-- Autoview using lynx -dump '/tmp/mutt.html' --]

   IFRAME: [1]cid:mccexrrgkte

   Hi.
   Undeliverable to mxwxeztble@america.com
[..]
-------- cut and paste end ---------

Andrea - If you prefer relying on open source software, check these links:
	    rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
	    http://www.cobite.com/cvsps/
	    svn://svn.kernel.org/linux-2.[46]/trunk

Re: offtopic (Re: Horiffic SPAM)

[Sandy Harris]

Andrea Arcangeli wrote:

> On Tue, Sep 23, 2003 at 11:53:04AM -0700, Matt Heler wrote:
>>
>>Ive been living in a mail hole theese past few years.. Where does one get this 
>>baesyan algorithm ?? 
>  
> www.spamassassin.org

Another good tactic:

Teegrube is German for tarpit, a trap that wastes
large amounts of spammer resources at little cost
to you.

English FAQ:
http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html

Re: Horiffic SPAM

[Paul Dickson]

On Tue, 23 Sep 2003 11:53:04 -0700, Matt Heler wrote:

> Ive been living in a mail hole theese past few years.. Where does one get this 
> baesyan algorithm ?? 

Go to google.com and search "bayesian spam filter".  The first two hits
are Paul Graham's articles that started it all.  There are at least two
sourceforge.net projects in the first tens hits.

	-Paul

Re: Horiffic SPAM

[Richard B. Johnson]

On Tue, 23 Sep 2003, Andrea Arcangeli wrote:

> On Tue, Sep 23, 2003 at 02:11:59PM -0400, Richard B. Johnson wrote:
> > Hello all,
> >
> > I took root@chaos.analogic.com off the linux-kernel list
> > for a few days so I can trap the spammers and write their
> > addresses to `ipchains`. I have been getting approximately
> > 12,000 email messages per day on that system, making it
> > impossible to use. It's all about the servers spreading
> > the M$ email virus with the phony message to update to the
>
> the baesyan algorithm learnt about them pretty quickly, so they don't
> hurt me anymore (besides some wasted bandwidth).
>
> I doubt answerning those messages will do any good besides generating
> more traffic, but I don't know the detail of the virus so I could be
> wrong.
>

Well it seems that fire-walling the SPAM servers is *not* a good idea.
They are persistant, gang up, and will not give up until they are
able to deliver the mail! When I firewall them, my network traffic
ends up being continuous SYN floods as every spam-server in the
country tries to connect. It doesn't do any good to set `ipchains` to
REJECT instead of DENY. They just keep on banging on the door.

This morning, there was too much traffic on our T3 link to use
a Web crawler, so I had to un-firewall my machine to get about
100,000 (maybe more) mail messages delivered and thrown away.
Procmail is throwing away everything as fast as it can. The
hard-disk LEDs are on continuously, and it takes about 20
seconds to log in. The machine has been eating SPAM mail since
7:00 this morning and it's now 10:15. Maybe, eventually, I
will be able to use my machine again.

To give you a hint of the size of the problem, my /var/log/messages
which logs sendmail activity is about 12 Gb in length. I truncated
it to zero this morning.

Richard B. Johnson
Project Engineer
Analogic Corporation
Penguin : Linux version 2.2.20 on an i586 machine (330.14 BogoMips).

[OT] Re: Horiffic SPAM

[Helge Hafting]

Richard B. Johnson wrote:
> On Tue, 23 Sep 2003, Andrea Arcangeli wrote:
> 
> 
>>On Tue, Sep 23, 2003 at 02:11:59PM -0400, Richard B. Johnson wrote:
>>

> Well it seems that fire-walling the SPAM servers is *not* a good idea.
> They are persistant, gang up, and will not give up until they are
> able to deliver the mail! When I firewall them, my network traffic

According to standards they will give up after 5 days or so.

> ends up being continuous SYN floods as every spam-server in the
> country tries to connect. It doesn't do any good to set `ipchains` to
> REJECT instead of DENY. They just keep on banging on the door.
> 

Have you considered teergrubing them instead?  That ought to
fix the bandwith problem.  And it is not so fun for whoever has
the spam server either - either disrupting some spammers operation
or harassing some server admin into making his box un-abuseable.


Helge Hafting

Re: [OT] Re: Horiffic SPAM

[Richard B. Johnson]

On Thu, 25 Sep 2003, Helge Hafting wrote:

> Richard B. Johnson wrote:
> > On Tue, 23 Sep 2003, Andrea Arcangeli wrote:
> >
> >
> >>On Tue, Sep 23, 2003 at 02:11:59PM -0400, Richard B. Johnson wrote:
> >>
>
> > Well it seems that fire-walling the SPAM servers is *not* a good idea.
> > They are persistant, gang up, and will not give up until they are
> > able to deliver the mail! When I firewall them, my network traffic
>
> According to standards they will give up after 5 days or so.
>
> > ends up being continuous SYN floods as every spam-server in the
> > country tries to connect. It doesn't do any good to set `ipchains` to
> > REJECT instead of DENY. They just keep on banging on the door.
> >
>
> Have you considered teergrubing them instead?  That ought to
> fix the bandwith problem.  And it is not so fun for whoever has
> the spam server either - either disrupting some spammers operation
> or harassing some server admin into making his box un-abuseable.
>
>

I thought it would be easier than that. However, I did write a
program that keeps the connection open forever (until the SPAM-server
hangs up). This slows down the servers. I also thought that I could
make multiple connections to the server and never hang up, depriving
the SPAM-server of resources. However, I can't make a new connection
with the same socket (don't know why), EISCONN,  without closing the
previous.
This means that I need a new socket for each connection. I run out
of sockets before the SPAM-servers do.


> Helge Hafting
>


Richard B. Johnson
Project Engineer
Analogic Corporation
Penguin : Linux version 2.2.15 on an i586 machine (330.14 BogoMips).

Re: [OT] Re: Horiffic SPAM

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 161 bytes --]

On Thu, 25 Sep 2003 10:21:49 +0200, Helge Hafting said:

> According to standards they will give up after 5 days or so.

Methinks you forgot the smiley on here.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Toshiba Tecra S1 Battery Status

[Bernt Hansen]

Hi,

Are there any patches available to read the battery status of a Toshiba
Tecra S1 laptop (module PT831C-11UDL)?

I currently have no way to read the battery time left - and when it runs
out the system comes crashing down -- ext3 to the rescue!  

The last kernel I tried was 2.6.0-test5.

Any help would be appreciated.

TIA
Bernt
-- 
Bernt Hansen     Norang Consulting Inc.

[OT] Re: Horiffic SPAM

[Grant Miner]

Some of us want to get as much spam as possible.  Can you figure out why?

Re: Horiffic SPAM

[John Bradford]

> They are persistant, gang up, and will not give up until they are
> able to deliver the mail! When I firewall them, my network traffic
> ends up being continuous SYN floods

The ISP who supply this DSL connection have been rejecting connects to
their inbound SMTP server from unlisted IPs for ten minutes after the
initial connection attempt.  Retries after ten minutes are accepted,
and future connections are allowed immediately, unless the IP doesn't
make any connections for more than a week.

Apparently, it has reduced the volume of junk mail considerably, as
the 'virus' SMTP engines often don't bother to retry after getting a
4xx error code :-).  Obviously it delays genuine traffic coming
through that server slightly.

This may be a good solution to the problem for anyone who has control
of their own SMTP servers.

(Before anybody says that such greylisting by an ISP is irresponsible,
it's not in this case - unlike most DSL providers, they provide a real
static IP address block, (both v4 and v6), and fully configurable and
delegatable reverse DNS.  This means that there is no need to use
their SMTP server at all.  The most obvious setup is to run your own
primary SMTP server(s), and use theirs as a secondary.)

One theoretical solution to the whole junk mail problem that occurs to
me, would be for everybody to run a spoof open mail relay on port 25
of every IP under their control.  By that I mean a script that accepts
mail and claims that it will be delivered, but never delivers it.
Since the IPs running these spoof SMTP servers would never be listed
against an MX record anywhere, no genuine mail would go to them, only
junk.

Anybody sending junk mail via open relays they'd discovered via port
scanning would probably see a >99% reduction in the mails that
actually got through.  Presumably the companies who pay for the bulk
mail delivery would learn that their mails were not getting through,
and the business would cease to be profitable.

The only junk mail left would be from identifyable sources which is
_much_ easier to deal with.

Of course IPv6 will bring some of these benefits as hopefully ISPs
will assign static IP allocations, rather than dynamic ones.

John.

Re: Horiffic SPAM

[David Lang]

if you want to block mail you need to have your MTA return a 500 series
error code when it gets a connection from that IP address, otherwise the
sending MTA will just retry later, resulting in the problem described.

David Lang

 On Wed, 24 Sep 2003, John Bradford wrote:

> Date: Wed, 24 Sep 2003 16:08:18 +0100
> From: John Bradford <john@grabjohn.com>
> To: rjohnson@analogic.com
> Cc: andrea@suse.de, linux-kernel@vger.kernel.org
> Subject: Re: Horiffic SPAM
>
> > They are persistant, gang up, and will not give up until they are
> > able to deliver the mail! When I firewall them, my network traffic
> > ends up being continuous SYN floods
>
> The ISP who supply this DSL connection have been rejecting connects to
> their inbound SMTP server from unlisted IPs for ten minutes after the
> initial connection attempt.  Retries after ten minutes are accepted,
> and future connections are allowed immediately, unless the IP doesn't
> make any connections for more than a week.
>
> Apparently, it has reduced the volume of junk mail considerably, as
> the 'virus' SMTP engines often don't bother to retry after getting a
> 4xx error code :-).  Obviously it delays genuine traffic coming
> through that server slightly.
>
> This may be a good solution to the problem for anyone who has control
> of their own SMTP servers.
>
> (Before anybody says that such greylisting by an ISP is irresponsible,
> it's not in this case - unlike most DSL providers, they provide a real
> static IP address block, (both v4 and v6), and fully configurable and
> delegatable reverse DNS.  This means that there is no need to use
> their SMTP server at all.  The most obvious setup is to run your own
> primary SMTP server(s), and use theirs as a secondary.)
>
> One theoretical solution to the whole junk mail problem that occurs to
> me, would be for everybody to run a spoof open mail relay on port 25
> of every IP under their control.  By that I mean a script that accepts
> mail and claims that it will be delivered, but never delivers it.
> Since the IPs running these spoof SMTP servers would never be listed
> against an MX record anywhere, no genuine mail would go to them, only
> junk.
>
> Anybody sending junk mail via open relays they'd discovered via port
> scanning would probably see a >99% reduction in the mails that
> actually got through.  Presumably the companies who pay for the bulk
> mail delivery would learn that their mails were not getting through,
> and the business would cease to be profitable.
>
> The only junk mail left would be from identifyable sources which is
> _much_ easier to deal with.
>
> Of course IPv6 will bring some of these benefits as hopefully ISPs
> will assign static IP allocations, rather than dynamic ones.
>
> John.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: Horiffic SPAM

[Wakko Warner]

> if you want to block mail you need to have your MTA return a 500 series
> error code when it gets a connection from that IP address, otherwise the
> sending MTA will just retry later, resulting in the problem described.

Adendum: 5xx error code for each RCPT command.  Otherwise, some MTAs will
treat 5xx as 4xx.

I've been hit enough with this virus that I've blocked everyone except lkml
and exim lists (by IP) from this server (my backup will accept however and is
on a quicker line)

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: Horiffic SPAM

[John Bradford]

> if you want to block mail you need to have your MTA return a 500 series
> error code when it gets a connection from that IP address, otherwise the
> sending MTA will just retry later, resulting in the problem described.

Read my post again.

A lot of the simple SMTP engines embedded in viruses _don't_ retry on
4xx error codes.  Real SMTP engines do.

That flaw is what we are taking advantage of, to filter out the junk.

I.E. we tell everybody 'come back later'.  Genuine mail does, whilst
junk mail often doesn't bother.

John.

Re: Horiffic SPAM

[David Lang]

correct, but the origional poster attempted to solve the problem at the
network layer, not at the SMTP layer, also while some of the virus engines
will not retry in the face of 400 series errors, if you have a backup MX
configured that accepts it and relays it to you that machine will retry.

my point (and I think part of yours as well) is that you need to block
this at the application layer, not the network layer

David Lang

 On Wed, 24 Sep 2003, John
Bradford wrote:

> Date: Wed, 24 Sep 2003 17:45:28 +0100
> From: John Bradford <john@grabjohn.com>
> To: david.lang@digitalinsight.com, john@grabjohn.com
> Cc: andrea@suse.de, linux-kernel@vger.kernel.org, rjohnson@analogic.com
> Subject: Re: Horiffic SPAM
>
> > if you want to block mail you need to have your MTA return a 500 series
> > error code when it gets a connection from that IP address, otherwise the
> > sending MTA will just retry later, resulting in the problem described.
>
> Read my post again.
>
> A lot of the simple SMTP engines embedded in viruses _don't_ retry on
> 4xx error codes.  Real SMTP engines do.
>
> That flaw is what we are taking advantage of, to filter out the junk.
>
> I.E. we tell everybody 'come back later'.  Genuine mail does, whilst
> junk mail often doesn't bother.
>
> John.
>

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: Horiffic SPAM

[James Stevenson]

> 
> A lot of the simple SMTP engines embedded in viruses _don't_ retry on
> 4xx error codes.  Real SMTP engines do.
> 
> That flaw is what we are taking advantage of, to filter out the junk.
> 
> I.E. we tell everybody 'come back later'.  Genuine mail does, whilst
> junk mail often doesn't bother.

This also seems to work with most spammer systems.
But its hard to tell which connections to refuse and
which to accept.

I have had a situation where the connection to the
internet has failed on either the mail server or
its backup relay and amount of spam that day for all users
is greatly reduced.

	James