Ataques al cable y a los servicios

La ruta de redes ya te mostro el handshake de TLS y la validacion de certificados. La pregunta de seguridad que sigue es mas estrecha y mas util: con una implementacion correcta de TLS, que puede hacer todavia un atacante en el camino? La respuesta es mas que nada y mucho menos que todo, y la parte interesante es exactamente donde cae la linea. Todo lo de abajo supone que el protocolo esta bien implementado. Las implementaciones rotas son su propio tema, y uno mucho mas raro de lo que sugieren los titulares. TLS te da tres cosas. Confidencialidad, para que los bytes en el cable no se lean. Integridad, para que un byte modificado se detecte en lugar de aceptarse. Y autenticacion del servidor, para que sepas que la clave acordada pertenece al nombre que pediste. Los atacantes van precisamente a lo ultimo, porque depende de algo fuera del protocolo: tu almacen de confianza. Si un atacante puede instalar un certificado raiz en tu dispositivo, o si el software que usas ya venia con uno instalado, el handshake se completa, aparece el candado y el trafico se descifra en medio. Eso no es una vulnerabilidad de TLS. Es TLS funcionando exactamente como se diseno, con un ancla de confianza que no deberia estar ahi. La otra via es mas simple y no necesita criptografia: una pagina que parece la de acceso y no lo es. TLS no puede ayudar, porque el certificado de un dominio parecido es perfectamente valido para ese dominio.

ARP no tiene autenticacion. Un host pregunta a quien pertenece una direccion IP, cualquiera puede responder, y la respuesta se guarda en cache. En una red cuyo switch controlas, es un problema manejable; en una red compartida, es un pase libre. El ataque no es exotico y no rompe nada: basta con anunciar una y otra vez que una direccion dada esta en tu MAC, para que las victimas envien su trafico primero a ti. Mudarse a una red que no es tuya es la mitigacion practica, y es mas eficaz que cualquier software que instales despues. La razon de que esto importe incluso con trafico cifrado son los metadatos. Puede que un atacante en el camino no lea tus bytes, pero ve con que direcciones hablas, cuando, con que frecuencia y cuanto. Tambien puede decidir no reenviar, lo que convierte una posicion pasiva en una denegacion de servicio. Defenderse en el extremo significa fijar la direccion de la puerta de enlace a una MAC conocida o usar una VPN que tunelice todo el trafico a un punto en el que confias. Defenderse en el switch significa funciones que descartan anuncios que un puerto no tiene por que hacer. Ambas son reales; ninguna esta disponible en el wifi de una conferencia. La idea del envenenamiento sin la mecanica. Lo danino no es la respuesta falsa en si, sino que se guarde en cache.

who has 192.168.1.1? tell 192.168.1.50     <- gateway ARP, normal
who has 192.168.1.1? tell 192.168.1.77     <- repeated, from a laptop

victim ARP cache
  192.168.1.1  ->  MAC of 192.168.1.77    <- poisoned entry

result: victim sends gateway-bound traffic to the laptop first

mitigation  dynamic ARP inspection on the switch
mitigation  port security, one MAC per port
mitigation  encrypted protocols with certificate checkingEl mecanismo con el detalle necesario para defenderse. Funciona porque la respuesta se cree sin ninguna prueba.

