LSI INTERRUPCIÓN [D]DOS, FIREWALLS Y MONITORIZACIÓN. PDF

Title LSI INTERRUPCIÓN [D]DOS, FIREWALLS Y MONITORIZACIÓN.
Course Lexislación e Seguridade Informática
Institution Universidade da Coruña
Pages 40
File Size 1.3 MB
File Type PDF
Total Downloads 37
Total Views 118

Summary

LSI resúmenes de las clases online, de la 16.2 a la 22...


Description

CLASES 16.2 - 22 – INTERRUPCIÓN [D]DOS, FIREWALLS Y MONITORIZACIÓN. Un ejemplo por excelencia de interrupción sería la Denegación de Servicio, a los que comúnmente se les llama DoS (Denial of Service) o DDoS (Distributed Denial of Service). El CERT (Computer Emergency Response Team) denomina a ésta como un ataque caracterizado por un intento explícito de denegar a los usuarios legítimos el uso de un servicio o recurso. Los servicios son vulnerables porque los protocolos no suelen estar diseñados para evitar estos ataques.

TIPOS DE ATAQUES DOS

A continuación describiremos los dos tipos de ataques DoS, aunque puede ocurrir que un ataque tenga características de ambos.

ATAQUES SEMÁNTICOS O LÓGICOS (LOGIC ATTACKS) .

Se explota una vulnerabilidad enviando paquetes mal construidos, provocando así una denegación de servicio en un sistema operativo o en un servicio de red. Puede ocurrir que sea: • • •

Completa: el sistema en su totalidad se viene abajo. Degradación del rendimiento: como p.e. un servidor web que va muy lento. Debido a malas configuraciones de nuestros sistemas. Un ejemplo podría ser el siguiente:

: es el nombre de una función () es lo que le pasamos a la función {} es el contenido que le vamos a meter a la función :|:& llamamos a la función, le pasamos la salida con un pipe (|) a la misma función, que la vuelva a llamar y lo ejecutamos como background ; fin de función

: llamamos a la función Si introducimos este conjunto de caracteres, al cabo de un rato habrá matado a la máquina. Se produce un fork bomb de procesos:

Resumidamente, la función se llama a si misma dos veces, y luego vuelve a llamarse dos veces de cada vez indefinidamente, por lo cual tenemos un proceso que la llama dos veces, luego otro que la llama otras dos veces, y así hasta infinidad de procesos. De esta forma se puede “comer” toda la cpu y tirar la máquina completamente abajo.

Para evitar estos ataques, tenemos distintos métodos: • •

Actualización de servicios (parcheo de vulnerabilidades). Definición de reglas en firewall.

EJEMPLOS:

PING OF DEATH (POD):

Se envía un ping malformado a una máquina. Un ping normalmente son 56 bytes (+20 bytes fijos de la cabecera IP, + 8 bytes de la cabecera ICMP, haciendo un total de 84 bytes). Muchos sistemas no podían soportar un paquete ping de mayor tamaño que el tamaño máximo de paquete IPv4 (65.535 bytes). Se puede enviar el paquete fragmentado. Cuando la máquina lo reensambla. Los sistemas operativos “modernos” (posteriores a 1997/1998) no son vulnerables a este ataque.

TEARDROP:

Se envía un paquete fragmentado a la máquina objetivo. Cuando se envían datos por red, se fragmentan en origen y se reensamblan en destino. P.e. para 3000 bytes: • • •

paquete 1 con 1-1500 bytes. paquete 2 con 1001-2000 bytes. paquete 3 con 1500-2500 bytes.

Como los fragmentos se solapan, la máquina cuando intente reensamblar los datos se quedará colgada o se reiniciará. Sistemas operativos modernos no son vulnerables a este ataque.

LAND (LOCAL AREA NETWORK DENIAL):

Consiste en enviar un paquete con la misma dirección IP y el mismo número de puerto en los campos fuente y destino de los paquetes IP. Basado en spoofing. Pasos: 1. Se envía un paquete TCP SYN a la máquina objetivo. 2. Se establece como IP origen (falsa) la dirección de la propia máquina objetivo. 3. La víctima se responde a sí misma continuamente, de forma que se terminará quedando colgada.

