spammers DoS my James

[Josip Almasi <jo...@vrspace.org>]

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@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

Re: spammers DoS my James

[David Legg <da...@searchevent.co.uk>]

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@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

Re: spammers DoS my James

[Josip Almasi <jo...@vrspace.org>]

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@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

Re: spammers DoS my James

[David Legg <da...@searchevent.co.uk>]

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@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

Re: spammers DoS my James

[Josip Almasi <jo...@vrspace.org>]

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@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

Re: spammers DoS my James

[Josip Almasi <jo...@vrspace.org>]

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@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

Re: spammers DoS my James

[Josip Almasi <jo...@vrspace.org>]

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@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org

Re: spammers DoS my James

[David Legg <da...@searchevent.co.uk>]

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@james.apache.org
For additional commands, e-mail: server-user-help@james.apache.org