Reprise du message précédent :

effectivement j'ai _aucune_ requete en v6 dessus  

je comprends rien à ce qui est affiché là  !  

Donc fo ke je fasse:
ipables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --sport 53-m state --state ESTABLISHED -j ACCEPT
 
Idem pour la premiere partie du ftp
 

Ah la la... iptables...
Sans critiquer du tout l'utilisation que vous en faites (je l'utilise aussi sur mes machines, et il marche très bien), j'ai quand même une remarque à faire...
Il y a quelque temps, j'ai essayé OpenBSD, dont le firewall est "pf". J'ai été carrément surpris par la SIMPLICITE de la syntaxe de pf. Elle est tout d'une simplicité incroyable, et pourtant d'une efficacité à toute épreuve.
Oui, je sais, je fais pas avance le schmilblik, mais en tout cas, n'hésitez pas à jetter un coup d'oeil à pf un de ces quatres, ça en vaut carrément la chandelle!

 
bah si tu nous montrais un exmple, on pourrait juger par nous même

Et pour moi c'est ca ou bien ?

tu te casses la tete pour tien
un coup de stateful & on n'en parle plus

non, d'apres moi, et contrairement à ce que dit mikala, il faut utiliser aussi NEW
je dis pas que mikala à tord, c'est juste ce que j'utilise, sans doute à tord, mais je te dis ce que je crois savoir (faudrait tester pour être sur) :

 
et pour le ftp, il faut rajouter RELATED

bah c'est ce qu'il fait là
j'imagine que tu voudrais qu'il fasse ça pour tous les ports ... m'enfin j'espere qu'il fait pas de p2p sinon ça risque d'avoir un peu de mal non ?

bah la regle que je lui est donné était _global_ sur tout le tcp
pourquoi vouloir la préciser sur les ports ?

Nan nan pas de p2p chez moi ok je vais tester ça

 
bah pour pas le faire sur le p2p    
parce que 500 connex à gérer c'est un peu raide ...

 
ah bah alors un stateful global fait très bien l'affaire ... d'ailleurs t'as psa du chercher bcp parce que dans la doc officiel la premiere regle qu'il donne en exemple c'est celle du stateful ...

ba peut etre parce que justement j'ai pas lu la doc officiel sauf la partie traitant de la forme des regles.    
Ba de toute facon ca marche très bien maintenant alors bon v pas m amuser a retourcher l ensemble
 
 

 
Yep... Je prends l'exemple d'une machine avec Zope et SSH ouverts sur le net. La machine se trouvant dans une DMZ. Il faut aussi que la machine puisse récupérer ses updates (via http), et effectuer des résolutions de hostnames. Les règles sont les suivantes:
 
# (déclaration variables $nom_interface_locale,
# $ip_interface_locale, $port_zope et $ip_serveurs_dns)
# règles par défaut:
block in all
block out all
# autoriser le traffic local
pass quick on lo0 all
# traffic entrant vers ssh autorisé
pass in quick on $nom_interface_locale proto tcp from any to $ip_interface_locale port ssh flags S/A modulate state
# traffic entrant vers le port de zope autorisé
pass in quick on $nom_interface_locale proto tcp from any to $ip_interface_locale port $port_zope flags S/SA modulate state
# traffic sortant vers www autorisé
pass out quick on $nom_interface_locale proto tcp from $ip_interface_locale to any port www flags S/SA modulate state
# traffic sortant vers dns autorisé
pass out quick on $nom_interface_locale proto { tcp, udp } from $ip_interface_locale to $ip_serveurs_dns port domain flags S/SA keep state
 
Bon, oki, c'est un exemple simple. Mais je vous évite le script de mon firewall avec ses 6 cartes réseau...  

mouai, un poil plus simple, m'enfin à part que pour certain truc avec iptables, il lui faut plus de ligne pour le décrire, c'est pas flagrant ... c'est un peu kif kif (et je dis ça en tenant compte que je ne connais pas la syntaxe de pf parce que sinon je dirais que c'est incompréhensible de prime abord )