ATAQUES DE FUERZA BRUTA O INUNDACIÓN (FLOODING ATTACKS). Consisten en hacer que una máquina tenga mucho tráfico para que deje de dar servicio o se caiga.

EJEMPLOS:

PING FLOOD (ICMP ECHO REQUEST):

Envío masivo de paquetes ICMP Echo.

TCP SYN FLOOD:

Se trata de una inundación con SYN, por lo cual podemos llegar a las máquinas DMZ (zona desmilitarizada o red perimetral), las cuales usa habitualmente para ubicar servidores que es necesario que sean accedidos desde fuera, como servidores de correo electrónico, web y DNS. Y son precisamente estos servicios alojados en estos servidores los únicos que pueden establecer tráfico de datos entre la DMZ y la red interna, como una conexión de datos entre un servidor web y una base de datos protegida situada en la red interna.. Explota una debilidad intrínseca del protocolo TCP, por lo que es complejo de evitar. Produciría un buffer overflow. Nuestras máquinas tienen una estructura de almacenamiento que es el TCB (Transmission Control Block) en la cual se va almacenando la información en el proceso de handshake de las máquinas con las que estamos abriendo conexión o que están abriendo conexión con nosotros. Esa información nos servirá para gestionar esas conexiones, la cual contiene: • • •

IP local. Puerto local de la conexión. IP remota.

• • • • •

Puerto remoto. Interface de red que se está utilizando para abrir esa conexión. El proceso que utiliza esa conexión. El estado en el que se encuentra la conexión. Los tamaños de ventana (windows size), tanto de la local como de la remota. Los números de secuencia de los paquetes para los que ya se ha recibido ACK. El número de secuencia de los paquetes enviados de los que todavía no se tiene confirmación (ACK). Los siguientes números de secuencia para enviar las transmisiones de datos.

• • • • • •

Round-trip time (RTT), que es el tiempo de ida y vuelta para poder establecer los timeouts de retransmisión. El tamaño del buffer local de datos, donde se va almacenando la paquetería que llega. Un puntero al propio buffer.

Su tamaño por defecto es de 128 entradas, pero lo podemos cambiar en el fichero /proc/sys/net/ipv4/tcp_max_syn_backlog.

Se envían paquetes TCP con flag SYN al servidor, reemplazando la IP origen por una IP legal pero inalcanzable. Cuando el servidor recibe el mensaje ocurren los siguientes pasos: 1. Reserva espacio para la conexión (buffer, sockets...). 2. Responde a una dirección inalcanzable, es decir, que nadie responderá. 3. Debe esperar que venza el timeout con socket abierto, reserva de buffers, etc. 4. Este ataque nos llenaría la TCB antes de que salten los timeouts, que son los que liberarían las entradas al no recibir un ACK como respuesta al SYN/ACK pasado el timeout especificado. El valor del timeout por defecto es de 5 segundos, pero se puede cambiar en el fichero /proc/sys/net/ipv4/tcp_synack_retries. 5. La máquina quedaría muerta a nivel de red puesto que no acepta nuevas conexiones a nivel TCP. Si hacemos que la tcb tenga muchas entradas, el acceso y los retardos van a ser mayores provocando problemas de rendimiento, hay que jugar con el equilibrio entre securizar y el rendimiento. Si bajamos demasiado los timeouts podríamos llegar a hacernos a nosotros mismos una denegación de servicio, porque podríamos estar cortando conexiones de clientes legales.

Para evitarlos, podemos usar: SYN Cookies:

Para activarlas, se pone el fichero /proc/sys/net/ipv4/tcp_syncookies a 1. Una vez que la TCB se llena por un floodeo, lo que va a hacer es que ante el SYN va a enviar un SYN/ACK (al que se le llama SYN cookie challenge) con un número de secuencia en el que va codificado o hasheado la IP origen, la IP destino y el puerto, de tal forma que cuando responda con el ACK podemos reconstruir esa IP de origen, de destino y puerto. De esta forma, la información mínima necesaria para hacer el handshake ya no la sacamos del TCB, sino de la propia codificación del número de secuencia de los paquetes. Así, se reserva espacio para la conexión únicamente cuando se recibe el mensaje de confirmación final. SYN Caches:

