spammers DoS my James

[Josip Almasi]

Hi all,

recently, I've noticed my server runs a bit slow.
Netstat shows me I have a dozen smtp connections from a dozen adresses,
from bulgaria and russia and china, I thought they try to brute force
crack my smtp auth so I just iptables them away.
But turns out they change addresses and they brute force guess my
server's usernames:)
So my james died with OutOfMemoryError, after 8GB spams in address-error
directory, about 1.8 million messages, when 500 MB ram wasn't enough.
FTR I did receive 38468 spams (~2%), which bayesian server & client side
correctly identified as spam and stored to my junk & trash folders; I
use them for statistics, want more statistics let me know.

Makes me think, james default conf is in fact insecure - spammers may
DoS your server away anytime. They just bomb you with millions of
messages, you never read any of them, but your server dies.

Should't default matcher class be Null for address-error?

Does database store help at all? You just get db or disk full instead of
memory full, right?

BTW, AFAIK ppl use greylisting to rather sucesfully get rid of spammer's
DoS. Here's how it works: spammer gets 450 service temporary unavailable
and gives up, and good MTA retries after a while and delivers.
Personally, I'd never use it, it only introduces unnecessary delays in
mail delivery; exact delay depends on foreign MTA config, and it can be
quite annoying in biz environment. Furthermore, it's just a matter of
time when spammers get smarter and greylisting won't work anymore.

Regards...

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@...
For additional commands, e-mail: server-user-help@...

[David Legg]

Josip Almasi wrote:
> Netstat shows me I have a dozen smtp connections from a dozen
> adresses, from bulgaria and russia and china, I thought they try to
> brute force crack my smtp auth so I just iptables them away.
> But turns out they change addresses and they brute force guess my
> server's usernames:)

Oh, bad Luck :-(

Long ago I decided to 'trust the force' and delete anything which failed
the bayesian filter.  That stops the backlog of messages for me but that
may not be acceptable for you.

A while ago, like many people, I noticed those horrible scripts
attempting dictionary attacks on the SSH daemon.  In the end I
implemented a fix I'd seen using iptables [1][2].  This involved
dropping any attempts to login using SSH if that same IP address had
previously failed to login for more than some threshold value.  The ban
on the IP address was set to half an hour.

I wonder if something similar could be implemented here?  It's not quite
the same as Greylisting as you penalise MTAs that try to connect too
often.  I guess if James doesn't limit the number of operations that the
same MTA can perform using one connection this won't work anyway.

I do get a chuckle though when I run dmesg and see all the failed
attempts to crack SSH ;-)

David Legg


[1] http://olivier.sessink.nl/publications/blacklisting/index.html
[2] http://www.la-samhna.de/library/brutessh.html


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@...
For additional commands, e-mail: server-user-help@...

[Josip Almasi]

David Legg wrote:
>
> Oh, bad Luck :-(

Indeed:)

> Long ago I decided to 'trust the force' and delete anything which failed
> the bayesian filter.  That stops the backlog of messages for me but that
> may not be acceptable for you.

Well I solved the issue by droping all address-error msgs.
But I'm still amazed by incredible ammount of msgs they can produce...:)

> A while ago, like many people, I noticed those horrible scripts
> attempting dictionary attacks on the SSH daemon.  In the end I
> implemented a fix I'd seen using iptables [1][2].  This involved
> dropping any attempts to login using SSH if that same IP address had
> previously failed to login for more than some threshold value.  The ban
> on the IP address was set to half an hour.
>
> I wonder if something similar could be implemented here?  
> [1] http://olivier.sessink.nl/publications/blacklisting/index.html

Great, thanks!!!
Gonna give it a try right away;)

Regards...

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@...
For additional commands, e-mail: server-user-help@...

[Josip Almasi]

Josip Almasi wrote:
>> I wonder if something similar could be implemented here?  [1]
>> http://olivier.sessink.nl/publications/blacklisting/index.html
>
> Gonna give it a try right away;)

Well it works allright:)

Here's the script modified for smtp traffic(*).

Trying to think of problems - it may make problems to MTA that opens a
new connection for each msg. But of course there's no such MTA's
around;) But in such a case this method is equivalent to greylisting.

Thanks again for the hint:)

Regards...

*)

#SMTP dynamic blacklist impl
#based on SSH blacklist
#http://olivier.sessink.nl/publications/blacklisting/index.html

