Seguridad en Redes

DNSSEC Domain Name System Security Extensions (Extensiones de seguridad para el sistema de nombre de dominios) Su objetivo principal es la protección de corrupción y spoofing de datos, asegura cierto tipo de información del DNS como son algunos elementos de la composición de los paquetes del mismo.

Este tipo de servicio provee a los clientes de validar la autenticación de quien origina la respuesta a una consulta DNS, indicación autenticada de la no existencia de información para los datos solicitados y de la integridad de los datos transferidos.

Proporciona un mecanismo para poder validar la autenticidad y la integridad de los datos contenidos en una zona DNS: • DNSKEY/RRSIG/NSEC Proporciona un mecanismo para delegar la confianza en ciertas claves públicas (cadena de confianza): • DS Proporciona un mecanismo para autenticar las transferencias de zona entre primarios y secundarios: • TSIG Dado que no es un protocolo nuevo y solo es un conjunto de extensiones presenta cambios en el Write Protocol (EDNSO) como es la extensión del tamaño máximo de una respuesta UDP de 512 a 4096 bytes, Agregado de nuevos resource record:  RRSIG: Resource Record Signature  DNSKEY: DNS Public Key  D: Delegation Signer  NSEC: Next Secure Agregado de nuevos flags : • Checking Disabled (CD): indica que no se realiza chequeo.

• Authenticated Data (AD): indica que la respuesta esta autenticada.

Un resource record en DNS es una tupla de cinco valores: nombre, clase, tipo, TTL, valor, por ejemplo, el registro www.empresa.com. 86400 IN A 200.40.100.141 esta representado por la tupla: • Nombre (www.empresa.com) • Clase (IN) • Tipo (A) • TTL (86400 segundos) • Valor (200.40.100.141) Un DNSSEC opera firmando RRSets y no RR individuales, donde un RRSet es un conjunto de RR que comparten igual clase, tipo y nombre. Ejemplo de RRSet con TTL omitido: •www IN A 200.40.241.100 • www IN A 200.40.241.101

Firmas de zona

Se genera un par de claves publica y su correspondiente privada propias de cada zona y no del servidor autoritativo, la privada se debe mantener bajo custodia y firma los RRSets de la Zona, la publica se debe publicar en DNS mediante un registro DNSKEY. Un RRSet puede tener múltiples firmas generadas con diferentes claves. Una firma de un RRSet se devuelve en forma de un registro RRSIG que es parte de la respuesta.

Maneja lo que en criptografía se conoce como clave publica y clave privada, que consiste en el manejo de 2 “llaves” donde una abre y otra cierra el elemento transmitido, lo cual se traduce como una firma digital sobre los datos transmitidos.

Para esto cada Administrador de zona del DNS firmara los RR (Resources Record) utilizando una clave privada para cada zona, luego publicara dichas firmas para cada RR en el archivo de zona correspondiente y por ultimo publicas la clave publica de la zona en el archivo de zona.

Adicionalmente se deberá tener la clave pública de cada zona firmada por la zona del siguiente nivel para asegurar la integridad de los datos.

Cadena de confianza ¿Cómo puede un cliente verificar un RRSet de una cierta zona?

Hace una consulta al DNSKEY correspondiente, realiza los cálculos correspondientes y los compara con RRSIG y si coinciden, la firma verifica, de lo contrario, no. Para confiar en la DNSEY se busca un registro DS en la zona padre ya que los registros DS firman claves de zonas hijas.

Para lograr lo anterior se deben añadir los siguientes registros:    

DNSKEY: guarda la clave publica con la que se firman las zonas.

RRSIG: guarda un hash encriptado del RRSet (encriptado con la clave privada de la zona).

NSEC: guarda la respuesta para que en el caso en el que el nombre requerido o el RR no este en el archivo de zona.

DS: contiene el hash de la clave pública de la zona hija firmada por la clave privada del padre.

IPSec IPsec es una extensión al protocolo IP que proporciona seguridad a IP y a los protocolos de capas superiores. Fue desarrollado para el nuevo estándar IPv6 y después fue portado a IPv4. La arquitectura IPsec se describe en el RFC2401. Los siguientes párrafos dan una pequeña introducción a IPsec.

IPsec emplea dos protocolos diferentes - AH y ESP - para asegurarla autenticación, integridad y confidencialidad de la comunicación. Puede proteger el datagrama IP completo o sólo los protocolos de capas superiores. Estos modos se denominan, respectivamente, modo túnel y modo transporte. En modo túnel el datagrama IP se encapsula completamente dentro de un nuevo datagrama IP que emplea el protocolo IPsec. En modo transporte IPsec sólo maneja la carga del datagrama IP, insertándose la cabecera IPsec entre la cabecera IP y la cabecera del protocolo de capas superiores.

Para proteger la integridad de los datagramas IP, los protocolos IPsec emplean códigos de autenticación de mensaje basados en resúmenes (HMAC - Hash Message Authentication Codes).

Para el cálculo de estos HMAC los protocolos HMAC emplean algoritmos de resumen como MD5 y SHA para calcular un resumen basado en una clave secreta y en los contenidos del datagrama IP. El HMAC se incluye en la cabecera del protocolo IPsec y el receptor del paquete puede comprobar el HMAC si tiene acceso a la clave secreta.

AH lleva un campo (Integrity Check Value) para comprobar la integridad del paquete y que nadie lo ha manipulado durante el trayecto. El valor de ese campo está dado por algoritmos de encriptación tales como MD5 o SHA-1.

Más que usar un checksum convencional, el cual podría no proveer una seguridad real contra una manipulación intencional, este usa una Hashed Message Authentication Code (HMAC), que incorpora una clave secreta mientras se crea el hash. Aunque un atacante puede recalcular un hash fácilmente, sin la clave secreta no sería capaz de crear el ICV apropiado.

HMAC

esta

descrito

por

el RCF

2104 y

se

ilustra

en

la

siguiente

imagen:

Huelga decir que IPsec no define ni obliga como debe hacerse la autentificación, simplemente ofrece un marco de seguridad en la que los dos hosts que realizan la comunicación se ponen de acuerdo sobre que sistema usar. Pueden usarse firmas digitales o funciones de encriptación, pero es obligatorio que ambos los conozcan y sepan como usarlos

Para proteger la confidencialidad de lo datagramas IP, los protocolos IPsec emplean algoritmos estándar de cifrado simétrico. El estándar IPsec exige la implementación de NULL y DES. En la actualidad se suelen emplear algoritmos más fuertes: 3DES, AES y Blowfish.

Para protegerse contra ataques por denegación de servicio, los protocolos IPsec emplean ventanas deslizantes. Cada paquete recibe un número de secuencia y sólo se acepta su recepción si el número de paquete se encuentra dentro de la ventana o es posterior. Los paquetes anteriores son descartados inmediatamente. Esta es una medida de protección eficaz contra ataques por repetición de mensajes en los que el atacante almacena los paquetes originales y los reproduce posteriormente.

Para que los participantes de una comunicación puedan encapsular y desencapsular los paquetes IPsec, se necesitan mecanismos para almacenar las claves secretas, algoritmos y direcciones IP involucradas en la comunicación. Todos estos parámetros se almacenan en asociaciones de seguridad (SA - Security Associations). Las asociaciones de seguridad, a su vez, se almacenan en bases de datos de asociaciones de seguridad (SAD - Security Asocciation Databases).

