Index: [Article Count Order] [Thread]

Date:  Sat, 10 May 2008 18:42:41 -0700
From:  "Doug Harvey" <ohgoodiee (at mark) gmail.com>
Subject:  [coba-e:12798] Re: brute force password guessing
To:  <coba-e (at mark) bluequartz.org>
Message-Id:  <48264eaf.20018e0a.1a44.566d (at mark) mx.google.com>
In-Reply-To:  <178601c8b2f9$69e75bf0$6601a8c0@OfficeKen>
X-Mail-Count: 12798

Hi all.

Since were on the subject of the 82, 91.xx.xx.xx ip's, I wanted to jump in
here for a second to say that I am constantly hit by these addresses:

arg1=ppp17-54.pppoe.mtu-net.ru, arg2=81.195.17.54,
relay=ppp17-54.pppoe.mtu-net.ru [81.195.17.54], reject=550 5.0.0 Mail
rejected
arg1=ppp83-237-124-100.pppoe.mtu-net.ru, arg2=83.237.124.100,
relay=ppp83-237-124-100.pppoe.mtu-net.ru [83.237.124.100], reject=550 5.0.0
Mail rejected
SYSERR(root): collect: read timeout on connection from
110-54-124-91.pool.ukrtel.net, from=<honkingqir80 (at mark) canvaselegance.com>: 1
Time(s)
   unable to write pid to /var/run/sendmail.out.pid: file in use by another
process: 1 Time(s)
arg1=ppp85-141-201-129.pppoe.mtu-net.ru, arg2=85.141.201.129,
relay=ppp85-141-201-129.pppoe.mtu-net.ru [85.141.201.129], reject=550 5.0.0
Mail rejected
arg1=ppp85-140-95-10.pppoe.mtu-net.ru, arg2=85.140.95.10,
relay=ppp85-140-95-10.pppoe.mtu-net.ru [85.140.95.10], reject=550 5.0.0 Mail
rejected
arg1=ppp91-78-240-199.pppoe.mtu-net.ru, arg2=91.78.240.199,
relay=ppp91-78-240-199.pppoe.mtu-net.ru [91.78.240.199], reject=550 5.0.0
Mail rejected

While this doesn't help solve the problem at hand, I did want to share with
the crowd that it's a constant battle with editing the firewall to take
these folks out of commission.

Doug
Sleepycathosting.com



-----Original Message-----
From: Ken Marcus - Precision Web Hosting, Inc.
[mailto:kenmarcus (at mark) precisionweb.net] 
Sent: Saturday, May 10, 2008 4:56 PM
To: coba-e (at mark) bluequartz.org
Subject: [coba-e:12794] brute force password guessing



I had an IP guessing pop logins last night.  On the one server that I 
checked, my system blocked them after 4 minutes. That was still enough time 
for 300 attempts.

I did not think they  would be able to find any easy logins with that many 
attempts. But, this morning I checked the logs by grepping for that IP 
address and no indication of failure.

The offending IP was: 82.165.177.156

What I did was:

cd /var/log

#one line below
cat maillog | grep 82.165.177.156 | grep -v "Authentication failure" | 
grep -v Aborted | grep -v "Password mismatch" | grep -v Inactivity | grep -v

Disconnected | grep -v incorrect

#one line below
gunzip maillog.1.gz



cat maillog.1 | grep 82.165.177.156 | grep -v "Authentication failure" | 
grep -v Aborted | grep -v "Password mismatch" | grep -v Inactivity | grep -v

Disconnected | grep -v incorrect

gzip maillog.1

gunzip maillog.2.gz

cat maillog.2 | grep 82.165.177.156 | grep -v "Authentication failure" | 
grep -v Aborted | grep -v "Password mismatch" | grep -v Inactivity | grep -v

Disconnected| grep -v incorrect

gzip maillog.2



What is interesting is that across all my servers, they actually found 7 
logins like user jason with password of jason, or user dennis with password 
of "password". I changed these  logins.

So, they could have spammed through these 7 accounts.

Also, I  have FTP disabled for non-admin users and I have the ~userdir 
functionality disabled. If I had both enabled, then they'd have had 7 ftp 
logins with which to upload spamming / hacking type scripts to my servers.

What I do for FTP is add this to the global section of my proftpd.conf

   <Limit LOGIN>
     DenyAll
     AllowGroup site-adm
     AllowUser someotherusername
     AllowUser admin
   </Limit>



What I do for the userdir functionality is edit each vhost file, eg. 
/etc/httpd/conf/vhosts/site2
from
AliasMatch ^/~([^/]+)(/(.*))? 
/home/.sites/143/site2/users/$1/web/$3
to
AliasMatch ^/~([^/]+)(/(.*))? 
/home/.sites/143/site2/users-invalid/$1/web/$3



Anyone who has a lot of users and who does not make one or both of these 
changes on their servers, is volunteering to be the low hanging fruit.



It will not affect me since I do it automatically already, but  if I could 
make 2 suggestions for future BQ versions:
1. Do not allow the password to be "password" or to be the same as the 
username
2. Have userdirs disabled; make it hard for customers to enable userdirs, 
and harder to enable with php and cgi access for those userdirs.





----

Ken Marcus

Ecommerce Web Hosting by

Precision Web Hosting, Inc.

http://www.precisionweb.net