Se usa una estructura de datos independiente de la TCB (una tabla hash), con un tamaño limitado y en la que se guarda sólo un subconjunto de datos de los que se guardarían normalmente en la TCB. El acceso sería más rápido que en la TCB.

Se utiliza la información mínima indispensable para poder hacer el hash. Básicamente vamos a tener IP origen, IP destino, puerto origen, puerto destino. Si se completa el handshake y se recibe el ACK, estos datos se copian a la TCB. Se pueden reutilizar los slots más antiguos. Implementado por defecto en FreeBSD. Una entrada ronda los 100 bytes, mientras que en la TCB rondaría los 800. SYN Proxies:

Por ejemplo el Checkpoint SYNDefender. La máquina intercepta todas las conexiones en handshaking de los equipos que se conectan a las máquinas de nuestra organización. Llega un SYN a esa máquina de dentro, la SYN Proxy le responde con un SYN ACK, se le responde con un ACK y el proxy se lo pasa a la máquina en cuestión. El proxy normalmente lo que se hace es IP spoofear la IP a la que se va a conectar.

UDP FLOOD:

Herramienta para hacer flood en UDP. Al contrario que TCP, el protocolo UDP no está orientado a conexión, sin confirmación ni control de flujo. Envío masivo de paquetes a puertos UDP aleatorios. La máquina objetivo comprueba si alguna aplicación está escuchando en ese puerto. Si puerto aleatorio -> ninguna aplicación estará a la escucha. Respuesta con un paquete ICMP Destination Unreachable. Si el número de paquetes enviados (puertos analizados) es suficientemente elevado el destino será incapaz de responder. Podría ser fácil floodear contra los típicos puertos, como el 123 (tcp/udp), el 53 (dns/udp)...

Podemos protegernos de un ataque de este tipo mediante filtrado, que consiste en tratar de filtrar cierta información y ciertos servicios de determinados sitios. https://github.com/nefarius/udpflood

MEDIANTE TTL :

El TTL en las conexiones parte con un determinado valor dependiente del sistema operativo, el cual se va decrementando en 1 cada vez que pasa por un router. Cuando llega a 0, se descarta la paquetería y se devuelve un paquete ICMP de expiración de TTL a la máquina origen. Podemos hacer floodeo de mucha paquetería en reflectivo contra una determinada IP origen inyectando TTL’s pequeñitos contra todo tipo de máquinas y de IP’s por todo Internet. Al ser pequeñito, va a expirar ese TTL y se va a inundar la máquina origen de forma reflectiva con todo tipo de paquetes ICMP de expiración de TTL.

A NIVEL LOCAL:

Spoofeando un router, haciendo que nadie en la red pueda entrar o salir. Spoofeando el propio servidor de DNS, de forma que nadie en la red pudiese resolver por DNS. Con un el plugin isolate del ettercap, que lo que hace es aislar máquinas, routers, por grupos de máquinas, etc, resolviendo por ARP que su MAC es la propia de la máquina que queremos aislar. Floodeando los conmutadores, provocando así una gran degradación de performance. Router Advertisement son paquetes IPv6 que se utilizan para autoconfigurar direcciones de enlace local. Provoca que las CPU de las máquinas se pongan al 100% y después se caigan.

HERRAMIENTAS DE GENERACIÓN O INYECCIÓN DE PAQUETERÍA

PACKIT. Captura e inyecta paquetes. Permite personalización de paquetes TCP, UDP, ICMP, IP, ARP, RARP, Ethernet header. Ejemplos: • •

Envío 2 paquetes udp al puerto 7 (UDP-Echo), falseando IP origen (aleatoria) y mostrando salida por pantalla: packit -t udp -D 7 -sR -d 172.30.0.20 -c 2 -h Envío 2 paquetes tcp con el flag SYN al puerto 22 (ssh), falseando IP origen (aleatoria) y mostrando salida por pantalla: packit -t tcp -D 22 -sR -FS -d 172.30.0.20 -c 2 -h

http://packetfactory.openwall.net/projects/packit/index.html

HPING3. Añade funcionalidades a ping, como el spoofing y la inyección de paquetes. P.e. Envío paquetes TCP con el flag SYN al puerto 80 de todo lo rápido que puede ( --flood) y desde direcciones IP origen aleatorias (--rand-source): hping3 --rand-source -p 80 -S --flood . https://kali-linux.net/article/hping3/