DNS es la parte de la red que convierte un nombre en una direccion, y se diseno cuando la red era pequena y todos en ella eran de confianza. Un resolutor que acepta registros que no pidio, y luego los cachea, los seguira sirviendo hasta que expire el tiempo de vida. Esa es la forma del envenenamiento de cache: el atacante influye en una respuesta y el resolutor la reparte a cada cliente que pregunte despues. La cache es lo que convierte una influencia momentanea en duradera, y por eso el tiempo de vida es el numero que decide lo grave que es. DNSSEC firma las respuestas, de modo que un resolutor puede verificar que un registro vino de la zona que lo posee y no fue modificado. No cifra nada y no hace privada la consulta. DNS over HTTPS y DNS over TLS cifran la consulta para que un observador en la red no pueda leerla ni reescribirla, pero no demuestran que la respuesta sea correcta; solo trasladan en quien confias de la red local al resolutor que elegiste. El resumen honesto es que ambos son parciales, el despliegue de DNSSEC es desigual, y el consejo practico para un usuario es configurar un resolutor en el que confie en lugar de depender de lo que le entregue la red. La denegacion de servicio es la categoria de ataque donde la defensa es genuinamente dificil, y merece la pena entender por que en lugar de coleccionar contramedidas. El filtrado funciona cuando el trafico malicioso se distingue del legitimo. En una denegacion de servicio a menudo no se distingue: los paquetes estan bien formados, vienen de direcciones reales y piden paginas reales. La unica diferencia es cuantos son y hacia donde apuntan. Una regla de cortafuegos que descarte el ataque tambien descarta a los clientes. Eso es lo que significa que no puedes filtrar lo que no distingues del trafico real, y es un limite estructural, no una funcion que falte. Las SYN cookies son la respuesta clasica, y son instructivas por aquello a lo que renuncian. En lugar de guardar estado por cada conexion a medio abrir, el servidor codifica lo que necesita en el numero de secuencia que devuelve y lo verifica cuando llega el acuse final. El precio es que algunas opciones de TCP no se pueden negociar en ese modo, asi que las conexiones son algo menos capaces. Sigue siendo el intercambio correcto para un servicio publico, porque la alternativa es que una cantidad moderada de trafico falsificado tumbe el servicio. Lo que las SYN cookies no arreglan es una avalancha de conexiones completas, y por eso el resto de la leccion trata de limitacion de tasa. Un ataque de amplificacion no necesita mucho ancho de banda del atacante. Envia una peticion pequena con la direccion de origen falsificada a un servicio que produce una respuesta grande, y la respuesta llega a la victima. La relacion entre peticion y respuesta es el factor de amplificacion, y es una propiedad del protocolo, no del atacante. Los casos conocidos son todos servicios que responden por UDP sin handshake, asi que la direccion de origen nunca se verifica. Por eso un resolutor abierto, un servidor NTP abierto o un memcached expuesto no son un hecho neutral sobre tu red: son un arma que alguien apuntara a un tercero, con tu direccion en el remitente. Factores de amplificacion por protocolo. La ultima fila es la razon por la que memcached en una interfaz publica se volvio una emergencia y no un error de configuracion. La defensa tiene dos mitades y pertenecen a personas distintas. Si operas el servicio que se abusa, lo cierras a internet: un resolutor autoritativo no debe responder recursion a desconocidos, y nada que hable UDP propenso a amplificacion deberia escuchar en una direccion publica. Si eres el objetivo, necesitas capacidad que no posees, en la practica un proveedor capaz de absorber y filtrar el trafico aguas arriba, antes de que llegue a tu enlace. La verdad incomoda es que la segunda mitad cuesta dinero en proporcion al ataque, y ningun ajuste del lado del servidor la sustituye. La limitacion de tasa es la mitigacion que de verdad se despliega, y es un estudio sobre danos colaterales. En cada capa donde puedes contar hay un grupo de usuarios legitimos que parecen un solo atacante. Contar por direccion de origen castiga a todos los que estan detras de una conexion de oficina compartida o de un NAT de operador, es decir, a la mayoria de los usuarios moviles. Contar por cuenta permite que un atacante con muchas cuentas se quede por debajo del limite mientras un script legitimo de exportacion queda bloqueado. No hay capa que evite esto, porque el limite es una frontera trazada a traves de un continuo, y siempre cortara a alguien. El diseno practico combina varias senales debiles, encarece conseguir aquello que cuentas y asegura que el limite falle degradando en lugar de rompiendo. Cada capa donde se puede contar y el trafico legitimo que queda atrapado en ella. La respuesta correcta suele ser mas de una a la vez.

normal open
  client  SYN          ->  server
  server  SYN-ACK      ->  client
  client  ACK          ->  server      connection established

backlog pressure
  client  SYN          ->  server     half-open, in the backlog
  server  SYN-ACK      ->  client     no reply ever comes
  ... thousands more, backlog fills, new SYNs are dropped

SYN cookies  the server answers without storing state
             the ACK carries back everything it needs

cost to the server: one SYN, 40 bytes
cost to the attacker: one spoofed source addressUn SYN flood en detalle. La asimetria que lo hace funcionar es que el atacante gasta un paquete pequeno y el servidor gasta memoria y un temporizador.