The Low-Intensity, Brute-Force Zombies Are Back

Peter N. M. Hansteen writes "In real life, zombies feed off both weak minds and the weak passwords they choose. When the distributed brute-force attempts stopped abruptly after a couple of months of futile pounding on ssh servers, most of us thought they had seen sense and given up. Now, it seems that they have not; they are back. 'This can only mean that there were enough successful attempts at guessing people's weak passwords in the last round that our unknown perpetrators found it worthwhile to start another round. For all I know they may have been at it all along, probing other parts of the Internet ...' The article has some analysis and links to fresh log data."

Comments

why are passwords even allowed?

[rcpitt]

None of my systems allow passwords via ssh - and I run log-guardian.pl to "3 strikes - you're out" the idiots who do the brute-forces by putting them into iptables

Anyone with passwords turned on is not secure IMHO

Re:why are passwords even allowed?

[miknix]

IMHO if the passwords are strong enough there is nothing to worry about, unless you get pissed off with flooded log files and the waste of bandwidth.

None of my systems allow passwords via ssh

Exactly, using public key authentication and disabling PAM/Password authentication solves the problem.

and I run log-guardian.pl to "3 strikes - you're out" the idiots who do the brute-forces by putting them into iptables

sshguard is nice too, they will be firewalled in no time. (watch out for DoSs though)

However, it is not just ssh. Http and servers also suffer a lot from automated breakin attempts.
Anyway.. I'm glad services running on port 22 are not in the same security level of services in 23,137 and 138. Otherwise it would be the holocaust!!

Re:why are passwords even allowed?

[Wonko the Sane]

If you only allow public key authentication then there's really no need to bother blocking them: you'll never block the entire botnet.

Just let them try - they'll never guess the right private key.

Re:why are passwords even allowed?

[MichaelSmith]

The problem is that noise in the logs makes it hard to find real problems. That and the risk of a bug in openssh or openssl, though the current environment is a pretty good test for the software.

Re:why are passwords even allowed?

[BitZtream]

grep -v for the win!

Re:why are passwords even allowed?

[palegray.net]

I don't allow password-based logins either (SSH keys only), allow SSH only from specific IP addresses, and I use fail2ban across all services that involve any kind of authentication (mail, ftp, http auth, etc). I've got it set to "two strikes and you're out"; every day I still get hundreds (some days thousands) of IPs banned in the logs. It's pretty sad.

Re:why are passwords even allowed?

[maeka]

I only allow public key connections, and am only listening on port 2022 (I have no issues telling the world that).
My auth.log is completely empty of password attempts. Am I missing something simple-stupid or is the bot net only going after port 22?

Re:why are passwords even allowed?

[palegray.net]

tail -f for the bored!

Re:why are passwords even allowed?

[Thantik]

I would suspect it's going after port 22 only. If your smart enough to move the port from 22, your probably smart enough to use key pairs and then what is the point of trying to brute force you? Focusing on default 22 is a good strategy because you'll find those who have completely defaulted settings, weak passwords, etc.

Re:why are passwords even allowed?

[tagno25]

grep -v |tail -f for the smart and lazy

Re:why are passwords even allowed?

[Sentry21]

Likewise - I use fail2ban with iptables to drop any packets from someone who fails auth about 5 times in a few minutes. I've toyed with the idea of adding them to a global blacklist for all servers in all locations, but in reality this solution works just fine.

Re:why are passwords even allowed?

[dbIII]

Nice in the short term but giving people an easy way to add rules to your firewall may create hassles later once miscreants know that is what you are doing. Some people have scripts that implement temporary blocking so it doesn't hurt much on the day that some script kiddie decides to have fun with them by forging attacks from different addresses.

Re:why are passwords even allowed?

[palegray.net]

grep -v | tail -f running in a screen session for the smart and lazy who frequently suffer from denial of service attacks from botnets.

Re:why are passwords even allowed?

[Anonymous Coward]

Anyone with passwords turned on is not secure IMHO

Don't go spouting nonsense like that! Storing SSH keys is only as secure as the physical security of the client. If you're travelling (esp international) and need remote access to servers, passwords are the only way to go.

Re:why are passwords even allowed?

[dbIII]

From a quick look at fail2ban it looks like one of it's features is that the blocking only lasts until the next log rotation. Considering that attacks are temporary and automatic firewall rule generation could become a script kiddies playpen this is actually a good thing. If they work out you have this and spoof a few adresses as a denial of service attack the system will recover over time without needing someone to go through all the firewall rules.
I'm still a bit nervous about allowing malicious third parties to effectively write firewall rules for me. The ideal is of course to only allow a certain address range in, but some of us don't really know where the next legitimate connection is going to come from.

Re:why are passwords even allowed?

[Anonymous Coward]

" I run log-guardian.pl to "3 strikes - you're out" the idiots who do the brute-forces by putting them into iptables"

Good to know that if I spoof your IP address I'll prevent you from login your own machines.

Re:why are passwords even allowed?

[The Redster!]

"aplay -t raw" for the truly over-the-edge!

Re:why are passwords even allowed?

[xlotlu]

Better throttle them to some 20b/s.

Re:why are passwords even allowed?

[thePowerOfGrayskull]

Anyone with passwords turned on is not secure IMHO

Don't go spouting nonsense like that! Storing SSH keys is only as secure as the physical security of the client. If you're travelling (esp international) and need remote access to servers, passwords are the only way to go.

Your keys are password protected on the client...

Re:why are passwords even allowed?

[Annorax]

Why not just set up an /etc/hosts.allow and /etc/hosts.deny file and set up them up so that only connections from trusted locations are allowed.

Yeah, I hear people saying "hey, how do you connect when you're out on the road?".

Simple answer: VPN service for remote users.

Re:why are passwords even allowed?

[timmarhy]

passwords are still the most portable lightweigth authentication method out there, that's why. I had a system that got caught by this when a user with shell access set a weakish password. the user was sandboxed with only a limited whitelist of applications they could execute, so no harm done, but i did log all of the bot's attempts and the IRC channel it connected to along with passwords to other bots. it was very interesting to take the attack a part, at it's core it runs a simple dictionary attack and once it's in attempts to launches the same attack on the root password (no chance mine is 9+ random characters), plants a trojan in /temp (which failed in my case) and then connects to an IRC channel and awaits instructions which were pharsed using a simple perl script (which also failed). it then starts scanning for other victims using another perl script.

the activity on the channel indicated brazilian hackers. the thing that suprised me the most though was the amaturish and fragile nature of the process, instead of insulating the whole package so it could operate in a sandbox it atcually relied heavily on installed dependancies which i suspect means it was targeting the default install of one linux distro.

Re:why are passwords even allowed?

[palegray.net]

From a quick look at fail2ban it looks like one of it's features is that the blocking only lasts until the next log rotation.

It's configurable, you can select any period of time for the ban to remain in effect.

I'm still a bit nervous about allowing malicious third parties to effectively write firewall rules for me.

That I completely understand. It's not without its potential hazards, but I think the benefits outweigh them.

some of us don't really know where the next legitimate connection is going to come from

I've been thinking about something like a variant on port knocking, wherein a machine would be make several connections attempts to a non-existent service port from source ports whose numbers add up to some magic number. Filtering would then be disabled for the life of that connection. Maybe someone's already done it.

Re:why are passwords even allowed?

[palegray.net]

To defeat zombie attacks, I suck live packets out of my router through a modified soda straw running Linux. You can guess where anything routed to /dev/null winds up.

Re:why are passwords even allowed?

[daemonburrito]

Or they should be. Unfortunately, there are a lot of "how-to"s on the web that use a null key passphrase to make scripting easier. That openssh allows this is a problem, but lots of people have written scripts that depend on it.

Re:why are passwords even allowed?

[al0ha]

>> Anyone with passwords turned on is not secure IMHO.

I disagree. I both cases, password auth or key auth, barring any security problem with the protocol, the weakest link is the user. A passphraseless ssh key is tempting to the user for many reasons and unless you audit the passphrases selected by your users, key auth is no more secure than password auth. In fact password auth may actually be more secure if you enforce complexity on the system(s). You have no control over the passphrase on a user's SSH key. You can try to control it, but the user can strip the password at any time and on any remote system.

Not allowing passwords may actually lull you into feeling secure. Multi-user and personal user systems are compromised all the time, and in my and my collegues experiences, break-ins via SSH are as likely to happen via either method. Lame botnets try weak passwords, crafty exploiters try everything and thanks to Phalanx2, their craft became much easier.

Re:why are passwords even allowed?

[Sancho]

If you just want to keep the logs cleaner and avoid the bot attacks, you can just run your server on another port.

Re:why are passwords even allowed?

[Ernesto Alvarez]

Something interesting about your usage of tcp/2022. I did the same thing recently on an occasion when I could not use tcp/22, since it seemed an obvious choice. Probable most automated attacks only concentrate on tcp/22 (the obvious target and if you can move it, you probably know enough to secure it properly), but I've been wondering if someone might start considering scanning on 2022 or any other "obvious" choice.

Right now it seems that nobody is scanning for them, but is anyone else setting ssh servers on tcp/2022 or tcp/2222?

(maybe I should give nmap a try, but I lose nothing by asking I guess)

Re:why are passwords even allowed?

[Ernesto Alvarez]

I've commented about that SSH/VPN idea somewhere else here.

