You are on page 1of 19

1.

INTRODUCCIN A LOS SISTEMAS IDS Y SNORT

Un IDS o Sistema de Deteccin de Intrusiones es una herramienta de seguridad que


intenta detectar o monitorizar los eventos ocurridos en un determinado sistema informtico
o red informtica en busca de intentos de comprometer la seguridad de dicho sistema.

Los IDS buscan patrones previamente definidos que impliquen cualquier tipo de
actividad sospechosa o maliciosa sobre nuestra red o host.

Los IDS aportan a nuestra seguridad una capacidad de prevencin y de alerta


anticipada ante cualquier actividad sospechosa. No estn diseados para detener un ataque,
aunque s pueden generar ciertos tipos de respuesta ante stos.

Los IDS: aumentan la seguridad de nuestro sistema, vigilan el trfico de nuestra red,
examinan los paquetes analizndolos en busca de datos sospechosos y detectan las primeras
fases de cualquier ataque como pueden ser el anlisis de nuestra red, barrido de puertos, etc.
(Alfon, 2003)

2. SNORT

Snort es un Sistema de Deteccin de Intrusos (IDS) basado en red (IDSN) open source.
Cuenta con un lenguaje de creacin de reglas en el que se pueden definir los patrones que
se utilizarn a la hora de monitorizar el sistema. Adems, ofrece una serie de reglas y filtros
ya predefinidos que se pueden ajustar durante su instalacin y configuracin para que se
adapte lo mximo posible a lo que deseamos.

Una de las ventajas de este sistema es que puede funcionar como sniffer (podemos ver en
consola y en tiempo real qu ocurre en nuestra red, todo nuestro trfico), registro de
paquetes (permite guardar en un archivo los logs para su posterior anlisis, un anlisis
offline) o como un IDS normal (en este caso NIDS). Cuando un paquete coincide con algn
patrn establecido en las reglas de configuracin, se loguea. As se sabe cundo, de dnde y
cmo se produjo el ataque. (Ortego Delgado, 2017).
3. MODOS DE EJECUCION

Snort es una herramienta que funciona en cuatro modos:

Sniffer Mode
Packet Logger Mode
Network Intrussion Detection System (NIDS)
Inline Mode

Los modos de ejecucin de Snort se activan dependiendo de los parmetros que le pasemos al
programa. En la tabla 1 podemos ver un resumen de los parmetros ms importantes que podemos
utilizar en Snort.
3.1. MODO SNIFFER

El modo sniffer permite escuchar todo el trfico de la red y mostrarlo en pantalla. Una vez que
finaliza el modo sniffer nos muestra una estadstica del trfico. Para iniciar el modo sniffer y
visualizar en pantalla todo el trfico TCP/ IP debemos ejecutar el comando.

$ snort -v
Si queremos visualizar los campos de datos que pasar por la interfaz de red ejecutamos:

$ snort -dev
3.2. MODO PACKET LOGGER

Si ejecutamos snort en modo sniffer veremos gran cantidad de informacin pasar por nuestra
pantalla, con lo cual sera interesante guardar estos datos en disco para su posterior estudio. El
modo Packet Logger escucha todo el trfico de la red y los registra en un determinado
directorio. Para ejecutar snort en este modo debemos utilizar el parmetro l/var/logs/snort.
Donde /var/log/snort es el directorio donde se registra el trfico.
3.3. MODO SISTEMA DE DETECCION DE INTRUSOS DE RED

Este ser el modo de funcionamiento en el que nos centraremos. Es la opcin ms completa y


configurable. Permite analizar el trfico de la red en busca de instrucciones a partir de los
patrones de bsqueda definidos por el usuario. Snort nos informar de intentos de acceso no
permitido a nuestro host, as como de escaneos de puertos, ataques DOS, ejecucin de exploits.
Para que Snort funcione en modo IDS, demos pasar el parmetro c directorio hacia un snort
conf. Como hemos visto antes, en el fichero de configuracin snort.conf, especificamos la
configuracin deseada. Una vez realizada la configuracin, el siguiente paso es hacer que snort
se ejecute cada vez que arrancamos. Para ello, podemos realizarlo de distintas formas. Una de
ellas es incluir el siguiente comando en el archivo de arranque: /etc/rc.d/rc.local:
3.4. MODO INLINE

