8 Oct
2010
8 Oct
'10
6:35 p.m.
Hi All,
I received several ssh attacks over the past week, and wonder how, if at all, to
deal with them.
Are they just script kiddies?
One address resolves to 'server.pamperedpawsdogboutique.com', a domain
registered with godaddy. Do I contact godaddy? This attack did not start until
7pm on a Friday...
I might create a blacklist of IP addresses... for example, to filter
/var/log/auth.log into /etc/hosts.deny... (but that might grow too large)
Or if I have confidence that my passwords are secure, do I simply ignore them as
a fact of life?
My aim here is to do productive work, not to fart around with nuisances.
Any help appreciated!
Cheers,
Max
8 Oct
8 Oct
7:41 p.m.
Hi Max,
On Fri, Oct 08, 2010 at 11:35:14AM -0700, Max B wrote:
Hi All,
I received several ssh attacks over the past week, and wonder how, if at all, to
deal with them.
Welcome to the Internet. :)
Go to:
http://lists.bitfolk.com/lurker/list/users.en.html
and type "ssh" after the "ml:users" in the search box at the bottom
to see some previous discussions.
Short answers:
I use and recommend Fail2ban if changing SSH port is not an option.
Are they just script kiddies?
Mostly hosts which have already fallen to previous dictionary
attacks and are now doing further dictionary attacks.
Every couple of months a BitFolk VPS gets compromised in this manner
and the customer only notices because our monitoring detects them
trying to do an SSH dictionary attack.
One address resolves to
'server.pamperedpawsdogboutique.com', a domain
registered with godaddy. Do I contact godaddy? This attack did not start until
7pm on a Friday...
If you want to make this your life, or if you can write a program advanced
enough that it can automatically report this to the right people
every time. Personally, I wouldn't bother, but I occasionally do
receive some automated abuse reports so some people obviously do
bother.
I might create a blacklist of IP addresses... for
example, to filter
/var/log/auth.log into /etc/hosts.deny... (but that might grow too large)
Several programs to do this are covered in the archives. Fail2ban,
denyhosts.
Or if I have confidence that my passwords are secure,
do I simply ignore them as
a fact of life?
Might be workable if you will never have users who might set weak
passwords.
Putting it on another port works well because the noise goes away
and the users can mostly adapt without issue.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
8:24 p.m.
I use an RSA key for SSH and Fail2Ban with iptables for everything,
which seems to work well. I followed a setup guide created by another
Bitfolk user: http://www.robertgauld.co.uk/omwb/2010apr~vps-setup-guide
Andy Smith wrote:
Hi Max,
On Fri, Oct 08, 2010 at 11:35:14AM -0700, Max B wrote:
Hi All,
I received several ssh attacks over the past week, and wonder how, if at all, to
deal with them.
Welcome to the Internet. :)
Go to:
http://lists.bitfolk.com/lurker/list/users.en.html
and type "ssh" after the "ml:users" in the search box at the bottom
to see some previous discussions.
Short answers:
I use and recommend Fail2ban if changing SSH port is not an option.
Are they just script kiddies?
Mostly hosts which have already fallen to previous dictionary
attacks and are now doing further dictionary attacks.
Every couple of months a BitFolk VPS gets compromised in this manner
and the customer only notices because our monitoring detects them
trying to do an SSH dictionary attack.
One address resolves to
'server.pamperedpawsdogboutique.com', a domain
registered with godaddy. Do I contact godaddy? This attack did not start until
7pm on a Friday...
If you want to make this your life, or if you can write a program advanced
enough that it can automatically report this to the right people
every time. Personally, I wouldn't bother, but I occasionally do
receive some automated abuse reports so some people obviously do
bother.
I might create a blacklist of IP addresses... for
example, to filter
/var/log/auth.log into /etc/hosts.deny... (but that might grow too large)
Several programs to do this are covered in the archives. Fail2ban,
denyhosts.
Or if I have confidence that my passwords are
secure, do I simply ignore them as
a fact of life?
Might be workable if you will never have users who might set weak
passwords.
Putting it on another port works well because the noise goes away
and the users can mostly adapt without issue.
Cheers,
Andy
9:19 p.m.
Hi All,
thanks for the substantial and numerous replies I received on this ssh issue.
Thanks also to Robert Gauld for his informative VPS setup page.
I read the pages at denyhosts.net, specifically FAQ answer 1.3 on sshd
configuration changes, and liked the 'PermitRootLogin no' and changed
'Port'
settings (mentioned by more than a few people here at bitfolk).
Security by obscurity should do it for now.
Cheers,
Max
________________________________
From: Michael Corliss <michaeljcorliss(a)gmail.com>
To: Andy Smith <andy(a)bitfolk.com>
Cc: users(a)lists.bitfolk.com
Sent: Fri, October 8, 2010 9:24:14 PM
Subject: Re: [bitfolk] how do *you* deal with ssh attack ?
I use an RSA key for SSH and Fail2Ban with iptables for everything,
which seems to work well. I followed a setup guide created by another
Bitfolk user: http://www.robertgauld.co.uk/omwb/2010apr~vps-setup-guide
Andy Smith wrote:
Hi Max,
On Fri, Oct 08, 2010 at 11:35:14AM -0700, Max B wrote:
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
Hi All,
I received several ssh attacks over the past week, and wonder how, if at all,
to
deal with them.
Welcome to the Internet. :)
Go to:
http://lists.bitfolk.com/lurker/list/users.en.html
and type "ssh" after the "ml:users" in the search box at the bottom
to see some previous discussions.
Short answers:
I use and recommend Fail2ban if changing SSH port is not an option.
Are they just script kiddies?
Mostly hosts which have already fallen to previous dictionary
attacks and are now doing further dictionary attacks.
Every couple of months a BitFolk VPS gets compromised in this manner
and the customer only notices because our monitoring detects them
trying to do an SSH dictionary attack.
One address resolves to
'server.pamperedpawsdogboutique.com', a domain
registered with godaddy. Do I contact godaddy? This attack did not start
until
7pm on a Friday...
If you want to make this your life, or if you can write a program advanced
enough that it can automatically report this to the right people
every time. Personally, I wouldn't bother, but I occasionally do
receive some automated abuse reports so some people obviously do
bother.
I might create a blacklist of IP addresses... for
example, to filter
/var/log/auth.log into /etc/hosts.deny... (but that might grow too large)
Several programs to do this are covered in the archives. Fail2ban,
denyhosts.
Or if I have confidence that my passwords are
secure, do I simply ignore them
as
a fact of life?
Might be workable if you will never have users who might set weak
passwords.
Putting it on another port works well because the noise goes away
and the users can mostly adapt without issue.
Cheers,
Andy
9 Oct
9 Oct
5:24 p.m.
On 08/10/10 21:24, Michael Corliss wrote:
I use an RSA key for SSH and Fail2Ban with iptables
for everything,
which seems to work well. I followed a setup guide created by another
Bitfolk user: http://www.robertgauld.co.uk/omwb/2010apr~vps-setup-guide
I decided
to install fail2ban today but get the following warnings on my
VPS (Debian Lenny). Google didn't come up with a solution. The strange
thing is that all the (many) failed SSH login attempts seem to have
disappeared in auth.log, although I see myself login if I tail auth.log
I see the reload in fail2ban.log, but no other activity
Any thoughts - here's the reload...
vs1:~# fail2ban-client reload
WARNING 'findtime' not defined in 'apache-noscript'. Using default value
WARNING 'findtime' not defined in 'pam-generic'. Using default value
WARNING 'findtime' not defined in 'vsftpd'. Using default value
WARNING 'findtime' not defined in 'xinetd-fail'. Using default value
WARNING 'findtime' not defined in 'named-refused-udp'. Using default
value
WARNING 'findtime' not defined in 'ssh-ddos'. Using default value
WARNING 'findtime' not defined in 'apache-multiport'. Using default value
WARNING 'findtime' not defined in 'apache-overflows'. Using default value
WARNING 'findtime' not defined in 'couriersmtp'. Using default value
WARNING 'findtime' not defined in 'wuftpd'. Using default value
WARNING 'findtime' not defined in 'ssh'. Using default value
WARNING 'findtime' not defined in 'postfix'. Using default value
WARNING 'findtime' not defined in 'sasl'. Using default value
WARNING 'findtime' not defined in 'apache'. Using default value
WARNING 'findtime' not defined in 'courierauth'. Using default value
WARNING 'findtime' not defined in 'proftpd'. Using default value
WARNING 'findtime' not defined in 'named-refused-tcp'. Using default
value
Regards,
Martin
5:43 p.m.
Hi Martin,
On Sat, Oct 09, 2010 at 06:24:12PM +0100, Martin Halford wrote:
I decided to install fail2ban today but get the
following warnings on my
VPS (Debian Lenny). Google didn't come up with a solution. The strange
thing is that all the (many) failed SSH login attempts seem to have
disappeared in auth.log, although I see myself login if I tail auth.log
I see the reload in fail2ban.log, but no other activity
Any thoughts - here's the reload...
vs1:~# fail2ban-client reload
WARNING 'findtime' not defined in 'apache-noscript'. Using default value
Any reason to believe it's not just as it says?
Aside from the warnings what leads you to believe it isn't working?
I would recommend disabling jails that you aren't using, though.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting
7:38 p.m.
On 09/10/10 18:43, Andy Smith wrote:
Hi Martin,
On Sat, Oct 09, 2010 at 06:24:12PM +0100, Martin Halford wrote:
You are right - setting findtime=600 under [ssh] in jail.local (copied
from jail.conf) eliminates one of the warnings. So the warnings are
probably not important.
At the moment I've only SSH enabled (Debian default in jail.conf).
Entries are starting to appear in the log file again - I suppose when
fail2ban was first started it parsed the auth.log file and immediately
banned everything that had multiple failed logins.
Thanks, Martin.
I decided to install fail2ban today but get the
following warnings on my
VPS (Debian Lenny). Google didn't come up with a solution. The strange
thing is that all the (many) failed SSH login attempts seem to have
disappeared in auth.log, although I see myself login if I tail auth.log
I see the reload in fail2ban.log, but no other activity
Any thoughts - here's the reload...
vs1:~# fail2ban-client reload
WARNING 'findtime' not defined in 'apache-noscript'. Using default value
Any reason to believe it's not just as it says?
Aside from the warnings what leads you to believe it isn't working?
I would recommend disabling jails that you aren't using, though.
Cheers,
Andy
8 Oct
8 Oct
7:41 p.m.
Max said:
I might create a blacklist of IP addresses... for
example, to filter
/var/log/auth.log into /etc/hosts.deny... (but that might grow too large)
Various programs exist to do this automatically (e.g. three failed
logins from the IP address and it gets put in hosts.deny). I use
denyhosts - it picks up one or two a day on average.
Alternative programs exist and someone will doubtless be along soon to
name the one various other people here use.
You can also move what port sshd is listening on and ban password-based
logins entirely.
Ian
9 Oct
9 Oct
11:30 a.m.
On 8 October 2010 19:35, Max B <txtmax(a)yahoo.ca> wrote:
Hi All,
I received several ssh attacks over the past week, and wonder how, if at
all, to deal with them.
lazy method:
sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW
-m recent --set --name SSH
sudo iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW
-m recent --update --seconds 60 --hitcount 8 --rttl --name SSH -j DROP
better methods exist but that's the simplest, I think.
4947
days inactive
4948
days old
8 comments
6 participants
participants (6)
-
Andy Smith -
Ian -
Martin Halford -
Max B -
Michael Corliss -
Philip Veale