Posted by ahowells on Thu 10 Jan 2008 at 10:50
I'm sure if you're responsible for any server connected to the Internet with a "real" IP address, or if you port forward :22 to a box on your LAN, your logs will contain a lot of failed SSH attempts. Here we'll look at some simple solutions.
The logged entries will probably look something like the following:
sshd[22768]: Invalid user carol from 91.194.85.65 sshd[22770]: Invalid user carolr from 91.194.85.65 sshd[22772]: Invalid user sergi from 91.194.85.65 sshd[22774]: Invalid user quala from 91.194.85.65
Now these are an annoyance, but not much of a concern, as none of these usernames exist on my system - its just filling up my logs, nothing more.
There are other more alarming messages hiding in your logs too, like these:
sshd[17810]: Failed password for root from 91.194.85.65 port 44229 ssh2 sshd[17811]: Failed password for root from 91.194.85.65 port 38154 ssh2 sshd[17814]: pam_unix(ssh:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=91.194.85.65 user=root sshd[17815]: pam_unix(ssh:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=91.194.85.65 user=root
Both of these logs come from different physical boxes, with IPs located in totally different /16's and yet it is the same IP address attacking both? Scary! Even more worrying is the fact the attacks are many hours apart, this guy has been hammering hundreds or thousands of servers all day...
What happens if they eventually get lucky? The "best case" scenario is they get an unprivileged account on your system, with which they can:
If they end up with root@yourserver, things get more interesting - they can literally do anything they want with the box. You're screwed. Really.
Every single decision you ever make about these sort of issues will involve balancing usability and accessibility vs. security and safety. There are lots of options available to you, some more "annoying" to real users than others.
Simply put this is "apt-get install denyhosts" and the default configuration is pretty good. It'll send you alert e-mails if you want them and the level at which block compromised IPs with /etc/hosts.deny is tunable.
Pros:
Cons:
A simple firewall rule can totally drop all traffic to your SSH server if the traffic isn't coming from your IP.
Pros:
Cons:
This is often overlooked, but a real winner. Ensure that all accounts on your system have strong passwords using cracklib.
Generating these passwords is easy with pwgen, to make really strong passwords invoke like so: "pwgen -syB 23"
Pros:
Cons:
Remembering all these strong passwords can be a chore. Often when you're dealing with 2-3+ boxes it's easier to just install the public part of a certificate in ~/.ssh/authorized_keys.
Then you may authenticate to the server with your private key.
Simply put: drop your key in authorized_keys and try to login by doing "ssh -i key.file user@your.hostname.here". Once you have this working you can disable other authentication methods.
Pros:
Cons:
Using options such as "AllowGroups" to limit the users which are considered valid for logins, regardless of the shell which may be set in /etc/passwd.
Perhaps run the daemon on a non-standard port so that scans only looking at :22 don't detect you're even running SSH.
Most of the things suggested above are covered in manual pages and other articles on this site, I am planning to write up some more in-depth coverage as part of this series, including coverage of sshd_config "Best Practice", cracklib and PAM, authentication using public key, etc.
This is the first article I've written in a long time, hope you enjoyed it.
For reference you might want to take a look at our earlier collection of advice upon Keeping SSH access secure.
[ Parent ]
[ Parent ]
[ Parent ]
The firewall is able to do some funky stuff also — I use a setup somewhat like this:
iptables -P INPUT DROP
iptables -N ssh
iptables -A ssh -m state --state ESTABLISHED -j ACCEPT
iptables -A ssh -m recent --update --seconds 300 --hitcount 3 -j REJECT
iptables -A ssh -m recent --set -j ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i tun0 -j ACCEPT
iptables -A INPUT -s $INTERNALNET -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ssh
The ssh-table will now reject the fourth and later attempts to create an SSH connection within five minutes.
Since it can be hard to guess a matching username and password in three guesses, this is good enough for me (root login is not permitted in my setup).
[ Parent ]
[ Parent ]
This downside doesn't exist IIRC when reusing an existing socket...
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
If your box is compromised, all they have to do, is go through your history to get a list of additional boxes to get access too.You mean the box holding the private key, not the server running sshd, right? Of course, the private key itself would be stored on disk with a strong passphrase as well, no? So yes, it could be a cascaded compromise if your local machine is compromised with the key, but it would require the compromising attacker to sort out your key's passphrase as well.
Another option is to offload the key itself to a removable RSA engine. I do this, and detailed how it works with the Cryptoflex eGate (back under debian sarge -- that page is seriously out of date, sorry!). In that case, even if your local machine is compromised, the private key is still inaccessible.
[ Parent ]
[ Parent ]
Sounds like desktop is running Windows, with putty as an ssh client, you have a single key stored on desktop, and you're using pageant for key management. Is this right?
If you have to give pageant a passphrase at startup, that's because it is automatically trying to load your private key, and the key itself is protected with a passphrase. If you tell pageant to unload the key, it should erase all knowledge of the passphrase from its memory.
You also said:
I don't ever remember that box asking for a passphrase to use my keys.Do you mean tools? Do you have a private key stored on tools? If you're using key-based authentication to ssh from tools to other places, you could do it without any private key on tools by simply forwarding your pageant-based authentication. In this case, if your account on tools is compromised, the attacker could read your history and attempt to connect to other hosts as you, but it would only be able to do that while your pageant authentication is forwarded.
I don't know if pageant is capable of prompting you directly each time a forwarded authentication request comes in, but if it can, i recommend that you try that setting. Then even if a compromised remote account attempts to use your forwarded authentication, you'll be aware of it. openssh's ssh-agent is capable of requiring end user confirmation for keys added to it with ssh-add -c, which is pretty handy.
[ Parent ]
[ Parent ]
Assuming tools is running OpenSSH and your private key is stored in the usual location, You can set up a passphrase on your private key with:
ssh-keygen -p ~/.ssh/id_rsa
Even better would be to remove your private key from tools entirely, and just use forwarded authentication (or the ProxyCommand option to OpenSSH, which deserves a whole other post). With the key removed from tools, the only way that a compromise of tools could cascade is if the attacker piggybacks on your existing forwarded authentication session.
Since you connect to tools from at least two machines (desktop and home), you'd need to either put a copy of your private key on each machine (downside: each copy is yet another copy that could be compromised) or put the key on a removable device that you could take with you and use on any machine (downside: if you lose that device, you could be pretty screwed!).
You might also want to consider the idea of a Trusted Physical Console -- if you always work physically from the same machine, you can just keep your keys on that machine (and take it with you), and forward the agent authentication or ProxyCommand hop when needed.
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
Compounding the problems, port knocking is fragile in the presence of firewalls between you and the remote host. If any firewall or filter decides to block any of the ports you've tried to use, your port knocking will fail, cutting you off from the remote machine.
If your SSH daemon's authentication is weak enough that the gain provided by port knocking seems significant, you should probably instead spend more time thinking about how to improve the choices you've made for SSH authentication (reading this article and the comments here is a good start!).
[ Parent ]
Port Knocking adds very little true security to an SSH service.
We should think about what *kind* of security we need -- that is, what sort of threat are we defending against?
Against an attacker who has identified my computer and is determined to compromise my specific computer, your comments are correct. But I would say that that scenario is rare. Much more common, as we see from the article and the comments, is automated scanning. A bot is not going to try to figure out if a target is using port knocking, or analyze traffic to that target to find a port knock sequence -- it's going to hit port 22, and move on when it finds the port is closed.
[ Parent ]
[ Parent ]
[ Parent ]
# Change to no to disable tunnelled clear text passwords #PasswordAuthentication yes PasswordAuthentication nofollowed by `/etc/init.d/ssh reload`. This means that you can access this Box ONLY via an entry in ~/.ssh/authorized_keys.
I do this on ALL Boxen which have an open ssh port on an untrusted network. (and I know very few trusted nets ;-)
Also, while we're at it, if you are behind a firewall which you control, (IPCop at home) then you might want to consider mapping the "visible ports" to something other than 22. You can do this for several Boxen if you wish; I have used the convention "22+last-byte-of-IP" at times. On the road I could call home with `ssh -p22123 user@outsideaddr.ISP.TLD` and land on port 22 of the Box x.y.z.123
keep up the good work
//rhi
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
[ Parent ]
I am a KISS person by nature so I decided to go my own way. I set up a list of things I would try but I would try one thing at a time to see what effect it would have. The first thing on my list was to simply change the port number (you mentioned this at the end of your article).
FYI, that is as far as I got on my list. Attacks on my machine through SSH have virtually disappeared altogether.
It is interesting to note that none of the articles I read during my research mentioned this step yet it was extremely effective and the simplest solution by far. The reason why it is effective is probably because the scans that are being done are automated, most probably by people who don't really understand what they are doing, or automated scans from machines that have been pwned. Nobody is portscanning me and trying to figure out what I am running behind each port. As a homeuser I am simply not worth the effort.
So my opinion is to try this first and foremost and then monitor your logs. I am certain that you will see these attacks die down. However, if you are looking into these things for something other than home network then make sure you dig deeper into the security solutions out there.
/David
[ Parent ]