Permite configurar el NIDS para que interacte con los contrafuegos de forma que si snort
detecta un ataque puede enviar a ip estables la peticin para que corte el trfico. Para utilizar el
modo snort-inline debemos configurar nuestro sistema en modo bridge y utilizar un mdulo de
salida para que se comunique con ip estables (por ejemplo, snortsam www.snortsam.net)

4. CARACTERISTICAS

Una caracterstica muy importante e implementada desde hace pocas versiones es FlexResp.
Permite, dada una conexin que emita trfico malicioso, darla de baja, hacerle un DROP mediante
el envo de un paquete con el flag RST activa, con lo cual cumplira funciones de Firewall, cortando
las conexiones que cumplan ciertas reglas predefinidas. No slo corta las conexiones ya que puede
realizar otras muchas acciones. La caracterstica ms apreciada de Snort, adems de su
funcionalidad, es su subsistema flexible de firmas de ataques.
Los sistemas IDS y Snort buscan patrones previamente definidos que impliquen cualquier tipo de
actividad sospechosa o maliciosa sobre nuestra red o Host. Aportan a nuestra seguridad una
capacidad de prevencin y de alerta anticipada ante cualquier actividad sospechosa. No estn
diseados para detener un ataque, aunque s pueden generar ciertos tipos de respuesta ante stos.
Aumentan la seguridad de nuestro sistema, vigilan el trfico de nuestra red, examinan los paquetes
analizndolos en busca de datos sospechosos y detectan las primeras fases de cualquier ataque como
pueden ser el anlisis de nuestra red.
Un problema de los IDS es cuando queremos implementarlos en redes conmutadas ya que no hay
segmento de red por donde pase todo el trfico. Otro problema para un IDS son las redes con
velocidades de trfico muy altas en las cuales es difcil procesar todos los paquetes.

5. REGLAS DE SNORT
5.1. ENCABEZADO DE REGLAS SNORT
Acciones: Permite ejecutar un evento relacionado con la informacin del paquete
capturado, se trata del primer atributo visible de la regla y puede tener uno de los 3
siguientes valores:

alert Gener una alerta usando el mtodo de


alerta seleccionado y posteriormente
genera un Log del paquete

log Gener un log del paquete.

pass Ignora (borra) el paquete

Protocolos: Despus de determinar que accin se debe tomar, se define el protocolo al


que aplica la regla, en Snort se pueden definir los siguientes protocolos de
comunicacin: TCP, UDP, ICMP
Direcciones IP y puertos: Indica la direccin o rango de direcciones de origen y
destino relacionadas con los paquetes capturados por Snort, se puede indicar un rango
de direcciones como por ejemplo /24 para redes clase C /16 para redes clase B ,
ahora bien, las direcciones se establecen despus de definir la accin y el protocolo al
que aplican, el primer conjunto de direccin(es) y puerto(s) declarados en la regla
corresponden a aquellos que figuran en la direccin origen del paquete, mientras que las
direccin(es) y puertos(s) declarados despus del smbolo de direccin de la regla (se
ver unos prrafos ms abajo su significado) corresponden a aquellos que figuran en la
direccin destino del paquete. En este orden de ideas se pueden tener encabezados de la
regla como los que se indican a continuacin:
1. Log sobre todo el trfico UDP sobre cualquier direccin IP y cualquier puerto
establecidos en el campo de origen del paquete y adems sobre las direcciones IP de
destino entre los rangos de 192.168.1.1 y 192.168.1.255 cuyo puerto se encuentre entre
1 y 1024
log udp any any -> 192.168.1.0/24 1:1024

