Re: [opensuse-es] Registro del cortafuegos (paquetes entre redes no conectadas)
Camaleón wrote:
El 2009-04-30 a las 17:53 +0200, carlopmart escribió:
Camaleón wrote:
- Los switches de ambas redes no están conectados / comunicados de ninguna forma. Son redes independientes. Nota: si desactivo el segundo adaptador del windows (eth1 / 172.16.0.30) dejo de recibir esos mesajes en el firewall de suse. No entiendo cómo el tráfico de esta tarjeta (eth1) pasa al otro adaptador (eth0) si no tengo configurado ningún puente entre ambas. Saludos, Entonces es el propio Windows el que está enrutando y provocandote ese tráfico. En el registro del XP hay un parámetro "IPEnableRouter", tiene que estar a 0.
Sí, está a cero :-?
*** HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ IPEnableRouter REG_DWORD 0x00000000 (0) ***
Saludos,
Pues el tema está entre el windows y al switch que conecta, no puede ser nada más. ¿Tienes otro linux en la red 192.x.x.x? ¿Puedes sniffar a ver si ve ese tráfico? -- 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-04-30 a las 18:36 +0200, carlopmart escribió:
Camaleón wrote:
Sí, está a cero :-? *** HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ IPEnableRouter REG_DWORD 0x00000000 (0) ***
Pues el tema está entre el windows y al switch que conecta, no puede ser nada más. ¿Tienes otro linux en la red 192.x.x.x? ¿Puedes sniffar a ver si ve ese tráfico?
Sólo capturo datos desde la suse que registra esos eventos. Bueno, la película es como sigue. Una consola la dejo con: *** linux:/etc/samba # tail -f /var/log/firewall *** Y otra con: *** linux:~ # tcpdump src 10.5.110.1 or dst 172.16.0.30 or dst 192.168.0.13 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes *** Cuando el cortafuegos registra el evento: *** May 1 12:54:12 linux kernel: SFW2-INext-DROP-DEFLT IN=eth0 OUT= MAC=xx SRC=10.5.110.1 DST=192.168.0.5 LEN=56 TOS=0x00 PREC=0x00 TTL=254 ID=0 PROTO=ICMP TYPE=3 CODE=13 [SRC=192.168.0.5 DST=172.16.0.30 LEN=221 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP SPT=137 DPT=137 LEN=201 ] May 1 12:54:43 linux syslog-ng[2288]: last message repeated 2 times *** El tcpdump captura esto otro: *** 12:54:12.330348 IP linux.site.netbios-ns > 192.168.0.13.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST 12:54:12.330445 IP linux.site.netbios-ns > 172.16.0.30.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST 12:54:12.375157 IP 10.5.110.1 > linux.site: ICMP host 172.16.0.30 unreachable - admin prohibited filter, length 36 12:54:13.819434 IP linux.site.netbios-ns > 172.16.0.30.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST 12:54:13.863304 IP 10.5.110.1 > linux.site: ICMP host 172.16.0.30 unreachable - admin prohibited filter, length 36 12:54:15.319569 IP linux.site.netbios-ns > 172.16.0.30.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST 12:54:15.364446 IP 10.5.110.1 > linux.site: ICMP host 172.16.0.30 unreachable - admin prohibited filter, length 36 *** ----- Notas ----- - 192.168.0.5 es la eth0 de suse - 192.168.0.13 es la eth0 del windows xp64 - 172.16.0.30 es la eth1 del windows xp64 - El samba en suse lo tengo para que los clientes puedan usar la impresora de faxes a través de CUPS. ------- Pruebas ------- - He probado a definir la misma métrica para ambos adaptadores en el xp (métrica de 10). Los adaptadores con la misma métrica basan su prioridad en el orden de las interfaces. La primera es eth0 y la segunda es eth1. Haciendo esto y reiniciando el windows seguía registrando estos mensajes en el cortafuegos. - He probado a detener el servicio nmb (rcnmb stop) y también dejó de registrar estos eventos en el cortafuegos. Es decir, el mismo efecto que desactivando la interfaz desde windows. - También he probado a definir los siguientes valores en el archivo de configuración de samba (/etc/samba/smb.conf): bind interfaces only = yes interfaces = 192.168.0.5 Y reiniciar ambos servicios (nmb y smb) pero sigue registrando los eventos - Otra cosa que también he probado es a añadir en el cortafuegos la siguiente entrada: FW_SERVICES_DROP_INT="0/0,udp,137" Y por si estuviera tomando la interfaz como ext (creo que lo hace así porque no lo he definido expresamente), también probé: FW_SERVICES_DROP_EXT="0/0,udp,137" Y reiniciando el cortafuegos, pero seguía registrando los eventos. --------- Hipótesis --------- - El tcpdump parece indicar que no es el windows quien intenta comunicar con la suse, sino al revés. SuSE manda un paquete tanto a 192.168.0.13 como al otro adaptador 172.16.0.30: *** 12:54:12.330348 IP linux.site.netbios-ns > 192.168.0.13.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST 12:54:12.330445 IP linux.site.netbios-ns > 172.16.0.30.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST *** Y al hacerlo le viene la respuesta lógica de que "no llega": *** 12:54:12.375157 IP 10.5.110.1 > linux.site: ICMP host 172.16.0.30 unreachable - admin prohibited filter, length 36 *** - Hay otros equipos en la red que tienen dos adaptadores de red pero curiosamente este comportamiento sólo se da con uno en concreto (windows xp64). Lo cual me hace pensar que podría ser alguna característica nueva que se ha incorporado en el xp64 (que comparte algunas de las opciones del w2003). Tendré que revisarlo. - Voy a seguir buscando información para intentar al menos evitar que se llene el registro del cortafuegos con esos datos. Si se os ocurre alguna otra cosa para probar, pues se agradece :-) 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
On Friday 01 May 2009 13:52:00 Camaleón wrote:
El tcpdump captura esto otro:
*** 12:54:12.330348 IP linux.site.netbios-ns > 192.168.0.13.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST
12:54:12.330445 IP linux.site.netbios-ns > 172.16.0.30.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST
12:54:12.375157 IP 10.5.110.1 > linux.site: ICMP host 172.16.0.30 unreachable - admin prohibited filter, length 36
12:54:13.819434 IP linux.site.netbios-ns > 172.16.0.30.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST
12:54:13.863304 IP 10.5.110.1 > linux.site: ICMP host 172.16.0.30 unreachable - admin prohibited filter, length 36
12:54:15.319569 IP linux.site.netbios-ns > 172.16.0.30.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST
12:54:15.364446 IP 10.5.110.1 > linux.site: ICMP host 172.16.0.30 unreachable - admin prohibited filter, length 36 ***
----- Notas -----
- 192.168.0.5 es la eth0 de suse - 192.168.0.13 es la eth0 del windows xp64 - 172.16.0.30 es la eth1 del windows xp64
- El samba en suse lo tengo para que los clientes puedan usar la impresora de faxes a través de CUPS.
Me parece que la causa fundamental es anterior a lo que has capturado. ¿Como sabe tu maquina suse de la existencia de 172.16.0.30?? Si puedes, yo haria la siguiente prueba : 1/Desconectar fisicamente la maquina suse de la red 2/Reiniciar la maquina suse 3/arrancar en suse wireshark 4/poner de filtro en wireshark ip.add == 172.16.0.30 5/arrancar la captura de wireshark 6/Conectar la maquina suse a la red Ahi deberian aparecer los mensajes que tienen relacion con 172.16.0.30 Podria ser hasta un arp gratuito.( un arp pidiendo la direccion mac de uno mismo, entre otras cosas se usa para detectar ip duplicada). -- Saludos Lluis
El 2009-05-01 a las 20:04 +0200, Lluis Martínez escribió:
On Friday 01 May 2009 13:52:00 Camaleón wrote:
El tcpdump captura esto otro:
*** 12:54:12.330348 IP linux.site.netbios-ns > 192.168.0.13.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST
12:54:12.330445 IP linux.site.netbios-ns > 172.16.0.30.netbios-ns: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONSE; UNICAST
Me parece que la causa fundamental es anterior a lo que has capturado.
No hay más tráfico :-?
¿Como sabe tu maquina suse de la existencia de 172.16.0.30??
Eso es lo que yo me pregunto. Al ejecutar el tcpdump veo que la suse pregunta a todos los equipos de la red 192.168.0.x. A todos sin excepción. Pero sólo con este equipo pregunta también a la segunda tarjeta que monta la estación cliente. ¿Cómo es posible? Pues no tengo la menor idea.
Si puedes, yo haria la siguiente prueba : 1/Desconectar fisicamente la maquina suse de la red 2/Reiniciar la maquina suse 3/arrancar en suse wireshark 4/poner de filtro en wireshark ip.add == 172.16.0.30 5/arrancar la captura de wireshark 6/Conectar la maquina suse a la red
Ahi deberian aparecer los mensajes que tienen relacion con 172.16.0.30
Podria ser hasta un arp gratuito.( un arp pidiendo la direccion mac de uno mismo, entre otras cosas se usa para detectar ip duplicada).
¿No sirve el tcpdump? No me gustaría instalar nada en esa suse. ¿Puedo usar la máquina virtual para capturar algo desde ahí con el wireshark? 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
On Friday 01 May 2009 21:27:34 Camaleón wrote:
Me parece que la causa fundamental es anterior a lo que has capturado.
No hay más tráfico :-?
Tiene que haberlo, sino de donde saldria el numerito 172.16.0.30
¿Como sabe tu maquina suse de la existencia de 172.16.0.30??
Eso es lo que yo me pregunto.
¿No sirve el tcpdump? No me gustaría instalar nada en esa suse.
Sirve pero puedes tener demasiados datos para ver claro.
¿Puedo usar la máquina virtual para capturar algo desde ahí con el wireshark? O:-)
No lo se. Lo que si puedes es instalar el wireshark en otra maquina, p.e. un portatil, y conectar un HUB o un switch con SPAN entre la suse y la red, ahi conectas tambien la maquina con el wireshark El wireshark lo tienes para linux y para el innombrable. -- Saludos Lluis
El 2009-05-01 a las 21:38 +0200, Lluis Martínez escribió:
On Friday 01 May 2009 21:27:34 Camaleón wrote:
Me parece que la causa fundamental es anterior a lo que has capturado.
No hay más tráfico :-?
Tiene que haberlo, sino de donde saldria el numerito 172.16.0.30
Pues... la hipótesis más lógica es que al preguntar al equipo en cuestión (192.168.0.13) el windows le comunique la existencia del segundo adaptador (172.16.0.30). No lo sé, es algo que se me escapa.
¿No sirve el tcpdump? No me gustaría instalar nada en esa suse.
Sirve pero puedes tener demasiados datos para ver claro.
Pasando el filtro adecuado se elimina mucha morralla. En los datos que envié antes creo que filtraba todo el tráfico (no sólo udp) y las direcciones ip de origen y/o destino.
¿Puedo usar la máquina virtual para capturar algo desde ahí con el wireshark? O:-)
No lo se.
Lo que si puedes es instalar el wireshark en otra maquina, p.e. un portatil, y conectar un HUB o un switch con SPAN entre la suse y la red, ahi conectas tambien la maquina con el wireshark
El wireshark lo tienes para linux y para el innombrable.
En el portátil tengo la suse virtualizada, por eso lo decía :-) Eso del span no lo pillo. ¿Cómo tendría que conectar el portátil, a qué redes? ¿A ambas (192.168.0.x y 172.16.0.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
On Friday 01 May 2009 22:14:35 Camaleón wrote:
El 2009-05-01 a las 21:38 +0200, Lluis Martínez escribió:
Lo que si puedes es instalar el wireshark en otra maquina, p.e. un portatil, y conectar un HUB o un switch con SPAN entre la suse y la red, ahi conectas tambien la maquina con el wireshark
El wireshark lo tienes para linux y para el innombrable.
En el portátil tengo la suse virtualizada, por eso lo decía :-)
Eso del span no lo pillo. ¿Cómo tendría que conectar el portátil, a qué redes? ¿A ambas (192.168.0.x y 172.16.0.x)?
Lo del SPAN tambien se llama port remoting o bocas de auditoria. Lo tienen algunos switch proesionales para que puedas ver el trafico en la red. Deberias conectar a la 192.168.0.x pero mejor si es algo parecido a esto : Maquina Suse -----------------------------HUB-------Conexion actual | | Maquina con wireshark -- Saludos Lluis
On Friday 01 May 2009 22:22:17 lluis wrote:
Maquina Suse -----------------------------HUB-------Conexion actual
Maquina con wireshark
Con el lio de los espacios el dibujo a mi me aparece mal. La maquina con wireshark se conecta al HUB -- Saludos Lluis
El 2009-05-01 a las 22:26 +0200, Lluis Martínez escribió:
On Friday 01 May 2009 22:22:17 lluis wrote:
Maquina Suse -----------------------------HUB-------Conexion actual
Maquina con wireshark
Con el lio de los espacios el dibujo a mi me aparece mal. La maquina con wireshark se conecta al HUB
Ah, vale... pues a ver si mañana lo puedo probar y ya cuento algo. Es que es un poco incordiante tener al cortafuegos registrando ese tráfico cada 5 minutos :-/. Ahora que lo tenía controlado, se me desboca otra vez, dita sea... ¿Por qué lo llaman "cortafuegos" cuando quieren decir "toca-narices"? :-P 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 2009-05-01 a las 23:21 +0200, Camaleón escribió:
El 2009-05-01 a las 22:26 +0200, Lluis Martínez escribió:
On Friday 01 May 2009 22:22:17 lluis wrote:
Maquina Suse -----------------------------HUB-------Conexion actual
Maquina con wireshark
Con el lio de los espacios el dibujo a mi me aparece mal. La maquina con wireshark se conecta al HUB
Ah, vale... pues a ver si mañana lo puedo probar y ya cuento algo.
Como "mañana es hoy", cuento ya sin dilación :-) Como soy muy brutica, pues he bajado una LiveCD de esas de seguridad (NST, Network Security Toolkit): http://networksecuritytoolkit.org/nst/index.html Bueno, he hecho dos pruebas. a) Conectar el equipo con la Live a la red de suse (192.168.0.x) y capturar todo lo que pase con el wireshark. No se ve ni coscorro :-( Hay todo tipo de tráfico (de los routers, de las impresoras -estas hablan como unas cosacas- de los equipos con windows...) pero no hay ni rastro de tráfico cruzado, es decir, ni con origen ni con destino a la red 172.16.0.x. b) Por si cazaba algo, he hecho los mismo pero conectando el equipo con la LiveCD a la red 172.16.0.x. Sigue sin verse ni coscorro >:-( Veo tráfico (esta red es menos parlanchina porque la mayoría de equipos están ahora apagados) pero bueno, veo las impresoras que envían paquetes, hacen preguntas y demás. Pero sigo sin capturar tráfico cruzado, es decir, que no hay paquetes con origen ni destino a la otra red (192.168.0.x). Estoy mosca. 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
On Saturday 02 May 2009 19:44:56 Camaleón wrote:
El 2009-05-01 a las 23:21 +0200, Camaleón escribió:
El 2009-05-01 a las 22:26 +0200, Lluis Martínez escribió:
On Friday 01 May 2009 22:22:17 lluis wrote:
Maquina Suse -----------------------------HUB-------Conexion actual
Maquina con wireshark
Con el lio de los espacios el dibujo a mi me aparece mal. La maquina con wireshark se conecta al HUB
Ah, vale... pues a ver si mañana lo puedo probar y ya cuento algo.
Como "mañana es hoy", cuento ya sin dilación :-)
Como soy muy brutica, pues he bajado una LiveCD de esas de seguridad (NST, Network Security Toolkit):
http://networksecuritytoolkit.org/nst/index.html
Bueno, he hecho dos pruebas.
a) Conectar el equipo con la Live a la red de suse (192.168.0.x) y capturar todo lo que pase con el wireshark.
No se ve ni coscorro :-(
Hay todo tipo de tráfico (de los routers, de las impresoras -estas hablan como unas cosacas- de los equipos con windows...) pero no hay ni rastro de tráfico cruzado, es decir, ni con origen ni con destino a la red 172.16.0.x.
b) Por si cazaba algo, he hecho los mismo pero conectando el equipo con la LiveCD a la red 172.16.0.x.
Sigue sin verse ni coscorro >:-(
Veo tráfico (esta red es menos parlanchina porque la mayoría de equipos están ahora apagados) pero bueno, veo las impresoras que envían paquetes, hacen preguntas y demás. Pero sigo sin capturar tráfico cruzado, es decir, que no hay paquetes con origen ni destino a la otra red (192.168.0.x).
Seguro que estas conectando en un hub o en una boca de mantenimiento? En caso contrario solo veras el broadcast -- Saludos Lluis
El 2009-05-02 a las 20:50 +0200, Lluis Martínez escribió:
On Saturday 02 May 2009 19:44:56 Camaleón wrote:
Bueno, he hecho dos pruebas.
a) Conectar el equipo con la Live a la red de suse (192.168.0.x) y capturar todo lo que pase con el wireshark.
No se ve ni coscorro :-(
Seguro que estas conectando en un hub o en una boca de mantenimiento? En caso contrario solo veras el broadcast
Si te refieres a un concentrador puro, no, estos son conmutadores, poco inteligentes pero conmutadores al fin y al cabo. ¿Pero el wireshark no captura todo el tráfico? Pues vaya }:-) Ah, ellos mismos ponen varios ejemplos: http://wiki.wireshark.org/CaptureSetup/Ethernet http://www.wireshark.org/faq.html#q7.1 Venga, probaré el lunes conectando a la suse y al equipo con wireshark a un concentrador (a ver si encuentro alguno) y el concentrador a uno de los switches. Ya contaré... 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:
Si te refieres a un concentrador puro, no, estos son conmutadores, poco inteligentes pero conmutadores al fin y al cabo.
Algunos conmutadores tienen una boca especial que puede recibir copia del tráfico de todas las bocas; debes conectar ahí para poder ver esos paquetes que buscas. Es como poner el switch en modo promiscuo. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkn80kcACgkQtTMYHG2NR9XsiACcDNQ/GPJdjV5tS8vb7oNhdOM3 lq4An3WWT+Kdi7NDJQ+gJTcdb86jZagP =8WEK -----END PGP SIGNATURE-----
On Sunday 03 May 2009 00:46:51 Camaleón wrote:
Seguro que estas conectando en un hub o en una boca de mantenimiento? En caso contrario solo veras el broadcast
Si te refieres a un concentrador puro, no, estos son conmutadores, poco inteligentes pero conmutadores al fin y al cabo.
¿Pero el wireshark no captura todo el tráfico? Pues vaya }:-)
No puede capturarlo, por que fisicamente no esta en tu cable. El switch redirige y aisla, -- Saludos Lluis
El 2009-05-03 a las 09:59 +0200, Lluis Martínez escribió:
On Sunday 03 May 2009 00:46:51 Camaleón wrote:
Seguro que estas conectando en un hub o en una boca de mantenimiento? En caso contrario solo veras el broadcast
Si te refieres a un concentrador puro, no, estos son conmutadores, poco inteligentes pero conmutadores al fin y al cabo.
¿Pero el wireshark no captura todo el tráfico? Pues vaya }:-)
No puede capturarlo, por que fisicamente no esta en tu cable. El switch redirige y aisla,
Traigo nuevas, que no buenas :-P Al final he podido hacerme con un "hub-hub" (un concentrador real) mini que me dieron con el router adsl allá por el año de la parrala, y lo he podido capturar. Como esto ya es un poco OT, pongo en este correo sólo las cabeceras del resultado del wireshark y enlazo al log completo que he puesto en pastebin: *** No. Time Source Destination Protocol Info 60 2009-05-03 12:48:24.298838 192.168.0.13 Broadcast ARP Who has 192.168.0.5? Tell 192.168.0.13 No. Time Source Destination Protocol Info 61 2009-05-03 12:48:24.298855 Supermic_86:e8:c3 192.168.0.13 ARP 192.168.0.5 is at 00:30:48:86:e8:c3 No. Time Source Destination Protocol Info 62 2009-05-03 12:48:24.299835 172.16.0.30 192.168.0.5 TCP clp > netbios-ssn [SYN] Seq=0 Win=65535 Len=0 MSS=1460 No. Time Source Destination Protocol Info 63 2009-05-03 12:48:24.299841 192.168.0.5 172.16.0.30 TCP netbios-ssn > clp [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 No. Time Source Destination Protocol Info 64 2009-05-03 12:48:24.340809 10.5.110.1 192.168.0.5 ICMP Destination unreachable (Communication administratively filtered) *** Y el registro completo, sin censura O:-), del diálogo que mantuvieron los acusados, el día D en la hora H. http://pastebin.com/m40172807 He resaltado las líneas de cabecera y las que me parecen interesantes, que es donde se produce el cambio de IP entre adaptadores, y otra, donde aparece en escena un nuevo personaje, que es CLP (Cisco Line Protocol) que no sé qué pinta aquí (todos los adaptadores de red que entran en juego son Intel gigabit -integrado en la placa- y Realtek gigabit -en slot pci-) :-? *** Reconstrucción hipotética de los hechos: El windows (192.168.0.13) eth0 pregunta por el equipo linux (192.168.0.5). El linux (192.168.0.13) le responde (192.168.0.13) El windows (¡¡¡pasa de 192.168.0.13 a 172.16.0.30!!!) le envía un "clp
netbios-ssn" vía TCP con puerto de origen "2567" al linux (192.168.0.5)
--> Cómo y porqué salta "de una interfaz a otra", es un misterio. --> Por qué usa ese protocolo de Cisco y envía un paquete netbios al linux es otro misterio. El linux (192.168.0.5) intenta responder al windows (172.16.0.30) por el mismo medio y al mismo lugar pero no llega y manda el paquete "por donde buenamente puede" (la puerta de enlace que es el router adsl con IP 192.168.0.59). Efectivamente, en el router también veo registrado ese evento. *** Si alguien tiene alguna hipótesis sobre el suceso acontencido, pues me puede enviar un correo en privado para no molestar más o bueno, ponerlo en la lista. Y si alguien sabe cómo podría eliminar ese registro del cortafuegos de suse que aparece cada 5 minutos, pues se agradece de veras. P.S. Gracias a Lluis por insistir con el wireshark (el-que-ve-lo-que-otros-no-ven) y el uso del hub-hub 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
On Tuesday 05 May 2009 23:13:35 Camaleón wrote:
P.S. Gracias a Lluis por insistir con el wireshark (el-que-ve-lo-que-otros-no-ven) y el uso del hub-hub O:-)
De gracias, nada.. yo te debo muy buenas ideas.Para eso estamos aquí. Solo me debes dos cervezas. Mañana, hoy es muy tarde ya, me miro con calma tu registro. -- Saludos Lluis
El 2009-05-05 a las 23:23 +0200, Lluis Martínez escribió:
On Tuesday 05 May 2009 23:13:35 Camaleón wrote:
P.S. Gracias a Lluis por insistir con el wireshark (el-que-ve-lo-que-otros-no-ven) y el uso del hub-hub O:-)
De gracias, nada.. yo te debo muy buenas ideas.Para eso estamos aquí. Solo me debes dos cervezas.
¡Ouch! :-)
Mañana, hoy es muy tarde ya, me miro con calma tu registro.
Me he pasado casi media tarde analizando este tema, buscando información, haciendo pruebas, aplicando distintas configuraciones en el cliente, activando los regsitros de su cortafuegos... y al final he podido descubrir el origen del zancocho. Ni samba, ni suse ni windows ni netbios ni equipos parlanchines ni gaitas. Una aplicación que está activada en el cliente (un verificador de cuentas pop) y que, visto lo visto, me parece que debe tener un fallo de programación, es la culpable de ese envío de tráfico cruzado que se producía en un equipo en concreto y que registraba el cortafuegos de suse. La pista me la ha dado el intervalo de tiempo en el que quedaba registrado el evento en el cortafuegos y el intervalo en el que se comprueba una cuenta de correo. Era el mismo: 5 minutos. Demasiada coincidencia para que no tuviera ninguna relación :-/ Nada más cerrar "esa" aplicación en el cliente, el cortafuegos ha dejado de registrar el evento de tráfico cruzado entre los adaptadores de red. Bingo. Pero ese programa también está instalado y ejecutándose en otros equipos de la red así que... ¿qué es lo que marca la diferencia entre el equipo que cruza el tráfico y el resto de equipos si todos tienen dos adaptadores de red conectados a dos redes distintas? Pues sólo podían ser dos cosas: 1. Que el sistema oeprativo es de 64 bits y la aplicación es de 32 bits (no hay versión nativa de 64 y por tanto se ejecuta en modo de compatibilidad). 2. Que hace unos días instalé y habilité un plugin para proporcionar acceso a cuentas imap Para descartar el punto 1 (que el programa completo tuviera alguna incompatibilidad con un sistema de 64 bits), he probado a desactivar sólo la cuenta que verificaba el correo en suse de manera local. Bingo 2. Desactivando sólo esa cuenta, seguía sin registrar ese mensaje en el cortafuegos, así que, el único culpable que quedaba era el plugin que había habilitado hace unos días para verificar la cuenta vía imap en lugar de pop. Configurando la cuenta para usar pop, me he librado del mensaje :-) Conclusión: pues obviamente que el plugin debe de tener algún error, quizá no funcione en sistemas de 64 bits o no lo haga correctamente y cruce el tráfico cuando éste es local y encuentra dos adaptadores. No lo sé, pero tiene pinta de bug... pero este bug es de "otros" :-P Perdón por el tostón, pero me he quitado un peso de encima al saber el motivo de ese cruce de tráfico O:-) Gracias a todos por las sugerencias. Este es el típico problema que sólo se saca si conoces de primera mano la red y los equipos que entran en juego, los programas que se han instalado recientemente y la configuración de los equipos. Y SuSE fue la que me puso en sobre aviso, así que en cierto modo, creo que también debo darle las gracias :-) 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 Martes, 8 de Mayo de 2009, Camaleón escribió:
* Ese trafico no debe provocarlo la aplicacion si no windows, a menos que la aplicacion genere llamadas a UDP 137 por que sea algo extraño un "wincorreo" que se anucie bajo soporte netbios, lo cual es absurdo para una aplicacion de correo , ya que smtp, imap, pop son protocolo de conexion y esa llamada no anuncia/recibe un servicio de correo si no de red, otra cosa es que windows la genere segun su leal saber y entender "por que hay algo que esta usando la red".
El 2009-05-08 a las 13:26 +0200, jose maria escribió:
El Martes, 8 de Mayo de 2009, Camaleón escribió:
* Ese trafico no debe provocarlo la aplicacion si no windows, a menos que la aplicacion genere llamadas a UDP 137 por que sea algo extraño un "wincorreo" que se anucie bajo soporte netbios, lo cual es absurdo para una aplicacion de correo , ya que smtp, imap, pop son protocolo de conexion y esa llamada no anuncia/recibe un servicio de correo si no de red, otra cosa es que windows la genere segun su leal saber y entender "por que hay algo que esta usando la red".
Lo único que sé es que al activar el "plugin" para habilitar la comprobación de las cuentas vía imap, se genera ese tráfico por parte del windows. No sucede cuando se utiliza pop3. ¿Cuál puede ser el "trigger" en concreto? Ni idea, no lo he depurado. Sé qué es lo que genera ese tráfico pero no el motivo. El programa (que es GPL) está escrito en Delphi. El plugin está escrito en C++. Si alguien tiene interés en el código de ambos, puedo poner el enlace. 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
participants (6)
-
Camaleón -
carlopmart -
Carlos E. R. -
jose maria -
lluis -
Lluis