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."
Outward facing systems ... (Score:5, Informative)
learn to.... (Score:5, Informative)
sudo apt-get install fail2ban
Re:learn to....denyhosts (Score:5, Informative)
Re:Ask Slashdot (Score:5, 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.
Re:If it's SSH it's really easy to rate limit atta (Score:4, Informative)
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:Outward facing systems ... (Score:4, Informative)
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 ... (Score:2, Informative)
Port knocking is a good way to conceal that ssh is available. Use fwknop!
Re:Ask Slashdot (Score:3, Informative)
Re:Outward facing systems ... (Score:3, Informative)
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 ... (Score:5, 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.
Re:It's 2009 and will be 2010 soon (Score:5, 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...
Re:Outward facing systems ... (Score:3, Informative)
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?
Your assumption about Debian's problems with ssh is rather unlikely. The only way weak keys still exist is if the system hasn't been updated in the last couple of years.
When Debian pushed out the ssh update they also pushed out an automated check for weak passwords that ran before the update was finished. The script told the admin if any weak keys existed on the machine and that they needed to be updated immediately.
Of course, you could be right that there are admins stupid enough to have ignored all that. I saw a request for help on how to enable root login for ssh just a couple of weeks ago, and the poster didn't reply to posts saying that allowing root login was a very bad idea.
My solution to this problem: (Score:5, 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 [cnet.com]
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 [builderau.com.au]
you would think we could put that old chestnut to bed by now.
Re:overly paranoid (Score:3, Informative)
The trick to making strong passwords is to not use them at all.
Random passwords don't work. People don't remember them, or they write them down, or they use the same one everywhere. Any of these options compromises the security of a 'bulletproof' random password.
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.
Better yet, smart cards are even harder to clone, especially if you don't have physical access to the card.
Re:Outward facing systems ... (Score:3, Informative)
Setting your ssh port to a high number is not a bad idea at all. All these brute-forcing ssh scanners don't portscan a host looking for ssh on any port, they connect to port 22 and see what is there. Moving it to any other port will reduce the incidence of these botnet scans by an order of magnitude, if not eliminate it entirely.
A non-root user can not run software that binds to low numbered ports, so having someone else on the system impersonate sshd is a non issue.
Secondly, as many mention, turning off password authentication altogether is another very good way to prevent these attacks, doing both (passwordless authentication on a port that is not 22) will virtually eliminate altogether these random scans.
If you don't have password authentication on, then even if someone impersonates sshd, they won't get any useful information from you.
Impossible to detect, so forget it (not!) (Score:2, Informative)
Let me make the same mistake you made and state: In the same way that it is impossible to use system logs to detect a compromise, it is in general impossible to conclude that a system is compromised even given a full dump of its state (stopping problem).
But we all know that that is not the case in reality/practicality, only a minuscule fraction of compromised systems would be compromised in such a careful way, leading us to believe that it is worthwhile to try to detect compromise.
Re:Impossible to detect, so forget it (not!) (Score:3, Informative)
I will add to this that any decently secured system will log all activities to an external machine through a logging service which does not allow for said machine to remove any logged events. That way two machines will need to be compromised to hide the fact.
This also protects against your legit admins doing some dodgy work and then deleting the evidence.
Re:Outward facing systems ... (Score:4, Informative)
No. It's about SSH being run on, for example, port 2222.
If SSH crashes (or is crashed), that means bad_guy can launch his honeypot on port 2222 now, something that would NOT be doable were it running on a privileged port.
Re:Ask Slashdot (Score:1, Informative)
I've actually been rooted, and I actually got notice of it via a tripwire email. If the attacker is sloppy it works.
Re:Outward facing systems ... (Score:2, Informative)
Re:Outward facing systems ... (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.
ever tried to scp an important system file? (Score:4, Informative)
Yes. I copy it with my regular, non privileged account and then change ownership and permission in the target machine as root.
You don't need root for one of transfer of files.