Cada asociación de seguridad define los siguientes parámetros:

   

Dirección IP origen y destino de la cabecera IPsec resultante. Estas son las direcciones IP de los participantes de la comunicación IPsec que protegen los paquetes.

Protocolo IPsec (AH o ESP). A veces, se permite compresión (IPCOMP).

El algoritmo y clave secreta empleados por el protocolo IPsec. Índice de parámetro de seguridad (SPI - Security Parameter Index). Es un número de 32 bits que identifica la asociación de seguridad.

Algunas implementaciones de la base de datos de asociaciones de seguridad permiten almacenar más parámetros:   

Modo IPsec (túnel o transporte) Tamaño de la ventana deslizante para protegerse de ataques por repetición.

Tiempo de vida de una asociación de seguridad.

En una asociación de seguridad se definen las direcciones IP de origen y destino de la comunicación. Por ello, mediante una única SA sólo se puede proteger un sentido del tráfico en una comunicación IPsec full duplex. Para proteger ambos sentidos de la comunicación, IPsec necesita de dos asociaciones de seguridad unidireccionales.

Las asociaciones de seguridad sólo especifican cómo se supone que IPsec protegerá el tráfico. Para definir qué tráfico proteger, y cuándo hacerlo, se necesita información adicional. Esta información se almacena en la política de seguridad (SP - Security Policy), que a su vez se almacena en la base de datos de políticas de seguridad (SPD - Security Policy Database).

Una política de seguridad suele especificar los siguientes parámetros:  



Direcciones de origen y destino de los paquetes por proteger. En modo transportes estas serán las mismas direcciones que en la SA. En modo túnel pueden ser distintas.

Protocolos y puertos a proteger. Algunas implementaciones no permiten la definición de protocolos específicos a proteger. En este caso, se protege todo el tráfico entre las direcciones IP indicadas.

La asociación de seguridad a emplear para proteger los paquetes.

La configuración manual de la asociación de seguridad es proclive a errores, y no es muy segura.

Las claves secretas y algoritmos de cifrado deben compartirse entre todos los participantes de la VPN. Uno de los problemas críticos a los que se enfrenta el administrador de sistemas es el intercambio de claves: ¿cómo intercambiar claves simétricas cuando aún no se ha establecido ningún tipo de cifrado?

Para resolver este problema se desarrolló el protocolo de intercambio de claves por Internet (IKE Internet Key Exchange Protocol). Este protocolo autentica a los participantes en una primera fase.

En una segunda fase se negocian las asociaciones de seguridad y se escogen las claves secretas simétricas a través de un intercambio de claves Diffie Hellmann. El protocolo IKE se ocupa incluso de renovar periódicamente las claves para asegurar su confidencialidad.

Los protocolos IPsec La familia de protocolos IPsec está formada por dos protocolos: el AH (Authentication Header Cabecera de autenticación) y el ESP (Encapsulated Security Payload - Carga de seguridad encapsulada). Ambos son protocolos IP independientes. AH es el protocolo IP 51 y ESP el protocolo IP 50. Las siguientes secciones tratarán brevemente sobre sus propiedades: AH - Cabecera de autenticación El protocolo AH protege la integridad del datagrama IP. Para conseguirlo, el protocolo AH calcula una HMAC basada en la clave secreta, el contenido del paquete y las partes inmutables de la cabecera IP (como son las direcciones IP). Tras esto, añade la cabecera AH al paquete. La cabecera AH se muestra en Figure 2.

Figure 2. La cabecera AH protege la integridad del paquete La cabecera AH mide 24 bytes. El primer byte es el campo Siguiente cabecera. Este campo especifica el protocolo de la siguiente cabecera. En modo túnel se encapsula un datagrama IP completo, por lo que el valor de este campo es 4. Al encapsular un datagrama TCP en modo transporte, el valor correspondiente es 6. El siguiente byte especifica la longitud del contenido del paquete. Este campo está seguido de dos bytes reservados. Los siguientes 4 bytes especifican en Índice de Parámetro de Seguridad (SPI). El SPI especifica la asociación de seguridad (SA) a emplear para el des encapsulado del paquete. El Número de Secuencia de 32 bit protege frente a ataques por repetición. Finalmente, los últimos 96 bit almacenan el código de resumen para la autenticación de mensaje (HMAC). Este HMAC protege la integridad de los paquetes ya que sólo los miembros de la comunicación que conozcan la clave secreta pueden crear y comprobar HMACs.

Como el protocolo AH protege la cabecera IP incluyendo las partes inmutables de la cabecera IP como las direcciones IP, el protocolo AH no permite NAT. NAT (Network address translation Traducción de direcciones de red, también conocido como Enmascaramiento de direcciones) remplaza una dirección IP de la cabecera IP (normalmente la IP de origen) por una dirección IP diferente. Tras el intercambio, la HMAC ya no es válida. La extensión a IPsec NAT-transversal implementa métodos que evitan esta restricción.

AH está dirigido a garantizar integridad sin conexión y autenticación de los datos de origen de los datagramas IP. Para ello, calcula un Hash Message Authentication Code (HMAC) a través de algún algoritmo hash operando sobre una clave secreta, el contenido del paquete IP y las partes inmutables del datagrama. Este proceso restringe la posibilidad de emplear NAT, que puede ser implementada con NAT transversal. Por otro lado, AH puede proteger opcionalmente contra ataques de repetición utilizando la técnica de ventana deslizante y descartando paquetes viejos.

AH protege la carga útil IP y todos los campos de la cabecera de un datagrama IP excepto los campos mutantes, es decir, aquellos que pueden ser alterados en el tránsito. En IPv4, los campos de la cabecera IP mutantes (y por lo tanto no autenticados) incluyen TOS, Flags, Offset de fragmentos, TTL y suma de verificación de la cabecera. AH opera directamente por encima de IP, utilizando el protocolo IP número 51. Una cabecera AH mide 32 bits, he aquí un diagrama de cómo se organizan: * next hdr Identifica cuál es el siguiente protocolo, es decir, cual es el protocolo que será autentificado, cuál es el payload. 

AH len El tamaño del paquete AH.



RESERVED Reservado para futuras aplicaciones. Debe estar a 0



Security parameters index (SPI) Indica los parámetros de seguridad, que en combinación con los parámetros IP, identifican la asociación de seguridad del paquete



Sequence Number Es un número creciente usado para prevenir ataques por repetición. El número está incluido en los datos encriptados, así que cualquier alteración será detectada



Authentication Data Contiene el valor de identificación de integridad. Puede contener relleno. Se calcula sobre el paquete entero, incluidas la mayoría de las cabeceras. El que recibe calcula otra vez el hash, y si este no coincide, el paquete se tira.

AH en Modo Transporte

La manera más fácil de entender el modo transporte es que protege el intercambio de información entre dos usuarios finales. La protección puede ser autentificación o encriptación (o las dos), pero no se hace usando un túnel (para eso está el modo túnel). No es una VPN, es una simple conexión segura entre dos usuarios finales.

En AH en Modo Transporte, el paquete IP es modificado ligeramente para incluir una nueva cabecera AH entre la cabecera IP y la información transmitida (TCP, UDP, etc.) y después se requiere un proceso “de arrastre” que interconecta las distintas cabeceras entre ellas.

