sábado, 18 de febrero de 2012

Puertos abiertos en el router: mala idea.

[Introducción chorra]
Juer, vaya día. Estoy tan tranquilo hoy haciendo unas pruebicas con sockets TCP en mi red local, trabajando con el wireshark capturando los paquetes resultantes para ver si, haciendo un par de putadas a una conexión TCP, puedo llegar a romper algo. Nada, intentando explotar una idea que tuve hace dos días y viendo si dá para un post o no. Hasta aquí todo normal.

Resulta que en una de estas he encendido el Transmission ( http://www.transmissionbt.com ), para el que no lo sepa es un cliente de BitTorrent. Si no sabes que es BitTorrent dale aquí aqui . Para la gente con poca memória: P2P. Intercambio de ficheros. ¿Te suena ya?

Bien. Voy a Edit>Preferences>Network>Test Port. "Port closed". Genial. Tendré que crear una regla en el router.

Voy a la configuración del router, veo que ya hay una regla creada para exactamente esto, pero en una IP que no es la mia (es la de otro ordenador de casa, que ahora mismo está apagado). Pos fale. No problemo. Le digo que todo lo que venga por el puerto 61415 me lo mande a mi IP local: 192.168.1.35. Pongo una regla en la configuración del cortafuegos de mi portátil para que accepte conexiones entantes por el puerto 61415. La regla es así:

iptables -A INPUT -p TCP -m state --state NEW --dport 61415 -j ACCEPT


Nótese que el puerto por "defecto" es el 51413, pero como ya está configurado para que lo use otra máquina en mi red, yo estoy usando el 61415 (puerto que he elegido al tuntún). Pruebo otra vez: Edit>Preferences>Network. Cambio el puerto del 51413 al 61415. Le doy a Test Port: "Port open". Genial, ahora esto irá chuscado. Voy a por algo para picar (esto de abrir puertos hace que a uno le entre hambre). Cuando vuelvo la descarga ya está completada. Genial. Apago el Transmission, me pongo algo de música, pongo enmarcha el Wireshark para seguir haciendo pruebas y.... WTF!!!

[Paquetes, Paquetes Everywhere]
Joder, macho. Aún habiendo cerrado el Transmission hay muchísimo tráfico que viene de Internet hacia mi máquina. Pero a saco. Unos 3-4 requests por segundo.

Todas las peticiones son paquetes TCP tipo SYN. O sea, que des de Internet quieren establecer una conexión con mi máquina. Miro el puerto de destino de estas conexiones y es el 61415. Mi ordenador responde a cada una de ellas con un paquete TCP tipo RST, que les dice "ummm.... pos va a ser que no", ya que no tengo ningún servicio escuchando en este puerto.

Vale, tate. Esto es lógico. Hace un momento, cuando tenía el Transmission encendido la gente se conectaba a mi máquina para pillar archivos. He cerrado la aplicación de Transmission, pero esto es algo que la gente de Internet no sabe, por lo que intentan conectarse igualmente a mi PC para pillar ficheros (por esto mandan un TCP-SYN). Mi portátil como no tiene ningún programa escuchando en el 61414, contesta las peticiones con un TCP-RST diciendo... lo siento, no hay nada a lo que te puedas conectar (de esto se encarga el kernel). O sea, esto es normal, y no hay nada malo en que intenten conectarse a mi máquina sin conseguirlo. Esto te puede llegar a quitar bastante ancho de banda, pero bueno, supongo después de un rato el número de requests va disminuyendo hasta que finalmente pare.

Claro, yo quiero seguir haciendo pruebas con el wireshark, pero con tanto "ruido" no hay quién trabaje. Total, que me voy al router y borro la regla de redirección de puerto 61415 hacia mi máquina. A ver si ahora puedo trabajar tranquilo.

Recordemos que ya tenía otra regla en el router. La regla dice que redirija todo el tráfico al puerto 51413 a la IP 192.168.1.33 (otro host de mi red, ahora mismo apagado). No la he modificado porque quiero que la 192.168.1.33 siga pudiendo usar el Transmission sin cambiar la configuración.

[ARP-FLOOD]
Pongo enmarcha el wireshark otra vez. Fuck. Ahora hay alguien que me está inundando la puta red de paquetes ARP. Que majos todos.



Veamos, el router (192.168.1.1) pregunta quién tiene la IP 192.168.1.33, mediante paquetes ARP lanzados casi cada segundo. Pues vaya: NADIE TIENE ESA IP; es un host en mi red que ahora mismo está apagado, normal que nadie conteste. Pero ¿por qué el router intenta descubrir quién es 192.168.1.33? Quiero decir.. esta máquina ha estado parada durante días. ¿Qué tráfico tiene que ir a una máquina apagada hace días? ¿Quién quiere ponerse en contacto con una máquia apagada? WTF!

Pues alguien que esté usando BitTorrent y quiera un fichero que cree que yo tengo. Parece que algún hijo de delfín daltónico y chimpanzé fitofílico ha decidido hacer conexiones contra mi IP pública, al puerto 51413. Pero, ¿Por quéeee y para qué? Vale que este sea el puerto por defecto de Transmission, pero yo hoy no lo he usado para nada. Yo siempre he estado usando el 61415. ¿Con que derecho intenta acceder al puerto 51413? o sea.... ¿qué espera encontrar? Esto parece una mala implementación de un cliente de BitTorrent, o alguna comprovación que harán algunos servidores de torrents para comprobar si, además del puerto 61415, también tenemos abierto el 51413, digo yo. No lo sé, pero la verdad que no me mola mucho el tema.

Lo que está pasando, es que como tengo una regla en el router que dice "redirígeme todo el tráfico que venga al puerto 51413 a la IP 192.168.1.33", el router la palica siempre. Si o si. Y claro, para poder mandarle tráfico entrante al host 192.168.1.33 necesita saber primero quién es éste host (obtener la dirección MAC, para los menos entendidos en tema de ARP). Y es por esto que está mandando paquetes ARP a SACO en toda mi red. De echo, manda un paquete ARP por cada petición que le llega al puerto 51413. Una de las características de ARP es que son paquetes que se mandan a broadcast. O sea que lo reciben TODOS los hosts de mi red. Fuck. Obviamente como ninguno de ellos es 192.168.1.33, todo el mundo descarta el paquete y andando. Pero bueno, es un desperdicio de ancho de banda y no me mola el rollo.


[Cómo ver el tráfico que recibiría 192.168.1.33 en caso de estar encendido]
Pues como me da pereza infinita ir a encender el host 192.168.1.33, poner el wireshark y demás, vamos a ver el tráfico que recibiría este host ahora mismo des de mi portatil:

$ sudo ifconfig eth0:2 192.168.1.33

Ala. Hecho. Ahora mi portátil tiene la IP 192.168.1.35 y la 192.168.1.33 en una subinterfície (conocíais lo de las subinterfícies, verdad? ;) ). Mi host se indentifica como 192.168.1.33 y responde las peticiones ARP. Miro el wireshark y ala! Estamos como al principio: Hosts de Internet intentan establecer una conexión con mi equipo, y mi equipo contestando que "no, no tengo ningún servicio escuchando en el puerto donde me estás haciendo la petición. RST! RST! RST!".



