-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-14 a las 22:40 +0200, carlopmart escribió:
Carlos E. R. wrote:
El 2009-09-14 a las 09:32 +0200, carlopmart escribió:
A ver si me explico bien. Son DOS problemas:
a) El porque no se puede deshabilitar el zeroconf de una forma sencilla sin hacer chapuzas (y eso incluye la creacion de scripts de arranque que ya comenté con camaleon o usar el rc.local o usar iptables, que ni me sirve ni me vale porque la ruta sigue ahí y se seguirá presentando a la red en cuanto se le haga un query)
Un script en rc.local no te va a funcionar, se ejecuta antes de que levante la red. Y en todo caso, lo que quita es la red, no los posibles servicios zeroconf aka linklocal.
Yo tenia entendido que se ejecutaba al final de todos los demas scripts de arranque (otra cosa nueva que no sabía de las SuSE)... Pero bueno, no me servía de todas formas.
No, se ejecuta al principio, antes del resto de todos los scripts que no sean boot*. De hecho, en suse no existe el rc.local.
b) problema de seguridad, ya que me registran incidencia tanto en firewalls como en IPS y a mi me reclaman el problema.
Y sí, es un problema de seguridad bastante fuerte. Es trivial inyectar paquetes de peticiones zeroconf desde redes internas y averiguar por consiguiente la IP del servidor y los servicios que presta.
Eso tienes que aclararlo, porque no entiendo en que puede afectar una ruta definida en el servidor. ¿Quien está generando esos paquetes que se ven en el cortafuegos?
La openSuSE y la SLES (están en el mismo segmento de red), ya que ambas exponen una nueva ruta de red fuera de su segmento de configuracion. Por consiguiente, tanto firewalls como IPS detectan spoofing ...
Eso no lo tengo claro. ¿Spoofing? ¿Desde las máquinas con suse?
Por cierto. Si se desactiva la ruta linklocal en el servidor, lo que podría pasar es que los paquets linklocal que pudiera emitir por algún motivo irían precisamente al gateway, y se registrarian en el cortafuegos. No es un ataque, sino un fallo de configuración.
Ya, eso explicaselo tu a los IPS y a los operadores que los gestionan (que no administran).
No, es que el error sería de tu red, por tener ordenadores que no tengan IP propia y busquen una IP mediante zeroconf. Y si los paquetes se envían al gateway, pienso que es precisamente por haber borrado la ruta: o sea, culpa tuya al intentar corregir el problema :-P Y sigo sin ver que problema supone eso para el gateway. Son direcciones legales, de la intranet. Lo único que tienen que hacer es descartarlas. Y estoy casi seguro que tu router de acceso a internet descarta esas direcciones sin quejarse. No veo de qué se quejan los administradores de esos routers.
Yo no necesito que envien ningun, y cuando ningun paquete digo ninguno, ni un triste echo-request, sencillamente porque no lo van a necesitar nunca para nada. Para eso tienen todo el hierro redundado .. Aka: me parece muy bien que lo pongan en openSuSE pero en la SLES es un gazapo de mucho bulto ... ¿Pero es que creen que el 100% de usuarios de SLES vienen de Windows (o peor aún de las Netware :)) o qué??
Sigo sin entender el problema.
En cuanto a averiguar qué servicios presta el servidor, pues eso se puede hacer aunque no tengas linklocal.
No en este caso. Estos servers solo publican un acceso ssh, cuando en realidad ofrecen más servicios (no públicos) como http, tomcat, mysql ... No te serviaría de nada lanzar un escaner porque la unica respuesta que recibirias es un ssh ...
Pues entonces no tienes que preocuparte de nada. Espera, si dices que ofrecen otros servicios, un nmap los descubre. Públicos o privados, los descubre, si están en la red. Pero si no quieres que atiendan peticiones zeroconf ni te den problemas, pues tienes que cerrar todos los puertos con el cortafuegos del servidor, incluido los broadcast de zeroconf entrantes. El resto no te va a servir de nada. Se supone que estamos hablando de una intranet, claro. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkquwI0ACgkQtTMYHG2NR9VviQCglHD92VO5Rpy5wG4xbtDg3kY1 NkkAniE06pk+ZNEjI7e72l4GbAIcg0eR =L4ri -----END PGP SIGNATURE-----