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."
Outward facing systems ... (Score:5, Informative)
Re:Outward facing systems ... (Score:5, Insightful)
Re:Outward facing systems ... (Score:4, Interesting)
Re:Outward facing systems ... (Score:5, Informative)
If you've connected to it once, you've got the host's public key.
Any user who generates their own key will trigger MASSIVE warnings from SSH, just as if you'd been MITM'd any other way.
Re:Outward facing systems ... (Score:5, Interesting)
First, the server signature would change, unless the attacker already has root access and can copy the private key, in which case the port number is irrelevant. Any decent SSH client whines quite a bit about such changes.
Second, there are several auth methods you could use that do not expose any private data, including pubkey and kerberos. One of the purposes of such auth methods is to prevent re-used even if an attacker gets your session credentials.
Re: (Score:3, Informative)
Setting your ssh port to a high number is not a bad idea at all. All these brute-forcing ssh scanners don't portscan a host looking for ssh on any port, they connect to port 22 and see what is there. Moving it to any other port will reduce the incidence of these botnet scans by an order of magnitude, if not eliminate it entirely.
A non-root user can not run software that binds to low numbered ports, so having someone else on the system impersonate sshd is a non issue.
Secondly, as many mention, turning off pa
Re: (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
Re:Outward facing systems ... (Score:4, Informative)
No. It's about SSH being run on, for example, port 2222.
If SSH crashes (or is crashed), that means bad_guy can launch his honeypot on port 2222 now, something that would NOT be doable were it running on a privileged port.
Re:Outward facing systems ... (Score:4, Informative)
Better yet, keep the port closed to the outside world. Use port knocking with software such as Aldaba [aldabaknocking.com] to control the ability to ssh in.
Re: (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
Re:Outward facing systems ... (Score:5, Informative)
I don't agree with setting the SSH port to non-standard, it is trivial for any determined attacker to figure out which one you've changed it to. Use one of the port/log monitoring daemons that are mentioned further down the page.
That being said I used to work for a hosting company with a few thousand linux servers, most of them running cPanel (cPanel is a hunk of insecure crap). We'd get a few script kiddie break ins a week. Our solution with dramatically reduced the amount of break-ins (In addition to the SSH mods by the grand-parent) were:
1) put /tmp as a separate partition and mount it as noexec, nosuid. Make sure your programs php/httpd use /tmp for temporary files, caches and session info. This simple step stopped 80% of attacks.
2) host allow/deny is your friend
3) rpm -V is your friend, most script kiddies/attackers are not bright enough to alter the rpm db, they will simply replace system binaries.
there are a few more but I can't seem to remember them.
Re: (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.
Re:Outward facing systems ... (Score:5, Funny)
Or you could just not use weak passwords.
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.
Re: (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 whic
Re: (Score:3, Interesting)
Oh, I agree that they deserve to be shot. But don't blame the admin himself. Just try to get a startup company run by former academics who aren't old enough to remember the Morris Worm to take security seriously. I spent far too long sharing guidelines with a professional colleague last year, only to have his company's VP's throw the whole security recommendation away under the guise of "not critical". Then they fired him, apparently partially in retaliation for expressing his concerns as part of his projec
Re: (Score:2)
And rip Subversion and CVS out because of their continuing practice of storing your account passwords in plain-text.
If your Subversion server is storing passwords in plaintext, you're doing it wrong. I've set up several servers for use with Subversion, and all of them store user passwords encrypted. As far as I know, that's the default way of doing it when you're doing Subversion through Apache.
Re: (Score:3, Informative)
What? Oh, I'm not talking about the server! I'm talking about the UNIX and Linux clients, which by default store your passwords in clear-text in $HOME/.subversion/auth/. Subversion has always done this: no fix has ever been planned for Linux and UNIX clients. There are workarounds, such as using 'svn+ssh' or using only Windows clients such as TortoiseSVN that do not have this problem, but there is no actual fix for this planned.
Subversion 1.6 does ask before storing the passwords, but that's not a fix.
Re: (Score:3, Interesting)
What $HOME/.subversion is set to is dependent on the account creator's permissions for $HOME, and the individual user's umask. But even if .subversion were protected, if the account is NFS mounted or is available on backup tapes, your password is availalble to anyone who can gain _local_ root access on an NFS client and do 'su' to act as other users, or gain access to the backup tapes. NFS, in particular, is generally available to any laptop with a live CD anyone can plug into your network.
It's an incredibl
Re: (Score:2)
The SVN client does store passwords in plaintext.
Re: (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
Re: (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: (Score:3, Funny)
Why do people assume that "the lan" is some magical secure place?
Because I don't let just anybody into my home and I don't have a wireless network either? And somehow I doubt somebody will break into my house just to hijack another linux box, but when they do they'll probably access the box directly instead of over the network.
Re:Outward facing systems ... (Score:4, Funny)
"DING DONG"
you: answer door; Hello?
guy: Hi I'm from linux, I'm here to install a critical patch.
you: huh? from where?
guy: linux, linus sent me, I need to patch your computers..
you: LINUS? REALLY?
guy: yes, here is my official linux ID, and we have a nice CD full of new unreleased software for your trouble...
Damn linux hackers are getting better and bolder every day.
Re: (Score:3, Interesting)
You know... most people have a server and laptop and a laser printer on a network and there are ways to password harvest using the printer.
I am hoping that newer HP printers are hardened to this, but back in the late 90's I was ableto perform remote exploits on jetdirect cards in HP printers that allowed me to do a LOT of things that most admins at that time ruled out as impossible.
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: (Score:3, Informative)
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?
Your assumption about Debian's problems with ssh is rather unlikely. The only way weak keys still exist is if the system hasn't been updated in the last couple of years.
When Debian pushed out the ssh update they also pushed out an automated check for weak passwords that ran before the update was finished. The script told the admin if any weak keys existed on the machine and that they needed to be updated immediately.
Of course, you could be right that there are admins stupid enough to have ignored all that
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.
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.
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: (Score:3, Interesting)
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...
Seriously. Brute force of actual good passwords is not a foreseeable option.
If it worries you that much, it's pretty easy to implement something to make the system even slower. For example, I've previously used iptables to only let each IP make three new ssh connections every minute. s
ever tried to scp an important system file? (Score:4, Informative)
Yes. I copy it with my regular, non privileged account and then change ownership and permission in the target machine as root.
You don't need root for one of transfer of files.
Re: (Score:2)
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.
You are not understanding how the total number of possible passwords affects things. With a secure password, there is no bias so there is no ordering of the total possible passwords to improve your odds. Everyone knows that you will almost never have to guess all of the possible passwords. The odds of hitting the correct password on that final 292 billionth password is the same as hitting it on the first guess.
The proper way to use the number is to look at how many guesses will get you at a 50% probabili
Re: (Score:3, Informative)
The trick to making strong passwords is to not use them at all.
Random passwords don't work. People don't remember them, or they write them down, or they use the same one everywhere. Any of these options compromises the security of a 'bulletproof' random password.
SSH private keys can't be guessed, they aren't compromised if you use them on more than one system (even untrusted systems), and you can revoke them if the machine they are on is compromised.
Better yet, smart cards are even harder to clone, especial
Re: (Score:2)
Anyway, from the black hat perspective, let's say a half a server a month cracked would be enough for it to be worthwhile. Then at one month, at one hit a second per server, that would be 2,592,000 tries. So lets say that you had two English words and a number, 292,410,000,000 tries. Then to get a 50 % chance of cracking one of the servers in a mo
Re:overly paranoid (Score:5, Interesting)
what is fun is write a nice tight C program that talks to the Telnet port offering a login and then makes it look like they got in. then just give errors for every command. it will DRIVE THEM NUTS.
I had a "cracker" screwing with mine for weeks trying all kinds of commands, tried a buffer overflow, etc... it drove him insane as he started to type curse words more and more.....
Nothing makes me happy than wasting hours of some asshat's time.
Re: (Score:2)
I'll take "when hell freezes over" in place of "once in a blue moon" any day of the week.
I agree completely, although I have seen systems breached because of mismanaged keypairs, misconfigured applications, and mismanaged permissions. Even without password logins, an insecure PHP script could potentially obliterate that layer of security.
I've gotten into the habit of chmod'ing my keypairs to 600 (and chmod'ing the .ssh directory they live in as 700) ever since a php script was exploited to fetch the keys on
Re: (Score:2)
What ever happened to random / gibberish passwords? pwgen is a pretty good tool for this. We all know pubkey authentication is a lot better, but sometimes I'd rather log on from some other box without having to carry around my private key. Pubkey authentication works when you have to manage many boxes from one or two specific boxes.
Password authentication is as secure as, well, your password. Good passwords are pretty damn secure. 'aiBea1su' is pretty hard to guess. 'sexy99', not so much.
Comment removed (Score:5, Insightful)
Re:SSH as root (Score:4, Interesting)
"If you are on a shell session on a server, you should NEVER be root-- that's what sudo is for."
Why?
Did you just come to bitch about something you personally disagree with or do you actually have a reason for this?
Re: (Score:2)
That system you have with SSH facing outwards - right now: PermitRootLogin no,
PubkeyAuthentication yes, PasswordAuthentication no, Allowusers one-guy-only
You mean there are other ways to configure a system?!?!? :-)
Re: (Score:2)
Actually a good strong password is quite enough. I use 8 random chars/numbers.
For convenience I have password-less ssh login, also for root, but only from root and from similarly or better protected machines.
Re:Outward facing systems ... (Score:4, Insightful)
Re: (Score:2, Informative)
Port knocking is a good way to conceal that ssh is available. Use fwknop!
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: (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:5, Interesting)
Don't set 'PasswordAuthentication no' * out the password for the SSH-only allowed users. Or even better yet, run ssh on a non-standard port, and do a fake SSHD that always denies and connection tarpitting on port 22.
That way the 'brute forcers' will have no idea your system is more secure. While they're wasting time trying to break security on your uber locked down systems, they're leaving some other systems alone. If they're trying to brute force X hosts at a time, and some of them are secure, it will be longer before they move along to possibly more insecure hosts.
This reduces the rate of expansion of these annoying brute forcers
Re: (Score:2)
PermitRootLogin no - Correct
PubkeyAuthentication yes - Not so much
Public keys are great for trusted intranets and all, but for external access they're not such a good idea. If someone compromises your workstation they're automatically authenticated on the outward-facing server.
Re: (Score:2)
You *can* create keys which require a passphrase to be used.
learn to.... (Score:5, Informative)
sudo apt-get install fail2ban
Re: (Score:2)
Doesn't help with slow distributed brute force attacks. The different attempts come from different bots in the same botnet.
Re:learn to....denyhosts (Score:5, Informative)
Re: (Score:2)
fail2ban is great, but this attack looks designed to sneak around it. Since this is a distributed attack, the offending script has hundreds of IP addresses at its disposal, and has each IP attack each server a small number of times (usually twice, often once, rarely thrice).
Fail2ban is designed to scan for repeated attacks from a single IP.
I second the PermitRootLogin no >> /etc/ssh/sshd_config advice from the above posts.
Re:learn to.... (Score:5, Insightful)
Re:learn to.... (Score:5, Funny)
Re: (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.
Ask Slashdot (Score:5, Interesting)
What is the Slashdot crowd using these days for log monitoring?
My /var/log/auth.log might be filled with WARNING BRIAN YOUR DOG HAS BEEN COMPROMISED BY ENEMY AGENTS for all I know.
Re: (Score:2)
Re:Ask Slashdot (Score:5, Informative)
My server just mails me its daily security run, and most days there is a couple of brute force attempts. I am yet to see it even target a valid account name, let alone getting around to guessing my totally random mixed case alpha-numeric password.
Oh, and i have sshguard blocking them at the firewall, just to keep log-file pollution down.
Re:Ask Slashdot (Score:4, Interesting)
Running awk 'gsub(".*sshd.*Failed password for (invalid user )?", "") {print $1}'
279 root
20 test
19 admin
9 john
9 guest
8 PlcmSpIp
7 oracle
7 info
6 webmaster
6 mysql
so, we have 6 that often are valid, a very common name, two that almost could be valid (info and webmaster), and one nonsense. Only one account on that system has ssh allowed, and it's certainly not root.
Re: (Score:3, Informative)
Re:Ask Slashdot (Score:5, Interesting)
My server just mails me its daily security run, and most days there is a couple of brute force attempts.
Of course if the server were compromised, would you expect it to mail you a log that showed that it was compromised? If someone gets in with root access (and they know what they are doing), they could just modify the logs to not show what just happened. As long as you keep getting the same type of security summary, you will be happy.
It reminds me of a time I was in an airport going through the TSA security line to go into the terminal. The agent checked my ID and boarding pass and then got distracted by a bunch of flight attendants she had to let through. She then turned back around and asked me if she had checked my ID. I gave her a hard time because in this system I am assumed to be untrustworthy until she says otherwise so she shouldn't trust anything I tell her.
The point is that if something is a potential attack vector, then you must assume that any information it gives you might be a lie.
Re: (Score:3, Funny)
She then turned back around and asked me if she had checked my ID. I gave her a hard time because in this system I am assumed to be untrustworthy until she says otherwise so she shouldn't trust anything I tell her.
Oh, how I laughed as her collegues repeatedly probed my anal cavity with their rough, unlubricated hands.
Re:Ask Slashdot (Score:4, Funny)
"She then turned back around and asked me if she had checked my ID. I gave her a hard time because in this system I am assumed to be untrustworthy until she says otherwise so she shouldn't trust anything..."
So how did the 'totally picked you at random' body cavity search go then?
Re:Ask Slashdot (Score:4, Interesting)
Seen a setup once that had all servers sending logging (via syslog) to a syslog server. This server was behind it's own firewall had nothing exposed other than syslog and it had the ability to send pages via an analog modem as well as email. About as secure a system I have seen.
Its actual purpose was more for monitoring the admins than for detecting intrusions, but it did both. The physical box was locked in a cabinet in the network manager's office.
The most an intruder could do, unless they know a hack for syslog, would be to disable syslog on the compromised machine so that their activities would not be logged. Of course a rooted machine would be wiped anyway so the logs are only valuable for forensic purposes anyway.
Re: (Score:3, Informative)
I will add to this that any decently secured system will log all activities to an external machine through a logging service which does not allow for said machine to remove any logged events. That way two machines will need to be compromised to hide the fact.
This also protects against your legit admins doing some dodgy work and then deleting the evidence.
Re: (Score:3, Interesting)
Simple solution! (Score:2)
this time 770 apparently already compromised Linux hosts are involved
<sarcasm> chmod 750 ? </sarcasm>
Re: (Score:2, Funny)
chmod 0 `find /`
The Headline (Score:3, Insightful)
Re:The Headline (Score:4, Interesting)
To add to that it begs the question, shouldn't any operating system/application be secure by default?
If that were the case then sloppy admins wouldn't be a problem, only incompetent admins that specifically go and disable said security features.
The problem is that sloppy admins will always exist, so to blame them doesn't really achieve much, nor does it absolve the operating system/application in question of blame. If a problem is known (i.e. some admins are sloppy), and nothing is done to resolve that, then the OS/App deserves just as much blame.
Again as you say, this is a problem for all operating systems and all software.
Re: (Score:2)
Windows admins being sloppy doesn't make the news.
Also, the fud machine favors attention granted to linux's foibles.
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.
Until they hit the jackpot (Score:3, Interesting)
They will eventually compromise a system which has keys for other systems, so the success rate will increase.
Re: (Score:2)
Re: (Score:2)
Not even Windows admins are incompetent enough to put a bunch of authentication keys on a system with a public-facing, root-login-permitted, weak-root-password ssh server.
Tell that to the bank that holds my mortgage.
Re: (Score:2)
Re:A REALLY SLOW attack ... (Score:5, Funny)
I run windows so I'm safe.
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:A measely 6k attempts over 4 days? Who cares? (Score:5, Funny)
Because it involves Linux boxes, and nothing gets the /. crowd riled up more than an assertion that Linux suffers from drawbacks. :P
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".
Yes, as opposed to "Typical Windows Admins Enable Rapid Bruteforce Attacks"
Re:A measely 6k attempts over 4 days? Who cares? (Score:4, Interesting)
The type of attack is interesting. There are security products that will block failed connections after a certain amount of tries and/or in a certain amount of time. This attack is distributed meaning that it doesn't trigger the failed connects per amount of time. It hits from multiple computers so IP bases detection is pretty much useless for automated security programs. It's also slowed to a pace that wouldn't cause a packet storm or otherwise flood the network tipping off other security products or admins with their eyes open.
This is news worthy because the style of the attacks, are designed to defeat normal security protocol and software designed to defend against these types of attacks. It's pretty much going to require someone to either tweak their settings until it's over or take a visual look at the logs to identify an attack. Plus, making sure your convenient password is actually a strong password to avoid getting hit in the first place. In other words, it highlights some things many pros might have become complacent about while at the same time illuminates the very same issues to the newbs who might not know as much as we would like.
If it's SSH it's really easy to rate limit attacks (Score:2)
All you need to drop any unsuccessful SSH logins for a specified period of seconds. /usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --set /usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --update --seconds 1000 --hitcount 2 -j DROP
Eth1 is obviously your public NIC
--hitcount is the number tries allowed
--seconds is, well, seconds the IP is dropped into a bit bucket for!
Re:If it's SSH it's really easy to rate limit atta (Score:4, Informative)
Sorry, text came out crap for some reason, trying again to make it clearer.
/usr/sbin/iptables -I INPU= T -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --set
/usr/sbin/iptables -I INPU= T -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --update --seco= nds 1000 --hitcount 2 -j DROP
Re: (Score:2)
This is great advice, for when you must accept password-based SSH logins, and I use it myself.
Unfortunately the style of attack discussed in the article is one that gets around this, by being both slow and distributed, so that rate limits based on IP address per unit time are effectively useless.
Re:If it's SSH it's really easy to rate limit atta (Score:3, Interesting)
All you need to drop any unsuccessful SSH logins for a specified period of seconds.!
With a distributed attack each attacker may only try once.
Re:If it's SSH it's really easy to rate limit atta (Score:5, Interesting)
Obviously, you didn't RTFA, or even the summary.
These attacks completely avoid the problem, you'd have to drop the IP for several days to mitigate this attack. It is hundreds of linux boxes tagging a target and waiting a while before hitting it again. It's a slow brute force attack because no individual bot attacks a particular target more than once or twice in a given time period, maybe several minutes, maybe even several hours. The frequency of this attack was about 1500 attacks per day total, which is only two attacks per machine in the 770 bot network in a single day.
Implimenting your strategy to prevent these attacks would also mean you would be locking out legitimate users who mis-type a password for a day or more. That is not going to work in any environment I am aware of.
The brilliance of this attack is that while a bot is only attacking a particular machine once or twice a day, there is nothing stopping it from attacking other machines in the mean time. A bot can still send out thousands of attacks per day, they are just sending them to thousands of machines instead of one. Well coordinated it certainly has the same potential for building a large botnet as normal brute force methods. The downside of course is your odds of getting a particular machine are terrible, you're playing statistics to get a large botnet.
Login as root. Does any Linux distribution allow? (Score:2)
Does any Linux distribution come with a default ssh config that allow root to login via ssh?
Re: (Score:2)
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: (Score:3, Interesting)
You still haven't presented a convincing argument that permitting root to login is inherently insecure.
I have several linux boxes that permit root login via keys and password. In six years none have been compromised.
Nobody but me has access to root on these systems and it wills stay that way because I use and remember proper passwords.
Re: (Score:2)
770? (Score:2)
When it gets to 777 all users will have read/write access to the files!
My solution to this problem: (Score:5, Informative)
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables -N SSH_WHITELIST
# My work network.
iptables -A SSH_WHITELIST -s 1.2.3.0/24 -m recent --remove --name SSH -j ACCEPT
# My home network
iptables -A SSH_WHITELIST -s 4.5.6.0/24 -m recent --remove --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Tune appropriately. I find that 4 per minute doesn't generate false positives but quite effectively blocks brute forcers. You could lower hitcount or increase the seconds to your liking.
And this is just for machines where I do need multiple people to be able to login from multiple locations. On other machines I definitely use ssh key only auth via the sshd_config.
PLUS: This proves that there ARE people out there interested in breaking into Linux boxes. It's just that this is the best way they can find to do it and I think that says a lot. So let's not hear any more of this "Linux would have viruses too if it were as popular as Windows" bull. Between this and the MySQL on Windows worm:
http://news.cnet.com/MySQL-worm-hits-Windows-systems/2100-7349_3-5553570.html [cnet.com]
and the recent Linux botnet perpetrated via password brute forcing:
http://www.builderau.com.au/program/linux/soa/Linux-botnet-discovery-points-to-lazy-administrators/0,339028299,339298642,00.htm [builderau.com.au]
you would think we could put that old chestnut to bed by now.
Malware detection software for Linux? (Score:4, Interesting)
So how, exactly, does one know whether a Linux box has been compromised?
Windows machines have an entire industry of antivirus software. We... don't. Dislike Windows as much as you like, but the mere fact that Windows is so insecure means that people are aware of it being insecure, and so the tools are available to deal with the problem.
What does a Linux user do? I know of tools like chkrootkit and rkhunter, and run them, but I have no idea if they're any good. What's the recommended way of finding out whether you've been compromised? Waiting for SORBS to blacklist you probably isn't the best way...
Re: (Score:2)
Only the strong survive.
Actually, it's only the best adapted that survive. That said, if you're strong enough you won't get rooted by that big guy named Bubba in the bottom bunk.
Re: (Score:2)
These are password-guessing attacks. No connection to public-key authentication.
Re:It's 2009 and will be 2010 soon (Score:5, Informative)
Because some of us want to be able to log in from anywhere without having to carry a flash drive around containing our ssh keys.
And some of us have customers who have a hard enough time grasping the concept of "strong passwords", let alone key-based authentication... And heaven forbid a client's computer crashes and you have to help them set it up again over the phone...
Re: (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: (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.