2. Log sobre todo el trafico TCP sobre cualquier direccin IP y cualquier puerto
establecidos en el campo de origen del paquete y ademas sobre las direcciones IP de
destino entre los rangos de 192.168.1.1 y 192.168.1.255 cuyo puerto sea menor o igual
a 6000
log tcp any any -> 192.168.1.0/24 :6000

3. Alerta sobre todo el trafico TCP sobre cualquier direccin IP y cualquier puerto
establecidos en el campo de origen del paquete y ademas sobre las direcciones IP de
destino entre los rangos de 192.168.1.1 y 192.168.1.255 cuyo puerto sea mayor o igual
a 1024

alert tcp any any -> 192.168.1.0/24 1024:

4. Alerta sobre todo el trafico TCP sobre cualquier direccin IP y puertos menores o
iguales al 1024 establecidos en el campo de origen del paquete y ademas sobre las
direcciones IP de destino entre los rangos de 192.168.1.1 y 192.168.1.255 cuyo puerto
sea mayor o igual a 500

log tcp any :1024 -> 192.168.1.0/24 500:

5. Alerta sobre todo el trafico TCP sobre cualquier direccin IP origen que no se
encuentre en el rango de 192.168.1.1 y 192.168.1.255 y en cualquier puerto, ademas
sobre las direcciones IP de destino entre los rangos de 192.168.1.1 y 192.168.1.255
cuyo puerto sea 111
alert tcp !192.168.1.0/24 any -> 192.168.1.0/24 111

Operador de Direccin: En las reglas anteriores ha existido un comn denominador


sin contar con la estructura de las reglas, se trata del smbolo -> este smbolo indica la
direccin del trfico que aplicar la regla, como se ha indicado anteriormente, el
conjunto de direcciones IP y puertos ubicados a la izquierda de este operador
corresponden a los campos de origen del paquete, mientras que el conjunto de
direcciones IP y puertos ubicados a la derecha de este operador corresponden a los
campos de destino del paquete. Sin embargo existe un operador ms que indica que el
trfico puede ser bidireccional, lo que quiere decir que Snort no distinguir entre los
campos de la izquierda y la derecha para definir el origen y el destino de los paquetes
utilizados, sino que utilizar ambos
5.2. OPCIONES DE LAS REGLAS DE SNORT
Finalmente para terminar de confeccionar una regla en Snort, es necesario definir
ciertas opciones que permitirn definir determinadas caractersticas en el
comportamiento de Snort cuando un paquete determinado encaja con el encabezado de
la regla visto anteriormente. A continuacin se listan las opciones aceptadas en las
reglas de Snort:
NOTA: todas las opciones se separan con ;
1. msg:
Indica a las acciones de alerta y logging el mensaje que se debe imprimir junto con
el volcado del paquete, se trata simplemente de una cadena con la descripcin que
se desea imprimir.

alert tcp any :1024 -> 192.168.1.0/24 500: (msg: mensaje de alerta;
sid:10000001;)

2. reference:
Indica una referencia externa a sistemas de identificacin de ataques, los sistemas
sistemas externos soportados por Snort a la fecha de escribir este documento son:
bugtraq http://www.securityfocus.com/bid/

cve http://cve.mitre.org/cgi-
bin/cvename.cgi?name=

nessus http://cgi.nessus.org/plugins/dump.php3?id=

arachnids http://www.whitehats.com/info/IDS
mcafee http://vil.nai.com/vil/content/v _

osvdb http://osvdb.org/show/osvdb/

url Url arbitraria


3. Las referencias anteriormente descritas se encuentran ubicadas en el directorio de
instalacin de Snort en el fichero reference.config. Para utilizar esta opcin, se debe
indicar de uno a muchos identificadores de sistema e identificadores de referencia
alert tcp any any -> any 7070 (msg:IDS411/dos-realaudio; \flags:AP; content:|fff4 fffd 06|;
reference:arachnids,IDS411;)
alert tcp any any -> any 21 (msg:IDS287/ftp-wuftp260-venglin-linux; \flags:AP;
content:|31c031db 31c9b046 cd80 31c031db|; \
reference:arachnids,IDS287; reference:bugtraq,1387; \
reference:cve,CAN-2000-1574;)

