Debido a que en casa estamos cambiando de ISP, hemos tenido unas semanas de doble servicio, ¿qué experimentos podemos hacer que habitualmente no con una sola conexión?

Si no estuviera un poco aburrido del asunto de la ciberseguridad, me pondría a tirar nmaps y esas cosas... bueno, lo hice igual, pero la verdad es que más es interesante...

Multitier torrent

Normalmente cuando usas bittorrent, si estás bajando algo popular alcanzás una muy alta velocidad, limitada en última instancia por los componentes cercanos a vos, o sea, tu ISP.

El experimento que voy a realizar es comparar bajar el mismo contenido de distintas maneras teniendo múltiples (dos) ISPs.

Limitaciones

No me interesa explorar si hay algún cliente que sabe cómo lidiar con la situación, pues es algo que no puedo generalizar luego para otras aplicaciones.

No puedo usar dos placas de red, pues me consta que la máquina donde puedo poner varias placas por tener bus PCI tiene contención de ese mismo bus, en otra oportunidad me afectó.

No puedo usar un dongle USB-Ethernet pues baja considerablemente la velocidad.

Tampoco pienso poner una placa en mi máquina pues en los últimos cinco años he andado con mala suerte y se me ha roto una proporción desproporcionada de las máquinas que he abierto.

Tres escenarios

En realidad son dos pero necesito uno de referencia para poder comparar.

Referencia

Hay que medir primero la performance de cada ISP por separado. Para ello agrego un router que tenía tirado por ahí y le conecto otra máquina. En ambas bajo lo mismo.

Considerá que todos estos números son un tanto imprecisos, sobre todo los del ISP 1, pues la misma conexión está siendo usada a la vez por otras personas.

Medición ISP 1

Bajé el archivo completo:

3.86 GB
21 minutos 1260 segundos
3860398080 / 1260 = 3063808 B/s = 3.06 MB/s
por momentos 3.65 MB/s

Medición ISP 2

Cuando llegó a 15 minutos me aburrí, tomé estos datos parciales

1.18 GB
15 minutos = 900 segundos
1180000000 / 900 = 1311112 B/s = 1.31 MB/s
por momentos 1.54 MB/s

Vía ISP 2

Dos máquinas

Dos máquinas, cada una conectada a un ISP y aprovechar que mi cliente entiende buscar en la red local si hay alguien bajando lo mismo, de este modo quizás cada uno baje un mitad y la comparta con el otro.

Local Peer Discovery en ambas máquinas

Para esto hay que:

desactivar DHCP en el router del ISP2
poner al router en una IP de la red del ISP1, por ejemplo 192.168.1.10
poner a la máquina 2 con IP 192.168.1.11 y gateway 192.168.1.10
tirar un cable del router al switch
activar LPD en ambas máquinas

Pre prueba

Que una máquina vea a la otra en la red local y baje todo de ahí, ok, dejé que la segunda máquina terminara y anduvo.

Habiendo activado Local Peer Discovery

Medición dos máquinas

3.86 GB
16 minutos, son 960 segundos
3860398080 / 960 = 4021248 B/s = 4MB/s
Por momentos 7MB/s

Bajada combinando un ISP y la otra instancia

Se ve la dirección local de la otra máquina

Es conveniente ejecutar en ambas máquinas como root o sudo:

$> mii-tool enp3s0
enp3s0: negotiated 100baseTx-FD flow-control, link ok

y las velocidades deberían coincidir.

Una máquina, dos rutas

En lo anterior no he cumplido con ser neutral con respecto al cliente de bittorrent, no sé si otros programas soportan LPD. Tampoco puedo contar con tener dos computadoras y espacio libre en ambas, notá que aunque bajé una sola instancia de la imagen, la tengo duplicada.

Lo que hay que hacer ahora es:

mantener el router del ISP2

DHCP desactivado
una IP estática conocida
cable al switch de la red principal

quitar la segunda máquina
LPD ya no es necesario
manipular sus rutas

