Vandals banging on the door of ssh….



Sometimes I wish I wasn’t curious about things…. The other night I was working on something on the testbox in the back room and saw the switch lights flickering fairly actively between the server and the internet gateway. At first I thought maybe it was some mail coming in, but it was awfully persistent. So, I started nosing around. I saw that sshd was showing up in the process list and on checking /var/log/messages…. found hundreds of ongoing attempts to break in through the ssh server. (sigh….) Now, there was a time when I’ve kind of snickered when I’ve seen these futile attempts, because I have a VERY short list of allowed ssh users. (AllowUsers username can be set in /etc/ssh/sshd_config) But, this was fairly persistent and there was more variety to the usernames than I’m used to seeing.


What’s more is that I saw one specific IP hammering away for a span of ten-twenty or even thirty minutes it seemed. Of course, it got me to thinking if there were any ways I could tighten my sshd security. I already make use of the AllowUsers setting and don’t DREAM of allowing Root login… so PermitRootLogin no good. I use UsePrivilegeSeparation yes which should help if the sshd process is crashed out by a buffer overflow I suppose…. I’ve set Protocol 2 to avoid the legacy (breakable) version 1 encryption…. what more could I do?

Well – one thing I was curious about is whether the attacker could see WHY an attempted login failed (banned user?) The answer is no – I’ve tried with ssh debugging enabled (as IF they’re doing that when they try 300 connections in a couple minutes….) So that makes me feel a bit better. What ways are there to throttle connections or blacklist their IP???

One setting I found was MaxStartups 2 With MaxStartups you can limit the number of unauthenticated simultaneous logins… no this doesn’t mean you can’t have more than 2 users logged in, but they have to authenticate before more can try. Well – at least that way we won’t have a bunch of memory tied up with unauthenticated sshd’s waiting for input. For that matter LoginGraceTime 600 might be a bit high and could be ratcheted down lower. (The given setting gives you 10 minutes to type in your username/password.)

But there’s another interesting tool to help work against these brute force attacks. sshutout. It essentially runs and monitors the appropriate system log where ssh login attempts are kept. If it detects an “attack signature” in those logs it dynamically manages firewall rules to ignore the attacking host.

Now there are other approaches (just use key based authentication?) as well. One thing I noticed was that my ssh server running on a non-standard port saw NO activity while the port 22 sshd was just getting hammered.

There is another good iptables based suggestion at this page… This… should allow only 3 connections per minute from a host to the ssh port and ban the host for a minute if that’s exceeded.

iptables -A INPUT -p tcp –dport 22 -m state –state NEW -m recent –set
–name SSH -j ACCEPT
iptables -A INPUT -p tcp –dport 22 -m recent –update –seconds 60 –hitcount 4 –rttl
–name SSH -j LOG –log-prefix “SSH_brute_force ”
iptables -A INPUT -p tcp –dport 22 -m recent –update –seconds 60
–hitcount 4 –rttl –name SSH -j DROP

(Should be entered as three seperate lines – the forward leaning slash breaks up a long line.) I’ve tested that and can vouch for it. There is also a suggestion there for creating a custom whitelist chain first (if you have “safe” hosts that you want to keep from getting caught in the spiderweb of the above chain.)

Recent may not be available for all distros. (Kernel patch). Also, this would affect ALL SSH logins legit or not. So if you try to connect multiple times from one machine it’ll make you wait too.

hosts.deny is an option as well for some, but requires that sshd be compiled with tcp wrappers support. Unfortunately on my chosen machine that’s not (currently) the case… that can be checked by the output of
ldd /usr/sbin/sshd | grep libwrap … if there’s nothing thne no wrappers support. IF YOU DO have libwrap support in sshd then hosts.deny will work and something like denyhosts can update hosts.deny for you based on log entries. There are a couple other usefull suggestions at this site.

__UPDATE__ I’m wrong – a blank output from ldd /usr/sbin/sshd | grep libwrap does NOT necessarily mean that tcpwrappers won’t work (hosts.allow hosts.deny) Another way to test would be to deny localhost and try ssh’ing to the localhost ssh server. (If you have ALL: ALL in hosts.allow it doesn’t matter WHAT you have in deny – allow is checked first.)

There’s also daemonshield which looks promising as a way of dynamically creating iptables rules to temporarily drop packets from the script kiddies banging on the door. (NOT just for SSH).

Hope that helps give some ideas on blunting the attacks when the vandals are at the gate….

__UDPATE__ denyhosts really looks the most straightforward and best solution if you JUST want to protect sshd from the bruteforce login attacks.

Related Posts

Blog Traffic Exchange Related Posts
  • IPtables magic, or... Blocking Aggressive Outbound Traffic with IPtables Blocking Aggressive Outbound Traffic with IPtables. For starters, I've tested this on a test system that started out with NO iptables rules, and then moved on to an IPCop install (the vmware download from vmwarez.com...) I've detailed previously one dilemma that I had with regard to my own cable connection......
  • Wordpress 2.0.4 Update It has been a few days now, but I noticed that Wordpress 2.0.4 has now been released and is highly recommended due to the fixing of a few security issues. They also list a number of bugfixes as well. So, if you're running a site based on wordpress it's time......
  • A closer look at x11vnc I've got to say, one of the things I really like about linux are the myriad of options for remotely administering a system. SSH is the one I use the most, but for the graphical you have x (especially on the LAN), nxserver (which is a compressed and optionally encrypted......
Blog Traffic Exchange Related Websites
  • Solidifying WP Security Designed with PHP, and powered by mySQL directories, WordPress is used by an amazing 8.5% of all websites. Web delivered spyware and web page hacking are becoming progressively more common. With such a lot of web content using WordPress as a CMS, any security weaknesses in the CMS structure or......
  • Reviewing My Social Security Statement in a Time of Economic Insecurity Yesterday Mr. ToughMoneyLove received his annual Social Security Statement, including earnings history and the estimate of retirement benefits.  It actually made me feel more secure in this time of economic upheaval.  Skeptical?  Read on.  My Social Security Statement is Actually Helpful  Many of my recent posts have been harshly critical......
  • Steadfast Finances was Hacked, Now Restored. (Thanks HostGator!) Last week, several lines of "seemingly malicious code" found its way into SF's theme. This prompted Google, Firefox, Google Chrome and even Twitter, to quickly label this blog as a "Reported Attack Site". If you happened to visit SF from the RSS feed, the email subscriber list, or basically clicked......
PDF24    Send article as PDF   

Similar Posts


See what happened this day in history from either BBC Wikipedia
Search:
Keywords:
Amazon Logo

Comments are closed.


Switch to our mobile site