Por otro es importante anotar que el fichero reference.config no es cargado


automticamente por Snort, de hecho es necesario que se encuentre definido en el
fichero de configuracin de Snort, en concreto debera tener la linea include reference.config
3. gid:
Indica el Generator Id que identifica que componente de Snort ha generado el evento
asociado a la regla, los identificadores de preprocessors y gids asociados se encuentran
ubicados en el fichero gen-msg.map
4. rev:Indica la revisin de la regla de forma nica, normalmente se utiliza con el atributo sid..

alert tcp any any -> any 80 (content:XXXX; sid:1000001; rev:1;)

5. sid:
Este atributo es til para identificar de forma nica las reglas de Snort, esta
informacin permite a los plugins de salida identificar reglas de forma fcil, por otro
lado esta opcin debera ser utilizada junto con opcin rev. Los siguientes son los
rangos manejados por Snort los posibles SID.
Menores de 100: Reservados para uso futuro.-Entre 100 y 999.999: Incluidos en la
distribucin de Snort.- Mayor o igual a 1.000.000: Usados para reglas locales.
6. classtype:Permite categorizar la regla en cuestin para clasificar el ataque bajo un
tipo mas general, por defecto Snort cuenta con algunas de estas categoras, todas se
encuentran definidas en el fichero classification.config localizado en el directorio
raz de instalacin de Snort. Este mecanismo de clasificacin, permite mejorar la
organizacin de los eventos que Snort produce durante su ejecucin. Por otro lado,
es posible declarar reglas personalizadas registrandolas en el fichero
classification.config siguiendo la sintaxis deconfig classification: <clasificacin> ,
<descripcin de la clasificacin> , <prioridad>Clasificacin y descripcin son
solamente cadenas de texto y prioridad es un valor entero entre 1(alto) y 4(muy
bajo).
Clasificacin personalizada
config classification: kickass-porn,Kicking the XXX Content,3
Regla Clasificada
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:
INAPPROPRIATE; flow: to_client,established; content:porn; nocase; threshold: type
threshold, track by_dst,count 5, seconds 360; classtype: kickass-porn; sid: 2001352; rev:5; )

7. Por otro es importante anotar que el fichero classification.config no es cargado


automticamente por Snort, de hecho es necesario que se encuentre definido en el fichero de
configuracin de Snort, en concreto debera tener la linea include classification.config
8. priority:Este atributo es utilizado para sobrescribir el valor de la prioridad definida en el
atributo classtype de la regla, se trata de un valor entero entre 1 y 4 que hace que la
prioridad declarada en el classtype sea sobrescrito.
9. metadata:
Permite que la regla disponga de informacin adicional que es til para el procesador de
reglas de Snort, los valores declarados tienen significados para Snort y hacen que el
comportamiento de la regla cambie en funcin a los valores definidos a continuacin

Clave Descripcin Valor de Formato

engine shared Indica una regla de


librera compartida

soid gid|sid Regla de librera


compartida para
generadores y sid

service http Identificador de servicio


basado en objetivo

Ejemplo:
alert tcp any any -> any 80 (msg:Ejemplo de Regla de librera compartida; \metadata:engine
shared; metadata:soid 3|12345;)alert tcp any any -> any 80 (msg:Ejemplo de regla de Servicio
HTTP; \metadata:service http;)

Aqu se han indicado los conceptos bsicos de creacin de reglas de Snort, en prximas
entradas se detallarn las opciones de deteccin de Payloads.

6. ATAQUE DE DENEGACION DE SERVICIO


Es un ataque a un sistema de computadoras o red que causa que un servicio o recurso sea
inaccesible a los usuarios legtimos. Normalmente provoca la prdida de la conectividad con la red
por el consumo del ancho de banda de la red de la vctima o sobrecarga de los recursos
computacionales del sistema atacado.