Para manipular las rutas hace falta tener una vaga idea de cuál será la partición.

Tirando un

watch -n 10 netstat -tn >> ips.txt

toda la noche, me hice un mapa de las IPs típicas, el problema es que la salida me quedó con caracteres de escape, más o menos lo limpié con esto, seguro se puede hacer mejor:

strings ips.txt | grep "[01234567890.]*:443" -o \

| grep "\..*\..*\..*" | cut -d "." -f 1-2 \

| sort -n | uniq -c

Quitando los errores del comando anterior me deja:

      6 1.13
      5 2.16
      2 2.18
      2 2.43
      7 3.77
      2 52.1
      7 6.58
     62 8.43
      1 8.67
      3 13.33
      1 15.96
      6 16.58
      1 16.73
      1 16.74
     30 2.217
      8 23.12
      1 23.32
      1 23.55
    104 23.77
     52 3.107
    194 31.13
      3 3.223
      3 3.232
      4 34.98
      2 4.233
     12 4.244
      1 45.54
     10 5.201
    131 52.43
     54 68.67
      1 86.18
      1 88.99
     70 92.16
     31 104.87
      1 115.96
    148 13.107
      7 13.227
      1 144.76
      1 185.63
      7 186.18
    113 192.16
      1 192.73
     15 200.42
    260 216.58
      5 23.197
     10 23.222
      2 34.194
    199 35.201
      1 35.241
      2 52.195
      1 54.187
      1 54.219
    170 64.233
    297 72.217
      1 74.119
      2 74.125
      3 95.216
     99 104.244
      4 104.254
      1 108.174
      1 151.101
     16 152.195
      1 152.199
    953 172.217
     22 192.168

y agrupando a ojo:

redes entre 1.0.0.0 y 63.0.0.0 = 700
redes entre 64.0.0.0 y 127.0.0.0 = 1500
redes entre 128.0.0.0 y 255.0.0.0 = 1000

Ojo otra vez, esas IPs son las conexiones que hubieron durante un tiempo, no es un buen análisis pues no tengo idea del tráfico que hubo que es lo que realmente me interesa para particionar.

Veamos primero que hay:

$> route -n
Kernel IP routing table
Destination Gateway     Genmask       Flags Metric Iface
0.0.0.0     192.168.1.1 0.0.0.0       UG    100    enp3s0
169.254.0.0 0.0.0.0     255.255.0.0   U     1000   enp3s0
192.168.1.0 0.0.0.0     255.255.255.0 U     100    0     0 enp3s0

Lo que tengo que agregar es una ruta tal que el Gateway sea el router que conduce al ISP 2, esto es, 192.168.1.10. Luego usando dos servicios de identificación de cuál es mi IP, ver que uno me dice una y otro la otra.

Tengo dos, con ping -c 1 obtengo sus IP

https://whatismyipaddress.com 104.16.155.36

https://www.whatismyip.com 104.27.199.91

ufa, están muy juntas.

https://www.myip.com 172.67.208.45

Mejor, de paso ya hago el particionado en 128.0.0.0, todos los route add son como root.

route add -net 128.0.0.0 netmask 128.0.0.0 gw 192.168.1.10 metric 100

Lo que nos da:

$> route -n
Kernel IP routing table
Destination Gateway      Genmask       Flags Metric Ref Use Iface
0.0.0.0     192.168.1.1 0.0.0.0       UG    100    0   0   enp3s0
128.0.0.0   192.168.1.10 128.0.0.0     UG    100    0   0 enp3s0
169.254.0.0 0.0.0.0      255.255.0.0   U     1000   0   0 enp3s0
192.168.1.0 0.0.0.0      255.255.255.0 U     100    0   0   enp3s0

Observá las distintas IPs según a quien le preguntes

Listo para torrentear.

En uno de los momentos de máxima velocidad

3.86 GB
17 minutos 1020 segundos
3860398080 / 1260 = 3063808 B/s = 3.78 MB/s
por momentos 4.77 MB/s