SCAPY. Es capaz de falsificar o decodificar paquetes de una amplia cantidad de protocolos, enviarlos por cable, capturarlos, hacer coincidir solicitudes y respuestas, y mucho más. Puede manejar fácilmente tareas más clásicas como escaneo, rastreo, sondeo, pruebas unitarias, ataques o descubrimiento de red. https://scapy.net/

OTRA CLASIFICACIÓN PARA ATAQUES DOS

FLOODEO O ATAQUE DIRECTO (DIRECT ATTACK) . Es aquel en el que se inyecta directamente desde IP origen (generalmente falsificada) IP destino (el de la máquina objetivo). No se tiene que hacer necesariamente desde nuestra máquina directamente, se puede hacer spoofeando a otras máquinas. Entre el 18% y el 20% de los segmentos de red en internet son IP spoofeables, con lo cual desde esos segmentos se pueden hacer ataques de floodeo directos o reflectivos IP spoofeando la paquetería con IP’s ajenas.

Aquí entran los Ping of Death y los TCP SYN Flood.

ATAQUES POR INUNDACIÓN REFLECTIVOS O REFLECTOR ATTACKS. Se hace inyección de paquetería (que puede ser spoofeada) cuya IP origen es de la máquina que queremos floodear y las IP destino otras máquinas, que responderán e inundarán a la máquina objetivo. Usa nodos intermedios como amplificadores, como pueden ser Routers, Servidores Web, DNS, NTP... Un firewall de control de estado nos puede echar una buena mano contra este tipo de ataques, puesto que no hemos generado nosotros el SYNC, sino que éste viene de fuera, con lo cual el firewall nos puede quitar toda esa paquetería TCP de encima. Tambien se podría hacer floodeo reflectivo pero con tráfico UDP, lo que sería un problema porque implementa un control de estado muy distinto del que tiene TCP.

EJEMPLOS:

SMURF :

Usa paquetes ICMP Echo-Request con IP origen la máquina que quiero floodear e IP destino la dirección broadcast de la red, de forma que le van a responder todas las máquinas.

En nuestras máquinas Debian existen varios ficheros de configuración útiles para evitar estos ataques: o icmp_echo_ignore_broadcasts que por defecto viene a 1, de forma que si les llega un ICMP ping a la dirección de broadcast lo dropean y no le responden, no haciendo esto si estuviera a 0. o icmp_echo_ignore_all que por defecto viene a 0, puesto que si lo pusiéramos a 1 nuestra máquina no respondería al ping que nos haga nuestro compañero, de forma que podría pensar que la máquina está muerta. Nos interesa permitir los pings a nuestra máquina para poder comprobar que está viva. o reverse path filtering (rp_filter) que si queremos activarlo hay que ponerlo a 1 (estudiarlo a fondo en el rfc 3064). Es una herramienta para protección ante ip spoofing. Si lo configuramos en strict mode, cuando un paquete entra por un interface de red, antes de pasarlo a aplicación, se comprueba si el routing de vuelta para responder a esa ip origen es por el mismo interface por el que me entra. Si lo ponemos a 2 (loose mode) nos permite routing asimétrico, de forma que si nos llega un paquete por un interface de red y la respuesta a ese paquete va por otro interface distinto no lo va a dropear como en el modo

anterior. Para más info: https://www.theurbanpenguin.com/rp_filter-and-lpic3-linux-security/

FRAGGLE:

Son exactamente lo mismo que los smurf pero trabajando a nivel UDP, de forma que si existe un firewall de control de estado tendrá muchas más posibilidades de atravesarlo. Para protegernos ante estos ataques podemos configurar nuestros routers para bloquear paquetes de broadcast que no sean de la propia red. El destino será generalmente al servicio chargen (puerto 19) o echo (puerto 7) de la víctima. La inundación ocurriría de la siguiente forma: o Equipos con echo inactivo responderán ICMP Error. o Equipos con echo activo reenviarán paquete a la víctima o Si la víctima tiene servicio chargen activo, entrarán en un bucle infinito con los servidores de echo activo.

FACTOR DE AMPLIFICACIÓN

