Sloppy Linux Admins Enable Slow Brute-Force Attacks 391
badger.foo passes on the report of Peter N. M. Hansteen that a third round of low-intensity, distributed brute-force attacks is now in progress — we earlier discussed the first and second rounds — and that sloppy admin practice on Linux systems is the main enabler. As before, the article links to log data (this time 770 apparently already compromised Linux hosts are involved), and further references. "The fact that your rig runs Linux does not mean you're home free. You need to keep paying attention. When your spam washer has been hijacked and tries to break into other people's systems, you urgently need to get your act together, right now."
Re:learn to.... (Score:5, Insightful)
Re:Outward facing systems ... (Score:5, Insightful)
Re:Outward facing systems ... (Score:5, Insightful)
And public keys aren't always that secure either. There are probably still plenty of servers with weak keys from the Debian debacle. What do you do with those users if password authentication is disallowed? Just lock them out and make them call you for a key reset?
Re:learn to.... (Score:3, Insightful)
Salting wouldn't help at all in this situation.. First of all it's only useful when the attacker already has the hash he needs to crack. Salting ensures that the attacker has to crack every password instead of getting free duplicates. It doesn't "add security" beyond that, since the salt must be stored in plain text.
The Headline (Score:3, Insightful)
overly paranoid (Score:4, Insightful)
That system you have with SSH facing outwards - right now: PermitRootLogin no, PubkeyAuthentication yes, PasswordAuthentication no, Allowusers one-guy-only
I'm sorry, but unless you have a laughably bad root password, this advice is unnecessary.
Even at 1 connections a second, in an entire year, an attacker could only guess 525,960 combinations. 10 connections a second?(REALLY fast...) 5.2M/year.
171,000 words in the English language, roughly. Pick two numbers, and now you're at 17 million combinations, and that's only assuming you put the numbers in one spot. Assuming they manage 10 connections a second, know the scheme you're using and hit it half-way (a HELL of a lot of assumptions in their favor) you're still looking at 1.6 years.
Two english words and a number? 292 BILLION combinations.
A REALLY SLOW attack ... (Score:5, Insightful)
This attack was first reported last November, eleven months ago, and again in April of this year, 180 days ago.
IF the bad guys have been able to capture only 770 Linux boxes since April that is only slightly more than 4 boxes per day. At that rate it would take them 833 years to create a Linux bot farm equal in size to the 1.3 Million Windows bot farm recently reported. Out of the millions of Linux boxes in use 770 represents a vanishingly small threat.
Using this "threat" as an excuse NOT to move from Windows to Linux, or to move from Linux back to Windows, would be similar to playing Russian roulette with a fully loaded revolver and hoping to survive.
Re:Outward facing systems ... (Score:5, Insightful)
And don't forget to keep it updated. And do not use FTP based on normal user passwords. And HTTP based on normal user passwords. And turn off rsh. And turn off telnet. And make sure people don't use the same passwords for your critical servers and their external bank accounts and web services. And rip Subversion and CVS out because of their continuing practice of storing your account passwords in plain-text. And make sure that your POP and IMAP servers are SSL protected, always. And make sure that your SMTPAUTH is done enctypred. And make sure that your boss does not send passwords to people via email.
Etc., etc., etc. I'm sorry, but please don't pretend that strong passwords are enough to protect you from general attacks. And don't pretend that you can force users to pick good passwords.
A measely 6k attempts over 4 days? Who cares? (Score:4, Insightful)
Re:A measely 6k attempts over 4 days? Who cares? (Score:5, Insightful)
You're right, though, in that good security practices should be just as effective in this case - which is why the title of the article is "Sloppy Linux Admins Enable Slow Bruteforce Attacks".
Re:Outward facing systems ... (Score:3, Insightful)
Who said anything about users? Of course, if you're running a system for other untrusted users, then you've got a whole host of other problems that you need to deal with. If you're running a server for yourself and a few friends though, using strong passwords for SSH (and not using them for other stuff too) is a perfectly valid solution. "Outward facing system" does not imply "public, multi-user server".
And seriously, if anyone out there is still doing HTTP/FTP/SMTP/POP3/IMAP with system auth passwords which also work for SSH, or has rsh or telnet enabled, or don't require SSL for SMTP/POP3/IMAP login, they deserve to be shot. All of those should be a given in this day and age.
Re:Outward facing systems ... (Score:4, Insightful)
Comment removed (Score:5, Insightful)
Re:overly paranoid (Score:4, Insightful)
The problem with 292 billion combinations or even just 17 million combinations is that your password will not be at the last point in the combination. IF the password ends up in the first quarter, then you only have 73 billion or 4.25 million before it's discovered. Now lets assume it's in the second half or third quarter of combination because you made a strong password. All I have to do is start trying mid way or in the last quarter of the possible sequences and I don't even need to go through a quarter of the possibilities to get it.
The point I'm trying to make is that your misleading yourself by looking at the possible combinations to a password because your password will lay somewhere within those possibilities. IF we apply some human characteristics to the issue, we can probably narrow the amount of passwords to try down some more before we get a hit. Humans Characteristics tend to be patterns like common strokes on a keyboard with reach or on hand, sometimes all in a row or diagonally, numbers tend to be consecutive and so on. Running a dictionary attack modified by those variables could potentially gain access without going through 10 percent of the possible combination you mention.
Now notice I said can. There is no guarantee that it will be successful. But there is a guarantee that you will not need to comb through all 292 billion possible combinations to get access so dwelling on that number is misleading.
Re:Outward facing systems ... (Score:3, Insightful)
Let's see...
don't forget to keep it updated.
Done.
do not use FTP based on normal user passwords.
I don't use FTP.
And HTTP based on normal user passwords.
I don't have any HTTP service that I need http-auth for.
And turn off rsh. And turn off telnet.
What distro are you using that has these on by default?
And make sure people don't use the same passwords for your critical servers and their external bank accounts and web services.
I'm the only one with ssh to this box. And this article has scared me into disabling PasswordAuthentication -- not that any of my critical accounts have passwords anyway.
And rip Subversion and CVS out
I use Git.
make sure that your POP and IMAP servers are SSL protected, always.
I don't use POP, and I only use IMAP over OpenVPN or a LAN. I think OpenVPN > SSL, and I can physically see all computers connected to the LAN switch.
And make sure that your SMTPAUTH is done enctypred.
I don't have SMTPAUTH enabled. This is a potential flaw -- if someone can get onto a trusted network. Again, OpenVPN or LAN.
And make sure that your boss does not send passwords to people via email.
I'm unemployed.
Now, you're right that strong passwords aren't nearly as good as strong keys. But they are sufficient, I think.
Of course, I use a 4096-bit RSA key.
my examples assume the attacker knows the scheme (Score:5, Insightful)
The problem with 292 billion combinations or even just 17 million combinations is that your password will not be at the last point in the combination.
My calculations on time involved the half-way mark, ie average time.
However, you missed a more critical point: my examples assumed the the attacker knows exactly what combination you're using. Which he or she does not.
Are your chosen words in English? Did you use punctuation? One number? Where is it? Did you substitute numbers for certain letters?
They have NO IDEA. Scotch2!Foo. Simple, short, and completely bulletproof. I laugh at the idiots who sit there and pound away on complex root passwords. Sure, that can be done in production environments where you then set up an SSH host key so you can get in easily (and yes, root login is necessary sometimes- ever tried to scp an important system file? Pain in the fucking ass if you can't login as root.)
Here's a simple test: run John overnight on your shadow file. If it can't guess your password, nobody's ever going to get in via ssh by guessing your root password. Ever. John tries passwords by the THOUSANDS per second...
Re:Outward facing systems ... (Score:5, Insightful)
Port knocking is a good way to conceal that ssh is available.
I guess it depends on what type of attacker you are trying to protect against. For attackers that are trolling around looking for easy targets, then things like this that add obscurity probably make sense. On the other hand, if I were in charge of a high value target, then I probably wouldn't bother. A high value target will have knowledgeable attackers who are very focused on exploiting you. In those cases, things like this are only mild inconveniences that will not make them give up. The port knocking sequence needed to open up ssh is not exactly a secret. It gets exposed in the clear to the network on every ssh connection. For high value targets, I would actually want the system as simple as possible to reduce the possiblity that a bug in one of the obscurity features actually becomes the attack vector.
Using port knocking is like locking my car door. It makes it harder for lazy, stupid thieves to get into my car, but it does absolutely nothing for someone who really, really wants to steal my car because a good thief can bypass it in a trivial amount of time.
Re:Outward facing systems ... (Score:3, Insightful)
You can get 99% of the port knocking benefit by simply running ssh on another port.
Almost all ssh attacks are automated, and if you're not running something on port 22, you won't be attacked.
So essentially you're left with people who are specifically targeting you, and portscan the system. Those are the sole people that port-knocking protects against.
Re:Outward facing systems ... (Score:1, Insightful)
Re:Login as root. Does any Linux distribution allo (Score:4, Insightful)
all disabling root login does is prevent the following:
ssh -l root some.domain.com
You can still login with
ssh -l user some.domain.com
and once connected you can su to gain root. The whole idea is to isolate root from the outside world, restricting root access to localhost only. Or are you happy with the world having direct access to the single most important account on the machine ?
Re:overly paranoid (Score:1, Insightful)
Are you sure? Knowing that you publicly criticize "going to such extreme measures" as relying on pubkey authentication instead of just using passwords... Well, with a security philosophy like that I wouldn't bet my paycheck on the chances you haven't suffered from security problems due to your half-baked security implementations.
Re:Outward facing systems ... (Score:3, Insightful)
Treat all traffic leaving your machine as if it is on a public network. Otherwise, any vulnerable computer on your lan makes all the rest of the computers vulnerable as well.
He's unemployed. Every computer on his LAN is his computer.
Re:Login as root. Does any Linux distribution allo (Score:1, Insightful)
Really? How do you SCP system files in a hurry without root access? Assign everything to wheel?
Re:Outward facing systems ... (Score:3, Insightful)
That's generally enough of an exposure reduction (combined with only allowing public key authentication.)
(Use of port-knocking would be useful if you setup a 2nd SSH instance that does allow password authentication. And you don't have more then 3 users, all of which are willing to put up with port-knocking. SSH public keys are a lot easier to configure and support.)
Re:Outward facing systems ... (Score:3, Insightful)
I would argue that it is a good idea.
While it may give you a "false" sense that your system is SECURE, when added with other precautions it will reduce the odds of getting "owned" -- as part of a comprehensive security plan. If your ONLY security is running ssh on port 10225 (or whatever), then I agree with you. Bad idea.
Running on a non-standard port will in the very least dramatically reduce your chances of getting hit by any zero-day exploits (give you a chance to fix/update ssh that bots are trying to exploit). It certainly reduces the amount of "noise" I need to sift through in my logs on a daily basis.
It might also help to run a trigger (like port sentry) to kill access to any IP attempting to connect to port 22.
Re:Login as root. Does any Linux distribution allo (Score:1, Insightful)
And since many people enable sudo for their account in order to make it easier to admin their boxes, this won't necessarily make their boxes any more secure:
ssh -l user some.domain.com
sudo su -
They just use the same password from the user and they're root. Woops.
Re:overly paranoid (Score:2, Insightful)
Please PLEASE put this up on sourceforge!
Re:It's 2009 and will be 2010 soon (Score:3, Insightful)
I said, for you to access a server without carrying around a USB drive. There's no way I'd have customers try it.
The huge bonus is that a lot of apps can use the same OTP system. Imagine getting to check your webmail from a dodgy Internet cafe and knowing that the login will only work that one time.
Re:It's 2009 and will be 2010 soon (Score:3, Insightful)
It's easier to have one system for everyone than to special-case a one-time-password system for my username.
Depending on your OS, it can be pretty easy [freebsd.org].
I guess you've never heard of SSL-protected POP3/IMAP? Or even HTTPS for webmail?
I guess you've never heard of keyloggers? With OTP, you could literally stand next to me and write down my username and password as I enter it, but that would get you nothing.
It's not my goal to convert you to OTP. I just wanted to point out that there are good compromises between password authentication and secure keys.
Re:Outward facing systems ... (Score:2, Insightful)
You don't agree with making an easy, small change to how sshd runs because it's "trivial" for a determined attacker to circumvent, but list 3 equally trivially circumvented defenses? A "determined attacker" will cut through all three of those, but as you point out a vast majority of the attacks are done by automated scripts run by kiddies.
Why not just agree with changing the ssh port and make it bullet point #4?
Re:Outward facing systems ... (Score:3, Insightful)
Right, what doesn't stop a targeted attack can still be quite useful against random opportunists/bots, which make up the lions share of attacks.
There's at least 3 levels of security: defense against worms and opportunists, defence against target attacks from script kiddies, and defense against targeted attacks from skilled attackers. Against a skilled attacker, you will lose if they want to dedicate enough time to attacking you.
However, 99.99% of attacks are of the opportunists and script kiddie level.