Configuration of a Gateway to the Internet

Our iptables.rules-Gateway.sh script sets up an iptables configuration with various services that can be enabled (e.g. for masquerading, IPTV, different kinds of servers) as an example that we hope is secure enough [1].

[1]	Please email us if you found otherwise! Refer to the top of this document for that.

This script expects a settings file to be available as /etc/iptables.settings-Gateway.sh (this file is meant to be sourced, not executed).

An example thereof:

# Local firewall settings.
#
# Meant to be sourced by the iptables.rules-Gateway.sh script.

# Where firewall-related outputs will be written:
log_file=/root/.last-gateway-firewall-activation

# Local (LAN) interface, the one we trust:
#lan_if=eth1
lan_if=enp2s0

# Internet (WAN) interface, the one we distrust:

# For PPP ADSL connections:
#net_if=ppp0

# For direct connection to a set-top (telecom) box from your provider:
#net_if=eth0
net_if=enp4s0

ban_file="/etc/ban-rules.iptables"

# As the IPs banned through the ban file above are quite minimal:
use_ban_rules="true"
#use_ban_rules="false"

# IP of a test client (to avoid too many logs, selecting only related events):
#test_client_ip="xxx"

# Enabled input TCP port range for traffic from LAN to gateway:
enable_unfiltered_tcp_range="true"

# TCP unfiltered window (e.g. for passive FTP and BEAM port ranges):
tcp_unfiltered_low_port=50000
tcp_unfiltered_high_port=55000

# Tells whether IPTV (TV on the Internet thanks to a box) should be allowed:
enable_iptv=false

# Tells whether a SMTP server can be used:
enable_smtp=false

# Typically a set-top box from one's ISP (defined as a possibly log match
# criteria):

# Classical example:
telecom_box="192.168.0.254"

# DHT subsection, for P2P exchanges:
# More infos: https://github.com/rakshasa/rtorrent/wiki/Using-DHT

dht_udp_port=7881

#use_dht="true"
use_dht="false"

# One may use a non-standard port:
#ssh_port=22
ssh_port=22320

smtp_port=25

# SMTPS is obsolete:
smtp_secure_port=465

# STARTTLS over SMTP is the proper way of securing SMTP:
msa_port=587

pop3_port=110

# POP3S:
pop3_secure_port=995

imap_port=143
imap_secure_port=993

A script to configure iptables is best integrated to systemd, see the iptables.rules-Gateway.service file for that (typically to be placed in /etc/systemd/system). Then one may test with:

$ systemctl start iptables.rules-Gateway.service

and enable it for good with:

$ systemctl enable iptables.rules-Gateway.service

Note that often these scripts are setup remotely, while being connected thanks to SSH from another host. Care must be taken in order not to lock oneself out of the target server, notably when updating rules (this happens quite easily). We advise to prefer the restart option of our iptables script in order to reduce the risk of "bricking" one's server.

Firewall-related Troubleshooting

Use iptables-inspect.sh to list the currently-used firewall rules for the chains of the main tables. Like iptables -nL --line-numbers [2], it displays the number of each rule of a given chain, which allows to add/remove rules more easily, like in:

# Deletes the first rule of the FORWARD chain (of the 'filter' table):
# (note that all the next rules will bear a decremented number afterwards!)
$ iptables -D FORWARD 1

[2]	Note that unfortunately this command does not display interface information, which can be quite misleading; the output of our script is more precise and thus should be preferred.

Setting environment variables (either through files such as /etc/iptables.settings-Gateway.sh or directly in the shell) is less error-prone; e.g.

[...]
$ lan_if=enp2s0
$ net_if=enp4s0
$ iptables -I FORWARD -i ${lan_if} -o ${net_if} -d ${telecom_box} -j LOG
$ journalctl -kf --grep="IN=.*OUT=.*" | grep -v "SRC=${telecom_box}"

To further match packets, one may specify log prefixes, like in:

$ iptables -A INPUT -i lan.foobar -j LOG --log-prefix "[VLAN INP FOO]"

Note that the LOG target does not intercept a packet, which thus continues to flow in the next rule(s). so log targets are better defined as first rules (and thus could be inserted lastly).

As a reminder, for a given table (filter by default), rules may be:

• appended at the end of the selected chain with -A (then of course any previous rule may eclipse it)
• inserted either at the beginning of the selected chain with -I, or at its position N with -I N

Therefore, just for the sake of testing a safe interface foo, to short-circuit all previous input rules for TCP, one may execute iptables -I INPUT -i foo -p tcp -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT to ensure that the host will accept from now on all (valid) incoming TCP packets; then use iptables -D INPUT 1 to remove that rule and/or, even better, run your stateless firewall initialisation script to ensure that the base configuration has been correctly restored.