What is the advantage of having an extra VPN in terms of SSH usage?
(I know there are other advantages, but you seem to imply that's just to allow SSH access from everywhere but a list of known addresses)

Re:why are passwords even allowed?

[Cheech Wizard]

I only allow public key connections, and am only listening on port 2022 (I have no issues telling the world that). My auth.log is completely empty of password attempts. Am I missing something simple-stupid or is the bot net only going after port 22?

You're not missing anything. I have used other ports for things like ssh for a long time. I changed after watching one IP try to brute force one of my sites for 8 days straight, 24 hours a day. Since changing ports I *very* rarely see a break-in attempt.

Re:why are passwords even allowed?

[palegray.net]

It's a good idea in theory, but the botnets are smarter than that these days. My server networks get portscanned multiple times a day, and it's inevitably followed up with login attempts (even with non-standard ports) on any hosts that aren't taking aggressive defense measures.

Re:why are passwords even allowed?

[Anonymous Coward]

Yeah, it all goes to me, you insensitive clod.

---Maxwell's Daemon.

Re:why are passwords even allowed?

[jonadab]

> Anyone with passwords turned on is not secure IMHO

That entirely depends what your passwords are. Mine are generally more than fifteen characters long and include non-alphabetic characters, so a brute-force attack that goes minutes between attempts, like the ones in this article, is fairly unlikely to get anywhere before my hardware dies of old age.

Re:why are passwords even allowed?

[smallfries]

Of course you get the best of both worlds with ssh-agent. Secure passphrase, and no keyboard input for scripts.

Re:why are passwords even allowed?

[micheas]

I think you over estimate the security of passwords.

You admit that the weakest link is the user.

Passwords are very dependent on the user. They are generally selected by the user and if any of your users recycled a username password pair from http://www.google.com/search?ie=UTF8&q=myspace1.txt.bz2 even though they are eight characters with a letters and numbers and mixed case they are essentially known.

Passwords depend on users not recycling username password pairs that have have been phished.

I will admit to having had a few of my old passwords on cracking lists. (I don't use those passwords anymore, obviously)

key auth is much improved when it is used with something like mod_usb where the private key is stored on a usb key, preferably one that is attached to the persons key chain so it is generally not attached to the machine. (Yes, I know some people leave there keyrings attached to their machines all day, but hopefully they need their other keys at some point and pull the usb drive out.)

Security is about tricking the users into behaving in a secure manner, and with passwords you will be fighting with your users in ways you haven't really thought about. (I am still amazed the way users undermine security.)

my understanding of phalanx2 is that it is more or less a brute force of the keys in debians openssh-blacklist, missing most of openssh-blacklist-extra. (although it may have been updated since the last time I looked at it.)

You are right about being compromised thought. It will happen. have a second and third line of defense ready.

Tripwire and snort are the obvious things to have in place but configuring them so that they provide meaningful information without a million false positives is a little tricky. (or maybe I just haven't done it enough :) )

Re:why are passwords even allowed?

[micheas]

s/mod_usb/pam_usb/

Time to head to bed.

Re:why are passwords even allowed?

[Haeleth]

Right. ssh passphrases are a PITA, so people don't use them.

But that doesn't have to matter, since anyone with any sense is storing their .ssh directory in an encrypted partition anyway. Along with their browser history, local copies of their email, and so forth. Why password-protect just one type of sensitive data, when you could protect everything at once?

Re:why are passwords even allowed?

[Anonymous Coward]

That won't work. Try tail -f | grep -v instead, or better yet tail -f | egrep -e '(filter1|filter2|filter3|...)'

Re:why are passwords even allowed?

[Anonymous Coward]

tee time, you muthafuckahs!

Also, you've got it backwards, grep will exit at the end of the file and there'll be nothing for tail to follow.

Also also, if you're trying to use pipes with tail -f (or -F if you're going to run this continuously so tail will handle log rotation), you'll want to reconfigure your shell's pipe buffer, otherwise it may buffer dozens of lines between when tail prints them and grep filters them.

Re:why are passwords even allowed?

[Anonymous Coward]

If you can succesfully spoof tcp/ip connections without massive numbers of packets for each successful connection, your victim has much worse problems than fail2ban adding one or two false rules to the firewall. You can spoof UDP, but setting up TCP/IP connections past the three way handshake should be hard.

Re:why are passwords even allowed?

[DarkOx]

Ideally some method of using both should be employed. The key should be something you *have* which can naturally be stolen; and the password should be something you *know* harder to steal but could be weak or might get leaked, with liberal application of Gin.

Using both is a good idea because its going to be hard for an attacker to come into the possession of both at the same time.

Re:why are passwords even allowed?

[tendays]

you got it backward - it should be tail -f | grep -v

Re:why are passwords even allowed?

[Sancho]

Interesting. I run an sshd on a non-standard port, and have yet to see this behavior.

I'll keep an eye out, though.

Re:why are passwords even allowed?

[WuphonsReach]

It's still worth doing, it cuts the rate of attacks by at least one order of magnitude (if not two) and your log files will be a lot cleaner. Yes, the worms are getting more sophisticated, but they also have to leave additional footprints in the IDS logs (because of having to port scan).

(We run public key only authentication, with SSH on a nonstandard port. The former is a bit of a PITA, but the latter is a simple change.)

Re:why are passwords even allowed?

[kbielefe]

Not everyone has the luxury of controlling all the passwords on the systems they are responsible for, but I agree with you for single user systems, especially home systems.

People also forget that not only is this kind of attack unlikely to guess my password, in several years of occasionally being hammered with similar attacks, they have yet to even guess the one username that is allowed ssh access.

Re:why are passwords even allowed?

[Anonymous Coward]

unfortunately for some, running on non standard ports is impossible. For me, the corporate giant blocks all outbound traffic excluding 3-4 ports. So personally i'm stuck with leaving 22 open at home.

Re:why are passwords even allowed?

[rcpitt]

I have a local mod that checks for a short list of IP addresses and does NOT put them into iptables :)

Got caught once - but got in from one of my other machines (and I have remote console via a completely different link) so was not disaster - just annoying, so I put in the fix - works with my relay-allow for exim so kills 2 birds with one file :)

Re:why are passwords even allowed?

[pnutjam]

no, but that's the combination to my luggage...

stop posting it in public

Re:why are passwords even allowed?

[Anonymous Coward]

Right now it seems that nobody is scanning for them, but is anyone else setting ssh servers on tcp/2022 or tcp/2222?

Not me. I recently switched to 668 (the neighbor of the beast).

Re:why are passwords even allowed?

[jonadab]

> in several years of occasionally being hammered with similar attacks,
> they have yet to even guess the one username that is allowed ssh access.

Actually, this consideration is why it is widely regarded as a Good Idea to disallow ssh logins directly as root (or other well-known usernames, but root in particular). I usually allow root ssh logins, for convenience, but I take this into account when I construct the root passwords.

Poor Odds

[Nerdfest]

The odds of them getting into a system like this must be quite low, but I guess they're after the low-hanging fruit. Running your services on a high port rather than the default reduces this, as does disabling password login and using 2-factor authentication. Quite easy to do, and very, very secure.

Re:Poor Odds

[ducomputergeek]

We did remapped SSH to a higher unused port and then took it a step further blocking access to that port on the hardware firewall from every IP address except for the office. If I need to connect to the server, I first have to connect to an OpenBSD box in the office.

