Regle Iptables

Merci pour ces réponses.

####activation du nat####
echo "1" > /proc/sys/net/ipv4/ip_forward 
iptables -A POSTROUTING -t nat -o $wan -j MASQUERADE
######################## LAN ##################################
#### Autoriser les connexions deja etablis ou renouvellé ######
#### qui traverse le pare-feu #################################
iptables -A FORWARD -i $wan -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT 
iptables -A FORWARD -i $lan -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT

######################## PARTIE SERVEUR #######################
#### Autorise protocole UDP pour le dns, Serveur 1 et 2 #######
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur1 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW -j ACCEPT
#### Autorise protocole TCP pour serveur 1 (pop3,smtp,dns)et 2(dns) ####
iptables -A FORWARD -p tcp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dport 110,25,53 -i $lan -o $wan -s $serveur1 -m state --state NEW -j ACCEPT
#### Autorise LAN à faire de l'https ####
iptables -A FORWARD -p tcp --dport 443 -i $lan -o $wan -m state --state NEW -j ACCEPT


############ LAN => FW ###################
#### redirection du port 80 qui rentre par l'interface lan vers le port dansgaurdian ####
iptables -t nat -A PREROUTING -i $lan -p tcp --dport 80 -j REDIRECT --to-ports 8080
#### Autorise le SSH du lan vers FW ####
iptables -A INPUT -p tcp --dport ssh -i $lan -m state --state NEW -j ACCEPT
#### Autorise le LAN a rentrer sur le port 8080 et donné la réponse sur le 80
iptables -A INPUT -p tcp --dport 8080 -i $lan -m state --state NEW -j ACCEPT 
############iptables -A OUTPUT -p tcp --sport 80 -o $lan -m state --state NEW -j ACCEPT 



#########
### FW ##
#########
###############################################################
##### Autorise les connexion dèja etablished ou renouvellé #### 
##### 				en  input /output					   ####
###############################################################
iptables -A INPUT -i $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
###################### interface local ########################
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
############### Autoriser le FW interroger DNS ################
iptables -A OUTPUT -o $wan -p udp --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o $wan -p tcp --dport 53 -m state --state NEW -j ACCEPT
############### Autoriser le FW interroger web ################
iptables -A OUTPUT -o $wan -p tcp --dport 80 -m state --state NEW -j ACCEPT


###############################################################
######################    FTP    ##############################
###############################################################
#################### Active Module ############################
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp
####################### FW => WAN ############################
iptables -A OUTPUT -o $wan -p tcp --dport 21 -m state --state NEW -j ACCEPT
################## ftp du LAN vers WAN #######################
IPTABLES -A FORWARD -p tcp -i $lan --sport 1024:65535 --dport 21 -o $wan -m state --state NEW -j ACCEPT

C’est vrai que j’hésite a y toucher, mais comme tu la indiqué le support de Ech s’arrête dans 1 ans.

Après concernant mon serveur qui fera office de pare-feu (un grand merci a vous) Iptable + Serveur Proxy Squid+ Controleur de contenue Dansguardian.

Mon serveur sera mise en production total, quand nous aurons à disposition de notre connexion Internet (AdslMax). Cela signifie que je pourrait faire l’upgrade avant mise en production.

Si j’effectuer la mise à jour est-il préférable d’un upgrade ou d’une réinstalle au propre? (Je peu le faire sans gêné mes utilisateurs)

Merci .

guigui69

Vaste question… je pense qu’elle mériterait un nouveau fil de discussion à elle seule. En tout cas je ne suis pas le mieux placé pour y répondre autrement que par “ça dépend” car chaque méthode a ses avantages et ses inconvénients, comme toujours.

Merci pour votre aide.

Je vait bientôt recevoir notre connexion adsl donc je vait tester le script dans quelque semaine, et je vait vous fait un retour.

guigui69

Bonjour à tous,

Ma connexion internet ne va tarder à arriver.

J’ai reçu le modem/ routeur (SfrBox).
Est-il mieux que je configure en pppoe (linux vers la box) ou bien en routeur la box (et je redirige les port vers ip du parefeu). je peut mettre la box soit en routeur ou bien en bridge.

