Using inspec to test your ansible

Over the past few days I’ve been binge listening to the Arrested Devops podcast. In one of the recent episodes (“Career Change Into DevOps With Michael Hedgpeth, Annie Hedgpeth, And Megan Bohl (ADO102)“) one of the interviewees mentions that she got started in DevOps by using Inspec.

Essentially, inspec is a way of explaining “this is what my server must look like”, so you can then test these statements against a built machine… effectively letting you unit test your provisioning scripts.

I’ve already built a fair bit of my current personal project using Ansible, so I wasn’t exactly keen to re-write everything from scratch, but it did make me think that maybe I should have a common set of tests to see how close my server was to the hardening “Benchmark” guides from CIS… and that’s pretty easy to script in inspec, particularly as the tests in those documents list the “how to test” and “how to remediate” commands to execute.

These are in the process of being drawn up (so far, all I have is an inspec test saying “confirm you’re running on Ubuntu 16.04″… not very complex!!) but, from the looks of things, the following playbook would work relatively well!

Experiments with USBIP on Raspberry Pi

At home, I have a server on which I run my VMs and store my content (MP3/OGG/FLAC files I have ripped from my CDs, Photos I’ve taken, etc.) and I want to record material from FreeSat to play back at home, except the server lives in my garage, and the satellite dish feeds into my Living Room. I bought a TeVii S660 USB FreeSat decoder, and tried to figure out what to do with it.

I previously stored the server near where the feed comes in, but the running fan was a bit annoying, so it got moved… but then I started thinking – what if I ran a Raspberry Pi to consume the media there.

I tried running OpenElec, and then LibreElec, and while both would see the device, and I could even occasionally get *content* out of it, I couldn’t write quick enough to the media devices attached to the RPi to actually record what I wanted to get from it. So, I resigned myself to the fact I wouldn’t be recording any of the Christmas Films… until I stumbled over usbip.

USBIP is a service which binds USB ports to a TCP port, and then lets you consume that USB port on another machine. I’ll discuss consuming the S660’s streams in another post, but the below DOES work :)

There are some caveats here. Because I’m using a Raspberry Pi, I can’t just bung on any old distribution, so I’m a bit limited here. I prefer Debian based images, so I’m going to artificially limit myself to these for now, but if I have any significant issues with these images, then I’ll have to bail on Debian based, and use something else.

  1. If I put on stock Raspbian Jessie, I can’t use usbip, because while ships its own kernel that has the right tools built-in (the usbip_host, usbip_core etc.), it doesn’t ship the right userland tools to manipulate it.
  2. If I’m using a Raspberry Pi 3, there’s no supported version of Ubuntu Server which ships for it. I can use a flavour (e.g. Ubuntu Mate), but that uses the Raspbian kernel, which, as I mentioned before, is not shipping the right userland tools.
  3. If I use a Raspberry Pi 2, then I can use Stock Ubuntu, which ships the right tooling. Now all I need to do is find a CAT5 cable, and some way to patch it through to my network…

Getting the Host stood up

I found most of my notes on this via a wiki entry at Github but essentially, it boils down to this:

On your host machine, (where the USB port is present), run

sudo apt-get install linux-tools-generic
sudo modprobe usbip_host
sudo usbipd -D

This confirms that your host can present the USB ports over the USBIP interface (there are caveats! I’ll cover them later!!). Late edit: 2020-05-21 I never did write up those caveats, and now, two years later, I don’t recall what they were. Apologies.

You now need to find which ports you want to serve. Run this command to list the ports on your system:

lsusb

You’ll get something like this back:

Bus 001 Device 004: ID 9022:d662 TeVii Technology Ltd.
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

And then you need to find which port the device thinks it’s attached to. Run this to see how usbip sees the world:

usbip list -l

This will return:

- busid 1-1.1 (0424:ec00)
unknown vendor : unknown product (0424:ec00)
- busid 1-1.3 (9022:d662)
unknown vendor : unknown product (9022:d662)

We want to share the TeVii device, which has the ID 9022:d662, and we can see that this is present as busid 1-1.3, so we now we need to bind it to the usbip system, with this command:

usbip bind -b 1-1.3

OK, so now we’re presenting this to the system. Perhaps you might want to make it available on a reboot?

echo "usbip_host" >> /etc/modules

I also added @reboot /usr/bin/usbipd -D ; sleep 5 ; /usr/bin/usbip bind -b 1-1.3 to root’s crontab, but it should probably go into a systemd unit.

Getting the Guest stood up

All these actions are being performed as root. As before, let’s get the modules loaded in the kernel:

apt-get install linux-tools-generic
modprobe vhci-hcd

Now, we can try to attach the module over the wire. Let’s check what’s offered to us (this code example uses 192.0.2.1 but this would be the static IP of your host):

usbip list -r 192.0.2.1

This hands up back the list of offered appliances:

Exportable USB devices
======================
- 192.0.2.1
1-1.3: TeVii Technology Ltd. : unknown product (9022:d662)
: /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3
: (Defined at Interface level) (00/00/00)
: 0 - Vendor Specific Class / unknown subclass / unknown protocol (ff/01/01)

So, now all we need to do is attach it:

usbip attach -r 192.0.2.1 -b 1-1.3

Now I can consume the service from that device in tvheadend on my server. However, again, I need to make this persistent. So, let’s make sure the module is loaded on boot.

echo 'vhci-hcd' >> /etc/modules

And, finally, we need to attach the port on boot. Again, I’m using crontab, but should probably wrap this into a systemd service.

@reboot /usr/bin/usbip attach -r 192.0.2.1 -b 1-1.3

And then I had an attached USB device across my network!

Unfortuately, the throughput was a bit too low (due to silly ethernet-over-power adaptors) to make it work the way I wanted… but theoretically, if I had proper patching done in this house, it’d be perfect! :)

Interestingly, the day I finished this post off (after it’d sat in drafts since December), I spotted that one of the articles in Linux Magazine is “USB over the network with USB/IP”. Just typical! :D

Podcast Summary – The Admin Admin Podcast #61 – Not quite so ephemeral

January was a busy month for me – between work, helping direct developments to CCHits.net, organising OggCamp, starting Sociable Tech (more on these later), I’ve now also become a regular co-host on The Admin Admin podcast – a podcast for people who work in IT.

Originally started by Al and Andy, Jerry joined them early in the recording series, and just recently Andy has changed jobs and doesn’t have the time to record at the moment. Ever since Al and Andy approached me at OggCamp ’15, I’ve recorded shows as an occasional guest host and providing feedback on episodes where it was appropriate… so I was happy to receive the message asking if I wanted to become a regular co-host.

As I’ve joined the show, we’ve changed the format slightly, reduced our recording expectations (we’re just aiming for one show a month now) and by our good fortune, my good friend, Dave Lee from The Bugcast, has also been roped in to help with recording and producing… he did a fine job with this show!

So, expect to see more posts from me, talking about the show in here.

In this show (Episode 61) we talk about naming hosts, home labs, routers and firewalls and Jerry and I waffle on about Vagrant…. a LOT :) Oh, and we teach Al what ephemeral means.

Oh, and yes, I explain about my Streisand box in this show and get it *completely and utterly wrong*. It’s rather embarrassing. I’ll explain properly on the next show exactly what happens!!

Getting a PEM file from your OpenSSH Private Key

At work, the system used to get a Windows Administrator password in our OpenStack based system (K5) is derived from the SSH Public Key recorded in the system.

It’s really easy to use, and can be found here: https://decrypt-win-passwd.uk-1.cf-app.net

There is one downside to this though – the application needs the private key to be supplied to it (it’s OK, you regularly rotate your SSH private keys… right??) in PEM format… Now, if you’re any sort of sensible SSH user, you’ve used either OpenSSH’s ssh-keygen command, or PuTTY’s puttygen command… neither of which produce a PEM format key.

So, you need to convert it. After a bit of proding and poking, I found this command

openssl rsa -outform PEM -in ~/.ssh/id_rsa -out ~/.ssh/id_rsa.pem

