Slashdot Mirror
Sloppy Linux Admins Enable Slow Brute-Force Attacks
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."
That system you have with SSH facing outwards - right now: PermitRootLogin no, PubkeyAuthentication yes, PasswordAuthentication no, Allowusers one-guy-only
sudo apt-get install fail2ban
THL phish sticks
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.
Ah, but things like denyhosts [1] with distributed reporting can and does catch these attacks. [1] http://denyhosts.sourceforge.net/
Couldn't we remove "Linux" from the headline and have it be just as accurate?
My sister opened a computer store in Hawaii. She sells C shells by the seashore.
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.
Please help metamoderate.
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.
Running with Linux for over 20 years!
They will eventually compromise a system which has keys for other systems, so the success rate will increase.
http://michaelsmith.id.au
So this guy is seeing 6,000 attempts to break in via SSH over 4 days. That averages about 1 per minute. His earlier attacks were on a similar scale. And apparently he has long windows where there aren't attacks. While being attacked is never good, this rate of attack doesn't seem newsworthy. Welcome to the internet, it's dangerous out there! I had no doubt that botnets were being used for attacking a variety of services, so I would expect to see them attacking SSH. Going slowly is slightly clever, as it does reduce the likelihood of tripping some detection measures, but good fundamental security should be as effective against this attack as any other. Am I missing something about why this is actually interesting? Or is it just a really slow news day.
Search 2010 Gen Con events
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
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...
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...
Please help metamoderate.
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.
http://michaelsmith.id.au
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.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
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. ssh also has that option, and it can only count failed attempts.
I turned it off because I realized that was utterly pointless, and no one was going to break in in any reasonable amount of time.
Although I've recently considered messing around with iptables on our mail server and making repeated failed ssh attempts block access to the email server, as obviously they are either malicious, or their machine is controlled by a virus, and either way, any mail from that IP is probably spam. I need to run some intersect of the spamming IPs with ssh attempts and see if there's any overlap first.
If corporations are people, aren't stockholders guilty of slavery?
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
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
you would think we could put that old chestnut to bed by now.
Sounds like we should set up a reverse botnet with a rating system, then.
Talk to some other companies you know, create a system that takes a list of failed logs, anonymizes it somewhat and publish it. They do the same, you all have a system that pulls down the list from the others and puts that into a list of "hosts we probably don't want to talk to, because they have tried as root@othercompany.com".
If the lists are properly anonymized and we have a rating system so getting bad data into the system is harder, I think we'll have more or less countered them for now.
I'm sure the next reply will tell us all about somebody who already has this designed and set up.
If you believe that, then this article is about you. There is NEVER any need for a direct root login.
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 ?
"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?
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...
Let me make the same mistake you made and state: In the same way that it is impossible to use system logs to detect a compromise, it is in general impossible to conclude that a system is compromised even given a full dump of its state (stopping problem).
But we all know that that is not the case in reality/practicality, only a minuscule fraction of compromised systems would be compromised in such a careful way, leading us to believe that it is worthwhile to try to detect compromise.
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.
IANAL but write like a drunk one.
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.
Dewey, what part of this looks like authorities should be involved?
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.
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.
Dewey, what part of this looks like authorities should be involved?
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.