Ce que vous pensez de mes règles iptables

**HNT** · 20/08/2006, 16h42

Bonjour,

Pour l'instant, j'utilise surtout Linux (Debian) sur mon poste de travail et j'ai crée mes règles iptables que j'applique au boot au passage en rc2 via un script, je voudrais savoir ce que vous pensez de ce script (améliorations ...)

#!/bin/bash
echo "Setting up iptables rules ..."
# Supprime tout les filtres actifs
iptables --flush
# Rejette tous les types de trafic
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
# Autorise tous les trafics sur lo
iptables -A INPUT -i lo --source 127.0.0.1 --destination 127.0.0.1 -j ACCEPT
# Autorise l'ouverture de connexion vers l'extérieur
iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
# Autorise la réception de connection initiée locallement
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Rejette les demandes de connexions provenant de l'éxtérieur
iptables -A INPUT -m state --state NEW -j REJECT
# Autorise les demandes de connexions sur les ports 4662 et 4672 pour amule
iptables -A INPUT -m state --state NEW -p TCP --dport 4662 -j ACCEPT
iptables -A INPUT -m state --state NEW -p UDP --dport 4672 -j ACCEPT

Vous pouvez constater que c'est la politique du tout fermer sauf ...
Ben voila, vos avis sont les bienvenus.
Merci d'avance,

**gorgonite** · 20/08/2006, 17h34

pas mal...
perso, je préfère fermer les ports inutiles, puis interdire le ping depuis l'extérieur.

et seulement ensuite, "blinder" iptables

**HNT** · 20/08/2006, 17h40

J'interdis aussi le ping depuis l'extérieur via /etc/sysctl.conf dans lequel j'ai ajouter ces lignes :

# Enable Spoof protection (reverse-path filter)
net.ipv4.conf.all.rp_filter=1

# Enable TCP/IP SYN cookies
net.ipv4.tcp_syncookies=1

# Packet forwarding for IPv4
#net.ipv4.conf.default.forwarding=1

# Ignore ICMP Redirect message
net.ipv4.conf.all.accept_redirects = 0

# Ignore ICMP Echo request message
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_echo_ignore_all = 1

# RFC's sending ICMP error replies to a broadcast frame is forbidden so drop response to them
net.ipv4.icmp_ignore_bogus_error_responses = 1

# Disabling source routing
net.ipv4.conf.all.accept_source_route = 0

**Olivier Regnier** · 20/08/2006, 17h59

Ce qui serait intéressant c'est de voir les rêgles d'iptables de Gorgonite et le processus pour bloquer les ports inutitles, si cela est possible. Ensuite, je vais jouer le rôle d'un débutant qui souhaite paramètrer mon firewall avec un tas de questions

**gorgonite** · 20/08/2006, 18h18

Envoyé par Larkine

Ce qui serait intéressant c'est de voir les rêgles d'iptables de Gorgonite et le processus pour bloquer les ports inutitles, si cela est possible. Ensuite, je vais jouer le rôle d'un débutant qui souhaite paramètrer mon firewall avec un tas de questions

cela t'aide...

http://gorgonite.developpez.com/tuto...isations#LII-3

**gnto** · 20/08/2006, 18h19

c'est bien tes règles mais t'as pas de http de resolution dns
Enfin c'est une machine dédié au emule ?

Perso je ne vois pas quoi ca sert d'interdire le ping ?

**HNT** · 20/08/2006, 19h23

Interdire le ping sert à éviter certain type d'attaque dos (denial of service), sur un pc je sais pas, mais sur un routeur une attaque de ce type à pour conséquence le fait que le routeur passe tout son temps à répondre au ping et ne fait plus son travail de routeur (c'est donc une manière de le mettre momentanement "par terre")

La machine n'est pas dédiée mais amule est lancé à chaque démarrage.
Je ne comprend pas ta phrase :

c'est bien tes règles mais t'as pas de http de resolution dns

**Nightfall** · 20/08/2006, 20h02

Il y pas de règle spécifique pour le protocole http et pour le dns dans le script de HNT mais c'est pas la peine puisqu'il autorise tout en sortie et il autorise en entrée toute connexion créée par sa machine.

Je fais la même chose sur ma machine perso, ça permet de bloquer toute connexion créée par l'extérieur tout en faisant de l'http, du mail, sans avoir à écrire une règle pour chaque protocole.

**gnto** · 20/08/2006, 20h28

Envoyé par HNT

La machine n'est pas dédiée mais amule est lancé à chaque démarrage.
Je ne comprend pas ta phrase :

Envoyé par gnto

c'est bien tes règles mais t'as pas de http de resolution dns

Tu n'autorise pas le surf (client http =>80/tcp) et si tu surf tu n'auras pas la résolution de nom (client dns = 53/udp et tcp). La résolution de nom intervient quand tu tape une adresse en caractère alphabétique. Si tu ne l'as pas il te faut taper des @IP dans ton navigateur,