Los ataques DoS se generan mediante la saturacin de los puertos con mltiples flujos de
informacin, haciendo que el servidor se sobrecargue y no pueda seguir prestando su servicio. Por
eso se le denomina denegacin, pues hace que el servidor no pueda atender a la cantidad enorme de
solicitudes. Esta tcnica es usada por los crackers o piratas informticos para dejar fuera de servicio
servidores objetivos.

Una ampliacin del ataque DoS es el llamado ataque de denegacin de servicio


distribuido(DDoS por sus siglas en ingls) el cual se lleva a cabo generando un gran flujo de
informacin desde varios puntos de conexin hacia un mismo punto de destino. La forma ms
comn de realizar un DDoS es a travs de una red de bots, siendo esta tcnica el ciberataque ms
usual y eficaz por su sencillez tecnolgica.

En ocasiones, esta herramienta ha sido utilizada como un buen mtodo para comprobar la capacidad
de trfico que un ordenador puede soportar sin volverse inestable y afectar a los servicios que
presta. Un administrador de redes puede as conocer la capacidad real de cada mquina.
El mayor ejemplo de ataque de denegacin de servicio jams realizado afect a los servidores de
Amazon, PayPal, Visa y MasterCard, all por el 2010, inhabilitando el poder realizar pagos a nivel
mundial. Esto no slo afecta negativamente a los usuarios (imaginaros el encontrar una oferta de
ltima hora de esas de 70% u 80% de descuento y no poder aprovecharla :( ); las empresas
objetivos perderan adems de las comisiones que cobrasen por transacciones durante el tiempo de
cada de sus servidores, parte de la confianza en la marca que tienen los usuarios, en resumidas
cuentas, su reputacin se vera en entredicho.

6.1. ATAQUE DoS CONOCIDOS

UDP Flood (Saturacin UDP)

Este ataque DDoS aprovecha el protocolo UDP (User Datagram Protocol), un protocolo de red
que no necesita una sesin iniciada en el equipo remoto. Este tipo de ataque inunda puertos
aleatorios dicho host remoto con numerosos paquetes UDP, causando que el equipo vctima
compruebe ante cada peticin a cada puerto, si hay alguna aplicacin escuchando en destino; y
en caso de no haberla responde con un paquete ICMP (Internet Control Message Protocol) de
error de destino. Al ser el nmero de paquetes enviado enormemente exagerado, este proceso
agota los recursos del servidor o equipo, y en ltima instancia puede conducir a la
inaccesibilidad.

ICMP Flood (Saturacin por Ping)

Similar en principio al ataque de inundacin UDP, este en particular satura el recurso de


destino con solicitud de paquetes eco ICMP (ms conocido como ping), bsicamente se trata
de enviar paquetes de solicitud sin esperar los paquetes de respuesta. Este tipo de ataque
puede consumir tanto ancho de banda saliente y entrante , ya que las solicitudes intentarn
ser respondidas con paquetes ICMP mientras no paran de llegar nuevos paquetes, dando como
resultado una significativa desaceleracin general del sistema, hasta lograr la cada del servicio
o el reinicio de la mquina. Los ataques mediante ICMP flood pueden ser detenidos gracias a
la configuracin de Listas de Control de Acceso (ACLs) en routers y 3. Service Port Flood
(Ataque sobre Puertos de Servicio).

As como en los ataques UDP Flood se atacaban puertos aleatoriamente, en este tipo de
ataques las peticiones irn dirigidas hacia los puertos estndar en los que se conoce que habr
ms volumen de trfico (el puerto TCP 80, por ejemplo) tanto entrante como saliente. Estamos
ante un tipo de ataque considerado de los ms complejos para evitarlos o detenerlos. Por lo que
deberemos implementar herramientas especficas para esta tarea o derivar todas nuestras
comunicaciones por un mitigador o analizador de trfico que detecte estos ataques.

HTTP Flood (Saturacin HTTP)

En los ataques por HTTP DoS, como atacantes haremos uso de peticiones GET o POST en
apariencia vlidas para atacar servidores o aplicaciones web . Aqu no usaremos paquetes con
tamaos abusivos ni nada por el estilo. Este ataque hace uso de muchsimo menos ancho de
banda para inhabilitar a nuestra vctima, o incluso tomar el control. Uno de los usos ms
habituales de este ataque, es el de usar la mquina que acabamos de atacar para usar sus
recursos y atacar a otros servidores o aplicaciones web; o dicho de otra forma para comenzar a
crear una botnet o seguir ampliando la que ya tenemos.

SYN Flood

As funciona la secuencia de conexin de tres pasos del protocolo SYN. Nosotros enviamos
una peticin SYN para iniciar la conexin TCP que el host al que conectamos debe responder
con un paquete SYN-ACK para nosotros confirmarlo con una respuesta ACK. El ataque
comienza cuando ignoramos la peticin ACK por parte de nuestro objetivo, este mantiene las
conexiones abiertas a la espera de respuesta y nosotros continuamos enviando paquetes SYN,
lo que provoca que dicha mquina siga enviando peticiones SYN-ACK; saturando as el trfico
saliente y entrante del host . Los ataques SYN flood puede ser detenido fcilmente con la
implementacin de firewalls, tanto de tipo hardware como software.
Slowloris

En el resto de tipos de ataques enviamos paquetes o solicitudes completas. Pero en esta


ocasin, lo que hacemos es enviar nicamente las cabeceras de las peticiones (HTTP en este
caso), sin llegar a completar nunca una de estas al completo, con lo que cada media-peticin
que enviamos queda abierta, a la espera de que terminemos de enviar la informacin restante
para completarla, lo que en poco tiempo acabar consumiendo los recursos del servidor vctima
y denegando el servicio al resto de peticiones legtimas.

Ping of Death (Ping de la Muerte)

Por norma general una peticin ping tiene un tamao de 32 bytes (incluida la cabecera) y los
servidores no tienen ningn problema para gestionar las peticiones y enviar la respuesta
correspondiente legtimas. Con el conocido como Ping de la muerte (Ping of Death o PoD),
lo que hacemos es enviar paquetes mediante ping, pero con un tamao mucho mayor y a
mayor frecuencia de lo normal.

El esquema de este ataque es el siguiente:

ping DIRECCIN.IP.DEL.OBJETIVO -l 65535 -n 10000000 -w 0.00001

Donde:

l: Indica el tamao del paquete en Bytes. Como vimos antes, el tamao por defecto es de
32bytes y nosotros estaremos enviando 65535bytes, que es el tamao mximo permitido
por el comando.

-w: Estipula el tiempo de espera para la respuesta antes de enviar otro paquete. Como no
nos interesa recibir respuestas, si no saturar de paquetes peticionarios al objetivo, lo
establecemos a una espera ridculamente pequea para que el envo de paquetes sea
continuo.

-n : Establece una cuenta con el nmero de paquetes que enviaremos. Por defecto enviar 4
peticiones, y como se ve en el ejemplo, para nosotros eso no era bastante, por lo que
subimos hasta los 10 millones de peticiones (y porque no nos hemos querido poner
chulos) ;).