We have 3 - 4 PCI scans a day (seems like every payment gateway we support for our clients scans the server daily. None of them even see SSH.

Re:Poor Odds

[Anonymous Coward]

it's enabled by default on macs for remote login or help (or whatever they call ssh)

Re:Poor Odds

[Anonymous Coward]

Neither "Remote Login" nor "Screen Sharing" are enabled by default.

Re:Poor Odds

[Cheech Wizard]

it's enabled by default on macs for remote login or help (or whatever they call ssh)

Wrong... You post is nothing but flame bait from someone who obviously has never installed OS X.

Re:Poor Odds

[Phroggy]

You're right, it is called Remote Login (in System Preferences, Sharing, Services). However, as others have said, it is off by default.

Re:Poor Odds

[Anonymous Coward]

The servers do not get any connections except from internal machines, good.

If you have to connect to the OpenBSD box to get to the server, then everyone can attempt a connection to that OpenBSD box. I they can get into that box, your server is now open to attack. After all most malware, hackers will try to get into any other machine in that network once they get into one.

Re:Poor Odds

[eric76]

Why not just disable cleartext passwords?

On our systems, we permit only skey and RSA/DSA keys for logins.

One question?

[Anonymous Coward]

Is "weakpassword" a weak password? I better change up my server double quick.

Not seeing it yet

[MichaelSmith]

...unless they are only attacking from my existing list of blocked IP addresses.

Re:Not seeing it yet

[Sentry21]

A fair point. I've set up on our production servers two lists for ipset, one each for China and Korea. Bullshit accesses to SSH and HTTP dropped way way off once I did that.

With 719 unique CIDR blocks for China and 430 for Korea, we get a lot less garbage traffic to our servers. Worth the hour it took to set up, too.

Re:Not seeing it yet

[drpt]

not here also
Like my water heater I shut off ssh from 24:00 to 06:00 any attempts during that time go on the blacklist.
If anyone bitches, I steal their laptop battery and make them memorize the access rules before they get it back

How-to

[Nerdfest]

Sorry, should have posted this with the original. Instructions for Linux 2 factor authentication

Oh...

[Perseid]

...you mean zombie PROGRAMS. Damn.

[puts shotgun down]

Re:Oh...

[MichaelSmith]

[puts shotgun down]

Don't be so hasty. There are real people herding the zombies.

Re:Oh...

[Anonymous Coward]

[puts shotgun down]

Don't put it down yet...

Re:Oh...

[__aaclcg7560]

You mean like Zombie Hooker Nightmare?

Re:Oh...

[StarkRG]

I know you're joking, but just ask Woody, he knows what to be scared of.

Re:Oh...

[Anonymous Coward]

Where is Woody Harrelson when you need him?

Protect yourself

[Matt Perry]

Use SSH keys in addition to passwords. Disable ssh root logins. Use the AllowUsers command in sshd_config to restrict what accounts can log in with ssh. Edit /etc/hosts.deny and add IP ranges for where you are unlikely to login from. Use iptables rules to block people who are hammering your ssh server from the same address. Use tools like Fail2ban and DenyHosts to block other abusers and share abuser information with other victims.

Re:Protect yourself

[anothy]

mostly good advice. you might consider using ssh keys instead of passwords, depending on your environment. the only thing i'd outright disagree with is pre-denying IP ranges based on a guess of where you're likely to log in from. i've had to leave the country on business unexpectedly on very short notice; it'd suck to have been locked out when i landed.

Re:Protect yourself

[GaryOlson]

Use VPN. Although it may seem redundant, SSH thru a VPN tunnel does provide a secondary access method which is secure.

Re:Protect yourself

[Ernesto Alvarez]

Use VPN. Although it may seem redundant, SSH thru a VPN tunnel does provide a secondary access method which is secure.

While a VPN is secure, so is SSH.
Your idea might have some merit, until someone decides to go for your VPN solution instead of SSH, then you're in the same kind of trouble.

What I'm trying to stress here is that either you block access from unknown/unexpected addresses or you don't, just as you use an established secure login protocol or you don't. Pretending to block unknown IPs while having a VPN endpoint accesible to anyone is not restricting access to your servers to known addresses, it's having access from everywhere and trading SSH's set of vulnerabilities for your VPN's.

If you assume SSH has some problem, then it's a good idea to do what you've done. Then again, if that is the case, you shouldn't leave it open even to a few addresses (since that fault might be exploited by anyone capable of impresonating/pwning one of these hosts). That VPN is handy if you have services other than SSH, though. On the other hand, SSH is supposed to be designed to work in a hostile environment. If there is a problem with SSH you should probably report it to the appropiate persons, so it can be corrected.

IMHO, you're deceiving yourself into thinking you're restricting using IP addresses when you're not.

PS: I run OpenSSH on port 22, RSA/DSA keys only, non-root, and have another set of security measures in order to escalate (once you get to a non-root account).

Re:Protect yourself

[Matt Perry]

you might consider using ssh keys instead of passwords

If you don't have a password as well then if your account is compromised the attacker will be able to access your accounts on other servers without entering a password. I know generating a ssh key without a password is convenient but it also creates risk.

Re:Protect yourself

[Anonymous Coward]

"Use iptables rules to block people [itwire.com] who are hammering your ssh server from the same address. Use tools like Fail2ban [fail2ban.org] and DenyHosts [sourceforge.net] to block other abusers"

None of which will help with this problem. The login attempts don't come from the same IP in a very long time.

Sounds to me like it may be an idle task for botnet out there someone. If you have nothing to do, attempt to increase the size of the botnet, but be subtle about it, so you don't lose the botnet for paying tasks.

Re:Protect yourself

[KingMotley]

Except VPNs are often hardened dedicated devices. Even if you could break through the VPN (Lets assume a software bug), your servers are still then safe with SSH. You can then change the VPN once it's detected. Breaking into your server(s) would require a simultaneous break in of both the VPN and SSH.

I've never seen SSH that uses things like biometrics, and key fobs. Personally I find they key fobs excellent. Coupled with a username, password, and restricting accounts via IPs (or range of IPs) makes a very formidable defense.

Re:Protect yourself

[Ash-Fox]

If you don't have a password as well then if your account is compromised the attacker will be able to access your accounts on other servers without entering a password.

I don't see how that's possible if he doesn't have the private key which is held by the client only.

Re:Protect yourself

[mcelrath]

By the way, you can look at the traffic statistics from DenyHosts, you can clearly see that ssh password-guessing traffic increased about 10 fold on Apr 6. (And since I configured DenyHosts to email me every time it blocks an IP, I've been very aware of this attack)

I've always wondered why someone doesn't do something with the DenyHosts IP list. It should be impossible to forge IP's for ssh, due to handshaking and key exchange. So doesn't DenyHosts have a pretty good map of somebody's botnet? Is any law enforcement agency or ISP using this information? I'm really fscking tired of hearing about attacks, and having law enforcement not appear anywhere in the conversation or articles. If people were systematically making physical keys and trying them on people's houses, you better believe the police would be involved. How is this any different?

Re:Protect yourself

[OrangeTide]

Same here with denyhosts and emails. I noticed immediately that three different systems were being slowly plucked away with ssh attempts. mainly to 'admin', which I suppose is typical of home routers.

you bring up a very good point about the denyhosts data being a good map of the botnet. I think it would be up to the private sector to initiate something before law enforcement would bother though. It seems most of the blackhat stuff is reported/stopped by a few whitehats instead of by government entities.

Re:Protect yourself

[russotto]

I'm really fscking tired of hearing about attacks, and having law enforcement not appear anywhere in the conversation or articles. If people were systematically making physical keys and trying them on people's houses, you better believe the police would be involved. How is this any different?

The only thing law enforcement is good for is punishing people for violations against powerful people which require a serious stretch of existing law to justify, and being the dog-in-the-manger by punishing anyone who actually fights back. They're not interested in stopping actual attacks on ordinary people.

Re:Protect yourself

[Matt Perry]

I don't see how that's possible if he doesn't have the private key which is held by the client only.

The private key is held by the compromised host. Try this: Run ssh-keygen, create a key, don't use a password. Copy the ~/.ssh/id_rsa.pub file to another computer and add the contents to ~/.ssh/authorized_keys. Now you can ssh from the first computer to the second computer and you will not be prompted for a password.

If the account on the first computer is compromised, the attacker could gain access to the second computer because of this lack of password. The OpenSSH people realized this a while back and started to hash the contents of the ~/.ssh/known_hosts file. This file used to contain the plaintext names of the hosts on each line. See this article for some history of the problem. Even though the contents of known_hosts are now hashed, it may be possible to discover other hosts via shell history or other means.

Re:Protect yourself

[Ash-Fox]

If the account on the first computer is compromised

If the first computer is compromised, passwords can be stolen anyway. Not helpful.

Just secure your workstation properly, in most cases, it doesn't need daemons or sshd open publically on the Internet.

Re:Protect yourself

[Ernesto Alvarez]

Good point the one about the VPN server being a hardened device (although it is not always that way).
I'm not talking directly about hardening, though. I was talking about being honest about having access from a limited set of addresses. I'm assuming that your post is about more than mere hardening.

You're explaining the reason why you prefer to trade one set of vulnrabilities for another. But you are still following my line of thought: you have access from everywhere, and you've traded SSH's bug set for your VPN's (or your VPN's and SSH's if that's the only thing accessible once you authenticate).

It's a great hardening measure, but you're still having access from anywhere on the Internet. Why not be honest to yourself?

As for fobs, have you used the ssh-agent? It is essentially a software implementation of a fob. There's nothing preventing someone from using a hardware token instead (I've heard rumors about using SSH with a PKCS#11 token, I've thought of it myself but decided not to because of driver issues).

As for biometrics, I don't know what kind of VPN you're using and if you were talking of biometrics as a thought exercise, but I honestly recomend you don't use it, and if you do, not as the only means of authentication. You're connecting remotely to a VPN server, so that server has no way of knowing if it's really communicating with a computer with a sensor or if it's communicating with an imposter replaying a fingerprint, iris scan, etc intercepted from a previous session or somehow captured from the user. Nothing short of trusted computing can (and you'd be relying on some sort of public/private key, anyway).

Re:Protect yourself

[KingMotley]

First, about VPN/SSH:
You configure your VPN so that user "KingMotley" can only be authenticated from an address that begins with 67.xxx.xxx.xxx, because I always connect from home with comcast. All comcast IP's are in that range. It also requires a password, and a key fob (RSA number generator thing). Now, unless the hardware is hacked by a bug, having just my password is useless, as is stealing my key fob without having my password. Lastly, even if the key fob is bypassed somehow, and my password is known, you still have to connect from comcast (or know to use a comcast IP).

After all that, assuming you can bypass all that, you STILL are protected by SSH's password. SSH should still be set up to only accept connections from the IP address range the VPN would normally give out the clients, protecting it from bypassing the VPN, or a different compromised server (The server IP address shouldn't be in the range the VPN would give out). It's not replacing the protection of SSH with VPN, it's layering it. You need to be able to break through the VPN and SSH protections faster than I can detect your hack attempts. That isn't likely.

Re:Protect yourself

[KingMotley]

As a side note, biometrics for VPN's are nothing more than basically a very long password. But they can't be replayed because the biometric data is combined with a key that the server sends down. So replaying it would be worthless unless you can figure out how to get the server to give you the same key again, which it's designed not to do ;-)

Here's a press release that might help you start your search for answers. http://www.itweb.co.za/office/securedata/0703120805.htm there it talks about RSA, it's SecureID, and third parties involved. Google the companies involved and look at their products and FAQs, it'll help you understand a lot better than I could explain it to you.

Re:Protect yourself

[Ernesto Alvarez]

So you were just talking about hardening after all.

It's a nice setup, but I was talking about people that only allow access to SSH from a few addresses and then undo the restriction by placing a VPN accessible from anywhere. You, on the other hand, know that if you need to access your system from outside comcast you won't be able to. You're not deceiving yourself.

Check the post I originally replied to.

Re:Protect yourself

[Ernesto Alvarez]

Just what I thought. Biometrics is just a fancy way of producing a password when used remotely. I'd rather use a password then. The reason I think biometrics are insecure when used remotely is that it is not that hard to take a sample for some types of systems, like face recognition and then replay it forever. It's harder when talking about fingerprints, so they might help.

I've been thinking of possible ways of using biometrics remotely, but it looks like unless you can make the user do something unexpected every time, it is open to replay attacks. Voice identification, provided the system makes the user say different things each time, might work.

I've just read that press release. It looks like they're using biometrics to unlock the fob. That's a good idea, mostly because it's not remote (the fob is not communicating via a network with the sensor, so you cannot have a fake sensor send replayed or fake data). And they keep the password, a very wise choice if you ask me.

Re:Protect yourself

[KingMotley]

Biometrics aren't typically used as the only security, they are used to increase security. So yes, many biometric systems will fail if you have access to the hardware, and/or you build a fake sensor to relay the data to the system. The replay could happen at the sensor level, but not at the network level. At the network level, it'd be secured from replay through other means (Salt/hash, encryption, etc).

You will notice even in the movies with biometric security, not only do you need the biometrics (which can be faked) but you also need a password, and typically a key (or fob/keycard) as well. Biometrics on the other hand is great for keeping out all but the most determined hacking attempts, and they likely have to have access to your biometric information (Face, fingerprint, palm print, and/or retina scan). *ALL* locks are breakable/hackable/pickable. It's just a matter of difficulty. Biometrics adds difficulty, it doesn't make it impossible. Nor is it appropriate in all cases, but, it is nice in many many more cases than it is currently used in.

SPA / PORT KNOCKING - Bye Bye Brute

[myspace-cn]

Roll out SPA / Port knocking, their IP shouldn't be touching your sensitive ports without a rule, table, or chain specifically allowing access. FORGET THE PASSWORD!

Re:SPA / PORT KNOCKING - Bye Bye Brute

[dannys42]

Just to follow onto your comment.... I'm actually surprised this hasn't been a bigger deal in distros. Port knocking is a fantastic way to virtually eliminate these sorts of threats.

For a home server, this one's nice and easy to use:
http://www.zeroflux.org/projects/knock

ISPs may want to run an SPA tool like fwknop, allowing each user to have their own code:
http://www.cipherdyne.org/fwknop/

I personally use knocking on my home server as if I'm really in a bind, I can attempt to use the local telnet client rather than having to have a program to create the magic packet.

While I've heard talk of it, I haven't actually seen any software that ties together with ssh (or login) that only allows the user from a particular IP to log in. That'd really be the ideal thing for ISPs or any system with lots of users. This way, even if you hack one of the codes, you still have to know which user that code is for. And of course you still have all of ssh's normal authentication mechanisms you have to go through.

references:
http://en.wikipedia.org/wiki/Port_knocking
http://www.portknocking.org/

Another solution

[IceCreamGuy]

Use a script like denyhosts, and I'm sure there are a ton of others out there that are just as good if not better. Unless your password is weak enough to be guessed in five attempts and the attacker isn't already in the denyhosts list, you shouldn't have to worry about too much. And, most importantly, just peruse your auth logs every now and then, it's not really that big of a chore.

Not So Shameless Plug

[value_added]

For those already familiar with Peter Hansteen's website, I'll offer a Thumbs Up recommendation for his Book of PF.

There's already been several stories on Slashdot either submitted by or about him, and I don't recall any mention of his book. I'd say his efforts if not his humility deserve some kind of reward, and the reduced sale price of $19.77 is a bargain.

Denial

[the eric conspiracy]

I've used a script to block servers that failed a certain number of attempts along with AllowUsers. That worked well for a couple of years, but was annoying in that you could see the attempts being made and knowing that if you made a config error you could be vulnerable. It seems to me that even after I got several hundred systems in my block list it wasn't making a difference since the pool of zombies was so large.

Now I just use key only access and AuthUsers and feel a lot more secure. I'm thinking I may add a white list of IP addresses as well. That would really lock things down pretty well.

If there's a bug on in openssh

[Nicolas MONNET]

... then there's no need to bruteforce it, and therefore blocking a botnet doing that is futile.

Re:If there's a bug on in openssh

[palegray.net]

I disagree. Should a new bug arise in openssh, I sure feel a lot better knowing that while I do enforce key-only authentication, I also restrict access to specific IP addresses. It's pretty hard to crack a service that you can't reach on the network due to packet filtering.

Re:If there's a bug on in openssh

[Z00L00K]

And if you have a three try block then you may still decrease the effectiveness of a botnet unless you are the specific target of the botnet.

But some bots are actually stupid enough to run the same list of passwords on every node, so it may work really well.

It's more the question of making your site less attractive than other sites on the net.

A hack for /etc/sysconfig/iptables to take care of the problem.

...
*filter
...
:blacklist - [0:0]
:ssh - [0:0]
...
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ssh
...
-A blacklist -m recent --set --name blacklist --rsource
-A blacklist -j DROP
-A ssh -m recent --update --seconds 60 --hitcount 1 --name blacklist --rsource -j DROP
-A ssh -m recent --set --name counting1 --rsource
-A ssh -m recent --set --name counting2 --rsource
-A ssh -m recent --set --name counting3 --rsource
-A ssh -m recent --set --name counting4 --rsource
-A ssh -m recent --update --seconds 20 --hitcount 3 --name counting1 --rsource -j blacklist
-A ssh -m recent --update --seconds 200 --hitcount 6 --name counting2 --rsource -j blacklist
-A ssh -m recent --update --seconds 2000 --hitcount 9 --name counting3 --rsource -j blacklist
-A ssh -m recent --update --seconds 20000 --hitcount 12 --name counting4 --rsource -j blacklist
-A ssh -j ACCEPT
...

disabling root login is idiotic

[Nicolas MONNET]

It's security theater.
There are good reason for allowing (private key only) root login, allong with autorized_keys command= directives.
Furthermore password+ssh keys is rather pointless.

Re:disabling root login is idiotic

[BitZtream]

Is that good reason: You're an idiot?

Re:disabling root login is idiotic

[Ernesto Alvarez]

While there might be good reasons to allow root access with a restricted key, that's hardly wise and there usually there is no need to do so.

As for the pointlessness of keys AND password, I think you're rather uncreative. There are a few uses of that scheme, the first one to come to my mind is a random password tightly controlled by the IT staff and periodically changed (and the user can do nothing about that) plus a key, under user control. The password allows enforcement of the security rules and insures that a stolen key is useless after a certain amount of time, even if the user chooses a guessable passphrase or leaves it unprotected, while having the security of a public/private key.

Re:disabling root login is idiotic

[Matt Perry]

Furthermore password+ssh keys is rather pointless.

Until your account is compromised and the attacker can now ssh into your other accounts without having to enter a password. I'd rather have to enter the password when the key is used. Better safe than sorry.

Re:disabling root login is idiotic

[Anonymous Coward]

Is that good reason: You're an idiot?

If someone is logging into your root account with your key, then it doesn't matter, you're already thoroughly compromised.

If someone is logging into your key-only root account WITHOUT your key... you have much bigger problems.

There is no case where disabling root login will protect you, except perhaps from yourself.

Re:disabling root login is idiotic

[Rennt]

No its not. Disabling root logins means the attacker has to brute force the username as well as the password, thus increasing the chances of the attack failing by a power of two. In actuality it is even more effective, as the attacker will usually try "root" and move on.

Same rationale exists on Windows. If you don't rename the "Administrator" account on setup, (or create a new admin account with a different name and delete the old one if you have a pre-installed box) you are asking for a world of hurt.

Even routers should have the default admin username changed, this is pretty elementary stuff.

Re:disabling root login is idiotic

[MadAhab]

Unless the root access is restricted to a single command - e.g. rsync for backups, scripts to generate checksums on bin and lib dirs, etc.

Needless to say, this should be run only from a secure host that has no inbound services except, if necessary, ssh.

Re:disabling root login is idiotic

[Anonymous Coward]

You've still failed if you run rsync as root. You've permitted remote access as an unidentified superuser not tied to an individual account. You want to run rsync, then run a fixed-command sudo--it'll work just as fine, *and* you can safely disable the login or the entire account if there's ever an issue. And there's an audit trail now!

Best of all, you don't have to worry about somebody somehow screwing up the keyfile--they don't have the permission to edit it even if they do get onto the system.

Re:disabling root login is idiotic

[corsec67]

Wouldn't a passphrase on the key itself be better in that case?

Re:disabling root login is idiotic

[Matt Perry]

Yes, that is what I am talking about. Make sure you have a password on the ssh key.

In all seriousness

[actionbastard]

This has been going on for years. Really. I've been seeing this crap in my logs since we started running an Internet-facing SSH host nearly ten years ago. It's always the same password based login attempts with the same dictionary/script used in the attacks. This is probably just some training exercise for Chinese hackers at some state-run school to see who can break into the running-dog Yankee Imperialist's computers the fastest.

Re:In all seriousness

[cmdr_tofu]

But this is distributed. Ie, from 13 different IPs there will be 13 different login attempts with different passwords targetting the same username.

To me, this seems like something new. I've been doing this for years to protect my users from your ordinary brute force attack: http://www.debian-administration.org/articles/187 Now, it is no longer effective. Of course my users should not have weak passwords, but rate-limiting by IP is no longer a trustworthy defense against dictionary attacks.

Re:In all seriousness

[mikael]

The botnet owners have large lists of likely usernames/passwords and IP addresses to try. In the past they just assigned a bot to try out a complete list of usernames/passwords to try for a range of IP addresses. Now, they just give each bot a range of usernames/passwords for a complete list of IP addresses. It doesn't affect the processing time required, but makes it harder to ban hosts.

I'm safe...

[hoytak]

I've now changed my password from Thomas to ThomasX, where X is a digit that I'm not telling.

Re:I'm safe...

[Main Gauche]

pinkie? C'mon, gimme a hint.

Re:I'm safe...

[Anonymous Coward]

I just cracked it. Very clever using a roman numeral 10 there.

Re:I'm safe...

[Anonymous Coward]

I prefer to use the password hunter2, because the internet automatically turns it into asterisks for me. Unless you copy/paste them.

Re:I'm safe...

[spartacus_prime]

I tried to make my password "penis," but it said it wasn't long enough. :(

Re:I'm safe...

[Phroggy]

reference

Re:I'm safe...

[Anonymous Coward]

Maybe if you bought some V1aG RA from one of those reputable online retailers that is so kind as to email everyone about how they can get a longer, better penis it will work?

Stop collaborate and listen.

[jonpublic]

Just checked my auth logs and I'm seeing hundreds of various IPs, some of which are connecting up to 20 times. Definitely a new twist. I'll have to do some poking around to see what kind of machines are doing the probing. ( Is it compromised windows boxes?)

Re:Stop collaborate and listen.

[Anonymous Coward]

( Is it compromised windows boxes?)

Conficker?

My server got attacked last Thursday

[h4x354x0r]

SSH login attempts from hundreds of different IP addresses. Could not get my IT department to block the port at the firewall. It's an old Mac OSX server - thus, why the POS locked up within minutes of the attack starting. Come to think of it, I haven't used SSH for ages. I always ARD into it to administer. CLICK. No more SSH.

At least it made me review my server security. I was way too lax, knowing how little value the data, or even the server itself, has. But the attack itself still annoyed me, so I tightened that bitch up real good (well, as good as you can tighten up an old Mac server).

Re:My server got attacked last Thursday

[mellon]

Um. You realize, of course, that remote desktop is a lot less secure than ssh, right?

It doesn't matter if people are trying to pick the lock on your door. What matters is whether they can pick the lock. Use RSA-based authentication, and no amount of brute force is going to improve the odds of their breaking in to the point where it's worth bothering.

Remote desktop, on the other hand, is completely brute-forceable. If you're not seeing brute force attacks, it's because nobody's bothering, not because you're not vulnerable.

Re:My server got attacked last Thursday

[dr2chase]

They're coming pretty steadily. I read the FA, logged in to the ssh-receiving box, looked at the logs, and a half-dozen showed up while I was looking. Makes me wish I had the time to run a honeypot.

Based on my quick reading of the ssh/sshd documentation, I created an empty ~/.ssh/rc file for the accounts with known-good passwords (i.e., mine) and then put "kill -9 $PPID" in /etc/sshrc.

That seemed to work, though I know it will be bad for X11 (which I never use over ssh to my home box).

There may be more elegant ways to do this, but if there are, I didn't find them quickly (which is to say, the ssh documentation, like all Unix documentation, sucks rocks).

Re:My server got attacked last Thursday

[Anonymous Coward]

We saw it focus on Mac OS X too (ignored Linux and Windows [cygwin] port 22). Given that TFA is named "That grumpy BSD guy" makes me think any BSD based systems were targeted. I wonder if anyone's cracked iPhones were targeted.

Re:My server got attacked last Thursday

[RzUpAnmsCwrds]

Um. You realize, of course, that remote desktop is a lot less secure than ssh, right?

Remote Desktop uses TLS and X.509 certificates, so it's not exactly trivial to crack. It's easily as secure as SSH using password-based authentication. It's definitely *more* secure if your users never bother to actually check unknown server keys.

Now, compared to SSH using only key-based authentication, Remote Desktop isn't as secure. Unless you use smart cards for authentication with Remote Desktop, which are probably more secure than having your private key stored on your computer. Unless it's encrypted with a strong passphrase. Unless your computer has been rooted and has a keylogger.

Bottom line? Both systems can be plenty secure. It's all in how you configure and use them.

Re:My server got attacked last Thursday

[Anonymous Coward]

LOL. So wrong on so many levels, it's not even worth it to bother correcting you. Please turn in any security or systems administration related badges to the front desk and be on your way.

Re:My server got attacked last Thursday

[Anonymous Coward]

Use RSA-based authentication, and no amount of brute force is going to improve the odds of their breaking in to the point where it's worth bothering.

Pshaw. Just get a big botnet and try all 2^1048 RSA key possibilities and there you go.

(Yes, I know how big 2^1048 is. I'm kidding)

Re:My server got attacked last Thursday

[eric76]

Just get a big botnet and try all 2^1048 RSA key possibilities and there you go.

My RSA keys are 8192 bits.

Re:My server got attacked last Thursday

[mellon]

Remote Desktop uses TLS and X.509? Could have fooled me. It just asks me for a password; as far as I can tell it goes over the wire in the clear. Maybe if you set it up in a special administrative mode you get TLS. Even so, as long as the machine being controlled is only checking the password, and not the cert, that's not good enough. But yeah, I'm certainly not claiming ssh with a password is in any way secure. It's not - you must use RSA keys, whether it's in the form of X.509 certs or ssh keys.

Re:My server got attacked last Thursday

[mellon]

I generally use 2048. 1024 may be prohibitively expensive to brute force now, but why take chances?

Don't just run it on a higher port.

[Anonymous Coward]

Be proactive on port 22 as well. At the advice of another comment I saw on /. a year or so ago I'm running a honeypot, with three static ports (one of them 22) and 4 roving ports. Establishing a TCP connection to any of them causes your IP to be instantly added to an iptables blacklist. It's worked pretty well; I've got about 2-3 unique addresses trying per day, and about 294 have been blocked since mid-December 2008. It takes care of both port scanners and bots deliberately connecting in order to try and get root on my server.

Of course, the only way to get root on the server anyway is through a Yubikey OTP or the 64-character randomly generated password I have on an encrypted partition somewhere in case my Yubikey is ever fried/stolen/lost.

Re:Don't just run it on a higher port.

[Ernesto Alvarez]

Is there any difference with respect to a PKCS#11 token?
I've been thinking of using one of these tokens as a "road warrior" SSH key, but then realised that since they need drivers to be useable, that wouldn't be practical to use on machines not owned by me.

Also, why not S/KEY instead of one of those yubikeys (or at least the random password)?

Re:Don't just run it on a higher port.

[russotto]

At the advice of another comment I saw on /. a year or so ago I'm running a honeypot, with three static ports (one of them 22) and 4 roving ports. Establishing a TCP connection to any of them causes your IP to be instantly added to an iptables blacklist.

So if you forget to add the port to the ssh command, you'd lock yourself out. Not such a good idea IMO.

After getting compromised a few years back (weak password on an account I'd forgotten about), I run keys only, a different key for each host I access from (including my laptop), and allow only specific accounts access. So far, so good. If I ever needed access from someplace where I couldn't have my laptop or even transfer the key, I'd need to come up with something else, though.

I always wondered about that

[Anonymous Coward]

Always these stories about zombies dossing this or bruteforcing that, but never a hint as to where these zombies came from, who they are, etc. You'd think that if you can see them in your logs that easily, it should be possible for their isps to see them as well, or else someone could inform them. Why aren't isps sending zombie customers a letter a la "please clean your machine, or we'll shut down your connection". Is it just that they can't reap profits from the customer anymore? In that case, why don't we just blacklist all isps who refuse to terminate zombies?

Re:I always wondered about that

[cdrguru]

The problem with ISPs is they would like to do as little work as possible. Contacting the customer can involve either management or legal - neither one is going to be happy about getting involved with a "trivial" problem.

They also want to be "customer friendly" and that means not shutting people off for possible TOS violations. Sure, it may be in their TOS "thou shall not break into systems", but that is mostly there for liability protection. In my experience, ISPs do not respond to information that their customers are attempting to break into systems.

Yet another facet of this is there is no law against attempting to break into a system. It is only (possibly) illegal to actually break in. So until you have a break in, the ISP customer has done nothing wrong, legally. Further, until you have $25,000 worth of damages (provable), no law enforcement agency in the US will touch it. And even at that level, most are reluctant.

The end result is this is a free ride for people and nobody is ever going to do something about it.

quickest fix

[capn_nemo]

While it's true there are a variety of techniques that can increase security, I've found simply moving to a new high-numbered port eliminates all random login attempts. Yes, security through obscurity is all it's cracked up to be, but for now, I've eliminated the problem with a pretty quick fix.

Re:quickest fix

[cmdr_tofu]

Good idea, you should run a honey_sshd on port 22 as well.

Tarpit

[Anonymous Coward]

I simply use the tarpit xtables module from http://xtables-addons.sourceforge.net/. It holds the connection open consuming resources per x connection initiated by the zombified machine.

Good Odds

[Anonymous Coward]

In this particular attack after 'root' and 'admin' has been tried, the zombies try 'james' which is the most common first name in the united-states, then they run an alphabetical list of only first names. (as per the article)

Sample:
http://www.bsdly.net/~peter/slowbrutes.all.txt

These zombies are seeking out accounts that are the most likely to have high up privileges.

Since people tend to prefer usernames that reflect their own in some way, and are easy to remember, your first name is probably your most preferred.

And following that, the only chance you really get at using your first name is probably on one that you own.

If you own it, you're most likely to have privileges that exceed other users on your system.

Goodness.

[geekboy642]

There sure are a lot of people who didn't bother to read the article.
The point of these attacks are that it's a coordinated botnet attack. Meaning if you block any single IP, or even a large subnet, you've cost the attacker nothing. Fail2ban, denyhosts, all of these won't even slow these attacks down.

Re:Goodness.

[Anonymous Coward]

What's worse, if you have a long timeout before re-allowing access to an IP (Or if you never re-allow access), your deny list can get very long, reducing iptables performance.

Re:Goodness.

[darhand]

That is why I use DenyHosts, it shares the ip's of brute force addresses among its users. That way you don't get attacked by all the bots in the botnet. If you use a rule like 3 strike-out to it you can even contribute and help others before the masses of zombies are on their doorstep.

Re:Goodness.

[garry_g]

> Fail2ban, denyhosts, all of these won't even slow these attacks down.

As for denyhosts, yes, you can slow them down, as it can share blocked hosts among all users ... I typically get about 5-10x as many from the denyhosts server than I block new remote hosts ...

meept

[larry bagina]

last post!

easy and hard is not absolute

[kentsin]

Think of cutting the space into several (2) pieces. Round one we attact piece 1, round 2 we can skip piece 1 and attack piece 2 and round 3 we can skip 1 and 2 and attack only 3.

It is good to check what they are attacking before we urge everyone to choose a hard password.

Noticed It

[cheese-cube]

I noticed this last night when lwatch just start spewing out failed authentication attempts. One point that I don't really see mentioned is that they will try a wide variety of different usernames. A snippet from auth.log:

Apr 12 23:16:27 host sshd[523]: Address 202.42.66.11 maps to changi.aglow.com.sg, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Apr 12 23:16:27 host sshd[523]: Invalid user warpuser from 202.42.66.11
Apr 12 23:16:27 host sshd[523]: pam_unix(sshd:auth): check pass; user unknown
Apr 12 23:16:27 host sshd[523]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.42.66.11
Apr 12 23:16:29 host sshd[523]: Failed password for invalid user warpuser from 202.42.66.11 port 58502 ssh2
Apr 12 23:16:32 host sshd[525]: Address 202.42.66.11 maps to changi.aglow.com.sg, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Apr 12 23:16:32 host sshd[525]: Invalid user fwadmin from 202.42.66.11
Apr 12 23:16:32 host sshd[525]: pam_unix(sshd:auth): check pass; user unknown
Apr 12 23:16:32 host sshd[525]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.42.66.11
Apr 12 23:16:35 host sshd[525]: Failed password for invalid user fwadmin from 202.42.66.11 port 58869 ssh2
Apr 12 23:16:38 host sshd[535]: Address 202.42.66.11 maps to changi.aglow.com.sg, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Apr 12 23:16:38 host sshd[535]: Invalid user mailadm from 202.42.66.11
Apr 12 23:16:38 host sshd[535]: pam_unix(sshd:auth): check pass; user unknown
Apr 12 23:16:38 host sshd[535]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=202.42.66.11
Apr 12 23:16:40 host sshd[535]: Failed password for invalid user mailadm from 202.42.66.11 port 59272 ssh2

An easy method to out-smart them that has been mentioned before is to simply change the SSH port.

Re:Noticed It

[Culture20]

Your log snippet shows a script kiddie from a single IP, not a bot-net.

iptables goodness

[grasshoppa]

Once again, we have a built in linux goody which helps us out;
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --set --name sshattack --rsource
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --rcheck --seconds 300 --hitcount 3 --name sshattack --rsource -j LOG --log-prefix "SSH Drop: "
-A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --rcheck --seconds 300 --hitcount 3 --name sshattack --rsource -j REJECT --reject-with tcp-reset
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

The above allows three connections in a 5 minute period to port 22. After that it rejects any further connection attempts until the 5 minute timer is up.

Re:iptables goodness

[Anonymous Coward]

what happens if they keep attempting it 24/7 and the port now drops all connections constantly? How do you log back in with ssh?

Re:iptables goodness

[grasshoppa]

The recent module in iptables tracks per source IP address, so that's not a concern.

Re:iptables goodness

[Anonymous Coward]

Is this ip specific? ie: does it trace who to lock out? Or are you just making it really easy to DoS your ssh server?

Re:iptables goodness

[wytcld]

Which means this won't work, since what I see in the logs (at least in the last go-round with this stuff) is one attempt per remote IP, yet a coordinated distributed dictionary attack. What we need is a ruleset that properly spots this attack pattern, then locks down port 22 entirely except for defined, fixed-IP administrative exceptions, just if there is any pattern of failed attempts over a longer period.

In a slightly-different recent case, I saw someone get ahold of an ftp login. The uses of that login were one-off per remote IP. The IPs were in Ukraine, Russia, China, Texas ... with hours between successive attacks. From what was attempted on the logins, it was obviously a generic attack, not well-directed at the particular server. Quite likely an infected client system divulged the login to the botnet that infected it, and the botnet then focused the distributed attack. As with ftp, so with ssh. They don't want you to even notice it in the logs. Each IP will be used for one transaction attempt with you, spaced hours apart.

We need tools to spot these slow-moving distributed attacks. The single bad login attempt needs to be correlated with others from completely different IPs, over a span of days, not just minutes.

Re:iptables goodness

[Qzukk]

then locks down port 22 entirely except for defined, fixed-IP administrative exceptions

This is my default configuration, with a port knock pattern for emergency access.

Re:iptables goodness

[drcesteffen]

Wouldn't it be better to TARPIT them rather than --reject-with tcp-reset? That said, if they are generating one query from each IP address and trying to log in more than 300 seconds apart this may have no effect. Perhaps all firewalls without ssh enabled should TARPIT attempts to connect to slow this down. Perhaps one could create a script on all computers to change the ssh port, assumes you are using a nonstandard high port, as a function of time and to tarpit all other ports.

Re:iptables goodness

[jonaskoelker]

The above allows three connections in a 5 minute period to port 22. After that it rejects any further connection attempts until the 5 minute timer is up.

Exactly what does this mean? Is it

handlepkt(pkt) { if num_rows(SELECT * FROM failed_connection_attempts as row WHERE pkt.srcip == row.srcip && first_packet_time > now minus 5 minutes) >= 3 then drop connection else continue handling pkt }

?

fail2ban and firewall won't help with this attack

[baileydau]

Likewise - I use fail2ban with iptables to drop any packets from someone who fails auth about 5 times in a few minutes. I've toyed with the idea of adding them to a global blacklist for all servers in all locations, but in reality this solution works just fine.

If you RTFA, they tell you that these attacks are coming from different machines, presumably so they don't trip such things as fail2ban et al.

Looking at the logs he supplied, this is a _very_ slow attack, the attempts are many seconds, or even minutes apart. You would have to have a very guessable username / password combination for it to work.

I would comment though that I'm not seeing anything like this attack in my logs. I personally use IPTables rules (using hashlimits) to limit 1 connection / IP per minute to my ssh ports. Typically, I see about 3-6 attempts per day (each only gets 1 or 2 tries before they get blocked). Doing an optical integration of my recent logs shows less than a dozen per day and they are not concentrating on any particular username (with the exception of root).

Prior to using hashlimits, I used to get hundreds or even thousands of attempts per day. My record was over 6,000 attempts from a single host. One guy at work has reported over 30,000 attempts in a single day.

I personally don't like the concept of fail2ban as it is permanently adding an IP address to your banned list. As most of these IPs are dynamic, keeping them in your banned list isn't really serving any useful purpose. I personally prefer a system that temporarily bans an IP.

damn!

[binaryseraph]

And here I thought this would be about zombies trying to scratch through my door or eat my cats- you know, in a really laid back, maybe give up and come back later kinda way. what a let down.

Post your banlist

[UnRDJ]

I get about 5 of these a day, on a relatively small site. I wrote a small shell script out of sheer boredom that parses hosts.deny and gives me country and hostname info. Here's the output from the past week or so. It seems to confirm that most of these are from public isps overseas.

117.21.249.75 CN, China
121.166.163.142 KR, Korea, Republic of
122.128.36.3 KR, Korea, Republic of
189.19.245.182 BR, Brazil 189-19-245-182.dsl.telesp.net.br.
200.111.157.187 CL, Chile
201.6.124.155 BR, Brazil c9067c9b.static.spo.virtua.com.br.
202.229.120.74 JP, Japan
203.125.51.23 SG, Singapore
207.5.149.188 US, United States 149-188.suscom-maine.net.
211.87.224.190 CN, China
211.99.203.168 CN, China
216.164.162.155 US, United States 216-164-162-155.pa.subnet.cable.rcn.com.
217.219.67.86 IR, Iran, Islamic Republic of
218.241.177.241 CN, China
219.121.10.35 JP, Japan m010035.ppp.asahi-net.or.jp.
221.3.131.110 CN, China
61.184.136.164 CN, China
61.191.53.99 CN, China 99.53.191.61.broad.static.hf.ah.cndata.com.
77.79.88.247 TR, Turkey reverse-77-79-88-247.grid.com.tr.
80.179.149.122 IL, Israel 122.sharatim.co.il.
82.165.27.220 DE, Germany p15173261.pureserver.info.
83.19.20.66 PL, Poland byq66.internetdsl.tpnet.pl.
84.53.78.183 NL, Netherlands 84-53-78-183.wxdsl.nl.
87.197.110.47 SK, Slovakia static-dsl-47.87-197-110.telecom.sk.
99.53.191.61 --, N/A adsl-99-53-191-61.dsl.mtry01.sbcglobal.net.
200.219.194.74 BR, Brazil static.200.219.194.74.datacenter1.com.br.
202.190.177.144 MY, Malaysia
164.77.195.60 CL, Chile
89.119.5.106 IT, Italy 89-119-5-106-static.albacom.net.
221.154.206.233 KR, Korea, Republic of
218.208.91.111 MY, Malaysia
65.120.74.22 US, United States
210.185.64.195 AU, Australia 210-185-64-195.intrapower.net.au.
202.168.58.111 AU, Australia 111.58.168.202.static.comindico.com.au.
85.25.71.36 DE, Germany loft1551.serverloft.de.
193.136.39.26 PT, Portugal genid.dcc.fc.up.pt.
150.146.40.173 IT, Italy mspasiano.cedrc.cnr.it.
221.194.128.66 CN, China
82.135.192.72 LT, Lithuania 82-135-192-72.static.zebra.lt.
80.10.250.17 FR, France
207.28.220.1 US, United States voyager.iavalley.cc.ia.us.
164.77.208.198 CL, Chile
38.107.141.131 US, United States host-38-107-141-131.mtl.net.vexxhost.com.
222.218.156.41 CN, China

Re:Post your banlist

[Anonymous Coward]

i've got fail2ban running on 3 servers, and i'm posting banned IPs from ssh here:

http://twitter.com/bannedips

at some point, i'm hoping to do a google maps mashup of the IPs and location.

Re:Post your banlist

[inject_hotmail.com]

Could you be so generous as to post the script that would create such a useful report?

Story of low hanging fruit

[dbIII]

I had to re-install one of those low hanging fruit which was taken over via a dictionary attack about four years ago.
For some reason the guy that was looking after what should have been a simple mail server and incredibly basic web server decided to change things so that everyone with a mailbox had shell access. Then he put a compiler on there. Then, sick of having to "su" all the time he changed the permissions of everything in /etc (system configuration files) and who knows where else so that any user on the system could change them (this guy loves "chmod 777" - lets anybody do anything to the file). Then a user changed their complicated initial password to "coffee", which required the same guy to help since the system rejected such simple passwords. To make things worse the username with that password is a very common girls name. The next step, which is where I failed, was the guy looking after the machine (who should have done nothing other than add new users and edit the very simple plain HTML web pages) asked for ssh access so he could work from home, but he didn't know what the IP address would be. I gave him a hole in the firewall to get to what used to be a fairly secure box, and a few days noticed the thing appeared to be scanning ports all over the place on a Friday afternoon, and it did a few other odd things (ps and grep had been obviously altered) which meant pulling the plug. From looking at the disk afterwards it looked like somebody got in via dictionary attack and once they were in the permissions were such that they could do just about anything they wanted and the thing was rooted. Maybe they built some lkm thing on there with the compiler or just ran a rootkit, it's hard to tell athough "/etc/init.d/functions" had weird stuff in there to start up all kinds of things. Obviously you never even let something like that even do a clean shutdown - you pull the plug and make sure nobody gets a chance to put the disk in another system without knowing what they are doing (read only, no exec). Luckily it didn't take that long to rebuild the thing (new disk, even different media since an upgrade had come out and this time I set up sudo for the guy using it) but I prefer to do other things on weekends, especially when a school reunion was on that weekend. On Monday the users had to all choose new passwords and the "chmod 777" guy was shown a lot of things starting with how easy it is tell ssh to only let in specific users and how to use "sudo" instead of changing permissions everywhere.
To sum up - it only takes a few incredibly stupid actions to add up to low hanging fruit.

Re:Story of low hanging fruit

[MadAhab]

"chmod 777" = justifiable homicide

I should add

[dbIII]

I know the way to do this to allow only those specific users that need ssh access (one or two in the above case - and never root on an external facing box), use keys instead of passwords, and only accept connections from the IP addresses that legitimate users will be on. None of those things are difficult. The above example shows what can happen with a far too relaxed approach.

My Solution

[ironicsky]

I was having similar brute force attacks.
I've made some alterations to protect my server from brute force SSH attempts.

1) Moved SSH to another random port
2) Bound the SSHD to an IP address that is not used for Web/Mail/FTP, etc.. So the IP should generally see less traffic
3) Disable Password Authentication, Users who are given SSH access must use a password protected key file
4) Disabled Root SSH Login
5) Setup the system that 3 failed logins add the entire IP Subnet(X.X.X.0-X.X.X.255) for 15 minutes, 5 failed attempts 1 week, anything else is a never ending ban. (iptables and hosts.deny, just in case)