# create properREJECT chain that does different rejects for tcp/udp
iptables -N properREJECT
iptables -A properREJECT -p tcp -j REJECT --reject-with tcp-reset
iptables -A properREJECT -j REJECT --reject-with icmp-port-unreachable
#
iptables -N blacklistdrop
iptables -A blacklistdrop -j LOG --log-prefix "adding to BLACKLIST: "
iptables -A blacklistdrop -m recent --name BLACKLIST --set -j DROP
#
#
# on external hosts, do rate limiting on incoming smtp packets, and keep
a black list for 30 seconds
# this rule drops *any* packet if the IP is in the blacklist
# icmp 'destination-unreachable' packets should not update BLACKLIST,
because
# they are generated by our own REJECT rule in the extern_out chain
iptables -A INPUT -m recent --name BLACKLIST --update --seconds 120 -j DROP
#
# all *established* smtp connections simply continue
iptables -A INPUT -p tcp --dport 25 -m state --state ESTABLISHED,RELATED
-j ACCEPT
#
# *new* smtp connections are all put into a list 'smtpconn', and if
there are 3 such packets in 30 seconds
# we send the package to chain 'blacklistdrop' which puts the IP in the
blacklist
iptables -A INPUT -p tcp --dport 25 -m state --state NEW -m recent
--name smtpconn --rcheck --seconds 30 --hitcount 3 -j blacklistdrop
#
# if we have seen less then 3 such packets in the last 30 seconds we accept
iptables -A INPUT -p tcp --dport 25 -m state --state NEW -m recent
--name smtpconn --set -j ACCEPT
#
# if the destination address is in the blacklist, we REJECT *any* packet
iptables -A OUTPUT -m recent --name BLACKLIST --rdest --rcheck --seconds
30 -j properREJECT
#
# outgoing we accept all smtp traffic, with connection tracking
iptables -A OUTPUT -p tcp --sport 25 -m state --state
ESTABLISHED,NEW,RELATED -j ACCEPT

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@...
For additional commands, e-mail: server-user-help@...

[David Legg]

Josip Almasi wrote:
> Well it works allright:)
>
> Trying to think of problems - it may make problems to MTA that opens a
> new connection for each msg. But of course there's no such MTA's
> around;) But in such a case this method is equivalent to greylisting.

Glad to hear it!

Mucking about with iptables always brings me out in a cold sweat... one
slip and you can be locked out of a remote server :-)

Thanks for the modified script... I might try it myself if I get a DDoS.

I'm not sure if it would be effective though if a spambot stays
connected while doing a dictionary attack or while it tries to relay
several hundred emails once it has cracked an account.  For that, James
itself would have to keep count of the number of commands executed and
force a disconnect after some threshold is reached.

You seem to be suggesting that the same IP address is connecting a lot
of times.  If I were a spambot writer I would be trying to get as many
messages relayed as possible and re-connecting each time I tested a
password or sent a message would get in the way of that.

David Legg


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@...
For additional commands, e-mail: server-user-help@...

[Josip Almasi]

David Legg wrote:
>
> Mucking about with iptables always brings me out in a cold sweat... one
> slip and you can be locked out of a remote server :-)

Hehe I know the feeling;)

> I'm not sure if it would be effective though if a spambot stays
> connected while doing a dictionary attack or while it tries to relay
> several hundred emails once it has cracked an account.  For that, James
> itself would have to keep count of the number of commands executed and
> force a disconnect after some threshold is reached.

Usually a few seconds timeout is just fine protection against bruteforce
attacks. It may not be as good against dictionary attacks, but its up to
admin to disallow weak passwords.
So IMHO auth handler should just sleep a a bit after unsucessfull auth.
Then again, that's why attacker does not wait for the response, he just
opens another socket and tries again:) And thats where the iptables
trick kick in;)

Once cracked, well, theres not much protection agains that.
FTR I see there's some sleep interval in RCPT handler...

> You seem to be suggesting that the same IP address is connecting a lot
> of times.  

Right. Seems like someone modified ssh attack to smtp:)

> If I were a spambot writer I would be trying to get as many
> messages relayed as possible and re-connecting each time I tested a
> password or sent a message would get in the way of that.

Sure. Just dont tell them that;)

Regards...


---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@...
For additional commands, e-mail: server-user-help@...

[David Legg]

Josip Almasi wrote:
> Usually a few seconds timeout is just fine protection against
> bruteforce attacks. It may not be as good against dictionary attacks,
> but its up to admin to disallow weak passwords.
> So IMHO auth handler should just sleep a a bit after unsucessfull auth.
This is similar to another technique called Tarpitting [1].  This
inserts a small (but increasing) delay after each RCPT TO command.  
Another technique is called Teergrubing [2] where you deliberately try
to keep a spambot on the line as long as possible with the theory that
while you keep it hanging around its spam sending capacity is severely
curtailed.

> Then again, that's why attacker does not wait for the response, he
> just opens another socket and tries again:) And thats where the
> iptables trick kick in;)

Ah!  I see... that's clever!  I see now why you would get so many
re-connections.

Regards,
David Legg

[1] http://www.palomine.net/qmail/tarpit.html
[2] http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@...
For additional commands, e-mail: server-user-help@...

[Josip Almasi]

Josip Almasi wrote:
>
> Trying to think of problems - it may make problems to MTA that opens a
> new connection for each msg. But of course there's no such MTA's
> around;) But in such a case this method is equivalent to greylisting.

Well as I suspected but didn't dare say, qmail is sensitive to this method.
It's still OK for regular mail traffic, but mailing lists delivered via
qmail result in bounce test msgs.
And apache.org delivers with qmail, including this list:>
Well it's not a big deal really, we need only manually whitelist
apache.org and other Bernstein fans:)

Regards...

---------------------------------------------------------------------
To unsubscribe, e-mail: server-user-unsubscribe@...
For additional commands, e-mail: server-user-help@...