SSH attacks

So, I tried an experiment last night. If you remember this thread from several weeks ago, I was working on setting up a home server.

Well, I got everything figured out and set up a few weeks ago, and it's working wonderfully. It's definitely very useful to me. Up until now, my server has only been visible on my private subnet: a.k.a. my apartment which is behind a Linksys router. This is fine for most cases...I don't access it too often from outside the house, but occasionally I do want to.

So last night I tried an experiment: I forwarded port 22 on the Linksys router to my server, essentially making it open to the world. Then I went to bed. When I woke up this morning, as was to be expected, the computer had been attacked throughout the night. 235 times to be exact. Not a single login attempt had been successful, of course.

Nevertheless, I don't like this for 2 reasons:
1. All these attacks increase the size of my log files! That's precious disk space! Of course they are small now...but over the course of months and years?
2. I'd like an easy solution to notify me of all successful login attempts. Of course...none of these should occur (except my own login attempts), but it'd be nice to have some kind of notification system so that I don't have to pour through the log files every once in awhile to make sure there were no successful attacks.

I know in the previous thread many people suggested public/private key authentication, but that's not really an option. If I'm going to have ssh running and visible outside my subnet, I want to be able to access it from any computer I happen to be at.

At the current time I'm not using DenyHosts, but I'll probably install it.

So much paranoia over this issue it's funny.

Quote:

---

Originally Posted by DavidP

1. All these attacks increase the size of my log files! That's precious disk space! Of course they are small now...but over the course of months and years?

---

You do have to manage log files in general, periodically. If you have a web server running, it's access log will outpace outpace auth.log by quite a bit, so it is not the most significant concern. Roll them over automatically with logrotate/cron (this happens by default with ssh and apache anyway) and delete old ones every now and again. It takes all of five seconds a week.

Quote:

---

I know in the previous thread many people suggested public/private key authentication, but that's not really an option. If I'm going to have ssh running and visible outside my subnet, I want to be able to access it from any computer I happen to be at.

---

The servers I work on, not using a key is what is "not an option". You either use a key, or you don't use at all. Put your keys on a $5 usb pen drive and carry it around. If all this is too much hassle for you, then that is your own laziness and foolishness, period. It's the difference between something that probably could be easily broken if someone wanted to make the effort (password) vs. something that will not be broken (a public/private key).

Quote:

---

At the current time I'm not using DenyHosts, but I'll probably install it.

---

You can do that manually by adding repeat offenders from auth.log to /etc/host.deny. This one might take 10-15 minutes to figure out and 2 minutes to periodically implement. Writing a script to rip IP's from a log should be a snap for a programmer, DavidP, you can do it while in your sleep tonight ;)

Lookup fail2ban. Nifty solution for exactly what you want to do.

Here's a bash script I like to use to parse my auth.logs for attacks.

Code:

---

#!/bin/bash

printf "Username stats:\n"
grep "invalid user" /var/log/auth.log* | awk '{print $11}' | sort | uniq -c | sort -r
printf "\nIP stats:\n"
grep "invalid user" /var/log/auth.log* | awk '{print $13}' | sort | uniq -c | sort -r

---

Quote:

---

Originally Posted by IceDane

Lookup fail2ban. Nifty solution for exactly what you want to do.

---

It would be roughly the same as DenyHosts here.

I just told my Linksys to forward port 55000 or so to 22 on the SSH server; stopped those attacks in a flash, haven't had one since. No additional software to install or maintain, works on any OS. Now when I ssh in I just add -P <my magic port number>. Rsync works a little differently but it works. Whats nice is then using FUSE to mount the SSH box as a file system remotely.SSH Filesystem

Quote:

---

Originally Posted by jeffcobb

I just told my Linksys to forward port 55000 or so to 22 on the SSH server; stopped those attacks in a flash, haven't had one since.

---

It is more security through obscurity than actual security, in my opinion. I know some people consider changing them to be good practice anyway, but I still prefer using standard port numbers.