Re:My Solution

[Ash-Fox]

4) Disabled Root SSH Login

Woha, there are still Linux distributions out there that have root logins enabled on SSH by default?

Re:My Solution

[Anonymous Coward]

5) Setup the system that 3 failed logins add the entire IP Subnet(X.X.X.0-X.X.X.255) for 15 minutes, 5 failed attempts 1 week, anything else is a never ending ban. (iptables and hosts.deny, just in case)
uhm...
so if i'm on your subnet, i just have to connect 6 times to your server, and you won't be able to connect to it? nice...

pam_abl does the trick

[tommi]

Im really impressed by pam_abl. It covers every pam enabled service so smart password guessers which may traverse between protocols will be covered as well. It's configurable as to how to handle guesses from hosts as well as users.

Re:pam_abl does the trick

[otis wildflower]

/agree++++

I dropped pam_abl on a loadbalancer that had been getting sshspam'd, works very nice, though unfortunately it's not (yet) in Ubuntu (at least 8.04)..

Only feature request I would have would be for pam_abl to have a 'blackhole to 127.0.0.1' host route option.

Re:fail2ban and firewall won't help with this atta

[perlchild]

I'm using fail2ban and it configurably allows you to set how long you want to ban, and permanently isn't the default.
You must be thinking of some other tool

