Thepiratebay.se, bloqueo y técnicas para evadirlo

Creo que casi todos conocemos ya que un juez ha ordenado bloquear el acceso a The piratebay desde España. Esta orden afecta a los proveedores de servicio españoles que suelen cumplirlo mediante:

  • Las resoluciones DNS
  • Inspección de paquetes

(El que no usen un filtro contra la IP es porque esa IP puede estar asignada para más de un sitio web y estos no deberían “pagar” por el hecho denunciado si no son los responsables)

Si se aplica el bloqueo en el DNS, con indicarle a nuestros sistemas que usen otros que no se hayan visto afectados por la orden sobra para que podamos seguir accediendo a dicho sitio. Por ejemplo, podemos usar openDNS o los de Google (8.8.8.8).

Si se realiza inspección de paquetes, con conectarnos mediante HTTPS sobra para acceder al sitio. En la inspección de paquetes lo que se busca es información relevante para realizar la tarea encomendada (normalmente, se busca en el nivel de aplicación). Para este caso, lo normal es que se busque la cabecera host del protocolo HTTP ya que se encarga de identificar el sitio al que nos queremos conectar. Si usamos HTTPS esta información va cifrada y “no la encontrará el analizador”.

Si se usaran combinadas las 2 técnicas, tendríamos que combinar las 2 “soluciones”. No es necesario ni VPNs ni TOR como se menciona en este artículo sobre cómo saltarse el bloqueo, aunque, evidentemente, son buenas opciones que, además, nos dan otras ventajas añadidas a simplemente conectarnos a ThepirateBay.se

¡Espero que os sea útil!

PD: No soy usuario de este sitio, pero he probado desde mi PC, con Vodafone como ISP, y  funciona perfectamente  la conexión con HTTPS y no con HTTP.

PD2: Conseguir el efecto que pretende la orden del juez es muy complicado tal y como funciona y se organiza Internet

 

 


Reutilización del mismo puerto en el lado del cliente

La entrada anterior está escrita desde el punto de vista de los servidores, aunque en el lado del cliente, también podemos reutilizar puertos. ¿Cómo? Pues añadiendo, antes de la función connect de, por ejemplo, este código de cliente, las siguientes órdenes:

sock.setsockopt(socket.SOL_SOCKET, SO_REUSEPORT, 1)
sock.bind((“0.0.0.0”,3000))

la primera orden es la misma que hemos comentado ya y es la que nos activa el flag que permite reutilizar el puerto; la segunda es necesaria para “forzar” el puerto y que no sea uno aleatorio. Si lanzamos 2 conexiones, nos queda:

Screenshot from 2015-03-23 10:59:20

¡Espero que os sea útil!


Reutilización de puertos en GNU/Linux

Para todos los sistemas operativos, una conexión (comunicación) entre dos equipos está definida por cualquier combinación de la tupla formada por la dirección IP origen y destino, el puerto de origen y destino y el protocolo de transporte (TCP o UDP).  Así, en cualquier nodo de nuestra red, podremos utilizar la función bind para “anclar” nuestro servidor a cualquier puerto libre. Si el puerto ya está en uso, y si nuestro nodo dispone de más de una dirección IP, podremos unir nuestro proceso utilizando otra IP que no tenga “ocupado” el puerto que nos interesa. Si el puerto y la dirección están en uso, siempre podremos usar el otro protocolo de transporte, suponiendo, nuevamente, que esté libre (y nos interese, claro).

En definitiva, esta tupla (recordemos: ip origen, puerto origen, ip destino, puerto destino, protocolo de transporte) le permiten al sistema operativo identificar unívocamente, el proceso que debe encargarse de los datos de aplicación.

Así que, ¿a qué viene el título de la entrada? ¿Qué es reutilizar puertos?

Pues para responder, debemos ver las opciones SO_REUSEADDR y, sobre todo, SO_REUSEPORT cuyo comportamiento es distinto en función del sistema operativo donde las utilicemos (ver [1]).

La opción SO_USEADDR ya la mencioné en esta entrada en la que comentaba los timeouts de TCP; en ella indicaba que, en general, interviene en el tiempo de espera…

