(Courriels de diversion: <balayerez@patte-rimeur.com> <amertume@tacheriez-perseveraient.com> <oppressants@admissions-sechee.com> <barbouillant@desequilibrees-fouettant.com> <ramona@kilometrer-lamentiez.com> <anticonstitutionnelles@promontoires-betonneuse.com> <mineur@ebranlez-candidat.com> <interesserent@dementirons-audiovisuels.com> <mithridatiser@trairions-centenaire.com> <voyagerent@demoliront-admonestation.com> )
Eric Huiban wrote: > On Sunday 19 December 2004 18:10, marc Thirion wrote: > >>batou wrote: >> >>>On aimerait eviter le ping de romarin, cause filtrage icmp ... >> D'une part le ping n'est pas obligatoire, il suffit qu'on puisse >>déterminer que romarin a du jus par le réseau. Tout serveur bidouillé ou >>non, tcp ou udp conviendrait. > ? Pour poursuivre mon idée, n'importe quel moyen d'interrogation de Romarin suffit par le réseau suffit. L'usage du ping n'est pas obligatoire, si c'est contre la religion. >> D'autre part, ne connaissant pas le détail de la configuration du >>filtrage IP de Romarin, il m'est difficile de me prononcer vraiment, >>mais l'interdiction de l'ICMP du côté des réseaux locaux me paraît _a >>priori_ pour le moins exagérément strict. > > C'est juste l'application d'une regle de base usuelle sur la derivation INPUT > d'un routeur dans le script en debug (on droppe l'acces direct et on traite > les erreurs) : > > $IPTABLES -N Ping > $IPTABLES -A Ping -m limit -j LOG --log-prefix "Dropped ICMP:" > $IPTABLES -A Ping -j DROP > $IPTABLES -A INPUT -p icmp -state --state ! RELATED -j Ping L'explication de l'utilité de cette restriction sur le réseau interne (et externe dans le cadre d'une adresse IP routable unique) ? (Le "c'est comme ça qu'il faut faire parce que nos pères faisaient comme ça" n'entre pas dans ma conception d'une explication. Je *souhaite* comprendre : pour moi en l'état actuel et prévisible, cette restriction est inutile, voire nuisible.) > On n'a pas encore prevu d'appliquer le nouvelles recomendations informelles > qui trainent sur le net de nos jours sur la contention des scripts-kiddies > par ex. drop des acces sur les ports 22 quand l'os est un linux. :o) Perplexe. Tu veux pas débrancher le routeur, par hasard ? Pour le coup, il serait 100% sûr. >>>Pour le wake on lan, bof, on n'a pas prévu de pouvoir se logguer sur le >>>routeur depuis l'extérieur... ça limite les emmerdements. Pas se loger sur le routeur == OK, je suis. Mais se loger sur le serveur du PIC derrière, ça c'est nécesssaire. >> Je ne comprends pas comment les serveurs >>sont signalés de l'événement "le courant est là, on ne tire plus sur >>l'onduleur, vous pouvez démarrer". > La theorie, la pratique usuelle et la technique etherée voudrait que le > soit autonome ou dependant uniquement de la gestion > technique du batiment. Pour le reste on est sorti des exigences > fonctionelles initiales. Je suis d'accord que cela ne faisait pas parti des exigences fonctionnelles initiales. Nous n'avions donc pas été complets lors de l'établissement de celles-ci. Aucune raison, cependant, de se faire du mal au portefeuille ni au délai pour cette raison sans nécessité clairement explicable. > Oui. Mais le WOL et la gestion electrique du batiment sortent des > exigences fonctionnelles initiales du routeur. La gestion des incidents électriques (hors onduleur) n'était effectivement pas prévue. Une erreur. Elle ne m'en paraît pas moins nécessaire. Il faut donc l'ajouter aux exigences fonctionnelles. Je propose en conséquence une modification qui me semble implantable à coût humain faible et financier nul. Je n'ai pas vu de contre-proposition, autre que celle à base d'un montage électronique dont les conditions de validation me sont inconnues, et à délai de disponibilité non précisé. -- Marc Thirion | Ramonville Saint-Agne, France Projet Internet et Citoyenneté : http://www.le-pic.org/