[opensuse-es] Deshabilitar zeroconf en el arranque
Hola, ¿Alguien sabe como deshabilitar la configuracion de zeroconf en el arranque? Cuando ejecuto el comando "ip ro" me muestra lo siguiente: 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 Lo que quiero que desaparezca es la ruta 169.254.0.0/16. No estoy usando ni dhcp ni servicios slp ni nada que se le parezca. Esto me ocurre tanto en una openSuSE 11.0 como en una SLES 11. Gracias de antemano. -- 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
El 10/09/09, carlopmart escribió:
¿Alguien sabe como deshabilitar la configuracion de zeroconf en el arranque? Cuando ejecuto el comando "ip ro" me muestra lo siguiente:
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
Lo que quiero que desaparezca es la ruta 169.254.0.0/16. No estoy usando ni dhcp ni servicios slp ni nada que se le parezca.
Esto me ocurre tanto en una openSuSE 11.0 como en una SLES 11.
Hum... curioso. En los servidores donde no tengo entorno gráfico, no aparece listada esa ip, pero en mi equipo (con kde3), sí está... luego debe ser el (los) paquete(s) avahi-* el/los que lo incorpora. ¿Cómo desactivarlo sin eliminar los paquetes? Ni idea :-? Hay dos servicios que se inician de manera predeterminada (avahi-daemon y avahi-dnsconf, creo) pero no creo que sólo con deterlos consigas lo que buscas... 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-10 a las 18:03 +0200, carlopmart escribió:
¿Alguien sabe como deshabilitar la configuracion de zeroconf en el arranque? Cuando ejecuto el comando "ip ro" me muestra lo siguiente:
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
Lo que quiero que desaparezca es la ruta 169.254.0.0/16. No estoy usando ni dhcp ni servicios slp ni nada que se le parezca.
Eso se usa cuando no has asignado una IP fija ni usas dhcp, o no funciona. Es decir, es un sistema de respaldo para tener red cuando todo lo demás ha fallado. Es un estándar más que linux soporta. Y no depende de avahi: yo no tengo avahi y tengo ese rango. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqpUgoACgkQtTMYHG2NR9XTSwCeMRylVd0c6i/5R2jTs/72it5o X28AnjL76WsPXH/NarO4xfAIR2wyeo92 =SUqO -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-09-10 a las 18:03 +0200, carlopmart escribió:
¿Alguien sabe como deshabilitar la configuracion de zeroconf en el arranque? Cuando ejecuto el comando "ip ro" me muestra lo siguiente:
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
Lo que quiero que desaparezca es la ruta 169.254.0.0/16. No estoy usando ni dhcp ni servicios slp ni nada que se le parezca.
Eso se usa cuando no has asignado una IP fija ni usas dhcp, o no funciona. Es decir, es un sistema de respaldo para tener red cuando todo lo demás ha fallado. Es un estándar más que linux soporta.
Y no depende de avahi: yo no tengo avahi y tengo ese rango.
Cierto, pero es un parámetro que se puede deshabilitar en el resto de distros de forma sencilla, pero aquí no veo la forma. No tengo ningún paquete de avahi instalado y mucho menos entorno gráfico. Ambas SuSE son servidores .... ¿Os suena de algo el parámetro NOZEROCONF=yes?? Es el que se usa en Mandriva/CentOS/RHEL y demás ... -- 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
El 2009-09-10 a las 21:52 +0200, carlopmart escribió:
Cierto, pero es un parámetro que se puede deshabilitar en el resto de distros de forma sencilla, pero aquí no veo la forma. No tengo ningún paquete de avahi instalado y mucho menos entorno gráfico. Ambas SuSE son servidores ....
Lo habrán integrado de serie en versiones posteriores :-? Al menos a mi no me aparece es ruta definida en la tabla.
¿Os suena de algo el parámetro NOZEROCONF=yes?? Es el que se usa en Mandriva/CentOS/RHEL y demás ...
¿Con "route del" no se eliminan rutas? :-? 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
Camaleón wrote:
El 2009-09-10 a las 21:52 +0200, carlopmart escribió:
Cierto, pero es un parámetro que se puede deshabilitar en el resto de distros de forma sencilla, pero aquí no veo la forma. No tengo ningún paquete de avahi instalado y mucho menos entorno gráfico. Ambas SuSE son servidores ....
Lo habrán integrado de serie en versiones posteriores :-?
Al menos a mi no me aparece es ruta definida en la tabla.
¿Os suena de algo el parámetro NOZEROCONF=yes?? Es el que se usa en Mandriva/CentOS/RHEL y demás ...
¿Con "route del" no se eliminan rutas? :-?
Saludos,
Si, pero en cuanto reboto las máquinas vuelve a salir. El script que la inserta es el ifup-route, pero no veo dentro ningún parámetro para anular esto ... fastidia porque varios firewalls e IPS están detectando esto y los logs crecen ... Podría hacer que no registrasen esta entrada pero antonces asumo riesgos que quiero evitar ... -- 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
El 2009-09-10 a las 22:19 +0200, carlopmart escribió:
Camaleón wrote:
¿Con "route del" no se eliminan rutas? :-?
Si, pero en cuanto reboto las máquinas vuelve a salir. El script que la inserta es el ifup-route, pero no veo dentro ningún parámetro para anular esto ... fastidia porque varios firewalls e IPS están detectando esto y los logs crecen ... Podría hacer que no registrasen esta entrada pero antonces asumo riesgos que quiero evitar ...
¿Y no hay forma de hacer el cambio persistente? :-? 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
Camaleón wrote:
El 2009-09-10 a las 22:19 +0200, carlopmart escribió:
Camaleón wrote:
¿Con "route del" no se eliminan rutas? :-?
Si, pero en cuanto reboto las máquinas vuelve a salir. El script que la inserta es el ifup-route, pero no veo dentro ningún parámetro para anular esto ... fastidia porque varios firewalls e IPS están detectando esto y los logs crecen ... Podría hacer que no registrasen esta entrada pero antonces asumo riesgos que quiero evitar ...
¿Y no hay forma de hacer el cambio persistente? :-?
Saludos,
Pues ahí está el tema, ¿como elimino esa configuración cada vez que rebote la máquina?? Hay un par de "chapucillas" que se pueden hacer pero prefiero hacerlo limpio, pero no encuentro la forma ... El caso es que debería haber algún archivo de configuración bajo /etc/sysconfig ... pero no lo veo .. -- 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
El 2009-09-10 a las 23:41 +0200, carlopmart escribió:
Si, pero en cuanto reboto las máquinas vuelve a salir. El script que la inserta es el ifup-route, pero no veo dentro ningún parámetro para anular esto ... fastidia porque varios firewalls e IPS están detectando esto y los logs crecen ... Podría hacer que no registrasen esta entrada pero antonces asumo riesgos que quiero evitar ...
¿Y no hay forma de hacer el cambio persistente? :-?
Pues ahí está el tema, ¿como elimino esa configuración cada vez que rebote la máquina?? Hay un par de "chapucillas" que se pueden hacer pero prefiero hacerlo limpio, pero no encuentro la forma ...
El caso es que debería haber algún archivo de configuración bajo /etc/sysconfig ... pero no lo veo ..
Algún script debe estar levantando esa ruta al iniciarse el servicio de la red... por ejemplo, en /etc/sysconfig/network/scripts/ifup-route aparece pero, buuff, vaya usted a saber >:-? 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-10 a las 22:19 +0200, carlopmart escribió:
Si, pero en cuanto reboto las máquinas vuelve a salir. El script que la inserta es el ifup-route, pero no veo dentro ningún parámetro para anular esto ... fastidia porque varios firewalls e IPS están detectando esto y los logs crecen ... Podría hacer que no registrasen esta entrada pero antonces asumo riesgos que quiero evitar ...
Hay una referencia en "/etc/sysconfig/network/config": ## Type: string("off","guess","auto-off","auto-manual","manual") ## Default: "off" # # !!!This feature is still not implemented. Leave it to 'off'!!! # What shall we do if there is no valid configuration? # off: do nothing, just fail # guess: try to guess the needed info (zeroconf) # auto-off: trigger automatic creation of a config file; if that fails, do # nothing, just fail # auto-manual: trigger automatic creation of a config file; if that fails, ask # user to provide configuration (via yast) # manual: ask user to provide configuration (via yast) # !!!This feature is still not implemented. Leave it to 'off'!!! FAILURE_ACTION=off Y otra en "/etc/sysconfig/SuSEfirewall2.d/services/avahi" que a lo mejor puede servir para bloquearlo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqpc98ACgkQtTMYHG2NR9VmLwCcDlgTFNtKKihkLxRC6drFu89D 8OcAoJG+97V3lJbh4piktML92+sbmj3o =0TSg -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-09-10 a las 22:19 +0200, carlopmart escribió:
Si, pero en cuanto reboto las máquinas vuelve a salir. El script que la inserta es el ifup-route, pero no veo dentro ningún parámetro para anular esto ... fastidia porque varios firewalls e IPS están detectando esto y los logs crecen ... Podría hacer que no registrasen esta entrada pero antonces asumo riesgos que quiero evitar ...
Hay una referencia en "/etc/sysconfig/network/config":
## Type: string("off","guess","auto-off","auto-manual","manual") ## Default: "off" # # !!!This feature is still not implemented. Leave it to 'off'!!! # What shall we do if there is no valid configuration? # off: do nothing, just fail # guess: try to guess the needed info (zeroconf) # auto-off: trigger automatic creation of a config file; if that fails, do # nothing, just fail # auto-manual: trigger automatic creation of a config file; if that fails, ask # user to provide configuration (via yast) # manual: ask user to provide configuration (via yast) # !!!This feature is still not implemented. Leave it to 'off'!!! FAILURE_ACTION=off
Y otra en "/etc/sysconfig/SuSEfirewall2.d/services/avahi" que a lo mejor puede servir para bloquearlo.
No tengo esas opciones ya que en ninguna de las SuSE tengo instalado ni SuSEfirewall2 ni avahi ... -- 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
carlopmart wrote:
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-09-10 a las 22:19 +0200, carlopmart escribió:
Si, pero en cuanto reboto las máquinas vuelve a salir. El script que la inserta es el ifup-route, pero no veo dentro ningún parámetro para anular esto ... fastidia porque varios firewalls e IPS están detectando esto y los logs crecen ... Podría hacer que no registrasen esta entrada pero antonces asumo riesgos que quiero evitar ...
Hay una referencia en "/etc/sysconfig/network/config":
## Type: string("off","guess","auto-off","auto-manual","manual") ## Default: "off" # # !!!This feature is still not implemented. Leave it to 'off'!!! # What shall we do if there is no valid configuration? # off: do nothing, just fail # guess: try to guess the needed info (zeroconf) # auto-off: trigger automatic creation of a config file; if that fails, do # nothing, just fail # auto-manual: trigger automatic creation of a config file; if that fails, ask # user to provide configuration (via yast) # manual: ask user to provide configuration (via yast) # !!!This feature is still not implemented. Leave it to 'off'!!! FAILURE_ACTION=off
Y otra en "/etc/sysconfig/SuSEfirewall2.d/services/avahi" que a lo mejor puede servir para bloquearlo.
No tengo esas opciones ya que en ninguna de las SuSE tengo instalado ni SuSEfirewall2 ni avahi ...
A ver, el script que llama a la ruta es el ifup-route, en esta parte de código: # Calling 'ip' if there is no interface (ifdown called from udev for remove # event) would trigger automatic module loading (Bug 199456) if [ -d /sys/class/net/$INTERFACE ] ; then # Don't add this route if interface has no v4 address (Bug 65557) test -z "`ip -4 a l dev $INTERFACE 2>/dev/null`" && islinklocal= if test -n "$islinklocal" ; then current=`ip -4 route show 169.254.0.0/16` if test -z "$current" -o "$current" != "${current/ dev $INTERFACE }"; then EXTRALINKLOCAL="169.254.0.0/16 - - $INTERFACE" fi fi fi Pero como dice que se llamará al comando ip si no existe interfaz o bin no tiene ip asignada, no entiendo porque la inserta si estos servidores tienen 4 interfaces cada uno con sus correspondientes IPs ... -- 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
El 2009-09-11 a las 00:04 +0200, carlopmart escribió:
A ver, el script que llama a la ruta es el ifup-route, en esta parte de código:
# Calling 'ip' if there is no interface (ifdown called from udev for remove # event) would trigger automatic module loading (Bug 199456) if [ -d /sys/class/net/$INTERFACE ] ; then # Don't add this route if interface has no v4 address (Bug 65557) test -z "`ip -4 a l dev $INTERFACE 2>/dev/null`" && islinklocal= if test -n "$islinklocal" ; then current=`ip -4 route show 169.254.0.0/16` if test -z "$current" -o "$current" != "${current/ dev $INTERFACE }"; then EXTRALINKLOCAL="169.254.0.0/16 - - $INTERFACE" fi fi fi
Pero como dice que se llamará al comando ip si no existe interfaz o bin no tiene ip asignada, no entiendo porque la inserta si estos servidores tienen 4 interfaces cada uno con sus correspondientes IPs ...
Ese es. Pero yo creo que sería mejor crear un script para que elimine la ruta y ponerlo en un sitio aparte para que se ejecute al iniciar el sistema antes que meter la mano por aquí :-/ Aunque sea más chapucero, es más "limpio", está "controlado" y lo puedes eliminar cuando quieras. P.S. Creo que a mi no me aperece la ruta esa del zeroconf porque tengo las interfaces configuradas en bonding O:-) 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
Camaleón wrote:
El 2009-09-11 a las 00:04 +0200, carlopmart escribió:
A ver, el script que llama a la ruta es el ifup-route, en esta parte de código:
# Calling 'ip' if there is no interface (ifdown called from udev for remove # event) would trigger automatic module loading (Bug 199456) if [ -d /sys/class/net/$INTERFACE ] ; then # Don't add this route if interface has no v4 address (Bug 65557) test -z "`ip -4 a l dev $INTERFACE 2>/dev/null`" && islinklocal= if test -n "$islinklocal" ; then current=`ip -4 route show 169.254.0.0/16` if test -z "$current" -o "$current" != "${current/ dev $INTERFACE }"; then EXTRALINKLOCAL="169.254.0.0/16 - - $INTERFACE" fi fi fi
Pero como dice que se llamará al comando ip si no existe interfaz o bin no tiene ip asignada, no entiendo porque la inserta si estos servidores tienen 4 interfaces cada uno con sus correspondientes IPs ...
Ese es.
Pero yo creo que sería mejor crear un script para que elimine la ruta y ponerlo en un sitio aparte para que se ejecute al iniciar el sistema antes que meter la mano por aquí :-/
Aunque sea más chapucero, es más "limpio", está "controlado" y lo puedes eliminar cuando quieras.
P.S. Creo que a mi no me aperece la ruta esa del zeroconf porque tengo las interfaces configuradas en bonding O:-)
Saludos,
Bastaria con ejecutar un "ip ro delete" en rc.local (aunque aún así ya me salta alerta en un firewall) ... pero me tiene muy mosqueado el que no se puede deshabilitar -- 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
El 2009-09-11 a las 00:31 +0200, carlopmart escribió:
Camaleón wrote:
# Calling 'ip' if there is no interface (ifdown called from udev for remove # event) would trigger automatic module loading (Bug 199456)
(...)
Pero como dice que se llamará al comando ip si no existe interfaz o bin no tiene ip asignada, no entiendo porque la inserta si estos servidores tienen 4 interfaces cada uno con sus correspondientes IPs ...
Hum... lo que dice es que "si se llama a 'ip' y no existe ninguna interfaz activaría automáticamente la carga del módulo" (y encima no se puede acceder al bug :-/), pero es como una especie de aclaración, la idea es activar la ruta zeroconf en cualquier caso pero evitando tropezar con ese bug que no vemos: # # add special link local route # can configure only one interface this way at the moment # EXTRALINKLOCAL= islinklocal= if test -n "$LINKLOCAL_INTERFACES" ; then eval "case \$INTERFACE in $LINKLOCAL_INTERFACES) islinklocal=true ;; esac" fi Al menos una de las interfaces activa la ruta link-local (en tu caso eth0), eso es lo que hace el script. (...)
Bastaria con ejecutar un "ip ro delete" en rc.local (aunque aún así ya me salta alerta en un firewall) ... pero me tiene muy mosqueado el que no se puede deshabilitar
Ojo, que también está en "ifdown-route" y en "ifstatus-route" así que debería estar contemplado desactivarlo modificando una variable de manera global, pero no veo esa opción por ninguna parte :-? 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
Camaleón wrote:
El 2009-09-11 a las 00:31 +0200, carlopmart escribió:
Camaleón wrote:
# Calling 'ip' if there is no interface (ifdown called from udev for remove # event) would trigger automatic module loading (Bug 199456)
(...)
Pero como dice que se llamará al comando ip si no existe interfaz o bin no tiene ip asignada, no entiendo porque la inserta si estos servidores tienen 4 interfaces cada uno con sus correspondientes IPs ...
Hum... lo que dice es que "si se llama a 'ip' y no existe ninguna interfaz activaría automáticamente la carga del módulo" (y encima no se puede acceder al bug :-/), pero es como una especie de aclaración, la idea es activar la ruta zeroconf en cualquier caso pero evitando tropezar con ese bug que no vemos:
# # add special link local route # can configure only one interface this way at the moment # EXTRALINKLOCAL= islinklocal= if test -n "$LINKLOCAL_INTERFACES" ; then eval "case \$INTERFACE in $LINKLOCAL_INTERFACES) islinklocal=true ;; esac" fi
Al menos una de las interfaces activa la ruta link-local (en tu caso eth0), eso es lo que hace el script.
(...)
Bastaria con ejecutar un "ip ro delete" en rc.local (aunque aún así ya me salta alerta en un firewall) ... pero me tiene muy mosqueado el que no se puede deshabilitar
Ojo, que también está en "ifdown-route" y en "ifstatus-route" así que debería estar contemplado desactivarlo modificando una variable de manera global, pero no veo esa opción por ninguna parte :-?
Saludos,
Mismamente es a eso a lo que voy, pero no me he expresado bien. En las distros basadas en rpm que conzoco esa variable es NOZEROCONF que se inserta en /etc/sysconfig/network -- 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
El 2009-09-11 a las 00:58 +0200, carlopmart escribió:
Camaleón wrote:
(...)
Ojo, que también está en "ifdown-route" y en "ifstatus-route" así que debería estar contemplado desactivarlo modificando una variable de manera global, pero no veo esa opción por ninguna parte :-?
Mismamente es a eso a lo que voy, pero no me he expresado bien. En las distros basadas en rpm que conzoco esa variable es NOZEROCONF que se inserta en /etc/sysconfig/network
Sí, te has expresado bien, pero en suse, por lo que sea, no funciona :-) Se podría crear un openfate o un bugzilla para que fuera posible activar/desactivar fácilmente esa ruta :-? 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-11 a las 00:49 +0200, Camaleón escribió:
El 2009-09-11 a las 00:31 +0200, carlopmart escribió:
Hum... lo que dice es que "si se llama a 'ip' y no existe ninguna interfaz activaría automáticamente la carga del módulo" (y encima no se puede acceder al bug :-/), pero es como una especie de aclaración, la idea es activar la ruta zeroconf en cualquier caso pero evitando tropezar con ese bug que no vemos:
Ojo una cosa. Lo que se activa es una ruta, no la IP en la tarjeta. Eso podría servir para hablar con otros ordenadores que tengan una IP en zeroconf, no que el nuestro tenga activo zeroconf. Está a la escucha por si otros lo hacen, con una ruta definida por si hay ordenadores usando ips de zeroconf. Yo creo que no hace falta quitar esa IP. Si estorba, lo que se hace es evitar que _otros_ usen zeroconf, por ejemplo, bloqueando sus paquetes en el cortafuegos. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqp2ZgACgkQtTMYHG2NR9W2cwCfTnXLhi/4CEhNT6TnYQ77cxYY WCMAnArttekM8393Gzz29ji8hSujp6UX =9BL6 -----END PGP SIGNATURE-----
El 2009-09-11 a las 07:01 +0200, Carlos E. R. escribió:
El 2009-09-11 a las 00:49 +0200, Camaleón escribió:
El 2009-09-11 a las 00:31 +0200, carlopmart escribió:
Hum... lo que dice es que "si se llama a 'ip' y no existe ninguna interfaz activaría automáticamente la carga del módulo" (y encima no se puede acceder al bug :-/), pero es como una especie de aclaración, la idea es activar la ruta zeroconf en cualquier caso pero evitando tropezar con ese bug que no vemos:
Ojo una cosa.
Lo que se activa es una ruta, no la IP en la tarjeta.
De eso hablamos, de la ruta que se genera automáticamente al iniciarse la red :-). La "ip" a la que se refiere el script es al comando "ip" no a una dirección.
Eso podría servir para hablar con otros ordenadores que tengan una IP en zeroconf, no que el nuestro tenga activo zeroconf. Está a la escucha por si otros lo hacen, con una ruta definida por si hay ordenadores usando ips de zeroconf.
Yo creo que no hace falta quitar esa IP.
No es una ip, es la tabla de rutas. Además, tampoco veo una forma sencilla de poder definir la interfaz (eth0, eth1, eth2...) en la que se quiere tener activada el zeroconf. Podría interesar que en lugar de eth0 estuviera en eth3, por ejemplo.
Si estorba, lo que se hace es evitar que _otros_ usen zeroconf, por ejemplo, bloqueando sus paquetes en el cortafuegos.
Más que estorbo, es curiosidad (en mi caso). Pero concuerdo con carlopmart en que se debería poder desactivar sin tener que hacer malabares. Servicio o configuración que no use, mejor tenerlo desactivado, y más en un servidor :-/ 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Reenviado por culpa del apagón - intento anterior Fri, 11 Sep 2009 15:48:00 +0200] El 2009-09-11 a las 08:04 +0200, Camaleón escribió:
El 2009-09-11 a las 07:01 +0200, Carlos E. R. escribió:
El 2009-09-11 a las 00:49 +0200, Camaleón escribió:
El 2009-09-11 a las 00:31 +0200, carlopmart escribió:
Hum... lo que dice es que "si se llama a 'ip' y no existe ninguna interfaz activaría automáticamente la carga del módulo" (y encima no se puede acceder al bug :-/), pero es como una especie de aclaración, la idea es activar la ruta zeroconf en cualquier caso pero evitando tropezar con ese bug que no vemos:
Ojo una cosa.
Lo que se activa es una ruta, no la IP en la tarjeta.
De eso hablamos, de la ruta que se genera automáticamente al iniciarse la red :-). La "ip" a la que se refiere el script es al comando "ip" no a una dirección.
Pero el problema original eran paquetes en el cortafuegos generando lineas de registro. Esos paquetes no los origina esa maquina suse.
Eso podría servir para hablar con otros ordenadores que tengan una IP en zeroconf, no que el nuestro tenga activo zeroconf. Está a la escucha por si otros lo hacen, con una ruta definida por si hay ordenadores usando ips de zeroconf.
Yo creo que no hace falta quitar esa IP.
No es una ip, es la tabla de rutas. Además, tampoco veo una forma sencilla de poder definir la interfaz (eth0, eth1, eth2...) en la que se quiere tener activada el zeroconf. Podría interesar que en lugar de eth0 estuviera en eth3, por ejemplo.
Lapsus linguae. Donde dije "IP" quise decir "ruta".
Si estorba, lo que se hace es evitar que _otros_ usen zeroconf, por ejemplo, bloqueando sus paquetes en el cortafuegos.
Más que estorbo, es curiosidad (en mi caso). Pero concuerdo con carlopmart en que se debería poder desactivar sin tener que hacer malabares. Servicio o configuración que no use, mejor tenerlo desactivado, y más en un servidor :-/
Lo único que está activo es la preparación por si otros lo usan, no usarlo nosotros. Es pasivo totalmente. Imaginate que hubiera ordenadores con zeroconf en esa red y que hiciesen peticiones de ficheros al servidor: sin esa ruta, no conectarían con tu servidor. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqsw9IACgkQtTMYHG2NR9Uo7ACgk6xdYXzwskFDSCNV7IB3Mx2I 5BcAnj/f0LcJ6BrbUVYjXvsT840eE/BT =jDz5 -----END PGP SIGNATURE-----
El 2009-09-13 a las 12:05 +0200, Carlos E. R. escribió:
[Reenviado por culpa del apagón - intento anterior Fri, 11 Sep 2009 15:48:00 +0200]
¿Ya funciona el servidor de la lista? :-?
El 2009-09-11 a las 08:04 +0200, Camaleón escribió:
De eso hablamos, de la ruta que se genera automáticamente al iniciarse la red :-). La "ip" a la que se refiere el script es al comando "ip" no a una dirección.
Pero el problema original eran paquetes en el cortafuegos generando lineas de registro. Esos paquetes no los origina esa maquina suse.
¿A cuálo? :-? La pregunta era cómo desactivar esa ruta que se genera al iniciar la red. Y no es cuestión baladí, desactivarla o configurarla puede tener varios propósitos >:-)
Yo creo que no hace falta quitar esa IP.
No es una ip, es la tabla de rutas. Además, tampoco veo una forma sencilla de poder definir la interfaz (eth0, eth1, eth2...) en la que se quiere tener activada el zeroconf. Podría interesar que en lugar de eth0 estuviera en eth3, por ejemplo.
Lapsus linguae. Donde dije "IP" quise decir "ruta".
Ahhh :-)
Más que estorbo, es curiosidad (en mi caso). Pero concuerdo con carlopmart en que se debería poder desactivar sin tener que hacer malabares. Servicio o configuración que no use, mejor tenerlo desactivado, y más en un servidor :-/
Lo único que está activo es la preparación por si otros lo usan, no usarlo nosotros. Es pasivo totalmente.
Pasivo o activo, es igual. Tiene que haber una forma sencilla para que no se genere. Es algo que debe depender del administrador del sistema.
Imaginate que hubiera ordenadores con zeroconf en esa red y que hiciesen peticiones de ficheros al servidor: sin esa ruta, no conectarían con tu servidor.
Que les den morcilla :-) Suponte ahora que esos equipos que piden una ruta accesible no tienen buenas intenciones precisamente. ¿Les dices por dónde tiene que ir para llegar al destino? >>:-P No, mira, esto es como lo del UPnP ese, yo prefiero desactivarlo. Si alguien se queja, que se identifique primero y yo le abro "la aduana". 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 2009-09-13 a las 12:05 +0200, Carlos E. R. escribió:
[Reenviado por culpa del apagón - intento anterior Fri, 11 Sep 2009 15:48:00 +0200]
¿Ya funciona el servidor de la lista? :-?
Ni idea. Ahora ya sé que sí funciona >:-) Mi correo llegó a suse a las 12:05:10, y ellos lo enviaron a tesa a las 12:48:15 (+0200)
El 2009-09-11 a las 08:04 +0200, Camaleón escribió:
De eso hablamos, de la ruta que se genera automáticamente al iniciarse la red :-). La "ip" a la que se refiere el script es al comando "ip" no a una dirección.
Pero el problema original eran paquetes en el cortafuegos generando lineas de registro. Esos paquetes no los origina esa maquina suse.
¿A cuálo? :-?
Eso era lo que le molestaba a carlopmart, eso dijo.
La pregunta era cómo desactivar esa ruta que se genera al iniciar la red. Y no es cuestión baladí, desactivarla o configurarla puede tener varios propósitos >:-)
Simplemente añade un servicio que arranque después de la red para que lo borre. Si no sabes a que me refiero, RTFM, pregunta luego por cual ;-) Es que quiero echarme la siesta O:-)
Más que estorbo, es curiosidad (en mi caso). Pero concuerdo con carlopmart en que se debería poder desactivar sin tener que hacer malabares. Servicio o configuración que no use, mejor tenerlo desactivado, y más en un servidor :-/
Lo único que está activo es la preparación por si otros lo usan, no usarlo nosotros. Es pasivo totalmente.
Pasivo o activo, es igual. Tiene que haber una forma sencilla para que no se genere. Es algo que debe depender del administrador del sistema.
Imaginate que hubiera ordenadores con zeroconf en esa red y que hiciesen peticiones de ficheros al servidor: sin esa ruta, no conectarían con tu servidor.
Que les den morcilla :-)
Suponte ahora que esos equipos que piden una ruta accesible no tienen buenas intenciones precisamente. ¿Les dices por dónde tiene que ir para llegar al destino? >>:-P
No, lo que dices es a tu ordenador cómo llegar a ellos. Es distinto.
No, mira, esto es como lo del UPnP ese, yo prefiero desactivarlo. Si alguien se queja, que se identifique primero y yo le abro "la aduana".
Pues cierra el cortafuegos. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqtD90ACgkQtTMYHG2NR9WQ4wCfYZ3VmkSPFIcs1sC595f2ULol 9Q8AoJdcdmY6czHX/DasCourkixYut0/ =VAgH -----END PGP SIGNATURE-----
El 2009-09-13 a las 17:29 +0200, Carlos E. R. escribió:
El 2009-09-13 a las 13:00 +0200, Camaleón escribió:
Pero el problema original eran paquetes en el cortafuegos generando lineas de registro. Esos paquetes no los origina esa maquina suse.
¿A cuálo? :-?
Eso era lo que le molestaba a carlopmart, eso dijo.
Lee el asunto del correo.
La pregunta era cómo desactivar esa ruta que se genera al iniciar la red. Y no es cuestión baladí, desactivarla o configurarla puede tener varios propósitos >:-)
Simplemente añade un servicio que arranque después de la red para que lo borre. Si no sabes a que me refiero, RTFM, pregunta luego por cual ;-)
No hace falta que seas tan desagradable. Esa opción ya la comentamos *hace días*, por cierto.
Es que quiero echarme la siesta O:-)
Suponte ahora que esos equipos que piden una ruta accesible no tienen buenas intenciones precisamente. ¿Les dices por dónde tiene que ir para llegar al destino? >>:-P
No, lo que dices es a tu ordenador cómo llegar a ellos. Es distinto.
No, mira, esto es como lo del UPnP ese, yo prefiero desactivarlo. Si alguien se queja, que se identifique primero y yo le abro "la aduana".
Pues cierra el cortafuegos.
Las rutas no tienen nada que ver con el cortafuegos. Además, el ataque puede venir desde dentro de la lan. 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
Camaleón wrote:
El 2009-09-13 a las 17:29 +0200, Carlos E. R. escribió:
El 2009-09-13 a las 13:00 +0200, Camaleón escribió:
Pero el problema original eran paquetes en el cortafuegos generando lineas de registro. Esos paquetes no los origina esa maquina suse. ¿A cuálo? :-? Eso era lo que le molestaba a carlopmart, eso dijo.
Lee el asunto del correo.
La pregunta era cómo desactivar esa ruta que se genera al iniciar la red. Y no es cuestión baladí, desactivarla o configurarla puede tener varios propósitos >:-) Simplemente añade un servicio que arranque después de la red para que lo borre. Si no sabes a que me refiero, RTFM, pregunta luego por cual ;-)
No hace falta que seas tan desagradable.
Esa opción ya la comentamos *hace días*, por cierto.
Es que quiero echarme la siesta O:-)
Suponte ahora que esos equipos que piden una ruta accesible no tienen buenas intenciones precisamente. ¿Les dices por dónde tiene que ir para llegar al destino? >>:-P No, lo que dices es a tu ordenador cómo llegar a ellos. Es distinto.
No, mira, esto es como lo del UPnP ese, yo prefiero desactivarlo. Si alguien se queja, que se identifique primero y yo le abro "la aduana". Pues cierra el cortafuegos.
Las rutas no tienen nada que ver con el cortafuegos.
Además, el ataque puede venir desde dentro de la lan.
Saludos,
Subscribo lo dicho por Camaleon. Carlos E.R., lo que ha hecho Novell con la opcion zeroconf es una chapuza, igual que lo que comentasteis hace dias de deshabilitar el ssh una vez realizada la instalación. Aquí se trata de SERVIDORES y no estaciones de trabajo usadas por windows-users. El control total lo debe tener un administrador (no Novell) y no tiene porque pelear con cosas que Novell no sabe implantar (no es que no deba o quiera, es que yo llego a la conclusión que no saben más). Estoy tratando de abrir un bugzilla de SLES (ya que con openSuSE desisto porque me sacarán el tema de los usuarios noveles), pero no hay forma. ¿Sabe alguien si con licencia trial es posible abrir bugzilla? Gracias. -- 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
El 2009-09-13 a las 19:26 +0200, carlopmart escribió:
Camaleón wrote:
Pues cierra el cortafuegos. Las rutas no tienen nada que ver con el cortafuegos. Además, el ataque puede venir desde dentro de la lan. Saludos,
Subscribo lo dicho por Camaleon. Carlos E.R., lo que ha hecho Novell con la opcion zeroconf es una chapuza, igual que lo que comentasteis hace dias de deshabilitar el ssh una vez realizada la instalación.
Aquí se trata de SERVIDORES y no estaciones de trabajo usadas por windows-users. El control total lo debe tener un administrador (no Novell) y no tiene porque pelear con cosas que Novell no sabe implantar (no es que no deba o quiera, es que yo llego a la conclusión que no saben más).
Bueno, de momento lo único que sabemos es que "no sabemos" cómo hacerlo, lo cual no quiere decir que no se pueda hacer :-) Quizá haya algún parámetro escondido que permita desactivar la ruta del zeroconf pero al menos yo desconozco cúal es y dónde ponerlo. Al menos en el manual de "ifcfg" no encuentro referencia alguna al valor "nozeroconf" y no aparece como parámetro admitido en el archivo de definición de las interfaces, que entiendo sería el lugar adecuado para configurarlo. También desconocemos los motivos de por qué esta omisión y tampoco he encontrado documentación alguna al respecto :-?
Estoy tratando de abrir un bugzilla de SLES (ya que con openSuSE desisto porque me sacarán el tema de los usuarios noveles), pero no hay forma. ¿Sabe alguien si con licencia trial es posible abrir bugzilla?
No sé cuáles son los requisitos para poner bugzillas sobre SLES, pero deberías poner un bugzilla para openSUSE 11.1, no tanto con la finalidad de que hagan algún cambio, sino sencillamente para sacar el tema, para saber si es posible configurarlo de alguna forma más "elegante" (aka, al estilo suse) y en el caso de que no sea posible, pues al menos sabremos los motivos y podremos criticarlos (o compartirlos) pero siempre con "conocimiento de causa" porque ahora sólo podemos "especular" :-) 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
El 13/09/09, Camaleón escribió:
Bueno, de momento lo único que sabemos es que "no sabemos" cómo hacerlo, lo cual no quiere decir que no se pueda hacer :-)
Vale. Misterio resuelto. Al final Carlos E. R. tenía razón... había que leer el j* manual. No exactamente el manual de los scripts de inicio, pero bueno, había que leer... O:-P man ifcfg Apartado "General variables" LINKLOCAL_INTERFACES Para ver las opciones hay que ir a /etc/sysconfig/network/config ## Type: string ## Default: "eth*[0-9]|tr*[0-9]|wlan[0-9]|ath[0-9]" # # Automatically add a linklocal route to the matching interfaces. # This string is used in a bash "case" statement, so it may contain # '*', '[', ']' and '|' meta-characters. # LINKLOCAL_INTERFACES="eth*[0-9]|tr*[0-9]|wlan[0-9]|ath[0-9]" Si se comenta "#" esa opción, ya no se genera ninguna ruta al reiniciar el equipo. Además, se puede configurar en qué interfaz en concreto se va a generar esa ruta del zeroconf. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-14 a las 00:15 +0200, Camaleón escribió:
Vale. Misterio resuelto.
Al final Carlos E. R. tenía razón... había que leer el j* manual. No exactamente el manual de los scripts de inicio, pero bueno, había que leer... O:-P
man ifcfg
Apartado "General variables" LINKLOCAL_INTERFACES
Anda, mira...
LINKLOCAL_INTERFACES="eth*[0-9]|tr*[0-9]|wlan[0-9]|ath[0-9]"
Si se comenta "#" esa opción, ya no se genera ninguna ruta al reiniciar el equipo. Además, se puede configurar en qué interfaz en concreto se va a generar esa ruta del zeroconf.
Interesante. Apuntado. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqtemkACgkQtTMYHG2NR9Xq6wCeJTE3qqkFbo+YmyVKfpfI9Sq8 viUAoJeICAmJ7YYMfYbonW56bQaVvBG6 =nF11 -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-09-14 a las 00:15 +0200, Camaleón escribió:
Vale. Misterio resuelto.
Al final Carlos E. R. tenía razón... había que leer el j* manual. No exactamente el manual de los scripts de inicio, pero bueno, había que leer... O:-P
man ifcfg
Apartado "General variables" LINKLOCAL_INTERFACES
Anda, mira...
LINKLOCAL_INTERFACES="eth*[0-9]|tr*[0-9]|wlan[0-9]|ath[0-9]"
Si se comenta "#" esa opción, ya no se genera ninguna ruta al reiniciar el equipo. Además, se puede configurar en qué interfaz en concreto se va a generar esa ruta del zeroconf.
Interesante. Apuntado.
Lo pruebo y digo algo con respecto a SLES, pero espero que no omita el resto de rutas ... -- 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
El 2009-09-14 a las 09:25 +0200, carlopmart escribió:
Carlos E. R. wrote:
El 2009-09-14 a las 00:15 +0200, Camaleón escribió:
Vale. Misterio resuelto.
Al final Carlos E. R. tenía razón... había que leer el j* manual. No exactamente el manual de los scripts de inicio, pero bueno, había que leer... O:-P
man ifcfg
Apartado "General variables" LINKLOCAL_INTERFACES Anda, mira... LINKLOCAL_INTERFACES="eth*[0-9]|tr*[0-9]|wlan[0-9]|ath[0-9]"
Si se comenta "#" esa opción, ya no se genera ninguna ruta al reiniciar el equipo. Además, se puede configurar en qué interfaz en concreto se va a generar esa ruta del zeroconf. Interesante. Apuntado.
Lo pruebo y digo algo con respecto a SLES, pero espero que no omita el resto de rutas ...
En teoría sólo debe afectar a la ruta del zeroconf, tanto en su creación como en su configuración, pero no al resto. Vaya, que este es (o debería ser) el "eslabón perdido" que estábamos buscando :-) Ahora bien, lo de "comentar" (#) esa línea es cosa mía, es decir, que no lo veo documentado por ninguna parte, así que... ¿efectos secundarios? pues a saber. Para mi gusto le faltaría un valor posible más para esa variable ("disable|off|none|0"), así se daría a entender que la desactivación del zeroconf está contemplada a todos los efectos. 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 2009-09-13 a las 17:29 +0200, Carlos E. R. escribió:
El 2009-09-13 a las 13:00 +0200, Camaleón escribió:
Pero el problema original eran paquetes en el cortafuegos generando lineas de registro. Esos paquetes no los origina esa maquina suse.
¿A cuálo? :-?
Eso era lo que le molestaba a carlopmart, eso dijo.
Lee el asunto del correo.
Dijo: ] Si, pero en cuanto reboto las máquinas vuelve a salir. El script que la ] inserta es el ifup-route, pero no veo dentro ningún parámetro para ] anular esto ... fastidia porque varios firewalls e IPS están detectando ] esto y los logs crecen ... Podría hacer que no registrasen esta entrada ] pero antonces asumo riesgos que quiero evitar ...
La pregunta era cómo desactivar esa ruta que se genera al iniciar la red. Y no es cuestión baladí, desactivarla o configurarla puede tener varios propósitos >:-)
Simplemente añade un servicio que arranque después de la red para que lo borre. Si no sabes a que me refiero, RTFM, pregunta luego por cual ;-)
No hace falta que seas tan desagradable.
Ya'tamos. No seas tan mal pensada. No estoy siendo desgradable, no te lo tomes por ahí. Dije que no tenía tiempo para explicarlo con detalle, pero os dí las pistas suficientes para encontrarlo. Creais un script: /etc/inid.d/anularzeroconf Como punto de partida se puede usar el "skeleton", cambiandolo adecuadamente: ### BEGIN INIT INFO # Provides: anularzeroconf # Required-Start: $local_fs $remote_fs $syslog $network # Required-Stop: $local_fs $remote_fs $syslog $network # Y en la sección "start" se pone la orden para borrar la ruta. Esto se ejecutará siempre que se arranque el ordenador, y problema resuelto. Y si os hace falta ayuda para saber como se inserta ese script, pues está en el manual, o preguntad. No te tomes a la tremenda lo de rtfm, me refería simplemente a eso, porque no tenía tiempo de explicarlo en detalle. No pienses tan mal de mí.
Esa opción ya la comentamos *hace días*, por cierto.
No, no lo hicisteis. Si se habló de como borrar la ruta, pero no de como hacerlo siempre al arrancar. Observa que "boot.local" no os vale. Yo os estoy diciendo donde hay que poner la orden para que se mantenga activa siempre. En realidad, el sitio más correcto para hacerlo es un script en "/etc/sysconfig/network/if-up.d", o mejor dicho, un script en "/etc/sysconfig/network/scripts" con enlace simbólico al anterior. El punto de partida podría ser "ifup-route" (para ejecutarlo después), o "ifup-skel". Pero nunca lo he hecho, personalmente.
Es que quiero echarme la siesta O:-)
Suponte ahora que esos equipos que piden una ruta accesible no tienen buenas intenciones precisamente. ¿Les dices por dónde tiene que ir para llegar al destino? >>:-P
No, lo que dices es a tu ordenador cómo llegar a ellos. Es distinto.
No, mira, esto es como lo del UPnP ese, yo prefiero desactivarlo. Si alguien se queja, que se identifique primero y yo le abro "la aduana".
Pues cierra el cortafuegos.
Las rutas no tienen nada que ver con el cortafuegos.
Las rutas no se emplean si no entran paquetes. Quitar la ruta no os va a proteger de ningún peligro potencial que pueda suponer lo del zeroconf; el cortafuegos sí. De eso es de lo que teneis que preocuparos, del cortafuegos, no de las rutas.
Además, el ataque puede venir desde dentro de la lan.
Precisamente. Dentro de la lan es cuando más hace falta cortafuegos >:-P - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqtW1EACgkQtTMYHG2NR9UcyQCcCU7voWPy5E6jv6x09TYSTrp6 RjIAnjyngY1lwuhNRxbmyxH/R4NEcF8W =682u -----END PGP SIGNATURE-----
El 2009-09-13 a las 22:51 +0200, Carlos E. R. escribió:
El 2009-09-13 a las 17:42 +0200, Camaleón escribió:
Lee el asunto del correo.
Dijo:
] Si, pero en cuanto reboto las máquinas vuelve a salir. El script que la ] inserta es el ifup-route, pero no veo dentro ningún parámetro para ] anular esto ... fastidia porque varios firewalls e IPS están detectando ] esto y los logs crecen ... Podría hacer que no registrasen esta entrada ] pero antonces asumo riesgos que quiero evitar ...
¿Y no crees que pudiera ser de utilidad más allá de para "ese" caso en concreto? De lo que estamos hablando es de poder configurar una opción, no de los motivos que tenga cada cual para hacerlo.
Simplemente añade un servicio que arranque después de la red para que lo borre. Si no sabes a que me refiero, RTFM, pregunta luego por cual ;-)
No hace falta que seas tan desagradable.
Ya'tamos. No seas tan mal pensada.
No he sido yo quien ha dicho eso.
No estoy siendo desgradable, no te lo tomes por ahí. Dije que no tenía tiempo para explicarlo con detalle, pero os dí las pistas suficientes para encontrarlo.
Creais un script: /etc/inid.d/anularzeroconf
Que eso ya lo hemos planteado, no se trata de crear un script que elimine la ruta cada vez que se inicia el servicio de red sino de por qué no existe una opción similar a la que tienen en RedHat. (...)
Esa opción ya la comentamos *hace días*, por cierto.
No, no lo hicisteis. Si se habló de como borrar la ruta, pero no de como hacerlo siempre al arrancar.
No hablamos de eso, Carlos, no te empeñes en algo que no estamos debatiendo. No hablamos de "cómo" hacerlo sino de "por qué" no es configurable. Ya sabemos que se puede hacer pero no sabemos por qué no lo ha integrado openSUSE en su configuración habitual, a través de los archivos de sysconfig.
Las rutas no tienen nada que ver con el cortafuegos.
Las rutas no se emplean si no entran paquetes. Quitar la ruta no os va a proteger de ningún peligro potencial que pueda suponer lo del zeroconf; el cortafuegos sí. De eso es de lo que teneis que preocuparos, del cortafuegos, no de las rutas.
Nadie ha sacado el tema de la seguridad excepto tú. Nosotros sólo queremos saber por qué no está contemplado (si no lo está, que yo desde luego no lo sé) la desactivación y/o configuración del zeroconf en opensuse. ¿Lo sabes tú?
Además, el ataque puede venir desde dentro de la lan.
Precisamente. Dentro de la lan es cuando más hace falta cortafuegos >:-P
Dentro de la lan las reglas del cortafuegos de opensuse son mucho más laxas. Y así podemos seguir hasta que te canses... 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 2009-09-13 a las 22:51 +0200, Carlos E. R. escribió:
El 2009-09-13 a las 17:42 +0200, Camaleón escribió:
Lee el asunto del correo.
Dijo:
] Si, pero en cuanto reboto las máquinas vuelve a salir. El script que la ] inserta es el ifup-route, pero no veo dentro ningún parámetro para ] anular esto ... fastidia porque varios firewalls e IPS están detectando ] esto y los logs crecen ... Podría hacer que no registrasen esta entrada ] pero antonces asumo riesgos que quiero evitar ...
¿Y no crees que pudiera ser de utilidad más allá de para "ese" caso en concreto?
De lo que estamos hablando es de poder configurar una opción, no de los motivos que tenga cada cual para hacerlo.
Vamos a ver, él dijo que lo que le molestaba era las entradas que se estaban generando en los cortafuegos. Entiendo que ese es el problema que tiene, no otro. Y el arreglo se supone que es eliminar zeroconf de la maquina suse. Es decir, hay un problema con las entradas del registro, y se busca cómo solucionarlo. Hay varias posibilidades, y yo hablo de una de ellas, la que sé.
Simplemente añade un servicio que arranque después de la red para que lo borre. Si no sabes a que me refiero, RTFM, pregunta luego por cual ;-)
No hace falta que seas tan desagradable.
Ya'tamos. No seas tan mal pensada.
No he sido yo quien ha dicho eso.
Tú eres la que ha has dicho que no sea desagradable... la F es de flipping, no seas mal pensada >:-P
No estoy siendo desgradable, no te lo tomes por ahí. Dije que no tenía tiempo para explicarlo con detalle, pero os dí las pistas suficientes para encontrarlo.
Creais un script: /etc/inid.d/anularzeroconf
Que eso ya lo hemos planteado, no se trata de crear un script que elimine la ruta cada vez que se inicia el servicio de red sino de por qué no existe una opción similar a la que tienen en RedHat.
Sí se trata. Dijisteis: ]> ¿Con "route del" no se eliminan rutas? :-? ]> ] Si, pero en cuanto reboto las máquinas vuelve a salir. El script que la ] inserta es el ifup-route, pero ... por tanto, yo explico una manera de que no vuelva a salir. Eso no se ha contado. ¿Que porqué no existe una opción al estilo de redhat? Ni idea, yo hablo de lo que sé, no de lo que no sé.
(...)
Esa opción ya la comentamos *hace días*, por cierto.
No, no lo hicisteis. Si se habló de como borrar la ruta, pero no de como hacerlo siempre al arrancar.
No hablamos de eso, Carlos, no te empeñes en algo que no estamos debatiendo. No hablamos de "cómo" hacerlo sino de "por qué" no es configurable. Ya sabemos que se puede hacer pero no sabemos por qué no lo ha integrado openSUSE en su configuración habitual, a través de los archivos de sysconfig.
¿Y yo que sé? Preguntadles a los de SuSE. Si no lo sabemos habrá que buscar otra manera, ¿no?
Las rutas no tienen nada que ver con el cortafuegos.
Las rutas no se emplean si no entran paquetes. Quitar la ruta no os va a proteger de ningún peligro potencial que pueda suponer lo del zeroconf; el cortafuegos sí. De eso es de lo que teneis que preocuparos, del cortafuegos, no de las rutas.
Nadie ha sacado el tema de la seguridad excepto tú.
Huy, sí, si lo habeis sacado. Dijo carlopmart: ] Podría hacer que no registrasen esta entrada pero antonces asumo ] riesgos que quiero evitar ... Habla de "riesgos".
Nosotros sólo queremos saber por qué no está contemplado (si no lo está, que yo desde luego no lo sé) la desactivación y/o configuración del zeroconf en opensuse.
¿Lo sabes tú?
Ya he dicho que no. Eso se lo teneis que preguntar a ellos. ¿Te has levantado con el pié izquierdo? Estás tiquismiquis hoy... :-)
Además, el ataque puede venir desde dentro de la lan.
Precisamente. Dentro de la lan es cuando más hace falta cortafuegos >:-P
Dentro de la lan las reglas del cortafuegos de opensuse son mucho más laxas. Y así podemos seguir hasta que te canses...
Hasa cierto punto. Las puedes poner más fuertes o quitarlas del todo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqtebsACgkQtTMYHG2NR9XGBwCePI46K0AI0VGMqJrUICtYiJCv MTEAn1nH8JfM8K7ee/EhSteoV1lFfnlJ =IiNR -----END PGP SIGNATURE-----
Carlos E. R. wrote:
Vamos a ver, él dijo que lo que le molestaba era las entradas que se estaban generando en los cortafuegos. Entiendo que ese es el problema que tiene, no otro. Y el arreglo se supone que es eliminar zeroconf de la maquina suse.
Es decir, hay un problema con las entradas del registro, y se busca cómo solucionarlo. Hay varias posibilidades, y yo hablo de una de ellas, la que sé.
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) 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. -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-14 a las 09:32 +0200, carlopmart escribió:
Carlos E. R. wrote:
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. El porqué no han previsto desactivarlo, pues te pueden decir que el objetivo de la opensuse no son servidores en empresas y que te está bien empleado :-P (y no, no estoy de acuerdo, pero te dirán eso).
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? 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. En cuanto a averiguar qué servicios presta el servidor, pues eso se puede hacer aunque no tengas linklocal. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqupjQACgkQtTMYHG2NR9VfmwCfbD2a02A2lcuwRMBjOieIco/w TzUAoIu8eM/bJzkzDA025JSYwLNjQ0et =fXLg -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-09-14 a las 09:32 +0200, carlopmart escribió:
Carlos E. R. wrote:
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.
El porqué no han previsto desactivarlo, pues te pueden decir que el objetivo de la opensuse no son servidores en empresas y que te está bien empleado :-P
(y no, no estoy de acuerdo, pero te dirán eso).
Ya, pero si miras mi correo inicial digo que eso pasa en openSuSE y en un SLES: y este es un servidor, o sea que gamba como una casa de Novell. Y también dije que no pensaba abrir un bugzilla en opensuse por el mismo motivo que dices ahora.
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 ...
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). 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é??
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 ...
- -- Saludos Carlos E. R.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkqupjQACgkQtTMYHG2NR9VfmwCfbD2a02A2lcuwRMBjOieIco/w TzUAoIu8eM/bJzkzDA025JSYwLNjQ0et =fXLg -----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
-----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-----
Carlos E. R. wrote:
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?
No, las SuSE insertan la ruta de zeroconf por lo tanto enviarán (y escucharán) un broadcast de vez en cuando. Ese broadcast es detectado por IPS y firewalls y como esa ruta no pertenece a ningún rango "controlado" por ellos y les está entrando por un direccionamiento legal, generan alertas de spoofing.
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.
Pero es que no es un error de mi red. TODOS los servers tienen asignado IP fija, no tienen que buscar ninguna IP, por lo tanto no deben ni pueden enviar paquetes a los gateways con esa segmentación de zeroconf .. ¿quien ha hablado aquí de 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.
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.
Si me tengo que preocupar. A mí generan una incidencia cada vez que hay un registro en los firewalls e IPS.
Espera, si dices que ofrecen otros servicios, un nmap los descubre.
No. Un nmap no puede descubrir nada. Por una sencilla razón: hasta que un usuario no se autentica, no vé el resto de servicios y además solo verá los servicios para los que a su perfil se le da acceso.
Públicos o privados, los descubre, si están en la red.
No. Hay varias formas por las cuales un nmap no consigue información de una red: ocultándosela, despistándole con cosas que no existen, etc. El nmap es efectivo si tiene al alcance los servicios, si no es nulo completamente como es este caso. Solo existe el riesgo que se desborde al servicio de ssh, y si lo hacen al estar el ssh configurado como chroot tampoco conseguirán gran cosa.
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.
Estamos hablando de una intranet, correcto. Pero una intranet un tanto peculiar. Aquí el tema es que se está hablando de un componente que un administrador decide si se activa o no, y no Novell o los desarrolladores de openSuSE deben tomar esa decisión. Es como lo que hablásteis hace días del ssh en la instalación y que comenté en otro email.
- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkquwI0ACgkQtTMYHG2NR9VviQCglHD92VO5Rpy5wG4xbtDg3kY1 NkkAniE06pk+ZNEjI7e72l4GbAIcg0eR =L4ri -----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
El 2009-09-15 a las 09:15 +0200, carlopmart escribió:
Aquí el tema es que se está hablando de un componente que un administrador decide si se activa o no, y no Novell o los desarrolladores de openSuSE deben tomar esa decisión. Es como lo que hablásteis hace días del ssh en la instalación y que comenté en otro email.
Ya sabes cómo desactivar y/o configurar la ruta del zeroconf... ¿cuál es la queja "ahora"? >:-) 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
Camaleón wrote:
El 2009-09-15 a las 09:15 +0200, carlopmart escribió:
Aquí el tema es que se está hablando de un componente que un administrador decide si se activa o no, y no Novell o los desarrolladores de openSuSE deben tomar esa decisión. Es como lo que hablásteis hace días del ssh en la instalación y que comenté en otro email.
Ya sabes cómo desactivar y/o configurar la ruta del zeroconf... ¿cuál es la queja "ahora"? >:-)
Saludos,
No es queja, estaba tratando de explicar el porqué no es una operación más trivial el desactivar el zeroconf. Saludos. -- 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
El 2009-09-15 a las 10:04 +0200, carlopmart escribió:
Camaleón wrote:
El 2009-09-15 a las 09:15 +0200, carlopmart escribió:
Aquí el tema es que se está hablando de un componente que un administrador decide si se activa o no, y no Novell o los desarrolladores de openSuSE deben tomar esa decisión. Es como lo que hablásteis hace días del ssh en la instalación y que comenté en otro email.
Ya sabes cómo desactivar y/o configurar la ruta del zeroconf... ¿cuál es la queja "ahora"? >:-)
No es queja, estaba tratando de explicar el porqué no es una operación más trivial el desactivar el zeroconf.
Bueno, ahora que ya sabemos cómo se hace, yo diría que es igual de trivial desactivarlo en RedHat que en SLES. 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Carlos E. R. wrote:
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?
No, las SuSE insertan la ruta de zeroconf por lo tanto enviarán (y escucharán) un broadcast de vez en cuando. Ese broadcast es detectado por IPS y firewalls y como esa ruta no pertenece a ningún rango "controlado" por ellos y les está entrando por un direccionamiento legal, generan alertas de spoofing.
Te equivocas. La inserción de la ruta no tiene que ver con el broadcast.
No veo de qué se quejan los administradores de esos routers.
Pero es que no es un error de mi red. TODOS los servers tienen asignado IP fija, no tienen que buscar ninguna IP, por lo tanto no deben ni pueden enviar paquetes a los gateways con esa segmentación de zeroconf ..
¿quien ha hablado aquí de routers??
El gateway es un tipo de router.
Pues entonces no tienes que preocuparte de nada.
Si me tengo que preocupar. A mí generan una incidencia cada vez que hay un registro en los firewalls e IPS.
Mándales a paseo :-P
Espera, si dices que ofrecen otros servicios, un nmap los descubre.
No. Un nmap no puede descubrir nada. Por una sencilla razón: hasta que un usuario no se autentica, no vé el resto de servicios y además solo verá los servicios para los que a su perfil se le da acceso.
Mmmm... - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqv4nEACgkQtTMYHG2NR9WbWwCdHQ2yE81/2uBBBN07tXMWGHdU IJ8AnRgvR5h9Wg5OaF4Ln7JYKCtklxop =x9Rx -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID:
El 2009-09-15 a las 09:15 +0200, carlopmart escribió:
Carlos E. R. wrote:
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?
No, las SuSE insertan la ruta de zeroconf por lo tanto enviarán (y escucharán) un broadcast de vez en cuando. Ese broadcast es detectado por IPS y firewalls y como esa ruta no pertenece a ningún rango "controlado" por ellos y les está entrando por un direccionamiento legal, generan alertas de spoofing.
Te equivocas. La inserción de la ruta no tiene que ver con el broadcast.
Neturalmente que no, a ver si me explico. Si yo conecto un laptop a ese segmento con zeroconf habilitado enviará paquetes al segmento via broadcast, por ende va a descubrir a esos dos servers en la red ¿si?
No veo de qué se quejan los administradores de esos routers.
Pero es que no es un error de mi red. TODOS los servers tienen asignado IP fija, no tienen que buscar ninguna IP, por lo tanto no deben ni pueden enviar paquetes a los gateways con esa segmentación de zeroconf ..
¿quien ha hablado aquí de routers??
El gateway es un tipo de router.
A ver: firewalls e IPS. ¿Donde he hablado yo de routers?. En ningún momento. Gateway es un término genérico para los dispositivos que saben enrutar paquetes entre otros menesteres, y eso engloba a firewalls. Pero yo no hablo nunca de routers (solo me faltaba administrar routers, me pego un tiro:)))
Pues entonces no tienes que preocuparte de nada.
Si me tengo que preocupar. A mí generan una incidencia cada vez que hay un registro en los firewalls e IPS.
Mándales a paseo :-P
Espera, si dices que ofrecen otros servicios, un nmap los descubre.
No. Un nmap no puede descubrir nada. Por una sencilla razón: hasta que un usuario no se autentica, no vé el resto de servicios y además solo verá los servicios para los que a su perfil se le da acceso.
Mmmm...
Esto que te explico puedes probarlo. Descarga pfsense (www.pfsense.org) y mirate la parte de auth rules. Así verás más claro lo que explico.
- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkqv4nEACgkQtTMYHG2NR9WbWwCdHQ2yE81/2uBBBN07tXMWGHdU IJ8AnRgvR5h9Wg5OaF4Ln7JYKCtklxop =x9Rx -----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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-15 a las 21:00 +0200, carlopmart escribió:
Carlos E. R. wrote:
Eso no lo tengo claro. ¿Spoofing? ¿Desde las máquinas con suse?
No, las SuSE insertan la ruta de zeroconf por lo tanto enviarán (y escucharán) un broadcast de vez en cuando. Ese broadcast es detectado por IPS y firewalls y como esa ruta no pertenece a ningún rango "controlado" por ellos y les está entrando por un direccionamiento legal, generan alertas de spoofing.
Te equivocas. La inserción de la ruta no tiene que ver con el broadcast.
Neturalmente que no, a ver si me explico. Si yo conecto un laptop a ese segmento con zeroconf habilitado enviará paquetes al segmento via broadcast, por ende va a descubrir a esos dos servers en la red ¿si?
Pero la ruta indefinida no te va a evitar eso. Te va a provocar el problema, como explico en otro correo. Piensalo. Se inserta el portatil, interroga, el server contesta... y la contestación va al gateway, no al portatil. Lo que debes hacer es impedir los broadcast e impedir que se responda a ellos, y quitar la ruta no es la solución. Lo empeora. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqv8i8ACgkQtTMYHG2NR9V50ACfR8vj2nTYF+5iXQKlcXvf1rrt 5lMAmwRTnVsT3sEsx+Zd4aMxufsqU6+E =5vkS -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-09-15 a las 21:00 +0200, carlopmart escribió:
Carlos E. R. wrote:
Eso no lo tengo claro. ¿Spoofing? ¿Desde las máquinas con suse? No, las SuSE insertan la ruta de zeroconf por lo tanto enviarán (y > escucharán) un broadcast de vez en cuando. Ese broadcast es detectado > por IPS y firewalls y como esa ruta no pertenece a ningún rango > "controlado" por ellos y les está entrando por un direccionamiento > legal, generan alertas de spoofing.
Te equivocas. La inserción de la ruta no tiene que ver con el broadcast.
Neturalmente que no, a ver si me explico. Si yo conecto un laptop a ese segmento con zeroconf habilitado enviará paquetes al segmento via broadcast, por ende va a descubrir a esos dos servers en la red ¿si?
Pero la ruta indefinida no te va a evitar eso.
¿ruta indefinida?? que es eso??
Te va a provocar el problema, como explico en otro correo. Piensalo. Se inserta el portatil, interroga, el server contesta... y la contestación va al gateway, no al portatil.
Lo que debes hacer es impedir los broadcast e impedir que se responda a ellos, y quitar la ruta no es la solución. Lo empeora.
Pues no sé como lo ves pero tengo la ruta zeronconf de las SuSE eliminida. Y todo funciona como debe ... Uhmm, un momento, ¿tu estás interpretando que he borrado la ruta del segmento de red a la que pertenecen las SuSE?? Si es así, la respuesta es no. Estoy borrando/desconfigurando la ruta zeroconf 169.254.0.0/255.255.0.0.
- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkqv8i8ACgkQtTMYHG2NR9V50ACfR8vj2nTYF+5iXQKlcXvf1rrt 5lMAmwRTnVsT3sEsx+Zd4aMxufsqU6+E =5vkS -----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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-15 a las 22:14 +0200, carlopmart escribió:
Te equivocas. La inserción de la ruta no tiene que ver con el broadcast.
Neturalmente que no, a ver si me explico. Si yo conecto un laptop a ese segmento con zeroconf habilitado enviará paquetes al segmento via broadcast, por ende va a descubrir a esos dos servers en la red ¿si?
Pero la ruta indefinida no te va a evitar eso.
¿ruta indefinida?? que es eso??
Te va a provocar el problema, como explico en otro correo. Piensalo. Se inserta el portatil, interroga, el server contesta... y la contestación va al gateway, no al portatil.
Lo que debes hacer es impedir los broadcast e impedir que se responda a ellos, y quitar la ruta no es la solución. Lo empeora.
Pues no sé como lo ves pero tengo la ruta zeronconf de las SuSE eliminida. Y todo funciona como debe ... Uhmm, un momento, ¿tu estás interpretando que he borrado la ruta del segmento de red a la que pertenecen las SuSE?? Si es así, la respuesta es no. Estoy borrando/desconfigurando la ruta zeroconf 169.254.0.0/255.255.0.0.
Eso mismo. Y eso es la causa del problema. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqv+GgACgkQtTMYHG2NR9VqlgCgiofeQKgTcUob4rwsoE+yOrHS LLkAn3mZhU6oY6Hj1Z6DeDcqkXR/vCts =xZ3l -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-09-15 a las 22:14 +0200, carlopmart escribió:
Te equivocas. La inserción de la ruta no tiene que ver con el > broadcast. Neturalmente que no, a ver si me explico. Si yo conecto un laptop a ese > segmento con zeroconf habilitado enviará paquetes al segmento via > broadcast, por ende va a descubrir a esos dos servers en la red ¿si?
Pero la ruta indefinida no te va a evitar eso.
¿ruta indefinida?? que es eso??
Te va a provocar el problema, como explico en otro correo. Piensalo. Se inserta el portatil, interroga, el server contesta... y la contestación va al gateway, no al portatil.
Lo que debes hacer es impedir los broadcast e impedir que se responda a ellos, y quitar la ruta no es la solución. Lo empeora.
Pues no sé como lo ves pero tengo la ruta zeronconf de las SuSE eliminida. Y todo funciona como debe ... Uhmm, un momento, ¿tu estás interpretando que he borrado la ruta del segmento de red a la que pertenecen las SuSE?? Si es así, la respuesta es no. Estoy borrando/desconfigurando la ruta zeroconf 169.254.0.0/255.255.0.0.
Eso mismo. Y eso es la causa del problema.
¿Que es lo que causa el problema?? A ver si nos aclaramos. A mí el problema me surge cuando las SuSE insertan la ruta zeroconf, porque hay dispositivos que me generan alertas. Ahora bien, si yo elimino esa ruta zeroconf y las SuSE cuando botean ya no la pueden insertar más, todos mis problemas desaparecen ... ¿si?.
- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkqv+GgACgkQtTMYHG2NR9VqlgCgiofeQKgTcUob4rwsoE+yOrHS LLkAn3mZhU6oY6Hj1Z6DeDcqkXR/vCts =xZ3l -----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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-15 a las 22:30 +0200, carlopmart escribió:
Carlos E. R. wrote:
Eso mismo. Y eso es la causa del problema.
¿Que es lo que causa el problema?? A ver si nos aclaramos. A mí el problema me surge cuando las SuSE insertan la ruta zeroconf, porque hay dispositivos que me generan alertas. Ahora bien, si yo elimino esa ruta zeroconf y las SuSE cuando botean ya no la pueden insertar más, todos mis problemas desaparecen ... ¿si?.
No. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqwCvYACgkQtTMYHG2NR9XQTgCdHTR+90MvqhIn2oQvrrIDeTEo /fwAn3DamkjdBOP8SNIlFnNZKHHPjQcK =k0hZ -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-09-15 a las 22:30 +0200, carlopmart escribió:
Carlos E. R. wrote:
Eso mismo. Y eso es la causa del problema.
¿Que es lo que causa el problema?? A ver si nos aclaramos. A mí el problema me surge cuando las SuSE insertan la ruta zeroconf, porque hay dispositivos que me generan alertas. Ahora bien, si yo elimino esa ruta zeroconf y las SuSE cuando botean ya no la pueden insertar más, todos mis problemas desaparecen ... ¿si?.
No.
Pues chico, no sé explicarme mejor ...
- -- Saludos Carlos E. R.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkqwCvYACgkQtTMYHG2NR9XQTgCdHTR+90MvqhIn2oQvrrIDeTEo /fwAn3DamkjdBOP8SNIlFnNZKHHPjQcK =k0hZ -----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
El 2009-09-14 a las 01:01 +0200, Carlos E. R. escribió:
El 2009-09-13 a las 23:20 +0200, Camaleón escribió:
¿Y no crees que pudiera ser de utilidad más allá de para "ese" caso en concreto?
De lo que estamos hablando es de poder configurar una opción, no de los motivos que tenga cada cual para hacerlo.
Vamos a ver, él dijo que lo que le molestaba era las entradas que se estaban generando en los cortafuegos. Entiendo que ese es el problema que tiene, no otro. Y el arreglo se supone que es eliminar zeroconf de la maquina suse.
Es decir, hay un problema con las entradas del registro, y se busca cómo solucionarlo. Hay varias posibilidades, y yo hablo de una de ellas, la que sé.
Solución que ya se ha contempaldo y ha sido descartada >:-P
No hace falta que seas tan desagradable.
Ya'tamos. No seas tan mal pensada.
No he sido yo quien ha dicho eso.
Tú eres la que ha has dicho que no sea desagradable... la F es de flipping, no seas mal pensada >:-P
¡Grrr! >:-)
Creais un script: /etc/inid.d/anularzeroconf
Que eso ya lo hemos planteado, no se trata de crear un script que elimine la ruta cada vez que se inicia el servicio de red sino de por qué no existe una opción similar a la que tienen en RedHat.
Sí se trata. Dijisteis:
]> ¿Con "route del" no se eliminan rutas? :-? ]> ] Si, pero en cuanto reboto las máquinas vuelve a salir. El script que la ] inserta es el ifup-route, pero
... por tanto, yo explico una manera de que no vuelva a salir. Eso no se ha contado.
A ver... Si ejecutas "route del" la ruta se elimina en la sesión actual. Al reinciar, vuelve a aparecer. Por eso luego salió la idea de crear un script al inicio para hacer el cambio permanente, pero fue descartada por ser un poco "chapucilla".
¿Lo sabes tú?
Ya he dicho que no. Eso se lo teneis que preguntar a ellos.
¿Te has levantado con el pié izquierdo? Estás tiquismiquis hoy... :-)
¡Chitón! O:-) 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-14 a las 12:35 +0200, Camaleón escribió:
El 2009-09-14 a las 01:01 +0200, Carlos E. R. escribió:
Es decir, hay un problema con las entradas del registro, y se busca cómo solucionarlo. Hay varias posibilidades, y yo hablo de una de ellas, la que sé.
Solución que ya se ha contempaldo y ha sido descartada >:-P
Porque no la habeis puesto en el sitio correcto :-p
Creais un script: /etc/inid.d/anularzeroconf
Que eso ya lo hemos planteado, no se trata de crear un script que elimine la ruta cada vez que se inicia el servicio de red sino de por qué no existe una opción similar a la que tienen en RedHat.
Sí se trata. Dijisteis:
]> ¿Con "route del" no se eliminan rutas? :-? ]> ] Si, pero en cuanto reboto las máquinas vuelve a salir. El script que la ] inserta es el ifup-route, pero
... por tanto, yo explico una manera de que no vuelva a salir. Eso no se ha contado.
A ver...
Si ejecutas "route del" la ruta se elimina en la sesión actual. Al reinciar, vuelve a aparecer. Por eso luego salió la idea de crear un script al inicio para hacer el cambio permanente, pero fue descartada por ser un poco "chapucilla".
¿Y que más dá que sea chapucilla? Funciona. Y mientras, buscas otra solución, si existe. Yo tengo algunas de esas puestas desde hace años. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkquwSsACgkQtTMYHG2NR9XSOQCfWlqkqKgVfdwo1oUrFFapkOIP PcAAnRI5KmdbiOAvdsI8MPpP63YfZgjL =u8XP -----END PGP SIGNATURE-----
El 2009-09-15 a las 00:18 +0200, Carlos E. R. escribió:
El 2009-09-14 a las 12:35 +0200, Camaleón escribió:
Es decir, hay un problema con las entradas del registro, y se busca cómo solucionarlo. Hay varias posibilidades, y yo hablo de una de ellas, la que sé.
Solución que ya se ha contempaldo y ha sido descartada >:-P
Porque no la habeis puesto en el sitio correcto :-p
No creo que sirviera. Se supone que tiene que ir en /etc/init.d/boot.local pero una vez iniciado el sistema si se reiniciara el servicio de red estaríamos en la misma situación esperpéntica :-) Tendría que estar vinculado al servicio de red, y que se ejecutara el script cada vez que se ejecuatara un "rcnetwork lo_que_sea".
Que eso ya lo hemos planteado, no se trata de crear un script que elimine la ruta cada vez que se inicia el servicio de red sino de por qué no existe una opción similar a la que tienen en RedHat.
Sí se trata. Dijisteis:
]> ¿Con "route del" no se eliminan rutas? :-? ]> ] Si, pero en cuanto reboto las máquinas vuelve a salir. El script que la ] inserta es el ifup-route, pero
... por tanto, yo explico una manera de que no vuelva a salir. Eso no se ha contado.
A ver...
Si ejecutas "route del" la ruta se elimina en la sesión actual. Al reinciar, vuelve a aparecer. Por eso luego salió la idea de crear un script al inicio para hacer el cambio permanente, pero fue descartada por ser un poco "chapucilla".
¿Y que más dá que sea chapucilla? Funciona. Y mientras, buscas otra solución, si existe. Yo tengo algunas de esas puestas desde hace años.
No, no funciona en este caso. La única forma de hacerlo es "hacerlo correctamente" y es configurando la variable del archivo /etc/sysconfig/network/config, que para eso está. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-15 a las 08:02 +0200, Camaleón escribió:
El 2009-09-15 a las 00:18 +0200, Carlos E. R. escribió:
Porque no la habeis puesto en el sitio correcto :-p
No creo que sirviera.
Se supone que tiene que ir en /etc/init.d/boot.local pero una vez iniciado el sistema si se reiniciara el servicio de red estaríamos en la misma situación esperpéntica :-)
Nunca puede ir en boot.local porque se ejecuta antes de levantar la red. Puede valer si lo pones en /etc/init.d/MiGuionDeRed y lo insertas adecuadamente. Y sin duda vale si lo pones en /etc/sysconfig/network/scripts/MiGuionDeRed y metes el enlace en /etc/sysconfig/network/if-up.d/NUMMiGuionDeRed
Tendría que estar vinculado al servicio de red, y que se ejecutara el script cada vez que se ejecuatara un "rcnetwork lo_que_sea".
Pues eso, el tercer caso de arriba hace eso precisamente.
¿Y que más dá que sea chapucilla? Funciona. Y mientras, buscas otra solución, si existe. Yo tengo algunas de esas puestas desde hace años.
No, no funciona en este caso.
La única forma de hacerlo es "hacerlo correctamente" y es configurando la variable del archivo /etc/sysconfig/network/config, que para eso está.
Sí, haber encontrado esa variable está muy bien, es ideal. Pero piensa una cosa, en lo que pasa realmente al borrar la ruta linklocal: si por cualquier motivo el sistema tiene que mandar o responder un paquete a una IP en ese rango, como no tiene ruta definida usará la ruta por defecto, que es... el gateway. La mandará al gateway de internet, donde su administrador va a protestar y dar la vara. ¿Eso es de verdad lo que quereis hacer? >:-) - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqv06oACgkQtTMYHG2NR9WlcwCffK9Uwf4wmgZVbEu2bGt3nQ3u DIQAn3xadyMHafb8xLtqZ1WqE/tFrgoF =8Pq+ -----END PGP SIGNATURE-----
El 2009-09-15 a las 19:49 +0200, Carlos E. R. escribió:
El 2009-09-15 a las 08:02 +0200, Camaleón escribió:
El 2009-09-15 a las 00:18 +0200, Carlos E. R. escribió:
Porque no la habeis puesto en el sitio correcto :-p
No creo que sirviera.
Se supone que tiene que ir en /etc/init.d/boot.local pero una vez iniciado el sistema si se reiniciara el servicio de red estaríamos en la misma situación esperpéntica :-)
Nunca puede ir en boot.local porque se ejecuta antes de levantar la red.
Aceptado.
Puede valer si lo pones en /etc/init.d/MiGuionDeRed y lo insertas adecuadamente.
Tampoco serviría, porque sólo se ejecutaría al iniciar el sistema, pero no al reiniciar el servicio, por lo que si tienes que reiniciar la red, tienes que acordarte de ejcutar ese script de nuevo o de eliminar la ruta a mano con el "route del".
Y sin duda vale si lo pones en /etc/sysconfig/network/scripts/MiGuionDeRed y metes el enlace en /etc/sysconfig/network/if-up.d/NUMMiGuionDeRed
Ahora sí has hecho los deberes :-) Pero tu sugerencia de poner el script en bajo /etc/init.d/borra_ruta tampoco hubiera servido :-P
Tendría que estar vinculado al servicio de red, y que se ejecutara el script cada vez que se ejecuatara un "rcnetwork lo_que_sea".
Pues eso, el tercer caso de arriba hace eso precisamente.
Hum... ¿debería ir ahí o en /etc/syconfig/network/scripts/ifup-route?
¿Y que más dá que sea chapucilla? Funciona. Y mientras, buscas otra solución, si existe. Yo tengo algunas de esas puestas desde hace años.
No, no funciona en este caso.
La única forma de hacerlo es "hacerlo correctamente" y es configurando la variable del archivo /etc/sysconfig/network/config, que para eso está.
Sí, haber encontrado esa variable está muy bien, es ideal.
Es el estilo suse. Y era muy extraño que no estuviera contemplado.
Pero piensa una cosa, en lo que pasa realmente al borrar la ruta linklocal: si por cualquier motivo el sistema tiene que mandar o responder un paquete a una IP en ese rango, como no tiene ruta definida usará la ruta por defecto, que es... el gateway. La mandará al gateway de internet, donde su administrador va a protestar y dar la vara.
¿Eso es de verdad lo que quereis hacer? >:-)
De redes estoy pez, pero me parece que los paquetes dirigidos al link-local no podrían salir nunca por la puerta de enlace (caso de que fuera un router con salida al isp), no son "rutables". Hemos vivido muchos años sin el zeroconf, ¿de verdad crees que ahora es necesario tenerlo configurado, activado y escuchando peticiones de "tó-quisqui" (aka: todos los chismes multimedia o impresoras, etc... habidos y por haber)? >:-) 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-15 a las 21:03 +0200, Camaleón escribió:
El 2009-09-15 a las 19:49 +0200, Carlos E. R. escribió:
Nunca puede ir en boot.local porque se ejecuta antes de levantar la red.
Aceptado.
Puede valer si lo pones en /etc/init.d/MiGuionDeRed y lo insertas adecuadamente.
Tampoco serviría, porque sólo se ejecutaría al iniciar el sistema, pero no al reiniciar el servicio, por lo que si tienes que reiniciar la red, tienes que acordarte de ejcutar ese script de nuevo o de eliminar la ruta a mano con el "route del".
Por eso dije "puede".
Y sin duda vale si lo pones en /etc/sysconfig/network/scripts/MiGuionDeRed y metes el enlace en /etc/sysconfig/network/if-up.d/NUMMiGuionDeRed
Ahora sí has hecho los deberes :-)
¡Pero es que ya lo dije hace varios mensajes!
Pero tu sugerencia de poner el script en bajo /etc/init.d/borra_ruta tampoco hubiera servido :-P
A medias :-)
Tendría que estar vinculado al servicio de red, y que se ejecutara el script cada vez que se ejecuatara un "rcnetwork lo_que_sea".
Pues eso, el tercer caso de arriba hace eso precisamente.
Hum... ¿debería ir ahí o en /etc/syconfig/network/scripts/ifup-route?
Donde quieras, mientras no exista, y "/etc/sysconfig/network/scripts/ifup-route" existe. No debe existir, porque una actualización te borraría tu cambio. Es mejor que te crees tu propio guión, y hay un "ifup-skel" para usar de punto de partida.
Sí, haber encontrado esa variable está muy bien, es ideal.
Es el estilo suse. Y era muy extraño que no estuviera contemplado.
Pero piensa una cosa, en lo que pasa realmente al borrar la ruta linklocal: si por cualquier motivo el sistema tiene que mandar o responder un paquete a una IP en ese rango, como no tiene ruta definida usará la ruta por defecto, que es... el gateway. La mandará al gateway de internet, donde su administrador va a protestar y dar la vara.
¿Eso es de verdad lo que quereis hacer? >:-)
De redes estoy pez, pero me parece que los paquetes dirigidos al link-local no podrían salir nunca por la puerta de enlace (caso de que fuera un router con salida al isp), no son "rutables".
En efecto, no son rutables; el gateway debe cepillarselos, igual que se cepilla los que vayan a IPs locales. Y eso no es problema en cualquier parte, excepto en la red de carlopmart porque sus admins son quisquillosos en exceso.
Hemos vivido muchos años sin el zeroconf, ¿de verdad crees que ahora es necesario tenerlo configurado, activado y escuchando peticiones de "tó-quisqui" (aka: todos los chismes multimedia o impresoras, etc... habidos y por haber)? >:-)
No, no lo creo. Pero... existe, está ahí, y "hay" que soportarlo por si alguien lo necesita. Es más fácil para la gente que meter un dhcp, que fíjate que los routers caseros de los proveedores de internet suelen ponerlo. Pero lo que estoy diciendo es otra cosa. Si quitas la definición de la ruta para los paquetes linklocal, y por algún motivo aparece un paquete que va a ese rango, el ordenador mirará en su tabla de rutas; al no encontrar ninguna, usará la ruta por defecto, que es la del gateway. Lo que estoy diciendo es que quitar la ruta de linklocal provoca que los paquetes linklocal vayan al gateway (en vez de al sitio a donde su autor/generador pensaba) generando un reporte y bronca de esos administradores quisquillosos. 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. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqv8JYACgkQtTMYHG2NR9WrYACfSimMaw1fs4o//GhvUPwYqC3Z 6OoAniScNJSfzLtXgFpAz7aKwAZodDJT =SC5/ -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-09-15 a las 21:03 +0200, Camaleón escribió:
El 2009-09-15 a las 19:49 +0200, Carlos E. R. escribió:
Nunca puede ir en boot.local porque se ejecuta antes de levantar la red.
Aceptado.
Puede valer si lo pones en /etc/init.d/MiGuionDeRed y lo insertas adecuadamente.
Tampoco serviría, porque sólo se ejecutaría al iniciar el sistema, pero no al reiniciar el servicio, por lo que si tienes que reiniciar la red, tienes que acordarte de ejcutar ese script de nuevo o de eliminar la ruta a mano con el "route del".
Por eso dije "puede".
Y sin duda vale si lo pones en /etc/sysconfig/network/scripts/MiGuionDeRed y metes el enlace en /etc/sysconfig/network/if-up.d/NUMMiGuionDeRed
Ahora sí has hecho los deberes :-)
¡Pero es que ya lo dije hace varios mensajes!
Pero tu sugerencia de poner el script en bajo /etc/init.d/borra_ruta tampoco hubiera servido :-P
A medias :-)
Tendría que estar vinculado al servicio de red, y que se ejecutara el script cada vez que se ejecuatara un "rcnetwork lo_que_sea".
Pues eso, el tercer caso de arriba hace eso precisamente.
Hum... ¿debería ir ahí o en /etc/syconfig/network/scripts/ifup-route?
Donde quieras, mientras no exista, y "/etc/sysconfig/network/scripts/ifup-route" existe.
No debe existir, porque una actualización te borraría tu cambio. Es mejor que te crees tu propio guión, y hay un "ifup-skel" para usar de punto de partida.
Sí, haber encontrado esa variable está muy bien, es ideal.
Es el estilo suse. Y era muy extraño que no estuviera contemplado.
Pero piensa una cosa, en lo que pasa realmente al borrar la ruta linklocal: si por cualquier motivo el sistema tiene que mandar o responder un paquete a una IP en ese rango, como no tiene ruta definida usará la ruta por defecto, que es... el gateway. La mandará al gateway de internet, donde su administrador va a protestar y dar la vara.
¿Eso es de verdad lo que quereis hacer? >:-)
De redes estoy pez, pero me parece que los paquetes dirigidos al link-local no podrían salir nunca por la puerta de enlace (caso de que fuera un router con salida al isp), no son "rutables".
En efecto, no son rutables; el gateway debe cepillarselos, igual que se cepilla los que vayan a IPs locales. Y eso no es problema en cualquier parte, excepto en la red de carlopmart porque sus admins son quisquillosos en exceso.
Hemos vivido muchos años sin el zeroconf, ¿de verdad crees que ahora es necesario tenerlo configurado, activado y escuchando peticiones de "tó-quisqui" (aka: todos los chismes multimedia o impresoras, etc... habidos y por haber)? >:-)
No, no lo creo. Pero... existe, está ahí, y "hay" que soportarlo por si alguien lo necesita. Es más fácil para la gente que meter un dhcp, que fíjate que los routers caseros de los proveedores de internet suelen ponerlo.
Pero lo que estoy diciendo es otra cosa. Si quitas la definición de la ruta para los paquetes linklocal, y por algún motivo aparece un paquete que va a ese rango, el ordenador mirará en su tabla de rutas; al no encontrar ninguna, usará la ruta por defecto, que es la del gateway.
No, no, no. De eso nada. Si ese server ve que el paquete no va hacia el, no hace absolutamente nada con él, a menos que sea un gateway (un router, un firewall, etc).
Lo que estoy diciendo es que quitar la ruta de linklocal provoca que los paquetes linklocal vayan al gateway (en vez de al sitio a donde su autor/generador pensaba) generando un reporte y bronca de esos administradores quisquillosos.
No. Si yo quito la ruta linklocal de esos servidores, ¿quien va a generar ningún paquete si no hay servers con esas rutas??
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.
- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkqv8JYACgkQtTMYHG2NR9WrYACfSimMaw1fs4o//GhvUPwYqC3Z 6OoAniScNJSfzLtXgFpAz7aKwAZodDJT =SC5/ -----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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-15 a las 23:25 +0200, carlopmart escribió:
Carlos E. R. wrote:
Pero lo que estoy diciendo es otra cosa. Si quitas la definición de la ruta para los paquetes linklocal, y por algún motivo aparece un paquete que va a ese rango, el ordenador mirará en su tabla de rutas; al no encontrar ninguna, usará la ruta por defecto, que es la del gateway.
No, no, no. De eso nada. Si ese server ve que el paquete no va hacia el, no hace absolutamente nada con él, a menos que sea un gateway (un router, un firewall, etc).
No es así.
Lo que estoy diciendo es que quitar la ruta de linklocal provoca que los paquetes linklocal vayan al gateway (en vez de al sitio a donde su autor/generador pensaba) generando un reporte y bronca de esos administradores quisquillosos.
No. Si yo quito la ruta linklocal de esos servidores, ¿quien va a generar ningún paquete si no hay servers con esas rutas??
Las rutas no sirven para generar paquetes. No tiene que ver. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqwC6EACgkQtTMYHG2NR9V6FgCdFXKB3CJfxEto1+IY94PMq2WP yUoAn3JeObO6QtUiVH6UfbYobxJF3DDp =dvvw -----END PGP SIGNATURE-----
El 2009-09-15 a las 21:52 +0200, Carlos E. R. escribió:
Pero lo que estoy diciendo es otra cosa. Si quitas la definición de la ruta para los paquetes linklocal, y por algún motivo aparece un paquete que va a ese rango, el ordenador mirará en su tabla de rutas; al no encontrar ninguna, usará la ruta por defecto, que es la del gateway.
Carlos, eso podría pasar en una red "de andar por casa", pero no en el escenario que te plantea carlopmart, donde parece que las rutas están perfectamente definidas y donde dudo mucho que haya un "gateway por defecto". Las rutas deben estar "hilvanadas".
Lo que estoy diciendo es que quitar la ruta de linklocal provoca que los paquetes linklocal vayan al gateway (en vez de al sitio a donde su autor/generador pensaba) generando un reporte y bronca de esos administradores quisquillosos.
¿Pero no te está diciendo que es precisamente todo lo contrario, que el hehco de tener esa ruta creada es la que le está generando esos informes? ¿O hablas de un "supuesto"? 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.
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 :-/ 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. 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 2009-09-15 a las 21:52 +0200, Carlos E. R. escribió:
Pero lo que estoy diciendo es otra cosa. Si quitas la definición de la ruta para los paquetes linklocal, y por algún motivo aparece un paquete que va a ese rango, el ordenador mirará en su tabla de rutas; al no encontrar ninguna, usará la ruta por defecto, que es la del gateway.
Carlos, eso podría pasar en una red "de andar por casa", pero no en el escenario que te plantea carlopmart, donde parece que las rutas están perfectamente definidas y donde dudo mucho que haya un "gateway por defecto". Las rutas deben estar "hilvanadas".
¿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 que estoy diciendo es que quitar la ruta de linklocal provoca que los paquetes linklocal vayan al gateway (en vez de al sitio a donde su autor/generador pensaba) generando un reporte y bronca de esos administradores quisquillosos.
¿Pero no te está diciendo que es precisamente todo lo contrario, que el hehco de tener esa ruta creada es la que le está generando esos informes? ¿O hablas de un "supuesto"?
Hablo de un supuesto. Pero tengo entendido que borraba esa ruta a mano antes de saber como quitarla automáticamente. ¿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. 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.
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). 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. ¿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". - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqwEd4ACgkQtTMYHG2NR9WUFQCgiexLnN+kIn2Sps3qc0zT7yo7 vx0AnRvt5EcqBcxx2ZmHf3Olg7TdRW2h =unCG -----END PGP SIGNATURE-----
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
El 2009-09-16 a las 00:14 +0200, Carlos E. R. escribió:
El 2009-09-15 a las 23:30 +0200, Camaleón escribió:
El 2009-09-15 a las 21:52 +0200, Carlos E. R. escribió:
Pero lo que estoy diciendo es otra cosa. Si quitas la definición de la ruta para los paquetes linklocal, y por algún motivo aparece un paquete que va a ese rango, el ordenador mirará en su tabla de rutas; al no encontrar ninguna, usará la ruta por defecto, que es la del gateway.
Carlos, eso podría pasar en una red "de andar por casa", pero no en el escenario que te plantea carlopmart, donde parece que las rutas están perfectamente definidas y donde dudo mucho que haya un "gateway por defecto". Las rutas deben estar "hilvanadas".
¿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 >:-) 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.
¿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.
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.
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).
:-) Un IPS es un "Intrusion prevention system" (o al menos eso es lo que yo había entendido). http://en.wikipedia.org/wiki/Intrusion_prevention_system
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.
¿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.
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 :-?
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.
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í.
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.
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".
Añade, además, que los servidores dhcp o dns que amabablemente has configurado para el vecino pueden tener agujeros de seguridad sin parchear y que podrían ser fácilmente explotables desde la red local >:-) 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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.
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.
¿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.
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.
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).
:-)
Un IPS es un "Intrusion prevention system" (o al menos eso es lo que yo había entendido).
Ah.
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.
¿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.
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 :-?
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.
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í.
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.
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".
Añade, además, que los servidores dhcp o dns que amabablemente has configurado para el vecino pueden tener agujeros de seguridad sin parchear y que podrían ser fácilmente explotables desde la red local >:-)
Puede. Pero, uno, mi vecino no puede entrar porque no tengo la wifi encendida. Y dos, no podría entrar en mi pc porque no considero mi intranet como confiable, esto es, el cortafuegos está plenamente activo, etc etc. Todo lo más podría entrar en el chisme de la tele. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEUEARECAAYFAkqxOooACgkQtTMYHG2NR9XdcwCeOhSuD2jTTAel5kJdQoGa1M3m 3NUAmLd/Bk5Fas/lNeDmZ4VjNizdCcM= =FIuT -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
El 2009-09-16 a las 21:20 +0200, Carlos E. R. escribió:
Eso es así, es de libro.
¿De qué libro hablas, exactamente?
Cualquier libro de redes.
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 >:-)
Mira que eres incrédula... Observa - trato de enviar paquetes a una IP del rango link-local cualquiera (inexistente): nimrodel:~ # traceroute 169.254.0.1 traceroute to 169.254.0.1 (169.254.0.1), 30 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 nimrodel.valinor (192.168.1.12)(H!) 2883.962 ms (H!) 2876.028 ms (H!) 2867.671 ms nimrodel:~ # ping 169.254.0.1 PING 169.254.0.1 (169.254.0.1) 56(84) bytes of data. - From 192.168.1.12: icmp_seq=2 Destination Host Unreachable - From 192.168.1.12 icmp_seq=2 Destination Host Unreachable - From 192.168.1.12 icmp_seq=3 Destination Host Unreachable - From 192.168.1.12 icmp_seq=4 Destination Host Unreachable ^C - --- 169.254.0.1 ping statistics --- 6 packets transmitted, 0 received, +4 errors, 100% packet loss, time 5003ms , pipe 3 nimrodel:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default router 0.0.0.0 UG 0 0 0 eth0 Eso es con la configuración normal. Ahora borro la ruta link-local: nimrodel:~ # route del -net 169.254.0.0/16 nimrodel:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default router 0.0.0.0 UG 0 0 0 eth0 nimrodel:~ # traceroute 169.254.0.1 traceroute to 169.254.0.1 (169.254.0.1), 30 hops max, 40 byte packets 1 router (192.168.1.1) 0.688 ms 0.442 ms 0.449 ms 2 192.168.153.1 (192.168.153.1) 53.018 ms 56.574 ms 53.849 ms 3 X.Red-Z-Y-V.staticIP.rima-tde.net (Z.Y.V.X) 51.855 ms 53.782 ms 51.759 ms 4 * * * 5 * * * ¿Ves como se va al gateway o ruta por defecto, al quitar la ruta del link-local?
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?
Ninguna. Si lo hiciera estaría mal, porque ya tienes una red configurada. Eso es lo que dice el texto. Que no debe crearla en ese caso.
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.
Pues la verdad es que quizás sí estaría disponible, o parte del sistema. La parte que le permite a los ordenadores conectados al vuelo obtener una IP, que desconozco que parte del sistema la ofrece. Pudiera ser el avahi, pero no lo sé seguro. Me parece que no hace falta contestación por parte de nadie con IP fija para que funcione: quienes tienen que contestar son los que tienen IPs automáticas. Es que no tienes que ofrecer nada especial... la ruta simplemente permite al ordenador contestar, los servicios son los mismos que tengas normalmente y con el mismo nivel de seguridad que tuvieras normalmente, ni más ni menos. No es la ruta lo que permite establecerse a los ordenadores "visitantes" y obtener una IP. Yo lo que propongo es cortar esos paquetes en el cortafuegos local de todas las máquinas participantes en la red.
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
No, eso es una hipótesis de trabajo, que yo digo que es incorrecta. El dato conocido es que hay unos avisos del sistema de seguridad, y lo que dicen lo desconocemos.
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.
Y yo digo que creará contratiempos adicionales. A las pruebas de mi traceroute me remito. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqxagMACgkQtTMYHG2NR9V5YwCfc8FbXm2IPS9V7+BV+X8L/6Ol LgQAmgJwf0Izi6T1DLRsfSbff96zHTJC =BI1f -----END PGP SIGNATURE-----
Carlos E. R. wrote:
Mira que eres incrédula... Observa - trato de enviar paquetes a una IP del rango link-local cualquiera (inexistente):
nimrodel:~ # traceroute 169.254.0.1 traceroute to 169.254.0.1 (169.254.0.1), 30 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 nimrodel.valinor (192.168.1.12)(H!) 2883.962 ms (H!) 2876.028 ms (H!) 2867.671 ms nimrodel:~ # ping 169.254.0.1 PING 169.254.0.1 (169.254.0.1) 56(84) bytes of data. - From 192.168.1.12: icmp_seq=2 Destination Host Unreachable - From 192.168.1.12 icmp_seq=2 Destination Host Unreachable - From 192.168.1.12 icmp_seq=3 Destination Host Unreachable - From 192.168.1.12 icmp_seq=4 Destination Host Unreachable ^C - --- 169.254.0.1 ping statistics --- 6 packets transmitted, 0 received, +4 errors, 100% packet loss, time 5003ms , pipe 3 nimrodel:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 link-local * 255.255.0.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default router 0.0.0.0 UG 0 0 0 eth0
Eso es con la configuración normal. Ahora borro la ruta link-local:
nimrodel:~ # route del -net 169.254.0.0/16 nimrodel:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default router 0.0.0.0 UG 0 0 0 eth0 nimrodel:~ # traceroute 169.254.0.1 traceroute to 169.254.0.1 (169.254.0.1), 30 hops max, 40 byte packets 1 router (192.168.1.1) 0.688 ms 0.442 ms 0.449 ms 2 192.168.153.1 (192.168.153.1) 53.018 ms 56.574 ms 53.849 ms 3 X.Red-Z-Y-V.staticIP.rima-tde.net (Z.Y.V.X) 51.855 ms 53.782 ms 51.759 ms 4 * * * 5 * * *
¿Ves como se va al gateway o ruta por defecto, al quitar la ruta del link-local?
Bravo, plas, plas, plas :)) No he podido evitarlo. Esto es de manual que ese ping se irá a un default gateway, pero ¿cuando he dicho yo que se ejcutaba un ping a una IP linklocal? En ningún correo. Repaso la incidencia: - Los dispositivos de firewall e IPS generan una inidencia porque "detectan" la inserción de una ruta linklocal: el IPS de una forma y el firewall de otra. - Los IPS lanzan una alerta de inserción de ruta zeroconf (recuerda, tienen 3 tablas de enrutamiento distintas ambos servidores) - Las SuSE al levantar la ruta, la publican en todas sus tablas de enrutamiento y las hacen públicas. - Por ende los firewalls lanzan alerta de spoofing, ya que los IPS no bloquean la publicación de rutas (solo faltaba) ¿Donde está el ping? ¿Cuando se supone que los servidores van a hacer un ping a una IP linklocal? ¿Que parte de la configuración de los servidores se supone que falla por eliminar la ruta zeroconf? Y lo más importante, ¿he dicho yo en algún momento que esos servidores hacen uso, publican, requieren o como querais llamarlo de servicios zeroconf? ¿cuando he dicho yo que algún dispositivo en cualesquiera de esos segmentos de red soiliciten ni por asomo IP's (se me caería el pelo)?
Yo lo que propongo es cortar esos paquetes en el cortafuegos local de todas las máquinas participantes en la red.
Para qué?. Esos servidores no van a responder a peticiones de nada que tenga que ver con zeroconf, y mucho menos los firewalls.
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
No, eso es una hipótesis de trabajo, que yo digo que es incorrecta.
El dato conocido es que hay unos avisos del sistema de seguridad, y lo que dicen lo desconocemos.
Te lo digo: "Inserted administrative prohibited route 169.254.0.0/16 on server ..." ... Me parece que te quedas igual ¿no? Por eso no ví necesidad de comentarlo en los correos.
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.
Y yo digo que creará contratiempos adicionales. A las pruebas de mi traceroute me remito.
¿Pero que pruebas? ¿Que contratiempos? ¿Que problemas? Lo único que has demostrado es que lanzas un ping que se va a un default gateway ... ¿cuando sale el conejo de la chistera? :))
- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkqxagMACgkQtTMYHG2NR9V5YwCfc8FbXm2IPS9V7+BV+X8L/6Ol LgQAmgJwf0Izi6T1DLRsfSbff96zHTJC =BI1f -----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
El 2009-09-17 a las 00:43 +0200, Carlos E. R. escribió:
El 2009-09-16 a las 23:12 +0200, Camaleón escribió:
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 >:-)
Mira que eres incrédula... Observa - trato de enviar paquetes a una IP del rango link-local cualquiera (inexistente):
Espero sinceramente, Carlos, que todo esto se trate de una mera broma o de una simple "cabezonería" tuya por no ser capaz de reconocer -sencillamente- que estás en un error. Y también espero que seas capaz de entender lo que escribo, porque a veces pienso que no, que simplememte interpretas lo que quieres y lo utilizas como arma arrojadiza con el único fin de intentar argumentar tu postura "a toda costa". (...)
¿Ves como se va al gateway o ruta por defecto, al quitar la ruta del link-local?
Obviamente, no me refería a eso. Si quieres leer (e intentar entender) lo que pone al principo de este correo (que es a la prueba a la que me estaba refiriendo), perfecto, y si no, también. Más no puedo hacer. (...)
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.
Y yo digo que creará contratiempos adicionales. A las pruebas de mi traceroute me remito.
Creo que el hilo ya ha llegado muy lejos y no me gustaría entrar en descalificaciones de ningún tipo. Sé que a veces en caliente puedo escribir cosas un tanto "mordientes" y si ha sido así en este caso, lo siento. Tan sólo voy a apuntar un documento adicional, porque sé que a buen entendedor, pocas palabras bastan: *** http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf Guide to the Secure Configuration of Red Hat Enterprise Linux 5 Revision 2 / December 20, 2007 Operating Systems Division Unix Team of the Systems and Network Analysis Center National Security Agency 9800 Savage Rd. Suite 6704 Ft. Meade, MD 20755-6704 (...) 1. Introduction The purpose of this guide is to provide security configuration recommendations for the Red Hat Enterprise Linux (RHEL) 5 operating system. The guidance provided here should be applicable to all variants (Desktop, Server,Advanced Platform) of the product. Recommended settings for the basic operating system are provided, as well as for many commonly-used services that the system can host in a network environment. The guide is intended for system administrators. Readers are assumed to possess basic system administration skills for Unix-like systems, as well as some familiarity with Red Hat’s documentation and administration conventions. Some instructions within this guide are complex. All directions should be followed completely and with understanding of their effects in order to avoid serious adverse effects on the system and its security. (...) 3.3 Base Services This section addresses the base services that are configured to start up on boot in a RHEL5 default installation. Some of these services listen on the network and should be treated with particular discretion. The other services are local system utilities that may or may not be extraneous. Each of these services should be disabled if not required. 3.3.9.3 Disable Zeroconf Networking ...... 79 3.3.9.3 Disable Zeroconf Networking Zeroconf networking allows the system to assign itself an IP address and engage in IP communication without a statically-assigned address or even a DHCP server. Automatic address assignment via Zeroconf (or DHCP) is not recommended. To disable Zeroconf automatic route assignment in the 169.245.0.0 subnet, add or correct the following line in /etc/sysconfig/network: NOZEROCONF=yes Zeroconf addresses are in the network 169.254.0.0. The networking scripts add entries to the system’s routing table for these addresses. Zeroconf address assignment commonly occurs when the system is configured to use DHCP but fails to receive an address assignment from the DHCP server. *** Mis conocimientos sobre la seguridad de las redes no son tan buenos como me gustaría, y por eso seguramente se me escapa el motivo por el cual los IPS le están generando esas alertas. Pero es precisamente por eso por lo que busco, leo (e intento entender) este tipo de documentación, para saber si realmente es "necesario" mantener un servicio "x" activado (o, en este caso, una ruta configurada) y cuáles son sus implicaciones. Dicho esto, si quieres discutir con alguien sobre la conveniencia o no de desactivar esa ruta, puedes dirigirte a la NSA. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-17 a las 10:41 +0200, Camaleón escribió:
El 2009-09-17 a las 00:43 +0200, Carlos E. R. escribió:
El 2009-09-16 a las 23:12 +0200, Camaleón escribió:
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 >:-)
Mira que eres incrédula... Observa - trato de enviar paquetes a una IP del rango link-local cualquiera (inexistente):
Espero sinceramente, Carlos, que todo esto se trate de una mera broma o de una simple "cabezonería" tuya por no ser capaz de reconocer -sencillamente- que estás en un error.
¿Broma? ¿De que vas? Si eso es lo que piensas, entonces yo creo sinceramente que la cabezonería es vuestra por no reconocer vuestro error.
Y también espero que seas capaz de entender lo que escribo, porque a veces pienso que no, que simplememte interpretas lo que quieres y lo utilizas como arma arrojadiza con el único fin de intentar argumentar tu postura "a toda costa".
Y yo espero que seas capaz de entender lo que escribo, porque... etc. Después de tanto tiempo que nos conocemos deberías darme un poco de crédito y pensar que si digo algo tendré motivos... :-/
(...)
¿Ves como se va al gateway o ruta por defecto, al quitar la ruta del link-local?
Obviamente, no me refería a eso.
¿No? Pues yo si. Y lo he demostrado: al quitar la ruta link-local, los paquetes van al gateway. Lo llevo diciendo hace nosecuantos mensajes. No se que rayos entenderás tú... Haz tú otras pruebas y me las muestras. Yo no hago más, porque no puedo hacerlas: no tengo tres ordenadores, tú sí.
(...)
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.
Y yo digo que creará contratiempos adicionales. A las pruebas de mi traceroute me remito.
Creo que el hilo ya ha llegado muy lejos y no me gustaría entrar en descalificaciones de ningún tipo. Sé que a veces en caliente puedo escribir cosas un tanto "mordientes" y si ha sido así en este caso, lo siento.
Tan sólo voy a apuntar un documento adicional, porque sé que a buen entendedor, pocas palabras bastan:
*** http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
Guide to the Secure Configuration of Red Hat Enterprise Linux 5 Revision 2 / December 20, 2007
Operating Systems Division Unix Team of the Systems and Network Analysis Center
National Security Agency 9800 Savage Rd. Suite 6704 Ft. Meade, MD 20755-6704
(...)
1. Introduction
The purpose of this guide is to provide security configuration recommendations for the Red Hat Enterprise Linux (RHEL) 5 operating system. The guidance provided here should be applicable to all variants (Desktop, Server,Advanced Platform) of the product. Recommended settings for the basic operating system are provided, as well as for many commonly-used services that the system can host in a network environment.
The guide is intended for system administrators. Readers are assumed to possess basic system administration skills for Unix-like systems, as well as some familiarity with Red Hat’s documentation and administration conventions. Some instructions within this guide are complex. All directions should be followed completely and with understanding of their effects in order to avoid serious adverse effects on the system and its security.
(...)
3.3 Base Services
This section addresses the base services that are configured to start up on boot in a RHEL5 default installation.
Some of these services listen on the network and should be treated with particular discretion. The other services are local system utilities that may or may not be extraneous. Each of these services should be disabled if not required.
3.3.9.3 Disable Zeroconf Networking ...... 79
3.3.9.3 Disable Zeroconf Networking Zeroconf networking allows the system to assign itself an IP address and engage in IP communication without a statically-assigned address or even a DHCP server. Automatic address assignment via Zeroconf (or DHCP) is not recommended.
To disable Zeroconf automatic route assignment in the 169.245.0.0 subnet, add or correct the following line in /etc/sysconfig/network:
NOZEROCONF=yes
Zeroconf addresses are in the network 169.254.0.0. The networking scripts add entries to the system’s routing table for these addresses. Zeroconf address assignment commonly occurs when the system is configured to use DHCP but fails to receive an address assignment from the DHCP server. ***
No sabemos que más cosas hace redhat al poner esa variable, pero seguro que no es sólo quitar la ruta (en la suse tienes que parar un par de daemons, y hacer un cambio en el cortafuegos). Yo he demostrado que al quitar la ruta los paquetes que haya (por el motivo que sea) van al gateway, y eso puede ser precisamente lo que se desea, porque el gateway puede configurarse para detectar esa situación, tirar los paquetes, y saltar una alarma que avise al administrador (que es probablemente lo que está pasandole a carlopmart).
Mis conocimientos sobre la seguridad de las redes no son tan buenos como me gustaría, y por eso seguramente se me escapa el motivo por el cual los IPS le están generando esas alertas. Pero es precisamente por eso por lo que busco, leo (e intento entender) este tipo de documentación, para saber si realmente es "necesario" mantener un servicio "x" activado (o, en este caso, una ruta configurada) y cuáles son sus implicaciones.
Dicho esto, si quieres discutir con alguien sobre la conveniencia o no de desactivar esa ruta, puedes dirigirte a la NSA.
Si, claro... no seas tan... Ains... Ten en cuenta que el apartado remarcado en el 3.3.9.3 habla sólo de como desactivar el rutado de zeroconf. No dice que eso desactive zeroconf. Es sólo una de las cosas a hacer: +----------------------------------------- | To disable Zeroconf automatic route assignment in the 169.245.0.0 | subnet, add or correct the following line | in /etc/sysconfig/network: | NOZEROCONF=yes +------------------------------------------ Para desactivar la ruta.... etc. No dice: para desactivar zeroconf.... aunque siendo redhat, puede que lo hagan. No lo se. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqygskACgkQtTMYHG2NR9XZhACfTAc1tJjXVgQsh1fL5bYG02Pz No8AoIhtLnH/RlZYUzBYPtEHeIY9bPqU =oAZa -----END PGP SIGNATURE-----
El 2009-09-17 a las 20:41 +0200, Carlos E. R. escribió:
El 2009-09-17 a las 10:41 +0200, Camaleón escribió:
Mira que eres incrédula... Observa - trato de enviar paquetes a una IP del rango link-local cualquiera (inexistente):
Espero sinceramente, Carlos, que todo esto se trate de una mera broma o de una simple "cabezonería" tuya por no ser capaz de reconocer -sencillamente- que estás en un error.
¿Broma? ¿De que vas?
Si eso es lo que piensas, entonces yo creo sinceramente que la cabezonería es vuestra por no reconocer vuestro error.
Juvar, bien empezamos en día.
Y también espero que seas capaz de entender lo que escribo, porque a veces pienso que no, que simplememte interpretas lo que quieres y lo utilizas como arma arrojadiza con el único fin de intentar argumentar tu postura "a toda costa".
Y yo espero que seas capaz de entender lo que escribo, porque... etc.
Después de tanto tiempo que nos conocemos deberías darme un poco de crédito y pensar que si digo algo tendré motivos... :-/
Aún estoy esperando a que digas "esos motivos" de manera clara y concisa, y si están sustentados en algún documento, mejor. Porque apreciaciones personales tenemos todos y pueden ser apreciaciones equivovadas.
(...)
¿Ves como se va al gateway o ruta por defecto, al quitar la ruta del link-local?
Obviamente, no me refería a eso.
¿No? Pues yo si.
Y lo he demostrado: al quitar la ruta link-local, los paquetes van al gateway. Lo llevo diciendo hace nosecuantos mensajes. No se que rayos entenderás tú...
Haz tú otras pruebas y me las muestras. Yo no hago más, porque no puedo hacerlas: no tengo tres ordenadores, tú sí.
¿Sigues hablando en broma, no? ¿O acaso es que no has entendido lo que decía?
Y yo digo que creará contratiempos adicionales. A las pruebas de mi traceroute me remito.
Creo que el hilo ya ha llegado muy lejos y no me gustaría entrar en descalificaciones de ningún tipo. Sé que a veces en caliente puedo escribir cosas un tanto "mordientes" y si ha sido así en este caso, lo siento.
Tan sólo voy a apuntar un documento adicional, porque sé que a buen entendedor, pocas palabras bastan:
*** http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
Guide to the Secure Configuration of Red Hat Enterprise Linux 5 Revision 2 / December 20, 2007
Operating Systems Division Unix Team of the Systems and Network Analysis Center
(...)
No sabemos que más cosas hace redhat al poner esa variable, pero seguro que no es sólo quitar la ruta (en la suse tienes que parar un par de daemons, y hacer un cambio en el cortafuegos).
¿Para quitar la ruta del zeroconf de la tabla de rutas? No, sólo tienes editar una variable o ejecutar un comando. Quitar la ruta del zeroconf != desactivar el servicio de avahi
Yo he demostrado que al quitar la ruta los paquetes que haya (por el motivo que sea) van al gateway, y eso puede ser precisamente lo que se desea, porque el gateway puede configurarse para detectar esa situación, tirar los paquetes, y saltar una alarma que avise al administrador (que es probablemente lo que está pasandole a carlopmart).
¿No hablas en broma? ¿De verdad que estás hablando en serio? Bueno... No hace falta que quites la ruta del link-local para hacer tus pruebas. Cualquier traza que hagas a una ip cuya ruta no tengas en la tabla de direcciones saldrá por la puerta de enlace que tengas predeterminada. Por tanto, según tu teoría, todos los equipos son "vulnerables", todas las configuraciones "pueden crear contratiempos adicionales (sic)", independientemente de que tengan (o no) la ruta del zeroconf en su tabla. ¿Estás *seguro* de que quieres decir eso?
Mis conocimientos sobre la seguridad de las redes no son tan buenos como me gustaría, y por eso seguramente se me escapa el motivo por el cual los IPS le están generando esas alertas. Pero es precisamente por eso por lo que busco, leo (e intento entender) este tipo de documentación, para saber si realmente es "necesario" mantener un servicio "x" activado (o, en este caso, una ruta configurada) y cuáles son sus implicaciones.
Dicho esto, si quieres discutir con alguien sobre la conveniencia o no de desactivar esa ruta, puedes dirigirte a la NSA.
Si, claro... no seas tan...
Ains...
Ten en cuenta que el apartado remarcado en el 3.3.9.3 habla sólo de como desactivar el rutado de zeroconf. No dice que eso desactive zeroconf. Es sólo una de las cosas a hacer:
+----------------------------------------- | To disable Zeroconf automatic route assignment in the 169.245.0.0 | subnet, add or correct the following line | in /etc/sysconfig/network: | NOZEROCONF=yes +------------------------------------------
Para desactivar la ruta.... etc. No dice: para desactivar zeroconf.... aunque siendo redhat, puede que lo hagan. No lo se.
Caray... A ver si lo entiendes. La idea principal de este hilo era "cómo desactivar la ruta del zeroconf", es decir, cómo hacer en openSUSE y SLES lo que "aconseja" ese manual de seguridad de RedHat. Aún así (y para más inri), si continúas leyendo ese manual, verás que también "recomienda" desactivar el servicio del ahavi si no se piensa utilizar. *** 3.7 Avahi Server The Avahi daemon implements the DNS Service Discovery and Multicast DNS protocols, which provide service and host discovery on a network. It allows a system to automatically identify resources on the network, such as printers or web servers. This capability is also known as mDNSresponder and is a major part of Zeroconf networking. By default, it is enabled. 3.7.1 Disable Avahi Server if Possible Because the Avahi daemon service keeps an open network port, it is subject to network attacks. Disabling it is particularly important to reduce the system’s vulnerability to such attacks. *** En fin, es como si le estuviera hablando a una pared... 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lo doy por imposible. Cuando te cierras en banada es imposible. Abandono. :-/ - -- Saludos Carlos E. R. El 2009-09-18 a las 08:38 +0200, Camaleón escribió:
El 2009-09-17 a las 20:41 +0200, Carlos E. R. escribió:
El 2009-09-17 a las 10:41 +0200, Camaleón escribió:
Mira que eres incrédula... Observa - trato de enviar paquetes a una IP del rango link-local cualquiera (inexistente):
Espero sinceramente, Carlos, que todo esto se trate de una mera broma o de una simple "cabezonería" tuya por no ser capaz de reconocer -sencillamente- que estás en un error.
¿Broma? ¿De que vas?
Si eso es lo que piensas, entonces yo creo sinceramente que la cabezonería es vuestra por no reconocer vuestro error.
Juvar, bien empezamos en día.
Y también espero que seas capaz de entender lo que escribo, porque a veces pienso que no, que simplememte interpretas lo que quieres y lo utilizas como arma arrojadiza con el único fin de intentar argumentar tu postura "a toda costa".
Y yo espero que seas capaz de entender lo que escribo, porque... etc.
Después de tanto tiempo que nos conocemos deberías darme un poco de crédito y pensar que si digo algo tendré motivos... :-/
Aún estoy esperando a que digas "esos motivos" de manera clara y concisa, y si están sustentados en algún documento, mejor. Porque apreciaciones personales tenemos todos y pueden ser apreciaciones equivovadas.
(...)
¿Ves como se va al gateway o ruta por defecto, al quitar la ruta del link-local?
Obviamente, no me refería a eso.
¿No? Pues yo si.
Y lo he demostrado: al quitar la ruta link-local, los paquetes van al gateway. Lo llevo diciendo hace nosecuantos mensajes. No se que rayos entenderás tú...
Haz tú otras pruebas y me las muestras. Yo no hago más, porque no puedo hacerlas: no tengo tres ordenadores, tú sí.
¿Sigues hablando en broma, no? ¿O acaso es que no has entendido lo que decía?
Y yo digo que creará contratiempos adicionales. A las pruebas de mi traceroute me remito.
Creo que el hilo ya ha llegado muy lejos y no me gustaría entrar en descalificaciones de ningún tipo. Sé que a veces en caliente puedo escribir cosas un tanto "mordientes" y si ha sido así en este caso, lo siento.
Tan sólo voy a apuntar un documento adicional, porque sé que a buen entendedor, pocas palabras bastan:
*** http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf
Guide to the Secure Configuration of Red Hat Enterprise Linux 5 Revision 2 / December 20, 2007
Operating Systems Division Unix Team of the Systems and Network Analysis Center
(...)
No sabemos que más cosas hace redhat al poner esa variable, pero seguro que no es sólo quitar la ruta (en la suse tienes que parar un par de daemons, y hacer un cambio en el cortafuegos).
¿Para quitar la ruta del zeroconf de la tabla de rutas? No, sólo tienes editar una variable o ejecutar un comando.
Quitar la ruta del zeroconf != desactivar el servicio de avahi
Yo he demostrado que al quitar la ruta los paquetes que haya (por el motivo que sea) van al gateway, y eso puede ser precisamente lo que se desea, porque el gateway puede configurarse para detectar esa situación, tirar los paquetes, y saltar una alarma que avise al administrador (que es probablemente lo que está pasandole a carlopmart).
¿No hablas en broma? ¿De verdad que estás hablando en serio?
Bueno...
No hace falta que quites la ruta del link-local para hacer tus pruebas. Cualquier traza que hagas a una ip cuya ruta no tengas en la tabla de direcciones saldrá por la puerta de enlace que tengas predeterminada.
Por tanto, según tu teoría, todos los equipos son "vulnerables", todas las configuraciones "pueden crear contratiempos adicionales (sic)", independientemente de que tengan (o no) la ruta del zeroconf en su tabla.
¿Estás *seguro* de que quieres decir eso?
Mis conocimientos sobre la seguridad de las redes no son tan buenos como me gustaría, y por eso seguramente se me escapa el motivo por el cual los IPS le están generando esas alertas. Pero es precisamente por eso por lo que busco, leo (e intento entender) este tipo de documentación, para saber si realmente es "necesario" mantener un servicio "x" activado (o, en este caso, una ruta configurada) y cuáles son sus implicaciones.
Dicho esto, si quieres discutir con alguien sobre la conveniencia o no de desactivar esa ruta, puedes dirigirte a la NSA.
Si, claro... no seas tan...
Ains...
Ten en cuenta que el apartado remarcado en el 3.3.9.3 habla sólo de como desactivar el rutado de zeroconf. No dice que eso desactive zeroconf. Es sólo una de las cosas a hacer:
+----------------------------------------- | To disable Zeroconf automatic route assignment in the 169.245.0.0 | subnet, add or correct the following line | in /etc/sysconfig/network: | NOZEROCONF=yes +------------------------------------------
Para desactivar la ruta.... etc. No dice: para desactivar zeroconf.... aunque siendo redhat, puede que lo hagan. No lo se.
Caray...
A ver si lo entiendes. La idea principal de este hilo era "cómo desactivar la ruta del zeroconf", es decir, cómo hacer en openSUSE y SLES lo que "aconseja" ese manual de seguridad de RedHat.
Aún así (y para más inri), si continúas leyendo ese manual, verás que también "recomienda" desactivar el servicio del ahavi si no se piensa utilizar.
*** 3.7 Avahi Server The Avahi daemon implements the DNS Service Discovery and Multicast DNS protocols, which provide service and host discovery on a network. It allows a system to automatically identify resources on the network, such as printers or web servers. This capability is also known as mDNSresponder and is a major part of Zeroconf networking. By default, it is enabled.
3.7.1 Disable Avahi Server if Possible
Because the Avahi daemon service keeps an open network port, it is subject to network attacks. Disabling it is particularly important to reduce the system’s vulnerability to such attacks. ***
En fin, es como si le estuviera hablando a una pared...
Saludos,
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqz0ykACgkQtTMYHG2NR9WJxQCfQyPr6eTyUdFE6QQw2FkZdZKv mw4AnRVKWCANPn685S2GD31qQUu4hl/G =xFEY -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
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.
Vamos a intentar entender esto del zeroconf. Bueno, lo dejo para la tarde, me tengo que ir. [...] Tenemos una red, por ejemplo con IPs en el rango 192.168.1.0, todo con IPs fijas. Todos se hablan entre si, tan contentos, sin problemas. No necesitamos zeroconf. No tenemos dhcp. Pero el sistema ha metido las rutas de link-local. De repente llega alguien y conecta un portatil sin darle una IP, por error, desconocimiento, o malicia. ¿Que ocurre? Pues exactamente no lo se, pero una de dos: o el nuevo escucha para saber que IPs hay libres, o el nuevo emite un broadcast especial, al que le contestan los demás diciendole que IPs están ocupadas. El nuevo probablemente coja una de las libres, y emita un broadcast para anunciarlo. Si hay colisión, pues volverá a negociar otra IP. Los demás no tienen que hacer nada, siguen con sus IPs fijas; si reciben una petición cualquiera, procedente de esa IP en link-local, pues le contestarán a esa IP, puesto que tienen la ruta definida. Hay dos o tres mecanismos que entran en juego acá: uno es la ruta de linnklocal: link-local * 255.255.0.0 U 0 0 0 eth0 y que no actúa mientras no haya que enviar un paquete o contestar a otro. Pero hay otro mecanismo que consiste en escuchar los paquetes broadcast del mecanismo de zeroconf, que pueden ser para negociar una IP libre entre todos, o que pueden ser también para anunciar a los demás donde están los servicios de impresión, por ejemplo. Y el único mecanismo sobre el que estais actuando es la ruta. ¿Que sucede si quitais la ruta? Queda esto: Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default router 0.0.0.0 UG 0 0 0 eth0 Si alguien enchufa el portatil en la red como antes, pues va a conectar igual de bien... (o casi), tanto si le contestan como si no. El mecanismo de negociación sigue intacto (y si no le contestan, es que todas las IPs están libres). Hay una diferencia: que cuando el portatil mande un paquete cualquiera a una de nuestras máquinas sin ruta link-local, la máquina le va a contestar, porque no está prohibido; pero como la IP a la que tiene que contestar no está en ninguna de las entradas "Destination", pues va a "default", sea lo que sea que esté ahí: router, gateway, cortafuegos... Nuestro portatil "intruso" hace una petición al servidor web, y el apache le contesta, pero envía el paquete al gateway, no al portatil. Ya la tenemos liada. Luego el objetivo de evitar que alguien se conecte y use link-local sin nuestro consentimiento no se ha conseguido. ¿Capishi? - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqw9k4ACgkQtTMYHG2NR9U7ewCeMzzWQrvK5xGS1WPj8jlCZXwz rHUAoIPC7TCCZggWz+4g6cNESmINLXah =WuoN -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID:
El 2009-09-15 a las 23:30 +0200, Camaleón escribió:
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.
Vamos a intentar entender esto del zeroconf.
Bueno, lo dejo para la tarde, me tengo que ir.
[...]
Tenemos una red, por ejemplo con IPs en el rango 192.168.1.0, todo con IPs fijas. Todos se hablan entre si, tan contentos, sin problemas. No necesitamos zeroconf. No tenemos dhcp. Pero el sistema ha metido las rutas de link-local.
De repente llega alguien y conecta un portatil sin darle una IP, por error, desconocimiento, o malicia. ¿Que ocurre? Pues exactamente no lo se, pero una de dos: o el nuevo escucha para saber que IPs hay libres, o el nuevo emite un broadcast especial, al que le contestan los demás diciendole que IPs están ocupadas. El nuevo probablemente coja una de las libres, y emita un broadcast para anunciarlo. Si hay colisión, pues volverá a negociar otra IP.
Los demás no tienen que hacer nada, siguen con sus IPs fijas; si reciben una petición cualquiera, procedente de esa IP en link-local, pues le contestarán a esa IP, puesto que tienen la ruta definida.
Hay dos o tres mecanismos que entran en juego acá: uno es la ruta de linnklocal:
link-local * 255.255.0.0 U 0 0 0 eth0
y que no actúa mientras no haya que enviar un paquete o contestar a otro.
Pero hay otro mecanismo que consiste en escuchar los paquetes broadcast del mecanismo de zeroconf, que pueden ser para negociar una IP libre entre todos, o que pueden ser también para anunciar a los demás donde están los servicios de impresión, por ejemplo.
Y el único mecanismo sobre el que estais actuando es la ruta.
¿Que sucede si quitais la ruta? Queda esto:
Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo default router 0.0.0.0 UG 0 0 0 eth0
Si alguien enchufa el portatil en la red como antes, pues va a conectar igual de bien... (o casi), tanto si le contestan como si no. El mecanismo de negociación sigue intacto (y si no le contestan, es que todas las IPs están libres).
Hay una diferencia: que cuando el portatil mande un paquete cualquiera a una de nuestras máquinas sin ruta link-local, la máquina le va a contestar, porque no está prohibido; pero como la IP a la que tiene que contestar no está en ninguna de las entradas "Destination", pues va a "default", sea lo que sea que esté ahí: router, gateway, cortafuegos... Nuestro portatil "intruso" hace una petición al servidor web, y el apache le contesta, pero envía el paquete al gateway, no al portatil. Ya la tenemos liada.
Luego el objetivo de evitar que alguien se conecte y use link-local sin nuestro consentimiento no se ha conseguido.
¿Capishi?
No, no, no y no. Vamos a ver. La primera parte de tu disertación es correcta al 35%. Preguntas: - ¿Que es un broadcast especial? Yo solo conozco uno y es el que incluye el direccionamiento de una red. ¿O te refieres a un multicast? - Si los switches están configurados como dios manda, el señor que conecta el portatil no verá ninguna IP, sencillamente porque el switch tendrá una tabla de ARP en cada una de sus bocas correspondientes y las IPs asociadas a esas ARPs, que será por donde encaminará las peticiones de los distintos dispositivos que configuran esa red. Por ende, tú no verás ninguna IP a menos que conozcas el direccionamiento, en cuyo caso podrás usar un scanner. Y mira por donde los switches donde yo tengo conectados esos servidores no admiten inserción dinámica de ARPs, están ajustadas estáticamente. Otro caso distinto es el de un hub, este útlimo escucha por todas sus bocas. La segunda no. Pero es que ya no sé como explicártelo, la forma más sencilla es que te simules un entorno de tres máquina: una de gateway, un servidor y una estación, y verás que un server sin zeroconf configurado no hace absolutamente NADA con una paquete emitido o recibido al direccionamiento zeroconf. Y el gateway (que es un firewall con IPS en modo transparente y con un TAP - http://en.wikipedia.org/wiki/Network_tap - que es el que ve las peticiones hacia/desde la red zeroconf. Y para colofón: en mi infraestructura, SI se ha conseguido que si tu conectas un pc y habilitas el zeroconf, no consigues nada. Cosa que no ocurría con el zeroconf activo. -- 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
El 2009-09-16 a las 16:29 +0200, Carlos E. R. escribió:
El 2009-09-15 a las 23:30 +0200, Camaleón escribió:
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.
Vamos a intentar entender esto del zeroconf.
Bueno, lo dejo para la tarde, me tengo que ir.
[...]
Gracias por la lección, Carlos, creo que ya la sabemos :-) Ahora intenta aclarar qué tiene que ver el funcionamiento del zeroconf con querer desactivar un servicio que no se se va autilizar en toda la red.
Hay una diferencia: que cuando el portatil mande un paquete cualquiera a una de nuestras máquinas sin ruta link-local, la máquina le va a contestar, porque no está prohibido; pero como la IP a la que tiene que contestar no está en ninguna de las entradas "Destination", pues va a "default", sea lo que sea que esté ahí: router, gateway, cortafuegos... Nuestro portatil "intruso" hace una petición al servidor web, y el apache le contesta, pero envía el paquete al gateway, no al portatil. Ya la tenemos liada.
Mejor prueba antes eso que dices y luego nos cuentas si obtienes alguna respuesta desde algún equipo de la red. Yo creo que sin ningún equipo de la red proporciona una configuración zeroconf, ningún cliente va a obtener respuesta alguna, por mucho que la pida, desde ningún sitio. ¿De qué equipo o interfaz crees que obtendría respuesta y por qué?
Luego el objetivo de evitar que alguien se conecte y use link-local sin nuestro consentimiento no se ha conseguido.
El objetivo no es ese. El objetivo es "eliminar" un servicio que no se usa. Yo sólo puse un ejemplo comparable entre el uso del zeroconf con un servidor dhcp o dns.
¿Capishi?
Yo sí... ¿y tú? ;-) 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-16 a las 17:01 +0200, Camaleón escribió:
Vamos a intentar entender esto del zeroconf.
Gracias por la lección, Carlos, creo que ya la sabemos :-)
No, no lo sabeis.
Luego el objetivo de evitar que alguien se conecte y use link-local sin nuestro consentimiento no se ha conseguido.
El objetivo no es ese.
El objetivo es "eliminar" un servicio que no se usa. Yo sólo puse un ejemplo comparable entre el uso del zeroconf con un servidor dhcp o dns.
¿Capishi?
Yo sí... ¿y tú? ;-)
No, tu no. NO ELIMINAS el zeroconf con SOLO eliminar la ruta. Repito: NO ELIMINAS el zeroconf con SOLO eliminar la ruta. La ruta es una de las tres patas nada más... - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqxNR8ACgkQtTMYHG2NR9VuHQCfVn6YL51NoXkn700YSkbMlEpX syIAn1YRt6GcPF4jU5yS2D/rwg8AQ035 =lncp -----END PGP SIGNATURE-----
El 2009-09-16 a las 20:57 +0200, Carlos E. R. escribió:
El 2009-09-16 a las 17:01 +0200, Camaleón escribió:
Vamos a intentar entender esto del zeroconf.
Gracias por la lección, Carlos, creo que ya la sabemos :-)
No, no lo sabeis.
Luego el objetivo de evitar que alguien se conecte y use link-local sin nuestro consentimiento no se ha conseguido.
El objetivo no es ese.
El objetivo es "eliminar" un servicio que no se usa. Yo sólo puse un ejemplo comparable entre el uso del zeroconf con un servidor dhcp o dns.
¿Capishi?
Yo sí... ¿y tú? ;-)
No, tu no.
NO ELIMINAS el zeroconf con SOLO eliminar la ruta.
Repito:
NO ELIMINAS el zeroconf con SOLO eliminar la ruta.
La ruta es una de las tres patas nada más...
Por mi parte, hilo terminado. 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
Camaleón wrote:
El 2009-09-16 a las 20:57 +0200, Carlos E. R. escribió:
El 2009-09-16 a las 17:01 +0200, Camaleón escribió:
Vamos a intentar entender esto del zeroconf. Gracias por la lección, Carlos, creo que ya la sabemos :-) No, no lo sabeis.
Luego el objetivo de evitar que alguien se conecte y use link-local sin nuestro consentimiento no se ha conseguido. El objetivo no es ese.
El objetivo es "eliminar" un servicio que no se usa. Yo sólo puse un ejemplo comparable entre el uso del zeroconf con un servidor dhcp o dns.
¿Capishi? Yo sí... ¿y tú? ;-) No, tu no.
NO ELIMINAS el zeroconf con SOLO eliminar la ruta.
Repito:
NO ELIMINAS el zeroconf con SOLO eliminar la ruta.
La ruta es una de las tres patas nada más...
Por mi parte, hilo terminado.
Saludos,
Totalmente de acuerdo. Saludos. -- 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
Pero piensa una cosa, en lo que pasa realmente al borrar la ruta linklocal: si por cualquier motivo el sistema tiene que mandar o responder un paquete a una IP en ese rango, como no tiene ruta definida usará la ruta por defecto, que es... el gateway. La mandará al gateway de internet, donde su administrador va a protestar y dar la vara.
¿Eso es de verdad lo que quereis hacer? >:-)
¿Pero que IP ni que rango ni que mandangas? Repito: que todos los servidores tienen su IP fija, ni dhcp ni nada por el estilo, con hardware redundado en switches y las interfaces en modo bonding y con tres default gateway de salida (eso es un total de mínimo 6 interfaces de red), inciso: los default gateways son firewalls y nunca routers ... Explicame cuando van a enviar un paquete, enrutar, petición, llámalo como quieras, a la red zeroconf ... Y yo no he dicho en ningún momento que los firewalls e IPS que llevan delante estos servers envien nada a Internet (primero porque no son dispositivos públicos). Simplemente no pueden.
De redes estoy pez, pero me parece que los paquetes dirigidos al link-local no podrían salir nunca por la puerta de enlace (caso de que fuera un router con salida al isp), no son "rutables".
Hemos vivido muchos años sin el zeroconf, ¿de verdad crees que ahora es necesario tenerlo configurado, activado y escuchando peticiones de "tó-quisqui" (aka: todos los chismes multimedia o impresoras, etc... habidos y por haber)? >:-)
Saludos,
Mismamente Camaleon. -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-15 a las 21:59 +0200, carlopmart escribió:
Pero piensa una cosa, en lo que pasa realmente al borrar la ruta linklocal: si por cualquier motivo el sistema tiene que mandar o responder un paquete a una IP en ese rango, como no tiene ruta definida usará la ruta por defecto, que es... el gateway. La mandará al gateway de internet, donde su administrador va a protestar y dar la vara.
¿Eso es de verdad lo que quereis hacer? >:-)
¿Pero que IP ni que rango ni que mandangas? Repito: que todos los servidores tienen su IP fija, ni dhcp ni nada por el estilo, con hardware redundado en switches y las interfaces en modo bonding y con tres default gateway de salida (eso es un total de mínimo 6 interfaces de red), inciso: los default gateways son firewalls y nunca routers ... Explicame cuando van a enviar un paquete, enrutar, petición, llámalo como quieras, a la red zeroconf ...
Pues ya me dirás de donde salen esos paquetes de zeroconf de los que te quejas que te echan la bronca... - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqv+NUACgkQtTMYHG2NR9Vp7wCfUdgHjjjtWkF2IEoA6RkUOMwp FwgAn03ql+vA8p5C1qncS1hC6Y1PEdEZ =ZKAo -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-09-15 a las 21:59 +0200, carlopmart escribió:
Pero piensa una cosa, en lo que pasa realmente al borrar la ruta linklocal: si por cualquier motivo el sistema tiene que mandar o responder un paquete a una IP en ese rango, como no tiene ruta definida > usará la ruta por defecto, que es... el gateway. La mandará al gateway > de internet, donde su administrador va a protestar y dar la vara.
¿Eso es de verdad lo que quereis hacer? >:-)
¿Pero que IP ni que rango ni que mandangas? Repito: que todos los servidores tienen su IP fija, ni dhcp ni nada por el estilo, con hardware redundado en switches y las interfaces en modo bonding y con tres default gateway de salida (eso es un total de mínimo 6 interfaces de red), inciso: los default gateways son firewalls y nunca routers ... Explicame cuando van a enviar un paquete, enrutar, petición, llámalo como quieras, a la red zeroconf ...
Pues ya me dirás de donde salen esos paquetes de zeroconf de los que te quejas que te echan la bronca...
Te quiero hacer ver que lo que dices de "Pero piensa una cosa, en lo que pasa realmente al borrar la ruta linklocal .... ", en mi infraestructura no tiene ningún sentido porque yo no necesito el linklocal para absolutamente nada ... por ende, no necesito rutas zeroconf en esos servidores.
- -- Saludos Carlos E. R.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkqv+NUACgkQtTMYHG2NR9Vp7wCfUdgHjjjtWkF2IEoA6RkUOMwp FwgAn03ql+vA8p5C1qncS1hC6Y1PEdEZ =ZKAo -----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
El 2009-09-15 a las 22:35 +0200, carlopmart escribió:
Carlos E. R. wrote:
Pues ya me dirás de donde salen esos paquetes de zeroconf de los que te quejas que te echan la bronca...
Te quiero hacer ver que lo que dices de "Pero piensa una cosa, en lo que pasa realmente al borrar la ruta linklocal .... ", en mi infraestructura no tiene ningún sentido porque yo no necesito el linklocal para absolutamente nada ... por ende, no necesito rutas zeroconf en esos servidores.
Exactamente. Recomiendo echar un vistazo al RFC: *** Dynamic Configuration of IPv4 Link-Local Addresses http://tools.ietf.org/html/rfc3927#page-8 1.9. When to configure an IPv4 Link-Local address A host with an address on a link can communicate with all other devices on that link, whether those devices use Link-Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both an operable routable address and an IPv4 Link-Local address configured on the same interface. The term "operable address" is used to mean an address which works effectively for communication in the current network context (see below). When an operable routable address is available on an interface, the host SHOULD NOT also assign an IPv4 Link-Local address on that interface. *** @carlopmart: Tampoco te lo tomes tan a pecho. Son decisiones que se toman (por parte de las distribuciones, RedHat o SLES) por algún motivo (sería interesante saber exactamente cuál :-P) y ojo, no creo que en RedHat esté desactivada esta ruta de manera predeterminada. Lo importante, en cualquier caso, es que sea un parámetro configurable de forma sencilla y efectiva. 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
Camaleón wrote:
El 2009-09-15 a las 22:35 +0200, carlopmart escribió:
Carlos E. R. wrote:
Pues ya me dirás de donde salen esos paquetes de zeroconf de los que te quejas que te echan la bronca... Te quiero hacer ver que lo que dices de "Pero piensa una cosa, en lo que pasa realmente al borrar la ruta linklocal .... ", en mi infraestructura no tiene ningún sentido porque yo no necesito el linklocal para absolutamente nada ... por ende, no necesito rutas zeroconf en esos servidores.
Exactamente.
Recomiendo echar un vistazo al RFC:
*** Dynamic Configuration of IPv4 Link-Local Addresses http://tools.ietf.org/html/rfc3927#page-8
1.9. When to configure an IPv4 Link-Local address
A host with an address on a link can communicate with all other devices on that link, whether those devices use Link-Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both an operable routable address and an IPv4 Link-Local address configured on the same interface. The term "operable address" is used to mean an address which works effectively for communication in the current network context (see below). When an operable routable address is available on an interface, the host SHOULD NOT also assign an IPv4 Link-Local address on that interface. ***
@carlopmart: Tampoco te lo tomes tan a pecho. Son decisiones que se toman (por parte de las distribuciones, RedHat o SLES) por algún motivo (sería interesante saber exactamente cuál :-P) y ojo, no creo que en RedHat esté desactivada esta ruta de manera predeterminada.
No me lo tomo a pecho, pero es que no sabía si Carlos E.R. me estaba entendiendo o no. RedHat también inserta la ruta y se la tienes que desconfigurar con el parámetro NOZEROCONF que comenté. De lo que me quejo con la SLES/openSuSE es que mientras yo voy a kb.redhat.com y pongo zeroconf como palabra de búsqueda el primer link ya me está diciendo como eliminarlo. Por contra en la knowledge de Novell (http://www.novell.com/support/microsites/microsite.do), ni por asomo sale ... En resumen: de lo que me quejo es de la poca doumentación que ofrece Novell para ver ciertas cosas. Ni que se necesitasen magos para manejar esto. :)) P.D: Cierto que en el script lo indicaba, pero vamos hubo que buscar. Ni en San Google me decían nada de este tema.
Lo importante, en cualquier caso, es que sea un parámetro configurable de forma sencilla y efectiva.
Saludos,
-- 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
El 2009-09-15 a las 23:21 +0200, carlopmart escribió:
Camaleón wrote:
@carlopmart: Tampoco te lo tomes tan a pecho. Son decisiones que se toman (por parte de las distribuciones, RedHat o SLES) por algún motivo (sería interesante saber exactamente cuál :-P) y ojo, no creo que en RedHat esté desactivada esta ruta de manera predeterminada.
No me lo tomo a pecho, pero es que no sabía si Carlos E.R. me estaba entendiendo o no.
RedHat también inserta la ruta y se la tienes que desconfigurar con el parámetro NOZEROCONF que comenté. De lo que me quejo con la SLES/openSuSE es que mientras yo voy a kb.redhat.com y pongo zeroconf como palabra de búsqueda el primer link ya me está diciendo como eliminarlo. Por contra en la knowledge de Novell (http://www.novell.com/support/microsites/microsite.do), ni por asomo sale ... En resumen: de lo que me quejo es de la poca doumentación que ofrece Novell para ver ciertas cosas. Ni que se necesitasen magos para manejar esto. :))
En esto te doy toda la razón. Yo también lo estuve buscando en la documentación en línea de la SLES 11 y sólo aparecía una mísera referencia al término "zeroconf", pero nada relacionado con lo que buscábamos (relacionado con la configuración desde yast de la red) :-(
P.D: Cierto que en el script lo indicaba, pero vamos hubo que buscar. Ni en San Google me decían nada de este tema.
Je, desde luego este era un caso 100% RTFM, eso es cierto. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-15 a las 23:21 +0200, carlopmart escribió:
RedHat también inserta la ruta y se la tienes que desconfigurar con el parámetro NOZEROCONF que comenté.
Seguro que RedHat hace algo más que quitar la ruta. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqwFnYACgkQtTMYHG2NR9U8XACdECc67r71Jo9wy948PWuDSn1E z7YAniK5jC+NQpb+drdbGyTusLoGayge =Q81i -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-09-15 a las 23:21 +0200, carlopmart escribió:
RedHat también inserta la ruta y se la tienes que desconfigurar con el parámetro NOZEROCONF que comenté.
Seguro que RedHat hace algo más que quitar la ruta.
¿Por ejemplo?
- -- Saludos Carlos E. R.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkqwFnYACgkQtTMYHG2NR9U8XACdECc67r71Jo9wy948PWuDSn1E z7YAniK5jC+NQpb+drdbGyTusLoGayge =Q81i -----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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-15 a las 23:09 +0200, Camaleón escribió:
El 2009-09-15 a las 22:35 +0200, carlopmart escribió:
Carlos E. R. wrote:
Pues ya me dirás de donde salen esos paquetes de zeroconf de los que te quejas que te echan la bronca...
Te quiero hacer ver que lo que dices de "Pero piensa una cosa, en lo que pasa realmente al borrar la ruta linklocal .... ", en mi infraestructura no tiene ningún sentido porque yo no necesito el linklocal para absolutamente nada ... por ende, no necesito rutas zeroconf en esos servidores.
Exactamente.
No tener las rutas no impide la aparición de los paquetes. Simplemente aparecerán (o no) de igual forma, pero con destino equivocado.
Recomiendo echar un vistazo al RFC:
*** Dynamic Configuration of IPv4 Link-Local Addresses http://tools.ietf.org/html/rfc3927#page-8
1.9. When to configure an IPv4 Link-Local address
A host with an address on a link can communicate with all other devices on that link, whether those devices use Link-Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both an operable routable address and an IPv4 Link-Local address configured on the same interface. The term "operable address" is used to mean an address which works effectively for communication in the current network context (see below). When an operable routable address is available on an interface, the host SHOULD NOT also assign an IPv4 Link-Local address on that interface. ***
OJO que no están hablando para nada de tener o no tener definida la ruta del rango linklocal. Hablan de que no pongas una IP de link-local en la misma interfase en la que has puesto la IP fija (o de dhcp). Fíjate bien en la palabrería del párrafo. Te dice que una máquina con ip (link-local) podrá comunicarse indistintamente con ordenadores con ip link-local, o con ordenadores con IP normal (rutable). Y no está demostrado que sus ordenadores tengan IPs link-local, sino más bien lo contrario. No hay nada incorrecto ahí, en la configuración que ha puesto suse por defecto. ¿Y porqué lo hace suse así? Pues porque es un estándar más a cumplir. Si no os gusta, pues abrir un FATE para configurarlo, y votadlo >:-P Pero ojo que quitar la ruta, por cualquier método, no impide que la máquina (suse) emita o responda a los broadcast de link-local. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqwFd8ACgkQtTMYHG2NR9VbPgCfQBIZYV30zs4iQZM0gJ5RvC+4 A3kAoIa5sbGh47JFThh6F6pCe3aLUy/K =7B0O -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-09-15 a las 23:09 +0200, Camaleón escribió:
El 2009-09-15 a las 22:35 +0200, carlopmart escribió:
Carlos E. R. wrote:
Pues ya me dirás de donde salen esos paquetes de zeroconf de los que te quejas que te echan la bronca...
Te quiero hacer ver que lo que dices de "Pero piensa una cosa, en lo que pasa realmente al borrar la ruta linklocal .... ", en mi infraestructura no tiene ningún sentido porque yo no necesito el linklocal para absolutamente nada ... por ende, no necesito rutas zeroconf en esos servidores.
Exactamente.
No tener las rutas no impide la aparición de los paquetes. Simplemente aparecerán (o no) de igual forma, pero con destino equivocado.
Recomiendo echar un vistazo al RFC:
*** Dynamic Configuration of IPv4 Link-Local Addresses http://tools.ietf.org/html/rfc3927#page-8
1.9. When to configure an IPv4 Link-Local address
A host with an address on a link can communicate with all other devices on that link, whether those devices use Link-Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both an operable routable address and an IPv4 Link-Local address configured on the same interface. The term "operable address" is used to mean an address which works effectively for communication in the current network context (see below). When an operable routable address is available on an interface, the host SHOULD NOT also assign an IPv4 Link-Local address on that interface. ***
OJO que no están hablando para nada de tener o no tener definida la ruta del rango linklocal. Hablan de que no pongas una IP de link-local en la misma interfase en la que has puesto la IP fija (o de dhcp).
Fíjate bien en la palabrería del párrafo.
Te dice que una máquina con ip (link-local) podrá comunicarse indistintamente con ordenadores con ip link-local, o con ordenadores con IP normal (rutable).
Y no está demostrado que sus ordenadores tengan IPs link-local, sino más bien lo contrario. No hay nada incorrecto ahí, en la configuración que ha puesto suse por defecto.
¿Y porqué lo hace suse así? Pues porque es un estándar más a cumplir. Si no os gusta, pues abrir un FATE para configurarlo, y votadlo >:-P
Pero ojo que quitar la ruta, por cualquier método, no impide que la máquina (suse) emita o responda a los broadcast de link-local.
O yo tengo que volver al colegio o no entiendo nada:)) . Si las SuSE no tienen definidas ni IP's ni rutas de linklocal, ¿como puñetas van a emitir o responder al broadcast de linklocal? bueno al broadcast ya te digo que no, pruebalo si quieres con un "ping -b ip.de.broadcast", es un parámetro de kernel que viene predefinido. Y otra cosa ¿que van a responder?
- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkqwFd8ACgkQtTMYHG2NR9VbPgCfQBIZYV30zs4iQZM0gJ5RvC+4 A3kAoIa5sbGh47JFThh6F6pCe3aLUy/K =7B0O -----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
El 2009-09-16 a las 01:33 +0200, carlopmart escribió:
Carlos E. R. wrote:
http://tools.ietf.org/html/rfc3927#page-8
1.9. When to configure an IPv4 Link-Local address
A host with an address on a link can communicate with all other devices on that link, whether those devices use Link-Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both an operable routable address and an IPv4 Link-Local address configured on the same interface. The term "operable address" is used to mean an address which works effectively for communication in the current network context (see below). When an operable routable address is available on an interface, the host SHOULD NOT also assign an IPv4 Link-Local address on that interface. ***
OJO que no están hablando para nada de tener o no tener definida la ruta del rango linklocal. Hablan de que no pongas una IP de link-local en la misma interfase en la que has puesto la IP fija (o de dhcp).
Lo cual es el caso que comentamos. Se le estaba creando una ruta (que no es una IP, Carlos, que es una ruta :-P) en una interfaz que ya tiene una ruta creada y operativa. Luego según el RFC no hay que añadirle el zeroconf a esa interfaz.
Fíjate bien en la palabrería del párrafo. Te dice que una máquina con ip (link-local) podrá comunicarse indistintamente con ordenadores con ip link-local, o con ordenadores con IP normal (rutable). Y no está demostrado que sus ordenadores tengan IPs link-local, sino más bien lo contrario. No hay nada incorrecto ahí, en la configuración que ha puesto suse por defecto.
Mejor relee con tranquilidad lo que estás diciendo porque no tiene ni pies ni cabeza :-) ¿Quién dice que usar la ruta del zeroconf sea "incorrecto"? El RFC en este caso en concreto dice que "no se debería configurar", no que sea un error de configuración. Es sólo una recomendación concreta para un caso concreto donde las rutas están definidas y operativas, nada más.
¿Y porqué lo hace suse así? Pues porque es un estándar más a cumplir. Si no os gusta, pues abrir un FATE para configurarlo, y votadlo >:-P
Tu argumento hace aguas... en una configuración de rutas compleja no hay cabida para el zeroconf. Te sigo recordando lo del "bonding", activas el bonding y te quedas sin zeroconf ¿por qué? >:-). El zeroconf es un estándar más, como lo es cualquier protocolo y no por eso tiene que hacerse uso de él "en cualquier circunstancia". Fíjate en el ipv6, muchos administradores lo desactivan, sencillamente porque no lo usan (su red es ipv4 pura) y su isp tampoco tiene soporte para ipv6. Tenerlo activado sólo es un problema y una pérdida de recursos. ¿Acaso quiere decir eso que la configuración de suse sea la incorrecta al activarlo? No, puesto que el ipv6 es un estándar más, (hoy en día opcional) y que se desactiva fácilmente.
Pero ojo que quitar la ruta, por cualquier método, no impide que la máquina (suse) emita o responda a los broadcast de link-local.
O yo tengo que volver al colegio o no entiendo nada:)) . Si las SuSE no tienen definidas ni IP's ni rutas de linklocal, ¿como puñetas van a emitir o responder al broadcast de linklocal? bueno al broadcast ya te digo que no, pruebalo si quieres con un "ping -b ip.de.broadcast", es un parámetro de kernel que viene predefinido.
Eso mismo. Que explique cómo un equipo sin zeroconf va a emitir o responder "llamadas" a una ruta inexistente >:-)
Y otra cosa ¿que van a responder?
¿Que son paquetes "marcianos" o que "vienen del más allá"? >X-) 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-09-16 a las 08:18 +0200, Camaleón escribió:
El 2009-09-16 a las 01:33 +0200, carlopmart escribió:
Carlos E. R. wrote:
http://tools.ietf.org/html/rfc3927#page-8
1.9. When to configure an IPv4 Link-Local address
A host with an address on a link can communicate with all other devices on that link, whether those devices use Link-Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both an operable routable address and an IPv4 Link-Local address configured on the same interface. The term "operable address" is used to mean an address which works effectively for communication in the current network context (see below). When an operable routable address is available on an interface, the host SHOULD NOT also assign an IPv4 Link-Local address on that interface. ***
OJO que no están hablando para nada de tener o no tener definida la ruta del rango linklocal. Hablan de que no pongas una IP de link-local en la misma interfase en la que has puesto la IP fija (o de dhcp).
Lo cual es el caso que comentamos. Se le estaba creando una ruta (que no es una IP, Carlos, que es una ruta :-P) en una interfaz que ya tiene una ruta creada y operativa. Luego según el RFC no hay que añadirle el zeroconf a esa interfaz.
Lo que te dice es que no crees una IP del rango de zeroconf en una interfaz con IP "normal"; es decir, que no tengas las dos IPs. Pero sí debes tener activa la ruta del zeroconf en esa misma interfaz (es decir, tanto la ruta normal como la link-local deben existir). Lo estás leyendo mal. La ruta es necesaria para que una máquina con IP "normal" pueda hablar tanto con el resto de ordenadores con ip "normal" como los que tienen IP "link-local", para que todos se hablen y la cosa funcione.
Fíjate bien en la palabrería del párrafo. Te dice que una máquina con ip (link-local) podrá comunicarse indistintamente con ordenadores con ip link-local, o con ordenadores con IP normal (rutable). Y no está demostrado que sus ordenadores tengan IPs link-local, sino más bien lo contrario. No hay nada incorrecto ahí, en la configuración que ha puesto suse por defecto.
Mejor relee con tranquilidad lo que estás diciendo porque no tiene ni pies ni cabeza :-)
Eso mismo te digo, releelo con tranquilidad.
¿Quién dice que usar la ruta del zeroconf sea "incorrecto"? El RFC en este caso en concreto dice que "no se debería configurar", no que sea un error de configuración. Es sólo una recomendación concreta para un caso concreto donde las rutas están definidas y operativas, nada más.
Que no debes configurar la IP, _sí_ debes configurar la ruta.
¿Y porqué lo hace suse así? Pues porque es un estándar más a cumplir. Si no os gusta, pues abrir un FATE para configurarlo, y votadlo >:-P
Tu argumento hace aguas... en una configuración de rutas compleja no hay cabida para el zeroconf. Te sigo recordando lo del "bonding", activas el bonding y te quedas sin zeroconf ¿por qué? >:-).
De bonding no tengo ni idea, por lo que no hablo.
El zeroconf es un estándar más, como lo es cualquier protocolo y no por eso tiene que hacerse uso de él "en cualquier circunstancia".
Vale, pero con desactivar la ruta no lo consigues desactivar. Le pones trabas, sí, y consigues un efecto distinto del que supones. Tu máquina no podrá hablar con máquinas en link-local, pero no consigues evitar que haya paquetes zeroconf en la red. No podrá hablar porque al no existir ruta definida pues manda los paquetes a la ruta por defecto.
Fíjate en el ipv6, muchos administradores lo desactivan, sencillamente porque no lo usan (su red es ipv4 pura) y su isp tampoco tiene soporte para ipv6. Tenerlo activado sólo es un problema y una pérdida de recursos. ¿Acaso quiere decir eso que la configuración de suse sea la incorrecta al activarlo? No, puesto que el ipv6 es un estándar más, (hoy en día opcional) y que se desactiva fácilmente.
Vale, pues desactivalo. Pero desactivalo de verdad, no a medias.
Pero ojo que quitar la ruta, por cualquier método, no impide que la máquina (suse) emita o responda a los broadcast de link-local.
O yo tengo que volver al colegio o no entiendo nada:)) . Si las SuSE no tienen definidas ni IP's ni rutas de linklocal, ¿como puñetas van a emitir o responder al broadcast de linklocal? bueno al broadcast ya te digo que no, pruebalo si quieres con un "ping -b ip.de.broadcast", es un parámetro de kernel que viene predefinido.
Eso mismo. Que explique cómo un equipo sin zeroconf va a emitir o responder "llamadas" a una ruta inexistente >:-)
Pruebalo. Va a responder, porque el paquete le llega... pero lo enviará al gateway. La conexión no se establece, por supuesto, salvo que el gateway lo reenvíe. Y claro que responde a una ruta inexistente. ¿Desde cuando no lo hace? Pruebalo. Yo sí he hecho pruebas con ethereal y rutas inexistentes e IPs en rangos distintos del de la interfaz. Verás que los paquetes salen. Otra cosa es que lleguen a donde pretendes que lleguen. Sólo has quitado una ruta, pero eso no desactiva la tarea o parte del kernel o de lo que sea que responde o emite esos paquetes. Lo que consigues es que vayan a otro sitio. Y ojo, que tener zeroconf puesto no supone tener una IP link-local. ¿Pero es que no os dais cuenta? :-/ Pensad bien en lo que estais diciendo, porque no es así. Ni de coña. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqxQK0ACgkQtTMYHG2NR9UchQCdFcmGLm5meQalS/LDac32gq8H uIUAn0kpZGIRYpqfofQSYYfehEoaJ5Gc =drTt -----END PGP SIGNATURE-----
On Wednesday 16 September 2009 21:46:46 Carlos E. R. wrote:
Vale, pero con desactivar la ruta no lo consigues desactivar. Le pones trabas, sí, y consigues un efecto distinto del que supones. Tu máquina no podrá hablar con máquinas en link-local, pero no consigues evitar que haya paquetes zeroconf en la red. No podrá hablar porque al no existir ruta definida pues manda los paquetes a la ruta por defecto.
Esto en mi opinion es indiscutible.
Pruebalo. Va a responder, porque el paquete le llega... pero lo enviará al gateway. La conexión no se establece, por supuesto, salvo que el gateway lo reenvíe.
Si esta en el rango de broadcast le llega. Pero,no se si es el caso, me parece que no. -- Saludos Lluis
On Wednesday 16 September 2009 22:28:02 Lluis wrote: Con el riesgo de meter la pata, porque no he seguido todo el hilo con la atención requerida. Estamos hablando de una instalación compleja, de la que sabemos la mitad, con lo que las cosas que suponemos pueden ser absolutamente erróneas. carlopmart, esta dando por buenos los resultados que le afectan( si no molesta es que esta bien). No me parece correcto. Debo darle la razón a Carlos en un punto clave, la existencia de una ruta, no genera trafico por si misma, por lo tanto si ese trafico existe y parece que sus logs así lo indican, lo que deberla eliminarse es la generación de dicho trafico. Eliminar la ruta porque así no se ven, viene a ser como lo de esconder la basura debajo de la alfombra. Me ha dado la impresión de haber leído algún comentario sobre la función que realizan los switch que habría que pensar mas detenidamente. Como siempre... Wireshark... puede explicar cosas. -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Con el riesgo de meter la pata, porque no he seguido todo el hilo con la atención requerida.
Estamos hablando de una instalación compleja, de la que sabemos la mitad, con lo que las cosas que suponemos pueden ser absolutamente erróneas.
carlopmart, esta dando por buenos los resultados que le afectan( si no molesta es que esta bien). No me parece correcto.
Debo darle la razón a Carlos en un punto clave, la existencia de una ruta, no genera trafico por si misma, por lo tanto si ese trafico existe y parece que sus logs así lo indican, lo que deberla eliminarse es la generación de dicho trafico.
Eliminar la ruta porque así no se ven, viene a ser como lo de esconder la basura debajo de la alfombra.
Me ha dado la impresión de haber leído algún comentario sobre la función que realizan los switch que habría que pensar mas detenidamente.
Como siempre... Wireshark... puede explicar cosas.
¡Gracias! Por fin alguien me entiende. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqxaxAACgkQtTMYHG2NR9V4zACdEWmj0FGZTEWRjYSK9fy0QDlO kB0An0PGF5AW7R+phgxeIJstLB+OAwVC =FJ5b -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Content-ID:
Carlos E. R. wrote:
Hay una referencia en "/etc/sysconfig/network/config": ... Y otra en "/etc/sysconfig/SuSEfirewall2.d/services/avahi" que a lo mejor puede servir para bloquearlo.
No tengo esas opciones ya que en ninguna de las SuSE tengo instalado ni SuSEfirewall2 ni avahi ...
La primera opción no es de ninguno de esos, es de la configuración de la red. Pero no tengo esa opción en versiones más recientes. Y si no tienes SuSEfirewall2 pues tendrás otra cosa que haga de cortafuegos y donde se pueda bloquear. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkqpeXgACgkQtTMYHG2NR9XIoACeJ6J8f4ISOJnggZWYuipSuJVY T98AniOT+khAD7FyaImqyYIdXfkeSWtf =u7p2 -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID:
El 2009-09-10 a las 23:51 +0200, carlopmart escribió:
Carlos E. R. wrote:
Hay una referencia en "/etc/sysconfig/network/config": ... Y otra en "/etc/sysconfig/SuSEfirewall2.d/services/avahi" que a lo mejor puede servir para bloquearlo.
No tengo esas opciones ya que en ninguna de las SuSE tengo instalado ni SuSEfirewall2 ni avahi ...
La primera opción no es de ninguno de esos, es de la configuración de la red. Pero no tengo esa opción en versiones más recientes.
Y si no tienes SuSEfirewall2 pues tendrás otra cosa que haga de cortafuegos y donde se pueda bloquear.
No tengo ningún tipo de cortafuegos en esos servidores SuSE ... para eso tienen delante los IPS. Lo que me tiene mosca es el ifup-route, porque me parece bien que levante la ruta si las interfaces fuesen por dhcp o no tuviesen nada configurado pero no es el caso ... -- 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
participants (4)
-
Camaleón -
carlopmart -
Carlos E. R. -
Lluis