Quote:

---

Originally Posted by laserlight

It is more security through obscurity than actual security, in my opinion. I know some people consider changing them to be good practice anyway, but I still prefer using standard port numbers.

---

It's my understanding that there are bots that probe port 22 on as many machines as possible, then attempt to gain access. If your SSH is running on some non-standard port then you'll be skipped.

I agree it's not security (you certainly haven't made it more secure). But there are downsides, I use SVN via SSH on my server. Configuring some SVN clients to use SSH on a non-standard port is sometimes impossible if not very hard.

I don't really have the option of using public/private keys on my server. Since I SSH from all sorts of other computers being friends and uni. I can't afford to run the risk of not having my keys on me ;), especially since I use it to sync my work across my computers.

Quote:

---

Originally Posted by laserlight

It is more security through obscurity than actual security, in my opinion. I know some people consider changing them to be good practice anyway, but I still prefer using standard port numbers.

---

Maybe but it works, needs no additional software to configure and only seconds to implement; I am totally sold on its effectiveness. If someone is determined to get in, they will have to perform more intensive and intrusive scanning, at which point I can take further directed action.

Some folks see it as a problem to solve, an enemy to engage. Some prefer to find ways not to have to engage the enemy at all. In a perfect world, I would prefer to stick to standard ports but that is not the world I live in.

Quote:

---

Originally Posted by laserlight

It would be roughly the same as DenyHosts here.

---

Yes, except it uses iptables(afaik) and it's automated. What's your point?

Quote:

---

It is more security through obscurity than actual security, in my opinion. I know some people consider changing them to be good practice anyway, but I still prefer using standard port numbers.

---

Not really. The security is dependent on the strength of the ssh daemon(e.g. whether it has exploitable bugs), its configuration and the password of the user/s that are allowed to log on. Changing port numbers is probably mostly for convenience. Less log litter and easier to manage real auth by real users, if there are multiple users.

Quote:

---

Originally Posted by IceDane

Yes, except it uses iptables(afaik) and it's automated. What's your point?

---

To get you (or anyone more familiar with fail2ban) to elaborate on why you would choose fail2ban over DenyHosts, which was already mentioned.

Quote:

---

Originally Posted by IceDane

Not really. The security is dependent on the strength of the ssh daemon(e.g. whether it has exploitable bugs), its configuration and the password of the user/s that are allowed to log on.

---

"Not really", as in you consider it to be more than security through obscurity? Your elaboration does not match with that; rather, it matches with my assertion that changing port numbers does not provide actual security.

Quote:

---

Originally Posted by IceDane

Changing port numbers is probably mostly for convenience.

---

If you look at the context of my post, you will see that I am addressing jeffcobb's use of non-standard port numbers to stop attacks.

LaserLight; what I am suggesting serves more to simply keep the target IP address off of the hackers radar...they go through massive scans on IP addresses checking standard ports to see if they are open and if so, that address is logged for later attack. Then based on the port found to be opened, one or more customized attacks are launched. For every person like you who might have port 22 open (in this case) but has adequate security running, there are probably a thousand or more who don't. These people are the low-hanging fruit that the hackers are after since it costs them nothing for the initial scan and probably very little effort to weed out the secure ones like you from the rest of the chattel. Notice at this point someone implementing what I have suggested is already way off of the radar and has to expend no more bandwidth,effort or monitoring to avoid the whole situation.

Its like if they ping me (on the standard port) the result is: no open ssh port.
They ping you and get: port is open but secure. They will have to expend more effort to establish this.
They ping everyone else and get: WIIIIDE open boys and girls, come-on in!

So preventing them from getting in and avoiding being a target are just two ways of dealing with it from two philosophies but unless you can prove that either don't work or are not effective, what is the difference?

Quote:

---

Originally Posted by jeffcobb

So preventing them from getting in and avoiding being a target are just two ways of dealing with it from two philosophies but unless you can prove that either don't work or are not effective, what is the difference?

