You are not logged in.
Bonjour,
voila j'ai un routeur WRT54GL, donc qui a une base linux et la possibilité de faire du iptables.
Ma question est simple : Qu'est ce qui ne vas pas dans ma conf d'iptables ?
Voici mes règles de pare feu dans l'ordre dans lequel je les ai tapées :
iptables -F
iptables -X
iptables -N limite
iptables -F limite
iptables -A limite -p tcp --dport 2222 -m limit --limit 3/min --limit-burst 3 -j ACCEPT
iptables -A limite -p tcp --dport 443 -m limit --limit 3/min --limit-burst 3 -j ACCEPT
iptables -A limite -p ICMP --icmp-type echo-request -m limit --limit 3/sec -j ACCEPT
iptables -A limite -p ! ICMP -j LOG --log-prefix " Connection dropper!! "
iptables -A limite -p tcp -j REJECT --reject-with tcp-reset
iptables -A limite -p udp -j REJECT --reject-with icmp-port-unreachable
iptables -A limite -j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p ICMP --icmp-type echo-request -j limite
iptables -A INPUT -p tcp --dport 2222 -m state --state NEW -j limite
iptables -A INPUT -p tcp --dport 443 -m state --state NEW -j limite
iptables -P INPUT DROP
Il doit me manquer quelque chose mais je n'arrive pas à mettre le doigt dessus....
Pour moi je créer une nouvelle chaine "limite" que je créer pour éviter toutes attaques de type brute force sur mon port 2222 et 443 qui sont les port d'administration de mon routeur. Cette règles prend aussi en compte le flood d'ICMP... Je verrais plus tard, une fois ce problème régler pour filtrer les paquets syn.
Quand je met en places ces règles (via SSH sur mon routeur) j'ai de gros problème de réseau. Il devient parfois impossible de joindre le routeur. Donc ma connection SSH plante parfois, ou il y a un temps de latence énorme... L'accès au WAN est quasi impossible, je crois que j'allais plus vite avec mon modem 56kbps....
Si quelqun voit une erreur dans ma configuraion je lui serai reconnaissant de m'en faire part par email, MP, ou répondre à ce post.
Pensez vous que ce genre de règle peut faire crashé le routeur ? Je veux dire, pensez vous que le fait qu'il doivent analyser tout le traffic IN/OUT, le routeur a du mal a tout faire un meme temps d'ou les latences dans le LAN et/ou vers la WAN ?
Merci @ tous,
Bonne journée.
Offline
Hello,
Je ne vois pas d'erreur flagrante; la perf ne devrait pas etre un probleme, parce que le NAT (si tu en as) impose deja l'inspection de chaque paquet et le tracking des connexions, qu'il y ait filtrage ou pas.
Un probleme potentiel est que tu refuses tout le reste du traffic a destination du routeur, ce qui inclut les requetes dhcp, et les requetes dns si tu utilises un tool comme dnsmasq.
Tu pourrais supprimer le reject par defaut a la fin de la chaine input, ca permettrait de voir si le probleme vient du limiteur ou du reste du traffic bloque.
Offline
Bonjour BOFH,
tout d'abord merci d'avoir répondu à mon post.
Alors oui je fais du NAT, je n'y ai pas touché, mais par défaut il y a du NAT car j'utilise plusieurs PC en wifi en quand les règles de pare feu ne sont pas mise je surf très bien !
Je ne vois pas comment je pourrai refusé tout le reste du traffic. Il est vrai que j'ai mis un politique de "dropper" les packet en INPUT, mais j'accept les packet dont la connection est déjà ESTABLISHED ou RELATED...
Côté OUTPUT et FORWARD, je suis en policy ACCEPT, et j'ai rajouter aucunes règles. Donc techniquement en output, n'importe qui depuis mon LAN peut sortir, la pare feu ne bloquera pas le retour car la connection sera ESTABLISHED.. Je ne vois pas de pb la dessus...
Par contre, en effet, j'utilise DNSmasq, il y était par défaut je n'y ai pas touché car je surfait tres bien avant de faire la conf du pare feu.. J'ai bien pensé au DNS, mais partant du principe qu'en OUTPUT tout en ouvert... Je ne vois pas pourquoi le port 63 sera bloqué sur le retour alors que les connection ESTABLISHED sont accepté aussi bien les paquets TCP et UDP (enfin je pense) vu que j'ai pas préciser le typé de protocole, par défaut iptables considère qu'il laisse passer le traffic TCP et UDP...
Je vais essayé de retirer la politique par défaut de DROPPER les paquets, si le traffic passe, c'est que j'ai oublié de préciser d'ouvrir certain port... DNS et DHCP alors ?
Peux tu m'expliquer rapidement pourquoi le DHCP doit etre controler par le FW ? Je veux dire, pour moi le DHCP n'est qu'en interne (coté LAN) le routeur pare-feu ne fait pas de requete DHCP vers l'extérieur si ? Depuis l'extérieur, je suis en IP fixe il me smble... Je suis chez FREE en dégroupé total... Depuis que je suis chez eux (env. 1 semaine mon IP publique n'a pas changé). Après je ne connais pas la durée de leur bail mais bon...
En tout cas merci de ton aide, je reviens vers toi plus tard dans la journée une fois le test fait au niveau de la politique de la chaine INPUT.
D'après ce j'ai compris, si ca fonctionne, il suffirait ensuite d'ajouter des règles dans la chaine INPUT pour accepter le DHCP et DNS c'est bien ca ?
Merci d'avance !
Offline
Hello,
Tes règles iptables dans INPUT ne spécifient ni adresse de destination, ni interface source, donc par défaut elles s'appliquent a toutes les interfaces, c'est a dire également le traffic du lan vers le routeur.
Tu n'indiques pas la topologie de ton réseau, mais DNSMasq fait serveur DHCP pour les clients du lan, et également serveur DNS (il forwarde les requêtes au DNS de ton ISP mais peut en passant ajouter des noms locaux ou autres trucs rigolos). Une requête DNS d'un client vers ton routeur sera vue comme une nouvelle connexion, et RELATED/ESTABLISHED ne la laissera pas passer.
Effectivement, une autre solution serait d'ajouter "-i ppp0" (ou tout autre interface wan) pour que les règles s'appliquent seulement à celles-ci.
PS: dns est udp/53, pas 63
Offline
Hello,
Merci de ta réponse rapide. Je suis toujours coincé au bureau je reviendrai vers toi un peu plus tard dans la soirée pour te dire ce qu'en sont les tests.
Donc si je comprends bien ce que tu m'explique, DNSmasq est un serveur DNS/DHCP côté LAN pour mes clients. La dessus ok je comprends. Ma requêtes DNS d'un client vers mon routeur sera vu comme nouvelles requetes, donc ma règle dans la chaine INPUT ne laissera pas passer le paquet car ce paquets sera considérer comme NEW. Ok je comprends, c'est logique dis comme ca.
Je pensais que la chaine INPUT appliquer les règles seulement sur l'interface WAN. Ici par défaut sur mon routeur est sur l'interface Vlan1 pour le WAN. Donc si je comprends ce que tu me dis, le plus simple serait de garder mes règles écrites plus haut en précisant EN PLUS que ces règles ne s'effectuent seulement pour l'interface VLAN1. C'est bien ca ?
Donc il suffirait de rajouter -i vlan1 sur toutes mes règles pour que cela fonctionne. Quand je dis tout, je comprends donc ma nouvelles chaîne "limite".
Concernant le DNS tu as a raison, c'est bien de l'UDP sur le port 53... aller, on va mettre ca sur le compte de la fatigue :p
Merci de ton aide
Last edited by rat9361 (23 Dec 2010 12:17:46)
Offline
Bonjour,
Concernant mes règles, tout se passe bien jusqu'a ce que je mette la politique DROP en INPUT malgrès que j'ai ajouter -i vlan1 sur toutes mes règles. Donc ce n'est pas mon limiteur mais bien le reste du traffic bloquant....
Aller savoir pourquoi, mon wireshark hier a refuser de reconnaitre mon interface réseau, donc impossible d'analyser les trames pour voir ou ca plante.
Sinon mes règles fontionne quand meme, par exemple hier quand j'ai écrit mes règles j'étais connecté à mon GMAIL est malgrès le DROP je pouvais accéder à mes autres mails.. J'en ai conclu que mes régles RELATED/ESTABLISHED fonctionner bien. J'ai donc fermé mon browser et je l'ai ré-ouvert, et la plus rien... Impossible de me connecter au WAN, connection SSH perdu avec mon routeur, le DHCP est bloqué, impossible de récup un IP LAN...
Ce soir je vais donc refaire mon iptables mais avant de faire "iptables -P INPUT DROP"
je vais ajouter ces 2 lignes :
iptables -A INPUT -p tcp --dport 67 -j ACCEPT -i vlan1
iptables -A INPUT -p udp --dport 53 -j ACCEPT -i vlan1
Avec ces règles, le DHCP pourra communiquer et le DNS aussi, donc pas de problème pour le surf logiquement..
BOFH, si tu me lis encore, dis moi si je ne raconte pas de bêtises et encore merci pour ton aide.
Offline
Hello,
Ahoui, j'ai oublié de préciser que l'option -i ne marche pas pour la policy (-P). Pour le reste, toutes tes hypothèses sont correctes.
Une autre possibilité, peut-être plus simple, serait de rajouter
iptables -A INPUT -i eth0 -j ACCEPT
au tout début. C'est une question de goût. Pour faire plus propre tu pourrais aussi créer d'autres chaines intermédiaires, p.ex. input_lan et input_wan, pour séparer les règles. Tu peux tester l'interface une fois dans INPUT et sauter vers la chaine appropriée, et les remplir avec les règles adéquates.
C'est aussi très courant de toujours laisser ESTABLISHED/RELATED tout au début de input, et d'ajouter un drop/reject pour --state INVALID juste après; le seul état possible pour les règles restantes est donc NEW, et ce n'est plus la peine de le tester systématiquement.
Pour aider au debug des règles, sur les distros récentes il y a la cible TRACE qui indique le détail des règles traversées par chaque paquet (c'est vite bruyant), moins violent il y a l'insertion de LOGs aux points stratégiques, et pour évaluer rapidement la situation les compteurs de paquets (iptables -vL chaine) sont assez utiles également.
Offline
Hey,
Merci pour ta réponse et ton aide apporté.
Je vais dans un premier temps essayer de faire comme j'ai dit dans mon post précédent, juste pour voir si ces règles fonctionnent et ensuite je verrais pour faire quelque chose de plus propre en effet.
Comme tu le dis, créer des nouvelles chaines input_lan et input_wan est une très bonnes idées pour moi. En revanche, je n'ai pas compris pourquoi il faudrait que je mette ta commande :
iptables -A INPUT -i vlan1 -j ACCEPT au tout début. N'importe quel pare feu lit les règles de haut en bas. Si la 1er est accepter tout le traffic arrivant sur l'interface WAN, tous les paquets vont passer rendant donc mes règles de filtrage derrière inutile, non ?
Concernant les chaine intermédiaires, est-il possible de préciser sur quel interface on agit ? Je veux dire, si je créer une chaine input_lan via la commande :
iptables -N input_lan
est-il possible de rajouter -i br0:0 en plus sur cette commande de manière a ce que de façon implicite toutes les regles dans la chaine input_lan "matcheront" une seul interface, ici br0:0 qui correspond a mon interface LAN ?
Et pour tout ce que tu me donne comme conseil, tu considère que la policy de INPUT est DROP ou ACCEPT ?
Concernant le debugging, je ne crois pas avoir TRACE sur mon routeur linksys, mais je peux toujours logger le traffic que je désire et puis tcpdump coté client pourra aussi m'être utile.
Sachant que les règles que j'ai créer ne servent que de teste et me permettent une meilleur compréhension de la fonction d'iptables.
D'ici quelques semaines je passerai en mode "production" car si ces règles là sont seulement pour sécurisé un peu mon routeur, sur du long terme j'aurai un NAS qui sera accessible depuis l'extérieur que je mettrai surement en DMZ.... Je verrais comment sécurisé tout ca un plus tard car le NAS sera serveur WEB/FTP.
Je te redemanderai surement tes conseils d'ici la, si ca ne te dérange pas ?
Bonne journée à toi
Offline
Hello,
rat9361 wrote:
En revanche, je n'ai pas compris pourquoi il faudrait que je mette ta commande :
iptables -A INPUT -i vlan1 -j ACCEPT au tout début.
Il faut évidemment mettre l'interface qui correspond au lan, pas au wan.
il possible de préciser sur quel interface on agit ? Je veux dire, si je créer une chaine input_lan via la commande :
iptables -N input_lan
est-il possible de rajouter -i br0:0 en plus sur cette commande de manière a ce que de façon implicite toutes les regles dans la chaine input_lan "matcheront" une seul interface, ici br0:0 qui correspond a mon interface LAN ?
Il faut mettre la condition au moment ou on entre dedans:
iptables -A INPUT -i br0:0 -j input_lan
iptables -A INPUT -i vlan1 -j input_wan
etc etc
Et pour tout ce que tu me donne comme conseil, tu considère que la policy de INPUT est DROP ou ACCEPT ?
drop, mais pour diverses raisons on préfère en général ignorer la policy (ou toujours la mettre sur drop) et utiliser une règle par défaut a la fin de la chaine. C'est aussi une question de goût.
N'hésite pas si tu as d'autres questions; il y a aussi une référence pas mal en français, ici:
http://www.linux-france.org/prj/inetdoc … -tutorial/
Offline
Ok, alors comme j'ai dit plus, je vais testé seulement d'ouvrir les ports DHCP et DNS dans un premier temps voir ce que ca donne.
Ensuite je vais essayer de faire ce que tu me conseil et qui me parait être un choix très judicieux :
iptables -A INPUT -i br0:0 -j ACCEPT
Avec cette commande au moins coté LAN je ne suis pas embêté avec le DHCP/DNS.
Quand tu dis :
"Il faut mettre la condition au moment ou on entre dedans:"
Que veux tu dire par "au moment ou je rentre dedans"... Désolé je suis peut être fatigué mais je n'arrive pas à te suivre...
A la fin tu me dis que pour une question de goût on utilise à la fin une regle par défaut à la fin de la chaine. Donc si l'on prend l'exemple de l'INPUT policy DROP, a la fin tu mettrais quelque chose comme :
iptables -A INPUT -j ACCEPT
Ais-je bien compris ?
je suis désolé je dois passer pour un boulet je n'ai pas eu le temps de lire la doc sur le lien que tu m'as donnée qui est très exhaustive. Je pense qu'on pourrait appeler ca "la bible iptables" :p Meme le man n'est pas aussi complet et concis.
Merci encore pour ton aide précieuse.
Quentin
Offline
J'ai aussi un router WRT54GL sur lequel j'ai installé OpenWRT. Je sais pas si c'est ton cas.
Pour la configuration, OpenWRT utilise UCI (Unified Configuration Interface), qui dispose de ses propres fichiers de configuration.
Est-ce que tu aurais UCI ou un mécanisme similaire qui surchargerait tes règles iptable ?
CRL
Offline
Bonjour crl,
Je n'ai pas installer OpenWRT mais DD WRT donc je peux pas vraiment t'aider. Je ne pense pas avoir de surcharge maintenant que mes règles de pare feu sont faites correctements.
Maintenant que mes règles sont en place, il n'y a pas de surchage du tout, le processeur tourne a 10-15%... Autant dire que c'est pas la surchage pour lui
BOFH, Merci pour ton aide, entre toi et le lien que tu m'as donnée j'ai finalement réussi a faire ce que je voulais pour le moment. En utilisant les règles dans l'INPUT pour le DNS et DHCP, je n'arrivait pas a surfer.. tcpdump ne m'as pas donnée assez d'info, wireshark toujours au abonné absent hier...
J'ai donc fait un ACCEPT sur l'interface LAN comme premiere règles puis j'ai ajouter les autres règles cité plus haut et la ca marche niquel.
Maintenant dans l'optique d'ouvrir certain port de mon NAS, en particulier le 443, 20-21, as tu une vision des choses précises sur comment faire mes règles ?
Dans l'idéal, j'aurais voulu mettre mon NAS dans une DMZ et ouvrir les port FTP et HTTPS pour que le WAN puisse taper dessus. Je suppose que cela inclut des règles dans l'INPUT pour accepter les connection entrant sur ces 3 ports mais aussi du NAT non ?
Ou est-il possible de créer des règles pour fonctionner comme des zones, comme un pare feu Juniper par exemple. C'est à dire que je pourrai donc faire quelque chose de vraiment propre pour mes régles et faire qqchose comme :
LAN -> LAN
LAN -> DMZ
LAN -> WAN
idem pour DMZ -> LAN DMZ -> WAN.... Je pense que tu as compris. Est-il possible de faire ce genre de chose avec iptables ? Si oui pourrais tu me donner la démarche/logique iptables ?
Merci à toi
Quentin
Offline
rat9361 wrote:
Maintenant que mes règles sont en place, il n'y a pas de surchage du tout, le processeur tourne a 10-15%... Autant dire que c'est pas la surchage pour lui
Quand je parlais de surcharge, je pensais pas à la charge du processeur.
J'ai pensé qu'il y avait une interface de configuration au dessus d'IPtable. Sous openwrt il y a UCI ou l'accès par le web. Cette interface aurait pu générer ses propres règles de filtrage au dessus des tiennes.
Content que ça marche pour toi.
Cyril
Offline
aah désolé je n'avais pas compris ca dans ce sens.
Non avec DD WRT via le GUI il y a quelques possibilités de modifier le pare feu mais c'est assez pauvre. Après il est peut etre possible de faire des lignes de commandes via le GUI et mettre des CRON.
Je n'ai pas encore saisie comment mon routeur marche complétement. Mais pour répondre a ta question, non il est n'y a pas d'outils direct pour créer les regles.. Après j'ai vu avec FirewallBuilder qui peux créer tes règles de facon précise mais je n'ai pas réussi a upper quoi que se soit sur mon WRT.
@+
Offline