security

Cloning private GitHub repositories with Ansible on a remote server through SSH

One of Ansible's strengths is the fact that its 'agentless' architecture uses SSH for control of remote servers. And one classic problem in remote Git administration is authentication; if you're cloning a private Git repository that requires authentication, how can you do this while also protecting your own private SSH key (by not copying it to the remote server)?

As an example, here's a task that clones a private repository to a particular folder:

- name: Clone a private repository into /opt.
  git:
    repo: git@github.com:geerlingguy/private-repo.git
    version: master
    dest: /opt/private-repo
    accept_hostkey: yes
  # ssh-agent doesn't allow key to pass through remote sudo commands.
  become: no

If you run this task, you'll probably end up with something like:

How to securely erase free space on a hard drive (Mac)

From time to time, I need to clean off the contents of a hard drive on one of my Macs—most often this is the case prior to selling the mac or giving it to someone else. Instead of just formatting the drive, installing macOS, then handing it off, I want to make sure all the contents I had stored on it are irrecoverably erased (I sometimes work on projects under NDA, and I also like having some semblance of privacy in general).

Disk Utility used to expose this functionality in the UI, which made this a very simple operation. But it seems to have gone missing in recent macOS versions. Luckily, it's still available on the command line (via Terminal.app):

diskutil secureErase freespace 0 "/Volumes/Macintosh HD"

This command would write zeroes on the entire 'Macintosh HD' drive. You can see a list of all the drives connected to your Mac with ls /Volumes. There are a few other common options available (instead of 0) if you run man diskutil and scroll down to the secureErase section. I most commonly use:

Fastest way to reset a host key when rebuilding servers on the same IP or hostname frequently

I build and rebuild servers quite often, and when I want to jump into the server to check a config setting (when I'm not using Ansible, that is...), I need to log in via SSH. It's best practice to let SSH verify the host key every time you connect to make sure you're not getting MITMed or anything else is going on.

However, any time you rebuild a server from a new image/OS install, the host key should be new, and this will result in the following message the next time you try to log in:

Blog post id enumeration can lead to unwanted information disclosure

With the rampant speculation there will be a new Raspberry Pi model released next week, I was wondering if the official Raspberry Pi blog might reveal anything of interest; they just posted a Four Years of Pi blog post on the 26th, which highlighted the past four years, and mentioned the excitement surrounding 4th anniversary of Pi sales, coming up on February 29th, 2016.

Glancing at the blog's source, I noticed it looks like a Wordpress blog (using httpie on the cli):

$ http https://www.raspberrypi.org/blog/four-years-of-pi/ | grep generator
<meta name="generator" content="WordPress 4.4.2" />

Having set up a few WP sites in the past, I knew there was a simple way to load content by its ID, using a URL in the form:

Drupal on Mothballs - Convert Drupal 6 or 7 sites to static HTML

Drupal.org has an excellent resource page to help you create a static archive of a Drupal site. The page references tools and techniques to take your dynamically-generated Drupal site and turn it into a static HTML site with all the right resources so you can put the site on mothballs.

From time to time, one of Midwestern Mac's hosted sites is no longer updated (e.g. LOLSaints.com), or the event for which the site was created has long since passed (e.g. the 2014 DrupalCamp STL site).

I though I'd document my own workflow for converting typical Drupal 6 and 7 sites to static HTML to be served up on a simple Apache or Nginx web server without PHP, MySQL, or any other special software, since I do a few special things to preserve the original URL alias structure, keep CSS, JS and images in order, and make sure redirections still work properly.

Fixing Drupal Fast - Using Ansible to deploy a security update on many sites

Earlier today, the Drupal Security Team announced SA-CORE-2014-005 - Drupal core - SQL injection, a 'Highly Critical' bug in Drupal 7 core that could result in SQL injection, leading to a whole host of other problems.

While not a regular occurrence, this kind of vulnerability is disclosed from time to time—if not in Drupal core, in some popular contributed module, or in some package you have running on your Internet-connected servers. What's the best way to update your entire infrastructure (all your sites and servers) against a vulnerability like this, and fast? High profile sites could be quickly targeted by criminals, and need to be able to deploy a fix ASAP... and though lower-profile sites may not be immediately targeted, you can bet there will eventually be a malicious bot scanning for vulnerable sites, so these sites need to still apply the fix in a timely manner.

In this blog post, I'll show how I patched all of Midwestern Mac's Drupal 7 sites in less than 5 minutes.

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.

Pages

Subscribe to RSS - security