Mostrando entradas con la etiqueta networking. Mostrar todas las entradas
Mostrando entradas con la etiqueta networking. Mostrar todas las entradas

2021/11/03

Ejemplo de SID

Aunque a todos nos debe haber ocurrido, es la primera vez que me ocurre a mi de modo tan evidente, comparto la experiencia.

Me contactaron unas personas para ver unos temas de seguridad y uno de los items era "revisar las seguridad de un firmware".

Los actores somos el end user, mi interlocutor que es el cliente y yo.

Este firmware era el resultado de la siguiente situación, el que hayan dos dispositivos y cada uno con dos firmwares representa las posibilidades, el end user termina conectándose a un firmware en un dispositivo:

 

Situación actual
Situación actual

Los end users tienen un dispositivo de hardware que para mejor interactuar con el  sistema del cliente requiere cambiar un aspecto de su configuración con frecuencia. Como la alta frecuencia de ese cambio no está prevista por el fabricante del firmware, no ofrece almacenar configuraciones alternativas, mediante la interfaz web del firmware hay que pisar con la nueva la existente en lugar de dar de alta varias y sólo elegir luego la activa.

La idea del cliente era tomar el firmware que es opensource y extenderlo.


Actualización de Firmware
Actualización de Firmware

Inmediatamente me generó incomodidad debido a que el firmware es una pieza delicada y cualquier cambio o extensión aumenta la superficie de ataque y aumenta la responsabilidad, tanto de seguridad como de funcionamiento. Además, pensaba estos inconvenientes adicionales:

  • Si hay upgrades al firmware oficial, el cliente va a tener que portar los cambios.
  • Si el cambio es aceptado e incorporado al firmware oficial, probablemente tenga que mantenerlo.
  • Hasta acá quizás es aceptable, pero si hubieran distintos firmwares, se multiplica el esfuerzo.

Esto viene de la mano de un concepto de seguridad que dice que a menos que te dediques a la criptografía, no diseñes criptografía, sólo usala, pues vas a meter la pata. En este caso aplica si no te dedicás a hacer firmware, no diseñes firmware.

 

La primera propuesta que se me ocurrió fue implementar una web que haga de fachada ante esos dispositivos y mediante un poquito de scrapping, opere contra el dispositivo, almacenando las configuraciones alternativas, que de paso no haría falta que las cargue el end user, sólo seleccionarlas.

 

Con servidor web en el medio
Con servidor web en el medio
 

El scrapper, al que elegantemente llamé "conector", sería uno por cada versión de firmware de cada dispositivo. Este concepto de conector se repite en todas mis propuestas.


Nuevamente una mala sensación, las credenciales de los dispositivos de los end users pasan por la infraestructura del cliente, eso aumenta su responsabilidad en términos de seguridad. Aunque sólo reciba las credenciales y las use sin persistirlas, que es una buena reducción de superficie, resulta inútil frente un APT en la infraestrucura del cliente.

Y están estos problemas adicionales:

  • El dispositivo debe ser accesible desde la red del cliente
  • Hay que darle una nueva credencial ante este sistema
  • Cuando el end user ingrese la IP del dispositivo sobre el cual operar... podría ser cualquier IP, se podría usar mal por error o a propósito.


Finalmente, evolucioné la idea a elaborar un plugin para el browser, que usando los conectores de scrapping, tomen las configuraciones o de un storage local o de la infraestructura del cliente.

 

Con plugin de browser
Con plugin de browser

Sólo hay que mantener dos versiones, no hace falta actualizar permanentemente, pues el cambio de arquitectura de los plugins de los browsers no es para nada frecuente. Las credenciales del dispositivo quedan del lado del end user

Los ataques que quedan pasan por influenciar al end user para que ponga la IP de un dispositivo atacante en lugar del suyo y así tomarle las credenciales, pero quien caiga en ese ataque probablemente caiga tambien en "dame las credenciales".

Una posibilidad extra es hacer una aplicación mobile, pero quizás nuevamente estás entrando en terreno desconocido y aumentando la superficie de ataque.


Por si no te diste cuenta, SID es un término nuevo que inventé, o quizás reinventé, pero no tengo ganas de andar buscando a ver si ya existe, Security Influenced Design, en la línea de TDD (Test Driven Design de Kent Beck), BDD (Behavior Driven Design), DDD (Domain Driven Design de Evans). No llega a guiar el diseño pero si lo influencia.

2020/11/13

Lidiando con protocolos legacy

Inspirado por un problema que suele ocurrir en ambientes legacy y en un artefacto que hallé hace muchos años tirado en la vereda, diseñaré una mitigación e intentaré implementar unos componentes, con la excusa de practicar qemu, networking, programar en C, cambiar el firmware de un router y finalmente FPGA.


En FTP las credenciales circulan en texto plano
En FTP las credenciales circulan en texto plano
 


El problema

 