Merci d’avance pour votre retour sur cette question.

Merci

guigui69

Je vais encore faire une réponse de normand. Les deux configurations ont leurs avantages et leurs inconvénients.

PPPoE avec le modem en bridge offre un meilleur contrôle sur la connexion. C’est la machine qui fait office de pare-feu qui gère la connexion (avec des logs d’état détaillés si nécessaire), a l’adresse publique, contrôle le NAT et les redirections. On n’est pas gêné par le double NAT et les éventuelles limitations du modem en mode routeur. En revanche PPPoE impose un MTU (taille de paquet maximum) de 1492 octets au lieu de la valeur classique 1500 sur ethernet. Normalement le protocole IP sait gérer cette situation : les paquets trop gros doivent être fragmentés ou provoquer un message d’erreur ICMP “fragmentation needed”. Mais un défaut dans l’architecture de collecte ADSL de certains FAI peut provoquer ce qu’on appelle un “trou noir de MTU” (MTU black hole) : les paquets de taille comprise entre 1493 et 1500 octets sont silencieusement perdus au lieu d’être fragmentés ou de provoquer un message d’erreur, avec comme effet notable que les téléchargements de plus de ~1400 octets échouent. Il existe un contournement mis en oeuvre par certains FAI et routeurs qui masque le problème pour les protocoles basés sur TCP (web, FTP, mail…) mais qui ne peut rien pour les autres protocoles susceptibles d’envoyer de gros paquets notamment les tunnels et VPN basés sur UDP (comme OpenVPN) ou IPSec et qu’il faut donc configurer explicitement pour ne pas envoyer des paquets de plus de 1492 octets encapsulation comprise.

Merci pour ta réponse,

je vient de recevoir la connexion (2458Kbps/347Kbps|| 10 marge de bruit||50db atténuation).

Cette accès va uniquement servir à surfer, récupérer les mails. Donc les 2modes se valent?.

je vais commencer mettre en place iptable (j’ai configuré squid, dansguardian). Ou doit-je placer mon script pour qu’il s’exécute au démarrage du pc.

Merci d’avance pour votre aide

guigui69

Juste pour du HTTP(S) et du POP/IMAP sortants, il n’y a pas d’avantage à gérer la connexion PPP sur le serveur, et la configuration réseau du serveur sera plus simple avec le modem en mode routeur (configuration d’une interface ethernet contre configuration d’une connexion PPP).

Je mets la partie statique du script dans /etc/init.d/ et je crée un lien symbolique dans /etc/rcS.d/ avec update-rc.d (cf. page man) ayant le numéro d’ordre S39 pour qu’il soit exécuté juste avant le script de configuration du réseau /etc/rcS.d/S40networking. S’il y a des règles qui dépendent d’informations variables non connues à l’avance (nom d’interface, adresse IP…), pour une interface PPP je mets le script dans /etc/ppp/ip-up.d/ (pppd exécute les scripts de ce répertoire après la réussite de la négociation du protocole IP et leur passe les paramètres tels que nom de l’interface, adresses IP locale et distante, valeur de l’option ipparam), et un autre dans /etc/ppp/ip-down.d/ pour supprimer les règles à la déconnexion. Pour une interface ethernet, il y a l’équivalent avec /etc/network/if-*.d/ ou les options up, down, pre-up et post-down dans /etc/network/interfaces qui peuvent invoquer un script placé n’importe où, mais en cas de configuration par DHCP je ne sais pas si ces scripts reçoivent les paramètres IP de l’interface. Sinon, il faut regarder du côté des scripts lancés par le client DHCP (pour dhclient, cf. man dhclient-hooks).

D’accord donc tu me conseille, de laisser le routeur gérer la connexion et de rediriger les ports du routeur vers mon pare-feu linux?

voici mon script:
Quand pensez-vous?

FW-PROXY:/perso# cat /perso/script-fw
#!/bin/bash
#script de configuration iptables
#16-05-2009


