Blocking SSH Dictionary Attacks
 

Recently I've noticed an increase in the number of attacks on my open SSH port. For the most part, these are the standard dictionary attacks, querying multiple names and passwords over the course of several hours. Unfortunately, they can come so rapidly that it increases my CPU use to 70%+. I'm not terribly worried about security, however, as I only have one account available and an extremely obscure user name and password. If for no other reason than log bloat, I'd like to start blocking these multiple offenders.

It seems as though it should be fairly straight forward to implement a block to an offending IP address after trying a certain number of user names within a certain timeframe... or even more strict - trying any username other than my own.

I looked thoroughly through the man pages for SSH, sshd, and ssh_config... and didn't find anything that seemed to do the trick. I don't know if there's a good IPFW rule that will do the trick here, or if another daemon is needed.

Any suggestions?

Move SSHD to another port.

Thanks for the reply.

After searching my way through sshd, sshd_config, xinetd and xinetd.conf, is the best (only?) way to change the port number in /etc/services? It seems a little too overarching of a file for a small change like that. But since sshd isn't actually the daemon running that spawns the individual sshd's... I suppose it is the only way.

But besides security by obscurity... is there a way to do what I was originally suggesting?

If you have a router in your system (if you don't, go buy one) you can do it very easily with port forwarding. Forward the external port of your choice to the server's port 22.

Otherwise, it's either ipfw rules or edit the sshd_config file (which really doesn't take that long, it's ony one line to change.)

For banning dictionary attacks, are they all coming from the same IP address? There are various allow/deny mechanisms but automating it is a little complex. Probably a Linux networking forum is the place to look.

Yeah, I have a router... but unfortunately it's a crappy linksys one that won't do that kind of 'unbalanced' port forwarding where the external and internal ports are different.
I've actually taken the liberty of blocking all Eastern European and Asian IP subnets... I know nobody is accessing my server from those regions and it seems as though many attacks come from that area from my personal experience. If I manually added all offending IPs to my ipfw ruleset I'd probably run out of those 65,000 slots within a few months... so I guess another daemon would be needed. I was finding some stuff on Linux sites... but it's always a pain to convert their instructions over to Mac - some things never quite work the same.

Security by obscurity is NO security at all!

Ya best of running something which adds IPs to the ipfw firewall rules when it sees a number of failed log in attempts from the IP.

http://www.pettingers.org/code/sshblack.html

--Zed :cool:

Turn the problem on it's head. You don't want to try to block 2^32 -1 addresses, you want to allow one. Yours. My web hosting company makes me enter an IP address to allow ssh logons. They also allow names and wildcards to accomodate dynamic IP assignments. The daemon does a reverse lookup and if it doesn't match it's blocked. Read up on Allow and Deny in the sshd manual.

Depends on your perspective. Lets say I give you 100lbs of diamonds. Small, light, stealable, untraceable and very sellable. Your two storage choices are in a heavily guarded box in the middle of a major city, or quietly buried in the permafrost in northern Canada somewhere between Yellowknife and Churchill.
Every diamond thief in the world (and possibly the guards) will be after the former. Pretty insignificant chance of anyone finding the latter unless they follow me there.

So, changing the port will very likely keep the bots out, although if someone wants YOUR machine it doesn't take that long to scan all 65,000 local ports.

Simplistic slogans don't solve complex problems.

If I was out to get you, hiding your sshd at port 54831 won't do you any good, no doubt about that.

However, we are talking about automated mass-attacks looking +only+ on port 22. Against those, relocating is an extremely efficient way of making the problem go away.

It is also useful to know that IPs can be spoofed and a really nasty hacker could take you off the net by sending you bad packets pretending to be from your DNS, upstream routers etc...
Dynamically generating fw-rules is extremely hairy stuff and should only be done if absolutely nothing else helps and with extreme care !

If you are that deep in the glue it's time to turn services (or the whole machine) off for a couple of days until they get bored and go away :D

I wouldn't worry too much about these attacks. Everybody who has SSHD running on port 22 has been receiving them for some time, and the list of name and password combinations these scripts / drones attempt is incredibly pathetic, but good enough to take over some sloppily configured machines.

If you only access your machine from one IP address, then you can configure SSHD to block all others. However, if you're like me and you access your machine from dynamic IPs, or multiple locations, the best solution may be adding the "AllowUsers" directive to your sshd_config, from which you can specify the only user(s) permitted to login. In the event that you, or some other program, created a user with a weak password it would still be blocked to the outside world.

If you do the above, and also move sshd to another port, you should eliminate the junk traffic hitting your machine, and also stay relatively secure.

Hi there,

I tried to do this but it didn't seem to work properly.

# Allow special User Networks

AllowUsers *@*.mydomain.com *@*.anotherdomain.com


I can access from any machine.
Is this wrong, as I understand you don't have to create any DenyAll Rules or something.

Thanks Zwitch

That directive doesn't accept hostnames, only usernames.

That is painful.

How could I allow only special networks without setting up a firewall or something?

Are you sure? I haven't played with it, but the sshd_config man page states:
suggesting hostnames are valid. However, although it isn't explicit, perhaps wildcards are only allowed in user names?

So I tested to log in from an external account.

And I reach the passwort input. But it doesn't accept a valid passwort.

Should it be blocked before that passwort input or is it casual, that it requests the password in any case?

For security reasons, things like sshd ask for a password even for an invalid user, so an attacker can't figure out valid usernames from invalid ones.

if you connect to it from a static if you can configure sshd to accept connections only from say your internal range and the ip that you commonly connect from for example your office ip

AllowUsers *@196.44.30.18 *@192.168.0.* *@192.168.1.* *@196.41.166.17 *@196.44.30.44

fine :) So my solution works, because the Users from the allowed networks can log in. THX for helping me.

