Sloppy Linux Admins Enable Slow Brute-Force Attacks 391
Posted
by
kdawson
from the time-lapse-intrusion-monitering dept.
from the time-lapse-intrusion-monitering dept.
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."
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:Outward facing systems ... (Score:1, Interesting)
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:Ask Slashdot (Score:3, Interesting)
Re:Outward facing systems ... (Score:4, Interesting)
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:Outward facing systems ... (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 project reports. I've written him excellent recommendations, but am very pleased that my upstream managerial personnel have been taught, partly by me, to take security seriously.
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: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.
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.
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:my examples assume the attacker knows the schem (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. 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.
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:overly paranoid (Score:2, Interesting)
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.
If you're relying on your private key to be able to ssh into your system, what happens when you're somewhere without your private key?
If you want to be able to log in anywhere, you have to start carrying your key on a USB stick or something -- at which point it's barely better than writing it down.
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:Outward facing systems ... (Score:1, Interesting)
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.
permitting root login does seem like a bad idea, but if you have a system with LDAP or kerborose where authentication can get messed up, sometimes being able to log in as root is able to save you a trip to your DC.
Reverse botnet, then (Score:2, Interesting)
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.
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?
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:Outward facing systems ... (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 incredible security problem, one generally ignored by people who "trust the people they work with".
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:Outward facing systems ... (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: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:Login as root. Does any Linux distribution allo (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.