Tenemos dos equipos, quizás en distintos datacenters, que están usando para intercambiar información sensible un protocolo inseguro como http, ftp o telnet. Estos protocolos son muy fáciles de inspeccionar si podés ver el tráfico. No se pueden cambiar por X motivo, esa es la esencia del legacy.

 

Inspiración

 
Cifrador de  X25
Cifrador de X25

El componente de la fotito lo encontré en la calle y se mete en el medio de una conexión serial para cifrar el canal, uno en cada extremo. En cierto modo es como agregar una capa que normalmente es lógica de modo físico. Está en mi lista de deseos en algún momento lograr la máxima posesión del mismo.

No sé los detalles de lo que hace, pero me imagino que cifra todo el tráfico y que lo hace de modo transparente, los nodos que se comunican no se enteran de este proceso. La diferencia con mi proyecto es que se tratará sólo un tipo de tráfico y el resto circulará sin modificaciones.

 

Análisis de impacto

 

Hay varios inconvenientes: un atacante puede ver usuario y credencial si puede inspeccionar el tráfico de red. Luego, como puede ver todo el tráfico la información sensible que haya.


En términos de CVSS, como vulnerabilidad, si dejamos de lado la integridad el valor pasa de 6.5 a 4.6 

 

Adyacente sin integridad
Adyacente sin integridad


Physical sin integridad
Physical sin integridad


Si consideramos la integridad, de 8.1 a  6.1  


Adyacente con integridad
Adyacente con integridad


 

Physical con integridad
Physical con integridad


Esta mejoría se debe a que hace falta ir físicamente al datacenter y pinchar el cable o sacar componentes, no se puede atacar desde otra máquina conectada a la misma red. 

Fijate que no cambie de Adyacente a Físico en la puntuación base, pues ese es el valor de vulnerabilidad en general, lo hice en la puntuación de entorno, es la aplicación concreta de las circunstancias a la base.

 

Mitigaciones

 

El cable cruzado


Una solución sencilla si estuvieran juntos y se pudiese agregar una placa de red en cada equipo es usar un cable cruzado.

 

Networking


Si no se puede tirar un cable o agregar placas, se podría hacer a nivel del equipamiento de red, cosa que no sé hacer, no tengo equipamiento de red. Me imagino algo así como "si viene de tal IP y va a tal IP y es de tal Protocolo, enviar por algún modo tal que no sea muy visible, ya sea una vlan o mejor cifrado.

 

Componentes como el de la fotito


Puedo desarrollar un par de dispositivos que separen el tráfico, algo así:

 

            +-----------------+           +----------------+
+-------+   |                 tráfico común                |  +-------+
|sistema|<--------------------------------------------------->|sistema|
+-------+   |+--------------+ |           |+--------------+|  +-------+
            ||tráfico legacy|<--cifrado-->||tráfico legacy||
            |+--------------+ |           |+--------------+|
            +-----------------+           +----------------+

 

Si el tráfico no corresponde, pasarlo de una interfaz a la otra sin más trámite.

Si el tráfico corresponde, tratarlo de alguna manera  y pasarlo al otro componente, que invierte el tratamiento y se lo dá al destino.

 

Modo de protección


Veo dos maneras de implementar la protección:

 

Tunneling

 

Este es el modo más sensato, usar la magia de iptables/fwbuilder y establecer una VPN para hacer circular el tráfico de interés por ahi.

 

Cifrado por paquete

 

No sé casi nada de criptografía, así que no tomés como referencia mi diseño ni implementación.

En terminos de latencia, lo mejor que podría hacer es un xor del tamaño del buffer, pero tendría que ir cambiando ese xor para cada paquete, pues si se repitiera se abriría la puerta a sencillos ataques.

 

Ponele que cifro con el mismo k varios mensajes:

a       01011011 
k       01010101  
A       00001110

b       00110011
k       01010101
B       01100110



Como atacante, tengo todos los A,B...


Supongamos que tengo un a, debido a que por lo general el primer mensaje suele ser igual debido a encabezados, por ejemplo una página web suele comenzar con


<!DOCTYPE html>
<html

Fijate como obtengo el mensaje b, o cualquier otro, teniendo un solo mensaje conocido:



A       00001110
B       01100110
xor     01101000

a       01011011 
b       ????????
xor     01101000

b       00110011

 

Y este es un ataque increiblemente sencillo, casi el único que estoy en condiciones de explicarte, no sos vos, soy yo. Después hay mil maneras sutiles de fallar. Repito, lo que haga es de juguete.


Cuando llegue el momento, veremos...

 

Implementaciones


Hay varias maneras que se me ocurren y pienso intentar implementar apuntando al máximo aprendizaje.

 

Virtualización


Puedo usar Qemu o VirtualBox

  • Ventajas
    • gratis
    • homogéneo
    • ambos modos
  • Desventajas
    • aburrido
    • poco creible

 