Este proceso “de arrastre” se necesita para que el paquete original IP sea reconstituido cuando llegue a su destino; cuando las cabeceras IPsec han sido validadas en el receptor, se despojan las cabeceras IPsec y la carga a transmitir (TCP, UDP, etc.) es guardada nuevamente en la cabecera IP. Cuando el paquete llega a su siguiente destino y pasa el test de autenticidad, la cabecera AH es quitada y el campo proto=AH es remplazado con el siguiente protocolo de la carga transmitida (TCP, UDP, etc.). Esto pone al datagrama es su estado original, y puede ser enviado al proceso original.

AH en Modo Túnel

El modo túnel es el más común para dar una funcionalidad de VPN, donde un paquete IP es encapsulado dentro de otro y enviado a su destino.

Igual que en el modo transporte, el paquete es “sellado” con un ICV para autentificar al que envía la información para prevenir modificaciones durante el tránsito. Pero a diferencia del modo de transporte, el modo túnel encapsula todo el paquete IP, no sólo la carga útil (TCP, UDP ,etc.). Esto hace que el destinatario del paquete sea uno diferente al destinatario original. Esto ayuda a la formación de un túnel.

Cuando un paquete en modo túnel llega a su destino, pasa el mismo proceso de autentificación igual que cualquier paquete AH-IPsec. Este proceso hace que se despoje de sus cabeceras IP y AH, luego nos queda el datagrama original, que es enrutado mediante un proceso normal.

La mayoría de las implementaciones tratan el final del túnel como una interfaz de red virtual -exactamente igual que una Ethernet o localhost - y el tráfico entrante y saliente de él está sujeto a todas las decisiones normales de enrutamiento.

El paquete reconstituido puede ser entregado a la máquina local o enrutado donde sea (dependiendo de la dirección IP encontrada en el paquete encapsulado), pero de ninguna manera vuelve a estar sujeto a las protección de IPsec. Esta finaliza al final del túnel. A partir de allí es tratado como un datagrama IP normal.

Tal como el modo de transporte es usado estrictamente para asegurar conexiones de extremo a extremo entre dos ordenadores, el modo túnel es usado normalmente entre pasarelas (routers, firewalls o dispositivos VPN) para proveer una Red Privada Virtual (VPN).

ESP - Carga de Seguridad Encapsulada El protocolo ESP puede asegurar la integridad del paquete empleando una HMAC y la confidencialidad empleando cifrado. La cabecera ESP se genera y añade al paquete tras cifrarlo y calcular su HMAC. La cabecera ESP consta de dos partes y se muestra en Figure 3.

Figure 3. La cabecera ESP Los primeros 32 bits de la cabecera ESP especifican el Índice de Parámetros de Seguridad (SPI).

Este SPI especifica qué SA emplear para desencapsular el paquete ESP. Los siguientes 32 bits almacenan el Número de Secuencia. Este número de secuencia se emplea para protegerse de ataques por repetición de mensajes. Los siguientes 32 bits especifican el Vector de

Inicialización (IV - Initialization Vector) que se emplea para el proceso de cifrado. Los algoritmos de cifrado simétrico pueden ser vulnerables a ataques por análisis de frecuencias si no se emplean IVs. El IV asegura que dos cargas idénticas generan dos cargas cifradas diferentes.

IPsec emplea cifradores de bloque para el proceso de cifrado. Por ello, puede ser necesario rellenar la carga del paquete si la longitud de la carga no es un múltiplo de la longitud del paquete.

En ese caso se añade la longitud del relleno (pad length). Tras la longitud del relleno se coloca el campo de 2 bytes Siguiente cabecera que especifica la siguiente cabecera. Por último, se añaden los 96 bit de HMAC para asegurar la integridad del paquete. Esta HMAC sólo tiene en cuenta la carga del paquete: la cabecera IP no se incluye dentro de su proceso de cálculo.

El uso de NAT, por lo tanto, no rompe el protocolo ESP. Sin embargo, en la mayoría de los casos, NAT aún no es compatible en combinación con IPsec. NAT-Transversal ofrece una solución para este problema encapsulando los paquetes ESP dentro de paquetes UDP. Añadir encriptación hace que ESP sea un poco más complicado, ya que la encapsulación rodea a la carga útil es algo más que precederla con AH: ESP incluye cabecera y campos para dar soporte a la encriptación y a una autentificación opcional. Además, provee los modos de transporte y túnel, los cuales nos son ya familiares.

Las RFCs de IPsec no insisten demasiado en un sistema particular de encriptación, pero normalmente se utiliza DES, triple-DES, AES o Blowfish para asegurar la carga útil de “ojos indiscretos”. El algoritmo usado para una conexión en particular es definido por la Security Association (SA), y esta SA incluye no sólo la el algoritmo, también la llave usada.

A diferencia de AH, que da una pequeña cabecera antes de la carga útil, ESP rodea la carga útil con su protección. Los parámetros de seguridad Index y Sequence Number tienen el mismo propósito que en AH, pero nos encontramos como relleno en la cola del paquete el campo “siguiente campo” y el opcional “Authentication data”.

Es posible usar ESP sin ninguna encriptación (usar el algoritmo NULL), sin embargo estructura el paquete de la misma forma. No nos da ninguna confidencialidad a los datos que estamos transmitiendo, y sólo tiene sentido usarlo con una la autentificación ESP. No tiene sentido usar ESP sin encriptación o autentificación (a no ser que estemos simplemente probando el protocolo).

El relleno sirve para poder usar algoritmos de encriptación orientados a bloques, dado que tenemos que crear una carga a encriptar que tenga un tamaño múltiplo de su tamaño de bloque.

El tamaño del relleno viene dado por el campo pad len. El campo next hdr nos da el tipo (IP, TCP, UDP, etc.) de la carga útil, aunque esto sea usado como un punto para volver hacia atrás en el paquete para ver que hay en el AH. Además de la encriptación, ESP puede proveer autentificación con la misma HMAC de AH. A diferencia de AH, esta autentifica sólo la cabecera ESP y la carca útil encriptada, no todo el paquete IP. Sorprendentemente, esto no hace que la seguridad de la autentificación más débil, pero nos da algunos beneficios importantes.

Cuando un forastero examina un paquete IP que contiene datos ESP, es prácticamente imposible adivinar que es lo que tiene dentro, excepto por los datos encontrados en la cabecera IP (siendo

interesantes las direcciones IP de origen y destino). El atacante va a saber casi seguro que son datos ESP (está en la cabecera que son datos ESP), pero no va a saber de que tipo es la carga útil.

Incluso la presencia de Authentication Data no puede ser determina solamente con mirar al paquete. Esta resolución está hecha por la Security Parameters Index, que hace referencia al conjunto de parámetros pre compartidos para esta conexión.

ESP en Modo Transporte Al igual que en AH, el modo transporte encapsula justamente la carga la carga útil del datagrama y está diseñado justamente para comunicaciones extremo-a-extremo. La cabecera IP original se deja (excepto por el campo cambiado Protocol), y esto hace - además de otras cosas - que las direcciones IP de origen y destino se quedan como están.

ESP en Modo Túnel El ESP en modo Túnel encapsula el datagrama IP entero y lo encripta:

