How to easily switch between ansible versions

Lately I’ve run into issues with different versions of ansible (1.9 handling async better, 2.x having more modules and handling IPv6 better) and having to test playbooks and roles against different versions to make sure they work. TO make life easier I put this little function in my .bashrc to switch back and forth between ansible versions. It checks out the specified version from github if it needs to, and switches over to it (just for that terminal, not the system). Usage is straight forward ansible_switch <branch> , i.e. ansible_switch 2.1  (or whatever branch you want, here is a list of all branches).

It is currently limited to stable branches, but you can change line 6 from stable- to whatever you want (or remove the prefix completely). If you have a github account you also may want to change from https to ssh by using the git@github.com:ansible/ansible.git checkout URL.

 

Ansible tasks to reboot a server if required

A quick one today.  The following ansible tasks check if a server needs to be rebooted, reboots it, and then waits for it to come back online. Easy to fire off during a maintenance after updating packages.

 


How to check if you are vulnerable for the DROWN attack (CVE-2016-0800).

CVE-2016-0800, also known as the DROWN attack, is an attack against servers that still support the old SSLv2 protocol. The only reason a server would still offer to use SSLv2 would be for possible compatibility reasons with 20-year-old PCs ( -> there is no reason to use or offer SSLv2 any more). From a configuration side you can disable the v2 protocol by adding  -SSLv2 to the list of protocols being used.

Where and how you configure this depends on the software, but using all -SSLv2 -SSLv3 is fine with most modern servers and clients, Mozilla has a fantastic overview for configuring SSL and TLS.

If you want to check a bunch of your hosts remotely, you can use the sslv2 script included with nmap like this:

Where hostname would be either a FQDN, or an IP, or an IP range. You can swap out  sslv2 with  ssl-enum-ciphers to see all SSL /TLS ciphers and protocols the server offers.

 


Granular OSSEC Emails

Occasionally I see questions on the OSSEC mailing list on how to send a bunch of alerts only to a specific email address. An example for a typical use case would be different departments responsible for different groups of servers and having alerts only go to them. OSSEC has a few options for sending Alerts to specific email addresses, but it only adds those email addresses to the alert (meaning it always goes to the global email address). Sometimes this isn’t desirable.

A workaround is setting the global email recipient to a blackhole email address (something that is aliased to /dev/null on the mail server) and only using the granular settings for delivering mail.

You can then use attributes like the rule ID, group names, or event locations to split up alerts to different recipients. The downside is that by doing this, you will miss alerts with  <options>alert_by_email</options> and a low level, unless you add a few granular email alerts. Rule 1002 (catch-all $BAD_WORDS) is a good candidate you will want to keep on receiving. Rules 501-504 (OSSEC agent/master status alerts) could also be interesting; either add an <email_alert>  for each rule individually, or overwrite the rules adding  <group>ossec,</group> to then, so you can add one <email_alert>  for the group of rules.

We use this system pretty extensively assigning alerts to email groups by <event_location>  and/or <group>

An example for the email block could look like this:

 


A script to diff files/directories on two different servers

Ok,  short one today. This is a straightforward script that simplifies comparing directories on different servers. There is no magic in it, it just rsyncs the directories to a local temp directory and runs diff against them (then deletes the directory afterwards). Mainly intended for config files, I wouldn’t recommend trying to diff gigabytes of binaries with it.