Pese a lo aburrido y poco creible, va a ser lo primero que haga, usando ambos modos, como para comprobar que se puede hacer y estar atento a que no haya algún bloqueante que luego va a ser más difícil de identificar. Además usaré qemu pues tengo poca práctica últimamente

 

Computadoras


Dos viejas netbooks y un adaptador usb-ethernet

  • Ventajas
    • más creible
    • homogéneo
    • ambos modos
  • Desventajas
    • tengo que comprar otro adaptador usb-ethernet o mejor dos para que sean usb 3 y gigabit, unos u$s 40
    • ocupa mucho lugar y consumo
    • sigue siendo aburrido

 

Como no le veo mucha diferencia a virtualizar y me obliga a comprar el adaptador y principalmente sigue siendo aburridísimo, no lo voy a implementar.

 

Routers


Un router hogareño de más, otro que tiene sólo un ethernet, pero puedo usar el adaptador usb pues tiene usb

  • Ventajas
    • gratis
    • divertido
    • ambos modos
    • por fin le doy uso a esos routers
    • tengo que cambiar el firmware
  • Desventajas
    • heterogéneo
    • son distintos
    • tengo que cambiar el firmware

 

Esta implementación sólo la haré por que me obliga a cambiar el firmware, cosa que nunca he hecho. Probablemente me conforme con el modo tunneling.

 

FPGA


Usar dos FPGA con dos o cuatro pmods ethernet

  • Ventajas
    • máxima diversión
    • máxima dificultad
    • máximo aprendizaje
    • heterogeno, tengo que usar dos placas distintas pues es lo que tengo
  • Desventajas
    • heterogeno, tengo que usar dos placas distintas pues es lo que tengo
    • al menos u$s 80 mas impuestos y gastos de envío
    • sólo cifrado
    • quizás no me dé el cerebro para hacerlo

 

 

Resumiendo

 


TunnelingCifradoLo haré?
Virtualessisiambos
CompussisiNo
Routerssinotunneling
FPGAsnosicifrado


Dame unos meses, pues ahora estoy medio complicado.





2020/05/30

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

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.


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.




2019/09/06

Diagnostico de HTTP Headers con Polymer y Node Express dentro de TLS


El Problema

Estoy haciendo una miserable aplicacioncita con Polymer del lado del cliente y Node Express como API, siendo servidas de distintas URLs, ambas con TLS.

Al intentar agregar un Custom HTTP Header en lugar de ver un:

api_1 | { connection: 'upgrade',
api_1 |   host: 'api.techu.example',
api_1 |   'user-agent': 'Mozilla/5.0 ...Firefox/57.0',
api_1 |   accept: 'text/html,application....9,*/*;q=0.8',
api_1 |   'accept-language': 'en-US,en;q=0.5',
api_1 |   'accept-encoding': 'gzip, deflate, br',
api_1 |   'access-control-request-method': 'GET',
api_1 |   'access-control-request-headers': 'content-type',

api_1 |   'X-Practitioner-Auth': '2',
api_1 |   origin: 'https://www.techu.example' }



veo


api_1 | { connection: 'upgrade',
api_1 |   host: 'api.techu.example',
api_1 |   'user-agent': 'Mozilla/5.0 ...Firefox/57.0',
api_1 |   accept: 'text/html,application....*;q=0.8',
api_1 |   'accept-language': 'en-US,en;q=0.5',
api_1 |   'accept-encoding': 'gzip, deflate, br',
api_1 |   'access-control-request-method': 'GET',
api_1 |  'access-control-request-headers': 'content-type,x-practitioner-auth'
api_1 |   origin: 'https://www.techu.example' }



y un 

NetworkError: A network error occurred

en la consola del browser.



Como no entiendo en absoluto por qué esta ocurriendo esto, quiero descartar capas intermedias, quiero ver el tráfico de red, pero está con TLS.


No me interesa tanto mostrar la solución al problema que es CORS sino el camino seguido, centrándome en la dificultad de que haya TLS de por medio.


Alcance y consideraciones


Tengo la clave privada del servidor pues estoy en un ambiente de test y yo generé las CAs.


Tuve suerte, la ciphersuite que acordaron el servidor y el cliente es descifrable por wireshark. Según leí por ahí, hay ciertas combinaciones que lo son y otras que no. Hay maneras de forzarla.

Linux Mint 19.x.

Para variar, no sé casi nada de Polymer, Node, CORS, pero se parece a cosas que he aprendido y olvidado varias veces.


Instalar wireshark 


sudo apt install wireshark-qt

Cuando pregunta si permitir a usuarios comunes capturar en modo promiscuo, decile que si.

Luego hay que agregar el usuario al grupo y reiniciar la sesión.

sudo addgroup practitioner wireshark

Configurar el browser


Pedile al browser que deje disponibles las claves de sesión en un archivo:


SSLKEYLOGFILE=/home/practitioner/sslkeylog.log firefox