Proveer una conexión encriptada en modo túnel es dar una forma muy cercana a como se crea una VPN, y es lo que se nos viene a la cabeza a la mayoría cuando pensamos acerca de IPsec.

Además de esto, tenemos que añadir autentificación. Esta parte se trata en la siguiente sección.

A diferencia de AH, donde un forastero puede ver fácilmente que es lo que se transmite en modo Túnel o Transporte, usando ESP eso no ocurre; esa información no está disponible para el forastero. El caso es que en el modo túnel (poniendo next=IP), el datagrama IP entero original es parte de la carga útil encriptada, y no será visible para nadie que no pueda desencriptar el paquete.

FIREWALLS Un Firewall es un sistema (o conjunto de ellos) ubicado entre dos redes y que ejerce la una política de seguridad establecida. Es el mecanismo encargado de proteger una red confiable de una que no lo es (por ejemplo Internet).

Puede consistir en distintos dispositivos, tendientes a los siguientes objetivos: 1. Todo el tráfico desde dentro hacia fuera, y viceversa, debe pasar a través de él.

2. Sólo el tráfico autorizado, definido por la política local de seguridad, es permitido.

Como puede observarse, el Muro Cortafuegos, sólo sirven de defensa perimetral de las redes, no defienden de ataques o errores provenientes del interior, como tampoco puede ofrecer protección una vez que el intruso lo traspasa.

Algunos Firewalls aprovechan esta capacidad de que toda la información entrante y saliente debe pasar a través de ellos para proveer servicios de seguridad adicionales como la encriptación del tráfico de la red. Se entiende que si dos Firewalls están conectados, ambos deben "hablar" el mismo método de encriptación-desencriptación para entablar la comunicación.

Tipos de Firewall 1. Filtrado de Paquetes Se utilizan Routers con filtros y reglas basadas en políticas de control de acceso. El Router es el encargado de filtrar los paquetes (un Choke) basados en cualquiera de los siguientes criterios: 1. Protocolos utilizados.

2. Dirección IP de origen y de destino.

3. Puerto TCP-UDP de origen y de destino.

Estos criterios permiten gran flexibilidad en el tratamiento del tráfico. Restringiendo las comunicaciones entre dos computadoras (mediante las direcciones IP) se permite determinar entre cuales máquinas la comunicación está permitida.

El filtrado de paquetes mediante puertos y protocolos permite establecer que servicios estarán disponibles al usuario y por cuales puertos. Se puede permitir navegar en la WWW (puerto 80 abierto) pero no acceder a la transferencia de archivos vía FTP (puerto 21 cerrado).

Debido a su funcionamiento y estructura basada en el filtrado de direcciones y puertos este tipo de Firewalls trabajan en los niveles de Transporte y de Red del Modelo OSI y están conectados a ambos perímetros (interior y exterior) de la red.

Tienen la ventaja de ser económicos, tienen un alto nivel de desempeño y son transparentes para los usuarios conectados a la red. Sin embargo presenta debilidades como: 1. No protege las capas superiores a nivel OSI. 2. Las necesidades aplicativas son difíciles de traducir como filtros de protocolos y puertos.

3. No son capaces de esconder la topología de redes privadas, por lo que exponen la red al mundo exterior.

4. Sus capacidades de auditoría suelen ser limitadas, al igual que su capacidad de registro de actividades.

5. No soportan políticas de seguridad complejas como autentificación de usuarios y control de accesos con horarios prefijados.

2. Proxy-Gateways de Aplicaciones Para evitar las debilidades asociadas al filtrado de paquetes, los desarrolladores crearon software de aplicación encargados de filtrar las conexiones. Estas aplicaciones son conocidas como Servidores Proxy y la máquina donde se ejecuta recibe el nombre de Gateway de Aplicación o Bastion Host.

El Proxy, instalado sobre el Nodo Bastión, actúa de intermediario entre el cliente y el servidor real de la aplicación, siendo transparente a ambas partes.

Cuando un usuario desea un servicio, lo hace a través del Proxy. Este, realiza el pedido al servidor real devuelve los resultados al cliente. Su función fue la de analizar el tráfico de red en busca de contenido que viole la seguridad de la misma.

Gráficamente:

3. Dual-Homed Host Son dispositivos que están conectados a ambos perímetros (interior y exterior) y no dejan pasar paquetes IP (como sucede en el caso del Filtrado de Paquetes), por lo que se dice que actúan con el "IP-Forwarding desactivado".

Un usuario interior que desee hacer uso de un servicio exterior, deberá conectarse primero al Firewall, donde el Proxy atenderá su petición, y en función de la configuración impuesta en dicho Firewall, se conectará al servicio exterior solicitado y hará de puente entre este y el usuario interior.

Es decir que se utilizan dos conexiones. Uno desde la máquina interior hasta el Firewall y el otro desde este hasta la máquina que albergue el servicio exterior.

4. Screened Host En este caso se combina un Router con un host bastión y el principal nivel e seguridad proviene del filtrado de paquetes. En el bastión, el único sistema accesible desde el exterior, se ejecuta el Proxy de aplicaciones y en el Choke se filtran los paquetes considerados peligrosos y sólo se permiten un número reducido de servicios.

5. Screened Subnet En este diseño se intenta aislar la máquina más atacada y vulnerable del Firewall, el Nodo Bastión. Para ello se establece una Zona Desmilitarizada (DMZ) de forma tal que sin un intruso accede a esta máquina no consiga el acceso total a la subred protegida.

En este esquema se utilizan dos Routers: uno exterior y otro interior. El Router exterior tiene la misión de bloquear el tráfico no deseado en ambos sentidos: hacia la red interna y hacia la red externa. El Router interior hace lo mismo con la red interna y la DMZ (zona entre el Router externo y el interno).

Es posible definir varios niveles de DMZ agregando más Routers, pero destacando que las reglas aplicadas a cada uno deben ser distintas ya que en caso contrario los niveles se simplificarían a uno solo.

Como puede apreciarse la Zona Desmilitarizada aísla físicamente lo s servicios internos, separándolos de los servicios públicos. Además, n o existe una conexión directa entre la red interna y la externa.

Los sistemas Dual-Homed Host y Screnned pueden ser complicados de configurar y comprobar, lo que puede dar lugar, paradójicamente, a importantes agujeros de seguridad en toda la red. En cambio, si se encuentran bien configurados y administrados pueden brindar un alto grado de protección y ciertas ventajas: Ocultamiento de la información: los sistemas externos no deben conocer el nombre de los sistemas internos. El Gateway de aplicaciones es el único autorizado a conectarse con el exterior y el encargado de bloquear la información no solicitada o sospechosa.

1. Registro de actividades y autenticación robusta: El Gateway requiere de autenticación cuando se realiza un pedido de datos externos. El registro de actividades se realiza en base a estas solicitudes.

2. Reglas de filtrado menos complejas: Las reglas del filtrado de los paquetes por parte del Router serán menos compleja dado a que él sólo debe atender las solicitudes del Gateway.

Así mismo tiene la desventaja de ser intrusivos y no transparentes para el usuario ya que generalmente este debe instalar algún tipo de aplicación especializada para lograr la comunicación. Se suma a esto que generalmente son más lentos porque deben revisar todo el tráfico de la red.