Adding/removing rules "safely" from the command-line may be done more easily by rule specification rather than by rule position.

For example removing a given rule can be done:

• by first listing all rules thanks to iptables -S, to pick the one of interest
• by removing the prefix (typically -A) of the spec, and pasting the rest of that spec after iptables -D in order to remove the corresponding rule

Putting back this rule at the first position on its chain instead is just a matter of using iptables -I and the same shortened spec.

So, for example if wanting to silence an untrusted device (e.g. some "smart" box, a netcam of dubious origin), an approach is to:

• determine its MAC address and associate a static IP to it; for example, if using dnsmasq, in /etc/dnsmasq.conf one may define dhcp-host=30:ef:50:36:54:68,10.0.17.203, so that the IP 10.0.17.203 is always assigned to the device of MAC address 30:ef:50:36:54:68
• define a firewall rule so that one's gateway never forwards outgoing packets from that (local) IP, for example with: iptables -I FORWARD -s 10.0.17.203/32 -i my_lan_interface -j DROP

See also:

• our filtered_local_hosts section of iptables.rules-Gateway.sh, the hosts being filtered out based on the ones specified in the setting_file configuration file
• the iptables section in the Arch wiki.

Resolving Host/Domain Names

Apparently the current trend is to rely on openresolv, which is an implementation of resolvconf.

From /etc/resolvconf.conf, the actual /etc/resolv.conf is generated (run resolvconf -u to apply a new configuration).

Caching DNS Requests

To better cache DNS requests, we chose to have both servers and clients run their instance of dnsmasq, with an extended cache size.

dnsmasq will then play the role of a (at least) local DNS server (reading its entries from /etc/hosts), DHCP server if wanted, etc.

For that, ultimately in /etc/resolv.conf (whose regeneration can be triggered manually with resolvconf -u), there should be "nameserver 127.0.0.1" or, more precisely with our conventions:

# Generated by resolvconf
search .
nameserver ::1
nameserver 127.0.0.1
options trust-ad

The configuration of dnsmasq itself is defined in /etc/dnsmasq.conf.

Even if the procedures described below may introduce per-network DNS servers, we recommend defining statically from here alternate/fallback DNS servers with at least one server=XX.YY.ZZ.TT line.

For these external "reference" DNS servers, prefer, for privacy rather than for performance, relying not on the ones of your ISP, and try to use non-tracking ones.

Adapting to Various Networks

Many computers, especially laptops, have to adapt to various networks.

One way of doing so is to use netctl, and per-network configuration files like /etc/netctl/my-foobar-network (started with netctl start my-foobar-network). These files may include a directive like DNS=('192.168.0.22') to designate the (here local) DNS server that shall be used. Note that its address will not end up in /etc/resolv.conf, as dnsmasq will be the (only) one interacting with that DNS server - and only when needed (i.e. when a DNS name is not already in its cache).

For that we have to tell openresolv to write the current, network-specific DNS server in a file that dnsmasq will later read. This is of course to be specified in /etc/resolvconf.conf, typically with a dnsmasq_resolv=/etc/dnsmasq-resolv.conf setting.

In order to check that setting, executing resolvconf -u should result in a /etc/dnsmasq-resolv.conf file whose content is, in this example:

# Generated by resolvconf
nameserver 192.168.0.22

We just have to tell dnsmasq to read and apply it. This is of course to be done in /etc/dnsmasq.conf, with following lines:

resolv-file=/etc/dnsmasq-resolv.conf

# If ever settings were to be passed from openresolv:
conf-file=/etc/dnsmasq-conf.conf

Checking is then a matter of running:

• systemctl status dnsmasq.service: using nameserver 192.168.0.22#53 shall be listed there (together with any DNS server(s) statically listed in /etc/dnsmasq.conf)
• drill google.com: then SERVER: ::1 or SERVER: 127.0.0.1 should be returned, which indicates that a local resolution is taking place indeed

Wrapping Up

So /etc/resolvconf.conf could be:

resolv_conf=/etc/resolv.conf
name_servers="::1 127.0.0.1"
resolv_conf_options="trust-ad"
dnsmasq_conf=/etc/dnsmasq-conf.conf
dnsmasq_resolv=/etc/dnsmasq-resolv.conf
search_domains=.

which should result in a resolv.conf like:

# Generated by resolvconf
search .
nameserver ::1
nameserver 127.0.0.1
options trust-ad