security

Secure your servers from Shellshock Bash vulnerability using Ansible

Now that all Server Check.in infrastructure is managed by Ansible (some servers are running CentOS, others are running Ubuntu), it's very simple to update all the servers to protect against vulnerabilities like Heartbleed or today's new Shellshock bash vulnerability.

For CentOS (or RedHat)

$ ansible [inventory_group] -m yum -a "name=bash state=latest" [-u remote_username] [-s] [-K]

For Debian (or Ubuntu)

$ ansible [inventory_group] -m apt -a "update_cache=yes name=bash state=latest" [-u remote_username] [-s] [-K]

If you have a different method of patch management, or you need to apply the fixes manually, then this method won't apply—but for most infrastructure using normal system-provided packages, using the above commands will get the fixes with minimal effort.

A little further explanation:

A brief history of SSH and remote access

This post is an excerpt from Chapter 11: Server Security and Ansible, in Ansible for DevOps.

In the beginning, computers were the size of large conference rooms. A punch card reader would merrily accept pieces of paper that instructed the computer to do something, and then a printer would etch the results into another piece of paper. Thousands of mechanical parts worked harmoniously (when they did work) to compute relatively simple commands.

As time progressed, computers became somewhat smaller, and interactive terminals became more user-friendly, but they were still wired directly into the computer being used. Mainframes came to the fore in the 1960s, originally used via typewriter and teletype interfaces, then via keyboards and small text displays. As networked computing became more mainstream in the 1970s and 1980s, remote terminal access was used to interact with the large central computers.

Restrict access to the Apache Solr admin interface

I've helped many people set up or fix a botched install of Apache Solr on their VPSes and web servers. Most of the time, I've noticed that people leave the administrative frontend to Solr wide open for anybody on the internet to access, by just accessing http://example.com:8983/solr. This is very dangerous, as not only can anyone browse and query your search indexes, they can even add, delete, or change your search cores, and see sensitive system information that can be used to gain further access!

Solr Dashboard
The Apache Solr admin dashboard

Quickly generate secure, random passwords (Mac)

If you use Mac OS X, add the following line to your .bash_profile:

alias passme='openssl rand 48 -base64 | pbcopy'

Whenever you need a password (like when you're registering a new account or resetting your password because yet another online service you used was hacked), just fire up the Terminal and type in passme. Then paste the password that's copied to your clipboard into the password fields, and into your password manager (I use 1Password).

This alias simply uses openssl to generate a random base64-encoded string with 48 characters (you can change that value to whatever you want). If the online service you use doesn't allow 48 characters in the password field, you should file a support request with that online service, telling them they're being silly only allowing X characters in a password.

Preventing Security Holes

I was recently browsing a very popular review website, when I noticed the following warnings popping up:

Angie's List website errors

From simply loading their web page and seeing these error messages, I could conclude:

  1. The website is using Drupal.
  2. The website is using memcached.
  3. The website is running on Acquia's managed hosting cloud.
  4. The website has error reporting set to print all errors to the screen.

If I were trying to break into this review site, or cause them a bad day, the information presented in this simple error message would help me quickly tailor my attacks to become much more potent than if I started from a blank slate.

Security through obscurity

I will quickly point out that security through obscurity—thinking you're more secure simply because certain information about your website is kept secret—is no security at all. However, that doesn't mean that obscurity is not an important part of your site's security.

Manage your Passwords Wisely

This is somewhat of a PSA: There have been many high-profile hacking cases lately where millions of user account passwords have been exposed. If you're anything like the majority of the population, and you're using one password for more than one website, you should stop doing that as soon as possible and switch to a more secure password strategy.

I've outlined what I do on Midwestern Mac's website: My Password Management Strategy.

You can't blame me for one of your accounts being accessed by a hacker! Also, if you're a web developer or application programmer, and you're not salting, stretching, and hashing all user passwords with something like SHA-2, you need to do that yesterday.

My Password Management Strategy

In light of the many high-profile hacking cases that have recently exposed millions and millions of user passwords (LinkedIn, Sony, etc.), I thought I would write down my password management practices, and some practical thoughts for others looking to secure their access to various online services.

Shared Passwords (major no-no)

For a long time, I had three passwords: a weak, eight-character password that I'd use on forums and places I didn't really care about. I had a ten-character password with a number, a capital letter, and a symbol, for medium security (like sites that had my credit card in my account). And I had a fourteen-character password which was truly random (generated by Keychain Access on my Mac) for a couple services that I needed to be extremely secure.

But, none of these passwords are truly adequate nowadays—especially since I reused the passwords on a variety of sites and services! Additionally, I often had trouble remembering which password I used on what site, and had to try all three before successfully logging in.

Simple iptables rules for a typical LAMP server

I've seen a ton of iptables configurations on the Internet, and none of them really got to the heart of what I need to do for the majority of my LAMP-based web servers (hosted on Linode, HostGator, Hot Drupal, and elsewhere). For these servers, I just need a really simple set of rules that restricts all incoming traffic except for web (port 80/443 for http/https traffic), ssh (usually port 22), smtp (port 25), and icmp ping requests.

The script below (save it as 'firewall.bash', chmod u+x it to make it executable, and run it with $ sudo /path/to/firewall.bash, then test your server (access websites, log on to it from another Terminal session, ping it, etc., and make sure that's all working)):

Fixing Problems with Passwordless SSH Authentication

I use CentOS, but these guidelines should apply no matter what flavor of linux you use. We all know it's a good security practice to lock down your server and require SSH logins to use an RSA key/pair, rather than a password, right? Plus, it makes it easier for you to login to your server from your primary computers/devices...

I was setting up a new server recently, and spent probably half an hour figuring out why the standard way of creating a shared key, sending it to the server, putting it in /home/[username]/.ssh/authorized_keys, and trying to log in without a password wasn't working for me.

It turns out, there were permissions issues I hadn't thought of (I usually would create accounts through cPanel, since I only live in the Terminal out of necessity, from time to time). When you create the authorized_keys file, which contains public SSH keys for your computers, you need to make sure the permissions are set so that:

Subscribe to security