6. Inspección de Paquetes Este tipo de Firewalls se basa en el principio de que cada paquete que circula por la red es inspeccionado, así como también su procedencia y destino. Se aplican desde la capa de Red hasta la de Aplicaciones. Generalmente son instalados cuando se requiere seguridad sensible al contexto y en aplicaciones muy complejas.

7. Firewalls Personales Estos Firewalls son aplicaciones disponibles para usuarios finales que desean conectarse a una red externa insegura y mantener su computadora a salvo de ataques que puedan ocasionarle desde un simple "cuelgue" o infección de virus hasta la pérdida de toda su información almacenada.

DMZ La DMZ o zona desmilitarizada es tan solo un complemento mas de seguridad implementados para la protección de LAN’s de diversas compañías u organizaciones que consiste en aislar un pequeño segmento de la red o subred para que pueda ser accedida desde una red externa para el intercambio de información sin que se ponga en riesgo el acceso de la red general, se encarga por lo general de las políticas de seguridad siguientes: 

El tráfico de la red externa a la DMZ está autorizado



El tráfico de la red externa a la red interna está prohibido



El tráfico de la red interna a la DMZ está autorizado



El tráfico de la red interna a la red externa está autorizado



El tráfico de la DMZ a la red interna está prohibido



El tráfico de la DMZ a la red externa está denegado

Los servidores en la DMZ se denominan "anfitriones bastión" ya que actúan como un puesto de avanzada en la red de la compañía.

Cuando algunas máquinas de la red interna deben ser accesibles desde una red externa (servidores web, servidores de correo electrónico, servidores FTP), a veces es necesario crear una nueva interfaz hacia una red separada a la que se pueda acceder tanto desde la red interna como por vía externa sin correr el riesgo de comprometer la seguridad de la compañía. El término "zona desmilitarizada" o DMZ hace referencia a esta zona aislada que posee aplicaciones disponibles para el público. La DMZ actúa como una "zona de búfer" entre la red que necesita protección y la red hostil.

Para asegurar un DMZ se debe usar un firewall con la configuración de tres patas que será descrita y se mostrar como realizar a continuación.

Los elementos principales son la maquina con 3 interfaces que hace de router y los 2 servidores en la DMZ. Vamos a suponer unas cuestiones previas que nuestro firewall debe cumplir: 1. Los clientes de la red local deben tener acceso a internet transparente. Todos los protocolos y servicios.

2. En el SERV1 hay un servidor WEB y SSH. En SER2 hay un servidor SSH y un servidor WEB escuchando en el puerto 1312.

3. Aunque el router que nos conecta hace NAT entre la dirección pública y nuestra red privada, es necesario hacer otra vez NAT en la interfaz eth1, dado que no podemos modificar la tabla de encaminamientos de router.

4. En la maquina router servirá SSH a internet a través del puerto 22220 y por el resto de interfaces por el puerto 22.

5. El puerto 22 de la maquina router será renviado al puerto 22 de SER2.

6. Debe estar controlado el tráfico entrante/saliente de la DMZ hacia la LAN para evitar sorpresas.

A continuación se creara un script para el servicio en /etc/init.d/. Este script permitirá alterar rápidamente entre poner y quitar el firewall, dejando siempre las reglas de encaminamiento y direcciones intactas.

Para a帽adir el script de init.d al arranque del sistema y que nuestro debian lo adapte, de se debe hacer:

Ahora se crean los siguientes ficheros de configuraci贸n de iptables. Uno con las reglas de encaminamiento y no las de firewall y otro con ambas.

A continuación el fichero con la configuración de iptables “fuerte”

Se deben gestionar los permisos adecuados de lectura/escritura/ejecución para estos ficheros.

Copiando el script y sustituyendo las variables puede adaptarse rápida y fácilmente a las necesidades de otra red u otra configuración similar.

Los firewalls con iptables pueden llegar a ser muy restrictivos y muy concretos en el trafico que se permite/deniega. Esta es una configuración bastante rápida y permisiva, pero eficaz como punto de partida para un ajuste mucho mas fino.

SISTEMAS DE DETECCION DE INTRUSOS

Un IDS (intruder detection system) o sistema d detección de intrusos es una herramienta o sistema de seguridad que monitorea el trafico en una red y los eventos ocurridos en un determinado sistema informático, para así poder identificar los intentos de ataques o amenazas que puedan comprometer la seguridad y el desempeño de dicho sistema. El desempeño de los IDS se basa en la búsqueda y análisis de patrones previamente definidos que impliquen cualquier tipo de actividad sospechosa o maliciosa sobre una red o host.

Los IDS aportan a la seguridad una capacidad de prevención y de alerta anticipada ante cualquier actividad sospechosa. Los IDS incrementan la seguridad de algún sistema o red vigilando el tráfico, examinando los paquetes en busca de datos sospechosos que puedan afectar a los elementos de la red.

Para que un IDS pueda funcionar correctamente en una red establecida detectando posibles amenazas o intrusiones, este sistema de seguridad se compone de los siguientes elementos:     

Fuentes de recolección de datos: su propósito es conseguir de una manera eficiente todos los datos necesarios durante el proceso de detección de intrusos. Estas fuentes pueden ser un log o el software de base de datos.

Reglas de contenido de datos: contienen los patrones para detectar anomalías de seguridad en el sistema.

Filtros: para analizar y comparar el trafico monitoreado en la red de acuerdo a las reglas de contenido de datos.

Detectores de eventos anormales en el tráfico de red: permite al IDS desempañar su función como detector de intrusos y amenazas para que posteriormente se evite algún ataque a la red.

Dispositivo generador de informes y alarmas: el IDS cuneta con sensores y dispositivos que le permiten avisar al administrador sobre posibles amenazas que pueden afectar el desempeño y funcionamiento de los elementos en la red.

Un log es el registro de actividad de un sistema que generalmente se guarda en un fichero o base de datos y al que se la van añadiendo información a medida que se realizan acciones sobre el sistema.

Los tipos más importantes de IDSes mencionados en el campo de seguridad son conocidos como IDSes basados en host y basados en red. Un IDSes basado en host es el más completo de los dos, que implica la implementación de un sistema de detección en cada host individual. Sin importar en qué ambiente de red resida el host, estará protegido. Un IDS basado en la red filtra los paquetes a través de un dispositivo simple antes de comenzar a enviar a host específicos. Los IDSes basados en red a menudo se consideran como menos completos puestos que muchos host en un ambiente móvil lo hacen indisponible para el escaneo y protección de paquetes de red.

IDS basados en host Un IDS basado en host analiza diferentes áreas para determinar el uso incorrecto (actividades maliciosas o abusivas dentro de la red) o alguna intrusión (violaciones desde afuera). Los IDSes basados en host consultan diferentes tipos de registros de archivos (kernel, sistema, servidores, red, cortafuegos, y más) y comparan los registros contra una base de datos interna de peculiaridades comunes sobre ataques conocidos. Los IDSes basados en host de Linux y Unix hacen uso extensivo de syslog y de su habilidad para separar los eventos registrados por severidad (por ejemplo, mensajes menores de impresión versus advertencias importantes del kernel). El comando syslog está disponible cuando se instala el paquete syslog, incluido con Red Hat