Un parámetro a tener en cuenta en los ataques DoS es el llamado factor de amplificación, que es la relación entre las tramas recibidas por la víctima por cada trama transmitida por el atacante el cual, definiendo entonces cuántos paquetes van a floodear a la máquina objetivo ante una petición o un paquete. Por ejemplo: • •

Si enviamos un SYNC a un máquina, él recibe uno (factor de amplificación = 1). P.e. en ataques directos como TCP SYN Flood. Si p.e. enviamos un paquete a una dirección de broadcast y en esa red hay 200 máquinas y esas 200 máquinas le responden a la máquina que quiero inundar, ahí tendremos un factor de amplificación de 200. P.e. en ataques reflectivos como SMURF.

ATAQUES DDOS

PARTICIPANTES PRINCIPALES:



Agentes (bots, zombies): o Máquinas intermediarias.

o



Equipos que tras su infección (e.g. malware) son usados por una tercera persona como medio para lanzar un ataque.

Handlers o manejadores: o Programa/servicio encargado del control de los agentes o Especifica a quien atacar, cuando atacar y cómo atacar.

DIMENSIÓN DE BOTNETS:

Los ataques pueden ser controlados de forma remota, como p.e. las botnet que son redes de máquinas infectadas (pueden llegar a tener miles y miles de equipos) y se usan para floodear determinadas máquinas. Habrá un sistema que coordine todos esos equipos infectados, p.e. mediante un canal de chat; tráfico http...; también empezaron a haber otro tipo de botnets que en vez de tener un nodo central son distribuidas como las redes p2p. Ejemplos de botnets: • • •

“Mariposa” (2010) – 13 millones equipos “TDL” (2011) – 4.5 millones equipos “Rustock” (2011) – 2.4 millones de equipos

FASES:

1. Reclutamiento agentes: o Escaneo de puertos, búsqueda de vulnerabilidades, etc. o Troyanos, Spam, etc. 2. Explotación / infección: o Generalmente automatizada. o Máquinas infectadas serán utilizadas para nuevos reclutamientos. 3. Ataque: o Tras la orden del manejador, los agentes serán los encargados del lanzamiento de paquetes.

CÓMO EVITAR ESTOS ATAQUES:

Lo más útil es jugar con el ancho de banda (se le suele llamar traffic shaping o packet shaping), de forma que si determinadas máquinas están pasando mucho tráfico, podemos reducir este ancho de banda para controlarlo. También lo podemos hacer con los firewalls, mediante iptables, haciendo cosas del tipo:

-A INPUT quiere decir que se lo estamos aplicando a los paquetes que entran a la máquina. -p tcp es protocolo tcp --dport 80 puerto destino 80 -m hashlimit carga el módulo hashlimit --hashlimit-burst 400 máximo de 400 paquetes por minuto --haslimit-mode srcip los paquetes que se permiten son por ip origen --hashlimit-upto 50/min si alguna máquina pasa del umbral, le reducimos a 50 paquetes por minuto -m conntrack –cstate NEW -j ACCEPT se permite que se abra una conexión por cada IP en el tiempo que hayamos indicado, con esto se puede evitar un ataque de password guessing, puesto que podriamos hacer que solo se pueda probar una contraseña por minuto. También es útil la infraestructura para evitar estos ataques. Por ejemplo, los balanceadores de carga que distribuyen la carga de peticiones contra distintas plataformas o servidores. También el uso de aceleradores. El tunning de nuestras máquinas, quitando procesos y servicios que no nos interesan. Puede también influir el hardware que tengamos, los RAID, los sistemas de ficheros. Podemos usar stress tools como: • • •

jmeter (https://jmeter.apache.org/) para pruebas de carga y rendimiento. soapUI (https://www.soapui.org/) para pruebas sobre servidores basados en SOAP. thc-ssl-down (https://github.com/azet/thc-tls-dos) para probar el protocolo de enlace SSL.

Para securizar también podemos usar los PVLANs (private LAN): se configura los puertos en capa 2 para securizar una DMZ.

MÓDULOS APACHE

DIRECTORIOS :

• • • •

mods_enable. Tiene los módulos que están cargados y funcionando en ese momento. Enlaces simbólicos a mods_avaliable. mods_avaliable. Tiene el conjunto de módulos disponibles. sites_avaliable. Todo el c...


Similar Free PDFs