Really?!

[sourcery]

Will they be in town all week? Can we still get tickets?

So the real question is...

[evilkasper]

.. what's your Zombie plan?

Re:fail2ban and firewall won't help with this atta

[SnowZero]

Fail2ban is actually configurable and temporary. Personally I've set it up to ban for an hour after 3 failed attempts. In the past this stopped most bots, who would go elsewhere if they were even temporarily banned. It looks like this new one is slow enough (<1 attempt/hr) that my current settings don't detect it. Of course, guessing username+password that way it'll take forever to get in, but it is kind of irksome.

Why do they have to be successful?

[FlyingBishop]

This can only mean that there were enough successful attempts at guessing people's weak passwords in the last round that our unknown perpetrators found it worthwhile to start another round.

There's no reason to assume this has any significant returns. I'd assume, rather, that the botnet herders occasionally find themselves with nothing better to do, so they just run this stuff in idle cycles. No real logic to it, they just have a botnet that isn't currently useful for anything else. And a .0001% chance of getting something is better than 0%, since it costs them very little if they've already written the requisite brute-force code.

Everybody has their formulas

[mcrbids]

Mine is:

1) No passwords for SSH. At all.

2) SSH keys that require passphrase authentication.

3) SSH on a high port.

That's it! No issues, that I'm aware of...