Enterprise Linux. Este paquete proporciona el registro de mensajes del sistema y del kernel. Los IDSes basados en hosts filtran los registros (lo cual, en el caso de algunas redes y registros de eventos del kernel pueden ser bastante detallados), los analizan, vuelven a etiquetar los mensajes anómalos con su propia clasificación de severidad y los reúne en su propio registro para que sean analizados por el administrador.

Los IDSes basados en host también pueden verificar la integridad de los datos de archivos y ejecutables importantes. Funciona verificando una base de datos de archivos confidenciales (y cualquier archivo añadido por el administrador) y crea una suma de verificación de cada archivo con una utilidad de resumen de archivos de mensajes tal como md5sum (algoritmo de 128-bit) o sha1sum (algoritmo de 160-bit). El IDS basado en host luego almacena las sumas en un archivo de texto plano y periódicamente compara las sumas de verificación contra los valores en el archivo de texto. Si cualquiera de estas sumas no coinciden, el IDS alertará al administrador a través de un correo electrónico o a un mensaje al celular. Este es el proceso utilizado por Tripwire, que es el IDS basado en host más popular para Linux. Los desarrolladores de Tripwire, Tripwire, Inc., abrieron recientemente el código fuente para la versión Linux y lo licenciaron bajo los términos de la Licencia Pública General GNU. IDS basados en red Los sistemas de detección de intrusos basados en la red operan de una forma diferente que aquellos IDSes basados en host. La filosofía de diseño de un IDS basado en la red es escanear los paquetes de red al nivel del enrutador o host, auditar la información de los paquetes y registrar cualquier paquete sospechoso en un archivo de registros especial con información extendida.

Basándose en estos paquetes sospechosos, un IDS basado en la red puede escanear su propia base de datos de firmas de ataques a la red y asignarles un nivel de severidad para cada paquete. Si los niveles de severidad son lo suficientemente altos, se enviará un correo electrónico o un mensaje de pager de advertencia a los miembros del equipo de seguridad para que ellos puedan investigar la naturaleza de la anomalía.

Los IDSes basados en la red se han vuelto muy populares a medida en que la Internet ha crecido en tamaño y tráfico. Los IDSes que son capaces de escanear grandes volúmenes de actividad en la red y exitosamente etiquetar transmisiones sospechosas, son bien recibidos dentro de la industria de seguridad. Debido a la inseguridad inherente de los protocolos TCP/IP, se ha vuelto imperativo desarrollar escaners, huzmeadores y otras herramientas de auditoria y detección para así prevenir violaciones de seguridad por actividades maliciosas en la red, tales como: 

Engaño de direcciones IP (IP Spoofing)



ataques de rechazo de servicio (DoS)



envenenamiento de caché arp



Corrupción de nombres DNS



ataques de hombre en el medio

La mayoría de los IDSes basados en la red requieren que el dispositivo de red del sistema host sea configurado a modo promiscuo, lo cual permite al dispositivo capturar todos los paquetes que

pasan por la red. El modo promiscuo puede ser configurado a través del comando ifconfig, tal como sigue:

ifconfig eth0 promisc Al ejecutar ifconfig sin ninguna opción revela que eth0 está ahora en modo promiscuo (PROMISC).

eth0

Link encap:Ethernet HWaddr 00:00:D0:0D:00:01 inet addr:192.168.1.50 Bcast:192.168.1.255 Mask:255.255.252.0 UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:6222015 errors:0 dropped:0 overruns:138 frame:0 TX packets:5370458 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:2505498554 (2389.4 Mb) TX bytes:1521375170 (1450.8 Mb) Interrupt:9 Base address:0xec80 lo

Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:21621 errors:0 dropped:0 overruns:0

frame:0 TX packets:21621 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1070918 (1.0 Mb)

TX bytes:1070918 (1.0

Mb) Usando una herramienta tal como tcpdump (incluida con Red Hat Enterprise Linux), se pueden ver las grandes cantidades de tráfico pasando a través de la red:

tcpdump: listening on eth0 02:05:53.702142 pinky.example.com.ha-cluster > \ heavenly.example.com.860: udp 92 (DF) 02:05:53.702294 heavenly.example.com.860 > \ pinky.example.com.ha-cluster: udp 32 (DF) 02:05:53.702360 pinky.example.com.55828 > dns1.example.com.domain: \ PTR? 192.35.168.192.in-addr.arpa. (45) (DF) 02:05:53.702706 ns1.example.com.domain > pinky.example.com.55828: \ 6077 NXDomain* 0/1/0 (103) (DF)

02:05:53.886395 shadowman.example.com.netbios-ns > \ 172.16.59.255.netbios-ns: NBT UDP PACKET(137): QUERY; BROADCAST 02:05:54.103355 802.1d config c000.00:05:74:8c:a1:2b.8043 root \ 0001.00:d0:01:23:a5:2b pathcost 3004 age 1 max 20 hello 2 fdelay 15 02:05:54.636436 konsole.example.com.netbios-ns > 172.16.59.255.netbios-ns:\ NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST 02:05:56.323715 pinky.example.com.1013 > heavenly.example.com.860:\ udp 56 (DF) 02:05:56.323882 heavenly.example.com.860 > pinky.example.com.1013:\ udp 28 (DF)