Para un launcher es parecido:


Si lo estás editando



Si lo estás creando





Una vez arrancado el browser, hay que identificar en que interfaz capturar. Podés usar ANY, pero estando con Docker mejor ser más especìfico. Sospecho que localhost es el lugar, pero comprobémoslo generando tráfico:


Tráfico en localhost y algunas interfaces de Docker


Localhost ok.


Luego hay que pedirle a wireshark que mire el archivo del browser:


(Pre)-Master-Secret log filename


y las private del sitio o sitios, yo tengo API y www, claro, si este problema se trata de algo de cross domain...



Private Keys



Mejor vaciar la cache, cerrar y volver a abrir el browser, para que no esté lleno de 304 y que agarre toda la sesión TLS.




Si tuviste éxito, vas a ver una solapita abajo que dice "Decrypted SSL"

No están de más algunos filtros como:

tcp.port == 443 && ssl.record.length > 66

La primera parte es para sacarse de encima lo que no es TLS, pero sólo si tenés la certeza que tu tráfico es sólo TLS.

Para tener esa certeza tendrías que activar en el servidor HSTS


La segunda es para eliminar los keep alives y otra información administrativa del canal. No hallé o al menos no busqué mucho como filtrar dentro del tráfico TLS, por ejemplo si quisieras sólo los GET, frame matches xxx no anda. No digo que no haya.

Con "Follow HTTP Stream" se pone mucho más amigable



Me apoyé en varias fuentes, fundamentalmente https://packetpushers.net/using-wireshark-to-decode-ssltls-packets/, donde hay más detalles relativos a las ciphersuites soportadas y como ajustarlas.

A diagnosticar

El encabezado sale "mal" desde el browser, no es problema de la API.



¿Qué estoy haciendo en el browser? Hago lo natural:


request.setRequestHeader('X-Practitioner-Auth', 'tok');

¿Qué hay de malo con eso?

Leyendo https://www.html5rocks.com/en/tutorials/cors/ inferí que el problema probablemente viene por el preflight fallido de CORS, que es ese OPTIONS sin GET posterior.

O sea que lo que puse en amarillo en realidad está ok, no me había dado cuenta que era en OPTIONS.... mejor no voy a decir nada por que no sé bien, aunque lo haya arreglado.



Supuse que la falla era tener en el middleware:


app.use(function(req,res,next) {
  res.setHeader('Access-Control-Allow-Origin','https://www.techu.example');
  res.setHeader('Access-Control-Allow-Headers','Content-Type');
  next();
});


en lugar de

app.use(function(req,res,next) {
  res.setHeader('Access-Control-Allow-Origin','https://www.techu.example');
  res.setHeader('Access-Control-Allow-Headers','Content-Type','X-Practitioner-Auth');
  next();
});



Pero no, no anda ni a palos. Despues de muchas vueltas llegué a que hay que usar CORS y listo:

npm install cors 

y en la API

const cors = require('cors');
var corsOptions = {
  origin: ['https://www.techu.example'],
  allowedHeaders: ['Content-Type', 'Autorization']
}

app.use(cors(corsOptions));


Un poco de CORS:


En resumen, en el comienzo todo era caos y promiscuidad, luego hubo SOP (Same Origin Policy) por motivos de seguridad pero eso complicaba la operativa así que hoy hay CORS (Cross Origin Resource Sharing), que es un mecanismo para que un servidor le diga a un navegador que puede ser llamado desde código provisto por otro sitio.

Que quede claro que CORS no afecta a una herramienta como Postman, en los navegadores incluso se puede deshabilitar. Dicen por ahí que con  --disable-web-security en chrome, no way firefox.

Me parece mejor implementarlo bien.


Mucho más largo, algún día...

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS




2018/05/25

Torrenter 2

Me había quedado una deuda en http://seguridad-agile.blogspot.com/2016/04/torrenter.html que procedo parcialmente a saldar.

Para poder resolver correctamente lo del dhcdp, hay que normalizar una situación: la interfaz de control, que toma la dirección de la red a la que se conecta no puede estar en la misma red que el trunk, que provée direcciones de red.

Tengo entonces que particionar el switch

VLAN

Voy a dejar el trunk y algunas bocas más en una VLAN y el resto del hogar en otra.

bridge->vlan->create->2
bridge->vlan->addPort->2->1
bridge->vlan->addPort->2->2-4 no hace falta, 1-4 estan trunking

bridge->vlan->addPort->2->5
bridge->vlan->addPort->2->...

bridge->vlan->addPort->2->12


Recapitulando



             +---------------------------+
             |        S W I T C H        |
             +-------------+-------------+
             |    VLAN2    |     VLAN1   |
             +------+------+-------------+
             | trunk|      |             |
             +------+------+-------------+
             | 1234 | 5-12 | 13-24       |
             +-++++-+------+-+-----------+
               ||||          |