antes de poner disponible, de nuevo, un puerto tras su cierre y el objetivo es dejar tiempo suficiente para que los segmentos de esta conexión saliente desaparezcan del sistema

aunque hay más y es lo que voy a tratar en el resto de la entrada junto con la opción SO_REUSEPORT. Ambas son importantes para la programación de Sistemas Distribuidos; y podemos usarlas cuando nos convenga, pero sin olvidarnos que debemos disponer de una versión del núcleo igual o superior a la 3.9.

SO_REUSEADDR, en GNU/Linux (así como en BSD y otros sistemas operativos) introduce, tal y como podemos comprobar en la página man de la función socket [2], la posibilidad de reutilizar la misma combinación IP-Puerto en un servidor, siempre y cuando el puerto no esté en escucha activa (es decir, se haya ejecutado la función listen para ese puerto). Básicamente, nos permite reutilizar puertos UDP, teniendo un comportamiento diferente en otros sistemas como por ejemplo BSD (ver [1]).

SO_REUSEPORT, en GNU/Linux, permite asociar un número arbitrario de sockets a la misma pareja IP-puerto, tanto para TCP como para UDP. Esto solo tiene una limitación (además de que el flag debe estar activo, antes de ejecutar bind, en todos los procesos): todos los sockets deben de pertenecer a procesos con el mismo EUID (identificador de usuario efectivo) para evitar el secuestro de puertos (port hijacking).

¿Qué ventaja aporta? Si consultamos la página man de socket:

this option allows accept load distribution in a multi-threaded 
server to be improved by using a distinct listener socket for each 
thread.  This provides improved load distribution as compared to 
traditional techniques such using a single accepting thread 
that distributes connections, or having multiple threads that 
compete to accept from the same socket.
UDP sockets, the use of this option can provide better distribution
of incoming datagrams to multiple processes (or threads) las compared
to the traditional technique of having multiple processes compete 
to receive datagrams on the same socket.

¿Cómo lo implementamos? Veamos un ejemplo. Si tomamos el código del servidor sencillo descrito en esta entrada y le añadimos la siguiente orden, justo antes de invocar la función bind*:

s.setsockopt(socket.SOL_SOCKET, SO_REUSEPORT, 1)

tras varias ejecuciones del programa, tendremos el resultado de la imagen 1 :

Screenshot from 2015-03-20 10:53:54

Y ¿qué proceso recibe los datos de aplicación? ¿Todos? Pues no. Tanto en TCP como en UDP, el núcleo de GNU/Linux trata de repartir equitativamente el trabajo entre los procesos: las conexiones entrantes para TCP (las reparte equitativamente entre los procesos que están con la ejecución de la función accept en ese puerto) y los datagramas para UDP. En el caso específico de multicast, SO_REUSEADDR tiene el mismo comportamiento que SO_REUSEPORT en conexiones unicast.

Para el ejemplo visto, tras 2 conexiones (una desde el propio equipo y otra desde otro nodo de la red) tenemos que estas se asignan a 2 procesos diferentes (ver imagen 2)

Screenshot from 2015-03-20 10:56:55

¡Espero que os sea útil!

*Solo nos falta definir: SO_REUSEPORT=15

Referencias

1.- Muy completa la respuesta dada en: http://stackoverflow.com/questions/14388706/socket-options-so-reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t

2.- man socket

3.- man setsockopt


Transparencias de la clase sobre DNS en el Grado de Informática

Revisando el material de clase que tengo, he comprobado que creé transparencias de temas que, casi seguramente, no vuelva a utilizar y antes de que se pierdan en la profundidad de mi sistema, las he dejado (o dejaré ya que tengo que revisar muchas de ellas) en Slideshare.

De la asignatura de Administración de Redes de Computadores, he dejado, por ahora, la dedicada al servicio DNS.

Aquí la tenéis:

¡¡¡Espero que os sean útiles!!!


Protección contra ARP poisoning

Ya he escrito en varias ocasiones acerca de problemas que permiten insertar un equipo entre nosotros y nuestros objetivos (Ataque Man In The Middle): aquí y aquí. En esta entrada, que amplía el “primer aquí”, el objetivo es explicar en qué consiste y cómo podemos abordarlo.

¿Qué es ARP Poisoning?

