Brute-Force SSH Server Attacks Surge (InformationWeek)

All the distros I've used lately don't allow ssh connections by default, I have to explicitly
enable sshd.

I don't bother with the overhead of iptables rules, I simply define a restrictive set of IPs
allowed to connect to sshd, via hosts.allow, and pare down the list of allowed ssh users, via
sshd_config, to the one or two who actually have a need to do so. For more security, I disable
password logins and require ssh keys to log in.

Every morning the syslog is full of new entries chronicling unsuccessful ssh login attempts.
Haha, suckers - knock yourself out!

I find changing the host port from the default to something else helps to reduce the incidence
of attempts.  If nothing else, it at least keeps the log files a little less jammed full of
entries that need to be reviewed.  You can add an entry to your personal ssh config file to
have it automatically use the alternative port without needing to specify it on the command
line.

Another suggestion - 
If you can, run sshd on an alternate port.  I know this can be inconvenient for some users,
but it is effective in dissuading the bots.  I know "security by obscurity" isn't an answer,
but it's harder to break in a door if you have to search awhile before you find the door.  

Anyway, it has helped dramatically reduce the attacks on my boxes.

In addition to the already mentioned measures, a very simple one is to change the standard ssh
port 22.  Since I did it last year I had not a single attempt, instead of several tens per
day.

Fedora installs SSH and opens a hole for it in the default firewall. So far as I know this is
still true in Fedora 9.

This is a frustrating type of vulnerability because it involves the user doing something
stupid (using a really easy password for 'root' or having a really obvious username AND using
a really easy password). The phrase "brute-force" in the write-up really over-states what
they're trying, SSH isn't vulnerable to being brute-forced, each connection incurs a small but
deliberate delay which, combined with the deliberately slow PAM authentication step means that
attackers can't hope to try more than a thousand or so passwords in an hour.

As a brute force technique that would be hopeless. Even with the ability to connect to say 100
machines at a time (much more and you run into problems with port re-use that screw you up)
they couldn't make much headway. Instead they're relying on small dictionaries, of variable
quality. Some might have 500 very common passwords and try them all against the 'root'
account, others have username + password pairs, or try just a few usernames of old Unix
daemons and other system accounts (the latter attack certainly won't work on any vaguely
modern Linux distro since these accounts have no login privileges).

Unfortunately, we can't actually rely on users not to pick 'password' as the root password of
their machine. So we need to create a situation where ordinary users (since they're the only
ones who'll benefit) can switch off remote password authentication and disable login to the
root account.

It seems like Ubuntu and similar distros have decided instead to throw their hands in the air
and disable remote administation out of the box. In reality I'd guess that a large number of
machines get the remote auth turned back on (with appropriate holes in the firewall) when the
user realises how inconvenient this is. So it doesn't achieve our goal of making the user
safer (though it does mean Ubuntu supporters can say Ubuntu isn't vulnerable to this problem,
which gets them some cheerleading points)

I'd suggest that we need

• User friendly SSH key sharing. People who can play Solitaire and write a document in
OpenOffice.org also need to be able to create and use SSH keys to authenticate between their
laptop and desktop computer, between the desktop computer and the Linux storage/ AV server
under the stairs maintained by their spouse/ sibling/ neighbor and so on. This isn't so that
they can get a bash prompt but so that they can use SFTP and similar user authenticated remote
services.

• Documentation which concentrates on the "login as yourself, obtain root privileges only when
necessary" model, maybe through sudo and the existing privilege escalation dialogs in GUI
environments. We're 90% of the way there on this, and as a result should turn off root logins
altogether by default. If you can't log in as root, then attackers can't either.

But to some extent I think we have to "suck it up" on these unwanted log messages. Attackers
are trying to break into your machine, and being reminded of that is no bad thing.

On my home box I have disallowed password authentication, which as others have
suggested is a good security measure. Also, the machine is behind a router
(with firewall enabled), and subject to NAT.

The only way to accomplish an ssh login is over IPv6; I can set up IPv6
tunnels to go6.net or another provider from my laptop, and access my home
network via this route. Address scanning will require much more work of the
attacker under IPv6, so they'll probably resort to probing the DNS for AAAA
records once there are sufficiently many IPv6 hosts to make this worthwhile
from a cracker's point of view. Disallowing zone transfers to unauthorized
hosts should complicate this strategy however.

To be clear,, I don't use IPv6 as a security tool; it's rather that I'm having
fun with it, and I don't like NAT, but would prefer to give each of my systems
static IPv6 addresses than to pay $$$ to obtain static IPv4 addresses.