bonjour a tous
J ai besoin d'aide pour eclaircir quelques points
En effet, j'ai installé la 1.4b3 sur un p2-266/80Mo/HD525Mo, alleché par l idee de pouvoir
monter un firewall materiel, moins vulnerable qu'un logiciel de poste de travail
Je me suis apercu que les regles par defaut n'etaient pas suffisantes pour mes tendances
paranoiaques et donc qu il allait falloir mettre "les mains dans le camboui".
C est donc avec un brin d'apprehenssion que je me suis lancé sur le petit chemin
caillouteux de la ligne de commande linux
Apres "un peu" de lecture et 1 semaine de plage histoire de digerer tout ca,
j'ai effectué quelques modifs avant de passer en "tout refuser par defaut":
etc/rc.d/rc.firewall.local
1
---------------------------------------------------------------------------------
J ai cru comprendre qu une regle dans la chaine POSTROUTING excluait les paquets avant que ceux ci
n atteignent le kernel donc limitation du spoofing sur eth1=red (une seule regle pour l exemple):
/sbin/iptables -t nat -A CUSTOMPREROUTING -i eth1 -s 10.0.0.0/8 -j DROP
Cela vous parait il correct?
2
--------------------------------------------------------------------------------
# regle inseree au debut de la chaine NEWNOTSYN pour contourner "-I NEWNOTSYN -j DROP"
# car probleme avec une application
#-I pour inserer en premier, car rc.firewall.local executé aprés rc.firewall
/sbin/iptables -I NEWNOTSYN -p tcp -s 192.168.0.10 --sport 7000 -j ACCEPT
/sbin/iptables -I NEWNOTSYN -p tcp -d 192.168.0.10 --dport 7000 -j ACCEPT
Le logiciel fonctionne apres ces changements (il y a en realité plusieurs ports mais les regles sont du meme type)
"dixit Christian Caleca:
ACCEPT
Les paquets qui satisfont aux critères sont acceptés, ils continuent leur chemin dans la pile"
la chaine NEWNOTSYN etant la cible de la chaine BADTCP, elle meme la cible des chaines INPUT
et surtout FORWARD:
le paquet va "rejoindre" POSTROUTING.
si je ne me trompe pas, le paquet ne vas pas etre correctement analysé.
Quelqu'un pourrait il verifier mon raisonnement SVP?
j aimerais pouvoir ne faire "sauter" que la regle NEWNOTSYN -j DROP a ces paquets
tout en etant sur que ceux ci passent bien par les autres
regles de controle.
Y a t il moyen de faire "sauter" une regle a certains paquets?
Merci d'avance
-------------------------------------------------------------------------------------------------------------
"vi est le petit caillou dans la chaussure du pelerin" -Jesus-
[Resolu] NEWBIE:Cheminement d'un paquet
Modérateur: modos Ixus
8 messages
• Page 1 sur 1
[Resolu] NEWBIE:Cheminement d'un paquet
par Chikouille » 11 Août 2004 00:03
Dernière édition par Chikouille le 13 Août 2004 02:34, édité 1 fois au total.
-
Chikouille - Second Maître
- Messages: 42
- Inscrit le: 10 Juin 2004 13:59
par Franck78 » 11 Août 2004 22:30
eh bien toi au moins tu as fait l'effort de lire et digérer pas mal de chose 
Tes questions restent cependant encore assez obscures...
D'abord une remarque : pourquoi un b3 à l'heure de la 1.4b8 ???
PREROUTING POSTROUTING, c'est pour bidouiller les adresses IP pour rester simple. En particulier le NAT.Comme ça ils prendront le bon chemin dans le firewall.
"Avant que ceux ci n'atteignent le kernel" : n'a pas vraiment de sens...
Ils peuvent aussi bien atteindre une autre interface !
Oui la régle est bonne si l'intention est de jeter les paquets avec adresse source 10.0.0.0/8
??????????
A partir du moment ou tu décides qu'il est bon pourquoi tu veux encore l'analyser(vérifier) ?
Inserer dans NEWNOTSYN / BADTCP etc... est une BAD idea ! Le but de ces chaines est de vérifier la validité du paquet (pas malformé).
C'est dans CUSTOMFORWARD/INPUT que tu ajoutes tes paquets acceptés.
Et en général une application n'écoute pas et ne réponds pas sur le même port. Donc le --sport --dport 7000 ne chagrinne. (Je dis bien en général). En plus il n'y a pas besoin d'ouvrir pour la réponse. Iptables le fait seul.
-j RETURN pour les paquets qui satisfont à ton critère 'de sautage', insérée au début de la chaine.
Tes questions restent cependant encore assez obscures...
D'abord une remarque : pourquoi un b3 à l'heure de la 1.4b8 ???
1
---------------------------------------------------------------------------------
J ai cru comprendre qu une regle dans la chaine PRE=>POSTROUTING excluait les paquets avant que ceux ci
n atteignent le kernel donc limitation du spoofing sur eth1=red (une seule regle pour l exemple):
/sbin/iptables -t nat -A CUSTOMPREROUTING -i eth1 -s 10.0.0.0/8 -j DROP
Cela vous parait il correct?
PREROUTING POSTROUTING, c'est pour bidouiller les adresses IP pour rester simple. En particulier le NAT.Comme ça ils prendront le bon chemin dans le firewall.
"Avant que ceux ci n'atteignent le kernel" : n'a pas vraiment de sens...
Ils peuvent aussi bien atteindre une autre interface !
Oui la régle est bonne si l'intention est de jeter les paquets avec adresse source 10.0.0.0/8
2
--------------------------------------------------------------------------------
# regle inseree au debut de la chaine NEWNOTSYN pour contourner "-I NEWNOTSYN -j DROP"
# car probleme avec une application
#-I pour inserer en premier, car rc.firewall.local executé aprés rc.firewall
/sbin/iptables -I NEWNOTSYN -p tcp -s 192.168.0.10 --sport 7000 -j ACCEPT
/sbin/iptables -I NEWNOTSYN -p tcp -d 192.168.0.10 --dport 7000 -j ACCEPT
la chaine NEWNOTSYN etant la cible de la chaine BADTCP, elle meme la cible des chaines INPUT
et surtout FORWARD:
le paquet va "rejoindre" POSTROUTING.
si je ne me trompe pas, le paquet ne vas pas etre correctement analysé.
Quelqu'un pourrait il verifier mon raisonnement SVP?
??????????
A partir du moment ou tu décides qu'il est bon pourquoi tu veux encore l'analyser(vérifier) ?
Inserer dans NEWNOTSYN / BADTCP etc... est une BAD idea ! Le but de ces chaines est de vérifier la validité du paquet (pas malformé).
C'est dans CUSTOMFORWARD/INPUT que tu ajoutes tes paquets acceptés.
Et en général une application n'écoute pas et ne réponds pas sur le même port. Donc le --sport --dport 7000 ne chagrinne. (Je dis bien en général). En plus il n'y a pas besoin d'ouvrir pour la réponse. Iptables le fait seul.
j aimerais pouvoir ne faire "sauter" que la regle NEWNOTSYN -j DROP a ces paquets
tout en etant sur que ceux ci passent bien par les autres
regles de controle.
Y a t il moyen de faire "sauter" une regle a certains paquets?
-j RETURN pour les paquets qui satisfont à ton critère 'de sautage', insérée au début de la chaine.
-
Franck78 - Amiral
- Messages: 5625
- Inscrit le: 20 Fév 2004 01:00
- Localisation: Paris
par Chikouille » 12 Août 2004 02:48
Waouuu, mes questions sont obscures mais tes reponses sont claires et je t'en remercie.
La 1.4b3 sortait lorsque j'ai decidé de tenter l'aventure et pour l'instant, ca me suffit pour faire des essais.
Peut etre qu'en lisant les changelogs, je trouverais des raisons de changer avant le finale.
ok pour le kernel, je ne savais pas trop de quoi je parlais. L'idee etait juste de supprimer "en amont" les paquets que l'on est certain de refuser.
ok pour le port 7000, il n'est qu'un port de "destination" (cf Logs), et il est effectivement inutile d'autoriser la sortie (quelle buse!!)
Pour ce qui est de la regle NEWNOTSYN, je suis parfaitement conscient qu'il n'est pas conseillé d'inserer des regles dans de telles chaines mais c'est la seule solution que j'ai pu envisager. Une simple regle dans CUSTMFRWD n'aurait a mon sens pas evité le rejet de ce paquet "invalide" pour Ipcop
Je veux ces paquets, qui semblent essentiels, mais je voudrais qu'ils passent le reste des tests car je n'ai pas totalement confiance en ce traffic (pitoupi).
Les autres tests pourraient peut etre detecter quelque malformation mais je peut me tromper car je n ai pas encore decortiqué toutes les regles.
La cible RETURN, si je comprend bien, vas retourner le paquet a l'endroit ou il a quitté la chaine precedente.Vais aller potasser...
Merci Franck78 pour ces infos car j'aurais pu mieux RTFM mais au debut c'est dur de s'auto-corriger, de chercher dans les forums des notions que l'on decouvre ou des reponses a des questions un peu particulieres. (j'ai meme eu peur de ne pas avoir de reponse, le flip!!)
J'aime Ixus!! a+
ps: doit je editer ce poste pour le marquer [resolu] puisque c'est le cas?
La 1.4b3 sortait lorsque j'ai decidé de tenter l'aventure et pour l'instant, ca me suffit pour faire des essais.
Peut etre qu'en lisant les changelogs, je trouverais des raisons de changer avant le finale.
"Avant que ceux ci n'atteignent le kernel" : n'a pas vraiment de sens...
ok pour le kernel, je ne savais pas trop de quoi je parlais. L'idee etait juste de supprimer "en amont" les paquets que l'on est certain de refuser.
Et en général une application n'écoute pas et ne réponds pas sur le même port. Donc le --sport --dport 7000 me chagrinne. (Je dis bien en général). En plus il n'y a pas besoin d'ouvrir pour la réponse. Iptables le fait seul.
ok pour le port 7000, il n'est qu'un port de "destination" (cf Logs), et il est effectivement inutile d'autoriser la sortie (quelle buse!!)
A partir du moment ou tu décides qu'il est bon pourquoi tu veux encore l'analyser(vérifier) ?
Inserer dans NEWNOTSYN / BADTCP etc... est une BAD idea ! Le but de ces chaines est de vérifier la validité du paquet (pas malformé).
Pour ce qui est de la regle NEWNOTSYN, je suis parfaitement conscient qu'il n'est pas conseillé d'inserer des regles dans de telles chaines mais c'est la seule solution que j'ai pu envisager. Une simple regle dans CUSTMFRWD n'aurait a mon sens pas evité le rejet de ce paquet "invalide" pour Ipcop
Je veux ces paquets, qui semblent essentiels, mais je voudrais qu'ils passent le reste des tests car je n'ai pas totalement confiance en ce traffic (pitoupi).
Les autres tests pourraient peut etre detecter quelque malformation mais je peut me tromper car je n ai pas encore decortiqué toutes les regles.
La cible RETURN, si je comprend bien, vas retourner le paquet a l'endroit ou il a quitté la chaine precedente.Vais aller potasser...
Merci Franck78 pour ces infos car j'aurais pu mieux RTFM mais au debut c'est dur de s'auto-corriger, de chercher dans les forums des notions que l'on decouvre ou des reponses a des questions un peu particulieres. (j'ai meme eu peur de ne pas avoir de reponse, le flip!!)
J'aime Ixus!! a+
ps: doit je editer ce poste pour le marquer [resolu] puisque c'est le cas?
-
Chikouille - Second Maître
- Messages: 42
- Inscrit le: 10 Juin 2004 13:59
par Franck78 » 12 Août 2004 03:23
tu mets résolu si tu veux mais ça fera penser que tu n'as plus besoin d'éclaircissement ou d'autres points de vue.
Moi j'ai toujours pas compris ton problème avec test paquets et NEWNOTSYN.
Ils ont quoi ?
Qu'est-ce que c'est ?
bye
Moi j'ai toujours pas compris ton problème avec test paquets et NEWNOTSYN.
Ils ont quoi ?
Qu'est-ce que c'est ?
bye
-
Franck78 - Amiral
- Messages: 5625
- Inscrit le: 20 Fév 2004 01:00
- Localisation: Paris
par Chikouille » 12 Août 2004 15:34
Ce traffic est tout simplement generé par emule+ 1l
Quand je place cette machine derriere le routeur sur l'interface GREEN, je m'apercois que de nombreux paquets sont rejetés
par la chaine NEWNOTSYN.
En effet, apres l'ajout de ces lignes,
"/sbin/iptables -I NEWNOTSYN -p tcp -d 192.168.0.10 --sport 4661:4663 -j RETURN"
"/sbin/iptables -I NEWNOTSYN -p tcp -d 192.168.0.10 --dport 7000 -j RETURN",
(EDIT: en fait je me suis emballé car je n ai pas encore testé avec RETURN, ce qui suit vaut pour la cible DROP)
tout va mieux et le comportement du logiciel redevient normal. Ces paquets font probablement partie du mecanisme de demande de "transfert" car sans eux, point ou tres peu de dl.
Si le paquet est ACCEPT, il n est plus traité avant le "hook" suivant. prenons un exemple:
NEWNOTSYN est appelé par BADTCP lui meme appelé par FORWARD
si le paquet est accepté il n'est plus traité par les regles de FORWARD, j'en deduis que:
- tous les tests de ne sont pas effectués (mais apres decortiquage de iptables --list, il semble que ce ne soit pas genant car NEWNOTSYN est appelé en dernier dans BADTCP).
- on ne peut plus matcher le paquet si on le desire, par exemple refuser une ip dans CUSTOMFORWARD, ou LOG pour test
c'est pourquoi la cible RETURN est interessante car elle permet tout cela
Pour moi cela parait clair mais je me trompe peut etre dans le raisonnement.
A Bientot.
Quand je place cette machine derriere le routeur sur l'interface GREEN, je m'apercois que de nombreux paquets sont rejetés
par la chaine NEWNOTSYN.
En effet, apres l'ajout de ces lignes,
"/sbin/iptables -I NEWNOTSYN -p tcp -d 192.168.0.10 --sport 4661:4663 -j RETURN"
"/sbin/iptables -I NEWNOTSYN -p tcp -d 192.168.0.10 --dport 7000 -j RETURN",
(EDIT: en fait je me suis emballé car je n ai pas encore testé avec RETURN, ce qui suit vaut pour la cible DROP)
tout va mieux et le comportement du logiciel redevient normal. Ces paquets font probablement partie du mecanisme de demande de "transfert" car sans eux, point ou tres peu de dl.
Si le paquet est ACCEPT, il n est plus traité avant le "hook" suivant. prenons un exemple:
NEWNOTSYN est appelé par BADTCP lui meme appelé par FORWARD
si le paquet est accepté il n'est plus traité par les regles de FORWARD, j'en deduis que:
- tous les tests de ne sont pas effectués (mais apres decortiquage de iptables --list, il semble que ce ne soit pas genant car NEWNOTSYN est appelé en dernier dans BADTCP).
- on ne peut plus matcher le paquet si on le desire, par exemple refuser une ip dans CUSTOMFORWARD, ou LOG pour test
c'est pourquoi la cible RETURN est interessante car elle permet tout cela
Pour moi cela parait clair mais je me trompe peut etre dans le raisonnement.
A Bientot.
-
Chikouille - Second Maître
- Messages: 42
- Inscrit le: 10 Juin 2004 13:59
par Chikouille » 13 Août 2004 01:47
peut etre que c'est une question de version
en tout cas merci d'avoir pris le temps de repondre.
vaya con dios...
en tout cas merci d'avoir pris le temps de repondre.
vaya con dios...
-
Chikouille - Second Maître
- Messages: 42
- Inscrit le: 10 Juin 2004 13:59
8 messages
• Page 1 sur 1
Qui est en ligne ?
Utilisateur(s) parcourant actuellement ce forum : Aucun utilisateur inscrit et 1 invité