192.168.2.0/24 ||||          | 192.168.1.0/24
               ||||          |
               ||||.3        | .112 x dhcp
             +-++++----+-----+----+
             | trunk   | control  |
             +---------+----------+
             |  T O R R E N T E R |
             +--------------------+

Habiendo normalizado esto, no hacen falta más los scripts goTrunk.sh y goNoTrunk.sh


DHCPD

Por último, falta proveer direcciones IP a quienes se conecten.

apt-get install isc-dhcp-server



Arranque desatendido

No voy a mentir, lo anterior quedó escrito hace mucho tiempo, ha perdido momentáneamente sino permanentemente mi interés, no creo que que agregue nueva información, queda así:

Por más último, hay que lograr que se pueda prender la máquina y funcione sin tener que interactuar.

Ya está para
  • raid
  • nginx

Falta para

  • trunking
  • routing
  • bttracker
  • btdownloadheadless
  • swap en video

2016/04/17

Torrenter


En alguna conversación relacionada a FLISOL CABA 2016, se mencionó disponer de alguna copia de la wikipedia para que los asistentes puedan llevársela.

La wikipedia pesa 12 GB completa, 3 GB sin índices ni imágenes según esa conversación.

Si este servicio estuviera disponible en la misma red del Flisolator, generaría un cierto impacto en el ancho de banda, por que una cosa es una instalación que intermitentemente baja 3 a 6 GB a 12 de un saque.

La idea es entonces tener una red separada donde las máquinas bajen sin interferir sobre las instalaciones y con bittorrent que sea más veloz, así no se quedan a vivir.

En cada lugar donde digo eth?, 192.168.?.?, /dev/sd??, /dev/ttyS? y similares, son valores míos, si has de transitar esta experiencia tus valores probablemente sean otros.

Plan A

Aprovechar hardware obsoleto.

Recordando que tenía un mother viejo muy decente con Athlon 2800+, con cinco puertos PCI gracias a @fcingolani y un switch 10/100 de 24 bocas, ofrecí sin compromiso armar una red aparte para este servicio.


En el primer intento venía bien, con 1.75GB de ram, una buena placa de video para usar su memoria como swap (128 MB + 120 MB se podrían usar), un disco sata de 160GB. El BIOS veía las cuatro placas 3com, video ok, memoria ok. Cuando intenté arrancar con pendrive, cuando estaba probando uno de los que tenía, dijo "missing operating system", ok, nada del otro mundo. Pero la apagué y fué definitivo. Nunca más arrancó. Dejé el mother pelado, sin pila, reset de la memoria del BIOS, revisé los capacitores, lo envolví en papel aluminio, cambié de fuente, puse velitas, nada.


Plan B


Lo mismo con un Pentium 3 de 700.

Bueno, no lo mismo, sólo 640MB de RAM y dos discos ATA de 40 80 GB. Es que cuando llegué a las primeras mediciones, uno de los de 40 falló y me obligó a buscar en el cajón y aparecieron dos de 80.

En parte por perversión, en parte por que hay un slot ISA 16, quise usar una (más) vieja ethernet 3c509 como interfaz de control, pero no prosperó. Le puse una Realtek. Retrospectivamente, el fallo se debía a problemas de enrutamiento, así que quizás tambien la agregue.


Las tareas


Instalar algún linux.

RAID: para aumentar el ancho de banda sobre los miserables discos.

Ethernet de control: para facilitar la vida.


Trunking: para aumentar el ancho de banda entre el Torrenter y la red, se configuran varios puertos del switch y las placas para que haga la comunicación en paralelo. En teoría pasamos de una red de 100Mbits a 400Mbits entre el servidor y el switch. A un sólo cliente no le hace diferencia, pero a cuatro o más si.

DHCPD: para que otorgue las direcciones IP a las máquinas que se conecten.

DNS: quizás en otra oportunidad

Memoria video como swap: para aumentar la performance del servidor.

Tracker: para que funcione bittorrent

Torrente: de eso se trata todo esto, no?

Mediciones: tiene sentido gastar plata en un taxi para llevar esto si no hay una diferencia importante en el tiempo de download? veremos...

Arranque desatendido: la idea es llevar una caja que se prenda y ande.

 

La ejecución


Distro

Asumo que quien lee esto sabe más o menos instalar cualquier distro y manejarse con linux.

Debian 8.0.4 32 bits, nada especial, sin entorno gráfico, con algunas cositas útiles.

apt-get install vim ethtool tcpdump

Particionamiento

Disk /dev/sda: 76.7 GiB, 82348277760 bytes, 160836480 sectors

Device     Boot    Start       End   Sectors  Size Id Type
/dev/sda1  *        2048  15624191  15622144  7.5G 83 Linux
/dev/sda2       15624192  16623615    999424  488M 82 Linux swap / Solaris
/dev/sda3       16623616 160835583 144211968 68.8G fd Linux raid autodetect


