Secure Jumpbox to Access your Network Infrastructure from Remote Locations

This tutorial is originally posted by the author on another website. This version has been edited for clarity and may appear different from the original post.

Introduction

A jump server or jump host or jumpbox is a (special-purpose) computer on a network typically used to access devices in a separate security zone. The most common example is managing a host in a DMZ from trusted networks or computers. This could be accessing your home network from remote location. Access internet from your mobile device in public locations via VPN and so on.

In this article, I will demonstrate some devops mashup — how to combine four ansible roles to build such jump box based on Ubuntu box.

What we want to achieve

Let's briefly state our goal:

• Perform base box securing (i.e. firewall, key only login, ban failed ssh attempts, preparation for further provisioning)
• Optional install of the PPTP VPN service
• Optional install of the OpenVPN VPN service
• Optional install of the SoftEther VPN as an alternative to OpenVPN VPN service.
• If you want to be even more secure, you can add an additional level of security via port knocking. This will make it harder for portscanners to detect services on your box, although it would be more tricky to get in.

Base box securing

Nowadays, deployments moved from bare-metal servers to a quickly started virtual machines, like the ones provided by Amazon, Digital Ocean, OpenStack, or other cloud-based providers. Thus, configuring the box no longer requires manual administration steps.

One of the options is ready to use pre-configured box images. Another approach is to start from the initial system restart and provision it according to the project needs with some provisioner like
Ansible or Chef.

The first step to proceed with custom provisioning is to perform basic box securing. And in some cases, you are given with freshly installed box with the root password.

Let me share some quick tips on initial box securing, which should be good for most web deployments.

What I usually do is I strictly prohibit SSH log in using password, as well as making sure than only strong keys are used. If I expose the SSH port to public, I would recommend installing tools like file2ban — a daemon to ban hosts that cause multiple authentication errors. On my home jump box, the ban list is longer than 100k hosts for a few years, thus, I even had to compress the list by banning larger networks to shorten it.

As for the jump box, it is important to have services up. I also recommend installing a monit tool for lightweight, proactive monitoring of Unix systems, network, and cloud services.

Thus, the first component in our mashup is an sa-box-bootstrap role, which can be found at https://galaxy.ansible.com/softasap/sa-box-bootstrap/

You would need to amend the following parameters:

• deploy_user (the user named different from root, that will be used for box accessing/provisioning). Hardly guessed user improves the strength of your box.
• Depending on services you plan to run on your jump box, you can also pre-configure a few firewall rules. For example, we will use 22 SSH ; 500/4500 - Softether with IPSec ; 1194 - OpenVPN; 1723 - PPTP;

More configuration options are available in role itself, but are out of scope for current the example.

my_deploy_user: slavko
my_deploy_authorized_keys:
  - "~/.ssh/id_rsa.pub"

  # revise port list for your use , consider securing by  custom_ufw_rules_allow_from_hosts
   custom_ports_allow:
      - {
          port: 22,
          proto: tcp
        }
      - {
          port: 500,
          proto: udp
        }
      - {
          port: 4500,
          proto: udp
        }
      - {
          port: 1194,
          proto: tcp
        }
      - {
          port: 1723,
          proto: tcp
        }

Thus, our bootstrapping part will be:

roles:
   - {
       role: "sa-box-bootstrap",
       deploy_user: "{{my_deploy_user}}",
       deploy_user_authorized_keys: "{{my_deploy_authorized_keys}}",
       ufw_rules_allow: "{{custom_ports_allow}}"
     }

Once this play is executed, we would have a UFW up, file2ban ready to guard, and a monit ready to monitor. And your deploy user is configured for further provisioning with ansible.

Optional PPTP VPN

Even if PPTP is considered a weak VPN protocol, it is easiest to configure by unexperienced users. Thus, I usually enable it for my clients, but enforce stricter policies for regular passwords rotation + password strength itself. For home use, I just set long enough random password + additionally protect with port knocking.

For PPTP, we would use in our mashup a sa-vpn-pptp role, which could be found at https://galaxy.ansible.com/softasap/sa-vpn-pptp/

To configure the role, we only need to pass a list of the users to create and know the type of firewall used. (IPTables or UFW are supported at a moment)

custom_pptp_vpn_users:
 - {
     name: "my_user",
     password: "my_password"
   }

Our PPTP VPN setup part would be:

roles:
   - {
      role: "sa-vpn-pptp",
      pptp_vpn_users: "{{custom_pptp_vpn_users}}",
      firewall_used: "ufw",
      when: option_jumpbox_pptp
     }

At the end of the role play, we would have our PPTP server up.

Optional OpenVPN VPN

OpenVPN is considered a way stronger than PPTP, and considered to be secure for enterprise deployments. For OpenVPN we would use in our mashup an sa-vpn-openvpn role, which can be found at https://galaxy.ansible.com/softasap/sa-vpn-openvpn/

To configure the role, we only need to pass a list of the users to create and know the type of firewall used. (IPTables or UFW are supported at a moment).