# Refuse les ping 
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
# Refuse les rénses aux broadcasts.
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# Refuse le routage des paquets source.
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
# Refuse les redirections ICMP.
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
# Active la protection contre les erreurs ICMP.
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# Log les paquets spoofé le routage des paquets source et la redirection des paquets.
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians




#Remise à ero

iptables -F
iptables -t nat -F
iptables -X
iptables -t nat -X

wan="eth1"
lan="eth0"
serveur1="172.16.0.19"
serveur2="172.16.0.252"
pcadmin1="172.16.0.91"
####activation du nat####
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -A POSTROUTING -t nat -o $wan -j MASQUERADE
######################## LAN ##################################
#### Autoriser les connexions deja etablis ou renouvellé#####
#### qui traverse le pare-feu #################################
iptables -A FORWARD -i $wan -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $lan -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT

######################## PARTIE SERVEUR #######################
#### Autorise protocole UDP pour le dns, Serveur 1 et 2 #######
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur1 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW -j ACCEPT
#### Autorise protocole TCP pour serveur 1 (pop3,smtp,dns)et 2(dns) ####
iptables -A FORWARD -p tcp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dport 110,25,53 -i $lan -o $wan -s $serveur1 -m state --state NEW -j ACCEPT
#### Autorise LAN Ã aire de l'https ####
iptables -A FORWARD -p tcp --dport 443 -i $lan -o $wan -m state --state NEW -j ACCEPT
iptables -A FORWARD -p ICMP -i $lan -o $wan -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp  -i $lan -o $wan -s $pcadmin1 -m state --state NEW -j ACCEPT


############ LAN => FW ###################
#### redirection du port 80 qui rentre par l'interface lan vers le port dansgaurdian ####
iptables -t nat -A PREROUTING -i $lan -p tcp --dport 80 -j REDIRECT --to-ports 8080
#### Autorise le SSH du lan vers FW ####
iptables -A INPUT -p tcp --dport ssh -i $lan -m state --state NEW -j ACCEPT
#### Autorise le LAN a rentrer sur le port 8080 et donnéa rénse sur le 80
iptables -A INPUT -p tcp --dport 8080 -i $lan -m state --state NEW -j ACCEPT
############iptables -A OUTPUT -p tcp --sport 80 -o $lan -m state --state NEW -j ACCEPT



#########
### FW ##
#########
###############################################################
##### Autorise les connexion dè etablished ou renouvellé###
#####             en  input /output                  ####
###############################################################
iptables -A INPUT -i $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
###################### interface local ########################
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
############### Autoriser le FW interroger DNS ################
iptables -A OUTPUT -o $wan -p udp --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o $wan -p tcp --dport 53 -m state --state NEW -j ACCEPT
############### Autoriser le FW interroger web ################
iptables -A OUTPUT -o $wan -p tcp --dport 80 -m state --state NEW -j ACCEPT


###############################################################
######################    FTP    ##############################
###############################################################
#################### Active Module ############################
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp
####################### FW => WAN ############################
iptables -A OUTPUT -o $wan -p tcp --dport 21 -m state --state NEW -j ACCEPT
################## ftp du LAN vers WAN #######################
iptables -A FORWARD -p tcp -i $lan --sport 1024:65535 --dport 21 -o $wan -m state --state NEW -j ACCEPT


# Interdire toute connexion entrante et sortante
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP

Pour sauvegarder et que cela s’enregistre j’ai trouvé ceci:

La commande iptables-save envoie sur l'écran le contenu des chaînes de toutes les tables dans un format relativement lisible :
[root@fw user]# iptables-save

Cette commande a un autre avantage.
En dirigeant sa sortie vers un fichier, vous obtenez un fichier de configuration qui sera exploitable par un autre script : iptables-restore
[root@fw root]# iptables-save > maconfig.iptables

Vous pourrez restaurer intégralement votre configuration depuis ce fichier :
[root@fw root]# iptable-restore < maconfig.iptables


Quand vous avez déterminé que votre configuration est bonne :
[root@fw user]# /etc/init.d/iptables save
Sauvegarde des règles courantes dans /etc/sysconfig/iptables : [ OK ]

Au prochain démarrage du PC vos règles IPTables seront automatiquement prises en compte.

