Le noyau Linux intègre le sous-système Netfilter, qui est utilisé pour manipuler ou décider ce qui arrivera lorsque du traffic réseau passe par votre serveur. Tous les pare-feu modernes pour Linux utilisent ce système pour le filtrage des paquets.
Le filtrage de paquets du noyau serait d'une utilité relative aux administrateurs sans une interface utilisateur pour le gérer. C'est le but d'iptables. Quand un paquet atteint votre serveur, Netfilter décidera si il sera accepté, manipulé, ou rejeté en suivant les règles fournies grâce à iptables. Iptables suffit donc à gérer votre firewall, mais de nombreuses interfaces existent pour vous simplifier la tâche.
The purpose of IP Masquerading is to allow machines with private, non-routable IP addresses on your network to access the Internet through the machine doing the masquerading. Traffic from your private network destined for the Internet must be manipulated for replies to be routable back to the machine that made the request. To do this, the kernel must modify the source IP address of each packet so that replies will be routed back to it, rather than to the private IP address that made the request, which is impossible over the Internet. Linux uses Connection Tracking (conntrack) to keep track of which connections belong to which machines and reroute each return packet accordingly. Traffic leaving your private network is thus "masqueraded" as having originated from your Ubuntu gateway machine. This process is referred to in Microsoft documentation as Internet Connection Sharing.
Cela peut être effectué à l'aide d'une simple règle iptables, qui pourra éventuellement changer suivant la configuration de votre réseau :
sudo iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o ppp0 -j MASQUERADE
La commande ci-dessus considère que votre adresse de réseau privé est 192.168.0.0/16 et que votre interface reliée à Internet est ppp0. La syntaxe est construite comme ceci :
-t nat -- la règle ira dans la table NAT
-A POSTROUTING -- la règle sera ajoutée (-A) à la chaîne POSTROUTING
-s 192.168.0.0/16 -- la règle s'applique au trafic provenant de plage d'adresse précisée
-o ppp0 -- la règle s'applique au trafic devant être routé à travers l'interface réseau précisée
-j MASQUERADE -- traffic matching this rule is to "jump" (-j) to the MASQUERADE target to be manipulated as described above
Each chain in the filter table (the default table, and where most or all packet filtering occurs) has a default policy of ACCEPT, but if you are creating a firewall in addition to a gateway device, you may have set the policies to DROP or REJECT, in which case your masqueraded traffic needs to be allowed through the FORWARD chain for the above rule to work:
sudo iptables -A FORWARD -s 192.168.0.0/16 -o ppp0 -j ACCEPT sudo iptables -A FORWARD -d 192.168.0.0/16 -m state --state ESTABLISHED,RELATED -i ppp0 -j ACCEPT
The above commands will allow all connections from your local network to the Internet and all traffic related to those connections to return to the machine that initiated them.
There are many tools available to help you construct a complete firewall without intimate knowledge of iptables. For the GUI-inclined, Firestarter is quite popular and easy to use, and fwbuilder is very powerful and will look familiar to an administrator who has used a commercial firewall utility such as Checkpoint FireWall-1. If you prefer a command-line tool with plain-text configuration files, Shorewall is a very powerful solution to help you configure an advanced firewall for any network. If your network is relatively simple, or if you don't have a network, ipkungfu should give you a working firewall "out of the box" with zero configuration, and will allow you to easily set up a more advanced firewall by editing simple, well-documented configuration files. Another interesting tool is fireflier, which is designed to be a desktop firewall application. It is made up of a server (fireflier-server) and your choice of GUI clients (GTK or QT), and behaves like many popular interactive firewall applications for Windows.
Firewall logs are essential for recognizing attacks, troubleshooting your firewall rules, and noticing unusual activity on your network. You must include logging rules in your firewall for them to be generated, though, and logging rules must come before any applicable terminating rule (a rule with a target that decides the fate of the packet, such as ACCEPT, DROP, or REJECT). For example:
sudo iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j LOG --log-prefix "NEW_HTTP_CONN: "
A request on port 80 from the local machine, then, would generate a log in dmesg that looks like this:
[4304885.870000] NEW_HTTP_CONN: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=58288 DF PROTO=TCP SPT=53981 DPT=80 WINDOW=32767 RES=0x00 SYN URGP=0
The above log will also appear in /var/log/messages
,
/var/log/syslog
, and /var/log/kern.log
.
This behavior can be modified by editing /etc/syslog.conf
appropriately or by installing and configuring ulogd
and using the ULOG target instead of LOG. The ulogd
daemon is a userspace server that listens for logging instructions from the kernel
specifically for firewalls, and can log to any file you like, or even to a
PostgreSQL or MySQL
database. Making sense of your firewall logs can be simplified by using a log
analyzing tool such as fwanalog,
fwlogwatch, or lire.