pas mieux
en effet je pense qu'il s'agit avant tout de comprendre comment cela fonctionne & apres on saisit le fonctionnement

 
Oui. Je pense que chacun doit se faire son opinion. iptables et pf sont tout deux d'excellent firewalls.
En ce qui concerne la simplicité de la syntaxe, je t'assure qu'elle est plus simple pour pf que pour iptables. Là, ce n'est pas flagrant sur l'exemple que j'ai donné. Mais sur mon firewall (6 interfaces), où les règles sont nombreuses (script de plusieurs dizaines de ko), on s'en rend compte tout de suite.
Personnellement, je trouve que pf est plus proche du "language humain" que pf. Pour preuve, au début, j'ajoutais avant chaque règle une "traduction" en français de ce qu'elle faisait. J'ai arrêté, car:
- les commentaires étaient 2 fois plus longs que la règle
- la règle est plus compréhensible plus rapidement (et pourtant, mes commentaires sont clairs!)
pf permet aussi de faire des trucs sympas, comme les gateways avec authentification, le CBQ et la prioritisation de paquets (intégré à pf), le "modulate state" (meilleur que le keep state)
 
Surtout, ce que j'apprécie dans pf, est la simplicité des règles de redirection de paquets, nécessaires pour la mise en place d'un firewall protégeant des DMZ. Là, y'a pas photo comparé à iptables.
 
Quoi qu'il en soit, je pense qu'il est quand même nécessaire de tester les 2 firewalls pour se faire une idée.

Tout t'as fait  

 
   
Je t'aide: remplace le second "pf" par "iptables".  
Sinon, le "t'as fais" n'est pas très très français là.
Mais bon, on s'en fout, hardware.fr n'est pas un cours d'orthographe et de grammaire?

  J'avais même pas vu cette faute trop content de faire remarquer la tienne surement  