Le module recent d'iptables permet de limiter le nombre de tentative pendant un certains temps. c'est une sorte de bannissement de l'utilisateur ( c'est très utiles sur les scans et DOS )

**granquet** · 20/08/2006, 22h43

Envoyé par gnto

Tu n'autorise pas le surf (client http =>80/tcp) et si tu surf tu n'auras pas la résolution de nom (client dns = 53/udp et tcp).

si si, c'est autorisé par ces "lignes"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
# Autorise l'ouverture de connexion vers l'extérieur
iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
# Autorise la réception de connection initiée locallement
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

**HNT** · 20/08/2006, 22h50

Je confirme, ça marche puisque je suis en train de vous parler sur le forum avec ces règles et je n'ai pas du taper l'ip de developpez.net pour y arriver.

Sinon des critiques ? des améliorations ?

**ripat** · 22/08/2006, 10h34

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
# Rejette les demandes de connexions provenant de l'éxtérieur 
iptables -A INPUT -m state --state NEW -j REJECT

Le choix entre le target REJECT ou DROP a déjà fait couler beaucoup d'encre. Ou plutôt consommé pas mal de bp!

Pour rappel, REJECT retourne un message icmp du genre host/port/protocole unreachable. DROP ne retourne rien. Le trou noir pour l'attaquant.

Avantages DROP, donne la même impression à l'attaquant qu'un connection timeout. Un peu comme si le serveur n'existait pas.

Désavantages, apparemment DROP "pourrait" laisser des sockets morts des deux côtés. Je n'ai jamais pu vérifier cette affirmation trouvée chez un seul auteur.

Avantage REJECT, l'attaquant comprend que le système/protocole/port est protégé efficacement (mais il sait maintenant qu'il y a un quelque-chose derrière l'IP).

Personnellement, je pratique "la sécurité par l'obscurité". Moins ils en savent mieux je me porte.

La discussion est ouverte...

Autre point: dans une phase de mise au point je rajouterais une règle LOG du type "filet". Puisque tes POLICY par défaut sont sur DROP. Toutes les requêtes qui passeraient au travers des règles de ton filtre, et qui ne sont donc pas acceptées, y sont capturées et journalisées dans syslog.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

iptables -A INPUT -j LOG --log-prefix '[iptables DROP]'

**HNT** · 22/08/2006, 11h06

C'est très intéressant tout ça, je pense que tu as raison, je vais aussi mettre DROP au lieu de REJECT et j'ajoute aussi la dernière règle.

Merci.

PS : ce que tu dis pour le REJECT est confirmé par des tests en ligne qui me dise que mes ports sont fermés, le programme de test a donc bien reçu une réponse d'inactivité !

**Spoutnik** · 28/08/2006, 21h03

2 petites remarques :

# Rejette les demandes de connexions provenant de l'éxtérieur
iptables -A INPUT -m state --state NEW -j REJECT

est inutile en soi. Ta politique par défaut est à DROP, et tu n'autorise pas les NEW en input dans

# Autorise la réception de connection initiée locallement
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

donc, par défaut, c'est dropé, tout comme les tentatives de ping venant de l'extérieur. Il n'y a rien à rajouter

Par contre, la ligne

iptables -A INPUT -i lo --source 127.0.0.1 --destination 127.0.0.1 -j ACCEPT

me pose un peu plus "problème":
Il n'y a pas que l'adresse 127.0.0.1 dans les adresses loopback

iptables -A INPUT -i lo -o lo --source 127.0.0.0/8 --destination 127.0.0.0/8 -j ACCEPT

gorgonite -> j'ai remarqué avec nos précédentes discussion que tu préfère fermer les ports un à un (il me semble en ts cas), je trouve préférable de n'ouvrir que ceux qui servent

**Rhineauféros** · 29/08/2006, 11h27

personnellement, en tant que perfectionniste ridicule, il y a un truc con qui me chiffonne : c'est de faire le flush AVANT de définir les policies : pendant l'intervalle très court qui suit l'exécution de ces deux lignes, le pare-feu peut être totalement perméable (cas où les anciennes policies étaient à ACCEPT)

**gorgonite** · 29/08/2006, 19h54

Envoyé par Spoutnik

gorgonite -> j'ai remarqué avec nos précédentes discussion que tu préfère fermer les ports un à un (il me semble en ts cas), je trouve préférable de n'ouvrir que ceux qui servent

nan... je préfère ouvrir les ports un à un ; mais fermer les services inutiles un à un

**Katyucha** · 01/09/2006, 09h12

Envoyé par Rhineauféros

personnellement, en tant que perfectionniste ridicule, il y a un truc con qui me chiffonne : c'est de faire le flush AVANT de définir les policies : pendant l'intervalle très court qui suit l'exécution de ces deux lignes, le pare-feu peut être totalement perméable (cas où les anciennes policies étaient à ACCEPT)

Le temps est suffisamment court pour être négligeable.