Like the last post, this is more for me to find stuff in the future, but… if he helps someone else, so much the better!!

A brief guide to using vagrant-aws

CCHits was recently asked to move it’s media to another host, and while we were doing that we noticed that many of the Monthly shows were broken in one way or another…

Cue a massive rebuild attempt!

We already have a “ShowRunner” script, which we use with a simple Vagrant machine, and I knew you can use other hypervisor “providers”, and I used to use AWS to build the shows, so why not wrap the two parts together?

Firstly, I installed the vagrant-aws plugin:

vagrant plugin install vagrant-aws

Next I amended my Vagrantfile with the vagrant-aws values mentioned in the plugin readme:

Vagrant.configure(2) do |config|
    config.vm.provider :aws do |aws, override|
    config.vm.box = "ShowMaker"
    aws.tags = { 'Name' => 'ShowMaker' }
    config.vm.box_url = "https://github.com/mitchellh/vagrant-aws/raw/master/dummy.box"
    
    # AWS Credentials:
    aws.access_key_id = "DECAFBADDECAFBADDECAF"
    aws.secret_access_key = "DeadBeef1234567890+AbcdeFghijKlmnopqrstu"
    aws.keypair_name = "TheNameOfYourSSHKeyInTheEC2ManagementPortal"
    
    # AWS Location:
    aws.region = "us-east-1"
    aws.region_config "us-east-1", :ami => "ami-c29e1cb8" # If you pick another region, use the relevant AMI for that region
    aws.instance_type = "t2.micro" # Scale accordingly
    aws.security_groups = [ "sg-1234567" ] # Note this *MUST* be an SG ID not the name
    aws.subnet_id = "subnet-decafbad" # Pick one subnet from https://console.aws.amazon.com/vpc/home
    
    # AWS Storage:
    aws.block_device_mapping = [{
      'DeviceName' => "/dev/sda1",
      'Ebs.VolumeSize' => 8, # Size in GB
      'Ebs.DeleteOnTermination' => true,
      'Ebs.VolumeType' => "GP2", # General performance - you might want something faster
    }]
    
    # SSH:
    override.ssh.username = "ubuntu"
    override.ssh.private_key_path = "/home/youruser/.ssh/id_rsa" # or the SSH key you've generated
    
    # /vagrant directory - thanks to https://github.com/hashicorp/vagrant/issues/5401
    override.nfs.functional = false # It tries to use NFS - use RSYNC instead
  end
  config.vm.box = "ubuntu/trusty64"
  config.vm.provision "shell", path: "./run_setup.sh"
  config.vm.provision "shell", run: "always", path: "./run_showmaker.sh"
end

Of course, if you try to put this into your Github repo, it’s going to get pillaged and you’ll be spending lots of money on monero mining very quickly… so instead, I spotted this which you can do to separate out your credentials:

At the top of the Vagrantfile, add these two lines:

require_relative 'settings_aws.rb'
include SettingsAws

Then, replace the lines where you specify a “secret”, like this:

    aws.access_key_id = AWS_ACCESS_KEY
    aws.secret_access_key = AWS_SECRET_KEY

Lastly, create a file “settings_aws.rb” in the same path as your Vagrantfile, that looks like this:

module SettingsAws
    AWS_ACCESS_KEY = "DECAFBADDECAFBADDECAF"
    AWS_SECRET_KEY = "DeadBeef1234567890+AbcdeFghijKlmnopqrstu"
end

This file then can be omitted from your git repository using a .gitignore file.

Running Streisand to provide VPN services on my home server

