Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Sloppy Linux Admins Enable Slow Brute-Force Attacks

kdawson posted more than 4 years ago | from the time-lapse-intrusion-monitering dept.

Security 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."

cancel ×

391 comments

Sorry! There are no comments related to the filter you selected.

Niggers (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29640129)

This is why niggers shouldn't be allowed in the work place.

Outward facing systems ... (5, Informative)

taniwha (70410) | more than 4 years ago | (#29640171)

That system you have with SSH facing outwards - right now: PermitRootLogin no, PubkeyAuthentication yes, PasswordAuthentication no, Allowusers one-guy-only

Re:Outward facing systems ... (0)

Anonymous Coward | more than 4 years ago | (#29640205)

pam_abl or a similar solution works fine for me :)

Re:Outward facing systems ... (5, Insightful)

quintus_horatius (1119995) | more than 4 years ago | (#29640243)

And perhaps set your SSH port to a non-standard port, where possible? Brute-force attackers seem to ignore high (> 1023) ports.

Re:Outward facing systems ... (4, Interesting)

Korin43 (881732) | more than 4 years ago | (#29640591)

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.

Re:Outward facing systems ... (-1, Redundant)

Anonymous Coward | more than 4 years ago | (#29640629)

I hate to break it to you, but all ports below 1024 typically require superuser privileges to be opened.

Re:Outward facing systems ... (4, Informative)

SanityInAnarchy (655584) | more than 4 years ago | (#29640789)

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 ... (4, Informative)

mysidia (191772) | more than 4 years ago | (#29640597)

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:Outward facing systems ... (4, Funny)

marcansoft (727665) | more than 4 years ago | (#29640249)

Or you could just not use weak passwords.

Re:Outward facing systems ... (4, Insightful)

Antique Geekmeister (740220) | more than 4 years ago | (#29640397)

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:Outward facing systems ... (2, Insightful)

marcansoft (727665) | more than 4 years ago | (#29640529)

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 ... (2, Interesting)

Antique Geekmeister (740220) | more than 4 years ago | (#29640671)

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:Outward facing systems ... (1)

HeronBlademaster (1079477) | more than 4 years ago | (#29640761)

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:Outward facing systems ... (2, Informative)

Antique Geekmeister (740220) | more than 4 years ago | (#29640787)

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:Outward facing systems ... (1)

SanityInAnarchy (655584) | more than 4 years ago | (#29640799)

The SVN client does store passwords in plaintext.

Re:Outward facing systems ... (2, Insightful)

SanityInAnarchy (655584) | more than 4 years ago | (#29640825)

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.

Re:Outward facing systems ... (5, Insightful)

icydog (923695) | more than 4 years ago | (#29640253)

I agree with your post if only one person needs access to the box (and i agree with PermitRootLogin no always). But while public key auth is great, it just isn't feasible for many applications. For example, imagine you're a cheap webhost that provides ssh, scp, sftp access to your users, Do you require them all to use public keys auth? 90% of them don't even know what that means. What a support headache.

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?

overly paranoid (4, Insightful)

SuperBanana (662181) | more than 4 years ago | (#29640369)

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 (0, Flamebait)

c0d3g33k (102699) | more than 4 years ago | (#29640511)

You're laughably stupid. Set PasswordAuthentication to no and your statistics become meaningless because they don't apply at all. Not even a lucky guess can result in a breach, because you have removed that avenue of attack entirely. If you want to play the statistics game, PubkeyAuthentication with strong encryption plus regular key changes plus some sort of port knocking scheme gives numbers that are much better than yours. I'll take "when hell freezes over" in place of "once in a blue moon" any day of the week. Give me scheme with even better odds and I'll take it. The highway of history is littered with fools who thought "they'll never figure this out. Wait. What? Oh shi....". SuperBanana indeed. You'll end up on the wrong end of someone's super banana before you know what hit you.

Re:overly paranoid (1)

MyDixieWrecked (548719) | more than 4 years ago | (#29640593)

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 a friend's server. I know Redhat/CentOS is smart enough to not allow that, but it's still a real threat especially on shared boxes. You've also got to be careful about the authorized_keys2 file.

I'm a huge fan of SELinux although I find that it requires the sysadmin to be SERIOUSLY on his toes when configuring everything. You really need to know what you're doing or things will randomly break and you'll be left scratching your head.

Re:overly paranoid (1)

marcansoft (727665) | more than 4 years ago | (#29640619)

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.

Re:overly paranoid (4, Insightful)

digitalchinky (650880) | more than 4 years ago | (#29640635)

The parent is far from stupid as you put it - quite the opposite actually. You stick daemonshield or one of a hundred similar log monitors on your server and the job is done, you can even tweak them to watch for slow brute force attacks. What is actually laughable is the admin going to such extreme measures to secure some backwater server that requires umpteen minutes of dicking around whenever you move to a new remote machine just to log in. And then ignoring it because you think it is so damn impregnable.

This fool littered highway, where is it exactly? I've been doing this crap near on 20 years now and I've never had root lost.

Re:overly paranoid (1)

mysidia (191772) | more than 4 years ago | (#29640651)

When you say auth only... it's not "when hell freezes over" it's once in a blue moon.

All they gotta do is get a reliable crack for RSA/DSA, probably by building a quantum computer and successfully implementing Shor's algorithm on a large scale :)

Re:overly paranoid (3, Insightful)

sumdumass (711423) | more than 4 years ago | (#29640723)

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 (4, Insightful)

SuperBanana (662181) | more than 4 years ago | (#29640855)

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:overly paranoid (1)

cetialphav (246516) | more than 4 years ago | (#29640857)

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% probability of getting the right password. Lets say that you figure someone could guess a million passwords before you change your password. To cause the attacker to have less than a 50% chance of success, you need to have at least 2 million possible passwords. For a 25% chance, you need 4 million. For a one in a million chance of success, you need 1 trillion possible passwords.

So the key numbers are the number of possible attempts that a system will allow in the time frame that a given password will be valid and what is the ratio of the number of attempts to the total password space. The nice thing is that adding one additional character greatly increases the password space and causes an exponential growth in the amount of passwords an attacker must try to have a x% chance of success.

Re:overly paranoid (1)

Time_Ngler (564671) | more than 4 years ago | (#29640831)

Isn't the idea to hit a ton of servers, hoping to get into one? First, I don't get the 525,960 attacks per year at one a second: 60 * 60 * 24 * 365 = 31,536,000

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 month, they'd need to know the ip address of log(.5)/(log((292410000000-1)-log(292410000000)) / 2592000 = 78163.5 machines. So if they have a bot net, and can search for an open port 22 until they have 78163 machines, (and one additional one that's up an average of half the time), and start brute forcing away.

So, yes, you'd be unlikely to be the one that got cracked in those 78163.5 machines, but it is possible, and it is fruitful to attack in this way, even if everyone had a pretty good password. And, the longer you have your server running, the greater the risk is.

Re:Outward facing systems ... (1, Interesting)

Anonymous Coward | more than 4 years ago | (#29640381)

May be this will help Top 20 OpenSSH Server Best Security Practices [cyberciti.biz]

Re:Outward facing systems ... (1)

ErikTheRed (162431) | more than 4 years ago | (#29640387)

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:Outward facing systems ... (0)

Anonymous Coward | more than 4 years ago | (#29640433)

And how exactly PermitRootLogin no makes your system more secure when you already have PubkeyAuthentication yes and PasswordAuthentication no? Are you afraid that someone is gonna guess your private key or something?

Re:Outward facing systems ... (1)

gweihir (88907) | more than 4 years ago | (#29640499)

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 ... (1)

madbavarian (1316065) | more than 4 years ago | (#29640531)

Blocking root is a bit of an over reaction. Blocking password, pam, kerberos, onetime and all that other rot is good enough for stopping the brute force attacks. Nobody is going to brute force root's 1k (or 2k) key in any usable timeframe. While one is editing the file, might as well put an ssh-level keepalive in there for 30 minutes to clean up dead connections and keep lame NAT boxes primed. Protocol 1 should probably also be turned off. It has a few known failure modes. Cranking down logingracetime keeps the bruteforce attacks from tying up too many resources. One should never see RSA login take 10 seconds on a modern system with the rsa key unlocked and stored in keyserver. Even typing the passowrd in realtime shouldn't take 10 seconds.

Protocol 2
LoginGraceTime 10
PermitRootLogin without-password
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
UsePAM no
X11Forwarding yes
ClientAliveInterval 60
ClientAliveCountMax 30
AllowUsers root myaccount

Re:Outward facing systems ... (3, Insightful)

Curunir_wolf (588405) | more than 4 years ago | (#29640595)

Or - unless you're traveling and using hotel or hotpoint access to get to your server a lot, or your list is too long, just block SSH from all IPs except for the addresses you know you'll be using.

Re:Outward facing systems ... (2, Informative)

Thaidog (235587) | more than 4 years ago | (#29640607)

Port knocking is a good way to conceal that ssh is available. Use fwknop!

Re:Outward facing systems ... (5, Insightful)

cetialphav (246516) | more than 4 years ago | (#29640907)

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 ... (5, Interesting)

mysidia (191772) | more than 4 years ago | (#29640627)

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 ... (1)

Trogre (513942) | more than 4 years ago | (#29640733)

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:Outward facing systems ... (1)

ion.simon.c (1183967) | more than 4 years ago | (#29640829)

You *can* create keys which require a passphrase to be used.

How many of these 770 machines were planted? (1)

celtic_hackr (579828) | more than 4 years ago | (#29640887)

I have to wonder, with such a small number of machines as this, how many of them were actually seeded by the botnetters. Just to see if they could get other Linux boxes to fall. Maybe some non-trivial number of these were/are test machines set up to try to break into.

While keys are nice, a good password policy with forced changing frequently is probably better. Ok, so you've created a key, what prevents a brute force attack on the "never-changing" key? How can a key which will never change, be more secure than a very strong password that is only good for two weeks? Odds are a key can be broken in a few months of intensive work. Or less.

I once left a machine out there and intentionally left it there with no updates, to see how long it would survive. It lived for several years before being cracked.

learn to.... (4, Informative)

gandhi_2 (1108023) | more than 4 years ago | (#29640185)

sudo apt-get install fail2ban

Re:learn to.... (1)

kabloom (755503) | more than 4 years ago | (#29640197)

Doesn't help with slow distributed brute force attacks. The different attempts come from different bots in the same botnet.

Re:learn to....denyhosts (5, Informative)

nairb774 (728193) | more than 4 years ago | (#29640319)

Ah, but things like denyhosts [1] with distributed reporting can and does catch these attacks. [1] http://denyhosts.sourceforge.net/ [sourceforge.net]

Re:learn to....denyhosts (0)

Anonymous Coward | more than 4 years ago | (#29640923)

I woke up in the morning with over 700 denyhosts bans a couple of days ago. Still getting 2 or 3 per hour.

Denyhosts blocks the ip of any more than 3 failed attempts. My hosts.deny (with the help of some other similar apps) has a list of over 5500 banned IPs.

Not sure if such a large list affect performance yet.

Re:learn to.... (0)

wizardforce (1005805) | more than 4 years ago | (#29640225)

FTA:

with a guessable password and a system administration regime that lets weak passwords exist in the first place.

Fail2ban would theoretically cut down on the attempts by 90% from 32 to 3 or whatever you set it at however, the real problem are the weak passwords used. Automatic salting of passwords and fail2ban should eliminate the threat entirely as these attacks are extremely unlikely to crack salted passwords in the number of attempts they would be allowed.

Re:learn to.... (4, Insightful)

icydog (923695) | more than 4 years ago | (#29640239)

How is salting relevant to over-the-network, slow brute force attacks that don't involve seeing the hashes?

Re:learn to.... (5, Funny)

Nested (981630) | more than 4 years ago | (#29640293)

Obviously it's only relevant by outing parent as a random Windows admin.

Re:learn to.... (2, Insightful)

Brian Gordon (987471) | more than 4 years ago | (#29640257)

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.

Re:learn to.... (0)

Anonymous Coward | more than 4 years ago | (#29640255)

DOES NOT WORK.

RTFA. fail2ban doesn't solve this problem. Stop pandering your dated solutions.

Re:learn to.... (1)

Trogre (513942) | more than 4 years ago | (#29640755)

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.

It's 2009 and will be 2010 soon (1)

gzipped_tar (1151931) | more than 4 years ago | (#29640199)

And boxes are still being hacked by *bruteforce* attacks?

I thought SSH Public key auth. is so 20th century.

Re:It's 2009 and will be 2010 soon (1)

gweihir (88907) | more than 4 years ago | (#29640545)

These are password-guessing attacks. No connection to public-key authentication.

Re:It's 2009 and will be 2010 soon (1)

gzipped_tar (1151931) | more than 4 years ago | (#29640731)

I mean, why are password based auth used in the first place?

Re:It's 2009 and will be 2010 soon (4, Informative)

HeronBlademaster (1079477) | more than 4 years ago | (#29640821)

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...

Ask Slashdot (4, Interesting)

Brian Gordon (987471) | more than 4 years ago | (#29640237)

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:Ask Slashdot (1)

i.of.the.storm (907783) | more than 4 years ago | (#29640341)

This is a good question, I'd like to know as well. I check every now and then and see a bunch of random login attempts that look like brute force (eg. root login attempts when we have root login disabled) but I don't really know whether I should be worried.

Re:Ask Slashdot (4, Informative)

robbak (775424) | more than 4 years ago | (#29640527)

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 (3, Interesting)

armanox (826486) | more than 4 years ago | (#29640677)

I see a lot of seemingly valid logins (could be valid, but not on my system...)

Running awk 'gsub(".*sshd.*Failed password for (invalid user )?", "") {print $1}' /var/log/secure* | sort | uniq -c | sort -rn | head -10'> yields

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:Ask Slashdot (2, Informative)

armanox (826486) | more than 4 years ago | (#29640707)

btw, numbers used to be higher, but I just archived the old secure logs, and have seen a massive drop in attacks since I started using denyhosts. Root used to see ~10k attacks in a week.

Re:Ask Slashdot (2, Interesting)

Chris Daniel (807289) | more than 4 years ago | (#29640509)

tenshi [inversepath.com] is cool.

Linux: the weakest OS (-1, Troll)

Anonymous Coward | more than 4 years ago | (#29640273)

I'll stick to safe and secure Windows 7. This is what happens when you run a hobby OS instead of a professionally coded program meant for serious work. Maybe if these lazy and slothful Linux admins would just put down the Bawlz, maybe the state of virus attacks would lessen.

Simple solution! (1)

PsiPsiStar (95676) | more than 4 years ago | (#29640285)

this time 770 apparently already compromised Linux hosts are involved

<sarcasm> chmod 750 ? </sarcasm>

Re:Simple solution! (1, Funny)

MichaelSmith (789609) | more than 4 years ago | (#29640375)

chmod 0 `find /`

Paging Charles Darwin (1)

Gothmolly (148874) | more than 4 years ago | (#29640311)

Only the strong survive.

Re:Paging Charles Darwin (1)

ScrewMaster (602015) | more than 4 years ago | (#29640505)

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.

The Headline (2, Insightful)

MagusSlurpy (592575) | more than 4 years ago | (#29640339)

Couldn't we remove "Linux" from the headline and have it be just as accurate?

Re:The Headline (1)

mx_mx_mx (1625481) | more than 4 years ago | (#29640373)

No, because linux admins aren't usually that sloppy, compared to windows admins....

Re:The Headline (0, Troll)

Anonymous Coward | more than 4 years ago | (#29640383)

Couldn't we remove "Linux" from the headline and have it be just as accurate?

Ahh, yes let's remove the fact that this is Loonix boxes being brute force attacked because it would hurt the "ZOMG TEH LOONIX CAN NOT BE H4X0R3D THATS ONLY DUH WINDOZE BOXES!!".

Re:The Headline (1)

shentino (1139071) | more than 4 years ago | (#29640771)

Windows admins being sloppy doesn't make the news.

Also, the fud machine favors attention granted to linux's foibles.

Re:The Headline (0)

Anonymous Coward | more than 4 years ago | (#29640959)

Oh yes it does. You do read Slashdot, correct?

Re:The Headline (1)

Exception Duck (1524809) | more than 4 years ago | (#29640419)

Sloppy Windows admins who use linux slow brute force attacks

A REALLY SLOW attack ... (5, Insightful)

Jerry (6400) | more than 4 years ago | (#29640395)

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 (2, Interesting)

MichaelSmith (789609) | more than 4 years ago | (#29640423)

They will eventually compromise a system which has keys for other systems, so the success rate will increase.

Re:Until they hit the jackpot (1)

Penguinshit (591885) | more than 4 years ago | (#29640485)

Even a 100% increase would still be insignificant to the numbers of Windows bots.

Re:Until they hit the jackpot (1)

benjamindees (441808) | more than 4 years ago | (#29640489)

Are you kidding me? This is a useful story to keep new *nix admins on their toes but it's nowhere near a threat. 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.

Re:Until they hit the jackpot (1)

ScrewMaster (602015) | more than 4 years ago | (#29640521)

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:A REALLY SLOW attack ... (1)

AmberBlackCat (829689) | more than 4 years ago | (#29640665)

Maybe the number of bots in the network is related to how popular the operating system is. And maybe 770 is just the ones they know about. There are enough "maybe"'s for everybody, no matter what side you're on. And I've got one more; maybe one day Linux will become mainstream and all of the botnets will be on Linux machines because most of the Windows users are actually looking for these threats while most of the Linux users just assume their system is invulnerable and make excuses any time there is a counterexample.

Michael Jordan Shoes (0)

Anonymous Coward | more than 4 years ago | (#29640679)

Air Jordan 4 [usa-jordan.com]
Air Jordan 5 [usa-jordan.com]
Air Jordan 6 [usa-jordan.com]
Air Jordan 7 [usa-jordan.com]

A measely 6k attempts over 4 days? Who cares? (3, Insightful)

ChaosDiscord (4913) | more than 4 years ago | (#29640445)

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.

Re:A measely 6k attempts over 4 days? Who cares? (4, Insightful)

DeadPixels (1391907) | more than 4 years ago | (#29640461)

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".

Re:A measely 6k attempts over 4 days? Who cares? (4, Funny)

ScrewMaster (602015) | more than 4 years ago | (#29640535)

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? (3, Interesting)

sumdumass (711423) | more than 4 years ago | (#29640819)

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 ths were a windows story (1, Troll)

smash (1351) | more than 4 years ago | (#29640449)

... we'd all be making fun of how insecure M$ is, amirite?

Incompetence with security matters means you will get owned sooner or later, whatever OS you're running. There are plenty of microsoft tools out there to secure your shit, just as there is for Linux or any of the BSDs.

Re:if ths were a windows story (0)

Anonymous Coward | more than 4 years ago | (#29640859)

It would never be a windows story :p

BFD (1)

JacobSteelsmith (911307) | more than 4 years ago | (#29640451)

I use BFD [rfxn.com] and CPanel enforced strong passwords. I don't know how well BFD would do against distributed attacks though. I also don't allow SSH access to just anyone, and if I do, it's using public key authentication, but they have to have a very good reason. SSH is also listening on a non-standard port. Really, the vast majority of clients will never *need* SSH.

guilty! (1, Funny)

Anonymous Coward | more than 4 years ago | (#29640491)

I haven't updated my server since 2004. it runs debian 3.

There were all kinds of root logins from brazil last month, so I did permitRootLogin no but haven't got any farther than that yet.

It is colocated and they haven't sent a bill in 4 years so I don't want to go in and upgrade it or they might realize it is there!

If it's SSH it's really easy to rate limit attacks (1)

aarggh (806617) | more than 4 years ago | (#29640507)

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 (3, Informative)

aarggh (806617) | more than 4 years ago | (#29640557)

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:If it's SSH it's really easy to rate limit atta (1)

GWRedDragon (1340961) | more than 4 years ago | (#29640881)

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

Yep, pretty much. Try rejecting with tcp reset if you want the bots to give up faster.

iptables -A INPUT -p tcp --syn --dport 22 -m recent --set
iptables -A INPUT -p tcp --dport 22 --syn -m recent --rcheck --seconds 1000 --hitcount 3 -j REJECT --reject-with tcp-reset

Re:If it's SSH it's really easy to rate limit atta (1)

jamesh (87723) | more than 4 years ago | (#29640935)

We have a few class C networks with about 30-50% usage. Any attempted by an IP address to hit port 22 on an unused IP gets put on an iptables 'recent' block list and it stays there until it hasn't been heard from for 5 minutes. It isn't a bulletproof security measure by any means but it sure cuts down the noise, which makes reviewing the logs a bit more useful.

I wish I had IPv6... assuming you can't axfr my dns zone to determine active hostnames, you have a in 2^48 chance of hitting an actual host, and a (2^48 - ) in 2^48 chance of being blocked for 5 minutes after the last time my firewall hears from you. The downside is that the hackers/bots probably have 2^48 addresses to choose from too, making my block list overflow. oh well :)

Re:If it's SSH it's really easy to rate limit atta (1)

XanC (644172) | more than 4 years ago | (#29640853)

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 (2, Interesting)

MichaelSmith (789609) | more than 4 years ago | (#29640939)

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 (5, Interesting)

Bigjeff5 (1143585) | more than 4 years ago | (#29640961)

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? (1)

TheSunborn (68004) | more than 4 years ago | (#29640563)

Does any Linux distribution come with a default ssh config that allow root to login via ssh?

Re:Login as root. Does any Linux distribution allo (1)

xous (1009057) | more than 4 years ago | (#29640675)

I believe the default gentoo configuration file does. There is nothing wrong with allowing root to login.

Re:Login as root. Does any Linux distribution allo (1)

armanox (826486) | more than 4 years ago | (#29640697)

Plenty do. Slackware, Fedora, CentOS, Debian, just to name a few.

Re:Login as root. Does any Linux distribution allo (0)

Anonymous Coward | more than 4 years ago | (#29640953)

CentOS / RedHat Enterprise Linux

770? (1)

Col Bat Guano (633857) | more than 4 years ago | (#29640583)

When it gets to 777 all users will have read/write access to the files!

Just Ban IPs after failed login attempts? (0)

Anonymous Coward | more than 4 years ago | (#29640747)

Not that I've done much in a big professional system, so feel free to tell me to STFU and go home...

Wouldn't it be feasable to ban IPs with X unsuccessful login attempts for long periods of time (perhaps longer than the "user must change password" time)? Perhaps making X something larger than the per-user login attempt ban so one bad day doesn't ruin loggin in forever?

Re:Just Ban IPs after failed login attempts? (1)

MichaelSmith (789609) | more than 4 years ago | (#29640925)

The problem is the size of the resulting database. Say you have a million hosts to ban. Thats a million IP addresses to check before accepting a legitimate connection.

This is a lot more benign (0, Offtopic)

mysidia (191772) | more than 4 years ago | (#29640911)

Than the worms enabled by sloppy Windows admins who fail to apply server patches...

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?