Morpheus and diavalo in iptables?

[Anonymous Coward]

Is it possible to block/ban morpheusf*ck*ngscanner and the south american one, diavalo iirc, in iptables by examining the first log line for the names of the scanner (the same text that pops up in each log line every hit) or similar phrase, and writing a temporary or permanant logdrop rule for the specific ip so iptables is updated immediately after the first log line/port scanned instead of allowing a couple dozen or more attempts from these scanners/bots? I'd like to do this in iptables instead of denyhosts or fail2ban if possible

Also, when adding a rule to iptables that's already entered in a system that is live, what's the syntax so that the rule is added to the bottom of the ruleset? For example, if I have a long list of ip addresses that have single "logdrop" rules, and I want to add, ie: 10.0.0.8 (let's make believe it's a public ip) to the _bottom_ of the iptable ruleset, what's the syntax? Otherwise adding it to the text file, saving/exiting, then re-running the file as an executable that flushes the rules and then adds in the new ruleset takes time/isn't immediate, especially with large rulesets that take time to load completely on slower systems.

Thanks!

[jaminJay]

I forgot to install denyhosts when I 'up'graded to F11 on Friday!

MOD UP - NUKE IT FROM ORBIT

[Anonymous Coward]

MOD UP, it's the only way to be sure.

Distributions must use blockers as a standard.

