Mecanismos de seguridad

Se necesita una política de seguridad que contemple el análisis periódico de vulnerabilidades de software, sistemas y protocolos, especialmente en equipos más propensos a ataques.

Analizadores de vulnerabilidades son herramientas que buscan automáticamente debilidades proporcionando un informe para que los administradores tomen acciones correctivas. hay diferentes tipos:

buscan vulnerabilidades en aplicaciones y sistemas en tiempo real. Los hay más especializados (ej. aplicaciones web). usan un «motor de búsqueda» y una lista de vulnerabilidades conocidas que crece con el tiempo
- Pueden ser analizadores de sistemas centrados en el equipo concreto, o que puedan buscar vulnerabilidades por la red.
Analizadores de código fuente estático (SSCA), buscan vulnerabilidades en el código. utilizan algoritmos relacionados con el lenguaje de programación y vulnerabilidades comunes para detectar debilidades en el código.

Es necesaria la supervisión de un experto al usar estas aplicaciones. definiciones comunes:

Falso positivo: supuesta vulnerabilidad detectada que resulta no serlo.
Falso negativo: vulnerabilidad real que el analizador no logra detectar.
Verdadero positivo: una vulnerabilidad real detectada correctamente.

Para utilizarlos correctamente hay que considerar también los siguientes puntos:

Ejecutarlos frecuentemente.
Tener en cuenta el impacto en el tráfico de la red.
Tener en cuenta el impacto de algunos test.
Informar al personal responsable.

NMAP

Nmap (Network Mapper) herramienta para escaneo de puertos y auditorías de seguridad. Permite detectar hosts activos en una red, identificar sus sistemas operativos, cortafuegos y filtros de paquetes

Zenmap: interfaz gráfica, facilita la configuración del escaneo. Zenmap organiza y muestra la información de Nmap de forma ordenada, indicando los puertos abiertos, servicios y versiones de software detectadas. Zenmap guarda los resultados obtenidos. Posteriormente estos resultados podrán ser comparados con escaneos posteriores a través de otra herramienta proporcionada por Zenmap.

Características:

Flexibilidad: permite mapear redes con diversas técnicas, incluso cuando están protegidas por cortafuegos o filtros de paquetes, incluyendo escaneo de puertos e identificación de sistemas operativos, versiones, etc.
Potencia: utilizado en redes con cientos de miles de hosts conectados.
Documentación: amplia documentación en varios idiomas, accesible desde http://nmap.org/docs.html.

perfiles más intensos envían más peticiones a los hosts objetivo, lo que aumenta la probabilidad de ser detectado por herramientas de seguridad. Para conocer máquinas conectadas a un sector de red, se recomienda usar un «Ping Scan» o «Quick Scan». este es un paso previo común en ataques de obtención de información. Para un examen exhaustivo de seguridad, se puede optar por una opción de escaneo intenso. Nmap muestra los resultados del escaneo a medida que se obtienen, y la cantidad de información variará según el tipo de escaneo.

NESSUS

es una herramienta comercial de análisis de vulnerabilidades desarrollada por Tenable Network Security, que ayuda a detectar posibles vulnerabilidades en máquinas escaneadas. utiliza la tecnología «Nessus Professional-Feed«. Tenable crea un plugin para Nessus para nuevas vulneravilidades permitiendo que Nessus realice chequeos de red y host siempre actualizados. Los suscriptores de Nessus pueden utilizar el contenido desarrollado por Tenable para realizar auditorías y cubren más de 50,000 vulnerabilidades Estas auditorías se realizan según políticas personalizadas, configuraciones de sistemas activos y políticas basadas en organismos especializados como NIST, CERT, SANS o vendedores como Microsoft y Red Hat.

Las características:

Análisis en profundidad.
Auditoría de dispositivos móviles.
Auditoría antivirus, de botnets y procesos maliciosos.
Integración de gestión de parches de seguridad.

Nessus funciona con una estructura cliente-servidor. se debe instalar el programa servidor descargable desde el sitio web de Tenable. Nessus se iniciará como un servicio y estará listo para ser accedido a través del cliente web. Para conectar con el mismo hay que acceder a la siguiente URL: https://ip_servidor_nessus:8834. La primera vez que se accede al servidor Nessus desde el cliente web, es necesario realizar la configuración inicial de la aplicación. Esto incluye la creación de una cuenta de administrador y el registro de un proveedor de plugins. Los plugins permiten al servidor Nessus llevar a cabo los escaneos de vulnerabilidades.

Aunque Nessus es una herramienta comercial, ofrece una opción gratuita llamada «Home Feed» para usuarios individuales. En la pantalla inicial del cliente Nessus, se pueden ver resultados de escaneos anteriores o definir nuevos. Para lanzar un nuevo escaneo, se debe seleccionar «Add» y definir el objetivo (dirección IP, dominio o rango de direcciones IP). Se debe indicar el tipo de análisis a realizar (escaneo interno o externo), según si la máquina objetivo se encuentra en la misma red o a través de Internet. se pueden agregar políticas de escaneo personalizadas en la sección «Policies».

Para cada nueva política, se deben definir características relevantes:

Nombre de la política.
Puertos a escanear.
Tipo de escaneo de puertos a realizar.
Número de conexiones paralelas.
Credenciales para un escaneo más en profundidad de determinados servicios.
Definición de las plugins que se van a utilizar en el análisis de vulnerabilidades que se está definiendo.
En la última pantalla de configuración se podrán definir una serie de preferencias que van a permitir ajustar tanto la forma de realizar el análisis como el detalle del mismo.

El escaneo en curso aparecerá en la lista de escaneos y mostrará su estado. Una vez finalizado, se moverá a la lista de «reports», donde se mostrarán los resultados de todos los escaneos realizados hasta el momento. Para examinar los resultados de un escaneo, seleccione el reporte deseado y presione «Browse». La primera pantalla mostrará un resumen de las vulnerabilidades encontradas, agrupadas por su nivel de riesgo. Al hacer clic en una entrada, se accede a los detalles, donde las vulnerabilidades encontradas se agrupan por nivel de riesgo y también por el puerto en el que se detectaron.

