Carlos E. R. wrote:
¿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 <======
Te he mostrado la tabla principal de rutas, no todas las tablas. ¿Conoces iproute2 correcto?. Bien pues estos servidores tienen 3 tablas distintas de enrutemiento con tres default gateways por defecto para salir y recibir peticiones por cualquiera de ellos en caso de fallo. En esta tabla de enrutamiento principal ves ese default gateway que es el que se utilizará en caso de que todo lo demás falle. Puedo poner todas las tablas si lo consideras necesario.
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.
No. Los paquetes seran "vistos" por todos los servidores del segmento 172.25.50.0/27, incluido el gateway. Eso es muy distinto a decir que "ahí es donde van a ir los paquetes". Los paquetes no "iran" al gateway, serán vistos por el gateway (y demás servidores), ya que el gateway no va a hacer nada con esos paquetes.
Hablo de un supuesto. Pero tengo entendido que borraba esa ruta a mano antes de saber como quitarla automáticamente.
Eso hice, hasta que vi la entrada del /etc/sysconfig/network/config como me indicó camaleon y deshabilité el linklocal.
¿Que pruebas tienes de que tener esa ruta genera los paquetes? Yo no me lo creo; las cosas están compartimentadas, una ruta creada no genera paquetes, sólo sirve para saber a donde enviar los paquetes que cumplan las condiciones, si los paquetes aparecen. Pero han de ser otros los que los generen.
Hombre por fin de acuerdo en algo. Correcto, una ruta de por sí no genera nada. Pero si aparece un dispositivo que comienza a generar paquetes como un avahi por ejemplo, ¿que podría llegar a pasar? ¿podría reconfigurarse el servidor, ya que tiene el zeroconf habilitado y permitido el linklocal?? Vaya putada, ¿no crees?.
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.
Correcto. Pero es que yo quiero impedir eso precisamente: que escuchen esos paquetes.
Ahora bien, sería interesante saber por qué esos equipos están detectando algo fuera de lo común cuando el link-local debería estar contemplado y deberían descartarlo automáticamente... pero bueno, ese es otro tema.
Puesto que no sabemos la arquitectura de la red, he de suponer que se trata del gateway. Yo hasta ahora he interpretado su "IPS" por el gateway/router de su proveedor de internet (ISP mal escrito, quizás).
No. Vuelvo a repetir: firewalls e ISP aka Internet Prevention System, o sea un IDS (Intrusion Detection System) en modo pro-activo, esto es: toma decisiones en función a reglas, patrones, expresiones, etc definidos, normalmente bloquean y generan alertas. Vamos, que no estoy hablando de ISP (Internet Service Provider). Aquí el único que interpreta router eres tú, porque vuelvo a repetir yo solo hablo de firewalls e IPS, no de routers. Y como comenté en otro correo el termino gateway es un genérico para englobar muchos dispositivos: routers, firewalls, ssl-vpn appliances, etc. Es una lista enorme.
Y es efectivamente tarea del gateway de internet cepillarse los paquetes que le lleguen destinados con IPs "ilegales" para el exterior.
Ahora parece que el gateway no es de internet :-? Pues ni idea, pero lo que no esté en sus tablas no lo rutará y quizás lo reporte.
No, un gateway no tiene que estar colgado en Internet, ¿porque tiene que estarlo?. A ver concoeis empresas con redes corporativas propias que enlazan entre sedes separadas físicamente, como por ejemplo centros de Disaster Recovery ¿verdad?. Bueno pues hay algunas que lo hacen sin Internet de por medio (vale una pasta, pero lo hacen). A ver quien es el bonito que hace pasar la información a través de Internet, se les cae el pelo ante cualquier problema. Otro ejemplo mejor son las conexiones entre las centrales de los bancos o cajas y sus oficinas.
¿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.
Estamos provocando la enfermedad.
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 :-?
Además, las interfaces configuradas en "bonding" no generan esa ruta de manera automática y obviamente no hay ningún problema.
Yo lo veo igual que tener un servidor dhcp o dns en marcha: si no lo necesito, no lo configuro... ¿para qué? ¿para que el vecino, a través del wifi, pueda obtener una ip en mi rango y acceder fácilmente a los recursos de la red? Pues no. Si en algún momento tengo que conectar un equipo a la red que necesita una IP asignada automáticamente, entonces me plantearé la configuración del servidor dhcp, pero no antes.
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í.
Yo creo lo contrario, que al tener un DHCPs vas a saber en qué rangos van a aparecer los ordenadores "intrusos", y evitas que algún otro meta un "rogue dhcps".
¿Ah, si? ¿Como evitas que un pc "blackhat" no se ponga una de esas IP's controladas? ¿Conoces el arp spoofing o mayormente conocido como envenenamiento de cache arp? Miratelo, te volverás más paranoico :)) No pretendo llegar tan lejos, porque físicamente es bastante complicado que alguien no autorizado pinche un PC en esos switches. Es más fácil sacarle las contraseñas a la secretaria del jefe. :)) Lo que intento evitar es un error de configuración por parte de otro administrador o un error de programación que haga llamadas a IP's no permitidas. Simple y llanamente.
- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkqwEd4ACgkQtTMYHG2NR9WUFQCgiexLnN+kIn2Sps3qc0zT7yo7 vx0AnRvt5EcqBcxx2ZmHf3Olg7TdRW2h =unCG -----END PGP SIGNATURE-----
-- CL Martinez carlopmart {at} gmail {d0t} com -- 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