David C. Rankin wrote:
Brian K. White wrote:
Except as someone else pointed out, it doesn't piss the bad guys off, rather the opposite, it just confirms that there is really a nice machine/target/victim there. Where simply dropping or refusing the connection tells them a lot less.
Brian:
I agree and I ultimately just went with the disconnect.
ssh : mynormal.offsite.IP : ALLOW ssh : LOCAL : ALLOW ssh : ALL : DENY
I sure do wish I could send something back though. Just for a few hours I would love to give them ssh : ALL : twist cat /usr/bin mplayer
But alas, it doesn't look like you can send anything back of ssh attempts.
Additionally, since it was over the weekend and I was the only one that would need ssh, I just turned the port off at the router. After being closed for 24 hours, the frequency of the attempts dropped a fair amount. Though it could have just been the Sunday factor instead of the Friday factor.
I haven't taken any stats, but it seems that Thursday-Saturday is the most active time for attacks (generally). With the immensity of the problem, I wish there was something that could be done to curtail all the malicious attempts. (I guess we could outlaw windows) But seriously, something will need to be done in a globally coordinated way in the future.
I seem to remember one approch that holds the connection open for a long time, wasting the attackers time and available tcp ports (and using up tcp ports on your end too). I don't remember which package does that or if it was simply a combination of ordinary sshd_config settings.
As for the susefirewall option, there is another problem. Some of these attacks do not come from one ip, they come one or a few connections each from a swarm of different ip's, each of which is an end-users windows pc desktop with a virus. IE: bot-net. I don't know of any good way to block those yet. Most of my servers very job in life is to accept ssh connections from several hundred end-users from any IP anywhere. Their natural traffic often produces spikes of connections-per-second from single ips (everyone in a large office behind a nat router) and from many ips. Like when everyone in a large office behind a nat router starts working in the AM, or when they all reconnect after their net connection flickers. I think the only way to allow those while still blocking bot-net attacks, besides simply using some other port besides 22 for my users, would be to configure a special client (like a hacked PuTTY) that does some sort of port-knocking, which you can configure iptables to recognize.
I had been meaning to try ssh on a higher port and with all the little beggers attacking port 22, I was motivated to go ahead and try. So far, the logs and deathly quiet. I like it.
For those that haven't moved ssh to a higher port, it is actually very simple. I put together a little cheat sheet, should you feel adventurous.
To move ssh to a higher port on openSuSE, you need to edit two files:
1. /etc/services 2. /etc/ssh/sshd_config
First open /etc/services and find an "Unassigned" high port the you would like to use. ('grep Unassigned /etc/services' works well) I would look between 5000 and 9999 so you are left with a four digit port and don't have to type 5 digit for the port. If you like typing, then just stay under 64,000. After you have found a port to use, then copy the lines for port 22, change the port to your desired port number and then comment out the port 22 lines:
#ssh 22/tcp # SSH Remote Login Protocol dcr reassigned to 5129 #ssh 22/udp # SSH Remote Login Protocol #ssh 22/sctp # SSH ssh 5129/tcp # SSH Remote Login Protocol dcr reassigned from 22 ssh 5129/udp # SSH Remote Login Protocol ssh 5129/sctp # SSH When you move the port
Then edit /etc/ssh/sshd_config and change the Port number:
#Port 22 Port 5129
The restart sshd, as root, rcsshd restart. You are ready to access your new ssh port with the port specified in the ssh command:
ssh -p 5129 you@your.host.com
Then all I had to do was update all my ssh aliases in .bashrc and the fact that ssh is now on a different port is completely transparent. Of course you have to change the port in you router as well. One show stopper for me would have been if the change caused difficulties with fish:// However, fish works just fine. All you need to do is add ':portnumber' to the end of the hostname like:
fish://user@somehost.com:port/
or to eliminate the password promt (if your not using public/private keys)
fish://user:pass@somehost.com:port/
Thanks for your help again Brian
Additional Information for rsync: For rsync to work with the alternate port, you must enclose the ssh command and desired port number in single quotes. Example: rsync -av -e 'ssh -p 5129' yoursite.com:~/tmp/somefile.doc tmp/ Works like a champ. -- David C. Rankin, J.D.,P.E. | openSoftware und SystemEntwicklung Rankin Law Firm, PLLC | Countdown for openSuSE 11.1 www.rankinlawfirm.com | http://counter.opensuse.org/11.1/small -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org