Ahora veamos uno de los IDS mas comunes y poderosos que puede ser tratado como cualquiera de los dos tipos anteriores, su nombre es SNORT. Snort (http://www.snort.org/) está disponible bajo licencia GPL, gratuito y funciona bajo plataformas Windows y UNIX/Linux. Es uno de los más usados y dispone de una gran cantidad de filtros o patrones ya predefinidos, así como actualizaciones constantes ante casos de ataques, barridos o vulnerabilidades que vayan siendo detectadas a través de los distintos boletines de seguridad.

Este IDS implementa un lenguaje de creación de reglas flexibles, potente y sencillo. Durante su instalación ya nos provee de cientos de filtros o reglas para backdoor, ddos, finger, ftp, ataques web, CGI, escaneos Nmap, etc.

Puede funcionar como sniffer (podemos ver en consola y en tiempo real qué ocurre en nuestra red, todo nuestro tráfico), registro de paquetes (permite guardar en un archivo los logs para su posterior análisis, un análisis offline) o como un IDS normal (en este caso NIDS).

En este taller daremos una importancia mayor a su funcionamiento como NIDS y, sobre todo, a la creación personalizada de reglas e interpretación de las alertas.

La colocación de Snort en nuestra red puede realizarse según el tráfico quieren vigilar: paquetes que entran, paquetes salientes, dentro del firewall, fuera del firewall… y en realidad prácticamente donde queramos.

Una característica muy importante e implementada desde hace pocas versiones es FlexResp.

Permite, dada una conexión que emita tráfico malicioso, darla de baja, hacerle un DROP mediante el envío de un paquete con el flag RST activa, con lo cual cumpliría funciones de firewall, cortando las conexiones que cumplan ciertas reglas predefinidas. No sólo corta las conexiones ya que puede realizar otras muchas acciones. Veremos más adelante su funcionamiento y ejemplos.

NOTA: Todos los ejemplos, mientras no se indique lo contrario, serรกn vรกlidos para win32 y Linux/UNIX.

C:\Snort20\bin>snort -*> Snort! <*Version 2.0.0-ODBC-MySQL-FlexRESP-WIN32 (Build 72)

By Martin Roesch (roesch@sourcefire.com, www.snort.org) 1.7-WIN32 Port By Michael Davis (mike@datanerds.net, www.datanerds.net/~mike) 1.8 - 2.0 WIN32 Port By Chris Reid (chris.reid@codecraftconsultants.com) USAGE: snort [-options] <filter options> snort /SERVICE /INSTALL [-options] <filter options> snort /SERVICE /UNINSTALL snort /SERVICE /SHOW Options: -A Set alert mode: fast, full, console, or none (alert file alerts only) -b Log packets in tcpdump format (much faster!)

-c <rules> Use Rules File <rules> -C Print out payloads with character data only (no hex) -d Dump the Application Layer -e Display the second layer header info -E Log alert messages to NT Eventlog. (Win32 only) -f Turn off fflush() calls after binary log writes -F <bpf> Read BPF filters from file <bpf>

-h <hn> Home network = <hn> -i <if> Listen on interface <if> -I Add Interface name to alert output -k <mode> Checksum mode (all,noip,notcp,noudp,noicmp,none) -l <ld> Log to directory <ld> -L <file> Log to this tcpdump file -n <cnt> Exit after receiving <cnt> packets -N Turn off logging (alerts still work) -o Change the rule testing order to Pass|Alert|Log -O Obfuscate the logged IP addresses -p Disable promiscuous mode sniffing -P <snap> Set explicit snaplen of packet (default: 1514) -q Quiet. Don't show banner and status report -r <tf> Read and process tcpdump file <tf> -R <id> Include 'id' in snort_intf<id>.pid file name -s Log alert messages to syslog -S <n=v> Set rules file variable n equal to value v -T Test and report on the current Snort configuration -U Use UTC for timestamps -v Be verbose -V Show version number

-W Lists available interfaces. (Win32 only) -w Dump 802.11 management and control frames -X Dump the raw packet data starting at the link layer -y Include year in timestamp in the alert and log files -z Set assurance mode, match on established sesions (for TCP) -? Show this information <Filter Options> are standard BPF options, as seen in TCPDump Uh, you need to tell me to do something... : No such file or directory

SNORT EN MODO SNIFFER Y REGISTRO DE PAQUETES El formato genĂŠrico para este modo es: snort [-opciones] < filtro >

C:\Snort20\bin>snort -v Running in packet dump mode Log directory = log Initializing Network Interface \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF} --== Initializing Snort ==-Initializing Output Plugins!

Decoding Ethernet on interface \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF}

--== Initialization Complete ==--*> Snort! <*Version 2.0.0-ODBC-MySQL-FlexRESP-WIN32 (Build 72)

By Martin Roesch (roesch@sourcefire.com, www.snort.org) 1.7-WIN32 Port By Michael Davis (mike@datanerds.net, www.datanerds.net/~mike) 1.8 - 2.0 WIN32 Port By Chris Reid (chris.reid@codecraftconsultants.com) 05/21-11:00:28.593943 ARP who-has 192.168.2.92 tell 192.168.2.60

05/21-11:00:28.594419 ARP who-has 192.168.2.8 tell 192.168.2.60

05/21-11:00:28.594544 ARP who-has 192.168.2.93 tell 192.168.2.60 05/21-11:00:30.467265 192.168.2.5:1025 -> 192.168.2.1:139 TCP TTL:128 TOS:0x0 ID:16685 IpLen:20 DgmLen:104 DF ***AP*** Seq: 0x6B703 Ack: 0x2266A0C Win: 0x2238 TcpLen: 20 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 05/21-11:00:30.467731 192.168.2.1:139 -> 192.168.2.5:1025 TCP TTL:128 TOS:0x0 ID:47513 IpLen:20 DgmLen:1500 DF

Con esta opción -v iniciamos snort en modo sniffer visualizando en pantalla las cabeceras de los paquetes TCP/IP, es decir, en modo sniffer. Esta opción el modo verbouse y mostrará las cabeceras IP, TCP, UDP y ICMP. Si queremos, además, visualizar los campos de datos que pasan por la interface de red, añadiremos -d.

C:\Snort20\bin>snort -vd Running in packet dump mode Log directory = log Initializing Network Interface \Device\NPF_{604C8AE3-5FAC-45A5-BFAA-81175A8C32BF} ..... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

05/21-11:06:18.943887 192.168.4.5:3890 -> 192.168.4.15:8080 TCP TTL:128 TOS:0x0 ID:33216 IpLen:20 DgmLen:40 DF ***A**** Seq: 0xE3A50016 Ack: 0x8B3C1E4D Win: 0xFAF0 TcpLen: 20 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

05/21-11:06:18.962018 192.168.4.5:3890 -> 192.168.4.15:8080 TCP TTL:128 TOS:0x0 ID:33217 IpLen:20 DgmLen:681 DF ***AP*** Seq: 0xE3A50016 Ack: 0x8B3C1E4D Win: 0xFAF0 TcpLen: 20 47 45 54 20 68 74 74 70 3A 2F 2F 77 77 77 2E 6F GET http://www.x 6D 65 6C 65 74 65 2E 63 6F 6D 2E 62 72 2F 73 75 xxxx.com.br/xx 70 65 72 6F 6D 65 6C 65 74 65 2F 64 6F 77 6E 6C xxxxxxx/downl 6F 61 64 73 2F 64 65 66 61 75 6C 74 2E 61 73 70 oads/default.asp 20 48 54 54 50 2F 31 2E 30 0D 0A 55 73 65 72 2D HTTP/1.0..User-