Pour restaurer l'état des tables au moyen du fichier /etc/sysconfig/iptables :
[root@fw user]# /etc/init.d/iptables start (ou restart)
Application des règles "iptables" du pare-feu : [ OK ]

Pour vérouiller votre machine (plus rien ne passe) :
[root@fw user]# /etc/init.d/iptables panic
Passage de la politique des cibles à DROP : [ OK ]

Qu’en pensez-vous?

Merci d’avance

guigui69

Pourquoi rediriger des ports (et lesquels) vers le pare-feu alors que le jeu de règles iptables n’accepte ni redirige aucune connexion entrante sur l’interface WAN ?

Le moins souvent possible, ça fatigue. :laughing: (désolé, trop tentant)

Pour éviter une myriade de blocs de quote et de code, j’insère mes commentaires directement dans le bloc de code en les faisant précéder de *

FW-PROXY:/perso# cat /perso/script-fw
#!/bin/bash
#script de configuration iptables
#16-05-2009


# Refuse les ping 
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
* Bof. Pourquoi ? C'est utile, le ping. Si tu veux le bloquer côté internet il suffit de ne pas créer de règle qui l'accepte.

# Refuse les rénses aux broadcasts.
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
* Primo, il s'agit seulement des pings (ICMP echo) broadcast, pas de tous les broadcast. Secundo, si tous les pings sont ignorés avec le paramètre précédent, celui-ci est redondant.

# Refuse le routage des paquets source.
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
* "les paquets avec l'option de routage source" plutôt

# Refuse les redirections ICMP.
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
* Note que ce paramètre est désactivé par défaut lorsque le mode routeur est activé (ip_forward=1).

# Active la protection contre les erreurs ICMP.
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# Log les paquets spoofé le routage des paquets source et la redirection des paquets.
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
* Ce paramètre ne loggue que les paquets "martiens" (avec des adresses impossibles), pas ceux avec l'option de routage source ni les ICMP Redirect.



#Remise Ã&nbsp;ero

iptables -F
iptables -t nat -F
iptables -X
iptables -t nat -X

wan="eth1"
lan="eth0"
serveur1="172.16.0.19"
serveur2="172.16.0.252"
pcadmin1="172.16.0.91"
####activation du nat####
echo "1" > /proc/sys/net/ipv4/ip_forward
* Ça c'est la fonction routeur, pas le NAT. Pourquoi ne pas l'avoir mise avec les autres paramètres du noyau ?

iptables -A POSTROUTING -t nat -o $wan -j MASQUERADE
######################## LAN ##################################
#### Autoriser les connexions deja etablis ou renouvellé#####
#### qui traverse le pare-feu #################################
iptables -A FORWARD -i $wan -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $lan -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT

######################## PARTIE SERVEUR #######################
#### Autorise protocole UDP pour le dns, Serveur 1 et 2 #######
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur1 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW -j ACCEPT
#### Autorise protocole TCP pour serveur 1 (pop3,smtp,dns)et 2(dns) ####
iptables -A FORWARD -p tcp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dport 110,25,53 -i $lan -o $wan -s $serveur1 -m state --state NEW -j ACCEPT
#### Autorise LAN Ã&nbsp;aire de l'https ####
iptables -A FORWARD -p tcp --dport 443 -i $lan -o $wan -m state --state NEW -j ACCEPT
iptables -A FORWARD -p ICMP -i $lan -o $wan -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp  -i $lan -o $wan -s $pcadmin1 -m state --state NEW -j ACCEPT
* Pourquoi seulement TCP ?

############ LAN => FW ###################
#### redirection du port 80 qui rentre par l'interface lan vers le port dansgaurdian ####
iptables -t nat -A PREROUTING -i $lan -p tcp --dport 80 -j REDIRECT --to-ports 8080
#### Autorise le SSH du lan vers FW ####
iptables -A INPUT -p tcp --dport ssh -i $lan -m state --state NEW -j ACCEPT
#### Autorise le LAN a rentrer sur le port 8080 et donnéa rénse sur le 80
iptables -A INPUT -p tcp --dport 8080 -i $lan -m state --state NEW -j ACCEPT
############iptables -A OUTPUT -p tcp --sport 80 -o $lan -m state --state NEW -j ACCEPT



