Regle Iptables

[guigui69]

Oui, penses au mises à jour de squid (si tu utilises des listes venant de l’extérieur) mais sur l’usage des machines, c’est toi qui vois.

mais sur l’usage des machines, c’est toi qui vois. J’ai pas compris??

[fran.b]

Il est très facile de faire un tunnel ssh avec travers du https par exemple. Interdire une sortie vers du ssh conduira juste à ne pas savoir qui fait du ssh à l’extérieur. Je ne suis pas sûr que ça soit une bonne idée d’interdire cela par exemple. Mais ces considérations dépendent juste de toi et de ta boite. C’était juste une remarque personnelle…

[PascalHambourg]

guigui69 :
Il reste encore une règle avec --sport à supprimer.

Attention pas d’«s» à dport, double emploi pour dns.

L’option –dports de la correspondance multiport prend bien un ‘s’. Ne pas confondre avec l’option –dport des correspondances tcp et udp.
Où vois-tu un double emploi pour DNS ? Il y a juste ce qu’il faut de règles pour serveur1 et serveur2 en TCP et UDP.

[guigui69]

Il est très facile de faire un tunnel ssh avec travers du https par exemple. Interdire une sortie vers du ssh conduira juste à ne pas savoir qui fait du ssh à l’extérieur. Je ne suis pas sûr que ça soit une bonne idée d’interdire cela par exemple. Mais ces considérations dépendent juste de toi et de ta boite. C’était juste une remarque personnelle…

Désolé je n’ai pas très bien compris

PascalHambourg, je n’ai pas compris ton dernier message concernant les dns.

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

###
###

iptables -A POSTROUTING -t nat -o $wan -j MASQUERADE
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
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 pop,smtp,dns -i $lan -o $wan -s $serveur1 -m state --state NEW  -j ACCEPT
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 80 -j REDIRECT --to-ports 8080


###
###
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
#SSH du lan vers FW
iptables -A INPUT -p tcp --dport ssh -i $lan -m state --state NEW -j ACCEPT


#proxy 8080 sur FW
iptables -A INPUT -p tcp --dport 8080 -i $lan -m state --state NEW -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 web
iptables -A OUTPUT -o $wan -p tcp -dport 80 -m state --state NEW -j ACCEPT

Merci

guigui69

[fran.b]

Désolé je n’ai pas très bien compris

PascalHambourg, je n’ai pas compris ton dernier message concernant les dns.

En clair, tout interdire en sortie n’est pas forcément toujours une bonne idée mais c’est un point de vue que tu peux ne pas partager, ça dépend de ton contexte et de ta vision du parefeu.

La remarque de Pascal Hambourg sur les DNS était pour moi, (j’ai mal lu une de tes règles), cf ci dessous

[quote=“PascalHambourg”]guigui69 :
Il reste encore une règle avec --sport à supprimer.

Attention pas d’«s» à dport, double emploi pour dns.

L’option –dports de la correspondance multiport prend bien un ‘s’. Ne pas confondre avec l’option –dport des correspondances tcp et udp.[/quote]
Oups…

[quote]
Où vois-tu un double emploi pour DNS ? Il y a juste ce qu’il faut de règles pour serveur1 et serveur2 en TCP et UDP.[/quote]
Télescopage serveur1 et serveur2 (la ligne avec --dport 53 suivi de la ligne avec --dports pop,smtp,dns , 53 un coup, puis dns).

Sinon, pour le ssh, je pense que tu veux parler de cette ligne

FW peut ouvrir des connexion n’importe où à partir du port ssh. Erreur de frappe peut être avec

iptables -A OUTPUT -p tcp --sport ssh -o $lan -m state --state RELATED, ESTABLISHED -j ACCEPT mais ça fait double emploi avec les règles déjà posées

[guigui69]

citation:

En clair, tout interdire en sortie n’est pas forcément toujours une bonne idée mais c’est un point de vue que tu peux ne pas partager, ça dépend de ton contexte et de ta vision du parefeu.

Quand tu parle tout interdire sur te base par rapport au FW -> Internet ou bien LAN -> Internet.

Une petite question:

Concernant le ftp, est-il mieux de l’autoriser depuis iptables ou bien le faire passé par un proxy(squid) ?

Merci

guigui69

[fran.b]

[quote=“guigui69”]citation:

En clair, tout interdire en sortie n’est pas forcément toujours une bonne idée mais c’est un point de vue que tu peux ne pas partager, ça dépend de ton contexte et de ta vision du parefeu.

