How to make a Linux systemd service wait for a VPN interface before starting

Like me, you may have a requirement for a service to start only once a VPN interface is established.

This is quite easy to achieve by extending the systemd unit file for the service in question. In this example, based upon Ubunutu 16.04 but portable to other systemd-based distros, I will focus on docker.service, but the configuration is applicable to any service – provided you change the relevant folder/ filenames, in bold, appropriately.

For a service other than docker.service, find and replace “docker.service” with the relevant service name you want to wait for VPN connectivity.

You also need to identify the systemctl device id for you VPN connection.

# Identify the VPN interface name - commonly "tun0"

# Find the systemctl interface name based upon output from command above. In my case this output "sys-devices-virtual-net-tun0.device"
systemctl | grep tun0

With the systemctl device name, and having replaced docker.service if required proceed.

sudo mkdir /etc/systemd/system/docker.service.d/
sudo touch /etc/systemd/system/docker.service.d/depend.conf
sudo vi /etc/systemd/system/docker.service.d/depend.conf

# New conf file should only contain lines below

# Now save the file and exit vim

# Reload systemd daemons
sudo systemctl daemon-reload

# Test container connectivity following a reboot

Vulnerability scanning for MS17-010 / 4013389 / WannaCry using OpenVAS in a Docker Container

For instructions on how to install Docker on Ubuntu see my post here:

Updated 31/05/17 to include Ping Host and NMAP (NASL wrapper) tests due to feedback around reliability of results without these tests enabled.

Following on from my previous post around MS17-010 / 4013389 vulnerability patching assurance I thought I’d share a more robust scanning and reporting tool that is simple to deploy and use, OpenVAS. The deployment/ configuration of which is made even simpler through the availability of a Docker Image.

Assuming you have an Ubuntu 16.04 server/ client with the docker engine installed, use the following commands to get OpenVas up and running:

docker pull mikesplain/openvas:9

docker run -d -p 443:443 --name openvas mikesplain/openvas:9

# *** Alternatively *** use the host machines IP address rather than the docker0 interface/ a NAT'd address as above.

docker run -d --net host -p 443:443 --name openvas mikesplain/openvas:9
Next, browse to https://<machine IP> and login, using default credentials of admin / admin :

Now, from the top menu, browse to Configuration > Scan Configs

Click the “sheep” (clone) button next to empty

Hit the spanner icon at the top of the window:

Name the Scan Config “MS17-010 Vulnerability Check” or something else meaningful:

Scroll down to “Windows : Microsoft Bulletins” and hit the spanner icon next to this:

Search for 4013389 (the relevant MS ID), enable all instances for the scan and click save:

As per comments via this post, also enable the Port Scanners | Ping Host and NMAP (NASL wrapper) tests.

Click Save, then click save again.

Now browse to: Scans > Tasks

Click the “Pink Wand” icon: New > Advanced Task Wizard

Name the task and select the new scan config you just created. Specify IP, subnet etc you want to scan. Hit “Create” to start the scan for this specific vulnerability.

Check the reports as the scan progresses, anything identified needs to be patched, or hardened/ isolated if it is older than those O/S editions that this patch was released for.

Happy hunting…

MS17-010 Vulnerability Checking with PowerShell and Nmap

There have been several MS17-010 PowerShell scripts that have emerged over the last week or so, I wanted to call out a couple in particular, aimed at assurance/ understanding vulnerability within a network rather than the remediation/ clean-up.

The first uses Nmap to identify individual IPs/ hostnames that are vulnerable to MS17-010 exploit:

Using Nmap is important as simply installing the patch itself without a reboot is not enough to protect against this vulnerability. This script uses Nmap to confirm that this exploit is no longer available on a per-target basis, rather than simply looking for an installed hotfix.

The second script is good for checking that machines have the patch itself installed:

No doubt you’ll come across scripts that help you deploy the patch and even decrypt/ clean-up WannaCry itself – certainly lots of interesting reads in recent days.