Disk /dev/sdb: 76.7 GiB, 82348277760 bytes, 160836480 sectors

Device     Boot    Start       End   Sectors  Size Id Type
/dev/sdb1           2048  15624191  15622144  7.5G 83 Linux
/dev/sdb2       15624192  16623615    999424  488M 82 Linux swap / Solaris
/dev/sdb3       16623616 160835583 144211968 68.8G fd Linux raid autodetect


No quiero incursionar en arrancar de raid, así que dejé las sd?1 para / y /home


RAID



apt-get install mdadm

Creación del raid con stripe, los discos en controladoras distintas debería mejorar el ancho de banda.

mdadm --create --verbose /dev/md0 --level=stripe \
  --raid-devices=2 /dev/sda3 /dev/sdb3



mkfs.ext4 /dev/md0




Para que monte al inicio



mdadm --detail --scan >> /etc/mdadm/mdadm.conf
 





blkid | grep md0 >> /etc/fstab

quedando

[/etc/fstab]

#UUID=044d6468-a015-404f-ae97-fb0814ca5aaf
/dev/md0        /RAID           ext4       defaults       0         3


Seguro que pude haber usado UUID en lugar de /dev/md0, pero me desvía de mi camino, que es bastante largo aún.


Trunking

 

Primero, hay que comunicarse con el switch.

apt-get install minicom

Usar un null-modem cable y configurar correctamente la comunicación en minicom:

/dev/ttyS0
19200 8n1 sw flow control
modem dcd line off


Ok, tengo login, pero, ¿cuáles eran las credenciales? las sabía hace 15 años.

Por suerte "3comcso" and password "RIP000" hace reset.

Luego, hay que cerrar las ventanas:


system->security->modify-> las claves de cada usuario


Configurar IP por si queremos guardar otros 15 años el cable en un cajón:

ip->interface->plin plin plin




Recuperar las 100 Mbits full duplex:

ethernet->portMode->all->100full

y finalmente armar el trunk de un lado...

feature->trunk->addPort->1->1
feature->trunk->addPort->1->2
feature->trunk->addPort->1->3
feature->trunk->addPort->1->4  

...y del otro


apt-get install ifenslave


[trunkIt.sh] 
    ifconfig eth0 down
    ifconfig eth1 down
    ifconfig eth2 down
    ifconfig eth3 down
  
    modprobe bonding mode=0 miimon=100
    ifconfig bond0 hw ether 00:11:22:33:44:55
    ifconfig bond0 192.168.1.3 netmask 255.255.255.0 up

    ifenslave bond0 eth0
    ifenslave bond0 eth1
    ifenslave bond0 eth2

    ifenslave bond0 eth3

Si tenés la interfaz de control en la misma red (mala idea, ahora la tengo así sólo por las pruebas) hay que ajustar las rutas con distintas combinaciones de


[goNoTrunk.sh]
    route del -net 192.168.1.0/24 bond0
    route add -net 192.168.1.0/24 eth4

[goTrunk.sh]
    route del -net 192.168.1.0/24 eth4
    route add -net 192.168.1.0/24 bond0

un ping 192.168.1.3 desde otra máquina seguido de un arp -a confirma que está funcionando:



192.168.1.3              ether   00:11:22:33:44:55   C                     eth6

si hay que continuar instalando cosas, puede hacer falta un

route add default gw 192.168.1.1

Primeras mediciones


Deseo determinar si el RAID es más rápido que el IDE pelado. Para ello transferí vía ssh linuxmint-17.3-cinnamon-32bit.iso de 1G4. No lo hice en condiciones de laboratorio, hay otro tráfico en la red, otras actividades en las máquinas involucradas y no repetiré las mediciones a menos que algo me llame la atención.

El resultado que esperaba era:
   La lectura sobre RAID es mejor que sobre IDE.
   La lectura vía trunk es mejor que vía enlace normal.

Veamos la cruda realidad

  • Escritura interfaz de control a IDE     5.0MB/s   04:37 (*)
  • Escritura interfaz de control a RAID    4.9MB/s   04:46
  • Lectura interfaz de control desde IDE   4.5MB/s   05:08



(*) es el mismo tiempo que me dió con los discos de 40 antes de fallar. Eso es bueno, el ruido de la red no interfiere mucho.

Epa, ¿qué pasó??? ¿Está tardando más en leer que en escribir teniendo de este lado una máquina brutalmente más poderosa?

32 bits vs 64 bits (doble)
640 MB vs 16 GB (25!!)
700 Mhz x 1 vs 3.2 GHz x 4 (cuádruple por cuatro)
IDE vs SATA (no sé)

Probablemente ssh está metiendo ruido, voy a tener que instalar un servidor web y usar wget en el cliente. De paso sirve para luego brindar descarga directa.

apt-get install nginx-light