A few months ago I was a guest on The Ubuntu Podcast, where I mentioned that I use Streisand to terminate my VPN connections. I waffled and blathered a bit about how I set it up, but in the end it comes down to this:

  1. Install Virtualbox on my Ubuntu server. Include the “Ext Pack”.
  2. Install Vagrant on my Ubuntu server.
  3. Clone the Streisand Github repository to my Ubuntu server.
  4. Enter that cloned repository, and edit the Vagrantfile as follows:
    1. Add the line “config.vm.boot_timeout = 65535” after the one starting “config.vm.box”.
    2. Change the streisand.vm.hostname line to be an appropriate hostname for my network, and add on the following line (replace “eth0” with the attached interface on your network and “192.0.2.1” with an unallocated static IP address from your network):
      streisand.vm.network "public_network", bridge: "eth0", ip: "192.0.2.1", :use_dhcp_assigned_default_route => false
    3. Add a “routing” line, as follows (replace 192.0.2.254 with your router IP address):
      streisand.vm.provision "shell", run: "always", inline: "ip route add 0.0.0.0/1 via 192.0.2.254 ; ip route add 128.0.0.0/1 via 192.0.2.254"
    4. Comment out the line “streisand_client_test => true”
    5. Amend the line “streisand_ipv4_address” to reflect the IP address you’ve put above in 4.2.
    6. Remove the block starting “config.vm.define streisand-client do |client|”
  5. Run “vagrant up” in that directory to start the virtual machine. Once it’s finished starting, there will be a folder called “Generated Docs” – open the .html file to see what credentials you must use to access the server. Follow it’s instructions.
  6. Once it’s completed, you should open ports on your router to the IP address you’ve specified. Typically, at least, UDP/500 and UDP/4500 for the IPsec service, UDP/636 for the OpenVPN service and TCP/4443 for the OpenConnect service.

Running Google MusicManager for two profiles

I’ve previously made mention of my addiction to Google Play Music… but I was called out recently, and asked about the script I used at the time. I’m sorry to say that I have had some issues with it, and instead, have resorted to using X forwarding. Here’s how I do it.

I create a user account for that other person (note, GMM will only let you upload to 3 accounts using this method. For any more, you’ll need a virtual machine!).

I then create an SSH public/private key with no passphrase.

ssh-keygen -b 2048 -N “” -C “$(whoami)@localhost” -f ~/.ssh/gmm.id_rsa

I write the public key into that new user’s .ssh/authorized_keys, by running:

ssh-copy-id -i ~/.ssh/gmm.id_rsa bloggsf@localhost

I will be prompted for the password of that account.

Finally, I create this script:

This is then added to the startup tasks of my headless-but-running-a-desktop machine.

What to do when your Facebook account gets hacked?

Hello! Congratulations, you’ve been hacked! Oh, OK, that’s probably not how it feels, right?

You’ve probably just had a message from someone to say that your account has been messaging loads of people, or that there is stuff on your timeline that … well, you didn’t put there.

It’s OK. It happens to a LOT of people, because Facebook is a very clear target. Many many people spend large quantities of their life scrolling through the content on there, so it’s bound to be a target, and for some reason, they found your account.

What happened?

So, first of all, let’s address how this probably happened.

  1. Most common: Someone found your password. I’ll cover how this could have happened in a bit – under where it says “Passwords – Something you know” below.
  2. Less common, but still frequent: Someone convinced you (using “Social Engineering” – again, I’ll explain this in a bit) to let them log in as you.
  3. A bit of a stretch, but it does happen occasionally: An application, service, or website you use that is allowed to use Facebook on your behalf, got compromised, and that system is using it’s permissions to use your account to post stuff “as you”.
  4. Someone got into your email account (because of one of the above things) and then asked for a password reset on your Facebook account.

Fixing the problem.

It’s easier to do this from the Facebook website, but you can probably still do all this lot from a mobile device.

Let’s solve the first two. Go into the Facebook Security Settings page, where you should change your password and boot off any sessions that aren’t YOU right now (don’t worry if there’s LOADS there – if you’ve used your phone somewhere that’s not where you are now, Facebook stores it as a new session). You can always log back into those other sessions later if you need to.

The third one can be a bit time consuming: kicking off apps you don’t use (mine was like walking into a museum!). Head into the Facebook Apps Settings page, and start clicking the X buttons to remove the apps you don’t use. Every now and then you might get a message saying that there was an error removing one of those apps. It’s fine, just give it a second and then try again. If someone has got into your account because of one of the first two, it’s probably worth checking this part anyway just in case they did something else to your account than just sending spam…