Consiste en conseguir indicarle a un nodo que la MAC asociada a una IP (por ejemplo la de nuestro router por defecto) es la otra diferente a la que tiene realmente el equipo objetivo. Conseguirlo es bastante fácil y, además, simplemente hay que usar el propio protocolo ARP. Una imagen vale más que mil palabras y, creo, la de la Wikipedia refleja bastante bien en qué consiste el envenamiento de ARP (también llamado, por el efecto, ARP Spoofing):

Leer más


IGMP: tráfico multicast y filtros

Cuando diseñamos una red una de las tecnologías/infraestructuras que planificaremos será la instalación de un cortafuegos*. En estas circunstancias tenemos que tener claro qué paquetes dejamos pasar, cuales desechamos, y todo en función de nuestra política de seguridad y sin perder la funcionalidad para la que estamos diseñando nuestra red.

Si utilizamos OSPF o, en general, si queremos manejar tráfico multicast, debemos habilitar los paquetes IGMP en nuestros filtros (suponiendo que tenemos la estrategia de denegar todo lo que no está explicitamente habilitado) ya que es el protocolo que utilizaran hosts y routers para establecer los miembros de los grupos de multicast. De este protocolo, debemos tener en cuenta, sobre todo, que se encapsula en datagramas IP con el número 2 de protocolo (esto implica que NO utiliza UDP ni TCP ni, por tanto, tiene puertos). Otro detalle que debemos tener en cuenta es que el TTL de los paquetes de IGMP, por defecto, es 1, lo que implica que no “atravesarán” los routers y no saldrán de la subred en la que se genera, aunque puede aumentarse para localizar servidores lejanos utilizando este campo como “barrera” y configurando los routers para que sean transparentes y no decrementen el TTL**.

La ejecución de las siguientes órdenes provocará que nuestro router de filtrado acepte y saque mensajes IGMP:

iptables -A INPUT -p igmp -j ACCEPT
iptables -A OUTPUT -p igmp -j ACCEPT

Para el caso de los grupos multicast relacionados con OSPF que comentábamos en la entrada anterior, podríamos limitar las reglas habilitando solo los grupos relacionados con OSPF:

iptables -A INPUT -p igmp -d 224.0.0.5 -j ACCEPT
iptables -A INPUT -p igmp -d 224.0.0.6 -j ACCEPT
iptables -A OUTPUT -p igmp -d 224.0.0.5 -j ACCEPT

Referencias

  1. Building Internet Firewalls, de Elizabeth D. Zwicky, Simon Cooper y D. Brent Chapman
  2. https://tools.ietf.org/html/rfc3376, RFC para IGMP versión 3
  3. http://tools.ietf.org/html/rfc2236, RFC para IGMP versión 2

* Prefiero usar el concepto de cortafuegos para la infraestructura de protección de red que diseñamos y que puede estar compuesta por varios elementos donde, uno de ellos, el dispositivo de red que filtra paquetes y que -casi- todo el mundo denomina cortafuegos, yo prefiero denominarlo router de filtrado.

** Una orden genérica para este caso es: iptables -A FORWARD -p igmp -j ACCEPT Si queremos, por ejemplo, especificar que el tráfico que queremos es el relacionado con el audio/vídeo: iptables -A FORWARD -p udp -m udp -d 239.0.0.0/16 –dport 5001 -j ACCEPT

 


Filtros de red para OSPF (Open Shortest Path First)

Si en nuestros routers utilizamos la estrategia de denegar todo por defecto y permitir expresamente lo que deseamos, en el caso de que estos equipos tengan configurado que aprendan sus rutas con OSPF, debemos habilitar dicho protocolo. Para ello, debemos tener en cuenta que OSPF

  • se encapsula en datagramas IP con el número 89 de protocolo (esto implica que NO utiliza UDP ni TCP ni, por tanto, tiene puertos),
  • usa tanto paquetes multicast (los grupos 224.0.0.5 y 224.0.0.6 y lo que nos obliga a configurar, usar y habilitar en nuestros filtros IGMP*) como unicast,
  • el TTL de sus paquetes es 1, por lo que no atravesarán un cortafuegos, salvo que configuremos un túnel (http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00800a43f6.shtml),
  • y por último, dispone de un identificador de tipo de paquete (nos permite mejorar las reglas, aunque dependemos del software de filtrado).