Este comando debe ejecutarse como usuario root para poder cambiar los tamaos de paquetes,
intervalos de envo, etc Adems, es de los ms flojitos que podemos encontrar en esta lista,
debido a que es uno de los ataques contra los que primero se protegen los servidores. Por lo que
para realizar una denegacin de servicio como tal necesitaramos una red de bots (botnet o red
de equipos bajo nuestro control) que atacasen al objetivo de forma simultnea.

NTP Amplification (Amplificacin NTP)

Este tipo de ataque es muy curioso a la par que tambin es bastante difcil de detener, explico el
por qu. Nosotros como atacantes realizaremos una peticin a un servidor NTP (Network Time
Protocol o Protocolo en Red de Tiempo, servicio dedicado a sincronizar el reloj del sistema con
diversos servidores). Una peticin realizada devolver un paquete que contendr las 100 ltimas
direcciones IPs que se hayan conectado a ese servidor, con un tamao en proporcin a la
peticin enviada de entre 1:60 a 1:200. Lo gracioso del ataque es que para realizar esta
peticin, spoofearemos (robaremos la ip de nuestra vctima y la usaremos como nuestra) la ip
de la mquina a la que queremos atacar, llegando a sta los enormes paquetes devueltos.

Si este proceso lo repetimos al estilo PoD, o bien usando una botnet, el resultado ser
la saturacin del servicio de la ip de nuestra vctima hasta hacer inaccesible , bien por la propia
saturacin del servicio, bien porque resulte en un crasheo del sistema.