Right, and in my case I just used domain names of the networks we use. Makes it easier to give external people access from trusted networks. Of course they all have to have this domains including static IPs.

Opps. I always thought this was controlled by two separate lines in the sshd_config; I guess not.

BTW, another way of knowing whether this configuration works properly or not is to check out /var/log/secure.log, and see why exactly your password was denied, ensuring that it was for the right reason (i.e., user login not permitted, hostname not permitted, etc).

Can I get a detailed explanation of exactly what the correct edit to /etc/sshd_config is in order to make it listen on a different port?

I currently have:
Nevertheless, sshd is listening on port 22.

I'm running OS X 10.4.2, OpenSSH_3.8.1p1, and port 2222 is open on my computer's firewall.

Trevor

Random Guess... did you restart the SSH daemon?

you can either HUP sshd or reboot the system.

-Zed :cool:

Yes, I tried* both.

Trevor

[Full disclosure edit: sshd is not running all the time, so HUPing sshd was unsuccessful--I got a "No matching processes belonging to you were found" message.]

ok then which sshd.conf file did you change? what was the full path to it?

--Zed :cool:

/etc/sshd_config

Trevor

hehe just got it working here...

it appears that sshd is not really running... apple must be running it under a different process.. not look yet.. but anyway do this:

sudo sshd

then try to connect again to 2222

--Zed :cool:

Yes, that works. Hmmm. What is the mechanism that usually launches sshd and makes it listen on port 22, ignoring /etc/sshd_config? Is that xinetd? So how do I configure xinetd (if that is correct) to launch sshd but not ignore sshd_config?

Trevor

nothing to do with xinetd... the ssh that's running on 22 is control from the sharing control panel.

I'm not sure what it's running atm..

If you're on 10.4, launchd is what's handling things; specifically, this part of /System/Library/LaunchDaemons/ssh.plist:
Changing ssh's info in /etc/services and HUPing launchd should switch ssh over (I haven't tested it though).