16 Oct
2009
16 Oct
'09
11:58 a.m.
I use different port for SSH to avoid hammering. For example 53412 or 60132
or whatever because bots and other
port scanners really doesn't go higher than 1024 by default so it's enough
to keep away bots and script kiddies.
I still listen for port 22 because in some places those higher outgoing
ports are blocked by local firewall (schools).
But for those places I use simple iptables rule, for example something
like...
iptables -A INPUT -p tcp --dport 22 -s ! IP.H.E.RE -j DROP
I'm still in progress to find out how to add mutiple IP addresses :>
Also, because iptables rules are dropped after every reboot, you have to
customize your if up down scripts or add needed lines to /etc/rc.local
(Debian).
~a
On Fri, Oct 16, 2009 at 1:37 AM, James Gregory <jgxenite(a)gmail.com> wrote:
Hi Ian,
The best way I've found to avoid SSH attacks like this is to use
iptables rules that allow only a certain number of connections to SSH
over a set period of time, and then all other connections are either
dropped or rejected. Personal experience shows dropping doesn't work
as well as plain rejecting any further connections. The rules I've
used (and now tweaked) are based on a document I found at
http://www.debian-administration.org/articles/187.
Below is a snippet from my iptables.rules file (I'm going to assume
you know how to configure iptables :) -
## SSH (taken from http://www.debian-administration.org/articles/187
with some changes)
## This will allow up to 3 new connections a minute, then drop any
further connections
# Route all new SSH traffic onto the SSH_FLOOD table
-A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_FLOOD
# Set a new entry (if one doesn't exist for this host)
# --rttl checks the TTL on the packet to avoid source address spoofing
-A SSH_FLOOD -m recent --rttl --set
# If more than 4 packets are received in 60 seconds, reject the packet
with host prohibited
# (this should instantly kill the SSH connection - DROP will just make it
hang)
-A SSH_FLOOD -m recent --rttl --update --seconds 60 --hitcount 4 -j
REJECT --reject-with icmp-host-prohibited
# Otherwise, accept the packet
-A SSH_FLOOD -j ACCEPT
Hope that helps!
James
2009/10/15 Ian Hobson <ian(a)ianhobson.co.uk>uk>:
Hi all,
My VPS started to perform very slowly today. The only thing I can see
from a
scan of the logs, is that both
/var/log/auth.log and /var/log/mail.debug are 3 times as large as normal
for
the last 2 days.
Andy reports disk usage heavy.
Here is a section from the mail.debug log.
Oct 14 13:49:46 ianhobson postfix/anvil[27480]: statistics: max
connection
rate 1/60s for (smtp:113.161.128.172) at Oct 14
13:46:23
Oct 14 13:49:46 ianhobson postfix/anvil[27480]: statistics: max
connection
count 1 for (smtp:113.161.128.172) at Oct 14
13:46:23
Oct 14 13:49:46 ianhobson postfix/anvil[27480]: statistics: max cache
size 1
at Oct 14 13:46:23
Oct 14 13:57:59 ianhobson postfix/smtpd[27488]: connect from
unknown[200.172.96.11]
Oct 14 13:58:36 ianhobson postfix/smtpd[27488]: NOQUEUE: reject_warning:
RCPT from unknown[200.172.96.11]: 504 5.5.2 <NCAQBNZS>: Helo command
rejected: need fully-qualified hostname; from=<
suspiciouslyo0(a)reulsport.com>
to=<vargassales(a)ianhobson.com> proto=ESMTP
helo=<NCAQBNZS>
Oct 14 13:58:36 ianhobson postfix/smtpd[27488]: warning: restriction
`smtpd_data_restrictions' after `permit' is ignored
Oct 14 13:58:37 ianhobson postfix/smtpd[27488]: E6E76680D6:
client=unknown[200.172.96.11]
Oct 14 13:58:41 ianhobson postfix/cleanup[27491]: E6E76680D6:
message-id=<000d01ca4ccd$f4594c20$6400a8c0@suspiciouslyo0>
Oct 14 13:58:41 ianhobson postfix/qmgr[6059]: E6E76680D6:
from=<suspiciouslyo0(a)reulsport.com>om>, size=2525, nrcpt=1 (queue active)
Oct 14 13:58:41 ianhobson postfix/virtual[27492]: E6E76680D6:
to=<vargassales(a)ianhobson.com>om>, relay=virtual, delay=4.9,
delays=4.7/0.01/0/0.13, dsn=5.1.1, status=bounced (unknown user:
"vargassales(a)ianhobson.com")
Oct 14 13:58:41 ianhobson postfix/cleanup[27491]: 94CB36825A:
message-id=<20091014125841.94CB36825A(a)smtp.ianhobson.com>
Oct 14 13:58:41 ianhobson postfix/qmgr[6059]: 94CB36825A: from=<>,
size=4350, nrcpt=1 (queue active)
Oct 14 13:58:41 ianhobson postfix/bounce[27493]: E6E76680D6: sender
non-delivery notification: 94CB36825A
Oct 14 13:58:41 ianhobson postfix/qmgr[6059]: E6E76680D6: removed
Oct 14 13:58:41 ianhobson postfix/smtp[27494]: certificate verification
failed for mail.reulsport.com[80.93.82.54]:25: self-signed certificate
Oct 14 13:58:42 ianhobson postfix/smtpd[27488]: disconnect from
unknown[200.172.96.11]
Looks to me as if many people are trying to relay and/or spam me - and
failing.
Auth.log contains a huge number of failures....
Oct 15 10:11:42 ianhobson sshd[30370]: pam_unix(sshd:auth): check pass;
user
unknown
Oct 15 10:11:42 ianhobson sshd[30370]: pam_unix(sshd:auth):
authentication
failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=59.27.92.25
Oct 15 10:11:44 ianhobson sshd[30370]: Failed password for invalid user
info
from 59.27.92.25 port 54696 ssh2
Oct 15 10:11:46 ianhobson sshd[30374]: Invalid user tony from 59.27.92.25
Oct 15 10:11:46 ianhobson sshd[30374]: pam_unix(sshd:auth): check pass;
user
unknown
Oct 15 10:11:46 ianhobson sshd[30374]: pam_unix(sshd:auth):
authentication
failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=59.27.92.25
Oct 15 10:11:48 ianhobson sshd[30374]: Failed password for invalid user
tony
from 59.27.92.25 port 54818 ssh2
Oct 15 10:11:50 ianhobson sshd[30378]: Invalid user core from 59.27.92.25
Oct 15 10:11:50 ianhobson sshd[30378]: pam_unix(sshd:auth): check pass;
user
unknown
Oct 15 10:11:50 ianhobson sshd[30378]: pam_unix(sshd:auth):
authentication
failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=59.27.92.25
Oct 15 10:11:53 ianhobson sshd[30378]: Failed password for invalid user
core
from 59.27.92.25 port 54938 ssh2
Oct 15 10:11:55 ianhobson sshd[30382]: Invalid user newsletter from
59.27.92.25
Oct 15 10:11:55 ianhobson sshd[30382]: pam_unix(sshd:auth): check pass;
user
unknown
Oct 15 10:11:55 ianhobson sshd[30382]: pam_unix(sshd:auth):
authentication
failure; logname= uid=0 euid=0 tty=ssh ruser=
rhost=59.27.92.25
Oct 15 10:11:57 ianhobson sshd[30382]: Failed password for invalid user
newsletter from 59.27.92.25 port 55071 ssh2
Oct 15 10:11:59 ianhobson sshd[30386]: Invalid user named from
59.27.92.25
Oct 15 10:11:59 ianhobson sshd[30386]:
pam_unix(sshd:auth): check pass;
user
unknown
That found the door bolted, and gave up at 10:17
Only to be replaced by 222.109.206.50 at 10:30. he went on and on until
13:15!
Then 202.131.144.19 appears to run the same script from 13:21
And then 173.10.126.226 comes battering at the door.
Then 64.183.103.148 has a go. Same script. Slight variation on user names
(and presumably passwords).
So I guess, some script kiddie was trying to break in. And with pam using
MySQL for mail authentication, the disk load would be high.
Is there any way I can tar pit him/them?
I want to know if anything is going wrong, and what, if anything I can do
to
regain the performance of the VPS?
Is there anything else I should check? Advice sought.
Regards
Ian
p.s Without wishing to temp providence, the PVS is back to normal now.
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users