#########
### FW ##
#########
###############################################################
##### Autorise les connexion dè etablished ou renouvellé###
#####             en  input /output                  ####
###############################################################
iptables -A INPUT -i $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
###################### interface local ########################
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
############### Autoriser le FW interroger DNS ################
iptables -A OUTPUT -o $wan -p udp --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o $wan -p tcp --dport 53 -m state --state NEW -j ACCEPT
############### Autoriser le FW interroger web ################
iptables -A OUTPUT -o $wan -p tcp --dport 80 -m state --state NEW -j ACCEPT


###############################################################
######################    FTP    ##############################
###############################################################
#################### Active Module ############################
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp
####################### FW => WAN ############################
iptables -A OUTPUT -o $wan -p tcp --dport 21 -m state --state NEW -j ACCEPT
################## ftp du LAN vers WAN #######################
iptables -A FORWARD -p tcp -i $lan --sport 1024:65535 --dport 21 -o $wan -m state --state NEW -j ACCEPT


# Interdire toute connexion entrante et sortante
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
* Il est plutôt d'usage de fixer les politiques par défaut au début, avant de vider les chaînes. Ainsi on ne crée pas de trou pendant la création des règles si la politique précédente était ACCEPT.

(iptables-save + iptables-restore)
Je préfère le format de sortie d’iptables-save, plus compact et plus proche de la syntaxe des règles, à celui d’iptables -L. En revanche je préfère la lisibilité d’un bon vieux script shell pour la mise en place du jeu de règles. iptables-restore ne se justifie que pour des raisons de performances avec un très grand nombre de règles à créer ; en effet pour ajouter une seule règle, iptables doit décharger la table entière, ajouter la règle et recharger la table, ce qui peut prendre un temps non négligeable avec des milliers de règles alors qu’iptables-restore charge toutes les règles d’une table d’un seul coup. Mébon, ce n’est que mon avis personnel.

Merci pour tes réponses je regarde ca lundi,

concernant la redirection des ports, je parlait dans le futur (dans le cas ou j’aurai a rediriger des ports) je ne le ferai pas maintenant.

Pour les règle iptable je regarde ca.

Merci pour ton aide.

guigui69

Pourquoi pop ?

pour un serveur d’entreprise, le smtp suffit pour envoyer/recevoir les messages, à moins que tu passes par des serveurs de ton FAI pour les mails ?

Bonjour,

voici mon script mis à jour:

#!/bin/bash
#script de configuration iptables
#16-05-2009



wan="eth1"
lan="eth0"
serveur1="172.16.0.19"
serveur2="172.16.0.252"
pcadmin1="172.16.0.91"
pcadmin2=$(/usr/bin/host pan-por03.panidor.org | cut -d" " -f4)

# Refuse les rénses aux broadcasts.
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# Refuse le routage des paquets source.
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
# Refuse les redirections ICMP.
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
# Active la protection contre les erreurs ICMP.
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# Log les paquets spoofé le routage des paquets source et la redirection des paquets.
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

# Active la protection TCP syn cookie
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
#activation du routeur####
echo "1" > /proc/sys/net/ipv4/ip_forward


# Interdire toute connexion entrante et sortante
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP

#Remise à ero

iptables -F
iptables -t nat -F
iptables -X
iptables -t nat -X

iptables -A POSTROUTING -t nat -o $wan -j MASQUERADE
######################## LAN ##################################
#### Autoriser les connexions deja etablis ou renouvellé#####
#### qui traverse le pare-feu #################################
iptables -A FORWARD -i $wan -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $lan -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT

######################## PARTIE SERVEUR #######################
#### Autorise protocole UDP pour le dns, Serveur 1 et 2 #######
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur1 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p udp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW -j ACCEPT
#### Autorise protocole TCP pour serveur 1 (pop3,smtp,dns)et 2(dns) ####
iptables -A FORWARD -p tcp --dport 53 -i $lan -o $wan -s $serveur2 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp -m multiport --dport 110,25,53 -i $lan -o $wan -s $serveur1 -m state --state NEW -j ACCEPT
#### Autorise LAN Ã aire de l'https ####
iptables -A FORWARD -p tcp --dport 443 -i $lan -o $wan -m state --state NEW -j ACCEPT
iptables -A FORWARD -p ICMP -i $lan -o $wan -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp  -i $lan -o $wan -s $pcadmin1 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p udp  -i $lan -o $wan -s $pcadmin1 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp  -i $lan -o $wan -s $pcadmin2 -m state --state NEW -j ACCEPT
iptables -A FORWARD -p udp  -i $lan -o $wan -s $pcadmin2 -m state --state NEW -j ACCEPT


############ LAN => FW ###################
#### redirection du port 80 qui rentre par l'interface lan vers le port dansgaurdian ####
iptables -t nat -A PREROUTING -i $lan -p tcp --dport 80 -j REDIRECT --to-ports 8080
#### Autorise le SSH du lan vers FW ####
iptables -A INPUT -p tcp --dport ssh -i $lan -m state --state NEW -j ACCEPT
#### Autorise le LAN a rentrer sur le port 8080 et donnéa rénse sur le 80
iptables -A INPUT -p tcp --dport 8080 -i $lan -m state --state NEW -j ACCEPT
############iptables -A OUTPUT -p tcp --sport 80 -o $lan -m state --state NEW -j ACCEPT



#########
### FW ##
#########
###############################################################
##### Autorise les connexion dè etablished ou renouvellé###
#####             en  input /output                  ####
###############################################################
iptables -A INPUT -i $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $lan -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPT
###################### interface local ########################
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
############### Autoriser le FW interroger DNS WAN ################
iptables -A OUTPUT -o $wan -p udp --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o $wan -p tcp --dport 53 -m state --state NEW -j ACCEPT

############### Autoriser le FW interroger DNS LAN ################
iptables -A OUTPUT -o $lan -p udp --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o $lan -p tcp --dport 53 -m state --state NEW -j ACCEPT

############### Autoriser le FW interroger web ################
iptables -A OUTPUT -o $wan -p tcp --dport 80 -m state --state NEW -j ACCEPT


###############################################################
######################    FTP    ##############################
###############################################################
#################### Active Module ############################
modprobe ip_conntrack_ftp
modprobe ip_nat_ftp
####################### FW => WAN ############################
iptables -A OUTPUT -o $wan -p tcp --dport 21 -m state --state NEW -j ACCEPT
################## ftp du LAN vers WAN #######################
iptables -A FORWARD -p tcp -i $lan --sport 1024:65535 --dport 21 -o $wan -m state --state NEW -j ACCEPT

Le pop car oui je passe par un fai pour récuperer des mails.

Pour ma connexion j’ai choisis de rester en Ethernet (c’est la sfrbox qui gere la connexion).

mes 2 interfaces (lan & wan) sont configuré en ip static.

Donc apres avoir lu ton post:

[quote]

Pour une interface ethernet, il y a l’équivalent avec /etc/network/if-*.d/ ou les options up, down, pre-up et post-down dans /etc/network/interfaces qui peuvent invoquer un script placé n’importe où, mais en cas de configuration par DHCP je ne sais pas si ces scripts reçoivent les paramètres IP de l’interface. Sinon, il faut regarder du côté des scripts lancés par le client DHCP (pour dhclient, cf. man dhclient-hooks).[/code]

Tu me conseilles de le mettre dans if-up.d?

Mon script actuel doit être modifier? ou est-il compatible?

Merci

guigui69