Quand tu parle tout interdire sur te base par rapport au FW -> Internet ou bien LAN -> Internet.
[/quote]
LAN vers Internet, mais encore une fois c’est un point de vue personnel.

Une petite question:

Concernant le ftp, est-il mieux de l’autoriser depuis iptables ou bien le faire passé par un proxy(squid) ?

Je ne connais pas les subtilités de Squid sur le FTP et il y a peut être des avantages que je ne connais pas. Les règles iptables permettent de décharger squid et donc limite la charge de FW mais il y a peut être des fonctionnalités intéressantes (logs, filtrage par exemple) dont tu as besoin

[guigui69]

D’accord ,

Mais je préfère bien bloquer, pour éviter des émule torrent etc…

Donc je vais voir pour le ftp. J’ai une question concernant squid,est-il possible de faire passer du https dedans? (sinon je créé une règle iptable pour laisser passé le https 443)

[PascalHambourg]

Dernier détail déjà souligné par fran.b : la règle REDIRECT fait référence à un nom réel d’interface qu’il faudrait remplacer par la variable d’environnement correspondante, d’une part par cohérence avec les autres règles et d’autre part pour éviter les problèmes en cas de changement de nom de l’interface ou de portage du script sur une autre machine avec des noms d’interfaces différents.

Concernant FTP et Squid, d’après ce que je sais Squid peut faire proxy FTP mais pas en proxy transparent, seulement en proxy explicite défini dans la configuration du client. Même chose pour HTTPS. A noter que dans le cas de HTTPS, le client utilise en fait la commande CONNECT pour établir une connexion TCP vers le port 443 du serveur à travers le proxy. Un peu comme un proxy SOCKS, en quelque sorte. Le flux des données entre le client et le serveur est chiffré et arbitraire sans contrôle possible par Squid (à part l’adresse et le port destination), donc il est possible de faire passer n’importe quoi dans cette connexion comme l’a écrit fran.b.

[guigui69]

Merci, je corrige ce probleme pour le REDIRECT.

Concernant le ftp et l’https, dans ma configuration actuelles vont-il passé par le proxy ou bien non ?

Merci

guigui69

[fran.b]

Si tu n’as pas modifié, la sortie vers un port www est redirigée vers le proxy, pas de sortie https autorisée, il faut explicitement demander à passer par le proxy qui n’a pas le droit de faire une requête vers du https.

[guigui69]

c’est bien se que je croyait. par contre si je modifie par iptables les règle https et ftp pour rediriger vers le proxy cela va-t-il fonctionner? vont-il bien passé par le proxy ? non ?

[PascalHambourg]

Concernant le ftp et l’https, dans ma configuration actuelles vont-il passé par le proxy ou bien non ?

Ça dépend entièrement de la configuration des clients.

par contre si je modifie par iptables les règle https et ftp pour rediriger vers le proxy cela va-t-il fonctionner?

A ma connaissance non. Squid est un proxy HTTP seulement, pas HTTPS ou FTP. Ça veut dire qu’il faut lui causer en HTTP. Si on lui cause en HTTPS ou en FTP, Squid ne va rien comprendre.

[guigui69]

Re Bonjour à tous,

j’ai mis a jour mon script:

• Autoriser le LAN avoir accès en https.
• Autoriser le LAN à avoir un accès en ftp.
• Autoriser le FW a avoir accès au ftp.

####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é
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

### Autorisation Serveurs
### 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

[b]### Autorise  le LAN:https
iptables -A FORWARD -p tcp --dport 443 -i $lan -o $wan -m state --state NEW -j ACCEPT
[/b]

############LAN => FW ###################
### redirection du flux 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
iptables -A OUTPUT -p tcp --sport ssh -o $lan -m state --state NEW -j ACCEPT
###On autorise le LAN a rentrer sur le port 8080 et donné la réponse sur le 80
[b]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 
[/b]


#########
### FW ##
#########

### autorise les connexion des etablished ou renouvellé  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
[b]### Autoriser le ftp sur le FW
iptables -A OUTPUT -o $wan -p tcp -dport 21 -m state --state NEW -j ACCEPT
[/b]

##########
## FTP ###
##########
### Active Module
[b]modprobe ip_conntrack_ftp
modprobe ip_nat_ftp

### FW => WAN (ftp actif)
iptables -A OUTPUT -o $wan -p tcp -dport 21 -m state --state NEW -j ACCEPT
iptables -A INPUT -i $wan -p tcp --sport 20 -m state --state NEW -j ACCEPT
### regle ftp passif
iptables -A OUTPUT -o $wan -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -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
IPTABLES -A FORWARD -p tcp -i $lan --sport 1024:65535 --dport 1024:65535 -o $wan -m state --state RELATED -j ACCEPT[/b]

