Databases, Systems & Networks

Introduction

UFW, or Uncomplicated Firewall, is an interface to iptables that is geared towards simplifying the process of configuring a firewall. While iptables is a solid and flexible tool, it can be difficult for beginners to learn how to use it to properly configure a firewall. If you’re looking to get started securing your network, and you’re not sure which tool to use, UFW may be the right choice for you.

This tutorial will show you how to set up a firewall with UFW on Ubuntu 14.04.

Prerequisites

Before you start using this tutorial, you should have a separate, non-root superuser account—a user with sudo privileges—set up on your Ubuntu server. You can learn how to do this by completing at least steps 1-3 in the Initial Server Setup with Ubuntu 14.04 tutorial.

UFW is installed by default on Ubuntu. If it has been uninstalled for some reason, you can install it with apt-get:

sudo apt-get install ufw

Using IPv6 with UFW

If your Ubuntu server has IPv6 enabled, ensure that UFW is configured to support IPv6 so that it will manage firewall rules for IPv6 in addition to IPv4. To do this, open the UFW configuration with your favorite editor. We’ll use nano:

sudo nano /etc/default/ufw

Then make sure the value of « IPV6 » is to equal « yes ». It should look like this:

/etc/default/ufw excerpt
...
IPV6=yes
...

Save and quit. Hit Ctrl-X to exit the file, then Y to save the changes that you made, then ENTER to confirm the file name.

When UFW is enabled, it will be configured to write both IPv4 and IPv6 firewall rules.

This tutorial is written with IPv4 in mind, but will work fine for IPv6 as long as you enable it.

Check UFW Status and Rules

At any time, you can check the status of UFW with this command:

sudo ufw status verbose

By default, UFW is disabled so you should see something like this:

Status: inactive

If UFW is active, the output will say that it’s active, and it will list any rules that are set. For example, if the firewall is set to allow SSH (port 22) connections from anywhere, the output might look something like this:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere

As such, use the status command if you ever need to check how UFW has configured the firewall.

Before enabling UFW, we will want to ensure that your firewall is configured to allow you to connect via SSH. Let’s start with setting the default policies.

Lire la suite…

Introduction

Iptables is the software firewall that is included with most Linux distributions by default. This cheat sheet-style guide provides a quick reference to iptables commands that will create firewall rules are useful in common, everyday scenarios. This includes iptables examples of allowing and blocking various services by port, network interface, and source IP address.

How To Use This Guide

• If you are just getting started with configuring your iptables firewall, check out our introduction to iptables
• Most of the rules that are described here assume that your iptables is set to DROP incoming traffic, through the default input policy, and you want to selectively allow traffic in
• Use whichever subsequent sections are applicable to what you are trying to achieve. Most sections are not predicated on any other, so you can use the examples below independently
• Use the Contents menu on the right side of this page (at wide page widths) or your browser’s find function to locate the sections you need
• Copy and paste the command-line examples given, substituting the values in red with your own values

Keep in mind that the order of your rules matter. All of these iptables commands use the -A option to append the new rule to the end of a chain. If you want to put it somewhere else in the chain, you can use the -I option which allows you to specify the position of the new rule (or simply place it at the beginning of the chain by not specifying a rule number).

Note: When working with firewalls, take care not to lock yourself out of your own server by blocking SSH traffic (port 22, by default). If you lose access due to your firewall settings, you may need to connect to it via the console to fix your access. Once you are connected via the console, you can change your firewall rules to allow SSH access (or allow all traffic). If your saved firewall rules allow SSH access, another method is to reboot your server.

Remember that you can check your current iptables ruleset with sudo iptables -S and sudo iptables -L.

Let’s take a look at the iptables commands!

Lire la suite…

Implementing a firewall is an important step in securing your server. A large part of that is deciding on the individual rules and policies that will enforce traffic restrictions to your network. Firewalls like iptables also allow you to have a say about the structural framework in which your rules are applied.