41 67 65 6E 74 3A 20 4D 6F 7A 69 6C 6C 61 2F 34 Agent: Mozilla/4 2E 30 20 28 63 6F 6D 70 61 74 69 62 6C 65 3B 20 .0 (compatible; 4D 53 49 45 20 36 2E 30 3B 20 57 69 6E 64 6F 77 MSIE 6.0; Window 73 20 4E 54 20 35 2E 30 29 20 4F 70 65 72 61 20 s NT 5.0) Opera 37 2E 31 31 20 20 5B 65 6E 5D 0D 0A 48 6F 73 74 7.11 [en]..Host 3A 20 77 77 77 2E 6F 6D 65 6C 65 74 65 2E 63 6F : www.xxxxx.co 6D 2E 62 72 0D 0A 41 63 63 65 70 74 3A 20 74 65 m.br..Accept: te 78 74 2F 68 74 6D 6C 2C 20 69 6D 61 67 65 2F 70 xt/html, image/p 6E 67 2C 20 69 6D 61 67 65 2F 6A 70 65 67 2C 20 ng, image/jpeg, 69 6D 61 67 65 2F 67 69 66 2C 20 69 6D 61 67 65 image/gif, image 2F 78 2D 78 62 69 74 6D 61 70 2C 20 2A 2F 2A 3B /x-xbitmap, */*; 71 3D 30 2E 31 0D 0A 41 63 63 65 70 74 2D 4C 61 q=0.1..Accept-La ......

Añadiendo la opción -e, snort nos mostrará información más detallada. Nos mostrará las cabeceras a nivel de enlace.

Con estas opciones y dependiendo del tráfico en nuestra red, veremos gran cantidad de información pasar por nuestra pantalla, con lo cual sería interesante registrar, guardar estos datos a disco para su posterior estudio. Entraríamos entonces en snort como packet logger o registro de paquetes.

C:\Snort20\bin>snort -dev -l ./log

La opción -l indica a snort que debe guardar los logs en un directorio determinado, en este caso Error! Hyperlink reference not valid. Dentro de la carpeta log se creará una estructura de directorios donde se archivarán los logs.

Podemos indicar la ip de la red a registrar ( -h ) y que el formato de los logs sea en modo binario ( -b ), es decir, el modo que entiende TCPDump o Windump, para estudiar más a fondo con los potentes filtros de estos programas los logs de snort. La salida del logs en el caso de la opción de salida binaria ya no será una estructura de directorios, si no, un sólo archivo.

C:\Snort20\bin>snort -vde -l ./log -h 192.168.4.0/24 Running in packet logging mode Log directory = ./log

C:\Snort20\bin>snort -l ./log -b Running in packet logging mode Log directory = ./log

Usando la opción -b no hará falta indicarle IP alguna de nuestra red (-h). Guardará todo en un mismo archivo y recogerá datos de toda nuestra red. Tampoco serán necesarias las opciones -de y por supuesto, tampoco la opción -v.

El archivo generado por snort en modo binario también podemos leerlo con este usando la opción -r nombrearchivo.log.

Otra opción a toma en cuenta es -i para indicar a snort que interface de red usar en el caso de que tengamos dos o más. Se hace de distinta forma dependiendo si usamos snort para Win32 o para Linux/UNIX. Para averiguar las interfaces de que disponemos, en Win32 usaremos la opción -W.

C:\Snort20\bin>snort -vde -i 1 # snort -vde -i eth0 C:\Snort20\bin>snort -W

FILTROS

Podemos añadir, a parte de las opciones, una serie de filtros para optimizar los resultados obtenidos. Estos filtros se añadirán en el mismo formato que usa programas como TCPDump ya que usan las mismas librerías de captura de paquetes (libpcap).

C:\Snort20\bin>snort -vd host 192.168.4.5 and dst port 8080 Running in packet dump mode Log directory = ./log Initializing Network Interface eth0

--== Initializing Snort ==-Initializing Output Plugins!

Decoding Ethernet on interface eth0 --== Initialization Complete ==--

-*> Snort! <*-

Version 2.0.0 (Build 72)

By Martin Roesch (roesch@sourcefire.com, www.snort.org) 07/15-12:34:26.059644 192.168.4.5:4533 -> 192.168.4.15:8080 TCP TTL:128 TOS:0x0 ID:16544 IpLen:20 DgmLen:40 DF ***A**** Seq: 0xC47AC53E Ack: 0xC83C2362 Win: 0xFAF0 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/15-12:34:26.059880 192.168.4.5:4533 -> 192.168.4.15:8080 TCP TTL:128 TOS:0x0 ID:16545 IpLen:20 DgmLen:40 DF ***A**** Seq: 0xC47AC53E Ack: 0xC83C31E4 Win: 0xFAF0 TcpLen: 20 =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Snort aceptará también filtros más avanzados en su modo sniffer: C:\Snort20\bin>snort -vd icmp[0] = 8 and dst host 192.168.4.1 C:\Snort20\bin>snort -vd icmp[0] != 8 and icmp[0] != 0 C:\Snort20\bin>snort -vd 'udp[0:2] < 1024' and host 192.168.4.1

SNORT EN MODO NIDS. En este apartado es donde nos centraremos más. El modo detección de intrusos de red se activa añadiendo a la línea de comandos de snort la opción -c snort.conf. En este archivo, snort.conf, se guarda toda la configuración de las reglas, preprocesadores y otras configuraciones necesarias para el funcionamiento en modo NIDS.

C:\Snort20\bin>snort -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf

Con al opción -D indicará a snort que corra como un servicio. Esto es sólo válido para las versiónes Linux/UNIX:

# snort -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf -D

Para la versión win32 usaremos /SERVICE /INSTALL:

C:\Snort20\bin>snort /SERVICE /INSTALL -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf

/SERVICE /UNINSTALL desinstala snort como servicio.

Snort creará, a parte de la estructura de directorios, un archivo alert.ids donde almacenará las alertas generadas.

MODOS DE ALERTA Hay varias maneras de configurar la salida de snort, es decir, las alertas, el modo en que se almacenarán estas en el archivo alert.ids.

Snort dispone de siete modos de alertas en la línea de órdenes, completo, rápido, socket, syslog, smb (WinPopup), consola y ninguno.

Fast: El modo Alerta Rápida nos devolverá información sobre: tiempo, mensaje de la alerta, clasificación, prioridad de la alerta, IP y puerto de origen y destino.

C:\Snort20\bin>snort -A fast -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf 09/19-19:06:37.421286 [**] [1:620:2] SCAN Proxy (8080) attempt [**] [Classification: Attempted Information Leak] [Priority: 2] ...

... {TCP} 192.168.4.3:1382 -> 192.168.4.15:8080

Full: El modo de Alerta Completa nos devolverรก informaciรณn sobre: tiempo, mensaje de la alerta, clasificaciรณn, prioridad de la alerta, IP y puerto de origen/destino e informaciรณn completa de las cabeceras de los paquetes registrados.

C:\Snort20\bin>snort -A full -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf

[**] [1:620:2] SCAN Proxy (8080) attempt [**] [Classification: Attempted Information Leak] [Priority: 2] 09/19-14:53:38.481065 192.168.4.3:3159 -> 192.168.4.15:8080 TCP TTL:128 TOS:0x0 ID:39918 IpLen:20 DgmLen:48 DF ******S* Seq: 0xE87CBBAD Ack: 0x0 Win: 0x4000 TcpLen: 28 TCP Options (4) => MSS: 1456 NOP NOP SackOK

Informaciรณn de la cabecera del paquete:

TCP TTL:128 TOS:0x0 ID:39918 IpLen:20 DgmLen:48 DF ******S* Seq: 0xE87CBBAD Ack: 0x0 Win: 0x4000 TcpLen: 28 TCP Options (4) => MSS: 1456 NOP NOP SackOK

Socket: Manda las alertas a través de un socket, para que las escuche otra aplicación. Está opción es para Linux/UNIX. # snort -A unsock -c snort.conf Console: Imprime las alarmas en pantalla.

C:\Snort20\bin>snort -A console -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf None: Desactiva las alarmas. # snort -A none -c snort.conf SMB: Permite a Snort realizar llamadas al cliente de SMB (cliente de Samba, en Linux), y enviar mensajes de alerta a hosts Windows (WinPopUp). Para activar este modo de alerta, se debe compilar Snort con el conmutador de habilitar alertas SMB (enable -smbalerts). Evidentemente este modo es para sistemas Linux/UNIX. Para usar esta característica enviando un WinPopUp a un sistema Windows, añadiremos a la línea de comandos de snort: -M WORKSTATIONS. Syslog: Envía las alarmas al syslog C:\Snort20\bin>snort -A console -dev -l ./log -h 192.168.4.0/24 -c ../etc/snort.conf -s 192.168.4.33:514 Eventlog: Registra las alertas para visualizarse a través del visor de sucesos de un sistema windows. Esta opción se activará mediante -E y sólo para Win32.