Slashdot Mirror

← Back to Stories (view on slashdot.org)

Sloppy Linux Admins Enable Slow Brute-Force Attacks

Posted by kdawson on 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."

30 of 391 comments (clear)

  1. Outward facing systems ... by taniwha · · Score: 5, Informative

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

    1. Re:Outward facing systems ... by quintus_horatius · · Score: 5, Insightful

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

    2. Re:Outward facing systems ... by marcansoft · · Score: 4, Funny

      Or you could just not use weak passwords.

    3. Re:Outward facing systems ... by icydog · · Score: 5, Insightful

      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?

    4. Re:Outward facing systems ... by Antique+Geekmeister · · Score: 4, 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.

    5. Re:Outward facing systems ... by Korin43 · · Score: 4, Interesting

      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.

    6. Re:Outward facing systems ... by mysidia · · Score: 4, Informative

      Better yet, keep the port closed to the outside world. Use port knocking with software such as Aldaba to control the ability to ssh in.

    7. Re:Outward facing systems ... by mysidia · · 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

    8. Re:Outward facing systems ... by SanityInAnarchy · · Score: 4, 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.

      --
      Don't thank God, thank a doctor!
    9. Re:Outward facing systems ... by cetialphav · · 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.

    10. Re:Outward facing systems ... by profplump · · Score: 4, 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.

    11. Re:Outward facing systems ... by IMightB · · 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.

  2. learn to.... by gandhi_2 · · Score: 4, Informative

    sudo apt-get install fail2ban

    --
    THL phish sticks
    1. Re:learn to.... by icydog · · Score: 4, Insightful

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

    2. Re:learn to.... by Nested · · Score: 5, Funny

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

  3. Ask Slashdot by Brian+Gordon · · Score: 4, 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.

    1. Re:Ask Slashdot by robbak · · Score: 4, 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.

      --
      Prediction for end of Universe #42: Fencepost error in Quantum_bogosort.cpp
    2. Re:Ask Slashdot by cetialphav · · 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.

  4. Re:learn to....denyhosts by nairb774 · · Score: 5, Informative

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

  5. overly paranoid by SuperBanana · · 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.

    --
    Please help metamoderate.
    1. Re:overly paranoid by digitalchinky · · Score: 4, Insightful

      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.

    2. Re:overly paranoid by Lumpy · · Score: 4, 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.

      --
      Do not look at laser with remaining good eye.
  6. A REALLY SLOW attack ... by Jerry · · 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.

    --

    Running with Linux for over 20 years!

    1. Re:A REALLY SLOW attack ... by ArsonSmith · · Score: 4, Funny

      I run windows so I'm safe.

      --
      Paying taxes to buy civilization is like paying a hooker to buy love.
  7. Re:A measely 6k attempts over 4 days? Who cares? by DeadPixels · · Score: 4, Insightful

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

  8. Re:A measely 6k attempts over 4 days? Who cares? by ScrewMaster · · Score: 4, 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"

    --
    The higher the technology, the sharper that two-edged sword.
  9. Re:It's 2009 and will be 2010 soon by HeronBlademaster · · Score: 4, 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...

  10. my examples assume the attacker knows the scheme by SuperBanana · · 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.

    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.
  11. Re:If it's SSH it's really easy to rate limit atta by Bigjeff5 · · 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.

    --
    Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
  12. My solution to this problem: by Tracy+Reed · · Score: 4, 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

    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.