You might also want to check out your timeline, and remove the messages you sent (if they were posted to your timeline) or contact people who have been messaged to let them know you lost control of your account.

If someone got into your email and started resetting passwords then you’ve got a much worse problem, and I can’t really go into it here, but, it’s probably best to say that if they were just after your Facebook account, you were REALLY lucky. Your email account typically has the ultimate reset code for *EVERY* account password, so it’s probably best to make sure that what I’m saying about Facebook is also true for your email provider!

Making it less likely to happen again in the future.

Passwords – “Something you know”

If you’ve done the above, but you’ve picked a password you’ve used somewhere else before, then you’re kinda setting yourself up for this to happen to you again in the future.

You see, the way that most of these attacks happen is by someone getting hold of a password you’ve used on a less secure site, and then tried logging into your Facebook account with that password they’ve snaffled. Want to see how likely this is? Visit Have I Been Pwned and see if your details are in there (the chances are very very very high!) and you’ll see websites who have been breached in the past and had your details taken from there… and this is just “the ones we know about” – who knows how many other websites have been breached and we don’t know about!

You can prevent this by not using the same password everywhere. I know. It’s hard to think of a new password every time you come to a new website, and how will you remember that password the next time you get there? Well, fortunately, there’s a solution to this one – a password manager. It’s an application for your laptops, desktops and mobile devices that stores your password for you, and tells you about them when you go to login to a website.

What’s more, that password manager can create passwords for you, not like “BobIsMyBestFriend1988” but more like “za{UHCtqi3<6mC_j6TblSk3hwS” (which, unless you’re some kind of savant, you’ll never remember that)…. and then tell you about that in the future. So now, you only need to remember one password to get into the password manager, and it will tell you about everything else! So, that helps!

There are two ways to do this – run an add-on in your web browser and on your mobile devices which synchronises everything to the cloud for you, or run a separate app and synchronise those passwords yourself. Personally, as I’m a bit geeky, I’m happy doing the second, but most people reading this are probably going to want someone else to sort out the synchronising.

Second Factor: “Something you have”

What if you accidentally gave your password to someone? Or if you went to a website that wasn’t actually the right page and put your password in there by mistake? Falling prey to this when it’s done on purpose is known as social engineering or phishing, and means that someone else has your password to get into your account.

To reduce the impact of something like this, we can force someone logging in to use a “second factor” – something you have, rather than something you know, sometimes referred to as “Two Factor” or “2FA”. You might already use something like this at work – either a card with a chip on it (called a “Smartcard”), a device you plug into the USB port on your computer, or a keyring style device with numbers on. Or… you might have an app on your phone.

If you want to set this up on Facebook, you’ll need to enable it. Take a look at their help page about this!

(And if you want to know about securing your email account, check out the “Docs” column on this site for instructions about many email providers)

Podcast Summary – The Ubuntu Podcast, S10E26

In two weeks I have appeared in three podcasts, and this is the third!

I was asked to participate in The Ubuntu Podcast – S10E26 – Endurable Wiry Bird because of my organisational involvement in the most recent OggCamp. I also mention a VPN product I think is useful for protecting yourself on public WiFi, and I mention my struggles with “Bash on Ubuntu for Windows” (symlinks of directories and FUSE filesystems). My wonderful and constructive wife said that I wasn’t very good at being interviewed (I kept having to be dragged back to talking to “normal people” level), but that it sounded like a professional radio show.

I really enjoy being on all these podcasts… I just wish I was a better guest on them!

Weird technical note: I have recently taken to recording the feeds from two separate microphones and submitting them both to the podcast for mixing purposes. On this occasion that back-fired… The “better” microphone picked up the other people in the audio from the “more rubbish” communications headset I use at work, that we were using to have the conference call. Fortunately, I’d recorded the audio from that too, as that had removed (or, more likely, never picked up) the audio from the other parties on the call… So next time, I need to either use better in-ear headphones for that, it just stick with the comms headset, and hope for the best!