Avant tout je voulais savoir si je pouvais me permettre de demander aux
amateurs iptables presents sur cette liste, si ils pouvaient jeter un
coup d'oeil sur mon script firewall.
Avant tout je voulais savoir si je pouvais me permettre de demander aux
amateurs iptables presents sur cette liste, si ils pouvaient jeter un
coup d'oeil sur mon script firewall.
Avant tout je voulais savoir si je pouvais me permettre de demander aux
amateurs iptables presents sur cette liste, si ils pouvaient jeter un
coup d'oeil sur mon script firewall.
Pourquoi pas. S'il est long, tu peux le publier sur un site web et
indiquer l'URL ici. Quelques conseils :
- Attention au formatage, en particulier aux lignes longues que le
logiciel de courrier peut couper en deux, ce qui va gêner la lisibilité.
- Indique le cahier des charges/spécification de ce que le script est
censé faire. Eventuellement des commentaires généreux peuvent suffire.
Pourquoi pas. S'il est long, tu peux le publier sur un site web et
indiquer l'URL ici. Quelques conseils :
- Attention au formatage, en particulier aux lignes longues que le
logiciel de courrier peut couper en deux, ce qui va gêner la lisibilité.
- Indique le cahier des charges/spécification de ce que le script est
censé faire. Eventuellement des commentaires généreux peuvent suffire.
Pourquoi pas. S'il est long, tu peux le publier sur un site web et
indiquer l'URL ici. Quelques conseils :
- Attention au formatage, en particulier aux lignes longues que le
logiciel de courrier peut couper en deux, ce qui va gêner la lisibilité.
- Indique le cahier des charges/spécification de ce que le script est
censé faire. Eventuellement des commentaires généreux peuvent suffire.
Bonjour,
le lien : http://smhteam.info/upload_wiki/firewall.tar.gz
Explications :
C'est le script present sur mon serveur a la maison.
Mon serveur est connecte a Internet via une LiveBox (192.168.1.1) a
partir de eth0 (192.168.1.10) et au lan a partir de eth1 (192.168.0.1).
1/ Les services vu via sont ssh en port knocking et ftp via une
redirection de port (10021 vers 21).
2/ Cote lan, y a du NFS, du serveur web, ftp et ssh je crois que c tout.
3/ Le masquerading est mis en place.
J'avais ete faire un petit tour chez plouf (y a des idees) ! et j ai
reprise l'idee de separer les differentes configurations en fichiers.
Du coup, je me retrouve avec :
- fw_config : me permettant de definir quelques options de configuration
- fw_modules : permettant le chargement des modules iptables
- fw_proc : pour l'initialisation des fichiers presents dans /proc
- un fichier fw_main, fichier principal a lancer au demarrage du serveur
- fw_wan : gerant les regles sur eth0
- fw_lan : gerant les regles pour l'interface du reseau local
- fw_forward_lan : pour la masqueradiing
Y a des commentaires dans le soft.
Autrement, question bonus :)! Quesl sont les types icmps qu'il faudrait
ne pas rejeter pour un bon fonctionnement ?
Bonjour,
le lien : http://smhteam.info/upload_wiki/firewall.tar.gz
Explications :
C'est le script present sur mon serveur a la maison.
Mon serveur est connecte a Internet via une LiveBox (192.168.1.1) a
partir de eth0 (192.168.1.10) et au lan a partir de eth1 (192.168.0.1).
1/ Les services vu via sont ssh en port knocking et ftp via une
redirection de port (10021 vers 21).
2/ Cote lan, y a du NFS, du serveur web, ftp et ssh je crois que c tout.
3/ Le masquerading est mis en place.
J'avais ete faire un petit tour chez plouf (y a des idees) ! et j ai
reprise l'idee de separer les differentes configurations en fichiers.
Du coup, je me retrouve avec :
- fw_config : me permettant de definir quelques options de configuration
- fw_modules : permettant le chargement des modules iptables
- fw_proc : pour l'initialisation des fichiers presents dans /proc
- un fichier fw_main, fichier principal a lancer au demarrage du serveur
- fw_wan : gerant les regles sur eth0
- fw_lan : gerant les regles pour l'interface du reseau local
- fw_forward_lan : pour la masqueradiing
Y a des commentaires dans le soft.
Autrement, question bonus :)! Quesl sont les types icmps qu'il faudrait
ne pas rejeter pour un bon fonctionnement ?
Bonjour,
le lien : http://smhteam.info/upload_wiki/firewall.tar.gz
Explications :
C'est le script present sur mon serveur a la maison.
Mon serveur est connecte a Internet via une LiveBox (192.168.1.1) a
partir de eth0 (192.168.1.10) et au lan a partir de eth1 (192.168.0.1).
1/ Les services vu via sont ssh en port knocking et ftp via une
redirection de port (10021 vers 21).
2/ Cote lan, y a du NFS, du serveur web, ftp et ssh je crois que c tout.
3/ Le masquerading est mis en place.
J'avais ete faire un petit tour chez plouf (y a des idees) ! et j ai
reprise l'idee de separer les differentes configurations en fichiers.
Du coup, je me retrouve avec :
- fw_config : me permettant de definir quelques options de configuration
- fw_modules : permettant le chargement des modules iptables
- fw_proc : pour l'initialisation des fichiers presents dans /proc
- un fichier fw_main, fichier principal a lancer au demarrage du serveur
- fw_wan : gerant les regles sur eth0
- fw_lan : gerant les regles pour l'interface du reseau local
- fw_forward_lan : pour la masqueradiing
Y a des commentaires dans le soft.
Autrement, question bonus :)! Quesl sont les types icmps qu'il faudrait
ne pas rejeter pour un bon fonctionnement ?
Bonjour
Avez-vous essayer le soft FIREWALLBUILDER qui permet de réaliser des
scripts IPTABLES sous une interface Windows.
Personnellement je le trouve très pratique.
Bonjour
Avez-vous essayer le soft FIREWALLBUILDER qui permet de réaliser des
scripts IPTABLES sous une interface Windows.
Personnellement je le trouve très pratique.
Bonjour
Avez-vous essayer le soft FIREWALLBUILDER qui permet de réaliser des
scripts IPTABLES sous une interface Windows.
Personnellement je le trouve très pratique.
le lien : http://smhteam.info/upload_wiki/firewall.tar.gz
Explications :
le lien : http://smhteam.info/upload_wiki/firewall.tar.gz
Explications :
le lien : http://smhteam.info/upload_wiki/firewall.tar.gz
Explications :
le lien : http://smhteam.info/upload_wiki/firewall.tar.gz
Personnellement, je ne suis pas fan du surtraitement en ce qui
concerne les états. Bon point de traiter ce qui est --state NEW, mais
personnellement, je ne ferai pas tout un cinéma avec ce qui est
RELATED et ESTABLISHED (port > 1024 et certains messages ICMP). Cela
peut t'apporter de mauvaises surprises, notamment par exemple les DNS
qui parlent de 53 à 53 ou les serveurs de temps qui parlent de 123 à
123.
Pareil pour le coup de vérifier les TCP flags.
le lien : http://smhteam.info/upload_wiki/firewall.tar.gz
Personnellement, je ne suis pas fan du surtraitement en ce qui
concerne les états. Bon point de traiter ce qui est --state NEW, mais
personnellement, je ne ferai pas tout un cinéma avec ce qui est
RELATED et ESTABLISHED (port > 1024 et certains messages ICMP). Cela
peut t'apporter de mauvaises surprises, notamment par exemple les DNS
qui parlent de 53 à 53 ou les serveurs de temps qui parlent de 123 à
123.
Pareil pour le coup de vérifier les TCP flags.
le lien : http://smhteam.info/upload_wiki/firewall.tar.gz
Personnellement, je ne suis pas fan du surtraitement en ce qui
concerne les états. Bon point de traiter ce qui est --state NEW, mais
personnellement, je ne ferai pas tout un cinéma avec ce qui est
RELATED et ESTABLISHED (port > 1024 et certains messages ICMP). Cela
peut t'apporter de mauvaises surprises, notamment par exemple les DNS
qui parlent de 53 à 53 ou les serveurs de temps qui parlent de 123 à
123.
Pareil pour le coup de vérifier les TCP flags.
Vincent Bernat a écrit :le lien : http://smhteam.info/upload_wiki/firewall.tar.gz
Personnellement, je ne suis pas fan du surtraitement en ce qui
concerne les états. Bon point de traiter ce qui est --state NEW, mais
personnellement, je ne ferai pas tout un cinéma avec ce qui est
RELATED et ESTABLISHED (port > 1024 et certains messages ICMP). Cela
peut t'apporter de mauvaises surprises, notamment par exemple les DNS
qui parlent de 53 à 53 ou les serveurs de temps qui parlent de 123 à
123.
D'accord avec toi au sujet de la limitation des ICMP ESTABLISHED. Si on
en reçoit un c'est qu'on l'a demandé. Par contre j'approuve la
limitation des ICMP RELATED car certains types non indispensables
(Redirect, Source Quench) peuvent servir à des attaques. Concernant la
limitation des ports en RELATED, je ne connais pas d'application qui
utilise des connexions TCP ou UDP RELATED sur des ports privilégiés. En
tout cas ça ne gêne pas les protocoles comme DNS ou NTP qui n'utilisent
que des connexions simples avec des états NEW et ESTABLISHED.Pareil pour le coup de vérifier les TCP flags.
Et certaines combinaisons comme SYN,RST ou SYN,FIN ne sont pas
strictement invalides puisqu'il y a une priorité entre flags. RST ayant
priorité sur SYN, et SYN sur FIN, SYN+RST équivaut à RST et SYN+FIN
équivaut à SYN. Or l'adage dit "Be liberal in what you accept". Les
combinaisons non standard ne peuvent affecter que des piles IP
vulnérables. Ce n'est pas le cas de Linux, mais peut-être de l'OS de
machines qui sont derrière.
Vincent Bernat a écrit :
le lien : http://smhteam.info/upload_wiki/firewall.tar.gz
Personnellement, je ne suis pas fan du surtraitement en ce qui
concerne les états. Bon point de traiter ce qui est --state NEW, mais
personnellement, je ne ferai pas tout un cinéma avec ce qui est
RELATED et ESTABLISHED (port > 1024 et certains messages ICMP). Cela
peut t'apporter de mauvaises surprises, notamment par exemple les DNS
qui parlent de 53 à 53 ou les serveurs de temps qui parlent de 123 à
123.
D'accord avec toi au sujet de la limitation des ICMP ESTABLISHED. Si on
en reçoit un c'est qu'on l'a demandé. Par contre j'approuve la
limitation des ICMP RELATED car certains types non indispensables
(Redirect, Source Quench) peuvent servir à des attaques. Concernant la
limitation des ports en RELATED, je ne connais pas d'application qui
utilise des connexions TCP ou UDP RELATED sur des ports privilégiés. En
tout cas ça ne gêne pas les protocoles comme DNS ou NTP qui n'utilisent
que des connexions simples avec des états NEW et ESTABLISHED.
Pareil pour le coup de vérifier les TCP flags.
Et certaines combinaisons comme SYN,RST ou SYN,FIN ne sont pas
strictement invalides puisqu'il y a une priorité entre flags. RST ayant
priorité sur SYN, et SYN sur FIN, SYN+RST équivaut à RST et SYN+FIN
équivaut à SYN. Or l'adage dit "Be liberal in what you accept". Les
combinaisons non standard ne peuvent affecter que des piles IP
vulnérables. Ce n'est pas le cas de Linux, mais peut-être de l'OS de
machines qui sont derrière.
Vincent Bernat a écrit :le lien : http://smhteam.info/upload_wiki/firewall.tar.gz
Personnellement, je ne suis pas fan du surtraitement en ce qui
concerne les états. Bon point de traiter ce qui est --state NEW, mais
personnellement, je ne ferai pas tout un cinéma avec ce qui est
RELATED et ESTABLISHED (port > 1024 et certains messages ICMP). Cela
peut t'apporter de mauvaises surprises, notamment par exemple les DNS
qui parlent de 53 à 53 ou les serveurs de temps qui parlent de 123 à
123.
D'accord avec toi au sujet de la limitation des ICMP ESTABLISHED. Si on
en reçoit un c'est qu'on l'a demandé. Par contre j'approuve la
limitation des ICMP RELATED car certains types non indispensables
(Redirect, Source Quench) peuvent servir à des attaques. Concernant la
limitation des ports en RELATED, je ne connais pas d'application qui
utilise des connexions TCP ou UDP RELATED sur des ports privilégiés. En
tout cas ça ne gêne pas les protocoles comme DNS ou NTP qui n'utilisent
que des connexions simples avec des états NEW et ESTABLISHED.Pareil pour le coup de vérifier les TCP flags.
Et certaines combinaisons comme SYN,RST ou SYN,FIN ne sont pas
strictement invalides puisqu'il y a une priorité entre flags. RST ayant
priorité sur SYN, et SYN sur FIN, SYN+RST équivaut à RST et SYN+FIN
équivaut à SYN. Or l'adage dit "Be liberal in what you accept". Les
combinaisons non standard ne peuvent affecter que des piles IP
vulnérables. Ce n'est pas le cas de Linux, mais peut-être de l'OS de
machines qui sont derrière.
Quant aux types ICMP consideres comme RELATED, la je trouve que cela se
complique. Il y a ce qui est appele les blind icmp attacks. Le type
source quench est utilise pour ralentir les connexions, de meme, les
protocol unreachable, port unreachable, et fragmentation needed peuvent
couper une connexion.
http://kerneltrap.org/node/5382
Quant aux types ICMP consideres comme RELATED, la je trouve que cela se
complique. Il y a ce qui est appele les blind icmp attacks. Le type
source quench est utilise pour ralentir les connexions, de meme, les
protocol unreachable, port unreachable, et fragmentation needed peuvent
couper une connexion.
http://kerneltrap.org/node/5382
Quant aux types ICMP consideres comme RELATED, la je trouve que cela se
complique. Il y a ce qui est appele les blind icmp attacks. Le type
source quench est utilise pour ralentir les connexions, de meme, les
protocol unreachable, port unreachable, et fragmentation needed peuvent
couper une connexion.
http://kerneltrap.org/node/5382
OoO En cette fin de matinée radieuse du dimanche 28 janvier 2007, vers
11:16, franck disait:
fragmentation needed doivent venir avec un fragment du paquet
original, ce qui permet de vérifier "l'authenticité" du paquet. Ce
fragment est peut-être vérifié (à voir). Si c'est le cas, les règles
sont inutiles : si un attaquant peut intercepter tes paquets, il a
d'autres moyens plus simples de couper ta connexion :)http://kerneltrap.org/node/5382
A priori, ce n'est donc pas supporté ou alors, récemment.
OoO En cette fin de matinée radieuse du dimanche 28 janvier 2007, vers
11:16, franck <joncourt_franck@yahoo.co.uk> disait:
fragmentation needed doivent venir avec un fragment du paquet
original, ce qui permet de vérifier "l'authenticité" du paquet. Ce
fragment est peut-être vérifié (à voir). Si c'est le cas, les règles
sont inutiles : si un attaquant peut intercepter tes paquets, il a
d'autres moyens plus simples de couper ta connexion :)
http://kerneltrap.org/node/5382
A priori, ce n'est donc pas supporté ou alors, récemment.
OoO En cette fin de matinée radieuse du dimanche 28 janvier 2007, vers
11:16, franck disait:
fragmentation needed doivent venir avec un fragment du paquet
original, ce qui permet de vérifier "l'authenticité" du paquet. Ce
fragment est peut-être vérifié (à voir). Si c'est le cas, les règles
sont inutiles : si un attaquant peut intercepter tes paquets, il a
d'autres moyens plus simples de couper ta connexion :)http://kerneltrap.org/node/5382
A priori, ce n'est donc pas supporté ou alors, récemment.
Quant aux types ICMP consideres comme RELATED, la je trouve que cela se
complique. Il y a ce qui est appele les blind icmp attacks. Le type
source quench est utilise pour ralentir les connexions,
de meme, les
protocol unreachable, port unreachable, et fragmentation needed peuvent
couper une connexion.
Du coup, je ne c'est plus trop comment faire. On ne peut pas interdire
tous les types ICMP.
Pour ce qui est des combinaisons pour les TCP flags, je vous laisse tous
les deux juges ; je ne m'y connais pas assez.
Quant aux types ICMP consideres comme RELATED, la je trouve que cela se
complique. Il y a ce qui est appele les blind icmp attacks. Le type
source quench est utilise pour ralentir les connexions,
de meme, les
protocol unreachable, port unreachable, et fragmentation needed peuvent
couper une connexion.
Du coup, je ne c'est plus trop comment faire. On ne peut pas interdire
tous les types ICMP.
Pour ce qui est des combinaisons pour les TCP flags, je vous laisse tous
les deux juges ; je ne m'y connais pas assez.
Quant aux types ICMP consideres comme RELATED, la je trouve que cela se
complique. Il y a ce qui est appele les blind icmp attacks. Le type
source quench est utilise pour ralentir les connexions,
de meme, les
protocol unreachable, port unreachable, et fragmentation needed peuvent
couper une connexion.
Du coup, je ne c'est plus trop comment faire. On ne peut pas interdire
tous les types ICMP.
Pour ce qui est des combinaisons pour les TCP flags, je vous laisse tous
les deux juges ; je ne m'y connais pas assez.