custom_openvpn_vpn_users:
 - {
     name: "my_user"
   }

If you specify a password in the configuration above, it will be set for the key and asked each time when accessed.

Our OpenVPN setup part would be:

roles:
  - {
     role: "sa-vpn-openvpn",
     openvpn_vpn_users: "{{custom_openvpn_vpn_users}}",
     firewall_used: "ufw",
     when: option_jumpbox_openvpn
    }

At the end of the play, playbook will download the OpenVPN configuration files for each user you request. Now it is your responsibility to distribute your keys. If you create a jump box for personal use, most likely, you will only need one key.

More specifics about using OpenVPN might be found at the role Github repository.

Optional SoftEther VPN

SoftEther VPN ("SoftEther" means "Software Ethernet") is one of the world's most powerful and easy-to-use multi-protocol VPN software. It runs on Windows, Linux, Mac. SoftEther VPN is open source. You can use SoftEther for any personal or commercial use for free.

It is believed to be able to work behind NAT by using project infrastructure, and it can sometimes be easier to connect to it from Windows boxes.

The number of supported VPN protocols is higher:

• SoftEther VPN Protocol (Ethernet over HTTPS)
• OpenVPN (L3-mode and L2-mode)
• L2TP/IPsec
• MS-SSTP (Microsoft Secure Socket Tunneling Protocol)
• L2TPv3/IPsec
• EtherIP/IPsec.

Note, that if you have your Windows computer behind NAT, you will need additional registry tuning to get the ability to connect to IPSec VPN (I.e. if you go with SoftEther, you can connect your jump box into higher number of ways. Also, if you select SoftEther, you should not use a sa-vpn-openvpn play).

For SoftEther, we would use in our mashup a sa-vpn-softether role, which could be found at https://galaxy.ansible.com/softasap/sa-vpn-softether/

Role is configurable by your own SoftEther setup script, but by default it configures OpenVPN and IPSec parts.

custom_softether_vpn_users:
  - {
      name: "my_user",
      password: "my_password"
    }

custom_softether_ipsec_presharedkey: "[1KH;+r-X#cvhpv7Y6=#;[{u"

Our SoftEther setup part would be:

roles:
  - {
      role: "sa-vpn-softether",
      softether_vpn_users: "{{custom_softether_vpn_users}}",
      softether_ipsec_presharedkey: "{{custom_softether_ipsec_presharedkey}}",
      firewall_used: "ufw",         
      when: option_jumpbox_softether
    }

More specifics about using SoftEther might be found at role Github repository and even more on its project documentation.

Similar to OpenVPN role, you will find the connection details downloaded to your local computer for further distribution.

Optional port knocking

Servers, by definition, are implemented as a means of providing services and making applications and resources accessible to users. However, any computer connected to the internet is inevitably targeted by malicious users and scripts hoping to take advantage of security vulnerabilities.

Firewalls exist and should be used to block access to ports not being utilized by a service, but there is still the question of what to do about services that you want access to, but do not want to expose to everybody. You want access when you need it, but want it blocked off otherwise.

Port knocking is a stealth method to externally open ports that, by default, the firewall keeps closed. It works by requiring connection attempts to a series of predefined closed port. From the point of view of port scanning, you can make your host be completely silent.

There are few utilities for port knocking. I find a utility named knockd to be robust.

Thus, for port knock securing, we will use in our mashup a sa-port-knock role, which could be found at https://galaxy.ansible.com/softasap/sa-port-knock/

To configure port rules, we will need configuration like: "knock sequentially ports 16000, 15000, 17000 in 5 seconds to open ssh port for your address for 10 seconds."

You might use more sophisticated rules, like turning off by knock password, etc. Just follow the knockd documentation. Your pull request to role are highly appreciated.

custom_knock_ports:
  - {
      "name": "ssh",
      "sequence": "16000, 15000, 17000",
      "seq_timeout": 5,
      "port": 22,
      "protocol": "tcp",
      "tcpflags": "syn",
      "cmd_timeout": 10
    }

Our port knock daemon setup part would be:

roles:
  - {
      role: "sa-port-knock",
      knock_ports: "{{custom_knock_ports}}",
      when: option_jumpbox_port_knock
    }

The full code in action

The full code in action can be found on Github. It configures the jump box with PPTP / OpenVPN / SSH via keys by default, but can be adjusted using option switches, to deploy a set of described above combinations.

option_jumpbox_pptp: true     # install classic PPTP server

option_jumpbox_openvpn: true  # install OpenVPN server

option_jumpbox_softether: false # install openvpn SoftEther server (+ few more targeting windows)

option_jumpbox_port_knock: false # configure portknocking

Wrapping up

You can reuse this playbook to create your own jump box for bootstaping projects, and reuse the role to configure your environments quicker in a secure way with Ansible.

This is acceptable for home or small team use. For enterprise use, make sure you understand what you do. And as for your company, you might need to follow different procedures.