Con iptables, la forma más fácil es ejecutar las siguientes ordenes**:

iptables -A INPUT -p 89 -j ACCEPT
iptables -A OUTPUT -p 89 -j ACCEPT

Si queremos ser más “finos”, debemos indicar las IPs de origen, destino y, si lo permite el software de filtrado, el tipo de paquete de OSPF. Las reglas en este caso***:

#hello ospf between rt_ext and rt_int
iptables -A INPUT -s rt_ext -d 224.0.0.5 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.5 -p 89 -j ACCEPT
#database description, link state request, asking for information about a particular link and request/update link state
iptables -A INPUT -s rt_ext -d rt_int -p 89 -j ACCEPT
iptables -A OUTPUT -d rt_int -s rt_int -p 89 -j ACCEPT
#link state update, flooding all link states from rt_ext router
iptables -A INPUT -s rt_ext -d 224.0.0.5 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A INPUT -s rt_ext -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.5 -p 89 -j ACCEPT
#rt_int router link state update from rt_ext router
iptables -A OUTPUT -s rt_int -d 224.0.0.5 -p 89 -j ACCEPT
iptables -A INPUT -s rt_ext -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A INPUT -s rt_ext -d 224.0.0.5 -p 89 -j ACCEPT

Referencias

  1. Building Internet Firewalls, de Elizabeth D. Zwicky, Simon Cooper y D. Brent Chapman

* Es muy sencillo, pero lo dejo para otra entrada 😉

**Estamos considerando que NO queremos reenviar (forward). Si quisiéramos hacerlo, ver el punto 3 de las consideraciones de OSPF que he escrito en la entrada. Además, estas reglas deben ejecutarse en los routers designados.

***Las reglas se deben de ejecutar en los router afectados (en rt_ext cuando ‘-s rt_ext’ o en rt_int si ‘-s rt_int’), salvo que dispongamos de un cortafuegos específico y, en ese caso, se ejecutan todas en él. Recordad que debe disponer de un túnel (ver **)


Timeouts de TCP en GNU/Linux y opciones para “afinar” un servidor

Los tiempos de espera de TCP vistos en la entrada anterior se pueden consultar y modificar en GNU/Linux a través de los ficheros apropiados del /proc y, para afinar un servidor y mejorar sus prestaciones en base a estos timeout, podremos modificar sus valores en este sistema de archivos sin necesidad de recompilar el núcleo. Pero, antes de nada, si lo que queremos es afinar nuestro sistema, lo que debemos es de plantearnos es esta pregunta: ¿cuántos puertos concurrentes podemos tener abiertos? Para ello:

Leer más


Timeouts de TCP

En TCP(1) existen 4 tipos de timeouts (tiempos de espera) y cada uno de ellos se aplica en diferentes momentos y con diferente duración. Algunos, incluso, podemos evitarlos si es lo que deseamos…

Conocer estos tiempos es importante tanto para administradores de sistemas como para programadores de aplicaciones distribuidas (¡¡¡pocas no lo son ya!!!)

Leer más


Como cambiar la MAC en GNU/Linux

Existen ciertas circunstancias en las que cambiar la MAC de nuestra tarjeta de red nos facilita el trabajo. Por ejemplo, si tenemos filtros por MAC (como ocurre con muchos routers ADSL) y cambiamos la tarjeta de red de nuestro equipo, quizás sea más fácil cambiar la MAC de la nueva por la que tenía la vieja y que se le apliquen todos “las ventajas” que tengamos implementadas, que ir cambiando los filtros en cada uno de los dispositivos.

Sea por la razón que sea (alguna también puede no ser “benigna”), en Debian se realiza con la ejecución de estos comandos (suponemos que la NIC es eth0):

ip link set dev eth0 down
ip link set dev eth0 address aa:bb:cc:dd:ee:ff
ip link set dev etho up

Si queremos comprobar que todo ha ido bien: ip link show eth0

Para que se quede fijo y al reiniciar dispongamos de la nueva MAC, podemos crear un guión con las 3 órdenes anteriores y lanzarlo en el arranque de la máquina.


Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Más información.