Re: [Confirme] Re: Re: ipchains et port 0
Christophe PEREZ a écrit : Le Fri, 19 Sep 2003 07:58:39 +0200, Troumad a écrit: Je vais voir ! Plus la peine :-) Si je tiens est correct, il m'intéresse! L'as-tu changer depuis ce vieux fil? Je comparerais à ce que je suis arrivé à faire et je vais essayer de commenter. -- Amicalement vOOotre Troumad Alias Bernard SIAUD mon site : http://troumad.free.fr : ADD, mathématiques, WEB, et sectes. Pour que vive la liberté soutenez http://www.mandrakelinux.com/fr/ : Mandrake Linux, http://www.eurolinux.org/index.fr.html Je souhaite recevoir uniquement des documents avec des formats ouverts, par exemple avec http://fr.openoffice.org Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft? Rendez-vous sur http://www.mandrakestore.com;
Re: [Confirme] Re: Re: ipchains et port 0
run_iptables -A common -p udp --sport 53 -mstate --state NEW -j DROP = tout les paquet UDP provenant d'une ip source quelconque et du port 53 et qui tente d'initialiser une connexion est rejeté C'est à peu près ce que j'avais compris, mais en clair, je veux dire, en réalité, ça peut correspondre à quoi ces requêtes sur le port 53 qui remplissent mes logs de DROP ?? ben c'est des requétes DNS justement qui sont dropé! donc je doute que la résolution de noms se fasse chez toi.Cela dit si ta résolution DNS ne fonctionne pas entre les clients de ton LAN et ton proxy cela ne génera pas car tes clients utilisent le cache proxy qui lui te fournit les page que tu demandes.Par contre si ta résolution dns ne fonctionne pas entre ton serveur proxy et le net alors là pas bon! tu ne sais pas si ton pb viens de ta résolution de nom (dns) causé par ton filtrage.je me demande si t'as pas fait des redirection un peu partout avec des regles shorewall un peu biscornu.tu peux faire voir ta conf shorewall. Alex
Re: [Confirme] Re: Re: ipchains et port 0
Christophe PEREZ a écrit : Le Mon, 18 Aug 2003 06:48:15 +, AMORE Rosaire a écrit: .../... Mon problème, il est que : Sur mon serveur, j'ai shorewall, apache, serveur dns (bind), et proxy squid configuré en proxy transparent. J'ai donc une règle shorewall dans les rules : REDIRECTloc 8080tcp www - !192.168.0.100 qui redirige tous les accès des postes du réseau sur le port 80 (http) vers le port 8080 (celui de squid), sauf pour les accès au serveur local (192.168.0.100) Tout fonctionne parfaitement (ou presque). Quand je surfe avec mes différents postes, linux ou windows, configurés normalement (donc sans proxy) tout passe bien par le proxy du serveur, et c'est bien ce que je veux. De même, tous les accès au serveur http local évitent bien de passer par squid, c'est parfait aussi. Sauf que, je ne sais pas trop pourquoi, ni dans quelle condition exacte, si la connexion internet est très chargé (téléchargement par exemple) ou pas établie du tout, et que (donc), un requête http, sur le net, n'est pas rapidement résolue (trop de délai, ou pas de site au bout) la demande est redirigée automatiquement vers mon serveur web ! Si la page demandée existe (la racine en particulier) sur mon site, elle est envoyée, et si elle n'existe pas, j'ai la page d'erreur traditionnelle de mon apache qui est balancée. Je ne sais pas si je suis clair, donc un exemple : Ma connexion internet est chargée, ou pas établie. Dans mon navigateur, je lance : www.google.fr Bien souvent (mais pas toujours non plus), j'ai la page index.html de mon serveur qui s'affiche. Si je lance www.google.fr/ma/page/en/particulier.html, j'ai une erreur de _mon_ apache qui dit que la page /ma/page/en/particulier.html n'existe pas. Tout ceci se vérifie exactement de la même manière dans les logs, de squid et de apache. Et je ne parviens pas à savoir si c'est un pb de dns (on me dit que non) de squid (mais je ne vois pas où), de iptables à cause de la fameuse redirection (mais alors c'est un bug car elle n'est pas censée faire ça). J'ai déjà essayé des multitudes de choses dans tous les sens, sans jamais parvenir à résoudre ce problème. Ben t'as bien fait d'aller voir sur confirme. Paske c'est pas moi qui vais te résoudre ça comme ça. Je ne pense pas maîtriser suffisament. Par contre, ce que tu racontes me fait penser à trois pistes : - Taille du cache - Un paramètre de timeout qq part (peux pas te dire où) - Le proxy transparent (voir iptables et ce que tu appelles redirection) : délicat à gérer d'après ce que j'ai compris. Tu peux en savoir plus, je répète à : http://christian.caleca.free.fr/ Ce que je peux rajouter aussi : quand on en est à régler des config aussi haute voltige, c'est bien plus simple de s'attaquer à l'interface de base (iptables). Parce que là, tout se passe comme si tu devais apprendre à utiliser une interface (shorewall), qui elle même attaque une autre interface (iptables) qui attaque elle même le logiciel de base (netfilter). Faut être sérieux : le problème est en lui même déjà, complexe. Pas la peine d'en rajouter : ce que tu fais. Bon courage. Alors s'il y a ici des gens qui se sentent le courage, je suis ok pour faire tous les tests qu'ils me suggéreront :-) Merci d'avance. Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft? Rendez-vous sur http://www.mandrakestore.com;
Re: [Confirme] Re: Re: ipchains et port 0
Es tu sur que tu n'ai pas 2 process qui répondent au port 8080 ? Essaie de couper squid pour voir si tu as une réponse d'apache ? Car si les 2 répondent en 8080, un fois squid répond google/tapage est accessible, une fois apache répond et là tu es coincé... C'est une hypothèse, je sais pas ... Le lundi 18 août 2003, à 10:33 AM, Christophe PEREZ a écrit : Le Mon, 18 Aug 2003 06:48:15 +, AMORE Rosaire a écrit: Excuses, je ne voulais pas être cassant, mais honnêtement, je ne connais rien à shorewall. Et je connais un peu iptables. La question sans réponse, c'était quoi? Mais je ne t'ai pas du tout trouvé cassant, c'est donc moi qui ai du l'être, mais je fais trop de choses à la fois :-)) Mon problème, il est que : Sur mon serveur, j'ai shorewall, apache, serveur dns (bind), et proxy squid configuré en proxy transparent. J'ai donc une règle shorewall dans les rules : REDIRECTloc 8080tcp www - !192.168.0.100 qui redirige tous les accès des postes du réseau sur le port 80 (http) vers le port 8080 (celui de squid), sauf pour les accès au serveur local (192.168.0.100) Tout fonctionne parfaitement (ou presque). Quand je surfe avec mes différents postes, linux ou windows, configurés normalement (donc sans proxy) tout passe bien par le proxy du serveur, et c'est bien ce que je veux. De même, tous les accès au serveur http local évitent bien de passer par squid, c'est parfait aussi. Sauf que, je ne sais pas trop pourquoi, ni dans quelle condition exacte, si la connexion internet est très chargé (téléchargement par exemple) ou pas établie du tout, et que (donc), un requête http, sur le net, n'est pas rapidement résolue (trop de délai, ou pas de site au bout) la demande est redirigée automatiquement vers mon serveur web ! Si la page demandée existe (la racine en particulier) sur mon site, elle est envoyée, et si elle n'existe pas, j'ai la page d'erreur traditionnelle de mon apache qui est balancée. Je ne sais pas si je suis clair, donc un exemple : Ma connexion internet est chargée, ou pas établie. Dans mon navigateur, je lance : www.google.fr Bien souvent (mais pas toujours non plus), j'ai la page index.html de mon serveur qui s'affiche. Si je lance www.google.fr/ma/page/en/particulier.html, j'ai une erreur de _mon_ apache qui dit que la page /ma/page/en/particulier.html n'existe pas. Tout ceci se vérifie exactement de la même manière dans les logs, de squid et de apache. Et je ne parviens pas à savoir si c'est un pb de dns (on me dit que non) de squid (mais je ne vois pas où), de iptables à cause de la fameuse redirection (mais alors c'est un bug car elle n'est pas censée faire ça). J'ai déjà essayé des multitudes de choses dans tous les sens, sans jamais parvenir à résoudre ce problème. Alors s'il y a ici des gens qui se sentent le courage, je suis ok pour faire tous les tests qu'ils me suggéreront :-) Merci d'avance. -- Christophe PEREZ Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft? Rendez-vous sur http://www.mandrakestore.com; Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft? Rendez-vous sur http://www.mandrakestore.com;
Re: [Confirme] Re: Re: ipchains et port 0
Le ven 15/08/2003 à 19:43, Christophe PEREZ a écrit : Le Fri, 15 Aug 2003 03:08:10 -0400, marc guillaume a écrit: auth113/udpAuthentication Service epmap 135/udpDCE endpoint resolution Oui, mais ça ne me dit pas du tout à quoi ça sert. va voir sur le site http://grc.com/default.htm rubrique ShieldsUp. La dedans tu pourras avoir des infos sur chaque port :-). Profite-en pour tester ta machine. David. Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft? Rendez-vous sur http://www.mandrakestore.com;
Re: [Confirme] Re: Re: ipchains et port 0
Le Vendredi 15 Août 2003 11:43, Christophe PEREZ a écrit : epmap 135/udpDCE endpoint resolution Oui, mais ça ne me dit pas du tout à quoi ça sert. Et bien pour ce que j'ai pu lire le port 135 est utilisé par windows et c'est le port qui a été attaqué par le dernier virus de l'autre jour. C'est curieux qu'il réponde chez toi. -- Je vous serai reconnaissant de ne pas m'envoyer de pièces jointes aux formats Microsoft Word ou Microsoft PowerPoint. Utilisez des formats universels et connus comme rtf ou texte. Merci. Lisez ceci : http://www.fsf.org/philosophy/no-word-attachments.fr.html Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft? Rendez-vous sur http://www.mandrakestore.com;
Re: [Confirme] Re: Re: ipchains et port 0
Le Samedi 16 Août 2003 02:10, David Robert a écrit : va voir sur le site http://grc.com/default.htm rubrique ShieldsUp. La dedans tu pourras avoir des infos sur chaque port :-). Profite-en pour tester ta machine. Heu justement si tu reprends ce fil c'est justement notre point de départ... mais les explications su Shield Ups ne sont pas toujours très éclairantes à notre goût. Merci -- Je vous serai reconnaissant de ne pas m'envoyer de pièces jointes aux formats Microsoft Word ou Microsoft PowerPoint. Utilisez des formats universels et connus comme rtf ou texte. Merci. Lisez ceci : http://www.fsf.org/philosophy/no-word-attachments.fr.html Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft? Rendez-vous sur http://www.mandrakestore.com;
Re: [Confirme] Re: Re: ipchains et port 0
Le sam 16/08/2003 à 18:35, marc guillaume a écrit : Le Samedi 16 Août 2003 02:10, David Robert a écrit : va voir sur le site http://grc.com/default.htm rubrique ShieldsUp. La dedans tu pourras avoir des infos sur chaque port :-). Profite-en pour tester ta machine. Heu justement si tu reprends ce fil c'est justement notre point de départ... mais les explications su Shield Ups ne sont pas toujours très éclairantes à notre goût. Ah ? explications ? Mais existe-t-il d'autres sites du même genre ? en français ? si oui on pourrait se faire une petite liste et vérifier nos machines ? :-) Merci Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft? Rendez-vous sur http://www.mandrakestore.com;
Re: [Confirme] Re: Re: ipchains et port 0
va voir sur le site http://grc.com/default.htm rubrique ShieldsUp. La dedans tu pourras avoir des infos sur chaque port :-). Profite-en pour tester ta machine. Heu justement si tu reprends ce fil c'est justement notre point de départ... mais les explications su Shield Ups ne sont pas toujours très "éclairantes" à notre goût. en fait tu as surement du voir 3 états possibles sur les differents ports scanné: close: le port n'est pas connectable(fermé ou filtré) et envoie un echo notifiant sa non disponibilité à la source du scanne open: le port est en écoute et est connectable par la source du scanne stealth: il ne renvoie aucun état à la source du scanne.A Priorie sois l'hote scanné n'existe pas sois il est protégé par un firewall. Pour info, le port 0 est les port utiliser par defaut pour les paquets ICMP (entre autre les ping) et le 135 est le port mapper des services RPC : il indique quel services/port sont utilisable sur la machine cible.
Re: [Confirme] Re: Re: ipchains et port 0
Le Samedi 16 Août 2003 13:56, [EMAIL PROTECTED] a écrit : Pour info, le port 0 est les port utiliser par defaut pour les paquets ICMP (entre autre les ping) et le 135 est le port mapper des services RPC : il indique quel services/port sont utilisable sur la machine cible. Oui je reviens donc à ma première question : comment écrire une règle ipchains (j'ai bien dit ipchains et pas iptables j'ai un noyau 2.2) qui fasse apparaître mon port 0 et mon port 1 en stealth comme tous les autres ? (voir plus haut dans le fil les règle que j'ai tentées et qui ne fonctionnent pas). Si tu as une idée n'hésite pas. -- Je vous serai reconnaissant de ne pas m'envoyer de pièces jointes aux formats Microsoft Word ou Microsoft PowerPoint. Utilisez des formats universels et connus comme rtf ou texte. Merci. Lisez ceci : http://www.fsf.org/philosophy/no-word-attachments.fr.html Vous souhaitez acquerir votre Pack ou des Services MandrakeSoft? Rendez-vous sur http://www.mandrakestore.com;
Re: [Confirme] Re: Re: ipchains et port 0
Dans un e-mail daté du 16/08/2003 20:26:21 Paris, Madrid (heure d'été), [EMAIL PROTECTED] a écrit : Oui je reviens donc à ma première question : comment écrire une règle ipchains (j'ai bien dit ipchains et pas iptables j'ai un noyau 2.2) qui fasse apparaître mon port 0 et mon port 1 en stealth comme tous les autres ? (voir plus haut dans le fil les règle que j'ai tentées et qui ne fonctionnent pas). je connais pas trop ipchains..j'étais trop jeune :-) mais grosso modo ca doit étre cela: admettons que l'interface eth1 est ouvert vers le Net: # pour empecher le ping ( refuser les ICMP echo request) ipchains -A input -i eth1 -p icmp -j DENY # pour refuser les connexion sur le port 135 (UDP et TCP) ipchains -A input -i eth1 -p tcp -s 0/0 -d 0/0 135 -j DENY ipchains -A input -i eth1 -p udp -s 0/0 -d 0/0 135 -j DENY Alex
