Ceci dit, si tu ne comptes pas faire de NAT, tu n’as pas besoin de la table nat, et donc de commandes qui y font appel.
C’est vrai que je peux me limiter aux commandes filter ^^ …
Que pensez vous de ce script :
(J’ai volontairement modifié les ports 42 pour ssh et 20-41 pour ftp)
EDIT: je viens de le lancer sur mon serveur … ca me coupe tout(ssh et http mort) alors que sur mon serveur de test tout passe … je ne comprend pas vraiment là
[code]#!/bin/sh
BEGIN INIT INFO
Provides: Firewall
Required-Start: $local_fs $remote_fs $syslog $network
Required-Stop: $local_fs $remote_fs $syslog $network
Default-Start: 2 3 4 5
Default-Stop: 0 1 6
Short-Description: Initialisation du Firewall
Description: Lance l intitialisation du Firewall
END INIT INFO
portsentry -audp
portsentry -atcp
On vide toutes les r.gles avant d’appliquer les nouvelles.
iptables -F
iptables -X
iptables -Z
On r.initialise les tables.
iptables -t filter -P OUTPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT
iptables -t filter -P INPUT ACCEPT
Bloque tout le trafic
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
on se prot.ge des scan de port
iptables -t filter -A INPUT -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
Protection SYN flood
iptables -t filter -A INPUT -p tcp --syn -m limit --limit 5/s -j ACCEPT
iptables -t filter -A INPUT -p udp -m limit --limit 10/s -j ACCEPT
Protection ping flood
iptables -t filter -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
iptables -t filter -A INPUT -p icmp --icmp-type echo-reply -m limit --limit 1/s -j ACCEPT
Protection ping flood
iptables -t filter -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
iptables -t filter -A INPUT -p icmp --icmp-type echo-reply -m limit --limit 1/s -j ACCEPT
Ping
iptables -t filter -A OUTPUT -p ICMP -j ACCEPT
iptables -t filter -A INPUT -p ICMP -j ACCEPT
Autorise les connexions d.j. .tablies et localhost
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
SSH
iptables -t filter -A INPUT -p tcp --dport 42 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 42 -j ACCEPT
DNS
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
#FTP
iptables -t filter -A OUTPUT -p tcp --dport 41 -j ACCEPT
Serveur Web
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
whois
iptables -t filter -A OUTPUT -p udp --dport 43 -j ACCEPT
NTP (horloge du serveur)
iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT
[/code]
J’ai pas tout regardé en détail mais à première vue il y a des choses qui ne me plaisent pas. Commentaire détaillé à venir.
Ce script a un en-tête LSB de script d’init mais n’en a pas la structure (cf. /etc/init.d/skeleton) : il ne tient pas compte de l’action start|stop|reload… passée en paramètre et effectue les même actions dans tous les cas.
Inutile de régler les politiques par défaut à ACCEPT pour les régler à DROP immédiatement après.
Les diverses règles de “protection” sont mal placées ou mal écrites : elles acceptent des paquets entrants sans autre considération de protocole, port… court-circuitant les règles ultérieures autorisant seulement certains protocoles et ports. Il faut soit bloquer les paquets au-delà de la limite, soit appliquer les règles de ports etc. au trafic en-deça de la limite, ce qui revient au même.
Les règles de suivi de connexion (ESTABLISHED,RELATED) devraient se trouver en début de chaîne. Celles relatives à l’interface de loopback aussi, à moins qu’on veuille filtrer le trafic entre processus locaux.
Il y a un doublon des règles de “protection ping flood”. D’autre part la règle limitant les ICMP echo-reply n’a pas grand intérêt. Les réponses au ping unicast sont dans l’état ESTABLISHED. Donc cette règle ne sert que pour les réponses au ping broadcast (qui ne devraient pas être nombreuses puisque désactivées par défaut sur les OS récents y compris Linux).
La paire de règles sous le commentaire “Ping” porte bien mal son nom : elle autorise sans limite les paquets ICMP de n’importe quel type et pas seulement le ping (types echo-request et echo-reply), et rend totalement inutiles les limitations des règles précédentes.
Le protocole DNS peut utiliser le port 53 en TCP aussi et pas seulement en UDP.
Le protocole FTP n’utilise pas que le port de commande (21 par défaut, ici 41). Le module de suivi de connexion FTP nf_conntrack_ftp permet de reconnaître les connexions de données à la volée. Mais si on utilise un port non standard pour la connexion de commande, alors il faut spécifier ce port au module lors de son chargement, car par défaut il ne surveille que le port 21.
Les règles sous le commentaire “Serveur web” sont en sortie, donc autorisent les connexions sortantes. Pour un serveur il faudrait plutôt autoriser les connexions entrantes.