[houghi]

Obviously ssh should be off by default. Many people use a different port for ssh, as long as you understand that that is security trough obscurity, that is fine. It is not a real option if your system is a multi user system. Imagine if each webserver on the internet ran on a random port. Not very nice.

So then you must ask yourself if everybody in the whole world is allowed to run ssh to you or just a few.
You can already use your hosts.allow to block many and allow other IP adresses.
Then you can ask yourself if each user is allowed to connect by ssh or not and use AllowGroups or DenyGroups to give access. (or AllowUsers and DenyUsers)

I can not put my ssh on a different port, as I am sometimes in places where only that port will work. I have ssh also running on port 80 and 443, as sometimes only those work. Next to that I use blockhosts which blocks IPs after 3 attempts and is very easy to use as described here.

So with all this, I have the following possible restrictions and they can be all used or none or in any combination.
1) Access on a different port.
2) Access only from certain IP adresses or ranges
3) Allow access only for certain users
4) Block the IP after a certain amount of failed attempts
2)

Re:Distributions must use blockers as a standard.

[eric76]

Obviously ssh should be off by default.

I don't think that is obvious at all. Quite the contrary -- ssh is probably the most secure method one has of connecting. Better to leave it on and turn off things like telnet.

I would like to see the password login shut off by default. If soneone wants to use plain passwords on ssh, let them edit the /etc/ssh/sshd_config file themselves to enable them.

Re:fail2ban and firewall won't help with this atta

[Sentry21]

I personally don't like the concept of fail2ban as it is permanently adding an IP address to your banned list. As most of these IPs are dynamic, keeping them in your banned list isn't really serving any useful purpose. I personally prefer a system that temporarily bans an IP.

fail2ban temporarily bans IPs. It removes them after a configurable time limit.

We Need

[berenixium]

BRAINS! MORE BRRRAINS! Shotguns, man. we need shotguns. Shoot those infected servers dead fast! They are after your goddamned brains!

If the account is compromised

[Nicolas MONNET]

it's compromised.
And having to type a password too often is not added security, because it only adds minimal, easily circumvented security in the rare case where you're already fucked, but it annoys the hell out of users *all* the time, causing them to have unsafe practices.

Re:If the account is compromised