---

The difference is that while both have merit, avoiding being a target is no defense if you actually do become a target, whereas preventing them from getting in is defense even if you do become a target.

LL: Not really. Saying that is no different than saying "preventing them from getting in is no defense if your defenses are not good enough". IOW all you are saying is that if a given strategy doesn't work, it will fail. File that one in the "duh" column. As I have already said, the only way they will find the non-standard port is to do a more intrusive scan which can be detected and easily dealt with but the odds of "them" trying are remote due to the cost/benefit of expending more resources to try to get into my IP versus grabbing someone using the standard port and using minimal to no defenses.

Quote:

---

Originally Posted by jeffcobb

As I have already said, the only way they will find the non-standard port is to do a more intrusive scan which can be detected and easily dealt with but the odds of "them" trying are remote due to the cost/benefit of expending more resources to try to get into my IP versus grabbing someone using the standard port and using minimal to no defenses.

---

I agree that what you say holds true most of the time. However, consider: an attacker might be specifically interested in your server, i.e., this attacker might not just be looking for an easy target. Furthermore, an attacker might have inside information, e.g., he/she was an ex-employee/friend turned enemy with some knowledge of your network configuration, including the non-standard port number.

It is not a terribly good analogy, but I might liken this to ciphers: a strong cipher provides secrecy even if it is known, whereas a weak cipher might only provide some measure of secrecy as long as it remains secret. A strong cipher that is not known would make an attacker's life even more difficult, but the strength of the cipher is independent of whether it is secret. In this case, I am arguing that the security of the server is independent on whether it is a likely target, although it is obviously good to avoid being a likely target.

I use logcheck to have it scan my log-files and send me notifications. Was a long time since i set it up but iirc you would pretty much just add a line from the log-file into an ignore file and any line that doesnt correspond to a line in the ignore file (through some sort of grep stuff....say you add a line get into the ignore file, now all lines in the log-files containing the word get would be ignored) will be mailed to you. Mine is set up to check once ever hour so i get up to 1 mail/hour.

Quote:

---

Originally Posted by laserlight

I agree that what you say holds true most of the time. However, consider: an attacker might be specifically interested in your server, i.e., this attacker might not just be looking for an easy target. Furthermore, an attacker might have inside information, e.g., he/she was an ex-employee/friend turned enemy with some knowledge of your network configuration, including the non-standard port number.

It is not a terribly good analogy, but I might liken this to ciphers: a strong cipher provides secrecy even if it is known, whereas a weak cipher might only provide some measure of secrecy as long as it remains secret. A strong cipher that is not known would make an attacker's life even more difficult, but the strength of the cipher is independent of whether it is secret. In this case, I am arguing that the security of the server is independent on whether it is a likely target, although it is obviously good to avoid being a likely target.

---

Laserly One: Oh make no mistake; I do have resources to put to the problem in the event that someone makes a concerted effort to attack my specific address and am not shy about going after them in retaliation if need be. The thing is, I have found it better not to "need be". However the kinds of attacks that the OP refer to (and I have seen when I did use a standard port number) are NOT this kind of attack. They are coordinated zombie attacks that happen so slowly that most log scanners tend to miss the actual threat. Indeed I only noticed it when doing a manual scan of the log files and the pattern jumped out at me. This is the kind of attack I am advising that moving your port number will avoid. Directed attacks are a whole other ball of wax.

And since you brought up the analogy of ciphers I would remind you of the other aspect of ciphers that only really experienced folks should try to implement them. Bad ones are easy to crank out but good ones take time and effort. My solution to this takes neither time nor effort and if someone of mediocre experience and little time wants to stop the attack, I posit that doing what I suggest is far more effective than any hastily-enacted defense of port 22. If nothing else it *will* buy them time to work up a better defense but at worst the attack is thwarted in seconds with no additional infrastructure. I am not now nor have I ever implied that this is adequate to protect something major like a business or research facility but it is a viable defense for the average home server.