[¿Cómo solucionar el problema?]
Bueno, no parece muy difícil llegar a la conclusión de que los puertos, si están cerrados, mejor. En caso de usar protocolos P2P, en necesario abrir los puertos para que el tema vaya flúido. Yo a partir de ahora voy a abrir/cerrar los puertos de mi router cada vez que me quiera descargar algo. No me mola que si a alguien le apetece enviarme un paquete al puerto por defecto de BitTorrent, esto se traduzca en chorrocientos paquetes ARP en mi red. Vale, tampoco hacen daño, pero no los quiero ahí.

[Notas finales]
En este post tampoco cuento nada extraño ni sofisticado. Todo funciona como es debido, y si se piensa bien, no hay problema de que las cosas funcionen así. Aún así para mi ha supuesto la primera prueba que tengo que respalde la afirmación que todo el mundo hace diciendo: "los puertos del router mejor cerrados!". Y tienen razón. Ahora veo que me estoy provocando ARP-Flooding en mi propia red, en el caso de que el host de destino esté apagado. O que en caso de que esté encendido, que el host tenga que responder a peticiones ( ni que sea para decir RST ) que provinenen de Internet. Mucho mejor que se encargue de hacer todo esto el router, y deje mis hosts de la LAN en paz.

También he vuelto a ver claro esto de que Internet es la selva, y que muchas veces el router nos hace de separación entre nuestra tranquila/estable/fiable red local, y la locura de Internet.

Un saludo, Jan.

No hay comentarios:

Publicar un comentario