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."
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.
Setting SSH to high port seems like a bad idea. A non-root user could run a fake SSH instance to collect your password. Of course, that assumes someone else has access and the SSH server isn't running or crashed, but still, it's not the best way to add security.
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
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.
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
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.
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.
"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...
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.
Do not look at laser with remaining good eye.