You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Kenneth Porter <sh...@sewingwitch.com> on 2004/09/11 06:35:26 UTC
Moron ratware
I've been getting the same bad RCPT TO from 200.232.195.50 for the last 13
hours. I can see the same sendmail process in /var/log/maillog for that
amount of time, with "last message repeated xxx times" a lot. I tcpdump'd
the connection and see the RCPT TO and rejection over and over. (System is
Fedora Core 2.) What's the right thing to do about it? I hate to kill the
connection just to have this guy go fill someone else's logs.
Re: Moron ratware
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Monday, September 13, 2004 1:42 PM -0700 John Hardin
<jo...@aproposretail.com> wrote:
> The way the SMTP protocol is constructed, the client opens a connection
> and waits for a welcome banner before sending data. If the connection is
> tarpitted immediately, then the client never receives the welcome banner
> and never gets tarpitted, and will (presumably) exit after a short wait
> for the banner.
True, any sane SMTP client would work this way. The one I was facing had
gotten past that point and was at the RCPT TO phase.
The interesting thing about the TARPIT netfilter target is that it can be
applied to an existing connection. It doesn't need to be part of a custom
application. The one cost I'd have is a stalled sendmail child (presumably
swapped out), but for low-frequency stuff like this I could live with that.
Re: Moron ratware
Posted by John Hardin <jo...@aproposretail.com>.
On Sat, 2004-09-11 at 12:21, Kenneth Porter wrote:
> --On Saturday, September 11, 2004 12:10 PM -0700 John Hardin
> <jo...@aproposretail.com> wrote:
>
> > Unfortunately, unless the tarpit responds to the first packet with a
> > SMTP welcome banner, the connection won't be tarpitted for longer than
> > the "wait for SMTP welcome" timeout in the client. You need to convince
> > the for end to send some data before they'll get stuck.
>
> I don't understand. This particular connection was repeatedly sending the
> same request over and over (hence my comment of "moron") so a tarpit would
> stop the connection but act like a keepalive, keeping the other side from
> dropping the connection but also not accepting any further data.
The way a tarpit roughly works is it sets the TCP receive window size to
zero and stops acknowledging receipt of packets. If the other side has
data to send, it will send an empty packet (TCP/IP header + no data) and
wait a very long time for an ACK.
The way the SMTP protocol is constructed, the client opens a connection
and waits for a welcome banner before sending data. If the connection is
tarpitted immediately, then the client never receives the welcome banner
and never gets tarpitted, and will (presumably) exit after a short wait
for the banner. Ideally you send a SMTP welcome banner like:
220 Welcome to the tarpit!
before tarpitting the connection, in order to get the client to start
sending data. I've been trying for a long time to convince Tom to add
this capability to LaBrea for precisely this reason. (Hi, Tom!)
This assumes, of course, that the client is well-behaved. I can see the
possibility of a ratware spam client assuming the SMTP server will send
all the proper responses and just spew out the entirety of it's side of
the exchange without waiting for those responses. This might be
poassible to tarpit without a welcome banner, but I wouldn't rely on the
client being that poorly written.
--
John Hardin KA7OHZ <jo...@aproposretail.com>
Internal Systems Administrator voice: (425) 672-1304
Apropos Retail Management Systems, Inc. fax: (425) 672-0192
-----------------------------------------------------------------------
If you smash a computer to bits with a mallet, that appears to count
as encryption in the state of Nevada.
- CRYPTO-GRAM 12/2001
-----------------------------------------------------------------------
Re: Moron ratware
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Saturday, September 11, 2004 12:10 PM -0700 John Hardin
<jo...@aproposretail.com> wrote:
> Unfortunately, unless the tarpit responds to the first packet with a
> SMTP welcome banner, the connection won't be tarpitted for longer than
> the "wait for SMTP welcome" timeout in the client. You need to convince
> the for end to send some data before they'll get stuck.
I don't understand. This particular connection was repeatedly sending the
same request over and over (hence my comment of "moron") so a tarpit would
stop the connection but act like a keepalive, keeping the other side from
dropping the connection but also not accepting any further data. One would
expect ratware to lack application-level timeouts and it would wait forever
in the send() call.
BTW, isn't there something in TCP sorta like the higher-layer HTTP
redirect, allowing one to redirect a connection to a different address?
This would be nice for forwarding a spammer connection to another known
spammer and stepping out of the connection. Sort of a "go pester him
instead" packet.
Re: Moron ratware
Posted by John Hardin <jo...@aproposretail.com>.
On Sat, 2004-09-11 at 00:09, Kenneth Porter wrote:
> --On Friday, September 10, 2004 10:05 PM -0700 Jeff Chan <je...@surbl.org>
> wrote:
>
> > Sounds like a good application for a tarpit, i.e.:
> >
> > http://www.spamcannibal.org/
>
> Good idea. Alas, the FC2 kernel lacks the netfilter tarpit module.
Unfortunately, unless the tarpit responds to the first packet with a
SMTP welcome banner, the connection won't be tarpitted for longer than
the "wait for SMTP welcome" timeout in the client. You need to convince
the for end to send some data before they'll get stuck.
--
John Hardin KA7OHZ <jo...@aproposretail.com>
Internal Systems Administrator voice: (425) 672-1304
Apropos Retail Management Systems, Inc. fax: (425) 672-0192
-----------------------------------------------------------------------
If you smash a computer to bits with a mallet, that appears to count
as encryption in the state of Nevada.
- CRYPTO-GRAM 12/2001
-----------------------------------------------------------------------
Re: Moron ratware
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Friday, September 10, 2004 10:05 PM -0700 Jeff Chan <je...@surbl.org>
wrote:
> Sounds like a good application for a tarpit, i.e.:
>
> http://www.spamcannibal.org/
Good idea. Alas, the FC2 kernel lacks the netfilter tarpit module.
Otherwise I could say something like "iptables -s nasty-spammer -j TARPIT".
That'll tarpit any TCP connection coming from that address. (SpamCannibal
wraps a DB around this, populating an iptables chain with new entries as
needed.)
Some stuff on the TARPIT module:
<http://www.netfilter.org/patch-o-matic/pom-extra.html#pom-extra-TARPIT>
<http://www.securityfocus.com/infocus/1723>
Re: Moron ratware
Posted by Jeff Chan <je...@surbl.org>.
On Friday, September 10, 2004, 9:35:26 PM, Kenneth Porter wrote:
> I've been getting the same bad RCPT TO from 200.232.195.50 for the last 13
> hours. I can see the same sendmail process in /var/log/maillog for that
> amount of time, with "last message repeated xxx times" a lot. I tcpdump'd
> the connection and see the RCPT TO and rejection over and over. (System is
> Fedora Core 2.) What's the right thing to do about it? I hate to kill the
> connection just to have this guy go fill someone else's logs.
Sounds like a good application for a tarpit, i.e.:
http://www.spamcannibal.org/
Jeff C.
--
Jeff Chan
mailto:jeffc@surbl.org
http://www.surbl.org/
Re: Moron ratware
Posted by Kenneth Porter <sh...@sewingwitch.com>.
--On Friday, September 10, 2004 9:35 PM -0700 Kenneth Porter
<sh...@sewingwitch.com> wrote:
> I've been getting the same bad RCPT TO from 200.232.195.50 for the last
> 13 hours.
I've now got 3 hosts connected to me submitting the same bad address over
and over. The address is the bogus one I use in the From line of newsgroup
postings. (My real address appears in the Reply-to, which requires
downloading the entire article instead of just the headers to scrape.)
200.199.184.238
201.12.11.93
200.140.109.223
Alas, they're filling my maillogs with the "no such user" message.
I can obviously firewall them off but for the long run it looks like I'll
have to find some automated way to recognize this stupidity so I can
automate the firewalling.