Resultados y reflexiones

Aun con un particionado muy bestia como el que he realizado, se pueden combinar exitosamente las velocidades de dos o más ISP.

Modo	tiempo [s]	velocidad [MB/s]	pico [MB/s]
ISP 1	1260	3.06	3.65
ISP 2		1.31	1.54
Dos máquinas	960	4	7
Dos rutas	1020	3.78	4.77

El pico no es muy representativo, en "Dos Máquinas" indica lo que ocurrió en la LAN. Lo interesante es que la red local de 100 Mb está prácticamente saturada, si agregara un tercer proveedor como el primero no lo podría aprovechar completamente, tendría que usar una red interna de 1Gb.

Siguientes pasos

Me interesa mucho este tema, pero dentro de dos días me quedo sin el segundo ISP y la verdad es que no me paso el día bajando cosas y tengo otras muchas tan o más interesantes que hacer, lo que sigue te puede servir de inspiración para que lo hagas vos. ¿No tenés dos ISP? No hay problema, le pedís a un vecino que tenga WiFi con un proveedor distinto al tuyo mejor que te preste sus credenciales y ya tenés dos ISPs, o tres o más.

Distribución mediante DHCP

Todo lo que hice antes fué en una sola máquina, si querés que todas tus máquinas tomen esa configuración, parece que con DHCP se puede.

Balanceo dinámico con ruteo

Si tenés varios canales como es este caso y además tenés el control en ambos extremos, el balanceo debe ser sencillo, en particular en una red local lo he hecho usando trunking/bonding.

Para el caso actual, donde están de un sólo lado del caño, no es tan sencillo, habría que estar midiendo cual es el mejor camino, una combinación de ancho de banda, latencia, saltos hasta el destino. Debe existir una manera común y normal pero para mejor aprender e investigar voy a seguir sin buscarla y pensando.

Para ver el tráfico discriminado se me ocurre agregar una interfaz virtual, de este modo se puede ver la saturación y si a la vez mirás netstat, podrías ir reparticionando. Cuando le pescaste la mano, reemplazás con un script. Pero no debe ser ten fácil, ¿qué pasa con una conexión que tenés abierta si cambia el enrutamiento? ¿El kernel se dá cuenta y no te la corta? Ahí recordé que man route ofrece:

-C operate on the kernel's routing cache.

Lo que me llevó a que manipulating the routing tables may not have an immediate effect on the kernel's choice of path for a given packet puede tener un efecto mitigante.

Parece que el kernel tiene un cache y que a menos que uno le pida explícitamente, add no lo toca. Esto no sólo salvaría a una conexión existente si no que muchas otras conexiones nuevas no tomarían la nueva ruta, debe haber un TTL por ahí.

Es todo un tema, listo, ya me cansé de pensarlo.

Si ponés en google algo así como

"dynamically changing routes to balance traffic between two providers"

tenés para divertirte.

Este curso no es la continuación del otro, deben ser parte de un grupo de cursos paralelos que comparten la intro y hacen referencias cruzadas.

No logro distinguir claramente que parte es confidencial y cuál pública, para discernirlo tendría que leer la documentación pública que debe ser interminable, así que me voy a limitar a comentar el efecto del curso sobre mí, expresando más mi visión sobre el tema que lo visto.

Trata de detección y prevención del accionar de bots, los cuales no dejan de ser automatizaciones de acciones humanas y pueden tener un mayor o menor parecido al accionar de un humano. Esta diferencia de parecidos es lo que permite detectarlo.

Según las cifras provistas, la mitad del tráfico de Internet es bot, siendo mitad y mitad "bueno" y "malo".

Bueno viene a ser google indexando, chat bots, feed fetchers, herramientas de monitoreo de salud de servicios

Malo robo y explotación de credenciales, intermediarios de datos, scrappers para recopilación de información por fuera de APIs, automated inventory purchasers que son los que compran cuando se abre una oferta limitada para la reventa y por supuesto, no me olvido de DDoS