Deca que es bastante difcil de detener porque los paquetes atacantes provienen de servidores
lcitos y verificados, por lo que lo nico que podremos hacer es mantener el servicio ntpd lo ms
actualizado posible, o si no nos es posible, restringir el proceso asociado moonlist mediante la
edicin del archivo ntp.conf, aadiendo la directiva noquery a las lneas de restriccin por
defecto, quedando algo como esto:

restrict default kod nomodify notrap nopeer noquery

restrict -6 default kod nomodify notrap nopeer noquery

Blended Flood (Ataque combinado)


Esto se da cuando mltiples tipos de ataques s e combinan en el servidor, lo cual al final
termina confundiendo al equipo. Debido a su complejidad, no pueden ser detenidos por
firewalls, switches, routers, ni dispositivos IPS (Intrusion Prevention System), a menos que lo
configuremos a conciencia, pero al ser ataques que mezclan las diferentes tcnicas aqu
descritas es una tarea tremendamente compleja.

Zero-day DDoS Attack (Ataques Da Cero)

Los ataques Zero-day o Da-Cero no son ms que ataques novedosos o desconocidos que
explotan vulnerabilidades de las cuales an no se han publicado correcciones o parches (este
trmino se aplica a cualquier vulnerabilidad, pero al existir tal cantidad de ataques DoS o
DDoS, lo incluyo para que se tenga presente).

Por lo que no es nada fcil defenderse de algo de lo que prcticamente no se sabe nada. Un
claro ejemplo de ataque Zero-day pueden ser aquellos relacionados con la vulnerabilidad
Stagefright de la que ya hablamos hace unos meses ya que se trata de una vulnerabilidad
conocida recientemente para la que an no ha salido correccin o parche oficial, pero como
vimos en aquella publicacin hay un par de trucos que nos pueden ayudar a evitar que seamos
afectados por un ataque.

6.2. CMO PROTEGERNOS DE ESTOS ATAQUES

Los ataques DDoS contra servidores son muy complicados de detectar a tiempo y, sobre todo,
de mitigar. Por suerte, existen varias tcnicas que podemos llevar a cabo en caso de ser atacados
que nos ayudarn a reducir el impacto de estos ataques:

Bloquear IPs. En la red existen listas negras de ordenadores infectados que forman parte de
una botnet. Si las bloqueamos en nuestro servidor, no podrn enviar solicitudes maliciosas.

Aplicar filtros. Estos ataques hacen uso de los diferentes protocolos que hemos visto
anteriormente. Si configuramos varios filtros para omitir el trfico a travs de estos protocolos
evitaremos que el ataque sea efectivo.

SYN cookies. Esta medida de seguridad se basa en enviar al cliente una cookie con la
informacin SYN cifrada, evitando que se pueda saturar la memoria del servidor al dejarla
almacenada.

Balanceo de carga. Si configuramos varios servidores en balanceadores de carga podremos


hacer frente a la sobrecarga aligerando nuestros servidores y dificultando el bloqueo.
Otra forma de protegernos de estos ataques es contratando un CDN, como CloudFlare, que
acte como servidor intermedio impidiendo a los piratas informticos conectar directamente
con nuestro servidor.

You might also like