• Les règles ftp vous paraisse t-elle correct? (entre ftp actif & passif)
• La règle https.
• La règle d’autorisation :
  ###On autorise le LAN a rentrer sur le port 8080 et donné la réponse sur le 80

Vous parait-elle correcte?

Merci d’avance pour votre aide.

guigui69

[fran.b]

Rapidement, (je n’ai pas le temps de tout regarder)

iptables -A OUTPUT -p tcp --sport 80 -o $lan -m state --state NEW -j ACCEPT

ne sert à rien, la réponse n’est pas une nouvelle connexion, cela devrait passer par le «related».

[quote]iptables -A INPUT -i $wan -p tcp --sport 20 -m state --state NEW -j ACCEPT
[/quote]
tu autorises n’importe qui à tout faire à partir du port 20.

[guigui69]

Merci pour ces réponses.

Concernant le ftp, c’est vrai que je but

####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é
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

### Autorisation Serveurs
### 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  le LAN:https
iptables -A FORWARD -p tcp --dport 443 -i $lan -o $wan -m state --state NEW -j ACCEPT


############LAN => FW ###################
### redirection du flux 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
iptables -A OUTPUT -p tcp --sport ssh -o $lan -m state --state NEW -j ACCEPT
###On 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 des etablished ou renouvellé  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 (ftp actif)
iptables -A OUTPUT -o $wan -p tcp -dport 21 -m state --state NEW -j ACCEPT
### regle ftp passif
iptables -A OUTPUT -o $wan -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -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
IPTABLES -A FORWARD -p tcp -i $lan --sport 1024:65535 --dport 1024:65535 -o $wan -m state --state RELATED -j ACCEPT

J’ai corrigé j’ai enlever la regle du ftp sur le port20. Aurait-je commis au niveau du ftp (ou autres)? (ftp actif /passif)

Merci

guigui69

[fran.b]

iptables -A OUTPUT -p tcp --sport ssh -o $lan -m state --state NEW -j ACCEPT

Cette ligne ne sert à rien et peut être nocive. Le port ssh de FW n’ouvrira jamais de lui même une connexion mais répondra à une connexion. Tu peux virer cette règle.

[quote][…]
##########

FTP

##########

regle ftp passif

iptables -A OUTPUT -o $wan -p tcp --sport 1024:65535 --dport 1024:65535 -m state --state ESTABLISHED,RELATED -j ACCEPT
[/quote]
Double emploi avec

iptables -A OUTPUT -o $wan -m state --state ESTABLISHED,RELATED -j ACCEPTtu peux l’enlever.

[…]
IPTABLES -A FORWARD -p tcp -i $lan --sport 1024:65535 --dport 1024:65535 -o $wan -m state --state RELATED -j ACCEPT

Idem avec la règle

[/code]

J’ai corrigé j’ai enlever la regle du ftp sur le port20. Aurait-je commis au niveau du ftp (ou autres)? (ftp actif /passif)

En passif, le client crée sur un port fourni par le serveur, le module s’occupe de ça il n’y a rien à faire. En actif, le serveur initialise une connexion du port 20 vers le port fourni par le client. Dans ce cas encore, je crois que le module s’occupe de faire les règles à la volée. Je crois donc que tu n’as rien de plus à mettre que la règle autorisant les nouvelles connexions vers le port 21.

[PascalHambourg]

J’avais promis une réponse, mais François a déjà tout dit.

• les règles inutiles et potentiellement nuisibles avec --sport et NEW à virer (il en reste encore une pour SSH)
• la règle pour le port 20 inutile (géré automatiquement par le module de suivi de connexion FTP)
• les règles redondantes pour les connexions de données FTP.

En passif, le client crée sur un port fourni par le serveur, le module s’occupe de ça il n’y a rien à faire. En actif, le serveur initialise une connexion du port 20 vers le port fourni par le client. Dans ce cas encore, je crois que le module s’occupe de faire les règles à la volée. Je crois donc que tu n’as rien de plus à mettre que la règle autorisant les nouvelles connexions vers le port 21.

