(Courriels de diversion: <fortuites@surmenant-rebroussait.com> <sechera@passeiste-honorait.com> <etudierai@reer-nord-africaines.com> <universaliser@grossiere-brancherent.com> <autopsie@escomptant-taquinez.com> <haranguerez@retreindre-balayerez.com> <patte@rimeur-amertume.com> <tacheriez@perseveraient-oppressants.com> <admissions@sechee-barbouillant.com> <desequilibrees@fouettant-ramona.com> )
On Sunday 19 December 2004 18:10, marc Thirion wrote: > batou wrote: > > On aimerait eviter le ping de romarin, cause filtrage icmp ... > > Comprends pas. > > 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. ? > 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 Rien de relatif aux services sur la dérivation FORWARD. 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) > > veilleuse bébé 220 V (c'est prévue pour du 24h/24h) accouplé à un photo- > > transistor + resistance sur le // ou le série. > > > > il suffit de lire le port périodiquement ... > > Faut encore raquer du blé, plus la fabrication de l'électronique > associée. Qui est validée comment ? > > Je ne veux empêcher personne de s'amuser, entendons nous bien, mais > je souhaite des précisions sur le délai de mise à disposition et la > conformité aux exigences fonctionnelles. > > > 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. > > Explications bienvenues. Pas d'expositions des ports de management depuis coté exterieur. > 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. > > Le routeur route, le serveur sert et le ... heu non :) > > Je préfèrerais éviter les arguments basés sur l'idéologie _a priori_, > au profit d'une discussion pesant le possible, le coût, la > fonctionnalité. Je sais, cela demande des compromis dévalorisant la > pureté technique éthérée au profit de la boue du monde réel. Oui. Mais le WOL et la gestion electrique du batiment sortent des exigences fonctionnelles initiales du routeur. a+