In this guide, we will construct a firewall that can be the basis for more complex rule sets. This firewall will focus primarily on providing reasonable defaults and establishing a framework that encourages easy extensibility. We will be demonstrating this on an Ubuntu 14.04 server.

Prerequisites

Before you begin, you should have a basic idea of the firewall policies you wish to implement. You can follow this guide to get a better idea of some of the things you should be thinking about.

In order to follow along, you will need to have access to an Ubuntu 14.04 server. We will be using a non-root user configured with sudo privileges throughout this guide. You can learn how to configure this type of user in our Ubuntu 14.04 initial server setup guide.

When you are finished, continue below.

Installing the Persistent Firewall Service

To get started, you will need to install the iptables-persistent package if you have not done so already. This will allow us to save our rule sets and have them automatically applied at boot:

sudo apt-get update
sudo apt-get install iptables-persistent

During the installation, you’ll be asked whether you want to save your current rules. Say « yes » here. We will be editing the generated rules files momentarily.

A Note About IPv6 in this Guide

Before we get started, we should talk briefly about IPv4 vs IPv6. The iptables command only handles IPv4 traffic. For IPv6 traffic, a separate companion tool called ip6tables is used. The rules are stored in separate tables and chains. For iptables-persistent, the IPv4 rules are written to and read from /etc/iptables/rules.v4 and the IPv6 rules are kept in /etc/iptables/rules.v6.

This guide assumes that you are not actively using IPv6 on your server. If your services do not leverage IPv6, it is safer to block access entirely, as we will be doing in this article.

Implementing the Basic Firewall Policy (The Quick Way)

For the sake of getting up and running as quickly as possible, we’ll show you how to edit the rules file directly to copy and paste the finished firewall policy. Afterwards, we will explain the general strategy and show you how these rules could be implemented using the iptables command instead of modifying the file.

Lire la suite…

Introduction

Using a firewall is as much about making intelligent policy decisions as it is about learning the syntax. Firewalls like iptables are capable of enforcing policies by interpreting rules set by the administrator. However, as an administrator, you need to know what types of rules make sense for your infrastructure.

While other guides focus on the commands needed to get up and running, in this guide, we will discuss some of the decisions you will have to make when implementing a firewall. These choices will affect how your firewall behaves, how locked down your server is, and how it will respond to various conditions that are likely to occur from time to time. We will be using iptables as an example to discuss specifics, but most of the actual decisions will be relevant regardless of the tools used.

Deciding on a Default Policy

When constructing a firewall, one of the fundamental decisions that you must make is the default policy. This determines what happens when traffic is not matched by any other rules. By default, a firewall can either accept any traffic unmatched by previous rules, or deny that traffic.

Default Drop vs Default Accept

A default policy of « accept » means that any unmatched traffic is allowed to enter the server. This is generally not advised because it means that, effectively, you will be maintaining a black list. Black lists are difficult to manage because you must anticipate and block every type of unwanted traffic explicitly. This can lead to maintenance headaches and is generally prone to mistakes, mis-configurations, and unanticipated holes in the established policy.

The alternative is a default policy of « drop ». This means that any traffic not matched by an explicit rule will not be allowed. This is akin to a white list ACL. Each and every service must be explicitly allowed, which might seem like a significant amount of research and work at first. However, this means that your policy tends towards security and that you know exactly what is permitted to receive traffic on your server.

Basically the choice comes down to a tendency towards security by default or reachable services out-of-the-box. While it may be tempting to implement a firewall that leans towards service availability, it is almost always a better idea to block traffic unless explicitly allowed.

Default Drop Policy vs Final Drop Rule

The above choice of a default drop policy leads to another subtle decision. With iptables and other similar firewalls, the default policy can be set using the built-in policy functionality of the firewall, or implemented by adding a catch-all drop rule at the end of the list of rules.

The distinction between these two methods lies in what happens if the firewall rules are flushed.

