The supposed OpenSSH vulnerability that Anti-Sec claimed would destroy the Internet never appeared. There were only a couple of interesting security announcements that day, none of which were as dramatic as what the OpenSSH release was supposed to be.
This leads to the question of how all of us, as users of the Internet, should respond to items such as this. On the one hand we can think of it as a schoolyard bully going for cheap intimidation, but on the other hand, when the bully has a history of abusing fireworks and now says that he has a bomb in his garage, it may be worth paying attention. Without the ability to search his garage, I think it makes sense to keep the kids out of school on the day that he says he'll blow it up.
Vigilance should never see a reduction in intensity but should be metered with common sense and rational thought. I don't advocate jumping at shadows, but I also caution against ignoring future claims because a group cried wolf. Each incident must be viewed in isolation and a response crafted that is appropriate for the severity of the cause.
We still recommend that SSH be secured, by restricting access to certain usernames and IPs or else by using a VPN or port knocking to limit access. The prevalence of brute force attacks against SSH accounts is, at the very least, an abuse of services. You pay for that bandwidth. Your system has to process the dictionary of usernames and passwords, and brute force attack software is getting stronger by the day. Some dictionary attacks can crash the system, making it a DOS attack by result (if not by intent). Why subject your environment to the risk of failure for the convenience of unrestricted access?
Adrian was describing the Anti-Sec claim for discovering a critical hole in OpenSSH a few days ago. Nothing was released, and this all seems to be no more than FUD designed to cause chaos and disruption in the IT industry It's still a valuable lesson, and we all should take a look at our machines. Having SSH access (or any other access to the system itself) properly secured from cracking attempts may help to prevent huge data and money loss for everyone's business, especially when it is not a big hassle to secure. Here are a few suggestions on how to make your data center more secure and less vulnerable to cracking:
Increase logging verbosity. Having more information is always better than lacking it. By setting 'LogLevel INFO' variable in OpenSSH config you are giving yourself a chance to spot malicious activity on your servers while it is actually happening. You can even install a log analysis tool of your choice to raise alarm as soon as something interesting arises.
Increase process privilege security and checking. Make sure you have variables 'UsePrivilegeSeparation yes' and 'StrictModes yes' set up and uncommented in the config file. The SSH daemon requires high system privileges for running and therefore can be exploited to gain root privileges upon a connection attempt. First of these settings makes sure that the each connection attempt will be processed in a separately chrooted, empty environment from which the attacker will unlikely escape, even upon successful privilege escalation. The second option is responsible for checking if the user's directory and key file permissions settings are secure, just before landing the user in her home directory.
Disable password authentication in favor of public key authentication. Most people use passwords to access their systems, which can make their systems vulnerable to bruteforce attacks. By using password protected public and private key pairs placed on the systems and the client machine and configuring the OpenSSH daemon you can greatly enhance the system security, because a password is no longer used to authenticate on server. Follow this guide on how to configure OpenSSH and create key pairs.
Limit users and groups allowed to log in. While logging to the system directly as a root user can certainly be comfortable, it is very insecure and should not be practiced. This should be disabled by using 'PermitRootLogin no' directive in OpenSSH config file, and additional authentication mechanism like su or sudo should be used to gain root privileges instead. Additionally, you should narrow the users and groups that are allowed to log in, by usage of 'AllowUsers' and 'AllowGroups' (or 'DenyUsers' and 'DenyGroups' accordingly) directives depending on your environment requirements. If root login is required, use the 'PermitRootLogin without-password' option to force root logins to use the SSH keypairs only.
Configure your firewall. In most cases you are connecting to your systems from known locations, such as your company's office, your datacenter, your house, or your vpn network. Therefore, there is no need to keep access to your SSH port open for the whole world. Use an external firewall or firewall software such as iptables, pf, or ipfw on the system itselft to restrict traffic to the SSH port from anything that is not your trusted location. What is a trusted location? Your office would be, and your datacenter also, but a computer in internet cafe, or laptop using public WiFi network isn't. What about your house? If you take care to secure your home computer and access to your home network then it also might be considered as secure location. Everything else must not be able to reach the SSH port.
Be proactive. It might sound boring, but it needs to be repeated - be proactive. Prevent the damage instead of recovering from the disaster. Stay up to date with your machines. Update the kernel and software as soon as security patches are released. Watch out for know holes in daemons you use to provide services. Have backups, and test them regularly. There isn't anything worse than realizing your backups are empty or broken on the day when you need them. Scan your network regularly for open ports or new services - your users or employees might be doing things, even not intentionally, that you wouldn't like, such as disabling firewalls or launching daemons that should not be launched. You need to know these things before something happens, and the only way to stay aware is to be proactive.
These steps aren't complicated, and they can increase the security of any environment, ultimately resulting in less downtime or financial loss. However, in a large server farm this can be time-consuming to implement, especially when companies are reducing the number of employees just to survive the economic crisis. It's very easy for a system to fall as a result of a strike from script kiddies or and automated botnet, especially when this is just a single brick in security wall.
Anti-Sec is the group that claims responsibility for hacking Imageshack 10 days ago. They followed this up today with this posting to the full-disclosure mailing list:
Dear Reader, In 48 hours, the anti-sec movement will publicly unveil working exploit code and full details for the zero-day OpenSSH vulnerability we discovered. It will be posted to the Full-Disclosure security list.
Soon, the very foundations of Information Technology and Information Security will be unearthed as millions upon million of systems running ANY version of OpenSSH are compromised by wave after wave of script-kiddie and malicious hacker.
Within 10 hours of the initial release of the OpenSSH 0-day exploit code, anti-sec will be unleashing powerful computer worm source code with the ability to auotmatically find and compromise systems running any and all versions of OpenSSH.
This is an attack against all White Hat Hackers who think that running a Penetration Test simply searching for known vulnerabilities is all they have to do in order to receive their payment. Anti-sec will savor the moment when White Hat Hackers are made to look like fools in the eyes of their clients.
Sincerely,
-anti-sec
This may be FUD or it may not. The responsible thing to do is to lock down any system with public access to SSH until after Wednesday, when we see what they've got in their hand.