Y pulsando en un determinado puerto se ve una lista detallada de las plugins que han detectado vulnerabilidades en dicho puerto. pulsando sobre cada una de las vulnerabilidades se mostrará información detallada sobre la misma. Se da una explicación detallada sobre la vulnerabilidad encontrada e incluso se proporciona información sobre cómo corregirla.

Herramientas de análisis de vulnerabilidades en código fuente

los analizadores de vulnerabilidades en código fuente (SSCA) son una herramienta para examinar el código heredado y también para utilizarla en el ciclo de desarrollo de software. no requiere la ejecución del programa.

Características

El código a analizar se transforma en un «modelo» utilizando una combinación de técnicas de análisis léxico y semántico y de parsing
Se analiza este «modelo», siguiendo una serie de reglas variadas y propiedades de código. (análisis intra-procedimiento (local) y análisis inter-procedimiento (global). Estas reglas pueden variar dependiendo de la herramienta.
Se muestran los resultados de las vulnerabilidades encontradas y su nivel de severidad.

Tipos de herramientas SSCA

Pueden clasificarse según los lenguajes que entienden, clases de vulnerabilidades o la longitud del código que es capaz de analizar. La clasificación más usada es la del libro de referencia de Chess y West:

De chequeo de estilos.
De chequeo de propiedades.
De tipo «bug finding».
De tipo «security review».

Existen más de 40 herramientas, pero ninguna puede garantizar al 100% la detección de vulnerabilidades. se recomienda utilizar varias herramientas y ser cuidadoso con los resultados obtenidos

Prevención y de detección de intrusiones

la fase de monitorización implica vigilancia y registro constante de los sistemas para detectar actividades maliciosas o comportamientos sospechosos. Pero esta es una medida de reacción a eventos que ya han ocurrido. Para una monitorización efectiva, es necesario implementar medidas preventivas con sistemas de detección de intrusiones.

Una intrusión se puede definir como un mensaje que cumple varias condiciones:

Se aparta de un comportamiento «normal».
Si es anormal, hay que decidir si esa anormalidad proviene de un uso incorrecto (probable ataque) o si es una situación no peligrosa.

Los primeros sistemas utilizaban la detección de anomalías y se basaban en la creación de perfiles de uso típico, que podían ser por tipos de usuario, tipos de red, tipos de trabajo, etc. estos sistemas producían muchos «falsos positivos«.

Los sistemas IDS (Intrusion Detection Systems) utilizados actualmente se basan en «firmas» (signatures). Estas firmas son mensajes o grupos de mensajes que indican con cierta fiabilidad la presencia de un ataque en curso

Ejemplo: un mensaje de tipo ping con una dirección de destino que sea la dirección broadcast de una red o muchos mensajes de intento de conexión TCP con la misma dirección IP, conocidos como SYN flood.

Una firma se compone de reglas típicas de una actividad que se asocian con una intrusión en la red.

El conjunto de firmas de ataque de cada sistema IDS es la suma de las firmas incluidas en el sistema que pueden ser actualizadas y pueden ser creadas por el administrador, expertos y agencias de ayuda como el CERT.

IDS basados en la red: Pueden colocarse en un segmento de red, en cuyo caso monitorizan el tráfico que circula por ese tramo de red, independientemente de la dirección IP origen y destino.

Detección de intrusiones basada en el sistema: Solo protegen un sistema, a cambio resultan más baratos.

El procedimiento de su funcionamiento es el siguiente:

monitorizan todo el tráfico que pasa por la tarjeta de red que usan.
Comparan el tráfico que capturan con cada una de las firmas.

Si un sistema IDS encuentra una firma que se ajusta a cierto tráfico, puede ejecutar una combinación de tres acciones:

Registrar el ataque (local o remoto)
Enviar una alarma (mediante un correo electrónico)
Detener el ataque. (Estas acciones son configurables y pueden incluir acciones adicionales)

Suele ser normal que su control se haga de manera remota, por dos razones:

Si hay varios IDS para llevar el control centralizado desde un solo sitio
Por facilidad de administración, con la gestión remota se hacen a través de una conexión web u otro tipo de herramientas gráficas

Características:

Debe tener actualizaciones frecuentes.
Debe tener capacidad de adaptación al entorno.
Debe exhibir un buen rendimiento.

Aspectos a tener en cuenta:

dónde colocarlo.
dónde se va a conectar el IDS a la red.
falsos negativos.
falsos positivos.

tener preparado cómo se va a realizar la respuesta a incidentes.

SNORT (sniffer + IDS + Registro)

funciona como un escuchador de paquetes (sniffer) y un detector de intrusiones basado en red. monitorea el segmento de red al que está conectado, proporcionando seguridad y prevención de intrusiones.

Este programa tiene tres modos de funcionamiento:

Sniffer.
Registro de paquetes.
IDS (Intrusion Detection System).

Información capturada

La primera línea en un registro de alertas contiene tres números: el número del componente que acabará la alerta, el Signature ID (identificación de firma de ataque) y la versión de la firma.

La siguiente línea puede incluir información sobre el tipo de ataque y su nivel de prioridad. Snort clasifica las alertas en 5 niveles, siendo el nivel 1 el más serio y el nivel 5 el menos significativo.

Para utilizar Snort como IDS continuo, es recomendable ejecutarlo como un servicio (daemon) y automatizar su inicio durante el arranque del sistema utilizando el parámetro –D

Snort tiene tres modos básicos de funcionamiento que se pueden configurar mediante el parámetro –Q:

Inline: permite usar reglas tipo drop para rechazar paquetes que generen alertas. funciona como un sistema de detección de intrusiones (IDS) y como sistema de prevención de intrusiones (IPS), al reaccionar ante ataques detectados.
Passive: este es el modo IDS, en el que las reglas de tipo drop no son cargadas
Inline-Test: simula el modo Inline, permite la evaluación de las reglas drop pero sin afectar al tráfico. Cuando el tráfico corresponda con una regla tipo drop esta se registrará en el log como wdrop (would drop).

El archivo snort.conf contiene la configuración para ejecutar Snort como IDS y permite adaptar su funcionamiento. Los parámetros más relevantes son las reglas aplicadas al tráfico capturado, basadas en firmas de ataque. Para evitar un archivo difícil de manejar, snort.conf permite incluir otros archivos mediante el comando «include». se pueden crear diferentes archivos de reglas y luego incluirlos en snort.conf facilitando la organización y configuración.

Snort incluye varias reglas agrupadas por tipo de amenazas en diferentes archivos. Para activar estas reglas, basta con incluir la línea «include» correspondiente en el archivo de configuración. Las reglas en Snort definen la acción a realizar y especifican criterios como protocolo, fuente, destino, contenido del paquete y valores en las cabeceras para identificar paquetes como posibles amenazas. Lo primero que indica la regla es la acción a realizar. En la regla del ejemplo se indica la acción alert, pero esta no es la única acción disponible, algunas de las posibles acciones que se pueden definir son:

alert: Genera una alerta que se incluye en el registro de alerta seleccionado y además guarda en el registro los paquetes que han provocado la alerta.
log: Guarda registro de los paquetes.
pass: ignora el paquete.
drop: bloquea el paquete y lo guarda en el registro.
reject: además de bloquear el paquete y guardarlo en el registro envía un paquete de respuesta de tipo «reset» para comunicaciones TCP o una respuesta de tipo «port unreachable» para UDP y así cortar la comunicación.
sdrop: bloquea el paquete pero no lo guarda en el registro

Snort incluye un conjunto extenso de reglas desarrolladas por el Vulnerability Research Team (VRT) de Sourcefire. este conjunto no es suficiente, ya que continuamente se detectan nuevas amenazas y se generan nuevas reglas. Es necesario actualizar las reglas con las publicaciones de Sourcefire y otros pudiendo ser estas actualizaciones gratuitas o mediante suscripción de pago. Pulled_Pork permiten realizar dicha actualización de forma automática. Snort forma parte de herramientas más complejas y llamativas de detección de intrusiones como Sguil, utilizándose como componente principal del módulo de detección.

SGUIL

Un sistema Sguil consta de un servidor y varios sensores distribuidos en la red. cada sensor monitorea la seguridad en su segmento de red y reporta la información al servidor Sguil de manera regular

Arquitectura de un sistema de monitorización Sguil

El servidor Sguil coordina y almacena la información recibida de todos los sensores en su base de datos. Los usuarios acceden a esta información mediante el cliente Sguil, que es multiplataforma. Para que los sensores Sguil sean capaces de capturar el tráfico de su segmento de red, deberán estar conectados a un Hub o Switch que haya sido configurado para enviar copia de todos los paquetes de datos.

Cada sensor Sguil monitorea el tráfico en el segmento de red al que está conectado, pudiendo instalarse múltiples sensores en una misma máquina para monitorear segmentos diferentes. Estos sensores utilizan diversas herramientas para supervisar el tráfico y obtener información que luego envían al servidor.

Sguil hace uso de Snort para obtener alertas de seguridad y/o intrusión.
Sguil integra también SANCP (Security Analyst Network Connection Profiler, una herramienta que permite obtener información estadística del tráfico analizado) para obtener datos de sesiones TCP.
Una segunda instancia de Snort se encarga de recolectar copia de todos los paquetes que pasan por el sensor (utiliza las funciones de capturador de paquetes o sniffer que proporciona Snort).
Gracias a tcpflow es capaz de reconstruir datos de la capa de aplicación.
Gracias a P0f es capaz de analizar las huellas del tráfico TCP/IP y detectar así el sistema operativo de los integrantes en la comunicación.
Una instancia de MySQL guarda toda la información obtenida por Snort.
La información obtenida se envía al servidor Sguil. La aplicación cliente permite conectarse a cualquier servidor Sguil mediante su dirección IP, puerto del servicio, y un usuario y contraseña autorizados en dicho servidor.

La información adicional sobre el ataque recopilado por Sguil tiene como objetivo ayudar al analista de seguridad a determinar las acciones del atacante, entender los pasos del ataque y las herramientas utilizadas. Proporciona una gran cantidad de información para investigar los diferentes eventos de seguridad. A partir de la información recopilada, el analista deberá analizar y evaluar cada alerta para tomar una decisión. Permite asociar diferentes categorías a las alertas y el analista puede marcar cada una de ellas dentro de un determinado nivel utilizando las teclas de función. Las categorías disponibles son:

F1: Categoría I: Acceso root/Admin no autorizado.
F2: Categoría II: Acceso de usuario no autorizado.
F3: Categoría III: Intento de acceso no autorizado.
F4: Categoría IV: Ataque de tipo de denegación de servicio efectivo.
F5: Categoría V: Violación de la política de seguridad.
F6: Categoría VI: Reconocimiento o escaneo de puertos abiertos.
F7: Categoría VII: Infección por virus informático.
F8: No es necesario realizar ninguna acción. Si el analista encargado de revisar las alertas considera que una alerta es un falso positivo, la puede descartar seleccionándola y pulsando F8.
F9: Escalar el evento. Si el analista no está seguro sobre una alerta, puede «escalarla» pulsando F9 para que otro analista más experimentado analice la actividad del posible atacante y trate de clasificarla.

Si considera que la alerta es real, seleccionará la alerta y pulsará la tecla de función correspondiente para asociarla con la categoría adecuada.

HONEYPOTS

Es un equipo falso modificado para tomar información de los intrusos. El nombre, los procesos del sistema, las cuentas de usuario y archivos, todo está diseñado para atraer a los atacantes. Son señuelos que parecen contener vulnerabilidades que los hacen atractivos para los hackers. El objetivo de estos sistemas es proteger el acceso a los datos reales, los controles de administración y equipos. Permite recopilar datos sobre la identidad, el acceso y métodos de ataque utilizados. Se puede observar cómo el intruso intenta explotar datos y evadiendo los sistemas de seguridad

Ventajas:

Parar los ataques.
Detectar ataques.
Educar.
Crear confusión.

Para comprender el nivel de ataque logrado, es común guardar una imagen de los binarios del sistema utilizando una utilidad como Tripwire y almacenarla de manera remota. Si el «honeypot» está comprometido, es útil detenerlo y volver a configurarlo con las vulnerabilidades corregidas, pero también agregar nuevas vulnerabilidades para aprender nuevas técnicas de ataque.

Categorías:

Honeypots de baja interacción. El intruso interactúa de manera limitada con un sistema simple o un «escuchador» de actividad en determinados puertos
Honeypots de interacción media.
Honeypots de alta interacción. El intruso interactúa con un sistema completo. A mayor nivel de interacción, mayor es la cantidad de información que se puede obtener. PERO un sistema completo supone un mayor riesgo.

Clasificación

Honeypots físicos.
Honeypots virtuales.

Honeynet

Es una combinación de varios honeypots operando juntos en una red. A diferencia de las emulaciones utilizadas en otros honeypots, Honeynet emplea sistemas completos para atraer y analizar ataques. utiliza sistemas completos detrás de un método de control de acceso, como un cortafuego, para atraer y analizar intentos de intrusión. Al ser sistemas completos, pueden ser reconocidos, atacados y explotados totalmente.

Estos sistemas pueden incluir cualquier sistema operativo encontrado en servidores en producción. ofrece todas las funcionalidades de otros honeypots, permitiendo detectar ataques y monitorizar todos los protocolos IP. es capaz de capturar amenazas desconocidas, convirtiéndolo en una valiosa herramienta de investigación para determinar la identidad de los atacantes, las herramientas que utilizan y las tácticas empleadas.

Hay tres aspectos fundamentales en una arquitectura Honeynet

Control de datos.
Captura de datos.
Recogida de información.

Tecnologías de virtualización como VirtualBox facilitan la creación de Honeynets y reducen significativamente los costes. Estas permiten guardar copias de las máquinas virtuales en un estado específico, lo que facilita la recuperación de las mismas en caso de ser comprometido, evitando la necesidad de reinstalar el sistema desde cero y ahorrando tiempo.

La seguridad en cada equipo individual sigue siendo esencial pero no se puede considerar de forma aislada. Hay que considerar:

El número de equipos en muchas organizaciones.
Entornos heterogéneos con distintos sistemas operativos y versiones de cada sistema operativo
usuarios con privilegios de administración pueden ser un problema a la hora de organizarlos.

Un cortafuego es una herramienta que protege una red de sistemas y dispositivos interconectados mediante el control del tráfico de red. El cortafuego debe tener tres características clave:

Todo el tráfico de «dentro a fuera» y de «fuera a dentro» debe pasar por él.
Solo el tráfico autorizado basado en la política de seguridad puede continuar.
Debe ser completamente inatacable.

Aunque ningún cortafuego actual cumple estos requisitos completamente, todos intentan acercarse a ellos lo más posible.

Para proteger las redes, se puede optar por colocar uno o varios cortafuegos.

Ventajas:

capacidad para ser utilizados como un punto esencial de aplicación de la política de seguridad.
son capaces de soportar técnicas avanzadas de autenticación de manera más eficaz y económica que si se hiciera equipo por equipo.
pueden centralizar alarmas y registros de tráfico
Tienen menos configuración en comparación con un sistema de propósito general
Necesitan pocos usuarios definidos para llevar a cabo su configuración y mantenimiento.

La política del tráfico en un cortafuego es restrictiva y solo permite el tráfico que ha sido explícitamente permitido. Esta política es segura, pero cada utilidad que necesite tráfico debe ser analizada y permitida de manera individual.

Desventajas:

pueden provocar una falsa sensación de seguridad para los usuarios y administradores.
Si son muy sofisticados, pueden requerir una configuración compleja.
Pueden representar un cuello de botella para el tráfico de red.

Tipos:

filtros de paquetes.
Gateways de aplicaciones.
stateful inspection. (el Firewall-1 de Checkpoint o el CiscoASA (Adaptative Security Appliance), además de su tecnología particular, pueden configurarse como servidores proxy.)
híbridos.

Arquitecturas de cortafuegos: son distintas formas de combinar cortafuegos

Filtros de paquetes

Los filtros de paquetes operan en el nivel de red y transporte y filtran paquetes IP basándose en valores de algunos campos de las cabeceras de IP, TCP o UDP. también permiten filtrar el tráfico en función del enlace de red del que provenga. El más básico consiste en un encaminador que trabaja a nivel de red, aunque en muchos casos, una máquina con software dedicado realiza esta tarea.

Cada filtro está compuesto por reglas que se utilizarán de distintas y orden en busca de una coincidencia. Un filtro de paquetes examina cada paquete entrante por la interfaz en la que está aplicado el filtro y:

Obtiene los contenidos de las cabeceras citadas del paquete.
Contrasta los valores contra los configurados en las reglas del filtro, ordenadamente.
Si cumple lo enunciado en una regla, aplica una de las dos únicas condiciones posibles: lo permite, en cuyo caso el paquete se encaminará a su destino o lo descarta.

Los campos de las cabeceras que se usan como criterios de filtrado son:

Las direcciones IP origen y destino del mensaje, que viajan en la cabecera de IP.
Los números de puerto origen y destino del mensaje, que son parte de la cabecera de TCP o de UDP.
El tipo de protocolo o número de protocolo, parte de la cabecera de IP, que indica, el tipo de mensaje IP: si es ICMP, OSPF, TCP, UDP, etc.
Una serie de opciones de la cabecera TCP, como los bits de sincronización, de final, de ACK, etc.

Para ser efectivo, un filtro debe permitir la especificación de puertos, ya que algunos servidores de aplicaciones IP utilizan números de puerto normalizados, mientras que los clientes utilizan números de puerto al azar por encima de 1023. Es necesario contar con operadores relacionales para implementar relaciones como «mayor que» o «igual a» y los filtros deben permitir el filtrado de paquetes según la interfaz de origen o destino. Pueden ser un software con funcionalidades avanzadas como IPTables o ser parte de un encaminador. La tecnología es simple y transparente para los usuarios.

Puntos débiles:

Si la configuración llega a hacerse muy grande, puede hacerse difícil el mantenimiento de los filtros.
Si se tiene que hacer una excepción ocasional, puede ser que haya que cambiar toda la configuración, haciendo la situación bastante insegura.
No permiten realizar ningún control a nivel de usuario ni a nivel de datos. No se puede filtrar por valores de campos de las cabeceras de aplicación.
No es fácil filtrar protocolos con más de una conexión activa simultáneamente, como ftp, ni protocolos basados en RPC.
No suelen guardar registro de los accesos de los usuarios.

Aplicaciones difíciles de filtrar son aquellas basadas en el entorno RPC (Remote Procedure Call), para las que cada servidor RPC tiene asociado un número de puerto que no es siempre el mismo. Aplicaciones como NFS (Network File System) o NIS (Network Information Services), envían mensajes al portmapper con el número de puerto 111 para conocer el número de puerto actual del servidor que están buscando.

Estas aplicaciones están compuestas por varios servidores que se registran con el portmapper al iniciar, lo que las hace difíciles de filtrar. no se debe permitir el tráfico de estas aplicaciones si el cortafuego es solo un filtro de paquetes. Las reglas de filtrado se expresan como una tabla de condiciones y acciones que se consultan en orden hasta encontrar una regla para decidir si se permite o se bloquea un paquete.

Es importante el orden de análisis de las reglas para implementar correctamente la política de seguridad. Cuanto más complejas sean las reglas y su orden de análisis, más difícil será para el administrador gestionarlas. ¿Y si un paquete que no cumple ninguna regla especificada? Se debe añadir una regla por defecto al final de la lista que bloquee todo el tráfico que no cumpla con ninguna otra regla.

muchas implementaciones de filtros de paquetes las incorporan directamente. los encaminadores Cisco incorporan dicho filtrado restrictivo por defecto en sus listas de control de acceso o ACLs (Access Control Lists).

Las ACL de los encaminadores Cisco son de dos tipos: standard y extended.

Las ACLs de tipo standard están compuestas de una serie de reglas ordenadas (ACE o Access control entry), cada una de las cuales solo usan, como criterio, la dirección IP origen del mensaje, y tienen una sintaxis:

router(config)# access-list N {permit|deny} dirección-IP-origen [máscara]

Recordar estas reglas para standard y extended:

Al final de todas las reglas existe una más (que no pone el administrador) implícita, que deniega el resto del tráfico, que no coincide con alguna de las reglas de la ACL. Es la condición de «todo lo demás negado por defecto».
Hay una serie de «palabras clave» que se pueden utilizar para hacer las reglas más legibles. Por ejemplo, en lugar de 144.21.13.12 0.0.0.0, se puede escribir host 144.21.13.12, o en lugar de escribir 0.0.0.0 0.0.0.0, se puede escribir any.
El comando access-list solo sirve para construir la ACL, pero no la aplica a ninguna interfaz. Para ello, existe otro comando diferente.

Para aplicar la ACL a una interfaz concreta, en el caso de los encaminadores de Cisco, se debe pasar a «modo de configuración de la interfaz» y aplicar el comando ip access-group. La sintaxis es:

router(config)# interface nombre-interface

router(config-if)# ip access-group N {in|out}

nombre-interface es la sintaxis propia de Cisco. Ej: «ethernet-0», N es el número que identifica la ACL que se quiere asociar a la interfaz. IN indica tráfico entrante y OUT saliente

En la figura. Se quiere dejar pasar hacia dentro todo el tráfico de las redes externas (más allá de la interfaz ethernet-1) excepto el que venga de la red 144.21.0.0. La ACL sería:

router(config)# access-list 1 deny 144.21.0.0 0.0.255.255

router(config)# access-list 1 permit any La segunda línea es obligatoria. Si no se tiene en cuenta, funcionará la «por defecto» ya citada, que, aunque no se vea es:

access-list 1 deny any

Para aplicar la ACL a la interfaz ethernet-1, los comandos serían:

router(config)# interface ethernet-1

router(config-if)# ip access-group 1 in

Filtrando así, solamente, el tráfico entrante.

Las ACLs de tipo extended, comparten todas las demás características del standard, pero tienen una sintaxis más complicada, atendiendo a que permiten filtrar utilizando muchos otros criterios:

router(config)# access-list N {permit|deny} protocolo dir.IP-fuente [máscara-fuente] [op puerto-fuente] dir.IP-destino [máscara-destino] [op puerto-destino]

En este caso, N es un número entre 100 y 199, para indicar que es una lista extended, protocolo es la referencia al campo de número de protocolo de la cabecera IP y op puede ser:

lt, indicando «menor que».
le, indicando «menor o igual que».
gt, indicando «mayor que».
ge, indicando «mayor o igual que».
eq, indicando «igual a».
ne, indicando «distinto a».
range, que permite expresar un rango de números.

Si lo que se busca es en la misma topología de la figura anterior, que se cumpla la siguiente política:

No dejar entrar tráfico Telnet externo, salvo de la dirección 155.15.1.1.
Permitir el tráfico, del tipo que sea, de la dirección 133.11.1.3.
No dejar entrar tráfico general salvo de la red 144.21.0.0.

La lista de acceso sería:

router(config)# access-list 101 permit ip host 133.11.1.3 any

router(config)# access-list 101 permit tcp 155.15.11.1 any eq 23

router(config)# access-list 101 permit ip 144.21.0.0 0.0.255.255 any

igual que antes, la condición implícita por defecto, no permite entrar más tráfico.

gateway (servidores proxy)

Son una alternativa a los filtros de paquetes ya que soportan filtros a nivel de aplicación en lugar de a nivel de red y transporte. Actúan para un protocolo de aplicación y hay un proceso proxy para cada protocolo que se quiere filtrar.

Un servidor proxy reside entre los clientes y el servidor real, intercepta las peticiones de los clientes de servicios particulares, las evalúa y decide qué tráfico se permite y qué tráfico se bloquea.

Arquitectura de servidores proxy

Ventajas:

soluciona problemas que presentan los filtros de paquetes, ya que permite filtrar a nivel de aplicaciónse puede filtrar por operaciones concretas de protocolo.
- Ej. en ftp e podría poner una regla de bloqueo de todos los comandos put y nadie podría subir archivos al servidor.
- los problemas relacionados con el esquema de ftp desaparecen ya que el proxy cambia el número de puerto usado en las sesiones para mantener el estado de las dos sesiones.
Pueden tener un proceso separado por protocolo, no tienen que tratar de hacerlo todo a la vez.
Es sencillo restringir el acceso a un servicio: si no hay proxy, no hay servicio.
Simplifica las reglas de filtrado en el encaminador. Solo se debe permitir el tráfico hacia la pasarela de aplicación y bloquear el resto.
Permite un grado de ocultación de la estructura de la red protegida. El nombre del proxy será el único que estará disponible hacia el exterior.

Desventajas:

Al funcionar un proceso proxy por servicio, se debe tener multitud de ellos, si se quiere atender al filtrado de muchos protocolos.
puede pasar que se tenga que usar distintos clientes, servidores o ambos.
Pueden llegar a ser un cuello de botella para el tráfico.

tipos de servidores proxy:

Un sistema genérico, SOCKS, requiere clientes distintos a los típicos, no es popular.
Proxy Server, como el de Microsoft, un paquete de software que permite hacer proxy de protocolos ftp, http y nntp.
TIS FWTK, de Trusted Information Systems, que incluye distintos tipos de servidores proxy. Entre otros, incluye proxies para Telnet, FTP, Rlogin, Sendmail, HTTP, etc.

¿Qué se puede mejorar?

Trabajar con tecnología «stateful inspection».
Reunir varias de las tecnologías, junto con distintos tipos de sistemas de autenticación, AAA, para crear cortafuegos mucho más sofisticados.
Con todas las tecnologías disponibles, crear distintas arquitecturas o topologías de seguridad, en torno al cortafuego.

zona desmilitarizada (DMZ)

Esta red aísla los servicios que se quieren mantener disponibles por Internet y separa los servicios de la red interna. Si estos servicios estuvieran en la red interna, cualquier ataque podría poner en peligro toda la red.

Topología de una DMZ típica

La robustez dependerá de qué cortafuegos se seleccione y de lo bien configurado que esté.

Dos principios de seguridad:

defensa en profundidad, los ataques deben de ser capaces de atacar con éxito primero el encaminador y, después, el cortafuego.
diversidad de defensa: El cortafuego y el encaminador estan por separado.

Topología de doble DMZ: consiste en dos DMZs, La externa con elementos que son menos atacables y la DMZ interna.

Es importante seleccionar cuidadosamente los dos cortafuegos y decidir qué servicios se colocarán en la DMZ externa e interna. esta arquitectura puede presentar dificultades de administración. En el caso de dispositivos móviles, un cortafuego no garantiza la protección de los datos ya que cuando estos dispositivos se conectan a redes externas no están protegidos por el cortafuego y son susceptibles a ser comprometidos.

si un dispositivo móvil comprometido se vuelve a conectar a la red de la organización, puede ser una puerta de entrada para el atacante y una fuente de infección para el resto de equipos de la red.

Diseño seguro de redes

La «alta disponibilidad» va más allá del 99%. Este 1% de tiempo de inactividad equivale a 83 horas al año. La alta disponibilidad se refiere 99,999% del tiempo funcionando, con menos de 5 minutos de caída al año. Existe una medida estándar del nivel de disponibilidad:

Disponibilidad = TMEF / (TMEF + TMR)

TMEF: Tiempo Medio Entre Fallos

TMR: Tiempo Medio de Reparación.

Se requiere tratar de evitar una serie de posibles problemas lógicos, físicos y organizativos.

Problemas lógicos:

puntos únicos de fallo en las redes.
paradas necesarias para actualizaciones.
periodos largos de re arranque o conmutación
sistemas no suficientemente probados.

Problemas organizativos:

tiempos excesivos de reparación de hardware y software.
problemas operacionales y de procedimientos.

Problemas físicos:

condiciones medioambientales poco apropiadas.
desastres naturales: terremotos, ciclones, etc.
accidentes, como incendios, derrumbamientos, etc.

Utilizaremos el modelo OSI como marco de referencia, comenzando con el análisis de los problemas en el nivel físico de OSI y ascendiendo a través de las capas del modelo hasta llegar al nivel de aplicaciones.

Características básicas y clásicas para mejorar la disponibilidad:

Unidades de disco redundantes.
Sistemas operativos tolerantes a fallos.
Copias de seguridad de los datos.
Plan de recuperación ante posibles desastres

Se realizará un análisis de las necesidades de disponibilidad en las redes de almacenamiento de datos (SAN – Storage Area Networks) y se examinarán las necesidades de alta disponibilidad para dispositivos específicos de seguridad. Al analizar los niveles del modelo OSI, se observan dependencias y posibles mejoras por la relación entre cada uno de los niveles.

Diseño de soluciones de alta disponibilidad

La alta disponibilidad es una necesidad, no un lujo. En este ciclo, siguiendo enfoques de Cisco o Nortel, se pueden distinguir 4 fases:

se identifica una tecnología nueva y necesaria y se implementa. Ej: el correo electrónico o en el comercio electrónico.
Debe llegar a toda la organización. Puede que se necesiten más ancho de banda y otros conmutadores.
Aplicar servicios a esa nueva tecnología. servicios de administración, seguridad, aplicaciones nuevas y tener en cuenta cuestiones de políticas de rendimiento, calidad de servicio y contabilidad
Construir una infraestructura de administración utilizando marcos ITIL y estándares como ISO/IEC 20000 que garantizan guías para implementar y mantener procesos de gestión de capacidad, disponibilidad y continuidad.

Para lograr una red de alta disponibilidad se suele utilizar herramientas de casi todos los niveles del modelo OSI, desde la redundancia del nivel físico hasta las aplicaciones de gestión de red.

El modelo de referencia OSI

El objetivo: asumiendo cualquiera de los posibles escenarios de problemas, la capacidad de un usuario de acceder a los servicios que necesita para realizar su trabajo debe ser permanente. Si se piensa en la infraestructura de la red como el conjunto de los dispositivos y aplicaciones y que cualquiera en cualquier nivel OSI, puede fallar, se define el camino que se debe analizar para identificar problemas y solucionarlos

Los problemas de infraestructura y soluciones

El diseño de una infraestructura sólida del nivel físico es vital. Se debe mantenerlos encendidos mediante fuentes de alimentación duales que comparten la carga. Si una fuente falla, la otra continúa suministrando energía.

Sistemas de alimentación ininterrumpida (SAI/UPS). Si ocurre un corte de energía el SAI permite mantener la integridad del servicio. También protege los equipos contra fluctuaciones de tensión, regulando la intensidad de la corriente y eliminando sobretensiones o compensando reducciones de tensión.

inteligencia distribuida: ningún componente dentro de una «caja», que realiza una función específica, debe depender de otros componentes dentro de la misma «caja». cada elemento dentro de un sistema es independiente de los demás. Se establece un diseño distinto para el núcleo y los extremos de la red. En el diseño del núcleo, el centro de datos y los dispositivos de red se implementan utilizando sistemas redundantes.

Además, se puede agregar más redundancia mediante métodos como el «dual-homing» (sistemas con dos tarjetas de red) y caminos alternativos.

Acceso redundante al núcleo de la red

Métodos de redundancia del hardware:

dispositivos físicos, por ejemplo, dos o más encaminadores proporcionando servicios a los mismos usuarios, usando protocolos como el VRRP (Virtual Router Redundancy Protocol).
Agregación de enlaces, mediante protocolos como el IEEE 802.3ad. este protocolo sirve para aumentar la disponibilidad del ancho de banda entre dispositivos y da redundancia. si falla un enlace, el resto continúa pasando datos, aunque sea a una velocidad menor.

La capacidad de ofrecer múltiples caminos de datos abarca todos los niveles del modelo OSI, incluyendo no solo entornos típicos de LAN, sino también de WAN o MAN.

Los problemas en el nivel 2 de OSI y soluciones

La clave es aprovechar las características de la infraestructura y aumentar la disponibilidad del sistema sin propagar mensajes de broadcast. El problema no radica en la velocidad de los mensajes broadcast, sino en la existencia de un único camino de datos por el cual pueden viajar los mensajes. Para solucionar el problema de caminos con bucle, el protocolo más utilizado es el STP (Spanning Tree Protocol) que permite la existencia de bucles físicos

Factores relacionados con el STP que hay que tener en cuenta:

El tiempo de recuperación tras un fallo de un dispositivo y que tarda el STP en re-converger
añadir o eliminar un equipo de la red.
puesta en marcha o la eliminación de un enlace en la red.

Los cambios en la topología de una red STP pueden deberse a diversos factores. La convergencia de la red se basa en una serie de temporizadores ajustables que, en algunos casos, pueden resultar demasiado largos.

Estándar 802.1w, protocolo de re-convergencia rápida, permite que las redes se re-converjan en un segundo tras cambios en la topología. Esto se logra cambiando entre estados de puerto blocking y forwarding

El protocolo IEEE 802.1s, conocido como STP múltiples, permite crear varios árboles ST, lo que reduce significativamente la exposición de la red a problemas de convergencia en caso de fallos o durante el mantenimiento de sistemas.

Los problemas en el nivel 3 de OSI y soluciones

Los protocolos de encaminamiento adaptativo de IP permiten que los encaminadores conozcan dinámicamente su entorno local y compartan esta información con sus vecinos facilitando determinar el mejor camino entre estaciones. Hay dos tipos principales de encaminamiento adaptativo distribuido:

basados en algoritmos de vector-distancia (como RIPv1 o IGRP)

basados en algoritmos de estado de enlace (como OSPF o IS-IS).

¿Qué sucede cuando falla un encaminador?

El impacto de un encaminador que falla en la red depende de su ubicación y de qué otros dispositivos lo están usando. Si la red está diseñada para ser de alta disponibilidad, otro encaminador tomará el relevo y se recalculará la nueva ruta. Si el encaminador que falla está en el backbone, el resultado puede ser catastrófico. En redes que solo tienen un encaminador por defecto, perder dicho encaminador significa que la red queda completamente aislada.

Para eliminar en estas topologías el único punto de fallo, se ha desarrollado el VRRP (Virtual Router Redundancy Protocol) que utiliza dos encaminadores físicos. Uno en funciones de master y el otro de backup, configurados como un único encaminador virtual, con una única dirección IP «virtual» para los dos. En el ejemplo, los encaminadores A y B forman dos encaminadores virtuales, EV-1 y EV-2.

El encaminador A es el master y el encaminador B es el backup, dentro del EV-1. En el caso del EV-2, los papeles están cambiados, siendo el encaminador B el máster y representando el encaminador A, el papel de encaminador de backup. Con esta configuración ambos encaminadores están trabajando y enviando tráfico.

HSRP (Hot Standby Router Protocol) es un protocolo desarrollado por Cisco que permite establecer un encaminador por defecto de alta disponibilidad. Se utiliza en conjunto con los protocolos de encaminamiento OSPF o EIGRP. HSRP envía mensajes multicast de tipo «hello» a direcciones específicas usando el puerto 1985 para definir la prioridad de los encaminadores.

El encaminador con mayor prioridad actuará como encaminador virtual, respondiendo a las solicitudes ARP de las máquinas conectadas a la LAN. En caso de fallo, el encaminador de prioridad más alta siguiente tomará el lugar del primero, permitiendo un failover transparente del encaminador por defecto.

Consideraciones para el resto de los niveles OSI

La latencia puede afectar negativamente a los datos que circulan por la red, provocando que las aplicaciones no sean capaces de ofrecer el servicio adecuado al no recibir información crítica a tiempo.
Las políticas de gestión de niveles se implementan para evitar problemas en la red, ofreciendo diferentes niveles de servicio a sus componentes.
Estas políticas clasifican el tráfico de la red, paquete por paquete, y según la clasificación de los datos, se utilizarán una acción específica o un nivel de servicio determinado
Es necesario utilizar dispositivos de red capaces de reconocer y priorizar diferentes tipos de tráfico, tomando acciones según la información de niveles superiores e inferiores.
En el contexto de alta disponibilidad, la clasificación de paquetes puede basarse en un puerto físico, dirección de nivel 2 o 3, o información del nivel 4.
Según esta clasificación, se aplica una política, como gestión de VLAN, calidad de servicio o gestión del ancho de banda, etc., antes de enviar el paquete a la red.

Consideraciones para el almacenamiento en red: SAN (Storage Area Networks)

Componentes para una infraestructura de almacenamiento de alta disponibilidad:

Tecnología de discos RAID.
Múltiples copias de discos en un sistema cluster o granja de servidores.
uso de clusters a distancia.
redes de área de almacenamiento o SAN.
copias de seguridad fiables.

La arquitectura SAN permite configuraciones de alta disponibilidad a nivel organizacional, siendo escalables para crecer junto con la organización.

tres aspectos críticos en el subsistema de almacenamiento:

Protección de los datos.
- Memorias secundarias (caches) redundantes: Permiten que los datos se almacenen en una caché en lugar del disco, reduciendo la latencia. Al utilizar dos cachés en espejo, de manera que si una falla, los datos no se pierden.
- Discos RAID: Mejora la disponibilidad de datos brindando protección y acceso. Existen diferentes niveles de RAID:
  - RAID 1 (copia de datos en 2 o más discos)
  - RAID 5 (distribución de datos en 3 o más discos con información de paridad) dan disponibilidad adicional en caso de fallo de disco.
- Replicación de los datos: Se utiliza para protegerse contra un fallo del subsistema de almacenamiento completo.
  - de manera síncrona, dentro de un centro de datos local, con muy poco impacto sobre el rendimiento de las aplicaciones
  - de manera asíncrona, a largas distancias. La replicación puede realizarse mediante el propio subsistema de almacenamiento a través de una aplicación externa.
Conectividad del subsistema.
- Interfaces redundantes. Cada unidad lógica de disco debe estar accesible a través de varias interfaces
Redundancia hardware del subsistema.
- Redundancia de la alimentación.
- Redundancia de controladoras. Las soluciones de alta disponibilidad cuentan con controladores dobles, de manera que si una falla, la otra puede seguir teniendo acceso a los datos almacenados en el sistema.
- sistemas RAID+ spare: sistemas RAID que «cambia» de manera automática un disco en caso de fallo

Consideraciones para los dispositivos de seguridad

La alta disponibilidad en dispositivos de seguridad de una red a menudo no se aborda debido a su elevado costo. Pero si todo el tráfico pase por un cortafuego, el fallo de este aislará la red del resto del mundo

Se debe considerar dos cortafuegos, de modo que, si uno falla, el otro lo reemplace rápidamente, restableciendo la seguridad y tráfico. Es ideal que ambos cortafuegos sean del mismo modelo para asegurar un funcionamiento óptimo.

roles para los cortafuegos:

El primario es el activo que realiza las operaciones normales

El secundario está en reserva, listo para tomar el control si el primario falla. Al ocurrir un fallo, el secundario se convierte en el activo y el primario pasa a reserva.

Tipos de procesos de redundancia:

El proceso estándar de redundancia, en el que ambos cortafuegos están conectados entre sí mediante un cable especial, propietario, llamado cable de recuperación, que suele ser de longitud corta.
El proceso basado en LAN, que usa una interfaz LAN de cada cortafuego y un conmutador entre ambos, evitando así la limitación de distancia anterior.

tipos de proceso de recuperación:

normal: las conexiones TCP existentes se pierden y las aplicaciones deben reconectarse para restablecer las comunicaciones. ofrecen redundancia PERO no garantizan una pérdida cero de conectividad.
completa: Proporciona redundancia y conectividad completa en caso de fallos al mantener la información de estado de las tablas de conexión de los cortafuegos, evita la pérdida de conexiones y elimina la necesidad de reconexión.

COMPARTE y Siéntete libre de agregar más sugerencias en los comentarios a continuación.