authentification : c'est possible aussi sous iptables mais effectivement c'est pas forcément très simple niveau syntaxe
cbq est dispo mais pas directement intégré (en même temps ça on s'en fout un peu )
et pour le modulate state, c'est ça qui me semblait pas mal dans ton exemple alors si tu pouvais en dire un peu plus ...
 
bon sinon je suis pas un expert en firewall
moi j'ai fait mes petites règles pépères, hors on connait ce qu'un outil a dans le ventre qu'en en atteignant les limites, ce qui n'est clairement pas mon cas vu mes besoins.
si la syntaxe est plus compliqué sur iptables, je serais tenter de dire que peut-être qu'iptable permet de faire plus de truc, plus modulaire dans les règles ...
si c'est pas le cas (encore une fois c'est pas moi qui pourrait apporter une réponse à ce niveau), c'est simple, iptables n'est qu'un frontend à netfilter et ce qui est sur c'est que netfilter permet autant de chose que sont équivalent sous bsd, donc il suffit de faire ses remarques aux devel d'iptables
en plus iptables n'est qu'un outil, ce qui importe c'est netfilter, mais rien n'empeche de faire un traducteur iptables <-> pf, ça doit être tout à fait possible
bref, vue l'exemple que tu as donné, tu as l'air d'avoir raison (j'avoue que iptables est pas forcément aisé, et la gestion du ftp est un peu bordélique par exemple), mais il ne tient qu'à nous de faire évoluer la chose : développons un traducteur ou soumettons nos remarques aux dev d'iptables (c'est pas comme si on demandait de réécrire netfilter)  

 
Concernant le "modulate state":
Le moteur d'état des paquets utilise soit le keep state soit le modulate state. Le modulate state n'est utilisable que sur les paquets TCP. Avec modulate state, le numéro de séquence des paquets est généré aléatoirement. Ceci permet:
- de réduire les risque de voir quelqu'un "forger" des paquets avec des numéros de séquences de paquets (ISN) prévisibles (ça s'appelle du "blind spoofing" ). Certains OS y sont plus sensibles que d'autres: je vous fais pas un dessin!    
- de donner l'impression qu'il n'y qu'une seule machine derrière la machine effectuant le NAT. En France, cela n'a que peu d'intérêt, mais aux USA, certains ISP (exemple: http://www.comcastonline.com) interdisent l'utilisation du NAT (1 facture=1 connection=1 machine), et vont même jusqu'à traquer les utilisateurs de NAT.
 
Il me semble avoir lu il y a quelques mois que l'auteur d'iptables planifiait de le revoir de fond en combles. Même si iptables fonctionne très bien, à mon avis, il est maintenant temps de le revoir...
Pour information, OpenBSD est très largement utilisé sur les firewalls critiques, quand l'on a pas les moyens de s'acheter des solutions tout prêtes genre Cisco&co (très très cher!). Il manquait encore il y a quelque temps à pf la possiblité de gérer la redondance (un firewall flanche, un autre prend le relais). Je ne sais pas si cela a depuis été incorporé, mais c'est une lacune comme celle-çi qui fait préférer aux entreprises l'achat de solutions "clés en main" (qui ne sont pas spécialement plus simples que pf!)
 
Bref, si vous avez une configuration réseau assez simple (1 ou 2 machines en NAT derrière un firewall), iptables est très bien. Mais franchement, pour les trucs plus sérieux, avec des DMZ et tout un tas de flux de paquets à gérer, franchement, OpenBSD et pf est bien plus adapté. Mes 2 cents...  

Il existe un plutot bon outil qui s'appelle fwbuilder qui est capable de générer les règles pour iptables/netfilter et pf, voire pour les Pix de Cisco (je sais pas où en est leur support exactement) ...

tu parles de ça :

   
le truc qui vaut 1 sur win95
bof, je crois qu'on risque plus grand chose de ce coté quand même, si ?  
 

à oui, j'ai entendu parlé de ça ...
putain c'est naze, s'ils arrivent à en finir avec le warez ils trouveront toujours qq chose à reprocher aux gens ... ils en ont pas marre d'être ridicule    
enfin bref, je crois que les dev de netfilter son sur le coup et qu'ils devraient sortir une parade du même type que celui de pf d'ici quelque temps ... par contre je comprends pas comment ça marche, vu qu'il me semblait que c'est comme ça que la table de forwarding faisait la dif entre les connexions des différentes machines avec ça ....
 

 
 
ok

 
ouai j'ai entendu parler de tout un tas de front end plus ou moins bien fait mais vu que je ne les ai pas utilisé, je préfère m'abstenir d'en parler bien entendu

il me semble bien que grsec incorpore la génération aléatoire des sequences en tcp  

Cui là est pas mal ... je l'ai suivi pendant longtemps et me suis tapé des bugs assez horribles avec lui au début mais là ca va mieux ...

 
bah je sais pas si je confonds avec autres choses mais vu la prédiction qu'il y a sur ma machine, et j'ai pas grsec, je pense que c'est d'origine non ? (j'opte pour la confusion)

 
j'essaierais par curiosité alors

En principe non ... il te faut les patches GRSecurity avec certaines options activées lors de la compil du noyau pour avoir des numéros de séquence aléatoires "à la xxxBSD" ...

 
et c'est quoi la prediction tcp de nmap ?

Me rappelle plus exactement ... la plus emmerdante possible pour lui j'imagine ... ...
 
EDIT : un truc dans le genre impossible quoi ...

 
et ça sort d'épita ...    
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

1/
EPITA, ca s'écrit comme ça déjà ...
Ecole Pour l'Informatique Et les Techniques Avancées ... oui mossieur ...
2/ Ca sort d'EPITA et ca va rentrer se coucher parce que il est naze et demain mise en service grosse VSAT prévue ...
3/ Concernant nmap et la classe de prédiction de la pile TCP/IP des xxxBSD, j'ai la flemme d'allumer un routeur satellite que j'ai sous la main et qui a comme OS embarqué un xxxBSD, justement ... ce sera pour une autre fois ...    
 
   
 
 
 
 
EDIT : Pour un Linux non patché GRSecurity, ca donne ça nmap :

mais y-a pas de dimanche par chez toi ?
tu es toujours en algérie ?

pour l'edit : bah oui voilà, c'est déjà vachement haut sans grsec ...

Le W.E. ici c'est le Jeudi et le Vendredi et aujourd'hui sté férié ... mais qd tu es en train de lancer ta boite, tu comptes plus le temps que tu y passes ...

et ça marche bien ?

Pas mal ... vu qu'on lance (ou sur le point pour certains) des services avec la même qualité qu'en Europe et aux US, Japon, etc ... Comme y'avait pas (avec un service qui tienne la route hein, passke la techno ils connaissaient qd même avant moi   ), ils viennent tous vers nous ...
Je m'amuse comme un petit fou .. j'ai une feuille blanche devant moi et un pays entier pour m'amuser .... juges en : VSAT, Wireless, Fibre Optique, Linux, Sun, M$ ( je sais ), ATM/MPLS, etc ...

en fait ils ont la technique mais ils ont pas d'organisation c'est ça ?
c'est dingue ça ... tu dois bien avoir du boulot pour moi non