Organisation: | Copyright (C) 2021-2025 Olivier Boudeville |
---|---|
Contact: | about (dash) howtos (at) esperide (dot) com |
Creation date: | Saturday, November 20, 2021 |
Lastly updated: | Friday, May 16, 2025 |
Tools like ping, traceroute, drill, arp, etc. are invaluable.
Use ip-scan.sh to scans all IPs with any specified prefix, and ip-examine.sh to collect information about a given IP.
Use monitor-network.sh to investigate unstable connections.
On GNU/Linux, some level of knowledge about iptables is useful, notably if exposing a computer to the Internet; note though that it is to be superseded by nftables.
One should read first the very clear Arch wiki section about iptables basic concepts. See also man iptables-extensions to understand the extended packet matching modules (triggered with the -m / --match options).
A general rule that we retain, especially for an Internet gateway, is to drop all packets by default, and then only to accept the expected ones explicitly and carefully.
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.
A few pieces of advice/information:
$ ip route add 192.168.0.0/16 dev enp4s0 scope link $ ip route default via 192.168.0.254 dev enp4s0 proto dhcp src 192.168.0.1 metric 1002 10.0.0.0/8 dev enp2s0 proto kernel scope link src 10.0.0.1 192.168.0.0/16 dev enp4s0 scope link
Here for example, in 192.168.0.0/16, 16 corresponds to the length of the network prefix; the next 16 bits are left to designate hosts, whose addresses therefore range in 192.168.[0..254].[1..254]. So 192.168.0.0/16 includes the 192.168.27.0/24 network - whereas 192.168.0.0/24 would not.
The current configuration of resolution can be tested just by using ping, yet tools lie drill (otherwise dig) are of help.
For example to:
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).
If having defined a wildcard DNS (e.g. *.foobar.org), by default the foobar.org server (possibly itself a DNS server for LAN clients) may resolve non-existing hosts into its own address (which may be the cause of many surprises), instead of returning the expected Name or service not known error.
To avoid that, ultimately in /etc/resolv.conf there should be "search ." (not having "search foobar.org" will not suffice). This is true for all resolution levels, i.e. for servers and clients alike.
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.
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:
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