Je me permet de soulever une petite interrogation.
Après maintes et maintes recherches, lectures de guides, etc., j’en suis arrivé à avoir une liste de règles iptables convenant à mes besoins.
MAIS, car il y a un mais, (corrigez moi sir je me trompe) iptables agi au niveau de la couche logicielle, et non matérielle.
Ce qui en soit me pose un léger problème technique :
en cas d’attaque DoS et autres attaques type flood machine, le matériel lui continue de recevoir les requête et de les traiter.
Ce qui signifie donc que les performances s’en retrouvent polluées, le matériel surchargé de requêtes.
Une idée pour parer cela ?
Appliquer une sorte de règle iptable bien avant la couche logicielle ?
(je parle ici d’un serveur et non d’un pc perso derrière un routeur)
J’ai cru comprendre que la chose ne se faisait que niveau matériel, par le biais d’un bon vieux routeur cisco ou autre marque. Mais dans un tel cas, certes le serveur craint moins, mais la bande passante en prend un coup.
On me dira de voir avec le fournisseur du serveur : ce dernier refuse d’intervenir x_x
Bref voilà, si quelqun à LA solution miracle x)

ps: le dit serveur tourne sous Deb. 5 lenny

Bonjour,

Certes, le développement de règles IpTables est très instructif et nécessaire pour comprendre ce qui se passe, mais pour une utilisation en entreprise, ne serait il pas plus sûr d’utiliser un logiciel prévu pour cela ?

Je pensais à FWBulider, qui te permettra de configurer ton firewall via une interface graphique digne des firewalls pro. De plus, les règles qu’il génère sont testées et débuggées par de nombreux utilisateurs, ce qui pourrais t’éviter une faille dans ton firewall due à une règle IpTables mal placée / éronnée.

Cela aura de plus l’avantage que ton firewall ne sera pas dépendant de toi et de ton savoir ‘programmer iptables’, en fournissant une interface claire et concise que ‘presque’ n’importe qui pourra prendre en main rapidement.

oui, je verrai bien par la suite, la je vient de mettre en place mon server (iptables-squid-dansguardian) j’attend de voir ce que ca donne.

guigui69

J’ai mis en place mon serveur (iptables+squid+dansguardian) cela fonctionne :smiley:

Pour l’instant rien à signaler.

J’aurai une question, avec iptables serai–il possible de rediriger l’ensemble des requete vers un autre routeur.

Pour etre clair, Si par exemple ma connexion adsl tombe en rade (plus de connexion). Iptable redirige l’ensemble des demandes vers un autre routeur.

Est-ce possible ?

Merci

guigui69

cette règle si:

iptables -t nat -A PREROUTING -p ALL -i $lan -j DNAT --to-destination 172.16.0.XX 

Cette règle indique que tout qui arrive sur l’interface lan je le redirige vers l’ip du routeur de secours.

Est-se correcte?

guigui69

Le reroutage via un autre routeur ne concerne pas vraiment iptables mais la table de routage. Il “suffit” de modifier la route par défaut en spécifiant l’autre routeur comme passerelle. Il peut cependant être nécessaire d’ajuster les règles iptables à cette situation si le routeur de secours est côté LAN et non WAN car les paquets entrent et sortent par la même interface. Une autre approche plus sophistiquée consiste à faire un “routeur virtuel”, en définissant une adresse de passerelle virtuelle qui sera attribuée au routeur actif.

Ta règle avec DNAT n’est pas du tout appropriée car elle définit le routeur de secours comme la destination finale de tout le trafic et non comme la passerelle.

Explication:

Internet1<=>Neufbox<=192.168.1.1||192.168.1.2=>FW<=172.16.0.254=> LAN
Internet2<=>Modem<=Ip-public=>Routeur Netopia<=172.16.0.175=>LAN

Le but c’est que si il n’y a plus internet sur le premier accès, cela bascule sur le second (Netopia).

cette route:

Route add default 172.16.0.175 eth0

Quel règle iptable serait à envisagé étant donné que les 2 routeurs sont sur le même lan?

Merci

guigui69.

La route est presque correcte, il manque manque juste gw devant l’adresse de la passerelle et la mention de l’interface de sortie n’est pas nécessaire car le noyau sait sans ambiguïté par quelle interface cette adresse est joignable.

Si le routeur de secours est connecté directement au LAN, ça complique les choses (il aurait été beaucoup plus simple de le connecter du côté de l’interface $wan du pare-feu). Je conseille de dessiner un schéma du réseau pour tracer le chemin que les paquets doivent emprunter dans les sens aller et retour, ça aide à définir les règles iptables nécessaires pour permettre ce trafic. Et les choix possibles, car il n’y a pas qu’une seule solution.

