Actualizado el 21 de Marzo del 2018 (Publicado el 16 de Enero del 2018)
1.163 visualizaciones desde el 16 de Enero del 2018
985,0 KB
13 paginas
Creado hace 18a (17/08/2005)
Utilizando Snort_inline
Técnica
Pierpaolo Palazzoli, Matteo Valenza
Grado de dificultad
El uso de Snort_inline en muchos entornos y escenarios
diferentes ha probado ser una buena estrategia para asegurar
redes internas, redes DMZ u hogareñas.
Para poder trabajar usando el modo drop, se lo debe adaptar a
las características del entorno que se está protegiendo. Por tanto,
no sólo vamos a presentar sus técnicas de configuración sino
también, la forma de añadir un dispositivo dedicado que esté bien
adaptado al entorno a resguardar.
S nort es, básicamente, un sistema de
detección de intrusiones (o IDS de
sus siglas en inglés Intrusion Detec-
tion System), de manera que su funcionalidad
nativa implica el uso de una tarjeta de red que
capte el tráfico de un segmento de red.
Para que Snort_inline analice el tráfico
de un segmento de red, debería ser añadi-
da, de forma transparente y por medio de
dos tarjetas en modo bridge, la funcionali-
dad inline. Dicha funcionalidad se consigue
conduciendo el tráfico a través de iptables
(ip_queue). Sin embargo, esto no es suficien-
te porque necesitamos saber, a través de las
iptables, que tráfico añadir. Gracias a este
modo, Snort_inline, se puede convertir como
cualquier otro sistema de prevención de intru-
siones y bloquear las conexiones que reciba.
Para actuar de este modo, Snort debería ser
compilado para conseguir respuestas flexibles
que permitan restaurar el tráfico que debería
ser bloqueado.
Para concluir, podemos decir que
Snort_inline es definitivamente el modo más
efectivo y preciso disponible; ya que controla
el tráfico basándose en reglas cargadas pre-
viamente.
Snort_inline en una LAN
La primera parte de esta sección será una
breve introducción acerca de Snort_inline en
una LAN.
Asumiremos que el tráfico de la LAN estará
principalmente orientado a clientes. Por tanto po-
demos definir los siguientes tipos de tráfico LAN:
Correo, cliente web, p2p, mensajería instantánea,
spyware, malware, virus, troyanos, vpn.
Una regla común a todos estos tipos de
IDS / IPS es que no podemos analizar tráfico
En este artículo aprenderás...
• Como funciona Snort_inline
• Lo básico sobre sistemas de prevención de
intrusiones
• Como poner a punto la configuración de Snort_
inline
Lo que deberías saber...
• Los fundamentos básicos sobre TCP/IP bajo
Linux
• Principios fundamentales de funcionamiento
de un IDS
2
www.hakin9.org
encriptado, esto quiere decir que no
permite ningún servicio vpn o ssl.
La Figura 1. muestra la solución
correcta para este tipo de protec-
ción, el IPS colocado entre el router
y el resto de la red nos permite ana-
lizar el tráfico que queremos monito-
rear o proteger. Una vez que hemos
colocado adecuadamente el dispo-
sitivo, necesitamos saber las reglas
de Snort y los preprocesadores que
iremos a utiliza.
Supongamos que el archivo de
configuración de Snort es snort_
inline.conf , para ver un ejemplo,
visita www.snortattack.org/mambo/
script/snort_inline.conf – que tiene
los preprocesadores para una LAN
que aparecen en el Listado 1.
Preprocesadores
para LANs
Estos preprocesadores están des-
criptos en el Listado 1. A continua-
ción, hemos hecho una pequeña
lista con una breve descripción de
sus componentes y funciones.
Clamav
Este procesador sólo es instalado si
se especifica durante el proceso de
instalación (--enable-clamav). Esca-
Escenarios para Snort_inline
Sería oportuno decir, que un sistema, el cual tiene como objetivo bloquear intrusiones,
debería ser personalizado y preparado para adaptarse a cualquier tipo de red y de
tráfico. El uso de un IPS (por Sistema de Prevención de Intrusiones, en inglés) inline
no resuelve todos los problemas de seguridad, pero permite construir un sistema de
seguridad central, dinámico y eficiente. Un IPS debería detectar el tráfico desde y
hacia una fuente bajo protección. A través de las interfaces de red en modo bridge, po-
demos añadir un dispositivo a la red de forma transparente y de esta manera recoger
todos los datos necesarios. Pero hay que tener en cuenta que para crear un dispositivo
inline, necesitamos saber todas las características del sistema que vamos a proteger
(desde la capa de red hasta las capas de aplicación).
Más adelante describiremos algunos ejemplos de tipos de segmentos de red para
los cuales la implementación de un IPS inline puede ser conveniente y así asegurar
todo el entorno:
• LAN interna: abarca un conjunto de aplicaciones clientes tales como un navegador,
correo electrónico, messenger, p2p, etc. (Figura 1.).
• DMZ: es un grupo de servidores para proporcionar servicios relacionados con
Internet (smtp, web, ftp, pop3, imap, mysql, etc.) (Figura 2.).
• LAN + DMZ (Figura 3.).
Primero, necesitamos poner Snort_inline en modo IDS (Alerta) durante un tiempo que
sea proporcional al tamaño de la red, en otras palabras, cuanto mayor sea el número de
hosts, necesitaremos más tiempo. Durante este periodo deberíamos:
• Detectar fallos (rendimiento, almacenamiento de datos, etc.)
• Analizar el tráfico para detectar falsos positivos.
Observando los datos recogidos, podemos cambiar la configuración y optimizar el fun-
cionamiento del dispositivo. Deberíamos fijarnos en que la implementación de un IPS
de código abierto, en comparación con uno comercial, puede no ser tan simple como
parece, por lo que podríamos tener problemas al quitar muchos falsos positivos encon-
trados durante la primera parte del procedimiento de puesta a punto.
Recomendamos instalar Snort_inline y organizar los recursos del sistema ade-
cuadamente (CPU, RAM) aplicando los siguientes principios:
• Más reglas requieren mucha RAM y un tráfico elevado lleva a una mayor carga de
la CPU.
• Recientes tests en redes han demostrado que para asegurar una conexión Adsl
(1280 a 256 kbps) se necesita un Geode a 266 MHZ 128 MB RAM (mil reglas).
• Para anchos de banda de mas de 1 Mbps necesitamos un Pentium 4 1 GHZ 512
MB RAM (tres mil reglas).
Snort_inline
nea los virus recogidos en la base de
datos de Clamav y se asegura de que
no estén encriptados o comprimidos.
Este preprocesador es extremada-
mente eficiente bloqueando emails
que han sido infectados usando técni-
cas de phising. Sus funciones son:
• ports: los puertos a escanear (to-
dos, !22 excepto el 22, 110 sólo
el 110)
• toclientonly: define la dirección
del tráfico
• action-drop: le dice al dispositivo
como responder ante un virus
• dbdir: el directorio que contiene
la base de datos con las defini-
ciones de Clamav
• dbreloadtime: cuanto tarda cada
definición en recargarse
Perfmonitor
Este preprocesador nos permite es-
cribir todas las estadísticas referentes
al rendimiento y al tráfico en un archi-
vo de texto, además, es fundamental
para el correcto funcionamiento de
pmgraph, un programa del que habla-
remos más adelante. Este preproce-
sador debería ser activado durante el
proceso de instalación (--enable-perf-
mon). Sus funciones son:
• time: el tiempo necesario para
muestrear la lectura de datos
• File: la ruta del archivo de datos
• pkcnt: el máximo número de re-
gistros contenidos en el archivo
Flow
Este preprocesador es requerido pa-
ra que otros preprocesadores pue-
dan funcionar, tales como flowbits
detection plug-in y flow-portscan, los
(o el preprocesador) preprocesado-
res Flow permiten a Snort mantener
sus mecanismos de adquisición de
datos. Sus funciones son:
• stats _ interval: este parámetro
especifica el intervalo de tiempo
expresado en segundos tras el
que queremos que Snort vuelque
las estadísticas en stdout.
• Hash: este parámetro especifica
el método hash, usando el valor
1 definimos un hash por byte,
www.hakin9.org
3
Técnica
Listado 1. Preprocesadores recomendados para LANs
preprocessor perfmonitor: time 60 file/var/log/snort/perfmon.txt pktcnt 500
preprocessor flow:stats_interval 0 hash 2
preprocessor stream4_reassemble: both
preprocessor stream4: disable_evasion_alerts
midstream_drop_alerts
preprocessor clamav:ports all !22 !443,toclientonly, action-drop,dbdir
/var/lib/clamav,dbreload-time 43200
preprocessor rpc_decode: 111 32771
preprocessor bo
preprocessor telnet_decode
usando el valor 4 definimos un
hash por entero.
Stream 4
Este preprocesador da a Snort la
habilidad de ver la base del paque-
te y donde fue generado (cliente o
servidor), citando a Marty Roesch:
Implementé stream4 con el deseo
de tener gran capacidad de re-en-
samblaje de streams y el deseo de
detener los más recientes ataques
no declarados. Sus funciones son:
• disable _ evasion _ alerts: esta
opción se usa para desactivar las
alertas escritas en stream4.
Figura 1. Configurando el
dispositivo en una LAN
• midstream _ drop _ alerts:
le
dice al preprocesador que blo-
quee las conexiones generadas
sin establecer un flow determi-
nado.
• Rpc decode: este preprocesador
re-ensambla un flujo rpc en un
sólo paquete para que sea más
fácil de analizar, si el preprocesa-
dor stream4 está presente, sólo
analizará el tráfico proveniente
del cliente.
• Telnet decode: este preprocesa-
dor normaliza el flow de caracte-
res de un protocolo telnet en una
sesión. Debemos especificar los
puertos a analizar.
Reglas para LANs
Una vez definidos los preprocesado-
res, Snort necesita colocar las reglas
en el archivo de configuración. Exis-
ten muchas reglas distintas:
• alert: genera un mensaje de
alerta y luego lo guarda en un log
o base de datos.
• log: hace un log en un archivo o
base de datos.
• Pass: ignora el tráfico que ha en-
contrado.
• Drop: pasa el paquete a través
Comentarios de: Hakin9 Utilizando Snort inline (0)
No hay comentarios