If your firewall’s built-in policy function is set to « drop » and your firewall rules are ever flushed (reset), or if certain matching rules are removed, your services will instantly become inaccessible remotely. This is often a good idea when setting policy for non-critical services so that your server is not exposed to malicious traffic if the rules are removed.

The downside to this approach is that your services will be completely unavailable to your clients until you re-establish permissive rules. You could even potentially lock yourself out of the server if you do not have local or out-of-band access to skirt the issue (DigitalOcean servers are accessible regardless of network settings by using the « Console Access » button located in the « Access » portion of your Droplet’s page in the control panel). If your firewall flush is intentional, this can be avoided by simply switching the default policy to « accept » just prior to resetting the rules.

The alternative to setting a drop policy using the built-in policy functionality is to set your firewall’s default policy to « accept » and then implement a « drop » policy with regular rules. You can add a normal firewall rule at the end of your chain that matches and denies all remaining unmatched traffic.

In this case, if your firewall rules are flushed, your services will be accessible but unprotected. Depending on your options for local or alternative access, this might be a necessary evil in order to ensure that you can re-enter your server if the rules are flushed. If you decide to use this option, you must ensure that the catch-all rule always remains the last rule in your rule set.

Lire la suite…

Introduction

Deploying discrete components in your application setup onto different nodes is a common way to decrease load and begin scaling horizontally. A typical example is configuring a database on a separate server from your application. While there are a great number of advantages with this setup, connecting over a network involves a new set of security concerns.

In this guide, we’ll demonstrate how to set up a simple firewall on each of your servers in a distributed setup. We will configure our policy to allow legitimate traffic between our components while denying other traffic.

For the demonstration in this guide, we’ll be using two Ubuntu 14.04 servers. One will have a WordPress instance served with Nginx and the other will host the MySQL database for the application. Although we will be using this setup as an example, you should be able to extrapolate the techniques involved to fit your own server requirements.

Prerequisites

To get started, you will have to have two fresh Ubuntu 14.04 servers. Add a regular user account with sudo privileges on each. To learn how to do this correctly, follow our Ubuntu 14.04 initial server setup guide.

The application setup we will be securing is based on this guide. If you’d like to follow along, set up your application and database servers as indicated by that tutorial.

Setting Up a Basic Firewall

We will begin by implementing a baseline firewall configuration for each of our servers. The policy that we will be implementing takes a security-first approach. We will be locking down almost everything other than SSH traffic and then poking holes in the firewall for our specific application.

The firewall in this guide provides the basic setup that we need. Install the iptables-persistent package and paste the basic rules into the /etc/iptables/rules.v4 file:

sudo apt-get update
sudo apt-get install iptables-persistent
sudo nano /etc/iptables/rules.v4

/etc/iptables/rules.v4

*filter
# Allow all outgoing, but drop incoming and forwarding packets by default
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Custom per-protocol chains
:UDP - [0:0]
:TCP - [0:0]
:ICMP - [0:0]

# Acceptable UDP traffic

# Acceptable TCP traffic
-A TCP -p tcp --dport 22 -j ACCEPT

# Acceptable ICMP traffic

# Boilerplate acceptance policy
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i lo -j ACCEPT

# Drop invalid packets
-A INPUT -m conntrack --ctstate INVALID -j DROP

# Pass traffic to protocol-specific chains
## Only allow new connections (established and related should already be handled)
## For TCP, additionally only allow new SYN packets since that is the only valid
## method for establishing a new TCP connection
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP
-A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP

# Reject anything that's fallen through to this point
## Try to be protocol-specific w/ rejection message
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable

# Commit the changes
COMMIT

*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

*security
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

If you are implementing this in a live environment do not reload your firewall rules yet. Loading the basic rule set outlined here will immediately drop the connection between your application and database server. We will need to adjust the rules to reflect our operational needs before reloading.

Lire la suite…