[opensuse-es] Configurar el registro del cortafuegos
Hola, En una suse 10.3 se me llena el registro del cortafuegos con mensajes de este tipo: *** Mar 31 20:01:09 stthpc kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=01:00:xxxx SRC=192.168.0.29 DST=224.0.0.251 LEN=28 TOS= 0x00 PREC=0x00 TTL=1 ID=53936 PROTO=2 Mar 31 20:01:18 stthpc kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=01:00:xxxx SRC=192.168.0.69 DST=224.0.0.1 LEN=28 TOS=0x 00 PREC=0x00 TTL=64 ID=0 PROTO=2 *** Datos: - Los equipos que los generan son routers e impresoras Preguntas: - ¿Están mal configurados (routers e impresoras)? Es decir, que envíen esos paquetes de multidifusión ¿es el comportamiento habitual o se pueden configurar de alguna forma para que no consulten tanto? :-? - Si no hay nada que configurar en los equipos ¿sería posible que no se guardaran este tipo de eventos en el registro del cortafuegos? 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 2008-03-31 a las 20:19 +0200, Camaleón escribió:
Hola,
En una suse 10.3 se me llena el registro del cortafuegos con mensajes de este tipo:
*** Mar 31 20:01:09 stthpc kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=01:00:xxxx SRC=192.168.0.29 DST=224.0.0.251 LEN=28 TOS= 0x00 PREC=0x00 TTL=1 ID=53936 PROTO=2
Mar 31 20:01:18 stthpc kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=01:00:xxxx SRC=192.168.0.69 DST=224.0.0.1 LEN=28 TOS=0x 00 PREC=0x00 TTL=64 ID=0 PROTO=2 ***
¿Lo has cortado? ¿No se ven puertos? :-?
Datos:
- Los equipos que los generan son routers e impresoras
Preguntas:
- ¿Están mal configurados (routers e impresoras)? Es decir, que envíen esos paquetes de multidifusión ¿es el comportamiento habitual o se pueden configurar de alguna forma para que no consulten tanto? :-?
El cups puede enviar multidifusion para anunciar el servidor de impresión. El router no se.
- Si no hay nada que configurar en los equipos ¿sería posible que no se guardaran este tipo de eventos en el registro del cortafuegos?
Algo puedes hacer, claro, y más si usas el syslog-ng. Es muy configurable... pero ya sabes que esa bestia no hace lo que se espera al primer intento. Es terco como una mula. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH8S8vtTMYHG2NR9URAl8HAJ90jPcyX51bE6GMllW5qIaR99EnggCgkTzH QGO6Marc6sGln1S3ek+Q86Q= =mLzO -----END PGP SIGNATURE-----
El 31/03/08, Carlos E. R. escribió:
¿Lo has cortado? ¿No se ven puertos? :-?
Hum, no... sólo quité la mac :-?.
El cups puede enviar multidifusion para anunciar el servidor de impresión.
No es cups, son impresoras con adaptador ethernet :-?
El router no se.
¿Raro, no? :-?
Algo puedes hacer, claro, y más si usas el syslog-ng. Es muy configurable... pero ya sabes que esa bestia no hace lo que se espera al primer intento. Es terco como una mula.
Buf, le cogí tirria cuando intenté poner un poco de orden con los registros de spamd, de cyrus y hylafax... pero con tanto daemon y facility distinta para filtrar, lo dejé... pero bueno, si no hay más remedio, me tendré que poner de nuevo con él... Estaba pensando en si podía tener algo que ver con avahi (zeroconf) o con los propios equipos que están enviando paquetes multicast y el cortafuegos lo registra... pensaba que registrar este tipo de paquetes era un parámetro configurable del cortafuegos, pero si me hablas de syslog-ng pues "m'has fastidiao" >:-) 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 2008-03-31 a las 21:13 +0200, Camaleón escribió:
El 31/03/08, Carlos E. R. escribió:
¿Lo has cortado? ¿No se ven puertos? :-?
Hum, no... sólo quité la mac :-?.
He mirado en mis logs a ver si tengo algo similar, pero no.
El cups puede enviar multidifusion para anunciar el servidor de impresión.
No es cups, son impresoras con adaptador ethernet :-?
Pero usan el mismo protocolo, ipp me parece que se llama.
El router no se.
¿Raro, no? :-?
Es que no viendo el puerto, no se puede saber que servicio es.
Algo puedes hacer, claro, y más si usas el syslog-ng. Es muy configurable... pero ya sabes que esa bestia no hace lo que se espera al primer intento. Es terco como una mula.
Buf, le cogí tirria cuando intenté poner un poco de orden con los registros de spamd, de cyrus y hylafax... pero con tanto daemon y facility distinta para filtrar, lo dejé... pero bueno, si no hay más remedio, me tendré que poner de nuevo con él...
Es la manera más versatil.
Estaba pensando en si podía tener algo que ver con avahi (zeroconf) o
No conozco ese bicho. Se que existe, pero no se que hace. "apropos avahi" suelta una retahila de manuales, pero... a ver la wikipedia. Avahi is a free Zeroconf implementation, including a system for multicast DNS/DNS-SD service discovery. It allows programs to publish and discover services and hosts running on a local network with no specific configuration. For example you can plug into a network and instantly find printers to print to, files to look at and people to talk to. It is licensed under the GNU Lesser General Public License (LGPL). Pues sí que puede ser.
con los propios equipos que están enviando paquetes multicast y el cortafuegos lo registra... pensaba que registrar este tipo de paquetes era un parámetro configurable del cortafuegos, pero si me hablas de syslog-ng pues "m'has fastidiao" >:-)
Sí tienes un ajuste, pero no es afinable. Se están dejando caer por defecto; lo puedes hacer explicitamente y usar: FW_SERVICES_DROP_EXT="" ó FW_SERVICES_REJECT_EXT="0/0,tcp,113" aunque si es avahi y lo estás usando, a lo mejor lo que debes hacer es abrirles el cortafuegos, justo lo contrario. En cuanto al log: FW_LOG_DROP_CRIT="yes" FW_LOG_DROP_ALL="yes" FW_LOG_ACCEPT_CRIT="no" FW_LOG_ACCEPT_ALL="no" FW_LOG_LIMIT="" ¡Ah, mira! # If you want to drop broadcasts however ignore the annoying log entries, set # FW_IGNORE_FW_BROADCAST_* to yes. # ... FW_IGNORE_FW_BROADCAST_EXT="yes" FW_IGNORE_FW_BROADCAST_INT="no" FW_IGNORE_FW_BROADCAST_DMZ="no" Mira los ejemplos en el ficherito, se puede especificar por puertos, creo. FW_ALLOW_FW_BROADCAST_EXT="netbios-ns netbios-dgm" O sea, que sí se puede hacer lo que quieres. Rechazarlos (que es lo que haces ahora), aceptar algunos, y registrarlos o no. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH8T4utTMYHG2NR9URAg/hAJ9aWrAlgxtyZAwaQ2G7kd2cfaTF6ACfUMWc KEwLXE7liAtbtMbjKHLjJXs= =ZKAU -----END PGP SIGNATURE-----
El 31/03/08, Carlos E. R. escribió:
Pero usan el mismo protocolo, ipp me parece que se llama.
Las impresoras tienen habilitado ipp, el puerto 9100, Rendezvous, slp, lpd, mdns, ¡ah! una tiene activada la multidifusión ipv4... buf, mucha cosa veo por aquí, no me gusta :-/.
Es que no viendo el puerto, no se puede saber que servicio es.
En los router no veo nada habilitado :-?
Es la manera más versatil.
Sí, bueno, pero es algo del cortafuegos, si lo puedo configurar para que no lo registre modificando sólo una cosa, mejor :-)
¡Ah, mira!
Voy O_O
# If you want to drop broadcasts however ignore the annoying log entries, set # FW_IGNORE_FW_BROADCAST_* to yes. #
Sí, sí... eso quiero, voy p'allá.
... FW_IGNORE_FW_BROADCAST_EXT="yes" FW_IGNORE_FW_BROADCAST_INT="no" FW_IGNORE_FW_BROADCAST_DMZ="no"
Hum, ya. Creo que esto no sirve (lo probé desde el módulo del cortafuegos de yast, que aparece para activar o desactivar). Mi eth0 está como externa y esa estaba a "yes" por defecto que entiendo es lo que evita en teoría esos mensajes, pero nada. Probé a poner las otras dos a yes y tampoco. De todas formas, lo voy a hacer de forma manual, no vaya a ser que yast me la esté jugando... (...) Cambiado (las tres a "yes"), guardado y reiniciado el servicio. Espero... pero nada, me siguen llegando (cada 2 minutos se registra).
Mira los ejemplos en el ficherito, se puede especificar por puertos, creo.
FW_ALLOW_FW_BROADCAST_EXT="netbios-ns netbios-dgm"
O sea, que sí se puede hacer lo que quieres. Rechazarlos (que es lo que haces ahora), aceptar algunos, y registrarlos o no.
Pero no va :-/. Hum, a ver, sí, dice que hay que rechazarlos (drop) primero, pero eso ya está activado y nada. A ver, he parado el servicio "avahi" (rcavahi-daemon stop) y ahora no me registra entradas que vienen de las impresoras, sólo de los routers :-?. Al pararlo, el registro me dice: ** Apr 1 00:12:44 stthpc avahi-daemon[3238]: Got SIGTERM, quitting. Apr 1 00:12:44 stthpc avahi-daemon[3238]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.0.8. Apr 1 00:12:44 stthpc avahi-dnsconfd[3250]: read(): EOF ** ¿Podría dejarlo desactivado? ¿Qué hace este servicio? :-? Bueno, confirmado, sin avahi no hay registro en el cortafuegos de las impresoras. Tengo que pensar qué hago: - Dejar desactivado el servicio de avahi, que no me convence mucho :-/ - Desactivar algunos servicios de las impresoras (mdns y multidifusión) y dejar avahi a ver si de esta forma tampoco envían paquetes al cortafuegos. Esto me gusta más, cuanto menos servicios disponibles en las impresoras, mejor... Y me quedan los router que siguen enviando datos... ¿Alguna idea / sugerencia para éstos? :-? Tienen nat activado, quizá sea normal. 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 31/03/08, Carlos E. R. escribió:
Pero usan el mismo protocolo, ipp me parece que se llama.
Las impresoras tienen habilitado ipp, el puerto 9100, Rendezvous, slp, lpd, mdns, ¡ah! una tiene activada la multidifusión ipv4... buf, mucha cosa veo por aquí, no me gusta :-/.
Es que no viendo el puerto, no se puede saber que servicio es.
En los router no veo nada habilitado :-?
Me ha dicho uno en privado una cosa que yo no me suelo fijar. Recupero tu log: *** Mar 31 20:01:09 stthpc kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=01:00:xxxx SRC=192.168.0.29 DST=224.0.0.251 LEN=28 TOS= 0x00 PREC=0x00 TTL=1 ID=53936 PROTO=2 Mar 31 20:01:18 stthpc kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=01:00:xxxx SRC=192.168.0.69 DST=224.0.0.1 LEN=28 TOS=0x 00 PREC=0x00 TTL=64 ID=0 PROTO=2 *** Es protocolo "2", no "TCP. El 2 es (mirando en /etc/protocols) IGMP, que dice que es como un ping. # Decimal Keyword Protocol References # ------- ------- -------- ---------- # protocol num aliases # comments hopopt 0 HOPOPT # IPv6 Hop-by-Hop Option [RFC1883] icmp 1 ICMP # Internet Control Message [RFC792] igmp 2 IGMP # Internet Group Management [RFC1112] ggp 3 GGP # Gateway-to-Gateway [RFC823] ip 4 IP # IP in IP (encapsulation) [RFC2003] st 5 ST # Stream [RFC1190,RFC1819] tcp 6 TCP # Transmission Control [RFC793] cbt 7 CBT # CBT [Ballardie] egp 8 EGP # Exterior Gateway Protocol [RFC888,DLM1] igp 9 IGP # any private interior gateway [IANA] # (used by Cisco for their IGRP) por tanto las reglas del cortafuegos que vimos no afectan, que es lo que has descubierto con tus pruebas. No sé cual es la manera adecuada de configurar el cortafuegos para eso, ni sé que hacen esos paquetes. El curso de redes que hice no me lo contaron.
A ver, he parado el servicio "avahi" (rcavahi-daemon stop) y ahora no me registra entradas que vienen de las impresoras, sólo de los routers :-?. Al pararlo, el registro me dice:
¿La IP de donde salen es la IP propia de la maquina? ¿Es decir, son paquetes salientes o entrantes? No se ni cómo funciona IGMP ni el avahi.
** Apr 1 00:12:44 stthpc avahi-daemon[3238]: Got SIGTERM, quitting. Apr 1 00:12:44 stthpc avahi-daemon[3238]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.0.8. Apr 1 00:12:44 stthpc avahi-dnsconfd[3250]: read(): EOF **
¿Podría dejarlo desactivado? ¿Qué hace este servicio? :-?
No lo se... ¿Tomar nota de lo que hay por la red, para que cuando necesites una impresora o alguna cosa decirte donde están?
Bueno, confirmado, sin avahi no hay registro en el cortafuegos de las impresoras. Tengo que pensar qué hago:
- Dejar desactivado el servicio de avahi, que no me convence mucho :-/ - Desactivar algunos servicios de las impresoras (mdns y multidifusión) y dejar avahi a ver si de esta forma tampoco envían paquetes al cortafuegos. Esto me gusta más, cuanto menos servicios disponibles en las impresoras, mejor...
Y me quedan los router que siguen enviando datos... ¿Alguna idea / sugerencia para éstos? :-? Tienen nat activado, quizá sea normal.
Como el cortafuegos bloquea esos paquetes, es inutil lo que trate de hacer. Habrá que leerse la wikipedia. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH8XwvtTMYHG2NR9URAkl+AJ9Yf4RUis8pAGpjnngW9yP9o6raJwCfbGoZ QeuyLh0f2ZGF42zFRKqory8= =3IRg -----END PGP SIGNATURE-----
El 1/04/08, Carlos E. R. escribió:
Me ha dicho uno en privado
Os doy la medallita a ambos, pues :-)... lo detallo más abajo.
una cosa que yo no me suelo fijar. Recupero tu log:
*** Mar 31 20:01:09 stthpc kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=01:00:xxxx SRC=192.168.0.29 DST=224.0.0.251 LEN=28 TOS= 0x00 PREC=0x00 TTL=1 ID=53936 PROTO=2
Mar 31 20:01:18 stthpc kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=01:00:xxxx SRC=192.168.0.69 DST=224.0.0.1 LEN=28 TOS=0x 00 PREC=0x00 TTL=64 ID=0 PROTO=2 ***
Es protocolo "2", no "TCP. El 2 es (mirando en /etc/protocols) IGMP, que dice que es como un ping.
Hum... hum... igmp...
por tanto las reglas del cortafuegos que vimos no afectan, que es lo que has descubierto con tus pruebas.
Correcto y lógico.
¿La IP de donde salen es la IP propia de la maquina? ¿Es decir, son paquetes salientes o entrantes? No se ni cómo funciona IGMP ni el avahi.
Sí, son los propios equipos (impresoras y routers). Si lo registra suse, serán paquetes salientes desde los equipos --> hacia el resto de equipos de la red.
No lo se... ¿Tomar nota de lo que hay por la red, para que cuando necesites una impresora o alguna cosa decirte donde están?
Sí, eso parece... una especie de "self-service" de configuración de equipos en red (de la wiki): *** "Zeroconf or Zero Configuration Networking is a set of techniques that automatically create a usable IP network without configuration or special servers. This allows inexpert users to connect computers, networked printers, and other items together and expect them to work automatically (...)" *** ¿"Automáticamente"? Glups, pues si este servicio funciona bien nos quita el puesto :-P.
Como el cortafuegos bloquea esos paquetes, es inutil lo que trate de hacer.
Creo que tengo... algo. Al final del día reporto de nuevo y confirmo...
Habrá que leerse la wikipedia.
La wiki no sé, pero el archivo de configuración de susefirewall2 hay que leerlo bien O:-). Siguiendo la sugerencia del "anónimo" usuario que indicó lo del igmp, acabo de configurar la siguiente variable que me decías ayer y que, erróneamente obvié, porque no caí en el protocolo: ## Type: string # # Packets to silently drop without log message # # Format: space separated list of net,protocol[,port][,sport] # Example: "0/0,tcp,445 0/0,udp,4662" # # The special value _rpc_ is recognized as protocol and means that dport is # interpreted as rpc service name. See FW_SERVICES_EXT_RPC for # details. # FW_SERVICES_DROP_EXT="0/0,igmp" Reiniciando el cortafuegos, los mensajes multicast (proto=2) han desaparecido :-D. Y al ejecutar "iptables -L", veo lo siguiente: DROP igmp -- anywhere anywhere state NEW ¿Efectos secundarios? Pues no sé, espero que siga registrando el resto de conexiones (¿cómo podría probarlo?) y que descartar los paquetes multicast no me de problemas. Lo mantendré en observación unos días... 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 1/04/08, Carlos E. R. escribió:
Me ha dicho uno en privado
Os doy la medallita a ambos, pues :-)... lo detallo más abajo.
A ver, a ver... :-)
una cosa que yo no me suelo fijar. Recupero tu log:
*** Mar 31 20:01:09 stthpc kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=01:00:xxxx SRC=192.168.0.29 DST=224.0.0.251 LEN=28 TOS= 0x00 PREC=0x00 TTL=1 ID=53936 PROTO=2
Mar 31 20:01:18 stthpc kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=01:00:xxxx SRC=192.168.0.69 DST=224.0.0.1 LEN=28 TOS=0x 00 PREC=0x00 TTL=64 ID=0 PROTO=2 ***
Sí, eso parece... una especie de "self-service" de configuración de equipos en red (de la wiki):
*** "Zeroconf or Zero Configuration Networking is a set of techniques that automatically create a usable IP network without configuration or special servers. This allows inexpert users to connect computers, networked printers, and other items together and expect them to work automatically (...)" ***
¿"Automáticamente"? Glups, pues si este servicio funciona bien nos quita el puesto :-P.
X-) Nada, nada, a boicotearlo, cortafuegos cerrados alprotocolo :-p
Como el cortafuegos bloquea esos paquetes, es inutil lo que trate de hacer.
Creo que tengo... algo. Al final del día reporto de nuevo y confirmo...
Habrá que leerse la wikipedia.
La wiki no sé, pero el archivo de configuración de susefirewall2 hay que leerlo bien O:-).
Siguiendo la sugerencia del "anónimo" usuario que indicó lo del igmp, acabo de configurar la siguiente variable que me decías ayer y que, erróneamente obvié, porque no caí en el protocolo:
## Type: string # # Packets to silently drop without log message # # Format: space separated list of net,protocol[,port][,sport] # Example: "0/0,tcp,445 0/0,udp,4662" # # The special value _rpc_ is recognized as protocol and means that dport is # interpreted as rpc service name. See FW_SERVICES_EXT_RPC for # details. # FW_SERVICES_DROP_EXT="0/0,igmp"
Pero entonces estás cerrando todo el igm, no sólo esos multicast. Uno directo también se bloqueará, y como lo haces silenciosamente, no te enterarás. Si acaso hazlo por IP de origen a esas máquinas concretas :-?
Reiniciando el cortafuegos, los mensajes multicast (proto=2) han desaparecido :-D. Y al ejecutar "iptables -L", veo lo siguiente:
DROP igmp -- anywhere anywhere state NEW
¿Efectos secundarios? Pues no sé, espero que siga registrando el resto de conexiones (¿cómo podría probarlo?) y que descartar los paquetes multicast no me de problemas. Lo mantendré en observación unos días...
pero es que los cierras todos. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH8foDtTMYHG2NR9URAt0mAJ996S6FrgzpudP6jGcOhl54LC6qCQCfdsms Thm8Fxu1csYQz9TANrWE47k= =38Lb -----END PGP SIGNATURE-----
El 1/04/08, Carlos E. R. escribió:
Pero entonces estás cerrando todo el igm, no sólo esos multicast. Uno directo también se bloqueará, y como lo haces silenciosamente, no te enterarás.
Si acaso hazlo por IP de origen a esas máquinas concretas :-?
Pues no sé... pero mira, tenerlo abierto seguro es un riesgo de seguridad >:-).
pero es que los cierras todos.
Por eso está en observación O:-). Lo que sí me gustaría comprobar es que el resto de entradas se registran... de momento veo actividad: *** Apr 1 10:46:59 stthpc kernel: SFW2-INext-DROP-DEFLT-INV IN=eth0 OUT= MAC=00:xxx SRC=192.168.0.5 DST=192.168.0.8 LEN=40 T OS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=56153 DPT=29695 WINDOW=0 RES=0x00 RST URGP=0 Apr 1 11:16:29 stthpc kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC= SRC=192.168.0.8 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP S PT=5353 DPT=5353 LEN=44 *** 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 2008-04-01 a las 11:52 +0200, Camaleón escribió:
El 1/04/08, Carlos E. R. escribió:
Pero entonces estás cerrando todo el igm, no sólo esos multicast. Uno directo también se bloqueará, y como lo haces silenciosamente, no te enterarás.
Si acaso hazlo por IP de origen a esas máquinas concretas :-?
Pues no sé... pero mira, tenerlo abierto seguro es un riesgo de seguridad >:-).
Es como un ping, no tiene gran peligro.
pero es que los cierras todos.
Por eso está en observación O:-).
No lo verás.
Lo que sí me gustaría comprobar es que el resto de entradas se registran... de momento veo actividad:
*** Apr 1 10:46:59 stthpc kernel: SFW2-INext-DROP-DEFLT-INV IN=eth0 OUT= MAC=00:xxx SRC=192.168.0.5 DST=192.168.0.8 LEN=40 T OS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=56153 DPT=29695 WINDOW=0 RES=0x00 RST URGP=0
Apr 1 11:16:29 stthpc kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC= SRC=192.168.0.8 DST=224.0.0.251 LEN=64 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP S PT=5353 DPT=5353 LEN=44 ***
Pero son TCP y UDP. De IGMP no verás nada. Wikipedia: The Internet Group Management Protocol (IGMP) is a communications protocol used to manage the membership of Internet Protocol multicast groups. IGMP is used by IP hosts and adjacent multicast routers to establish multicast group memberships. It is an integral part of the IP multicast specification, operating above the network layer, though it doesn't actually act as a transport protocol[1]. It is analogous to ICMP for unicast connections. IGMP can be used for online streaming video and gaming, and allows more efficient use of resources when supporting these uses. IGMP does allow some attacks[2] [3] [4] [5], and firewalls commonly allow the user to disable it if not needed. Pone algo más, pero no mucho. ¿Usais algún tipo de broadcast de vídeo? Parece que se usa para eso. Yo en todo mi histórico de logs no tengo ningún "PROTO=2" - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH8gwPtTMYHG2NR9URAsiVAJ9LiRxCPbb731mDPRr70Y3lDkXrSgCghDVZ a265p2bOtb3X3qPmI7bvwSc= =npxv -----END PGP SIGNATURE-----
El 1/04/08, Carlos E. R. escribió:
Es como un ping, no tiene gran peligro.
Psé... Multiple Vendor Spoofed IGMP Report Denial Of Service Vulnerability http://www.securityfocus.com/bid/5020/info IGMP Security Problem Statement and Requirements (PDF) http://www.securemulticast.org/GSEC/gsec3_ietf53_SecureIGMP1.pdf
:-)
No lo verás.
Me refería a los servicios (samba, impresión, cups, fax...) de momento ninguno se queja.
Pero son TCP y UDP. De IGMP no verás nada.
No, claro ¡es que no quiero verlos! Me inundan el registro y eso que sólo vienen de unos cuantos equipos... y si dejara pasar los paquetes igmp y no lo registrara pues tampoco me serviría de nada :-/. La cuestión es por qué son tan "comunicativos".
Wikipedia:
The Internet Group Management Protocol (IGMP) is a communications protocol used to manage the membership of Internet Protocol multicast groups. IGMP is used by IP hosts and adjacent multicast routers to establish multicast group memberships.
(...)
Pone algo más, pero no mucho. ¿Usais algún tipo de broadcast de vídeo? Parece que se usa para eso.
Pues no. Pero también se usa con snmp, creo, y eso sí tienen las impresoras. En los routers poco puedo configurar y no veo nada relacionado que controle el envío de este tipo de paquetes, quizá vía CLI.
Yo en todo mi histórico de logs no tengo ningún "PROTO=2"
Es raro, sí. Y no veo ningún problema en registrarlo, pero no cada 2 minutos y por cada chisme, eso no me sirve, porque me "desvirtua" el registro. Lo voy a dejar así, pero lo anoto en el cortafuegos para saber qué variable he modificado y con qué propósito. 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 2008-04-01 a las 12:58 +0200, Camaleón escribió:
El 1/04/08, Carlos E. R. escribió:
Es como un ping, no tiene gran peligro.
Psé...
Multiple Vendor Spoofed IGMP Report Denial Of Service Vulnerability http://www.securityfocus.com/bid/5020/info
IGMP Security Problem Statement and Requirements (PDF) http://www.securemulticast.org/GSEC/gsec3_ietf53_SecureIGMP1.pdf
:-)
Fale, fale, algún dia que me aburra los leo.
No lo verás.
Me refería a los servicios (samba, impresión, cups, fax...) de momento ninguno se queja.
Pero son TCP y UDP. De IGMP no verás nada.
No, claro ¡es que no quiero verlos! Me inundan el registro y eso que sólo vienen de unos cuantos equipos... y si dejara pasar los paquetes igmp y no lo registrara pues tampoco me serviría de nada :-/. La cuestión es por qué son tan "comunicativos".
Porque se usa para descubrirse entre si. Esos chismes anuncian cada dos por tres que están ahí por si alguien lo necesita. Si necesitas el servicio que ofrecen no te gustaría esperar media hora hasta que tu programa descubra donde está el router con esa capacidad.
(...)
Pone algo más, pero no mucho. ¿Usais algún tipo de broadcast de vídeo? Parece que se usa para eso.
Pues no. Pero también se usa con snmp, creo, y eso sí tienen las impresoras. En los routers poco puedo configurar y no veo nada relacionado que controle el envío de este tipo de paquetes, quizá vía CLI.
Si son cisco, seguro que se puede hacer algo :-p
Yo en todo mi histórico de logs no tengo ningún "PROTO=2"
Es raro, sí. Y no veo ningún problema en registrarlo, pero no cada 2 minutos y por cada chisme, eso no me sirve, porque me "desvirtua" el registro.
Por eso te dije lo del syslog-ng
Lo voy a dejar así, pero lo anoto en el cortafuegos para saber qué variable he modificado y con qué propósito.
Si, eso siempre es bueno. Y en una libreta. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH8iLZtTMYHG2NR9URAv2FAJsGQHHBy5Nb1z49sR+B6TIhH8FZSACeLC6Q tazi4JcGD8W2LzwkO1hzO+Y= =88Xu -----END PGP SIGNATURE-----
El 1/04/08, Carlos E. R. escribió:
Fale, fale, algún dia que me aburra los leo.
Y el del "ping de la muerte", también >:-) http://en.wikipedia.org/wiki/Ping_of_death Por cierto (de la wiki)... *** "(...) IGMP does allow some attacks[2] [3] [4] [5], and firewalls commonly allow the user to disable it if not needed." *** Ea, cerrado a cal y canto. Si algún paquete igmp quiere pasar, que llame antes >:-)
Porque se usa para descubrirse entre si. Esos chismes anuncian cada dos por tres
Cada dos minutos, exactamente...
que están ahí por si alguien lo necesita. Si necesitas el servicio que ofrecen no te gustaría esperar media hora hasta que tu programa descubra donde está el router con esa capacidad.
Me parece bien, pero para que sea efectivo, debería ser un parámetro configurable (activar / desactivar, intervalo de consulta, etc...). Imagina una red con cientos de equipos, todos escuchando "la canción del multicast / igmp". Digo yo que se genera un tráfico innecesario en la red.
Si son cisco, seguro que se puede hacer algo :-p
Va a ser que no O:-). Son los Nokia M1112 que ponía Telefónica sobre rdsi hará unos 6 / 7 años. Y ahora que lo pienso, el otro router (un speedstream) no dice ni "mu", no envía nada... Ah, será que Alcatel sabe hacer chismes ;-). 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:
Cada dos minutos, exactamente...
que están ahí por si alguien lo necesita. Si necesitas el servicio que ofrecen no te gustaría esperar media hora hasta que tu programa descubra donde está el router con esa capacidad.
Me parece bien, pero para que sea efectivo, debería ser un parámetro configurable (activar / desactivar, intervalo de consulta, etc...).
Imagina una red con cientos de equipos, todos escuchando "la canción del multicast / igmp". Digo yo que se genera un tráfico innecesario en la red.
Holas! Pero es que tiene que ser así, es inevitable por ser necesario, discutible si es mucho ó bastante tráfico, quieres ver más? sniffea tráfico arp en redes públicas, 802.1d en redes privadas, bgp más arriba, cdp para quienes configuren switches sin segurizar... y la lista continúa, y se va agrandando conforme las nuevas tecnologías se van implementando... VoIP, wireless, etc (hasta con dos latas unidas por una cuerda tienes ese efecto, y no es analogía...) Y tienes razón, quien matenga tu red, debe estudiar qué cosas publica, y cada cuanto de intervalos. Ahora, tal vez no venga al caso, pero con eso del log del firewall me has hecho acordar de algo que desde que apareció siempre quise saber.. La pregunta es.. se sabe que "dmesg" es lo que hay en el buffer del kernel que ha disparado al syslog para que o procese, bah, en realidad, es syslogd quien sabe capturarselo al kernel. Bien.. hay forma de que "kernel" no mantenga en el buffer los eventos de firewall? ó decirle: no "bufferees" los eventos del firewall.. Saludos Ricardo. --------------------------------------------------------------------- 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 2008-04-01 a las 11:20 -0300, Ricardo escribió:
Ahora, tal vez no venga al caso, pero con eso del log del firewall me has hecho acordar de algo que desde que apareció siempre quise saber.. La pregunta es.. se sabe que "dmesg" es lo que hay en el buffer del kernel que ha disparado al syslog para que o procese, bah, en realidad, es syslogd quien sabe capturarselo al kernel. Bien.. hay forma de que "kernel" no mantenga en el buffer los eventos de firewall? ó decirle: no "bufferees" los eventos del firewall..
Creo que no. Es el daemon de postproceso, el syslog, el que implementa los filtros; el dmesg es una simple pila. Bueno, dmesg es el comando, la pila creo que es /dev/kmsg - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH8knmtTMYHG2NR9URAmrOAJ4vvA+ETsKxlvS9sM/uX4au2DxHSACfYcnj BvdHj9bTSG1OK8cSDJe/xIA= =ENzJ -----END PGP SIGNATURE-----
Carlos E. R. wrote:
El 2008-04-01 a las 11:20 -0300, Ricardo escribió:
Ahora, tal vez no venga al caso, pero con eso del log del firewall me has hecho acordar de algo que desde que apareció siempre quise saber.. La pregunta es.. se sabe que "dmesg" es lo que hay en el buffer del kernel que ha disparado al syslog para que o procese, bah, en realidad, es syslogd quien sabe capturarselo al kernel. Bien.. hay forma de que "kernel" no mantenga en el buffer los eventos de firewall? ó decirle: no "bufferees" los eventos del firewall..
Creo que no.
Es el daemon de postproceso, el syslog, el que implementa los filtros; el dmesg es una simple pila.
Bueno, dmesg es el comando, la pila creo que es /dev/kmsg
-- Saludos Carlos E.R.
Sep, exactamente.. bueno, seguiré quejandomé.... aunque pensandolo mejo, lo que quiero es por naturaleza imposible, al menos ilógico.. Gracias --------------------------------------------------------------------- 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 1/04/08, Ricardo escribió:
aunque pensandolo mejo, lo que quiero es por naturaleza imposible, al menos ilógico..
Para nada... el dmesg tiene que servir precisamente para "depurar" problemas, por lo que debería ser más flexible, al menos en la presentación de salida de datos. "man dmesg" menciona el parámetro "-n nivel", y es una buena idea. La pregunta es qué tipo de niveles permite (críticos, pánico...) y qué gestionan cada uno de ellos ¿hardware, red, seguridad, servicios...? :-? 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 1/04/08, Ricardo escribió:
aunque pensandolo mejo, lo que quiero es por naturaleza imposible, al menos ilógico..
Para nada... el dmesg tiene que servir precisamente para "depurar" problemas, por lo que debería ser más flexible, al menos en la presentación de salida de datos.
"man dmesg" menciona el parámetro "-n nivel", y es una buena idea. La pregunta es qué tipo de niveles permite (críticos, pánico...) y qué gestionan cada uno de ellos ¿hardware, red, seguridad, servicios...? :-?
Saludos,
y no... si no lo ejecuto a la "antigua" (léase | grep) no me dá nada con las opciones de level...... qué habrán querido decir.. --------------------------------------------------------------------- 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 1/04/08, Ricardo escribió:
y no... si no lo ejecuto a la "antigua" (léase | grep) no me dá nada
¿Cómo que no? >:-) hpc02@stthpc:~> dmesg | grep -i tty serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A La "-i" le indica que sea "case insensitive". ¿No hay un comando contrario a "grep" (un grep reverse :-P) es decir, que saque todo lo que no concuerde con el término que le precede? Así se podría evitar la salida del cortafuegos >:-)
con las opciones de level...... qué habrán querido decir..
Ni idea... no pone mas información, no sé qué tipo de eventos registran esos niveles ni cuántos hay :-? 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 1/04/08, Ricardo escribió:
y no... si no lo ejecuto a la "antigua" (léase | grep) no me dá nada
¿Cómo que no? >:-)
hpc02@stthpc:~> dmesg | grep -i tty serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
La "-i" le indica que sea "case insensitive".
¿No hay un comando contrario a "grep" (un grep reverse :-P) es decir, que saque todo lo que no concuerde con el término que le precede? Así se podría evitar la salida del cortafuegos >:-)
con las opciones de level...... qué habrán querido decir..
Ni idea... no pone mas información, no sé qué tipo de eventos registran esos niveles ni cuántos hay :-?
Saludos,
Que siiii, que te estaba diciendo que si no lo filtro "a la antigüita", no filtra, que tamos de acuerdo en eso See, pruebate el "egrep" Hasta donde acepta, va del dmesg -n1 al dmesg -n8... --------------------------------------------------------------------- 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 1/04/08, Ricardo escribió:
Que siiii, que te estaba diciendo que si no lo filtro "a la antigüita", no filtra, que tamos de acuerdo en eso
Ah, vale. Leí mal, entendí peor O:-).
See, pruebate el "egrep"
Hum... bueno, con: dmesg | grep -i -v sfw2 No veo ni rastro del cortafuegos. No sé qué mas se habrá podido zampar :-?
Hasta donde acepta, va del dmesg -n1 al dmesg -n8...
Donde -n1 registra... ¿lo qué eventos? Y -n8 registra ¿lo qué otros eventos? :-? 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 1/04/08, Ricardo escribió:
Que siiii, que te estaba diciendo que si no lo filtro "a la antigüita", no filtra, que tamos de acuerdo en eso
Ah, vale. Leí mal, entendí peor O:-).
See, pruebate el "egrep"
Hum... bueno, con:
dmesg | grep -i -v sfw2
No veo ni rastro del cortafuegos. No sé qué mas se habrá podido zampar :-?
Hasta donde acepta, va del dmesg -n1 al dmesg -n8...
Donde -n1 registra... ¿lo qué eventos? Y -n8 registra ¿lo qué otros eventos? :-?
Saludos,
Y está bien... ya con el -v anulas las entradas que contengan "sfw2" O no entendí lo que querrías con eso de "un grep reverse" y sii, el comando acepta el modificador, pero sólo hace eso... aceptarlo jejejeje, pero de ahí a debug... le falta pulida a eso... --------------------------------------------------------------------- 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 1/04/08, Ricardo escribió:
Que siiii, que te estaba diciendo que si no lo filtro "a la antigüita", no filtra, que tamos de acuerdo en eso
Ah, vale. Leí mal, entendí peor O:-).
See, pruebate el "egrep"
Hum... bueno, con:
dmesg | grep -i -v sfw2
No veo ni rastro del cortafuegos. No sé qué mas se habrá podido zampar :-?
Hasta donde acepta, va del dmesg -n1 al dmesg -n8...
Donde -n1 registra... ¿lo qué eventos? Y -n8 registra ¿lo qué otros eventos? :-?
Saludos,
Que ya caigo, y esto es parte de una duda ancestral, que por falta de tiempo y/o ganas, nunca me detuve a desasnar... dmesg1... dmesg7 se refieren a la variable "facility" recuerdan ó vieron alguna vez LOCAL0, LOCAL1, etc? es eso el modificador... ja! mi vida es mas fácil ahora.... :) pero igual voy a seguir viviendo sin personalizar las "facilities".... y continuaré editando a la syslog por .info y .kern y a la syslog-ng crreando filtros y destinations... sisi Saludos! --------------------------------------------------------------------- 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 2008-04-01 a las 14:28 -0300, Ricardo escribió:
Que ya caigo, y esto es parte de una duda ancestral, que por falta de tiempo y/o ganas, nunca me detuve a desasnar... dmesg1... dmesg7 se refieren a la variable "facility" recuerdan ó vieron alguna vez LOCAL0, LOCAL1, etc? es eso el modificador... ja! mi vida es mas fácil ahora.... :) pero igual voy a seguir viviendo sin personalizar las "facilities".... y continuaré editando a la syslog por .info y .kern y a la syslog-ng crreando filtros y destinations... sisi
A ver, que os liais más que la pata de un romano. Los niveles no son "facility", son niveles. La facility es "kernel", está fijada. Los niveles venían explicados muy bien en el manual de syslog, y si teneis el syslog-ng, que no lo explica porque lo da por sabido. Los teneis en man 2 syslog: #define KERN_EMERG "<0>" /* system is unusable */ #define KERN_ALERT "<1>" /* action must be taken immediately */ #define KERN_CRIT "<2>" /* critical conditions */ #define KERN_ERR "<3>" /* error conditions */ #define KERN_WARNING "<4>" /* warning conditions */ #define KERN_NOTICE "<5>" /* normal but significant condition */ #define KERN_INFO "<6>" /* informational */ #define KERN_DEBUG "<7>" /* debug-level messages */ Capishi? :-) - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH8nigtTMYHG2NR9URAm1zAKCGSS99UvhDoSHEHzqJphvcV9LU8QCcCPnu /ayUC7aJqfQhkfK1yK/MjUw= =fDuI -----END PGP SIGNATURE-----
Carlos E. R. wrote:
El 2008-04-01 a las 14:28 -0300, Ricardo escribió:
Que ya caigo, y esto es parte de una duda ancestral, que por falta de tiempo y/o ganas, nunca me detuve a desasnar... dmesg1... dmesg7 se refieren a la variable "facility" recuerdan ó vieron alguna vez LOCAL0, LOCAL1, etc? es eso el modificador... ja! mi vida es mas fácil ahora.... :) pero igual voy a seguir viviendo sin personalizar las "facilities".... y continuaré editando a la syslog por .info y .kern y a la syslog-ng crreando filtros y destinations... sisi
A ver, que os liais más que la pata de un romano.
Los niveles no son "facility", son niveles. La facility es "kernel", está fijada.
Los niveles venían explicados muy bien en el manual de syslog, y si teneis el syslog-ng, que no lo explica porque lo da por sabido. Los teneis en man 2 syslog:
#define KERN_EMERG "<0>" /* system is unusable */ #define KERN_ALERT "<1>" /* action must be taken immediately */ #define KERN_CRIT "<2>" /* critical conditions */ #define KERN_ERR "<3>" /* error conditions */ #define KERN_WARNING "<4>" /* warning conditions */ #define KERN_NOTICE "<5>" /* normal but significant condition */ #define KERN_INFO "<6>" /* informational */ #define KERN_DEBUG "<7>" /* debug-level messages */
Capishi? :-)
-- Saludos Carlos E.R.
No te entiendo, será estamos hablando de lo mismo? ahora, qué niveles? si es por mí, no lo he dicho, no he nombrado niveles........ Como sea, estamos de acuerdo, y eso me basta. --------------------------------------------------------------------- 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:
El 2008-04-01 a las 14:28 -0300, Ricardo escribió:
Que ya caigo, y esto es parte de una duda ancestral, que por falta de tiempo y/o ganas, nunca me detuve a desasnar... dmesg1... dmesg7 se refieren a la variable "facility" recuerdan ó vieron alguna vez LOCAL0, LOCAL1, etc? es eso el modificador... ja! mi vida es mas fácil ahora.... :) pero igual voy a seguir viviendo sin personalizar las "facilities".... y continuaré editando a la syslog por .info y .kern y a la syslog-ng crreando filtros y destinations... sisi
A ver, que os liais más que la pata de un romano.
Los niveles no son "facility", son niveles. La facility es "kernel", está fijada.
Los niveles venían explicados muy bien en el manual de syslog, y si teneis el syslog-ng, que no lo explica porque lo da por sabido. Los teneis en man 2 syslog:
#define KERN_EMERG "<0>" /* system is unusable */ #define KERN_ALERT "<1>" /* action must be taken immediately */ #define KERN_CRIT "<2>" /* critical conditions */ #define KERN_ERR "<3>" /* error conditions */ #define KERN_WARNING "<4>" /* warning conditions */ #define KERN_NOTICE "<5>" /* normal but significant condition */ #define KERN_INFO "<6>" /* informational */ #define KERN_DEBUG "<7>" /* debug-level messages */
Capishi? :-)
No te entiendo, será estamos hablando de lo mismo? ahora, qué niveles? si es por mí, no lo he dicho, no he nombrado niveles........
¿No? Pues yo os he visto hablando de niveles o levels referente a la opción -n de dmesg: -nlevel Set the level at which logging of messages is done to the console. For example, -n 1 prevents all messages, expect panic messages, from appear‐ ing on the console. All levels of messages are still written to /proc/kmsg, so syslogd(8) can still be used to control exactly where kernel messages appear. When the -n option is used, dmesg will not print or clear the kernel ring buffer. En el correo anterior decías que eso era lo de "facility", y yo digo que no, que no es eso.
Como sea, estamos de acuerdo, y eso me basta.
Pues ahora sí que me he perdido. :-? - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH8pCJtTMYHG2NR9URAl3LAJ4iPKhLWp7My0q2s0WhZJU+DR3pfwCcCD8R 7qpP96JaJ2uzRxecjuq0PMU= =+YD2 -----END PGP SIGNATURE-----
Carlos E. R. wrote:
Content-ID:
El 2008-04-01 a las 15:11 -0300, Ricardo escribió:
Carlos E. R. wrote:
El 2008-04-01 a las 14:28 -0300, Ricardo escribió:
Que ya caigo, y esto es parte de una duda ancestral, que por falta de tiempo y/o ganas, nunca me detuve a desasnar... dmesg1... dmesg7 se refieren a la variable "facility" recuerdan ó vieron alguna vez LOCAL0, LOCAL1, etc? es eso el modificador... ja! mi vida es mas fácil ahora.... :) pero igual voy a seguir viviendo sin personalizar las "facilities".... y continuaré editando a la syslog por .info y .kern y a la syslog-ng crreando filtros y destinations... sisi
A ver, que os liais más que la pata de un romano.
Los niveles no son "facility", son niveles. La facility es
"kernel", está
fijada.
Los niveles venían explicados muy bien en el manual de syslog, y si teneis el syslog-ng, que no lo explica porque lo da por sabido. Los teneis en man 2 syslog:
#define KERN_EMERG "<0>" /* system is unusable */ #define KERN_ALERT "<1>" /* action must be taken immediately */ #define KERN_CRIT "<2>" /* critical conditions */ #define KERN_ERR "<3>" /* error conditions */ #define KERN_WARNING "<4>" /* warning conditions */ #define KERN_NOTICE "<5>" /* normal but significant condition */ #define KERN_INFO "<6>" /* informational */ #define KERN_DEBUG "<7>" /* debug-level messages */
Capishi? :-)
No te entiendo, será estamos hablando de lo mismo? ahora, qué niveles? si es por mí, no lo he dicho, no he nombrado niveles........
¿No? Pues yo os he visto hablando de niveles o levels referente a la opción -n de dmesg:
-nlevel Set the level at which logging of messages is done to the console. For example, -n 1 prevents all messages, expect panic messages, from appear ing on the console. All levels of messages are still written to /proc/kmsg, so syslogd(8) can still be used to control exactly where kernel messages appear. When the -n option is used, dmesg will not print or clear the kernel ring buffer.
En el correo anterior decías que eso era lo de "facility", y yo digo que no, que no es eso.
Como sea, estamos de acuerdo, y eso me basta.
Pues ahora sí que me he perdido. :-?
-- Saludos Carlos E.R. Más de acuerdo, niveles se dijo cuando se habló de dmseg (por lo del bendito "-n"), y hasta donde llevaba el hilo de lo que se decía ahí quedó esa palabreja, después no se la volvío a nombrar, ya que tácitamente había quedado que lo que el dmesg entendía como level, era ni más ni menos que el "LOCAL" en idioma klogd, como muy bien aclaraste tú. Y que es exactamente lo que acabas de pegar. De vuelta, estamos hablando de lo mismo, créeme.
--------------------------------------------------------------------- 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 2008-04-01 a las 18:17 +0200, Camaleón escribió:
¿No hay un comando contrario a "grep" (un grep reverse :-P) es decir, que saque todo lo que no concuerde con el término que le precede? Así se podría evitar la salida del cortafuegos >:-)
La -v invierte el significado, devuelve lo que no coincide. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH8njjtTMYHG2NR9URAq1sAJ94xIUxKrgL3Yr+Lc7rBv5m1FSlPACdFKk8 xcKu8lBjcg6hPX3CP/myaxY= =2yUk -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-04-01 a las 15:53 +0200, Camaleón escribió:
El 1/04/08, Carlos E. R. escribió:
Fale, fale, algún dia que me aburra los leo.
Y el del "ping de la muerte", también >:-)
Pero de todos modos ese bug ya no existe en los linuxes.
Por cierto (de la wiki)...
*** "(...) IGMP does allow some attacks[2] [3] [4] [5], and firewalls commonly allow the user to disable it if not needed." ***
Ya lo vi.
Ea, cerrado a cal y canto. Si algún paquete igmp quiere pasar, que llame antes >:-)
Pues eso hacían, llamar.
Porque se usa para descubrirse entre si. Esos chismes anuncian cada dos por tres
Cada dos minutos, exactamente...
ya, ya.
que están ahí por si alguien lo necesita. Si necesitas el servicio que ofrecen no te gustaría esperar media hora hasta que tu programa descubra donde está el router con esa capacidad.
Me parece bien, pero para que sea efectivo, debería ser un parámetro configurable (activar / desactivar, intervalo de consulta, etc...).
Puede. Pero cada dos minutos no es tanto trafico. Más hacen los windozes con el samba y no te das cuenta.
Imagina una red con cientos de equipos, todos escuchando "la canción del multicast / igmp". Digo yo que se genera un tráfico innecesario en la red.
Escuchando, no generando.
Si son cisco, seguro que se puede hacer algo :-p
Va a ser que no O:-).
Son los Nokia M1112 que ponía Telefónica sobre rdsi hará unos 6 / 7 años. Y ahora que lo pienso, el otro router (un speedstream) no dice ni "mu", no envía nada... Ah, será que Alcatel sabe hacer chismes ;-).
Es de antes de eso ;-) Bueno, si lo pensaban usar para multimedia pues le pondrían eso. A saber. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH8kvGtTMYHG2NR9URAooEAJ9pimA4KmwCxqQCmPqX6etfjwxWHwCgkX1H fBDO8810PlbJqIsJiw3mEJI= =k9TO -----END PGP SIGNATURE-----
robin.listas> > Pues no sé... pero mira, tenerlo abierto seguro es un riesgo de seguridad >:-). robin.listas> robin.listas> Es como un ping, no tiene gran peligro. Si, si tiene peligro. Hay algunos ataques basados en IGMP. Ahora solo se me ocurre "el beso de la muerte" que solo afectaba a máquinas windows, pero seguro que tiene que haber más cosas. :-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2008-04-01 a las 16:14 +0200, J.M.Queralt escribió:
robin.listas> Es como un ping, no tiene gran peligro.
Si, si tiene peligro. Hay algunos ataques basados en IGMP. Ahora solo se me ocurre "el beso de la muerte" que solo afectaba a máquinas windows,
¿Ese era con igmp?
pero seguro que tiene que haber más cosas. :-)
Güeno. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFH8kf4tTMYHG2NR9URAshmAJ9ytpI0edMeVMpHw0JTNvCf7VYYswCfYEez 5bENNfGqszK6Y9dGCKtNaMw= =Fluh -----END PGP SIGNATURE-----
Carlos E. R. wrote:
El 2008-04-01 a las 16:14 +0200, J.M.Queralt escribió:
robin.listas> Es como un ping, no tiene gran peligro.
Si, si tiene peligro. Hay algunos ataques basados en IGMP. Ahora solo se me ocurre "el beso de la muerte" que solo afectaba a máquinas windows,
¿Ese era con igmp?
pero seguro que tiene que haber más cosas. :-)
Güeno.
-- Saludos Carlos E.R.
Uhh!! si.. qué recuerdos..... era la que hacía también... (jejej) que se active el blue screen en wuindows..., se llamó tmb "blue screen de la muerte" y si, eso es igmp.. Y que no, no tiene peligro, para eso salen los parches, incluidos los de los kernel de linux, (comentario sólo para los fanáticos.....) --------------------------------------------------------------------- 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 mar, 01-04-2008 a las 02:05 +0200, Carlos E. R. escribió:
*** Mar 31 20:01:09 stthpc kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=01:00:xxxx SRC=192.168.0.29 DST=224.0.0.251 LEN=28 TOS= 0x00 PREC=0x00 TTL=1 ID=53936 PROTO=2
Mar 31 20:01:18 stthpc kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=01:00:xxxx SRC=192.168.0.69 DST=224.0.0.1 LEN=28 TOS=0x 00 PREC=0x00 TTL=64 ID=0 PROTO=2 ***
Los dos destinos son multicast, en el 224.0.0.1 creo que responden a un ping 224.0.0.1 todos los equipos de esta red que tienen capacidad multicast, el del 251 esta buscando algo tambien en esta red, fijate el TTL = 1; habria que mirar en IANA que son. Saludos Lluis
participants (5)
-
Camaleón
-
Carlos E. R.
-
J.M.Queralt
-
Lluis Martinez
-
Ricardo