I've found in my /var/log/secure and /var/log/messages files that just about every day some IP tries several hundred attempts to log in as various users through SSH on my box. Is there some way that I can lock out an IP after a certain number of failed login attempts? Any other recommendations on how to secure myself?

I'm not sure that sshd can do that.. (usernames yes, IP's no). However, someone had an interesting idea here that might help you with just a little scripting. Monitor your /var/log/messages file, and if you see the same IP and whatever phrase indicates a failed login attempt (so you don't block yourself or any other legitimate users) X number of times in a given time frame/in a row/whatever you want your criteria to be, awk the IP out of the file and shunt it into /etc/hosts.deny. Viola, blocked It wouldn't even be too hard...tail -n 5 the file every 5 seconds, say, and run each line through awk to grab the IP and wherever "failed" typically appears. For me, awk '{print $6, $11}' will return "Failed, bad.ip.add.ress" You could store it all in something, and if it's the same on every line... echo $badIP >> hosts.deny

The only problem with this approach (as someone else pointed out on another forum) is that if an attacker notices that you're blocking IPs he could start spoofing legitimate IP addresses, effectively DoS'ing your system.

I was considering doing just that if I couldn't find the functionality in sshd. I was going to block the IPs at the firewall, though. I guess it would be easier to use the hosts.deny file instead, though. I'll also block them for a limited period of time (an hour or two) so the DoS issue won't be as big of a deal.

Good idea

you can also check out the thread in this forum entitled "changing ssh port" to find out how to do that. the brute force login script seems to focus on port 22, so by changing ports you can sidestep the whole thing and make yourself more secure without blocking any ip addresses (which always seems to me a last-resort type thing).

Yes, I think somebody has written some scripts out there that look for certain usernames on SSH port
22, cause it will be coming from different IP's but looking for the same usernames. Well at least I saw
this on a friends box, til we secured his box using my procedure. Then they all went away. This is
what they see now.

Example:
$ ssh localhost
ssh: connect to host localhost port 22: Connection refused
$

Now they just hit port 22 once and move on to less secure machines...

You can get to my SSH hardening procedure by following this thread:
http://www.linuxquestions.org/questi...25#post1699125


Otherwise, you can deny them through the hosts.deny file, but do it in such a way that you only
deny them SSH access to the machine. This way you also won't deny access to legitimate users.

Example:
sshd: 192.168.0.5 : DENY   (Note: Ignore the space between : and DENY)*

Someone trying to connect from that IP will now get a short pause, and then see this:

$ ssh <hostname>
ssh_exchange_identification: Connection closed by remote host
$

Someone trying to connect from 192.168.0.6 could still connect.

You can also deny entire subnets, like this.

Example:
sshd: 192.168.0. : DENY &nbsp; (Note: Ignore the space between : and DENY)*

Just make sure that you always have a blank line as the last line in the file (in some cases it
may fail if you don't). See the note about; newline characters at the end of the line, in the
HOSTS_ACCESS man pages. See also HOSTS_OPTIONS for even more tips...

You could also reverse this if you only needed to be able to SSH in from one box. So, instead
of editing the /etc/hosts.deny file, edit the /etc/hosts.allow file and use this sequence:

Example:
sshd: 192.168.0.10 :ALLOW

Now, only the .10 address can connect, all others will be denied. Use this carefully though,
cause if you are out on the road one day you may not be able to connect remotely unless
you had added the IP of the remote box prior to leaving the house...

Example:
sshd: 192.168.0.10 XXX.XXX.XXX.XXX :ALLOW

Where XXX.XXX.XXX.XXX is the ip of the remote box you want to allow to connect.

/Les


* I had to add a space between : and DENY otherwise the : and D together give me a
smiley face like this

Just wanted to comment that changing the ssh port doesn't make
your system more "secure" -- it is just a case of obfuscation. Indeed
your system will get fewer hits from these automated attacks, but
all they need to do is add port scanning to their attack and you're
in the same boat as before you switched ports. An insecure
system with some obfuscation thrown in will still get broken; it's
just a matter of time.

The automated hosts.deny idea is pretty neat. The logwatch
package already scans your logs and summarizes all of the invalid
login attempts, like this:

sshd:
Authentication Failures:
unknown (210.72.96.71): 73 Time(s)

it would be pretty easy to add automated hosts.deny functionality to
logwatch.

I've been doing hosts.deny manually like once a day for a long time
now, and the file is getting big. It might just be my imagination,
but it seems like it takes longer and longer for the ssh login procedure
to complete. The hosts.deny file has to be re-read and re-parsed every
time there is a login, I would think.

Don't we really want something less ad-hoc? Perhaps a PAM
module that maintains a database of bad IPs.

Matt

There are lots of automated bots out there these days. Strong passwords are probably the best defense against these, but the ideas above are also valid.

point well taken. secure was a poor choice of words. personally i use strong passwords, rsa public/private key login only, no root login, and an obscure port. it's all so easy i figure there's no excuse not to.

"Hiding the ssh port doesn't make your system secure"

This is true but, to me, it all depends on the system being attacked and the attacker itself... I mean: in some cases, it may be a valid way...

If the attacker is a person who really wants to break into your machine, he/she will have only to portscan you before starting to bruteforce passwords. In this case, obfuscation is not security (it would be a matter of time) but, if you're protected, this would ring some alarms...

If the attacker is a script kiddie making a net-wide scan for ssh servers, we won't be noticed.
If we use strong passwords and a secure ssh server then, at least, it would save our bandwidth, our hard drive space and CPU time. Any attempt to access this port should be monitored.

Also, it could save us temporarily from 0-day exploits against specific ssh servers (these scanners are known to save the versions installed on each IP)

And for IP spoofing and DoS, this is not really a problem since TCP uses a 3-way handshake, and a spoof attack is only possible if the attacker performs man in the middle and/or ARP poisoning on your Ethernet network.
You could also setup a do-not-block list of IP's to further avoid this kind of DoS .