Copy Link
Add to Bookmark
Report
SET 030 0x09
-[ 0x05 ]--------------------------------------------------------------------
-[ Hackoot DDoS ]------------------------------------------------------------
-[ by Kirby ]--------------------------------------------------------SET-30--
--== HACKOOT ~DDoS~ ==--
v1.0 por Kirby
---------------------
Indice
---------------------
1.Introduccion
2.Explicacion detallada de los DDoS
2.1.Hackeando una red o pc
2.2.Sin hackear nada
-SmurF
-Fraggle
3.DoS sencillos
4.Tipos de Denegaciones
-SYN flood
-TCP FIN flood
-Connection flood
-Land Atack
-Supernuke/Winnuke
-Teardrop/Newtear
-paquetes fragmentados
-finger bomb
-email bomb
-MAC flooding
-DNS flood
-Bucle UDP/Snork UDP
5.Puntos debiles del SNMP
6.Jugando con los firewalls
7.Paquetes
8.filtros
8.1.ante ICMP
8.2.contra inundacion SYN
9.Prevencion y respuesta
10.Sobre los NIDS (Network Intrusion Detection System)
11.Bastion Hosts
12.Bastion routers
13.Conclusion
----------------
1. Introduccion
----------------
Los ataques DDoS (Distributed Denial of Service), son un desarrollo ya no tan
reciente, pero si muy efectivo para lograr la denegacion de un servicio, y por
eso constituyen una gran amenaza para la seguridad.
Voy a intentar dar una vision del problema, funcionamiento, como se lleva a
cabo, como defendernos... de los DDoS, a fin de minimizar los daños producidos.
El primer encuentro que sabemos con los DDoS (que no quiere decir que fuera la
primera vez) fue en la semana del 7 al 11 de febrero del año 2000. Supongo que
tod@s os acordais de los ataques a Yahoo, Buy.com, eBay, Amazon, Datek, E*Trade
y CNN. Estas empresas se quedaron sin conexion unas horitas.
El problema es el de siempre. Ocultismo. Cierto es que ahora comienza a estar
mas documentada la cosa, pero es un poco pobre la info. En ningun documento
(hasta ahora :P) se daban los suficientes detalles para decir 'ahhhh! claro,
ahora lo entiendo'. Asi que si queda alguna duda despues de leer este tuto, me
mandais un mail (al final teneis mi clave pubica o publica, com querais ñ_ñ).
Entonces tenemos el problema que si no sabemos bien bien que pasa, dudo mucho
que sepamos solventarlo y/o prevenirlo.
El objetivo de un DDoS puede ser cualquiera, como:
-Floodear para que evitar que se conecte a la red.
*Mantienes el PC ocupado mientras spoofeas su IP o MAC...
*Evitas que se conecte a internet porque estas participando en unas
subastas :P
*Estas jugando al Counter, subele el ping xD
-Floodear para anular un servicio especifico.
*No te interesa que una persona, ordenador o servidor mande algun tipo
de info (mail, logs...)
*Solo quieres putear (¬¬')
*Intentas que el NIDS, Firewall o lo que sea, pete y
que te deje tranquilo.
No hay manera de saber si un ataque de este tipo se trata de el principio de
algo mas grande, o si quien lo lanza no quiere nada mas. Es importante tener en
la cabeza, que un DoS y un DDoS no son tecnicas de hackeo. En mas de un sitio he
leido la tonteria que te pueden hackear con un DoS, no tiene sentido.
El proceso esta compuesto de 4 pasos principales:
1) Fase de escaneo con un conjunto objetivo de sistemas muy elevado, 100.000 o
mas. Se prueban estos frente a una vulnerabilidad conocida.
2) Se obtiene acceso a parte de esos sistemas a traves de la vulnerabilidad.
3) Se instala la herramienta de DDoS en cada sistema comprometido.
4) Se utilizan estos sistemas para escanear y comprometer nuevos sistemas.
Se podrian realizar estos 4 pasos a mano, pero lo mas eficiente, rapido, y
anonimo, es un gusanito multiplataforma que haga el trabajo por ti.
------------------------------------
2. Explicacion detallada de los DDoS
------------------------------------
Un DDoS involucra a muchos ordenadores (mientras mas mejor). Y se puede
llevar a cabo de varias formas:
1. Hackeando una red
a. Instalando soft especifico para un DDoS
b. no instalar nada
2. Sin hackear nada
a. Smurf --> TCP
b. Fraggle --> UDP
Este esquema nos esta diciendo que si hackeamos una red (u ordenador),
podemos meter un software especifico para lanzar ataques o hacerlo
manualmente (deberiamos acceder a cada ordenador y decirles uno a uno
que debe hacer). Lo mejor desde el punto de vista del atacante es usar
un software, que consta de master/agente (el clasico cliente/servidor).
De esta forma, lanza el ataque masificado controlandolo todo desde un
ordenador. Si no fuera porque dentro de un tiempo las empresas de telefonia
quitaran las targetas de prepago para ser todo bajo contrato, habria
salido la forma de lanzar un DDoS utilizando el movil en un futuro
(que es todo lo animo que quieras, o casi).
Las consecuencias suelen ser el ahogo del ancho de banda, o del router o de los
recursos de la pila de red... siempre se pretende denegar algun recurso.
2.1.Hackeando una red o pc
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Como es logico el primer paso sera hackear ordenadores, con ayuda
de exploits, ing social, malas configuraciones y demas tecnicas.
Despues se procederia a subir privilegios y a instalar un rootkit a fin de
ocultar los procesos pertinentes, puertos, etc y se borrarian o modificarian los
logs. Y dependiendo del sistema operativo en el que nos encontramos utilizaremos
un programa u otro como agente.
Repitiendo varias veces estos pasos, conseguiremos tener la suficiente
artilleria como para reproducir esos gigabytes por segundo del ataque a Yahoo,
segun datos del SANS (se utilizaron miles de ordenadores).
Okis, ahora toca el ataque. El atacante puede hacer varias cosas; entrar PC a PC
con el backdoor que tenga puesto y ejecutar el ataque (un bucle ping, el DoS
Pepsi-win, cualquier cosa sirve). Despues saldria del ordenador comprometido
(mientras se esta lanzando el ataque) e iria haciendo lo mismo en cada ordenador
que tenga hackeado. Esto, a parte de ser un trabajo pesado, el ataque se hace
mas lento.
La otra opcion mas inteligente seria dar los parametros necesarios al master, y
todos los ordenadores harian lo que se le ha pedido. Es decir, que con tan solo
un par de instrucciones, podemos controlar muuuuuuchas maquinas. Este ataque, se
ha de hacer muy bien, ya que si te dejas algun log en alguna maquina, comienza a
preocuparte. Tambien has de estar concienciado que todos esos servidores que has
hackeado, los vas a perder. Porque cuando denuncien (si lo hacen) investigaran
los servidores involucrados, y tal vez esperen a que te vuelvas a conectar a
alguno de ellos para snifarte y pillarte.
*----------*
| |
| Atacante |
| |
*----------*
|
|<--- Bouncer ;)
|
*----------*
| |
| Master |
| |
*----------*
|
(comandos a los agentes)
|
*------------*------*------*------------*
| | | | paquetes!
| | | |
v v v v
*----------* *----------* *----------* *----------*
| | | | | | | |
| agente | | agente | | agente | | agente |
| | | | | | | |
*----------* *----------* *----------* *----------*
\ \ / /
\ \ / /
\ \ / /
\(Cualquier tipo de flood)/
\ \ / /
\ \ / /
\ \ / /
V V V
*-----------------------*
| |
| Victima |
| |
*-----------------------*
Los terminos paquete y datagrama suelen parecer intercambiables, pero no.
Conceptualmente, un paquete es la unidad fisica de mas bajo nivel, mientras que
datagrama se refiere a la unidad de datos a nivel IP. Sin embargo, en la mayoria
de las redes no se puede distinguir porque coinciden, asi que la gente suele
usar los dos terminos indistitivamente.
2.2.Sin hackear nada
^^^^^^^^^^^^^^^^^^^^
-*-SmurF-*-
Ping --> Internet Control Message Protocol (ICMP). La administracion de redes
abarca un amplio numero de temas. En general, se suelen tratar con muchos
datos estadisticos e informacion sobre el estado de distintas partes de la red,
y se realizan las acciones necesarias para ocuparse de fallos y otros cambios.
La tecnica mas primitiva para la monitorizacion de una red es hacer 'pinging' a
los host criticos; el 'pinging' se basa en un datagrama de 'echo' (eco), que es
un tipo de datagrama que produce una replica inmediata cuando llega al destino.
La mayoria de implementaciones TCP/IP incluyen un programa (normalmente llamado
'ping') que envia un echo a un host en concreto. Si recibimos replica, sabremos
que host se encuentra activo, y que la red que los conecta funciona; en caso
contrario sabremos que hay algun error. Pues bien, sumemos miles y miles de este
datagrama. El resultado es predecible.
Existen tecnicas basadas en ICMP, pero NO en los paquetes de tipo echo. Podrian
considerarse tecnicas tanto de ICMP sweep como de ICMP broadcast, pero con otros
tipos de paquetes ICMP, no echo. Estos paquetes se van a a analizar a continuacion:
- ICMP Timestamp:
Mediante el envio de un paquete ICMP de tipo timestamp, si un sistema esta
activo, se recibira un paquete de timestamp indicando que implementa
este tipo de transferencia de informacion que permite conocer la referencia de
tiempo en el sistema destino. Tal y como denota el RFC 1122, la decision de
responder a estos paquetes depende de la implementacion. Algunos sistemas
Windows si responden mientras que otros no, sin embargo la mayoria de los Unix
si que lo implementan.
- ICMP Information:
El proposito de los paquetes ICMP de informacion y su respuesta asociada,
information reply, es permitir que ciertos equipos que no poseian disco del que
extraer su propia configuracion, pudieran autoconfigurarse en el momento de su
arranque, principalmente para obtener su direccion IP. En el paquete, tanto la
direccion origen como destino tienen el valor cero. Tanto el RFC 1122 como el
1812 indican que los sistemas no deberian generar ni responder a este tipo de
paquetes, pero la realidad de las implementaciones existentes es otra. Algunos
sistemas operativos responderan cuando la direccion IP destino del paquete tiene
el valor de una direccion IP especifica. En la respuesta, en lugar de tener la
direccion IP de la red en el campo de direccion origen, se tiene la direccion IP
del host. Algunos UNIX comerciales y equipos Cisco implementan la respuesta ante
este tipo de paquetes.
- ICMP Address Mask:
El proposito de los paquetes de tipo address mask y address mask reply,
era que los equipos o estaciones de trabajo sin disco pudiesen obtener la
mascara de red asociada a la subred en la que estaban conectados en el momento
de arrancar. Se supone que un sistema no deberia responder con un paquete de
este tipo salvo que fuera un agente autorizado para notificar la mascara,
tipicamente el router de la subred.
Una red se puede proteger frente a este ataque si los firewalls o screening
routers se encargan de verificar y descartar este tipo de errores, no
permitiendo este tipo de trafico. Asimismo, si el dispositivo de filtrado no
implementa esta caracteristica, es posible filtrar los paquetes ICMP Parameter
Problem en su camino de vuelta. Existe una herramienta, ISIC: IP Stack Integrity
Check, de Mike Frantzen (http://www.packetfactory.net/Projects/ISIC) disponible
para este tipo de pruebas, que permite poner a prueba la pila TCP/IP, encontrar
debilidades en un firewall, y comprobar la implementacion de firewalls e IDS.
Permite especificar si los paquetes se fragmentan, sus opciones IP, las opciones
TCP y el bit URG.
Existe un tipo de DDoS denominado SmurF que amplifica considerablemente los
efectos de un ataque ICMP. En el SmurF el atacante dirige paquetes ICMP echo
request a una direccion IP de broadcast.
Existen tres partes en un ataque SmurF: El atacante, el broadcast y la victima.
La direccion logica de broadcast, es decir, aquella que representa a todas las
maquinas de una red, se utiliza en algunos protocolos para localizar el sistema
que proporciona un servicio concreto de forma sencilla, es decir, preguntando a
la red, y no consultando uno por uno a todos los sistemas existentes. Si esta
direccion se encuentra disponible tambien para usuarios externos a la red, es
posible que un atacante pueda enviar un paquete de datos a la misma, provocando
que todos los sistemas pertenecientes a dicha red respondan simultaneamente,
aumentando la potencia de la respuesta en un factor de N, siendo N el numero de
maquinas disponibles en la red. Es decir, se realiza un ataque a una red desde
otra red intermedia que permite multiplicar los recursos existentes (elementos
validos para desarrollar ataques DDoS). Este metodo no implica tener que
controlar las redes empleadas como multiplicadoras del efecto de ataque. Si se
auna esta tecnica junto a la de IP spoofing, al enviar un paquete ICMP con la
direccion IP origen de la maquina a atacar y direccion IP destino la direccion
de broadcast de una red con un elevado numero de maquinas, digamos cientos,
todas las respuestas de la red de broadcast se dirigiran realmente a la
direccion IP del sistema 'spoofeado'.
Aunque no es tan sencillo :P El primer router que recive el paquete puede ver
que la direccion IP origen esta spoofeada. Puesto que el router conoce que rango
de IPs pueden salir por el. Este es el gran problema. Solo has de mirar si tu
ISP permite IP spoofing. Si no te deja, encuentra un servidor desde el que se
permita, y lanza el ataque desde ahi.
Generalmente, la IP del broadcast tiene unos octetos definiendo la clase de red,
y los demas tienen el mismo bit. Por ejemplo para una red 10.0.0.0 es
10.255.255.255. Si tuvieramos una subred de clase A con 256 subredes, el
broadcast para 10.50 seria 10.50.255.255. La direccion del estilo 10.50.0.0
puede producir una respuesta broadcast.
+--------+ +-----------------+
| | +---------------+===I====> | |
| | | |===C=====>| |
-a--| ISP +------+ Broadcast +===M=====>| www.victima.com |
| | | 20 PCs |===P=====>+-----------------+
| | +---------------+
+--------+
El ordenador 'a' manda un echo haciendose pasar por www.victima.com, y como su
ISP permite el spoofeo, el ataque SmurF se realiza con exito.
-*-Fraggle-*-
Es lo mismo que el SmurF pero utilizando datagramas UDP.
---------------
3.DoS sencillos
---------------
Logica poca, pero bueno, siempre hay algun bicho raro por ahi...
Solo enumero algunos, para saber que existen, pero no tienen la belleza del DDoS
ñ_ñ
* X-Servers:
Es facil tirar un X-Server. Si el StickyBit no esta puesto en
el directorio /tmp.. borrando el archivo /tmp/.X11/x0 o
/tmp/.x11-unix/x0 (normalmente los directorios son estos 2 .X11 o
.x11-unix)
* Creando multiples procesos:
#include <sys/types.h>
#include <unistd.h>
#include <iostream.h>
main()
{
while(1)
{
system("sync");
fork();
}
}
* Linux & Time service:
El InetD en linux se viene abajo si se envian muchos paketes SYN
a los puertos time-37 o daytime-13
------------------------
4.Tipos de Denegaciones
------------------------
Syn Flood
^^^^^^^^^
Cuando dos procesos establecen una comunicacion usan el modelo Cliente/Servidor
para establecer la conexion. La aplicacion del Servidor 'escucha' todo lo que
mandan por los puertos. La identificacion del Servidor se efectua a traves de
la direccion IP del sistema en el que se ejecuta y del numero de puerto del que
depende para la conexion. El Cliente establece la conexion con el Servidor a
traves del puerto disponible para luego intercambiar datos.
La informacion de control llamada HandShake (saludo) se intercambia entre el
Cliente y el Servidor para establecer un dialogo antes de transmitir datos.
Los paquetes o segmentos TCP tienen banderas que indican el estado del mismo.
El protocolo TCP de Internet, sobre el que se basa la mayoria de los servicios
(incluyendo el correo electronico, el web y el IRC) implica esta conexion entre
dos maquinas. El establecimiento de dicha conexion se realiza mediante lo que se
llama Three-Way Handshake ('conexion en tres pasos') ya que intercambian tres
segmentos. En forma esquematica se tiene:
1. El programa Cliente (C) pide conexion al Servidor (S) enviandole un segmento
SYN (Synchronize Sequence Number). Este segmento le dice a S que C desea
establecer una conexion.
2. S (si esta abierto y escuchando) al recibir este segmento SYN (activa su
indicador SYN) y envia una autentificacion ACK a modo de acuse de recibo a C.
Si S esta cerrado envia un indicador RST.
3. C entonces ACKea (autentifica) a S. Ahora ya puede tener lugar la
transferencia de datos.
Cuando las aplicaciones conectadas terminan la transferencia, realizaran otra
negociacion a tres bandas con segmentos FIN en vez SYN.
La tecnica TCP SYN flooding, implementa un flood de 'media-apertura', dado que
nunca se abre una sesion TCP completa. El Cliente envia un paquete SYN pero no
responde al paquete ACK ocasionando que la pila TCP/IP espere cierta cantidad de
tiempo a que el host hostil responda antes de cerrar la conexion. Si se crean
muchas peticiones incompletas de conexion (no se responde a ninguna), el
Servidor estara inactivo mucho tiempo esperando respuesta. Esto ocasiona la
lentitud en los demas servicios. Se puede ver el numero de conexiones SYN_RECV
de un sistema utilizando el netstat.
El problema es que muchos sistemas operativos tienen un limite muy bajo en el
numero de conexiones semiabiertas que pueden manejar en un momento
determinado. Si se supera ese limite, el servidor sencillamente dejara de
responder a las nuevas peticiones de conexion que le vayan llegando. Las
conexiones semiabiertas van caducando tras un tiempo, liberando 'huecos' para
nuevas conexiones, pero mientras el atacante mantenga el Syn Flood, la
probabilidad de que una conexion recien liberada sea capturada por un nuevo SYN
malicioso es muy alta.
La potencia de este ataque reside en que muchos sistemas operativos fijan un
limite del orden de 5 a 30 conexiones 'semiabiertas', y que estas caducan alcabo
de un par de minutos. Para mantener el servidor fuera de servicio, un atacante
solo necesita enviar un paquete SYN cada 4 segundos (algo al alcance de,
incluso, un modem de 300 baudios).
La principal ventaja de esta tecnica es que pocos sitios estan preparados para
detecarlos, con lo que el firewall no los pararia. La desventaja es que en
algunos sistemas Unix, se necesita ser root para construir estos paquetes SYN.
TCP FIN Flooding
^^^^^^^^^^^^^^^^
Puede pasar que no te interese que algun tipo de filtro detecte los paquetes
SYN. Esto es logico si tenemos pocas maquinas desde las que atacar, si a eso le
sumamos que el firewall de la victima nos para los pocos paquetes, tal vez
consumamos algo de ancho de banda... pero poco mas. Asi que si conseguimos
saltarnos el firewall, esos pocos paquetes iran al corazon de la pila de red.
Para subsanar este inconveniente los paquetes FIN. Este tipo de flood esta
basado en la idea de que los puertos cerrados tienden a responder a los paquetes
FIN con el RST correspondiente. Los puertos abiertos, en cambio, suelen ignorar
el paquete en cuestion.
Este es un comportamiento correcto del protocolo TCP, aunque algunos sistemas
(entre los que se hallan los de Microsoft) no cumplen con este requerimiento,
enviando paquetes RST siempre, independientemente de si el puerto esta abierto o
cerrado.
Este ultimo es un ejemplo en el que se puede apreciar que algunas
vulnerabilidades se presentan en las aplicacion de tecnologias (en este caso el
protocolo TCP nacido en los años ´70) y no sobre sus implementaciones. Es mas,
se observa que una implementacion incorrecta (la de Microsoft) soluciona el
problema. 'Muchos de los problemas globales de vulnerabilidades son inherentes
al disño original de algunos protocolos'.
Como ya se explico en el TCP SYN Flooding el protocolo TCP se basa en una
conexion en tres pasos. Si el paso final no llega a establecerse, la conexion
permanece en un estado denominado 'semiabierto'.
Antes de utilizar esta tecnica convendria averiguar el comportamiento de la
victima ante un FIN a un puerto abierto y a uno cerrado. Y despues, segun lo
que pase, combinar, adaptar y crear paquetes al gusto del consumidor.
Connection Flood
^^^^^^^^^^^^^^^^
Los servicios TCP orientados a conexion, que son la mayoria (telnet, ftp, http,
smtp, nntp...) tienen un limite maximo de conexiones simultaneas soportadas;
cuando este limite se alcanza, cualquier conexion nueva es rechazada.
De forma similar al Syn Flood, si un atacante es capaz de monopolizar el limite
definido con conexiones de su propiedad, que simplemente son establecidas pero
por las que no se realiza ninguna comunicacion posterior, el sistema no
proporcionara servicio.
Al igual que antes, las conexiones expiran progresivamente con el paso del
tiempo, pero un ataque constante de apertura de conexiones mantendra
continuamente el limite en su valor maximo. La diferencia esta en que en este
caso la conexion se ha establecido y por tanto se conoce la identidad del
atacante (direccion IP), y a su vez, la capacidad del sistema o sistemas
atacante/s debe ser lo suficientemente elevada como para mantener abiertas todas
las sesiones que colapsan el servidor atacado.
Existe una variante de estos ataques basada en el uso de un cliente que
establezca conexiones contra un sistema, pero que no las finalice de forma
correcta, de modo que en el servidor los sockets correspondientes a estas
comunicaciones seguiran estando activos y consumiendo recursos, concretamente en
el estado TCP denominado TIME_WAIT.
Para evitar la existencia de un ataque basado en el cierre incorrecto de las
conexiones, el sistema servidor puede controlar el tiempo que un socket TCP
puede permanecer en el estado TIME_WAIT, evitando asi un consumo de recursos
excesivo.
- HP-UX y Solaris:
Para ello se emplea el siguiente comando limitando el tiempo a 60 segundos:
ndd set /dev/tcp tcp_time_wait_interval 60000
- Linux (2.2):
Igualmente, se limita el tiempo de vida del socket en este estado:
/sbin/sysctl w net.ipv4.vs.timeout_timewait 60000
- Linux (2.4):
En este caso, se limita el numero de sockets en este estado. En el caso de que
se supere el numero, se destruiran sockets en ese estado, generandose un
warning:
# echo 512 > /proc/sys/net/ipv4/tcp_max_tw_buckets
- Windows NT, 2000, XP:
A traves del editor del registro (regedt32.exe) debe localizarse la clave:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Bajo la misma es necesario añadir el valor:
Value Name: TcpTimedWaitDelay
Data Type: REG_DWORD
Value: 30-300 segundos (defecto: 240 segundos)
Land Attack
^^^^^^^^^^^
Este ataque permite bloquear un sistema, mediante el envio de un
paquete SYN cuya direccion IP fuente y destino es la misma. Existe una variacion
de este ataque, basada en que los puertos origen y destino tambien son iguales.
Para ello es necesario enviar paquetes IP mediante la tecnica de spoofing.
Debe tenerse en cuenta que algunos sistemas IDS detectan la primera situacion y
otros la segunda. Por tanto, podria darse algun caso en el que se establezca una
conexion a la propia maquina, se envie por tanto un paquete
[127.0.0.1:puerto_cliente ==> 127.0.0.1:puerto_servidor], y el sistema IDS lo
detecte como un ataque cuando en realidad no lo es. Este ejemplo, aplicable a un
gran numero de las vulnerabilidades mencionadas, refleja la estrecha linea
existente entre un ataque real y una situacion convencional, denotando que su
deteccion y automatizacion no es trivial.
Este ataque se puede prevenir filtrando los paquetes recibidos cuya direccion de
origen sea la misma que la de alguno de los ordenadores de la red interna.
Supernuke o Winnuke
^^^^^^^^^^^^^^^^^^^
Un ataque caracteristico (y quizas el mas comun) de los equipos con Windows
es el Nuke, que se aprovecha del error llamado 'Windows OOB bug'. OOB significa
out-of-band.
Este DoS funciona de la siguiente manera: se establece una conexion TCP/IP con
la direccion de destino, usando el puerto 139 (el puerto de NetBIOS). Despues el
programa envia los datos empleando una marca llamada MSG_OOB (o Urgente) en el
encabezamiento del paquete, que indica al Winsock del ordenador que envie los
datos llamados 'datos fuera de banda' (out-of-band-data). Tras la recepcion de
esta marca, el servidor Windows al que se ha dirigido espera una indicacion de
la posicion del paquete, en la que terminan los datos urgentes a los que deben
seguir los datos normales, pero el indicador OOB del paquete, creado por
WinNuke, indicara el final del marco, donde no encontrara datos que sigan a los
datos urgentes. Con todo ello, lo que se provoca es que la maquina Windows no
sepa como enfrentarse al problema e interrumpe la comunicacion de la red,
produciendose de esta forma una denegacion del servicio a todos los usuarios que
intentan comunicarse con el servidor.
Un ataque WinNuke suele exigir el reinicio del ordenador para asi poder
restablecer la comunicacion con la red.
Tanto Windows 95 como NT 3.51 y 4.0 son vulnerables a estos ataques, a menos que
se instalen los parches proporcionados por Microsoft, mientras que Windows 98/ME
y 2000/XP no son vulnerables a este ataque. Desgraciadamente aun quedan
muchas redes en las que se usan los sistemas operativos mas antiguos de
Microsoft, y muchas veces no se han aplicado las actualizaciones y los paquetes
de servicio correspondientes.
Teardrop I y II/Newtear-Bonk-Boink
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Al igual que el Supernuke, los ataques Teardrop I y Teardrop II afectan a
fragmentos de paquetes. Algunas implementaciones de colas IP no vuelven a armar
correctamente los fragmentos que se superponen, haciendo que el sistema se
cuelgue. El problema es que los campos de desfase de estos fragmentos, que se
supone que indican la porcion (en bytes) del paquete original que contiene cada
uno de los fragmentos, se pueden superponer.
Windows NT 4.0 de Microsoft es especialmente vulnerable a este
ataque. Aunque existen parches que pueden aplicarse para solucionar el
problema, muchas organizaciones no lo hacen, y las consecuencias pueden
devastadoras.
Los ataques tipo Teardrop son especialmente peligrosos ya que existen multitud
de implementaciones (algunas de ellas forman paquetes), que explotan esta
debilidad. Las mas conocidas son aquellas con el nombre Newtear, TearDrop2,
SynDrop, Bonk y Boink.
Por ejemplo, normalmente los campos de desfase de dos fragmentos pueden aparecer
de la siguiente forma:
Fragment 1: (offset) 100 - 300
Fragment 2: (offset) 301 - 600
Esto indica que el primer fragmento contiene los bytes del 100 al 300 del
paquete original, mientras que el seguno contiene los bytes del 301 al 600.
Sin embargo, los campos de superpuestos suelen tener esta forma:
Fragment 1: (offset) 100 - 300
Fragment 2: (offset) 200 - 400
Cuando el ordenador de destino intenta volver a montar estos paquetes, no puede
conseguirlo, provocandose un cuelgue o reinicio del ordenador.
Paquetes fragmentados
^^^^^^^^^^^^^^^^^^^^^
Esta tecnica es una modificacion de las anteriores. En lugar de enviar paquetes
completos, particionamos en un par de pequeños fragmentos IP. Asi, se logra
partir una cabecera IP en distintos paquetes para hacerlo mas dificil de
monitorizar por los filtros que pudieran estar ejecutandose en la maquina
objetivo. Haciendo que se sobrecargue el sistema del a victima.
Existen dos formas de afrontarlo:
- Metodo directo:
Existe un valor TMIN que indica la longitud minima de la cabecera TCP requerida
para contener toda la informacion de transporte relevante, desde el punto de
vista de los filtros de paquetes. La medida se toma desde el comienzo de la
cabecera TCP en el paquete original (sin fragmentar). El control se basa en
analizar los paquetes con un offset de cero frente a este valor, para no
permitir paquetes con un valor de TMIN menor.
- Metodo indirecto:
Este se basa en el analisis de un paquete TCP, de forma que cuando es
fragmentado, si los campos que definen los flags no se encuentran en el paquete
inicial, este se deja pasar, pero al recibirse el siguiente fragmento, en base
al campo FO, Fragment Offset, se descarta, con lo cual se bloquea el proceso de
reconstruccion del paquete original.
Finger Bomb
^^^^^^^^^^^
La mayoria de las instalaciones de fingerd dejan redireccionar a otro host.
Ejemplo:
$finger @sistema.dos.com@sistema.uno.com
Finger en el ejemplo tendra que ir a traves del sistema.uno.com y despues al
sistema.dos.com. Todo lo que el sistema.dos.com sabe es que el
sistema.uno.com esta contactandole usando finger. Este metodo puede ser usado
para esconderte, pero tambien para hacer uso de un truco sucio. Ejemplo:
$ finger @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@host.que.atacamos.com
Todos esos signos @ ocasionaran que finger llame a host.que.atacamos.com una
y otra vez. El efecto es desastroso para host.que.atacamos.com resultando
en un alto uso del ancho de banda y falta de memoria debido a todos los procesos
creados.
La solucion es instalar un fingerd que no soporte redirecciones, por ejemplo
el finger GNU. Tambien puedes desinstalar el servicio finger.
Email Bombing
^^^^^^^^^^^^^
En un ataque de email se envian muchos mensajes identicos a una o varias
direcciones del host. El efecto en el objetivo es un alto uso del ancho de banda
y menos espacio de disco. Cuando envias muchos mensajes a una direccion
inexistente del host desde otra inexistente, el mensaje crecera debido a las
cabeceras. Ira de un lado a otro creciendo. Por mas odioso que se vea este
ataque es bastante efectivo y aun no es ilegal en muchos paises latinoamericanos
y europeos.
Ejemplo:
Envia un mail de 100k a noexiste@host.atacado.com desde una direccion que
no exista como noexiste@esta.direccion.zus
Cuando el mensaje llege a host.atacado.com como no existe la direccion
noexiste regresara el mensaje a noexiste@esta.direccion.zus y como esta
direccion tampoco existe, regresara ahora como un mensaje de 300k y asi...
Si lo haces con dos cuentas del mismo servidor, todo sera mas rapido
(y menos doloroso :P).
Otra forma de abusar el email y servidores norteamericanos es juntar varios
remailers. Por ejemplo:
Suponiendo que tenemos nosotros una cuenta en Geocities. Digamos
uno@geocities.com y le decimos que queremos que el mail que llegue a esa
direccion lo mande a dos@bigfoot.com. Ahora en la cuenta dos@bigfoot.com
le decimos que lo mande a tres@iname.com. Y en la cuenta tres@iname.com le
decimos que lo mande a uno@geocities.com. Despues mandamos un mega o dos
a uno@geocities.com que lo mandara a dos@bigfoot.com y de ahi a
tres@iname.com y de nuevo a uno@geocities.com... Si mandas 5 megas a saber
que puede pasar!
MAC flooding
^^^^^^^^^^^^
Esta tecnica intenta colgar o reiniciar los perifericos de red (routers por ejemplo)
inundandon las tablas con MACs falsas.
DNS flood
^^^^^^^^^
El ataque DNS flood saca partido de las diferencias de tamaño entre una
solicitud DNS y su respuesta, haciendo que todo el ancho de banda de la red este
atascado por falsas respuestas DNS. El atacante utiliza los servidores DNS como
amplificadores, para multiplicar el trafico DNS.
El atacante comienza enviando pequeñas solicitudes DNS, que contienen la
direccion IP spoofeada de la victima, a cada servidor DNS. Las respuestas
devueltas a las pequeñas peticiones son mucho mayores que si se devolvieran
muchas respuestas al mismo tiempo, congestionandose el vinculo y produciendose
la negacion de servicio.
Una de las soluciones para este problema es que los administradores configuren
los servidores DNS para responder con una respuesta de 'rechazado', que tiene un
tamaño mucho menor que una respuesta de resolucion de nombre, cuando reciben las
solicitudes DNS de fuentes sospechosas o inesperadas.
Bucle UDP/Snork UDP
^^^^^^^^^^^^^^^^^^^
Un atacante puede utilizar el Protocolo de Datagrama de Usuario (User Datagram
Protocol :P) y uno de los muchos servicios que responden a los paquetes que
reciben para crear una congestion en la red, generando un flujo de paquetes UDP
entre uno o dos sistemas escogidos.
Por ejemplo, el servicio chargen del primer ordenador, que es una herramienta de
pruebas que genera una serie de caracteres por cada uno de los paquetes que
recibe, envia paquetes al servicio de eco UDP de otro sistema, que responde a
cada uno de los caracteres que recibe. El chargen UDP se encuentra en el puerto
19. Al aprovechar estas herramientas de pruebas se consigue un flujo
interminable de ecos entre y salga de los dos sistemas, floodeando la red.
A este proceso tambien se le suele llamar tormenta de paquetes UDP o bomba UDP.
Ademas del puerto 7 (el puerto del eco), un atacante puede utilizar el puerto
17, el servicio de la cita del dia (quotd) o bien el servicio del dia del puerto
13, servicios que tambien responden con ecos a los paquetes que reciben. La
desactivacion de los servicios UDP innecesarios en cada uno de los ordenadores
nos protegera de este ataque. Filtrar los puertos con un firewall no ayudaria
mucho, mas abajo explico alguna de las formas de saltarse los firewalls.
El ataque Snork es similar al bucle UDP. Emplea un marco UDP en el que el puerto
de origen puede ser el 7 (echo) o el 9 (chargen) y el puerto de destino es el
135 (servicio de localizacion de Microsoft). Con ello se consigue el mismo
resultado que con el bucle UDP, un flujo de transmisiones basura que reduce el
rendimiento o hace que el/los sistema/s quede/n anulado/s.
-------------------------
5.Puntos debiles del SNMP
-------------------------
SNMP se utiliza para controlar los dispositivos de la red y administrarlas. Se
trata de un grupo de protocolos que envian mensajes llamados Unidades de datos
de protocolo (PDU, Protocol Data Units) a traves de la red, hasta diversos
dispositivos o maquinas que disponen de un software agente SNMP instalado. Estos
agentes mantienen Management Information Bases (MIBs, no son los Men In Black
:P) que contienen informacion sobre cada uno de los dispositivos. Cuando los
agentes reciben los PDU, responden con la informacion contenida en las MIB.
En algunas instalaciones de SNMP se han descubierto puntos debiles que
proporcionan a los atacantes una via para desactivar dispositivos de la red.
-------------------------------
6.Ataques de enrutado de origen
-------------------------------
TCP/IP admite el enrutado de origen (source routing), que es un medio de
permitir que el emisor nos dirija los paquetes a traves de un punto concreto de
la red. Hay dos tipos de enrutado de origen:
-Enrutado de origen estricto
El emisor de los datos puede especificar la ruta exacta (no se
suele usar mucho)
-Registro de ruta de origen flexible (LSRR, Loose Source Record Route)
El emisor puede especificar ciertos routers por los que debe
pasar el paquete.
El enrutado de origen es una opcion del encabezamiento IP que permite que el
emisor anule las decisiones de enrutado que se suelen tomar en el router que
encuentra el paquete entre el origen y el destino final. Los administradores de
redes lo utilizan para realizar un mapa de la red o para resolver problemas en
las comunicaciones o el enrutado.
Si el sistema permite el enrutado de origen, este puede ser usado por cualquier
intruso para alcanzar direcciones internas privadas de la LAN, que normalmente
no estarian a su alcance desde Internet, enruntando el trafico a traves de otra
maquina a la que si se puede acceder desde Internet o desde una paquina interna.
El enrutado de origen puede desactivarse, en la mayor parte de los routers para
evitar este tipo de ataques.
Para vulnerar RIP, como se especifica a continuacion, es necesario inicialmente
identificar un router que hable este protocolo a traves de la identificacion del
puerto UDP 520. En el caso de pertenecer al mismo segmento de red, deben
escucharse las actualizaciones RIP que circulan por la red o solicitarselas
directamente a alguno de los routers. De esta forma se obtendra la tabla de
rutas que se anuncia en ese momento. Si no se esta en el mismo segmento, se
dispone de herramientas como rprobe para realizar una peticion RIP remota: el
resultado se obtendra mediante un sniffer en el sistema desde el que se ataca.
Una vez definida la informacion que se pretende inyectar en la tabla de rutas
anunciada, por ejemplo, redireccionar todo el trafico a un sistema desde el que
se pueda analizar el mismo, mediante utilidades como srip, se inyectara la ruta
deseada. A partir de ese momento todo el flujo de trafico pasara por el nuevo
camino definido. Para que el funcionamiento habitual no se vea modificado, es
necesario que el nuevo sistema al que van destinado los paquetes los
redireccione consecuentemente: ip forwarding.
El primer ejemplo de configuracion de este tipo se aplica a la capacidad de los
kernels para hacer routing entre varios interfaces. esta se configura como
sigue:
- En HP-UX basta con introducir en el fichero /etc/rc.config.d/nddconf:
TRANSPORT_NAME[1]=ip
NDD_NAME[1]=ip_forwarding
NDD_VALUE[1]=1
- En Solaris basta con ejecutar mediante ndd en un script de arranque:
ndd set /dev/ip ip_forwarding 0
- En Linux, se debe añadir tambien en un script de arranque:
echo 1 > /proc/sys/net/ipv4/ip_forward
En el caso de Linux es posible especificar los parametros en el fichero
/etc/sysctl.conf (p.ej., Red Hat) que es cargado por la utilidad /sbin/sysctl.
La documentacion al respecto se encuentra en el directorio /Documentation del
kernel, en el fichero proc.txt.
- En Windows las modificaciones se realizan a traves del editor del registro
(regedt32.exe); para ello debe localizarse la clave:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Bajo la misma es necesario añadir el valor:
Value Name: IPForwarding
Data Type: REG_DWORD
Value: 1
--------------------------------------------------------
6.Jugando con los Firewalls y herramientas automatizadas
--------------------------------------------------------
Que pasa si la victima dispone de una politica de seguridad bien definida, y su
firewall banea las IPs desde las que atacamos. Pues podemos reirnos de el de
varias formas ñ_ñ:
-Atacarle haciendonos pasar por la IP del DNS (para que lo banee)
-Atacarle haciendonos pasar por su gateway
-Atacarle mandando los paquetes hacia el puerto 53 (nos saltaremos el
firewall)
-Construir paquetes de nivel 7
-Mandar los paquetes a algun puerto abierto publicamente (no protegido)
Esto es lo mismo que dice un amigo mio: 'depende de que errores quieras,
intalate un Windows u otro'. Todo depende de que resultado te guste mas.
*----------* *----------* *----------* *----------*
| | | | | | | |
| agente | | agente | | agente | | agente |
| | | | | | | |
*----------* *----------* *----------* *----------*
\ \ / /
\ \ / /
\ \ / /
\ \ / /
\ \ / /
\ \ / /
\ \ / /
V V V
*-----------------------*
D <----- | |-----> D
E <----- | Firewall |-----> E
N <----- | |-----> N
Y *-----------------------* Y
|
???
|
*--------*
| |
| PC |
| |
*--------*
Tenemos aqui un ordenador que hace la funcion de firewall, conectado al
ordenador de trabajo habitual. Como podemos ver, el firewall rechaza los
paquetes. Es un firewall propietario muy caro y muy bueno, pero esta tan ocupado
rechanzando paquetes de la congestionada red, que el PC no navegara.
Otra cosa graciosa es que algunos sistemas desactivan cuentas al cabo de cierto
numero de intentos de login incorrectos (lo dejo en el aire, jurjur)
----------
7.PAQUETES
----------
A estas alturas mas de uno se debe de estar preguntando como es un paquete, que
forma tiene, si tiene patas o no... a eso vamos ahora.
Hay herramientas que sirven para mirar que paquetes entran y salen de tu
ordenador, para Linux el mas tipico es 'tcpdump'. Estos programas se llaman
packet sniffers.
La cabecera de cada paquete es filosofico, nos dice a donde va, de donde viene,
el tipo de paquete...
El resto del paquete contiene los datos a transmitir, es el cuerpo del paquete.
Asi que como acabamos de decir, todos los paquetes IP comienzan con una cabecera
(de al menos 20 bytes de longitud).
Diagrama del RFC 790:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Tipo de Servic.| Tamaño Total |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identificacion |Flags| Desplaz. del Fragmento |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Tiempo de Vida | Protocolo | Checksum de la cabecera |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Direccion de Origen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Direccion de Destino |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version: 4 bits.
Este campo describe el formato de la cabecera utilizada. En la tabla se describe
la version 4.
Tamaño Cabecera (IHL): 4 bits.
Longitud de la cabecera, en palabras de 32 bits. Su valor minimo es de 5 para
una cabecera correcta, y el maximo de 15.
Tipo de Servicio: 8 bits.
Indica una serie de parametros sobre la calidad de servicio deseada durante el
transito por una red. Algunas redes ofrecen prioridades de servicios,
considerando determinado tipo de paquetes 'mas importantes' que otros (en
particular, algunas redes pueden admitir solo los paquetes con una prioridad
alta en momentos de sobrecarga).
Estos 8 bits se agrupan de la siguiente manera:
bits 0-2: Prioridad: Valores altos para prioridades superiores.
bit 3: 0 = Retraso Normal, 1 = Bajo Retraso.
bit 4: 0 = Transito Normal, 1 = Transito Rapido.
bit 5: 0 = Fiabilidad Normal, 1 = Alta Fiabilidad.
bits 6-7: Reservados para futuros usos.
Longitud Total: 16 bits.
Es el tamaño total, en octetos, del datagrama, incluyendo el tamaño de la
cabecera y el de los datos. El tamaño maximo de los datagramas usados
normalmente es de 576 octetos (64 de cabeceras y 512 de datos). Una maquina no
deberia enviar datagramas mayores a no ser que tenga la certeza de que van a ser
aceptados por la maquina destino.
En caso de fragmentacion este campo contendra el tamaño del fragmento, no el del
datagrama original.
Identificador: 16 bits.
Identificador unico del datagrama. Se utilizara, en caso de que el datagrama
deba ser fragmentado, para poder distinguir los fragmentos de un datagrama de
los de otro. El originador del datagrama debe asegurar un valor unico para la
pareja origen-destino y el tipo de protocolo durante el tiempo que el datagrama
pueda estar activo en la red.
Indicadores: 3 bits.
Actualmente utilizado solo para especificar valores relativos a la fragmentacion
de paquetes:
bit 0: Reservado; debe ser 0
bit 1: 0 = Divisible, 1 = No Divisible
bit 2: 0 = ultimo Fragmento, 1 = Fragmento Intermedio (le siguen mas fragmentos)
La indicacion de que un paquete es indivisible debe ser tenida en cuenta bajo
cualquier circunstancia. Si el paquete necesitara ser fragmentado, no se
enviara.
Posicion de Fragmento: 13 bits.
En paquetes fragmentados indica la posicion, en unidades de 64 bits, que ocupa
el paquete actual dentro del datagrama original. El primer paquete de una serie
de fragmentos contendra en este campo el valor 0.
Tiempo de Vida (TTL): 8 bits.
Indica el maximo numero de segundos que un paquete puede estar circulando. Cada
vez que algun nodo procesa este paquete disminuye su valor en, como minimo, 1
segundo. Cuando llegue a ser 0, el paquete no sera reenviado.
Protocolo: 8 bits.
Indica el protocolo de siguiente nivel utilizado en la parte de datos del
datagrama.
Checksum Cabecera: 16 bits.
Checksum de la cabecera. Se recalcula cada vez que algun nodo cambia alguno de
sus campos (por ejemplo, el Tiempo de Vida). El metodo de calculo
(intencionadamente simple) consiste en sumar el complemento a 1 de cada palabra
de 16 bits de la cabecera y hacer el complemento a 1 del valor resultante.
Direccion IP de Origen: 32 bits.
Direccion IP de Destino: 32 bits
Opciones: Variable.
Aunque no es obligatoria la utilizacion de este campo, cualquier nodo debe ser
capaz de interpretarlo.
Puede contener un numero indeterminado de opciones, que tendran dos posibles
formatos:
Simple: Un solo octeto indicando el 'Tipo de Opcion':
El Tipo de Opcion esta dividido en 3 campos:
Indicador de Copia: 1 bit. En caso de fragmentacion, la Opcion
se copiara o no a cada nuevo fragmento segun el valor de este
campo:
0=no se copia
1=se copia
Clase de Opcion: 2 bits. Las posibles clases son:
0=control
1=reservada
2=depuracion y mediciones
3=reservada
Numero de Opcion: 5 bits. Identificador de la Opcion.
Compuesto: Un octeto para 'Tipo de Opcion', otro para 'Tamaño de
Opcion', y uno o mas octetos conformando los 'Datos de Opcion'.
El Tamaño de Opcion incluye el octeto de Tipo de Opcion, el de
Tamaño de Opcion y la suma de los octetos de datos.
La siguiente tabla muestra las opciones actualmente definidas:
+-----+--------+---------+---------------------------------------------------
Clase |Numero |Tamaño | Descripcion
------+--------+---------+------------------------------------------------
0 |0 | - |Final de lista de opciones. Formato simple.
0 |1 | - |Ninguna operacion (NOP). Formato simple.
0 |2 |11 |Seguridad.
0 |3 |variable |Enrutado desde el Origen, abierto (Loose Source
|Routing).
0 |9 |variable |Enrutado desde el Origen, estricto (Strict Source
|Routing).
0 |7 |variable |Registro de Ruta (Record Route).
0 |8 |4 |Identificador de flujo (Stream ID).
2 |4 |variable |Marca de tiempo (Internet Timestamping).
------+--------+---------+--------------------------------------------------
Final de Lista de Opciones:
Se usa al final de la lista de opciones, si esta no coincide con el final de la
cabecera IP.
Ninguna Operacion (NOP):
Se puede usar para forzar la alineacion de las opciones en palabras de 32 bits.
Seguridad:
Especifica niveles de seguridad que van desde 'No Clasificado' hasta 'Maximo
Secreto', definidos por la Agencia de Seguridad de la Defensa (de EE.UU.).
Enrutado desde el Origen (abierto) y Registro de Ruta (LSSR):
Esta opcion provee el mecanismo para que el originador de un datagrama pueda
indicar el itinerario que ha de seguir a traves de la red y para registrar el
camino seguido.
Los Datos de Opcion consisten en un puntero (un octeto) y una lista de
direcciones IP (4 octetos cada una) que se han de alcanzar ('procesar'):
El puntero indica la posicion de la siguiente direccion de la ruta, dentro de la
Opcion; asi, su valor minimo es de 4.
Cuando un nodo de Internet procesa la direccion de la lista apuntada por el
puntero (es decir, se alcanza esa direccion) incrementa el puntero en 4, y
redirige el paquete a la siguiente direcion. Si el puntero llega a ser mayor que
el Tamaño de Opcion significa que la informacion de ruta se ha procesado y
registrado completamente y se redirigira el paquete a su direccion de destino.
Si se alcanza la direccion de destino antes de haber procesado la lista de
direcciones completa (el puntero es menor que el Tamaño de Opcion) la siguiente
direccion de la lista reemplaza a la direccion de destino del paquete y es a su
vez reeemplazada por la direccion del nodo que esta procesando el datagrama
('Ruta Registrada'), incrementando, ademas, el puntero en 4.
Utilizando este metodo de sustituir la direccion especificada en origen por la
Ruta Registrada se asegura que el tamaño de la Opcion (y de la cabecera IP) no
varia durante su recorrido por la red.
Se considera que la ruta especificada por el originador es 'abierta' porque
cualquier nodo que procesa el paquete es libre de dirigirlo a la siguiente
direccion siguiendo cualquier otra ruta intermedia.
Solo puede usarse una vez en un datagrama, y, en caso de fragmentacion, la
opcion se copiara a los paquetes resultantes.
Enrutado desde el Origen (estricto) y Registro de Ruta (SSRR):
Exactamente igual que LSSR, excepto en el tratamiento que los nodos haran de
este datagrama. Al ser la ruta especificada 'estricta', un nodo debe reenviar el
paquete directamente a la siguiente direccion, es decir, no podra
redireccionarlo por otra red.
Registro de Ruta:
Mediante el uso de esta Opcion se puede registrar el itinerario de un
datagrama.Los Datos de Opcion consisten en un puntero (un octeto) y un espacio
relleno de ceros que contendra la Ruta Registrada para el paquete.
Cuando un nodo recibe un paquete en el que esta presente esta opcion, escribira
su direccion IP en la posicion indicada por el puntero, siempre que esta sea
menor que el Tamaño de Opcion, e incrementara el puntero en 4.
Es preciso que el espacio reservado para la Ruta Registrada tenga una longitud
multiplo de 4; si al intentar grabar su direccion un nodo detecta que existe
espacio libre pero es menor de 4 octetos, el paquete no se reenvia (se pierde) y
se notifica el error, mediante ICMP, al originador del datagrama.
Esta Opcion no se copia en caso de fragmentacion, y solo puede aparecer una vez
en un paquete.
Relleno: Variable.
Utilizado para asegurar que el tamaño, en bits, de la cabecera es un multiplo de
32. El valor usado es el 0.
Ahora, si el campo de protocolo dice que es un paquete TCP, entonces a esta
cabecera IP le sigue inmediatamente una cabecera TCP: la cabecera TCP tambien
tiene al menos 20 bytes de longitud:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Puerto de Origen | Puerto de Destino |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Numero de Secuencia |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Numero de Confirmacion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Deplz. | |U|A|P|R|S|F| |
|de los | Reservado |R|C|S|S|Y|I| Ventana |
| Datos | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Puntero de Urgencia |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Los campos mas importantes son el puerto de origen y el de destino, que dicen a
que servicio esta destinado el paquete (o de cual viene, en el caso de que sea
un paquete de respuesta). Los numeros de secuencia y confirmacion
(acknowledgement) se utilizan para mantener el orden de los paquetes, y decirle
al otro extremos cuantos paquetes se han recibido. Los indicadores (flags) ACK,
SYN, RST y FIN (escritos de mayor a menor) son simples bits que se utilizan en
la negociacion de apertura (SYN) y cierra (RST o FIN) de las conexiones.
Siguiendo a esta cabecera viene el verdadero mensaje que la aplicacion envio (el
cuerpo del paquete). Un paquete normal puede tener hasta 1500 bytes: esto
significa que el mayor espacio que pueden ocupar los datos es de 1460 bytes (20
bytes para la cabecera IP y 20 para la cabecera TCP): alrededor del 97%.
---------
8.Filtros
---------
8.1.Medidas de proteccion ante los ICMP
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Dado que ahora las conexiones suelen ser de alta velocidad en la mayoria de la
gente, intentar inundar la victima desde pocos ordenadores con paquetes ICMP es
una tonteria. Para que tenga efecto, necesitarias muchas maquinas a tu
disposicion. En teoria los ISP deeberian limitar el numero de paquetes ICMP que
atraviesan sus firewalls y routers pero como he dicho, en teoria.
Los firewalls actuales (incluyendo el filtrado de paquetes del nucleo de linux)
puden limitar o desactivar totalmente el ICMP en las redes que protegen.
8.2.Medidas de proteccion contra la inundacion SYN
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A parte de mantener el kernel de tu sistema operativo actualizado, deberias
consutar varias entradas en el directorio /proc. Puedes modificar ciertos
parametros para disminuir el tiempo de espera por un paquete SYN/ACK y para
establecer el numero maximo de paquetes SYN de salida que se pueden almacenar en
la cola:
Jana# cat /proc/sys/net/ipv4/vs/timeout_synack
100
Jana# cat /proc/sys/net/ipv4/vs/timeout_synrecv
10
Jana# /proc/sys/net/ipv4/tcp_max_syn_backlog
130
Si alguna de tus maquinas esta siendo atacada por una inundacion SYN, incrementa
el valor de tcp_max_syn_maxlog y disminuye los tiempos de espera timeout_*.
-------------------------
9.Prevencion y respuesta
-------------------------
Existen varios pasos que los administradores pueden dar para ayudar a prevenir
el acceso a traves de los puntos debiles de los protocolos, aplicaciones y
sistemas operativos, por ejemplo:
-Asegurarse de que todos los sistemas disponen de los ultimos parches de
seguridad. La aplicacion de los parches puede dar proteccion frente a la mayor
parte de los DoS, que se suelen basar en problemas del Sistema operativo o de
los protocolos.
-Los sistemas Linux se pueden proteger de los ataques SYN compilando el
kernel con cookies SYN. Algunas versiones de UNIX (como solaris 2.6 y
superiores) incluyen proteccion ante los ataques SYN. En Windows 2000 se
puede editar el registro para protegerse ante los ataque SYN.
-Se puede configurar el router para que responda a las difusiones
dirigidas, en vez de pasarlas a la subred, protegiendose asi del SmurF.
-El router tambien se puede configurar para que filtre todos los
paquetes entrantes que dispongan de una IP que aparente pertenecer a la
red local.
-Configurar el sistema para ignorar los redireccionados del router.
-Desactivar Java, JavaScript, ActiveX y el resto de los contenidos
activos del explorador puede anular muchos de los principales puntos
debiles del explorador.
-Usar firewall y NIDS
-Cambiar todo lo que sea standard; el passwd del router, usar un
explorador de internet que no sea el de Microsoft, etc.
------------------------------------------------------
10.Sobre los NIDS (Network Intrusion Detection System)
------------------------------------------------------
Si estamos seguros de que queremos lanzar un DDos sobre cierta compañia
o persona/s, deberemos optimizar el ataque para que cumpla su funcion.
Uno de los pasos a cuidar es, si vas a utilizar una herramienta de DDoS
publica, cambiar TODOS los valores por defecto (puertos, passwords, banners,
etc) ya que habran reglas para los NIDS.
Hay dos tipos de trafico generado por un DDoS, el trafico de control (entre
los agentes y los masters) y el trafico del floodeo (entre la/s victima/s y los
agentes).
Una de las posibles detecciones por parte del NIDS es sobre los paquetes
enviados.
Las sesiones UDP normalmente se mandan paquetes pequeños, con un cuerpo de no
mas de 10 bytes. Y sobre los paquetes ICMP decir que suelen estar entre 64 y 128
bytes. Asi que los paquetes que sean demasiado grandes son sospechosos de ser el
trafico de control de algun DDoS, y si encima estan cifrados es mas mosqueante
aun. Siempre se puede obtener como minimo una informacion de cualquier agente
(por muy sofisticado que sea), y es la IP de la victima. Es el unico dato que no
puede estar cifrado, asi que si nuestra red esta actuando de agente, podemos
configurar una regla en el firewall para que no deje salir ningun paquete hacia
esa IP.
Los paquetes TCP y UDP no son partes de una conexion. El modulo de ocultacion
de las herramientas DDoS usan protocolos aleatorios, incluyendo los orientados
a conexiones, para mandar informacion sobre canales no orientados a conexiones.
Un firewall puede detectar estos paquetes. Ademas, los paquetes que indican una
peticion de conexion a puertos superiores a 1024, que no se traten de algun
puerto standard (ej IRC-6667) son sospechosos.
El cuerpo de los paquetes contienen SOLO caracteres alfanumericos (sin
espacios, signos de puntuacion, caracteres de control...). Esto puede decirnos
que el cuerpo esta codificado en BASE64, y por lo tanto, solo contiene
caracteres propios de la codificacion en BASE64.
Puesto que el trafico de control del TFN2K es mediante UDP, para evitar la
deteccion de los paquetes y hacer todo algo mas silencioso, lo que hace es no
mandar los ACK de respuesta. Se limita a mandar 10 veces cada paquetes (y alguno
llegara, no??).
El patron especifico del TFN2K y sus derivados lacteos ñ_ñ es usar un string de
A's (AAAAA...) en el cuerpo, desde que la rutina de cifrado rellena el tamaño
del buffer. Si no esta codificado en BASE64, y el cuerpo contiene trafico
binario encriptado, las A's se convierten en \0's binario.
----------------
11.Bastion Hosts
----------------
La primera regla de oro a la hora de securizar un sistema (hardening o armoring),
tanto Unix como Windows, pasa por deshabilitar todos los
servicios TCP/IP innecesarios. A su vez, son multiples los controles que pueden
llevarse a cabo, tanto desde el punto de vista del sistema (no analizados en
este documento centrado en TCP/IP) como de la red, en los que se profundiza en
este documento.
Las recomendaciones de configuracion respecto a la pila TCP/IP que se presentan
a continuacion no han sido incluidas en referencias especificas para la
proteccion de una vulnerabilidad concreta comentada.
- HP-UX:
Existen dos documentos de referencia a la hora de securizar el sistema operativo
HP-UX, para la version 11.00 y para la 10.X.
Concretamente, para ajustar la seguridad mediante los parametros de red de
TCP/IP se deben añadir las siguientes lineas al fichero
/etc/rc.config.d/nddconf.
# Para evitar que se propaguen paquetes de una interfaz a otra (uso de routing)
TRANSPORT_NAME[1]=ip
NDD_NAME[1]=ip_forwarding
NDD_VALUE[1]=0
#
# Para evitar el chequeo de gateway muerto (este no funciona bien con firewalls)
TRANSPORT_NAME[2]=ip
NDD_NAME[2]=ip_ire_gw_probe
NDD_VALUE[2]=0
#
# Para evitar el uso de la estrategia PMTU discovery (echo-request).
TRANSPORT_NAME[3]=ip
NDD_NAME[3]=ip_pmtu_strategy
NDD_VALUE[3]=1
#
# Para no enviar ICMP source quench
TRANSPORT_NAME[4]=ip
NDD_NAME[4]=ip_send_source_quench
NDD_VALUE[4]=0
#
# Para evitar que se responda a peticiones Timestamp
TRANSPORT_NAME[5]=ip
NDD_NAME[5]=ip_respond_to_timestamp
NDD_VALUE[5]=0
#
# Para no enviar mensajes en paquetes de reset de TCP
TRANSPORT_NAME[6]=tcp
NDD_NAME[6]=tcp_text_in_resets
NDD_VALUE[6]=0
- Solaris:
Los parametros de configuracion generales recomendados en este SO son
aplicables a un fichero de arranque del sistema, por ejemplo /etc/rc2.d/S69inet.
Para que todos estos cambios tengan efecto se deben ejecutar los siguientes
comandos:
# /etc/rc2.d/S69inet stop
# /etc/rc2.d/S69inet start
Para evitar que la maquina encamine paquetes desde una interfaz a otra se debe
incluir la siguiente linea:
ndd set /dev/ip ip_forwarding 0
Para evitar que por cualquier interfaz de una maquina se reciban paquetes con
destino a direcciones IP correspondientes a otros interfaces de la maquina, se
debe incluir la linea:
ndd set /dev/ip ip_strict_dst_multihoming 1
Para evitar que se responda a peticiones Timestamp se debe incluir la siguiente
linea:
ndd -set /dev/ip ip_respond_to_timestamp 0
- Linux:
Al igual que los dos sistemas Unix previos, existen guias similares para Linux.
Asimismo, existen versiones completas derivadas de Linux enfocadas desde el
punto de vista de la seguridad, como Trinux (http://www.trinux.org/) u Openwall
Owl (http://www.openwall.com/Owl/).
Chequeo del gateway activo o no:
A traves del editor del registro (regedt32.exe) debe localizarse la clave:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Bajo la misma es necesario añadir el valor:
Value Name: EnableDeadGWDetect
Data Type: REG_DWORD
Value: 0 (desactivarlo)
Las referencias respecto a los diferentes parametros configurables de las pilas
TCP/IP de los distintos sistemas operativos son multiples. A modo de ejemplo se
muestran las principales:
- UNIX IP Stack Tunning Guide v2.7:
http://www.cymru.com/~robt/Docs/Articles/ip-stack-tuning.html
- Enabling High Performance Data Transfers on
Hosts:
http://www.psc.edu/networking/perf_tune.html
- Linux kernel 2.4:
http://www.linux.org/docs/ldp/howto/Adv-Routing-HOWTO-14.html
- Windows NT, 2000: http://support.microsoft.com/
TCP/IP and NBT Configuration Parameters for Windows (Q120642)
- Windows XP: http://support.microsoft.com/
TCP/IP and NBT Configuration Parameters for Windows XP (Q314053)
- Solaris 2.X - Tuning Your TCP/IP Stack and more:
http://www.sean.de/Solaris/tune.html
------------------
12.Bastion routers
------------------
Al igual que ocurre con los sistemas, los dispositivos de red deben ser
configurados desde un punto de vista restrictivo, de forma que imposibiliten
explotar la mayoria de vulnerabilidades comentadas. Para ello se configuran como
un bastion router.
Las caracteristicas vulnerables de un router considerandolo como un host son:
- Existencia de claves en claro en la configuracion.
- Servicios TCP y UDP simples activos: echo, discard, daytime...
- Protocolos de routing sin autenticacion y/o encriptacion.
- Protocolos AAA sin encriptacion.
- Aceptacion de paquetes source routing.
- Redirecciones IP.
- Proxy ARP.
- CDP, Cisco Discovery Protocol.
- Servidor HTTP activo.
A continuacion se comentan algunos de los comandos que permiten securizar
(hardening o armoring) desde el punto de vista de TCP/IP un router Cisco. Otros
se han comentado en la seccion asociada a la defensa de un ataque especifico.
Deshabilitar los siguientes servicios:
- Finger:
no service finger
- Servicios simples: echo, discard, daytime.
no service tcp-small-servers
no service udp-small-servers
- HTTP server:
no ip http server
- Proxy ARP: en algunos escenarios, el uso de un Proxy ARP puede condicionar a
que el trafico circule por un camino que no es el impuesto por los protocolos de
routing.
no ip proxy-arp
- Deshabilitar el Protocolo CDP:
no cdp run
--------------
13.Conclusion
--------------
Bajo mi punto de vista no existe proteccion para evitar un DDoS. Porque si
no te lo hacen a la red (u ordenador) te lo haran al ancho de banda. Asi que
estamos casi casi en lo mismo: imposibilidad de trabajar con la red.
En estos casos, la red victima no puede hacer nada. Aunque filtre el trafico en
sus sistemas, sus lineas estaran saturadas con trafico malicioso,
incapacitandolas para cursar trafico util. Un ejemplo habitual es el de un
telefono: si alguien quiere molestar, solo tiene que llamar, de forma continua.
Si se descuelga el telefono (para que deje de molestar), tampoco se puede
recibir llamadas de otras personas. Este problema es habitual, por ejemplo,
cuando alguien intenta mandar un fax empleando el numero de voz: el fax insiste
durante horas y sin que el usuario llamado pueda hacer nada al respecto.
El atacante envia tantos paquetes de solicitud de conexion que las conexiones
autenticas simplemente no pueden competir. En casos asi el primer paso a
realizar es el ponerse en contacto con el Proveedor del servicio para que
intente determinar la fuente del ataque y, como medida provisional, filtre el
ataque en su extremo de la linea. El siguiente paso consiste en localizar las
fuentes del ataque e informar a sus Administradores, ya que seguramente se
estaran usando sus recursos sin su conocimiento y consentimiento. Si el atacante
emplea Ip Spoofing, esto puede ser casi imposible, ya que en muchos casos la
fuente del ataque es, a su vez, victima y el origen ultimo puede ser
practicamente imposible de determinar.
Ahora que conocemos como va todo, podeis echar la imaginacion a volar. Por
ejemplo, mientras hacemos un DDoS mediante agentes, mandar unos cuantos ICMP a
unos broadcasts simulando ser la victima. Previamente habras tenido que mirar si
el ISP de dicho server admite el spoofeo.
O si eres un programador loco, diseñar un agente controlado mediante paquetes 'sueltos'
sin que haya una comunicacion apta de ser esnifada y logeada. Por ejemplo, un cierto tipo
de paquete con los parametros para empezar el ataque, y otro paquete para pararlo.
En fin, que si alguien se dedica a jugar con los DDoS que se lo curre y no haga
pijaditas tipicas. La grandeza esta en el arte de la creacion, creacion que no toda la
gente tiene. Esa gente falsa que monta asociaciones para ganar dinero y va jodiendo
y engañando a los socios. Que no os enrede nunca mas cierto personaje...
Kirby
mail to:smurfito@hush.ai
* EOF *