[Matt Perry]

You can use ssh-agent if you get tired of typing your password over and over.

Go ahead, brute force a private key

[Nicolas MONNET]

Good luck with that.

Re:Go ahead, brute force a private key

[Rennt]

Look up defense-in-depth and the reasons it is used. Encrypted keys may be the strongest link in the chain, but if they are the only defense you have then you are SOL the instant a vulnerability is discovered.

Why would you sit back after implementing private key access without any further consideration to the other techniques for making ssh even safer? For home servers this is probably sufficient, but if it is your job to secure systems then this would be negligence - possibly criminally so, depending on the industry you support.

Re:Go ahead, brute force a private key

[Anonymous Coward]

Good luck with that.

Tappity, tappety, tap. Done. Guess you shouldn't have used an 80 bit modulus.

FIGHT BACK NOW!!!!

[mcnazar]

Any SSH attempt on my server generates an automatic abuse EMAIL to the offender's server and the upstream provider.

I generally get a 70% reply rate on my email from system admins saying that thanks to the notification they have found and patched the trojan responsible.

If enough of us would run this script then any such future attack would generate enough email notifications to all responsible admins then all ssh bots will be cleansed in a couple of attacks.

Read about and get my script from here: http://panthersoftware.com/articles/view/5

Re:FIGHT BACK NOW!!!!

[CompMD]

I had something like this (but far less automated) going back in my one-man-IT department days. I also had good responses from admins who generally felt bad and wanted things fixed up on their end ASAP. My employer told me it was a waste of my time and to stop because I wasn't "the Internet police." He looked stupid after I was gone and my incompetent replacement managed to get them hacked. He actually allowed someone to set a password to "password" because they complained that my old password requirements were too difficult. I didn't shed a tear.

Re:FIGHT BACK NOW!!!!

[cdrguru]

The experience I have had with reporting such attacks has been "F... off!!!" or nothing. Especially from anything .nl - it is evidently the enshrined right of all ISP customers there to break into servers worldwide. Even in the US, ISPs have generally not responded or responded with questioning the log timestamps or suggesting getting a court order.

The result is that I just don't see the point. The idea seems to be to allow "minor" offenses to build up and up until the perpetrator believes they are untouchable. Then, maybe, they do something so incredibly high profile that it no longer can be ignored.

However, I still believe that nothing is ever going to happen to people that break into systems like this. It's the Internet and that sort of behavior is expected. If you put your computer on the Internet, you better expect to have break in attempts. And if any succeed, it was your own fault.

Some more info

[six]

For all I know they may have been at it all along, probing other parts of the Internet

I don't think so, my firewall has many public adresses in distant subnets, and I've seen the exact same patterns as the OP.

So my (informed) guess is that's actually a second run.

Well, my current crop of zombies are brain-dead.

[bplipschitz]

Maybe that's redundant, but "james" has tried 7500 times in the last 5 days to login to a machine that neither allows password authentication, nor has a user named "james".

Something is broken on their end.

My Server got hit.

[Brycewb]

My ftp on my server got hit with over 45MB of logs of brute force attacks to my ftp server, none however got in, and the logs pointed to dedicated servers being hosted by OnRamp and Leaseweb, in Amsterdam and Ohio.

Passwords are a terrible idea

[betterunixthanunix]

"IMHO if the passwords are strong enough there is nothing to worry about"

The problem is that most users are not capable of choosing a strong password. Even when you try to enforce policies about minimum password strength, users will manage to choose weak passwords; aside from the world's most common password (password1), there are plenty of people who use their own username as a password -- and requiring non-alphanumeric symbols won't stop them: jane123 will just becomes j@ne123. Minimum password lengths won't do it either, since the users will either write their password down (not an issue for botnets, but certainly an issue for high profile targets) or just come up with something that is easily guessed (abc123abc123).

Public key authentication is better but not by much. The real issue with it is that users do things like not having a passphrase for their private key (which is even more convenient than a weak password) and making copies of that key everywhere that they want to log in from (some might even carry the key around on a thumb drive). Public key authentication will solve the problem of distributed brute force attacks, but it does not really solve the problem of users having their accounts compromised by a determined adversary.

Assuming that your system is high profile enough to be worth the expense, you would really want to use a one-time password device. If the device is stolen, you have a problem, but beyond that there is not much an adversary can do. You can even mitigate the problem by requiring check-ins -- a user must login at a certain time, so if their device was stolen they will be forced to call helpdesk and report the problem.

Of course, it really depends on your security needs. None of the systems I administrate are high profile enough that I am worried about anything other than a distributed brute force attack, so public key authentication is good enough (an attacker who wanted to take over some Linux servers for his nefarious deeds could find an easier target with equal computing power, and the data on the disks is just academic research which will be published anyway).

Re:Passwords are a terrible idea

[Dark_Gravity]

some might even carry the key around on a thumb drive

If the only place the private key is stored is on a thumb drive on the user's person, that should make for a relatively secure authentication scheme, especially if the key requires a pass phrase.

Re:Passwords are a terrible idea

[jimshatt]

How is carrying around a one-time password device that can be stolen better than carrying around a thumb drive with a public key?

Re:Passwords are a terrible idea

[Thad Zurich]

How is carrying around a one-time password device that can be stolen better than carrying around a thumb drive with a public key?

If your "one-time password device" has no PIN, and it is your only authenticator, then it isn't better (you're back to weak single-factor authentication). If it does have a PIN, and/or is combined with a password (both, I hope), then you now have strong two-factor authentication. Unless, of course, you wrote the PIN down and stored it on/with the device.

However, before you worry about this problem, makes sure you've killed all the LM authentication in your enterprise that's happily coughing up hashed passwords and usernames to anything and everything it talks to.

What about Shimmer?

[kenrick]

http://shimmer.sourceforge.net/

Adds another layer of security if you've got SSH running.

Probably more effective than you think

[Angst Badger]

Some years ago, I worked for a partner of a then-enormous national ISP that shall remain unnamed, but its initials are AOL. At one point, I had access to a large list of usernames and passwords of their users. Out of curiosity, I performed a statistical analysis of the data and discovered, to my not very large surprise, that about 20% -- I forget the exact figure -- had passwords that were either "password", "secret", or their username. In other words, if you know one of their usernames, you have a roughly one-in-five chance of being able to compromise their account. (You'll have to take my word for this, since AOL users are a lot harder to come by now than they were five years ago.)

One would hope that people with actual ssh accounts would be smarter, but I frankly doubt it. This being the case, the wise administrator will require strong passwords. Even otherwise smart (i.e., non-AOL) users can be amazingly clueless about basic computer security.

Because security is a trade-off

[Nicolas MONNET]

And forcing users to go through hoops for a negligeable gain in security is worse than nothing.

Re:Because security is a trade-off

[Rennt]

Nearly all of the significant improvements to security we are talking about here are implemented by the sys admin and are completely transparent to users.

The only change that I can think of which the users need to be aware is using a different port - hardly strip searching people at the airport is it?

Re:My Solution -- question for you...

[inject_hotmail.com]

One thing I don't understand well is the idea that admins must disable root's ability to login remotely via SSH. Could you explain your reasoning? (I'm not being sarcastic, I'm curious...and I don't know any linux admins other than myself with which to discuss the topic)

I can understand it via FTP, but SSH is different. You see, I would imagine that any proper admin has a wicked long password, where most users have a relatively short password, thus introducing a weak point. If a user has a relatively easy username and password combination, an attacker could gain access to a server. Once in, the attacker can spend all day attempting to su as root, bypassing any potential brute force blocking measures via IPTables.

Is it theorized that an attacker would be less likely to guess a proper username? Thus, making any user's password more secure by a few orders of magnitude? Or is it just the fact that you can let someone run literally forever attempting to crack root, but won't be able to?

Personally, I subscribe to the "put ssh on a different port" and have a long password school of thought. 99% of all regular users don't need ssh, so, they won't be inconvenienced by a non-default port, and if they do, it's easy to pre-program their ssh client to save the proper port. Furthermore, I'd say a 20 character password is enough to essentially take "forever" to crack...unless of course, there's some hash collision that will exist with a smaller set of characters...which is not likely, right?

I used to have thousands of FTP brute force attemps daily. I threw in some IPTables rules, cutting off an IP after 6 attempts (stupid IE connects 4 times per actual "human" login attempt! Yes, 3 to try "anonymous" then it prompts the user for u/p combo, and tries that!!!). My bandwidth usage went down, and my logs aren't hideous anymore.

My Fav type

[cdpage]

These are my Favorite type zombies... much more fun to take down. the new breads are not nearly as fun.

Too vicious, too fast, communicate with other zombies...

We need more dumb, slow, possibly confused zombies. :)

Re:My Fav type

[Anonymous Coward]

They must have modelled these ones in the style of the original Dawn of the Dead...

Re:why are passwords even allowed? Sooo

[davidsyes]

This is not so scary: we now have zombies that gnibble instead of naw... But, will they goo "huuh huhhh", or "RAHRRR"?

noticed the same thing.. know why too

[Anonymous Coward]

i used to see crackers requesting this kind of help all the time on irc... 'hack' groups go and 'root' servers its for ddos power, irc based filesharing, irc spaming, and email spam. most of the truly good ones can get superuser access from any local account.

my server has the same thing hitting it, but im the only one allowed to access said server so blocking it was easy. using logwatch i notice it start up 4 days after my server was placed online. easy way to counter this attack is to denyhost for 10 failed attempts in the past 11 days. since i have a insane password (random shit) i just started ssh-key'ing in and the slow way would still get blocked and sent to the sync servers

Quote

[s1lverl0rd]

In real life, zombies feed off (...) weak minds... - Are you sure? I always thought they ate brains...