El 2009-09-16 a las 21:20 +0200, Carlos E. R. escribió:
El 2009-09-16 a las 08:52 +0200, Camaleón escribió:
¿Y yo que sé? No nos ha explicado todo, lo va contando con cuentagotas. El caso es que sí tiene gateway, lo dijo en el primer correo:
172.25.85.0/28 dev eth1 proto kernel scope link src 172.25.85.7 172.25.50.0/27 dev eth0 proto kernel scope link src 172.25.50.15 169.254.0.0/16 dev eth0 scope link 127.0.0.0/8 dev lo scope link default via 172.25.50.28 dev eth0 <======
Hay una ruta por defecto, ahí es donde van a ir los paquetes para el rango 169.254.0.0/16 si borras esa linea.
Lo dudo >:-)
Chica, es de libro: si hay un paquete para 169.254.0.1 y eso encaja en 169.254.0.0/16, pues sale por el dispositivo eth0. Eso es de libro. ¿Que pasa si no hay esa ruta explícita? Pues que sale por la ruta por defecto:
default via 172.25.50.28 dev eth0
y eso también es de libro. Y va exclusivamente a la IP 172.25.50.28 (a la MAC que tiene esa IP), para que esa máquina se encarge de reenviarlo a 169.254.0.1.
Eso es así, es de libro.
¿De qué libro hablas, exactamente?
Pero la prueba es sencilla de hacer: se configura un equipo con un adaptador de red sin configurar y se conecta a la red donde está el servidor suse con el zeroconf ese activado. Luego se hace la misma prueba pero con la ruta del zeroconf eliminada. Todo esto con un monitor de red activado para ver por dónde se van los paquetes.
Lo pruebas y me lo cuentas, yo no tengo tantas máquinas como para poder probarlo.
Yo no tengo ninguna duda de que desactivar el zeroconf pueda ser una operación "peligrosa", eres tú quien asegura que los paquetes destintados a una ruta inexistente del zeroconf se van por la puerta de enlace predeterminada >:-)
Lo único que haces al tener esa ruta es definir a donde van esos paquetes si "algo" los genera. No impides ni que se generen ni que se responda a ellos.
Lo que desconocemos es la configuración de los IPS y por qué geenran las alertas cuando se activa la ruta... pero hombre, si te te está diciendo que es lo que pasa, pues no tenemos por qué desconfiar.
Sabemos que llegan al cacharro ese. Yo de eso no he dicho que desconfío. Lo que no me trago es que tener esta linea:
169.254.0.0/16 dev eth0 scope link
en la tabla de rutas genera paquetes link-local. Demuestramelo. Díme en que manual se dice que crear una ruta crea paquetes.
¿Que hay paquetes? Vale. Pero no es por eso.
¿Y quién ha dicho que sea por éso? :-? Lo único que sabemos es que algún chisme de seguridad le está detectando "algo" y salta una alerta/aviso. Nada más, o al menos yo no he captado nada más de la exposición de carlopmart.
¿O no es un gateway y es un cortafuegos solamente? Un cortafuegos es un tipo de router al fin y al cabo. Normalmente reporta lo que bloquea.
Pero no supone ningún problema.
Pues aparentemente sí lo supone.
Porque tendrá administradores quisquillosos.
No lo sé, no estoy en su red. Ya te digo que tampoco entiendo como un IPS no es capaz de detectar que los paquetes (o lo que sea que detecte) le viene de esa ruta y descartar una alerta administrativa. No sé qué tipo de IPS son y la configuración exacta de su red.
Lo que hay que hacer no es borrar la ruta, sino redefinirla para que vayan a la basura, o cortarlos en un cortafuegos en cada máquina.
Después de leer el RFC yo diría que es todo lo contrario :-/
Explica :-?
Pues que el RFC precisamenterecomienda no crear esa ruta del zeroconf sobre una interfaz que ya tiene configurada y está operativa. El zeroconf es para redes pequeñas donde no haya una infraestructura de dhcp o de dns, o donde los usuarios no tengan los conocimientos suficientes para configurar la red.
Creo sinceramente que no es el caso que nos ocupa.
Lo has leído mal.
Lo que recomienda es no crear la IP, repito, la IP del zeroconf sobre una interfaz que ya tiene configurada y está operativa. Sí recomienda crear la ruta sobre esa misma interfaz. No te confundas.
¿De qué IP estás hablando? ¿Qué IP te está creando el zeroconf?
Es una falsa sensación de seguridad: el cracker simplemente se inventará una IP y listo, entra igual. No tener un servidor dhcp no le va a parar en modo alguno, sólo va a tener que escuchar un rato para ver que IPs se usan y adivinar una del rango libre, que puede corresponder a un PC existente pero parado o a una no asignada por tí.
No le va parar, pero tampoco le voy dar pie a que siga, salvo que tenga algún honeypot configurado "ex professo" :-)
La recomendación que verás en todos los whitepapers de seguridad es que si no usas un servicio, es mejor desactivarlo. No veo por qué debería ser diferente en este caso del zeroconf.
Si en eso estamos de acuerdo... en eso estamos de acuerdo. Por supuesto, conviene desactivar zeroconf. Vale. Ahora, demuestrame que quitar la ruta, y sólo la ruta, desactiva el zeroconf. Porque no me lo trago.
Antes tendrías que definir qué es para ti "desactivar el zeroconf". Supongo que sólo tener la ruta creada y activa NO hace que el servicio esté operativo y listo para ofrecerse al resto de equipos de la red porque entonces tendríamos un agujero de seguridad como un crater en los sistemas. Lo que te estamos diciendo es que: Dado un problema X -> teniendo la ruta activada que crea el zeroconf se generan aviso por parte de los sistemas de seguridad de una red Tenemos la solución Y -> desactivar esa ruta que no está proporcionando ningún servicio y que en ningún caso (ni estando activada ni estando desactivada) supone ningún contratiempo adicional. ¡No estamos diciendo nada más! Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org