Tools like ping, traceroute, drill, arp, etc. are invaluable.
For example:
- to get all/most DNS records of a given domain, knowing that any requests (e.g. dig +noall +answer +multiline TARGET_DOMAIN any) may be not honored by some servers, we recommend using our list-dns-records.sh script
- to perform a reverse DNS lookup (thus translating a given IP address into a domain name), one may use: drill -x TARGET_IP.
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.
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 .
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.
Use iptables-inspect.sh to list the currently-used firewall rules for the chains of the main tables. Like iptables -nL --line-numbers, 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
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
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:
A few pieces of advice/information:
- be familiar with ip link, ip addr and ip route (generally used in that order), and tcpdump for the worst cases
- to review host-local open ports and sockets, use:
- ss (for socket statistics, replacement of netstat), e.g. to determine which program is running at TCP port #8080: ss --inet --listening -np | grep :8080
- netstat could be for example netstat -ltnp | grep :8080
- lsof -i :8080
- fuser 8080/tcp, before looking up the returned PID
- for remote testing of open ports and sockets, use nmap
- nowadays, many devices change their MAC address regularly, like smartphones do
- one may rely on netctl, and create as many profiles as found useful
- regularly inspect network-related messages (e.g. with journalctl -kf) to detect anomalies such as IPv4: martian source 192.168.0.49
- interfaces may be associated to any number of IP addresses, this may create surprises
- when a network does not work properly, always consider that this device may be faulty, that cables may malfunction, and that power supplies may be culprits
- having smart switches may help a lot, to better control one's network (e.g. disabling ports, checking statuses, isolating sections, etc.)
- beware to DHCP server(s) being left unnoticed; various devices may use them to get a random address and become difficult to spot
- netmasks shall not be neglected, for example in routes:
$ 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.
- go for VLAN only when having reached a first level of correct operation; note that some devices (e.g. non-manageable switches) are not able to handle VLAN-tagged packets and may reject or overwrite this information
- in some cases, hard reboots / returns to factory settings will fix inexplicable situations; updating to latest firmware may help too (network appliances do have bugs as well!)
- secure spare parts (if possible all cables, fibers, devices, power supply, etc. shall exist at least in two copies, tested just after purchased): when the one in operation will fail, the outage will be quickly solved by switching element; the troubleshooting will be easier as well: replace the whole set of equipment, check that everything works again, and try to progress by dichotomy (change half of the elements, and check whether everything remains functional)
- purchase only equipment of quality, and treat it gently (e.g. use an Uninterruptible Power Supply providing good-quality current)
- take notes about the operations that are performed, the detected issues and the current configuration, and put the whole in VCS
- check temperature, ventilation and prevent dust accumulation
- consider monitoring temperatures, fans, availability, performances