Sep 07, 2018

10 min read

Ansible security playbook for your VPS (part 2)

Written by

Vippy The VPS

In part 1 of our Ansible security playbook tutorial, we started building out an Ansible playbook with a focus on creating better security for your VPS.

We made it as far as hardening SSH with a few simple-but-logical edits to /etc/ssh/sshd_config, but there's still plenty more that we can do to improve the playbook's immediate functionality.

If you haven't seen the first part of this tutorial series, hop over there first to get a handle on how the playbook functions, and its basic structure: Ansible security playbook for your VPS.

We'll jump right back in where we left off-- using Ansible iptables and installing fail2ban with Ansible to prevent brute force attacks.


Step 6. Creating Ansible iptables/tasks/main.yml

With Ansible 2.2, there's a built-in iptables module that lets us create rules without having to rely on running plain bash commands.

It's really convenient, but not very well documented, sadly. But before we get to those rules, let's hit the ground running by installing the Ansible iptables module.

- name: Install the iptables package
    name: iptables
    state: latest

Using the package module is familiar territory by now—we're just double-checking that iptables is installed.

Next up, starting from a clean slate:

- name: Flush existing firewall rules
    flush: true

Our first example of using the iptables Ansible module, just to flush any existing rules that might exist.

And now, onto creating rules:

- name: Firewall rule - allow all loopback traffic
    action: append
    chain: INPUT
    in_interface: lo
    jump: ACCEPT

We first want to allow any loopback traffic that might exist between various applications and services that could be running on your VPS now or in the future. We can now see how we specify the chain, which can be set to any of the built-in chains that iptables offers: 'INPUT', 'FORWARD', 'OUTPUT', 'PREROUTING', 'POSTROUTING', 'SECMARK', 'CONNSECMARK'. The jump parameter is where we specify what we want to do with traffic that matches the chain and interface—we want to ACCEPT this traffic, but we could also REJECT or DROP it.

For convenience, we also want to allow established connections.

- name: Firewall rule - allow established connections
    chain: INPUT
    jump: ACCEPT

Here's our first (and only) taste of the ctstate parameter, which can be used to create some more complex rules.

Now, let's get to the juicy bits—allowing certain types of traffic, on certain ports, that are usually wanted on a VPS.

- name: Firewall rule - allow port ping traffic
    chain: INPUT
Continue reading this article
by subscribing to our newsletter.
Subscribe now

A note about tutorials: We encourage our users to try out tutorials, but they aren't fully supported by our team—we can't always provide support when things go wrong. Be sure to check which OS and version it was tested with before you proceed.

If you want a fully managed experience, with dedicated support for any application you might want to run, contact us for more information.