En fait le module de suivi de connexion FTP nf_conntrack_ftp/ip_conntrack_ftp ne crée pas de règles à la volée, il ne fait que classer dans l’état RELATED au lieu de NEW le premier paquet d’une connexion de donnée FTP. Quant au module de NAT FTP nf_nat_ftp/ip_nat_ftp, il modifie automatiquement tout ce qui doit l’être (adresse, port) dans un contexte où du NAT est appliqué à la connexion de commande FTP, dans un sens (SNAT, MASQUERADE) et/ou dans l’autre (DNAT).

Maintenant, un peu de “philosophie”. guigui69, les règles que tu avais ajoutées pour autoriser les connexion de données FTP sont plus restrictives sur les ports sources et destination que les règles globales de suivi de connexion (celles avec ESTABLISHED,RELATED). En effet un reproche qu’on fait souvent au module de suivi de connexion FTP (et aux autres modules de suivi de protocoles complexes en général) est qu’il peut “ouvrir” n’importe quel port défini par le client ou le serveur dans la connexion de commande, contournant les restrictions du jeu de règles.

Pour être plus concret, on peut imaginer les deux exemples suivants.

1. Un faux client FTP se connecte à un faux serveur FTP sur le port 21 (autorisé), et demande une connexion de données FTP en mode actif vers son propre port 139 (netbios, ça fait peur, surtout si c’est Windows). Le module de suivi de connexion FTP va classer la demande de connexion du serveur vers le port 139 du client dans l’état RELATED, et la règle globale de suivi de connexion qui n’a pas de restriction de port va l’accepter.

2. Un faux client FTP se connecte à un faux serveur FTP sur le port 21 (autorisé), et demande une connexion de données FTP en mode passif. Le serveur propose son propre port 139. Le module de suivi de connexion FTP va classer la demande de connexion du client vers le port 139 du serveur dans l’état RELATED, et la règle globale de suivi de connexion qui n’a pas de restriction de port va l’accepter.

Si on veut éviter cela, on ne peut plus se contenter de règles globales pour les paquets RELATED. Il faut écrire des règles spécifiques selon ce qu’on veut laisser passer. Ce n’est en revanche pas nécessaire pour l’état ESTABLISHED.

Ceci étant dit, il convient de relativiser le risque. En effet il faut un faux client FTP dans la place et un faux serveur FTP à l’extérieur pour exploiter la faille. Ben ouais, s’il y a un vrai client ou un vrai serveur, il ne fait que du FTP donc pas de risque à moins d’exploiter une faille existante dans ce programme. Or il serait bien plus simple de remplacer le faux programme FTP par un programme qui se connecte lui-même au port local visé d’une part (le trafic local est rarement filtré) et à une machine distante complice sur un port autorisé quelconque d’autre part, faisant le relais entre les deux.

[guigui69]

Bonjour,

Merci pour les réponses.

voici mon code

####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

J’ai commenter cette ligne:

############iptables -A OUTPUT -p tcp --sport 80 -o $lan -m state --state NEW -j ACCEPT
qui je pense est une erreur.

Autres questions:

• Mon serveur est sur une debian Etch, il va me servir uniquement de pare-feu; proxy; dansguardian. Est-il préférable que je reste sous Etch ou que je upgrade sous lenny?

Merci

guigui69

[PascalHambourg]

Ça a l’air bon cette fois, excepté quelques -dport au lieu de --dport.
La règle avec --sport 80 est effectivement erronée.

- Mon serveur est sur une debian Etch, il va me servir uniquement de pare-feu; proxy; dansguardian. Est-il préférable que je reste sous Etch ou que je upgrade sous lenny?

Il y a un dicton bien connu : “if it ain’t broken, don’t fix it”, qu’on peut traduire approximativement en “tant que ça marche, on n’y touche pas”. Il faut peser les avantages et les inconvénients d’une migration.

Parmi les inconvénients :

• risque de tout casser (faible avec Debian normalement si on suit la procédure)
• nécessité de reprendre la configuration de certains logiciels qui ont changé
• nouveaux bugs (à voir)

Parmi les avantages :

• paquets plus récents corrigeant d’anciens bugs ou apportant de nouvelles fonctionnalités intéressantes (à voir)
• la prise en charge de sécurité pour l’ancienne stable s’arrêtera dans moins d’un an, il faudra donc avoir migré avant de toute façon ; et même avant cela le délai de publication des mises à jour de sécurité des paquets de l’ancienne stable peuvent être plus longs, car plus un paquet est ancien, plus le rétroportage d’un correctif peut être compliqué (cf. par exemple le noyau pour DSA-1809) voire impossible (cf. par exemple BIND 8 pour DSA-1604) à cause de changements majeurs entre les versions.