Config de mon parefeu

[Berfizan]

Je l'ai passé à la moulinette, il a enlevé tous les LF ( 0D).

 

Je l'ai remis dans /etc et lancé ...Pas de message d'erreur mais plantage complet du routeur..plus d'accès au net, plus d'accès au routeur en telnet, plus d'accès au routeur par IE.

 

Penses-tu que je doive créer le ln et rebooter le routeur pour voir ?

 

Je t'avais posé une question a laquelle tu n'as pas répondu dans un post précédent :

 

berfizan Écrit aujourd'hui à 09h13

 

 

Si je prends l'ensemble du script cela va-t'il remplacer l'intégralité des reglages actuels de mon parefeu ou s'ajouter ? ( car j'ai deja des règles NAT définies que je vourais bien sur conserver. )

.

[Greywolf]

bon, c'était les LF alors.

 

Pour ta question, le script réinitialise en effet toutes les règles préétablies et repart de zero à chaque fois qu'il est lancé.

 

Si le script te plante la connexion (étrange, ça fonctionnait bien chez moi DHCP ethernet et wifi), il ne vaut mieux pas créer le lien qui lancerait le script systématiquement (et donc plus de connexion, plus de telnet, plus rien....).

 

J'ai cru noté que ta version du dwb était plus récente que celle que j'avais (rapport au login/pass de l'invite telnet), peux-tu me donner le résultat de

ifconfig

et

iptables -L

 

pour ta config originale?

 

//les lignes suivantes sont censées permettre un accès total au routeur depuis le LAN, étrange que cela t'ait planté la connexion telnet

#Les connexions entrantes sur l'interface LAN sont autorisees
iptables -A br0-if -p icmp -j icmp-acc
iptables -A br0-if -j ACCEPT

 

Comment as-tu rétabli ta connexion si cela avait planté? reset du routeur?

 

Pour tes règles de NAT, il faudra en effet les recréer/inclure dans le script

[Berfizan]

Bonjour

 

( C'est bien les OD qui ont été enlevés mais c'est CR, erreur de ma part )

 

Suite au plantage, j'ai rétabli par un arrêt/marche.

 

Ifconfig :

 

 

 

iptables

 

 

 

 

EDIT : Du nouveau

 

J'ai "allégé" le script en enlevant touts les lignes vides et les commentaires.

 

J'ai exécuté le script et j'ai attendu environ 5 minutes pour qu'il me rende la main.

 

J'avais de nouveau accès au routeur en telnet et en http.

 

Par contre plus d'accès au net.

 

J'ai fait un iptables -L qui a duré 7 minutes !!

 

 

Ensuite je suis entré dans la config du routeur par http et j'ai remis la config de parefeu via l'interface Web

 

et j'au de nouveau eu accès au WeB

 

le nouveau fichier klb.fw

 

 

#! /bin/sh

#Initialisation des tables

iptables -F

iptables -F INPUT

iptables -F OUTPUT

iptables -F FORWARD

iptables -P INPUT DROP

iptables -P OUTPUT DROP

iptables -P FORWARD DROP

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

iptables -X ppp0-br0

iptables -N ppp0-br0

iptables -X br0-ppp0

iptables -N br0-ppp0

iptables -X icmp-acc

iptables -N icmp-acc

iptables -X log-and-drop

iptables -N log-and-drop

iptables -A log-and-drop -j DROP

iptables -A FORWARD -p tcp --tcp-flags ALL ALL -j log-and-drop

iptables -A FORWARD -p tcp --tcp-flags ALL NONE -j log-and-drop

iptables -A FORWARD -m state --state INVALID -j log-and-drop

iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT

iptables -A FORWARD -i ppp0 -s 224.0.0.0/4 -j log-and-drop

iptables -A FORWARD -i ppp0 -s 192.168.0.0/16 -j log-and-drop

iptables -A FORWARD -i ppp0 -s 10.0.0.0/8 -j log-and-drop

iptables -A FORWARD -i br0 -o ppp0 -j br0-ppp0

iptables -A FORWARD -i ppp0 -o br0 -j ppp0-br0

iptables -A FORWARD -j log-and-drop

iptables -A icmp-acc -j ACCEPT

iptables -A ppp0-br0 -p icmp -j icmp-acc

iptables -A ppp0-br0 -p tcp -m state --state RELATED -j ACCEPT

iptables -A ppp0-br0 -j log-and-drop

iptables -A br0-ppp0 -p udp --dport domain -j ACCEPT

iptables -A br0-ppp0 -p tcp --dport domain -j ACCEPT

iptables -A br0-ppp0 -p tcp --dport smtp -j ACCEPT

iptables -A br0-ppp0 -p tcp --dport 110 -j ACCEPT

iptables -A br0-ppp0 -p tcp -m state --state NEW --dport ftp -j ACCEPT

iptables -A br0-ppp0 -p tcp -m state --state RELATED,ESTABLISHED --dport 1024: -j ACCEPT

iptables -A br0-ppp0 -p tcp --dport www -j ACCEPT

iptables -A br0-ppp0 -s 192.168.1.201 -p tcp -d www.mabanque.fr--dport 443 -j ACCEPT

iptables -A br0-ppp0 -p tcp --dport telnet -j ACCEPT

iptables -A br0-ppp0 -p icmp -j icmp-acc

iptables -A br0-ppp0 -j log-and-drop

iptables -X ppp0-if

iptables -N ppp0-if

iptables -X br0-if

iptables -N br0-if

iptables -A INPUT -i ppp0 -j ppp0-if

iptables -A INPUT -i br0 -j br0-if

iptables -A INPUT -i lo -j ACCEPT

iptables -A OUTPUT -o lo -j ACCEPT

iptables -A OUTPUT -o br0 -j ACCEPT

iptables -A ppp0-if -j log-and-drop

iptables -A br0-if -p icmp -j icmp-acc

iptables -A br0-if -j ACCEPT

echo "1" > /proc/sys/net/ipv4/ip_forward

Modifié le 1 mars 2006 par berfizan

[Greywolf]

alors là... j'en perds mon latin... surtout pour les temps de latence observés.

 

se pourrait-t-il que cette version de DWB ait si peu de place que rajouter un script le perturbe autant?

tu peux me donner le résultat de la commande

df -h

pour visualiser l'espace disque disponible ?

 

Pour l'accès au net qui ne se fait pas, tout est pourtant en place... :-/

 

Si tu as toujours envie de faire des essais, on peut

• logger ce qui ne sort pas en rajoutant cette ligne dans la chaine log-and-drop
  

iptables -A log-and-drop -i br0 -o ppp0 -j LOG

juste avant de les dropper
(ligne iptables -A log-and-drop -j DROP)
et aller voir le fichier /var/log/syslog (ou /root/adsl.log) pour voir si effectivement c'est le pare-feu qui merdoie.
 
Je pense aussi à un problème de MTU (la requête passe mais tu ne reçois pas la réponse); tu peux rajouter cette ligne à la chaine br0-ppp0

iptables -A br0-ppp0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

juste avant la ligne iptables -A br0-ppp0 -p udp --dport domain -j ACCEPT

//tu peux également me confirmer que le routage est bien activé?

cat /proc/sys/net/ipv4/ip_forward 

doit te retourner 1 comme valeur

 

//edit_bis:

je viens de penser à ceci en revérifiant les screenshots: malgré la ligne pour https avec nom de domaine dans le script, la règle n'apparait pas dans la sortie de iptables -L car, je pense, le routeur n'a pas le droit d'interroger des serveurs de noms sur la zone internet => du coup, il pédale dans la choucroute pour interpréter la ligne

Peut-être qu'en rajoutant cette règle dans OUTPUT, cela arrangera les choses:

iptables -A OUTPUT -p udp --dport domain -j ACCEPT 

+ déplacer les règles pour OUTPUT en début de script (avant la série des FORWARD)

 

//edit_ter:

avec le script chargé, arrives-tu à partir d'un des PC à faire une résolution de noms?

nslookup www.zebulon.fr

un ping sur www.zebulon.fr ?

 

//rererere-edit:

Si on veut que le routeur fasse une résolution DNS, il faut accepter le retour de connexion dans INPUT

iptables -A ppp0-if -m state --state ESTABLISHED -j ACCEPT

 

//j'ai refait le script que tu trouveras ici: fw.klb

Modifié le 1 mars 2006 par Greywolf

[Berfizan]

Bonjour et merci encore pour ta patience et ton aide.

 

BRAVO !! Ca marche impec..les adresses https ( j'en ai rajouté une seconde ) sont accessibles et uniquement depuis mon PC.

 

J'ai créé une autre chaine pour un besoin spécfique d'un autre Pc de mon réseau et ça marche également.

 

Pourrais-tu ( encore ) me donner juste un exemple de synthaxe car j'ai besoin de reconstruire des redirections de ports ( NAT ).

 

J'avais une regle qui me dirigeait le port d'entrée du routeur XXXX sur le port NNNN pour l'adresse ip AAA.AAA.AAA.AAA.

 

J'espére etre clair ( ca entrait sur le port externe XXXX , sortait par le port interne NNN et allait sur le PC AAA.AAA.AAA.AAA )

 

Merci encore

Modifié le 1 mars 2006 par berfizan

[Greywolf]

Salut, content que ça marche.

 

Pour la redirection de ports, ça se passe dans la table nat chaine PREROUTING

 

exemple pour le cas d'un serveur web hébergé sur une machine interne d'adressage 192.168.0.3:

iptables -t nat -A PREROUTING -i ppp0 -p tcp -dport www -j DNAT -to-destination 192.168.0.3:80

 

L'adresse de destination du paquet est modifié, il faut ensuite l'autoriser dans la chaine FORWARD de la table filter

iptables -A ppp0-br0 -m state --state NEW -p tcp --dport 80 -d 192.168.0.3 -j ACCEPT

 

www est le port côté WAN (ici 80) et tu indiques le port de redirection avec l'adresse privée (ici c'est aussi 80)

le port à indiquer dans la chaîne FORWARD est celui côté privé.

 

//si tu veux éviter de saturer l'espace disque du routeur, il serait peut-être judicieux d'enlever la règle permettant de logger les paquets sortants; à moins que tu ne fasses un contrôle/effacement régulier du fichier de log ou à moins d'installer un demon syslog sur une de tes machines et de rediriger les logs de iptables vers celle ci. (mais je sais pas si ça existe sous windows)

[Berfizan]

Bonjour

 

Avec l'iptables -L, je ne vois pas de table PREROUTING, ne faut-il pas d'abord la créer ?

[Greywolf]

iptables -L ne liste que les chaines de la table filter

 

pour voir celles de la table nat:

iptables -t nat -L

 

j'avais commencé un topo iptables (plus pour m'amuser avec LateX par ailleurs) mais que je n'ai jamais eu le temps/courage de terminer, si ça t'intéresse de comprendre comment ça marche, c'est par là