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

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

    2. 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!
    3. 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
  3. 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/

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

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