Hi,
I get ssh connect attempts all the time, to my servers at home and at work. I've noticed lately they come from a certain ip address, hitting every 3 or 4 seconds, trying 50 or 100 different user names and passwords. And I get these sweeps from 2 or 3 ip addresses a day. I guess this is an automated attempt to guess a user/pass and break into a system.
I tried to secure ssh better by putting in an AllowUsers line in sshd_config. Then I thought tcp wrappers and just putting in my own addresses in /etc/hosts.allow would be even better, until I found out that all mail to my email server would be rejected.
I have 2 questions. One, is there anything you can do to stop these attempts, other than not running ssh?
And two, do those ssh attempts every 3 or 4 seconds slow down a box, or put any strain on it?
John
hi,
I have 2 questions. One, is there anything you can do to stop these attempts, other than not running ssh?
- run sshd onto another port - use OTP devices and method or token based authentication or at least an rsa key to authenticate yourself
And two, do those ssh attempts every 3 or 4 seconds slow down a box, or put any strain on it?
depends on but generally it doesn't do it.
bye, Ago
I have 2 questions. One, is there anything you can do to stop these attempts, other than not running ssh?
Welcome to script-kiddie 101. You can use key based authentication instead of password based, which will help, or you can move ssh to an alternate port. by moving ssh off port 22, you'll eliminate virtually all of these probes.
And two, do those ssh attempts every 3 or 4 seconds slow down a box, or put any strain on it?
Theoretically, it reduces it a little, but in practice, you won't/shouldn't notice the difference. The most noticeable hit is to bandwidth, but even that should be reasonably small.
-- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety'' Benjamin Franklin 1775
Use port knocking. The iptables settings for port knocking is available at http://www.soloport.com/iptables.html. Others port knocking methods are available in http://www.portknocking.org
On 2/13/06, Jim Perrin jperrin@gmail.com wrote:
I have 2 questions. One, is there anything you can do to stop these attempts, other than not running ssh?
Welcome to script-kiddie 101. You can use key based authentication instead of password based, which will help, or you can move ssh to an alternate port. by moving ssh off port 22, you'll eliminate virtually all of these probes.
And two, do those ssh attempts every 3 or 4 seconds slow down a box, or put any strain on it?
Theoretically, it reduces it a little, but in practice, you won't/shouldn't notice the difference. The most noticeable hit is to bandwidth, but even that should be reasonably small.
-- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety'' Benjamin Franklin 1775 _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Cleber P. de Souza
John Merritt wrote:
. . . is there anything you can do to stop these attempts, other than not running ssh?
I have found a non-standard port to be satisfactory so far.
APF firewall has a built-in feature, but I am not sure it works on non-standard ports.
I am thinking about installing this, http://denyhosts.sourceforge.net/, in case any persistent script finds my port. I have not tried this yet, so I do not know.
I have 2 questions. One, is there anything you can do to stop these attempts, other than not running ssh?
I use a pam_listfile entry in /etc/pam.d/sshd that reads a file (mine is called /etc/sshusers). If the user requested to log in is not in the file, the authentication attempt is rejected. So, if I had a user named "bob" and someone managed to sniff "bob"'s password during a cleatext protocol authentication session, the user would not be able to log in to the ssh server if "bob" wasn't listed in the file. You can do the same with groups. The main advantage of using this method over the AllowUsers method is that this file can be updated, and sshd does not have to be restarted to re-read the file. You also might look into the pam_access module. I've used that on occasion as well.
Hope this helps.
Barry
John Merritt wrote:
I tried to secure ssh better by putting in an AllowUsers line in sshd_config. Then I thought tcp wrappers and just putting in my own addresses in /etc/hosts.allow would be even better, until I found out that all mail to my email server would be rejected.
There should be no problem here. Just disallow everything in /etc/hosts.deny and then enable particular ip addresses for sshd. And also enable the appropriate addresses for other services that you want to be available to various IP addresses. You can use the word ALL to indicate no restriction. e.g.:
sendmail:ALL
man hosts.allow should get you the information that you need.
But if you are remote to the machine, be careful you don't lock yourself out!
-Steve
John Merritt wrote:
Hi,
I get ssh connect attempts all the time, to my servers at home and at work. I've noticed lately they come from a certain ip address, hitting every 3 or 4 seconds, trying 50 or 100 different user names and passwords. And I get these sweeps from 2 or 3 ip addresses a day. I guess this is an automated attempt to guess a user/pass and break into a system.
I tried to secure ssh better by putting in an AllowUsers line in sshd_config. Then I thought tcp wrappers and just putting in my own addresses in /etc/hosts.allow would be even better, until I found out that all mail to my email server would be rejected.
I have 2 questions. One, is there anything you can do to stop these attempts, other than not running ssh?
And two, do those ssh attempts every 3 or 4 seconds slow down a box, or put any strain on it?
John _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
!DSPAM:43f10f2d290541804284693!
Using hosts.* files.
cat hosts.allow # # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. #
sshd : 192.0.0. : allow sshd : 192.14.89.55 : allow sshd : localhost : allow
# end hosts.allow
The first allows the entire class C on 192.0.0. access and the single IP address 192.14.89.55.
Set the allowed IP addresses to your location(s). Setting these to class Cs, is not such a bad idea. If someone local is trying to get in, it's pretty easy to find out who they are... and if someone suddenly throws you off onto another IP... hopefully it'll still be on the same class.
and then we deny all....
cat hosts.deny # # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # # The portmap line is redundant, but it is left to remind you that # the new secure portmap uses hosts.deny and hosts.allow. In particular # you should know that NFS uses portmap!
sshd : ALL
# end hosts.deny
Then
/etc/init.d/sshd restart
Be sure you have it right if you are remote or you'll not be able to shell in. ;)
And, as stated in other emails.... it's a good idea to have another method for getting in, so that when you're 500 miles from home, on a strange network, you don't suddenly find yourself locked out during a major catastrophe!
Best, John Hinton
John Hinton wrote:
Be sure you have it right if you are remote or you'll not be able to shell in. ;)
Indeed. tcpwrapper only affects new connections. So I usually make sure that I have at least a couple of shells open on the remote machine, make my changes to hosts.allow and hosts.deny, and then bring up yet another terminal to make sure I can still log in.
-Steve
John Merritt wrote:
Hi,
I get ssh connect attempts all the time, to my servers at home and at work. I've noticed lately they come from a certain ip address, hitting every 3 or 4 seconds, trying 50 or 100 different user names and passwords. And I get these sweeps from 2 or 3 ip addresses a day. I guess this is an automated attempt to guess a user/pass and break into a system.
Everything on the internet gets them all day long. I have several dedicated servers so the attacks become weary, and the only time I have ever had a security problem was a user with a guessable password.
What I do is:
Install APF on every box as the first thing I do. http://www.rfxnetworks.com/apf.php
#apf -a myownips
disallow ssh entirely with apf by leaving port 22 out of the the ingress setting.
#chkconfig apf off in the event the server hangs, I want the data center to be able to ssh to the box, so a reboot will disble apf and they will be able to access.
install bfd - http://www.rfxnetworks.com/bfd.php this will also stop the attacks on any port by banning the specifics IPs that have too many failed logins. APF is wonderful, very well thought out and powerful. It's not as flexible as a firewall such as shorewall, but I feel that is overkill to protect a single online server.
Quoting John Merritt (jmerritt@johnlyuba.mine.nu):
I get ssh connect attempts all the time, to my servers at home and at work. I've noticed lately they come from a certain ip address, hitting every 3 or 4 seconds, trying 50 or 100 different user names and passwords. And I get these sweeps from 2 or 3 ip addresses a day. I guess this is an automated attempt to guess a user/pass and break into a system.
I tried to secure ssh better by putting in an AllowUsers line in sshd_config. Then I thought tcp wrappers and just putting in my own addresses in /etc/hosts.allow would be even better, until I found out that all mail to my email server would be rejected.
I have 2 questions. One, is there anything you can do to stop these attempts, other than not running ssh?
As others have said, one option is to use port knocking. You could also stop using passwords altogether. Alternatively you could firewall sources of repeated login attempts using iptables. I've been looking at
http://www.csc.liv.ac.uk/~greg/sshdfilter/ http://fail2ban.sourceforge.net/
only this afternoon.
Sounds like you've got your hosts.allow config wrong, but others appear to have dealt with that already.
My preference would be to firewall rather than block in hosts.[allow|deny], purely because you get rid of the unwanted traffic as early as possible.
And two, do those ssh attempts every 3 or 4 seconds slow down a box, or put any strain on it?
I don't think it's any significant extra load. However, if you start to get large numbers of them then I guess it's possible that sshd may stop responding at times.
James
On 13/02/06, John Merritt jmerritt@johnlyuba.mine.nu wrote:
Hi,
I get ssh connect attempts all the time, to my servers at home and at work. I've noticed lately they come from a certain ip address, hitting every 3 or 4 seconds, trying 50 or 100 different user names and passwords. And I get these sweeps from 2 or 3 ip addresses a day. I guess this is an automated attempt to guess a user/pass and break into a system.
This question's popped up a fair few times in the last couple of weeks/months. I wonder, if haven't already got one, might it be worth setting up a CentOS mailing list FAQ?
I think the general concensus in the past has been...
* Only allow SSH v2 RSA/DSA key-based authentication and use agent forwarding (i.e. *not* passwordless private keys) * Run SSHd on a non-standard port * Disallow root logins via SSH * Only allow users that belong to a specific group to connect via SSH, typically people use the "wheel" group but a custom group is easily substituted * Use a denyhosts script or similar * If you know absolutely where all SSH connections originate from drop all other traffic on that port bar the know IP address/range
As long as you at least understand the basics of how and why you're doing these things, the more layers of security you add the better.
Will.
Will McDonald wrote:
On 13/02/06, John Merritt jmerritt@johnlyuba.mine.nu wrote:
Hi,
I get ssh connect attempts all the time, to my servers at home and at work. I've noticed lately they come from a certain ip address, hitting every 3 or 4 seconds, trying 50 or 100 different user names and passwords. And I get these sweeps from 2 or 3 ip addresses a day. I guess this is an automated attempt to guess a user/pass and break into a system.
This question's popped up a fair few times in the last couple of weeks/months. I wonder, if haven't already got one, might it be worth setting up a CentOS mailing list FAQ?
I think the general concensus in the past has been...
- Only allow SSH v2 RSA/DSA key-based authentication and use agent
forwarding (i.e. *not* passwordless private keys)
- Run SSHd on a non-standard port
- Disallow root logins via SSH
- Only allow users that belong to a specific group to connect via SSH,
typically people use the "wheel" group but a custom group is easily substituted
- Use a denyhosts script or similar
- If you know absolutely where all SSH connections originate from drop
all other traffic on that port bar the know IP address/range
As long as you at least understand the basics of how and why you're doing these things, the more layers of security you add the better.
Will. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi,
Thanks to everyone who responded. I learned a lot today.
What I've done is moved sshd to an alternate port, and also set up hosts.allow and hosts.deny by daemon, to only allow sshd to connect from hosts of mine without blocking other services.
Now when they scan port 22 sshd appears to not be running. If they do guess the alternate port and try a user/pass on it, they'll get stopped by tcpwrappers from even trying a password.
I like the sound of AFP; I didn't install it yet. It sounds like it gives the appearance of port 22 being closed, only it will allow connections from your chosen ips. It says on the web site there are rpms for it, but I didn't see them.
One thing I may be amiss in though, is your number one suggestion above:
* Only allow SSH v2 RSA/DSA key-based authentication and use agent forwarding (i.e. *not* passwordless private keys)
Right now I use passwords for some ssh connections, and passwordless ssh for crontab rsyncs, using passwordless rsa keys. (When it asked to enter a password for ssh-keygen I just hit enter). Does this leave me vulnerable? Is there a how-to on this that explains how to use ssh-agent with keys with passes?
Thanks, John
John
Right now I use passwords for some ssh connections, and passwordless ssh for crontab rsyncs, using passwordless rsa keys. (When it asked to enter a password for ssh-keygen I just hit enter). Does this leave me vulnerable? Is there a how-to on this that explains how to use ssh-agent with keys with passes?
I recommend Keychain http://www.gentoo.org/proj/en/keychain/. With keychain, you can log in and unlock your keys and allow your ssh communications to use them as needed. You do have to unlock them after each reboot.
Barry
On 14/02/06, Barry Brimer barry.brimer@bigfoot.com wrote:
Right now I use passwords for some ssh connections, and passwordless ssh for crontab rsyncs, using passwordless rsa keys. (When it asked to enter a password for ssh-keygen I just hit enter). Does this leave me vulnerable? Is there a how-to on this that explains how to use ssh-agent with keys with passes?
I recommend Keychain http://www.gentoo.org/proj/en/keychain/. With keychain, you can log in and unlock your keys and allow your ssh communications to use them as needed. You do have to unlock them after each reboot.
As Barry says, Keychain is very useful, especially for situations where you want a script to connect to another system unattended but want to avoid passwordless keys. There were some decent how-tos on IBM Developerworks ages ago...
http://www.ibm.com/developerworks/library/l-keyc.html http://www.ibm.com/developerworks/library/l-keyc2/ http://www.ibm.com/developerworks/linux/library/l-keyc3/?Opent=grl,l=929,p=K...
I believe some of the options Keychain accepts have have changed since the article was written but it's still useful.
I have SSHd setup similarly to...
<---------------------------------------------------------------------> Port 2220 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key SyslogFacility AUTHPRIV StrictModes yes RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys IgnoreRhosts yes PasswordAuthentication no X11Forwarding yes <--------------------------------------------------------------------->
In scripts which require the facility to connect "passwordlessly" to other hosts generate a new keypair with a strong password for the user the script will run as. In one of the user's initialisation scripts (.bashrc/.bash_profile) add the following...
keychain --clear --nogui id_rsa
And then in the script itself source the keychain agent authentication details...
[[ -f $HOME/.keychain/$HOSTNAME-sh ]] && source $HOME/.keychain/$HOSTNAME-sh
Anyone logging into the system as the user will need to enter the password for the keypair to see/use the ssh-agent authentication information but scripts will be able to use it without intervention.
Will.
John Merritt wrote:
Hi,
Thanks to everyone who responded. I learned a lot today.
I found a cool project called DenyHosts that I just setup last evening for this purpose. I haven't used it very long, but it was very easy to setup, and seems to be working for me. I know it's cut down on the invalid user logging in /var/log/secure in a matter of a day already, and I've even left SSH traffic on port 22, just to make sure that it's being hammered on.
Check it out.
http://denyhosts.sourceforge.net/index.html
Max
Max wrote:
John Merritt wrote:
Hi,
Thanks to everyone who responded. I learned a lot today.
I found a cool project called DenyHosts that I just setup last evening for this purpose. I haven't used it very long, but it was very easy to setup, and seems to be working for me. I know it's cut down on the invalid user logging in /var/log/secure in a matter of a day already, and I've even left SSH traffic on port 22, just to make sure that it's being hammered on.
Check it out.
http://denyhosts.sourceforge.net/index.html
Max
a very simple way of denying repeated ssh access after the first time is to replace the
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
line in /etc/syconfig/iptables with the following two lines (the mailer might wrap them):
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport ssh -m recent --name SSH --update --seconds 30 -j DROP -A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport ssh -m recent --name SSH --set -j ACCEPT
The only drawback is that a permitted user has to wait 30 seconds after the end of a ssh session before she can establish a new one.
Works very well here.
Kay
Without sounding rude, this item features quite regularly and it would be faster to search. For example this was on the Nahant list recently (some of the Redhat's devs views particularly on denyhosts is amazing.), is a sticky in the gentoo forums, features in fedora forum and Linux Questions etc.
Thus more time could be given to solve non-recurring important issues.
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Jim Smith wrote:
Without sounding rude, this item features quite regularly and it would be faster to search. For example this was on the Nahant list recently (some of the Redhat's devs views particularly on denyhosts is amazing.), is a sticky in the gentoo forums, features in fedora forum and Linux Questions etc.
Jim,
I know what you're saying.. but...
Let me predicate this with my goal of working within the CentOS distribution almost exclusively. My main use is internet server systems. Setting up and maintaining servers is already getting very complex... not to mention needing to keep up potential security issues for those 'other' programs/packages. I admit.. I'm anal about this.
When I 'search', particularly on very common things, the relevance of the returns is worse than horrid. I've spent hours, many times without ever producing the particular search string to get to potential answers. Also, when on this list, I know the information is most of the time pertinent to CentOS and its base package set... not leading off into a wild goosechase, leading to compiling, blah blah blah.. adding non-standard packages and getting to an end that many times doesn't fit after many hours have passed. Dependency hell can be enough at times.... I'm sure most of you know the drill. Searches just many times don't produce for me.
From another recent thread... simple FTP! How common is that? But yet somehow I had missed the ip_conntrack_ftp 'key', which solved my issues with passive ftp. I didn't make a post, but the thread was fantastic. And on it goes with this list. Yes, sometimes it's something I already know.. might interject a bit here and there.. many times it's about something I'll never need.
But I vote to keep the common stuff going... If nothing else it provides alternatives.. and based on who is suggesting what, as I've come to know what to pay close attention to.. and what to totally discount (just kidding ;) ). This list is sort of like my CentOS Daily (minute-ly) Newspaper. Some articles I read, some I don't. My overall knowledge has grown.
Thanks to all. And Jim, I'm not meaning to pick on you here either, but these ssh dictionary attacks have been bothersome to me and the 'alternative' solution's', has made this latest thread interesting for me. But yeah, I could say the same thing as above with regards to other threads..... but those are likely helping many others............ Lets see, on my motorcycle lists... it's the oil thread, the tire thread, blah blah blah... As someone did suggest though, a FAQ on SSH would be a good idea.
Best Regards, John Hinton
John Hinton wrote:
Jim Smith wrote:
Without sounding rude, this item features quite regularly and it would be faster to search. For example this was on the Nahant list recently (some of the Redhat's devs views particularly on denyhosts is amazing.), is a sticky in the gentoo forums, features in fedora forum and Linux Questions etc.
Jim,
I know what you're saying.. but...
[SNIP] Best Regards, John Hinton
I agree with Jim. Ok I dont want this list to be as hostile as the courier-imap is but for some time most of the threads debated here are common or wouldn't exist if the original poster has done so search (like the openvpn one or the recent ftp - by the way go to vsftp's website, there are example for restraining the passive ports used by the ftpd daemon: pasv_min_port & pasv_max_port). Where is Bryan JS so the amount of technical infos provided will force new users to make some search before posting? kfx.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Jim Smith wrote:
Without sounding rude, this item features quite regularly and it would be faster to search. For example this was on the Nahant list recently (some of the Redhat's devs views particularly on denyhosts is amazing.), is a sticky in the gentoo forums, features in fedora forum and Linux Questions etc.
Thus more time could be given to solve non-recurring important issues.
No rudeness taken. In response, without sounding rude back, isn't that what a forum is supposed to be about? If someone finds a topic to not be important, delete the post, or ignore it, and find an issue you find important to reply to. I only mentioned the DenyHosts link because, I myself, just found the project a few days ago, and no one had mentioned it on this thread.
There are a million ways to handle a common issue like this, I think the original poster was simply looking to be pointed to some good ways to handle it. I just learned of all the different ways to handle SSH attacks by reading this post as well, so if someone can learn something from a recurring issue, then that's a good thing.
I've been told time after time to RTFM by my mentor, but he still takes the time to sit me down and show me the good and right way to do even the simple things. And at the very least, he'll shoot a URL to me with the information to read on my own time. Sometimes there can be too much information on a certain topic, and new people to Linux don't know which is the best way to do a simple task. It can be confusing to know which is the best or preferred way people are handling things.
I understand you though, so don't take offense. :)
Max
Jim Smith wrote:
Without sounding rude, this item features quite regularly and it would be faster to search. For example this was on the Nahant list recently (some of the Redhat's devs views particularly on denyhosts is amazing.), is a sticky in the gentoo forums, features in fedora forum and Linux Questions etc.
Thus more time could be given to solve non-recurring important issues.
ay laddie... you're right... it was rude.
On Monday 13 February 2006 7:19 pm, Will McDonald wrote:
- If you know absolutely where all SSH connections originate from drop
all other traffic on that port bar the know IP address/range
As long as you at least understand the basics of how and why you're doing these things, the more layers of security you add the better.
Great summary.
You might want to add: *Ban/block class A subnets you know you would never need SSH access from (usually foreign countries, etc) *Consider dedicating a spare machine to run as an SSH server/proxy.
Peopled hav had lots of suggestions... pretty much everything has been suggested except for my approach:
1) don't use 1234 or test for password 2) ignore the suckers
/Peter
On Monday 13 February 2006 23:58, John Merritt wrote:
Hi,
I get ssh connect attempts all the time, to my servers at home and at work. I've noticed lately they come from a certain ip address, hitting every 3 or 4 seconds, trying 50 or 100 different user names and passwords. And I get these sweeps from 2 or 3 ip addresses a day. I guess this is an automated attempt to guess a user/pass and break into a system.
I tried to secure ssh better by putting in an AllowUsers line in sshd_config. Then I thought tcp wrappers and just putting in my own addresses in /etc/hosts.allow would be even better, until I found out that all mail to my email server would be rejected.
I have 2 questions. One, is there anything you can do to stop these attempts, other than not running ssh?
And two, do those ssh attempts every 3 or 4 seconds slow down a box, or put any strain on it?
John
I successfully use denyhosts that will automatically blacklist ips after several failed attempts. I now have more than 70 IPs blacklisted. John Merritt wrote:
Hi,
I get ssh connect attempts all the time, to my servers at home and at work. I've noticed lately they come from a certain ip address, hitting every 3 or 4 seconds, trying 50 or 100 different user names and passwords. And I get these sweeps from 2 or 3 ip addresses a day. I guess this is an automated attempt to guess a user/pass and break into a system.
I tried to secure ssh better by putting in an AllowUsers line in sshd_config. Then I thought tcp wrappers and just putting in my own addresses in /etc/hosts.allow would be even better, until I found out that all mail to my email server would be rejected.
I have 2 questions. One, is there anything you can do to stop these attempts, other than not running ssh?
And two, do those ssh attempts every 3 or 4 seconds slow down a box, or put any strain on it?
John _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Barry Brimer -
Chris Mason (Lists) -
Cleber P. de Souza -
Craig White -
Deim Ágoston -
James Fidell -
Jim Perrin -
Jim Smith -
John Hinton -
John Merritt -
John Thomas -
kadafax -
Kay Diederichs -
Mark Weaver -
Max -
Peter Kjellström -
ryan -
sophana -
Steve Bergman -
Will McDonald