Aller : poste - [$lan - pare-feu - $lan] - routeur de secours - internet
Retour : internet - routeur de secours - [$lan - pare-feu - $lan] - poste

J’ai mis des crochets car le trafic ne passe pas forcément par le pare-feu. J’explique.

Pour les postes du LAN, la passerelle par défaut reste le pare-feu. Celui-ci reçoit les paquets de requête sur son interface $lan et doit les retransmettre au routeur de secours par la même interface $lan. Cela correspond à -i $lan -o $lan dans la chaîne FORWARD. Pour autoriser ces paquets, tu as plusieurs options :

  • dupliquer toutes les règles avec -i $lan -o $wan en -i $lan -o $lan (la création d’une chaîne utilisateur aiderait à réduire le nombre de règles en les factorisant) ;
  • supprimer -o wan de ces règles ;
  • ajouter une simple règle avec -i $lan -o $lan autorisant tout ;

Dans le sens retour, le routeur de secours va envoyer les paquets de réponse directement à au poste qui a émis la requête. Par conséquent le pare-feu ne les voit pas et ne met pas à jour sa table d’état de suivi des connexions. Par conséquent le paquet suivant dans le sens aller d’une connexion TCP peut être considéré comme invalide et être bloqué. Le filtrage à état, comme le NAT, ne fait pas bon ménage avec les situations de routage asymétrique.

Ce n’est pas tout. En tant que routeur, quand Linux reçoit et retransmet un paquet par la même interface, par défaut il envoie à la source du paquet un message ICMP “Redirect” qui signale qu’il existe un chemin plus court pour la destination avec l’adresse de la passerelle à utiliser, ici l’adresse du routeur de secours. Une exception est quand l’adresse destination du paquet a subi l’effet d’une règle iptables de NAT (DNAT, REDIRECT). L’envoi d’ICMP redirect peut être désactivé pour une interface si les sysctl (paramètres du noyau) net.ipv4.conf.all.send_redirects et net.ipv4.conf..send_redirects sont à 0. Selon son OS et/ou sa configuration (et le réglage de son pare-feu le cas échéant), un poste client peut accepter ou ignorer les messages ICMP redirect. Pour Linux, c’est contrôlé par les paramètres net.ipv4.conf.*.accept_redirects qui sont activés par défaut pour une configuration en hôte (ip_forward=0) et désactivés pour une configuration en routeur (ip_forward=1).

Selon qu’un poste client accepte ou non les ICMP redirect pour une destination, les paquets aller vers cette destination vont suivre des chemins différents, avec des conséquences différentes :

  • redirect non accepté : le poste envoie les paquets suivants vers le pare-feu qui risque de les bloquer comme invalides car il ne voit pas le trafic retour ;
  • redirect accepté : le poste envoie les paquets suivants vers le routeur de secours, ce qui court-circuite les règles de filtrage du pare-feu pour cette destination.

Pour éviter ces ennuis, il y a une solution :

  • ajouter une règle SNAT ou MASQUERADE sur l’interface $lan du pare-feu, ainsi le routeur de secours voit l’adresse LAN du pare-feu comme source du trafic aller et lui renvoie le trafic retour ;
  • désactiver l’émission d’ICMP redirect par le pare-feu afin que les postes continuent à lui envoyer le trafic aller.

Cependant un poste client pourrait de toute façon modifier sa route par défaut pour court-circuiter le pare-feu.

Il y a un autre détail que le routage : les DNS. A moins qu’ils disposent d’un cache DNS récursif autonome (qui sait résoudre une requête DNS sans l’aide d’un autre serveur DNS récursif), le pare-feu et les postes du LAN devront utiliser les DNS du routeur de secours ou du FAI de secours. Si les postes du LAN utilisent directement les DNS du FAI principal, ce qui semble être le cas d’après tes règles iptables, alors il faudra probablement ajouter des règles DNAT pour rediriger leurs requêtes vers le routeur de secours ou les DNS du FAI de secours.