Sólo hay que tirar un par de symlinks a los archivos previamente subidos. La escritura no me importa mucho, en realidad lo interesante es la lectura. Va de nuevo.

  • Lectura interfaz de control desde IDE   11,2MB/s   in 2m 8s
  • Lectura interfaz de control desde RAID  10,9MB/s   in 2m 9s
No hay diferencia apreciable, está en la velocidad máxima, vamos bien.


Ahora, a probar la lectura utilizando el trunk, que es el escenario productivo, de lecturas simultáneas. No pongo la velocidad pues wget marca la última, no la promedio.

  • 3 interfaz de control / IDE     6m 11s
  •                                 5m 45s
  •                                 6m 8s

 Parece coherente, se triplica el tiempo.

  • 3 trunk / RAID                  2m 47s
  •                                 3m 31s
  •                                 2m 47s

repitiendo...


  • 3 trunk / RAID                  4m 55s
  •                                 4m 19s
  •                                 3m 45s
     
Todo mal, los resultados que esperaba eran tipo  2m , veamos que dice ps:



top - 21:54:24 up 12 min,  2 users,  load average: 1.77, 0.98, 0.58
Tasks:  76 total,   1 running,  75 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.2 us, 11.1 sy,  0.0 ni, 42.8 id,  5.9 wa,  0.0 hi, 39.0 si,  0.0 st
KiB Mem:    641708 total,   593456 used,    48252 free,     9332 buffers
KiB Swap:   999416 total,        0 used,   999416 free.   548752 cached Mem
 

530 www-data  20   0    6520   2164   1688 D 39.5  0.3   0:41.50 nginx

No sé bien como diagnosticar, probablemente hay una saturación general.

Una medida más, igual pienso que lo mejor va a ser ver como se comporta con bittorrent.
  • 4 trunk / RAID                  5m 34s
  •                                 5m 35s
  •                                 4m 3s
  •                                 5m 37s


  • 4 interfaz de control / RAID    8m 20s
  •                                 8m 24s
  •                                 8m 31s
  •                                 8m 27s

pero load average: 0.60

Momento de parar y pensar


¿o será que le cuesta hacer funcionar a las cuatro ethernets? ¿Y si en lugar de usar el trunking, ponemos un cable cruzado en cada ethernet y tenemos cinco conexiónes simultáneas?


Recapitulemos, estos son los planes:

Usar bittorrent, para lo cual hace falta que estén todos en la misma red, para lo cual hace falta trunking.

¿Hace falta trunking? Si hay suficientes máquinas la carga sobre el servidor se alivia considerablemente.


Usar descarga directa, cada uno en su red, pero hay que medir si no es eso lo que hace que se caiga la performance. Además no tengo que sacar del rack el switch y llevarlo, menos trabajo y riesgo.

A ojo, los 12 GB son 45 minutos. Sin duda está mejor que los 70 de sin trunk, pero lejos de los 20 de una conexión no compartida, con o sin trunk. De todos modos, si viene una sola persona a la vez, el tiempo es 20 minutos. A medida que se sumen se degrada por un lado pero se compensa por bittorrent.

Apuesto entonces por trunking + bittorrent, sin importar los números. Igual si me queda tiempo probaré la conexión directa x 5.


Tracker

Ver Torrente

Torrente


Elegí este porque es el único que según apt-cache search hace tracking.

man bittorrent-downloader es tu amigo

Las próximas instrucciones son muy empíricas, puede ser que haya alguna importante falencia conceptual. Es lo que me funcionó.

*) Construir el archivo de torrent, el que uno le pasa al cliente.

btmakemetafile http://192.168.1.3:6969/announce linuxmint-17.3-cinnamon-32bit.iso

No olvidar el /announce, perdí horas por ello.

*) Copiar el .torrent a una carpeta e iniciar el tracker

bttrack --port 6969 --dfile dstate --logfile - --allowed_dir /RAID/TORRENT --allow_get 1



*) Abrir un browser en http://192.168.1.3:6969, tomar el link para el siguiente paso.

*) Posicionarse en la carpeta donde esta el archivo a compartir

btdownloadheadless --check_hashes 0 \
http://192.168.1.3:6969/file?info_hash=l%FCyH%7F%E2%9C%7B%25%92%7D%40%0F%26%C3%05%19%AB%A3%DD



El check_hashes en 1 la primera vez, la siguientes en 0.

Tras mucho, mucho, mucho fallar, he llegado a la conclusión de que sólo convendría usar bittorrent si hay mucha gente bajando.

Hacer un link de /var/www a /RAID/TORRENT (o donde lo hayas puesto) y ahí:

[index.html>
  <html>
    <head>
      <title>
        Flisol CABA 2016 Tracker
      </title>
    </head>
    <body>
      Torrent:

         <a href="linuxmint-17.3-cinnamon-32bit.iso.torrent">
           linuxmint-17.3-cinnamon-32bit.iso
         </a>
      <br/>
      Descarga directa: 

        <a href="linuxmint-17.3-cinnamon-32bit.iso">
           linuxmint-17.3-cinnamon-32bit.iso
        </a>
     <br/>
    </body>
  </html>

Memoria video como swap

Ya estoy un poco cansado y se me acaba el tiempo, así que le doy para adelante. Si puedo en otro momento edito y mejoro.

Hay que hallarla con


lspci -vvv -s 01:00.0

01:00.0 VGA compatible controller: Advanced Micro Devices, ...
  Subsystem: ASUSTeK Computer Inc. Radeon 9200 SE / TD / 128M
  Control: ...
  Status: ...
  Latency: ...
  Interrupt: ...
  Region 0: Memory at e0000000 (32-bit, prefetchable) [size=128M]

  ...

I'm feeling lucky, tiene dos adaptadores...


lspci -vvv -s 01:00.1

01:00.1 Display controller: Advanced Micro Devices, ...  (Secondary)...       Subsystem: ASUSTeK Computer Inc. Device c007
    Control: ...
    Status: ...
    Latency: ...
    Region 0: Memory at e8000000 (32-bit, prefetchable) [size=128M]




Ok, podremos rapiñar 120 MB + 128 MB.

Primer adaptador



Region 0: e0000000 + 800000 (los 8M que dejamos para video) = E0800000

Longitud total: 8000000 (128 MB)
Menos los 8 MB =  7800000 (120 MB)

El comando es entonces:

modprobe slram map=VRAM,0xE0800000,+0x7800000
 
dmesg dice:
 
[  695.642037] slram: devname=VRAM, devstart=0xe0800000, devlength=0x7800000
[  695.659638] slram: Registered device VRAM from 3678208KiB to 3801088KiB
[  695.659664] slram: Mapped from 0xe9780000 to 0xf0f80000



Y el otro? Probemos


e8000000 es la dirección y son los 128 MB completos (80000000)



modprobe phram phram=VRAM,0xe8000000,+0x8000000


cat /proc/mtd

dev:    size   erasesize  name
mtd0: 07800000 00004000 "VRAM"
mtd1: 08000000 00001000 "VRAM"


modprobe mtdblock


ls /dev/mtd*

/dev/mtd0
/dev/mtd0ro
/dev/mtd1
/dev/mtd1ro
/dev/mtdblock0
/dev/mtdblock1

mkswap /dev/mtdblock0
 

Setting up swapspace version 1, size = 122876 KiB
no label, UUID=767e1e0d-cf7b-464d-8895-b2b04685046
9
 

mkswap /dev/mtdblock1
 

Setting up swapspace version 1, size = 131068 KiB
no label, UUID=80ce243a-4c85-43a5-af96-1031cba2470c


Hay que darle prioridad a esta memoria antes que al disco con -p.

swapon /dev/mtdblock0 -p 10
swapon /dev/mtdblock1 -p 10
 
Veamos que pasó. 
 
swapon --summary 


Filename    Type  Size Used Priority
/dev/sdb2                               partition 499708 0 -1
/dev/sda2                               partition 499708 0 -2
/dev/mtdblock0                          partition 122876 0 10
/dev/mtdblock1                          partition 131068 0 10



El script actual es:

[swapOnVideo.sh]

modprobe slram map=VRAM,0xE0800000,+0x7800000
modprobe phram phram=VRAM,0xe8000000,+0x8000000
swapon /dev/mtdblock0 -p 10
swapon /dev/mtdblock1 -p 10

DHCPD

Por último, falta proveer direcciones IP a quienes se conecten.

apt-get install isc-dhcp-server

-------- Lo completaré otro día. --------

Arranque desatendido

Por más último, hay que lograr que se pueda prender la máquina y funcione sin tener que interactuar.

Ya está para
  • raid
  • nginx

Falta para

  • trunking
  • routing
  • bttracker
  • btdownloadheadless
  • swap en video

-------- Lo completaré otro día. --------

Conclusiones


Como ya todos sabemos, si las horas que dediqué las hubiera invertido en freelancear, pude haber comprado una máquina usada funcionando bastante más potente y aprovechar el trunking como es debido. Pero no puedo negar que me divierte bastante hacer esto, al menos no estoy gastando plata.



Links

https://flisol.usla.org.ar/event/caba/

https://raid.wiki.kernel.org/index.php/RAID_setup

http://computerdd.blogspot.com.ar/2006/10/linux-connect-to-serial-console-of.html

https://www.pantz.org/hardware/switches/3com3300passreset.html

http://www.linuxhorizon.ro/bonding.html

http://nginx.org/en/docs/beginners_guide.html

http://www.bittornado.com/


http://ft23.pmenier.net/docext/mtd/TIP_Use_memory_on_video_card_as_swap.html

https://wiki.archlinux.org/index.php/swap_on_video_ram