Claramente, lo bueno y malo puede ser difuso.

Una navegación desde un navegador deja una traza de eventos con un patrón que la distingue de una herramienta de descarga como pueden ser wget o curl. Estas últimas pueden bajar elementos de más o de menos, más probable. No ejecutan el código javascript, lo que produce falta de mensajes y descargas.

Tambien hay múltiples maneras de detectar un bot por sus headers, tanto presencia como orden, ausencia y valores utilizados.

Un recurso más completo es usar headless browsers, como puede ser webdriver, lo que se usa con selenium. Este método reproduce el patrón, pero no de forma humana, no hay movimientos del cursor en la pantalla, no hay demoras o son fijas entre las interacciones.

Desde el servidor es improbable detectarlo, pero agregando un poco de javascript en algunos puntos cruciales se detecta a mejor. Supongo que siguiendo este link eventualmente llegarás a una demo que no pongo pues aún no me han contestado si puedo mostrar capturas de pantalla.

Otro recurso es por reputación de IP, pero no es decisivo, podés estar navegando legítimamente desde una máquina que tiene un bot haciendo un 5% de tráfico. O podés estar junto con mil personas y un bot mas detrás de un NAT y ahí se complica.

Una vez que detectaste un bot, ¿qué hacés? Bueno, depende de si es bueno o malo y de lo que esté haciendo. Si es bueno pero no se está portando bien, lo frenás o le dás contenidos cacheados, entendiendo que no te quiere molestar, sólo está mal configurado.

Si es malo, depende de la inteligencia que haya detrás, siempre es bueno que cuando te atacan lo hagan por donde conocés. Si vos le decís que ya sabés que es un bot y lo rebotás, estás haciendo que busque otro lugar por donde molestar. Entonces quizás sea mejor darle diversas respuesta, todas inhabilitantes pero que no revelen que ha sido descubierto como bot. Podés negarle a veces, demorarle otras, mandarle a contenido alternativo o a un honey pot.

Como en todo curso y más tan pautado como son estos de tipo corporativo, lo más importante es el área docente y la interacción del resto del alumnado, lo que hace la diferencia con leer el material provisto. En la intro previamente mencionada se mencionó algo que quizás me perdí en el otro, no creo pues nació de una pregunta.

Llega una petición al Edge y después de un INCREIBLE manoseo sin salir del Edge y quizás sumado a otro manoseo al llegar al Site, recién ahí llega al servidor protegido, la pregunta es, ¿cómo afecta eso a la latencia?

Da justo la casualidad que estoy leyendo un breve libro de los liberados por ACM debido al covid que se llama

Heterogeneous Computing: Hardware and Software Perspectives, Mohamed Zahran

en el cual se menciona que uno de los más importantes factores a considerar es la comunicación entre los nodos que procesan la información, al punto que pueden haber operaciones que te conviene hacer en este nodo ineficiente en lugar de en el optimizado para no perder tiempo en la transferencia de los operandos y el resultado.

Menciona por ejemplo los cores de aceleración que están en el mismo silicio como los APU de AMD en contraste con tener que ir vía PCI hasta la otra placa.

Eso ya se adivina en el chip Epiphany de la placa parallella, que tiene un sistema de mensajería interno entre los 16 cores. Y parece ser la tendencia al usar los Zynq y los MPSocZynq por el lado de Xilinx y tambien por Intel.

Volviendo a Akamai, lo que explicaron es que por un lado no es tanto tiempo el de procesamiento en comparación a viajar por Internet, lo cual queda compensado por no utilizar el enrutamiento normal si no el suyo propio.

Recordá que esto es sólo TCP, en particular 80 y 443, no te sirve usar Akamai para evitar el lag en UrbanTerror o el FPS de tu preferencia.

Seguridad Agile

2020/05/30

Qué podés hacer cuando tenés dos ISPs