Hace un par de semanas se realizó en Valencia una jornada de seguridad organizada por ISMS Forum donde pude asistir, entre otras, a una charla de Jelle Niemantsverdriet (el principal consultor forensics de Verizon), quien, aparte de remarcar la importancia de los logs para llevar a cabo sus análisis —importancia que también se ha remarcado en distintas entradas en este blog—, presento brevemente el framework VERIS desarrollado por Verizon.

El framework VERIS (Verizon Enterprise Risk and Incident Sharing) proporciona un lenguaje común para describir incidentes de seguridad de forma estructurada y repetitiva, basado en lo que denominan las cuatro ‘A’:

[Read more…]

Recientemente he tenido que volver a repasar parte del funcionamiento del Adaptive Security Algorithm de Cisco. De manera breve, este algoritmo es el encargado de inspeccionar el tráfico y permitir o denegarlo basándose en las políticas existentes.

A grandes rasgos, cuando una conexión llega al sistema, es procesada mediante el Session Management Path, quien se encarga de comprobar la tabla de rutas y NAT y las listas de control de acceso, de forma que si la política definida permite el tráfico, se crea una nueva entrada en la tabla de estados mediante el Fast Path, que es el encargado de revisar las cabeceras 3 y 4, comprobar el checksum IP, números de secuencia TCP, etc. El resto de paquetes de la conexión ya establecida son enviados directamente al Fast Path. La conjunción del Session Management Path y del Fast Path es lo que se conoce como Accelerated Security Path (ASP).

El problema por el cual he tenido que volver a revisar este funcionamiento ha venido provocado por un sistema Cisco ASA que denegaba paquetes de conexiones permitidas por la política de control de acceso del propio firewall, por lo que los contadores de ASP podrí­an aportarme más información sobre lo que estaba sucediendo en el sistema.

ASA# show  asp drop 
Frame drop:  
    No route to host (no-route)                                                  2  
    Flow is denied by configured rule (acl-drop)                               101  
    NAT-T keepalive message (natt-keepalive)                                     4  
    First TCP packet not SYN (tcp-not-syn)                                      29  
    Bad TCP flags (bad-tcp-flags)                                                8  
    TCP failed 3 way handshake (tcp-3whs-failed)                                 3  
    TCP RST/FIN out of order (tcp-rstfin-ooo)                                    7  
    ICMP Error Inspect no existing conn (inspect-icmp-error-no-existing-conn)    9  
    FP L2 rule drop (l2_acl)                                                    30
Last clearing: 09:49:26 CEST Nov 24 2011 by enable_15

Como se puede ver, se están filtrando paquetes no solo por la propia polí­tica de control de acceso, sino también por problemas de enrutamiento o inconsistencias en el protocolo TCP (si queremos capturar este tráfico, podemos hacerlo mediante el comando capture CAPTURA type asp-drop OPCION). Para intentar mitigar alguna de estas inconsistencias en el protocolo TCP, podemos seguir los siguientes pasos:

Como hemos visto, aunque lo habitual es que el tráfico se deniegue por la propia polí­tica, existen otras opciones que también pueden filtrar conexiones (antispoofing, inspección de tráfico, IPS,..) las cuales pueden estar configuradas por defecto en el sistema, por lo que es esencial disponer de un buen sistema de log que nos dé pistas de que esta sucediendo en el sistema, preferiblemente de forma automatizada buscando ciertos patrones en tiempo real, sin tener que llevar a cabo una revisión periódica por parte del administrador.

Es todo por hoy. La semana que viene introduciré el framework VERIS (Verizon Enterprise Risk and Incident Sharing), utilizado para algo tan necesario (y probablemente tan escaso) como es compartir información sobre incidentes de seguridad. Pasen un buen fin de semana y cojan o no puente (para aquellos que nos siguen desde fuera de España, el martes y el jueves que viene son festivos nacionales), les estaremos esperando.

Habitualmente, cuando hablamos de enrutamiento ya sea en un router, un firewall o un servidor conectado a varias redes, siempre se hace referencia a enrutamiento por destino, es decir, si quiero llegar desde el nodo A hasta el nodo B, miro en mi tabla de rutas la forma más rapida (mejor métrica) de alcanzar el nodo B y envío el tráfico por la ruta especificada. Si no tengo ninguna ruta especifica al destino, usaré la ruta por defecto, no obstante, hay ocasiones en que esto no es suficiente.

Supongamos por ejemplo, tenemos un sistema GNU/Linux (IP forwarding activado) con una conexión a internet por defecto (ISP1). Por necesidades de la plataforma, añadimos una nueva conexion a internet, y queremos que el servidor 1 se conecte mediante el ISP1 (ISP por defecto), y el servidor 2, mediante la nueva conexión al ISP2. Esto lo conseguiremos mediante enrutamiento por origen(en ningín momento hablamos enrutamiento dinámico ni balanceo de carga de forma dinámica entre los multiples enlaces).

En las distribuciones modernas de GNU/Linux, la forma de gestionar toda la configuración de red (rutas, dispositivos, túneles, etc) es mediante el comando ip (sí, los comandos ipconfig o route están deprecated aunque sigan existiendo). En GNU/Linux nos podemos encontrar distintas tablas de rutas, las cuales aparecen indicadas en el fichero /etc/iproute2/rt_tables:

#
# reserved values
#
255	local
254	main
253	default
0	unspec
#
# local
#
#1	inr.ruhep

Como podemos ver, existe una tabla main, la cual contiene las rutas de nuestro sistema (lo que vemos formateado con el comando route):

ip route show table main

# Red directamente conectada ISP1
20.20.20.0/24 dev eth0  proto kernel  scope link  src 20.20.20.20 
# Red directamente conectada ISP2 
30.30.30.0/24 dev eth1  proto kernel  scope link  src 30.30.30.30
# Red directamente conectada LAN
10.10.10.0/24 dev eth2  proto kernel  scope link  src 10.10.10.254
# Ruta por defecto  
default via 20.20.20.254 dev eth0 				             

También existe una lista de reglas que hacen uso de dichas tablas para enrutar:

ip rule show 

0:	from all lookup local 
32766:	from all lookup main 
32767:	from all lookup default

Son estas reglas las que nos darán toda la potencia del enrutamiento por origen, manipulando la RPDB (routing policy database) de nuestro sistema GNU/Linux; para ello, primero creamos una nueva tabla de enrutamiento; existen identificadores de tablas reservados para el sistema, no obstante, los identificadores entre el 1 y el 252 están disponibles para los usuarios:

echo "250	ISP2" >> /etc/iproute2/rt_tables

Añadimos las rutas a la nueva tabla ISP2. Todo lo que no enrute la nueva tabla, sera enrutado por la tabla main, usando las políticas definidas por defecto en el sistema. Puesto que nuestro ejemplo es sencillo, únicamente crearemos una ruta por defecto hacia el ISP2 y mantendremos el resto de rutas igual que están definidas en la tabla main:

ip route add 20.20.20.0/24 dev eth0  proto kernel  scope link  src 20.20.20.20  table ISP2
ip route add 30.30.30.0/24 dev eth1  proto kernel  scope link  src 30.30.30.30  table ISP2
ip route add 10.10.10.0/24 dev eth2  proto kernel  scope link  src 10.10.10.254 table ISP2
ip route add default via 30.30.30.254 dev eth1 table ISP2 

ip route show table ISP2

20.20.20.0/24 dev eth0  proto kernel  scope link  src 20.20.20.20
30.30.30.0/24 dev eth1  proto kernel  scope link  src 30.30.30.30 
10.10.10.0/24 dev eth2  proto kernel  scope link  src 10.10.10.254 
default via 30.30.30.254 dev eth1

Llegados a este punto, creamos una nueva regla que nos permita el enrutamiento por origen del Servidor 2 usando la tabla de enrutamento creada, ISP2:

ip rule add from 10.10.10.200/32 table ISP2

Podemos observar que nos crea una nueva regla de enrutamiento:

ip rule show

0:	from all lookup 255 
32765:	from 10.10.10.200 lookup ISP2
32766:	from all lookup main 
32767:	from all lookup default

A continuación, borraríamos la cache de rutas (o solo las rutas de cada tabla) mediante el comando ip route flush, indicando los parámetros correctos dependiendo del caso, y comprobaríamos desde el Servidor 2, que tenemos conectividad con el exterior a través de la nueva conexión. Para finalizar, solo quedaría añadir las rutas y reglas de enrutamiento a uno de los ficheros de arranque del sistema (o al fichero de configuracion de red) para que lo cargara después de cada reinicio.

Otra solución válida sería por ejemplo, marcar paquetes con iptables y crear reglas de enrutamiento a partir de las marcas creadas.

Más información : Linux Advanced Routing & Traffic Control HOWTO

Cuando hablamos de continuidad de negocio y planes de recuperación ante desastres, siempre nos vienen a la mente alternativas de recuperación del tipo Cold, Warm y Hot Sites dependiendo del RTO requerido por nuestra organización. No obstante, existen otras alternativas de recuperación menos conocidas (o al menos, menos aplicadas), por ejemplo los conocidos como Mobile Sites.

A grandes rasgos, un Mobile site no es más que un trailer que contiene toda la tecnología necesaria para dar soporte a una organización que se ha visto afectada por un desastre (generalmente con un RTO de entre 3 y 5 días), el cual puede ser ubicado de forma fácil en una zona considerada segura. Un ejemplo de este tipo de alternativa de recuperación ante grandes desastres (por ejemplo en el reciente terremoto de Japón) es el conocido como Cisco NERV (Network Emergency Response Vehicle). Este vehículo es capaz de conectarse vía satelite y proporcionar a la organización servicios de voz, vídeo y datos allí donde se requiere su presencia, tanto acceso a Internet como a redes remotas.

El sistema consiste en una serie de equipos capaces de proporcionar servicios de Routing, Firewalls, VPN, sistemas de vigilancia CCTV, equipos de conferencias de voz y datos, sistemas de telepresencia, telefonía IP (mediante CUCME), conectividad Wireless o integración con sistemas de radio mediante la funcionalidad LMR (land mobile radio) proporcionada por los routers y el sistema IPICS (Cisco IP Interoperbility and Collaboration System).

El vehículo también dispone de una serie de baterías, SAIs y su propio generador por si el suministro eléctrico se ha visto afectado por el desastre. Podemos encontrar información mas detallada sobre el vehículo en la página de Cisco sobre el producto (pdf).

¿Algún lector conoce un vehículo similar con tecnología de otro fabricante?

Generalmente, cuando administramos switches Cisco, es fácil encontrarnos con configuraciones idénticas en distintas interfaces de red. La forma habitual de configurar las interfaces, aunque sencilla, puede resultar tediosa, puesto que se trata de copiar la misma configuracion en distintas interfaces individuales o rangos de interfaces. No obstante, una forma más cómoda de hacerlo es mediante el uso de macros smartport.

Los macros Smartport son scripts de configuraciones creados previamente, que es posible aplicarlos a las distintas interfaces de red, de forma que ganamos consistencia y velocidad a la hora de configurar dispositivos.

Los Switches Cisco tienen varias macros creadas por defecto, que nos permiten configurar interfaces para soportar entre otros, equipos de usuario, telefonos, u otra electronica de red; mediante el comando show parser macro brief es posible ver las macros definidas en nuestro switch:

Switch#show  parser macro  brief                                                
    default global   : cisco-global                                             
    default interface: cisco-desktop                                            
    default interface: cisco-phone                                              
    default interface: cisco-switch                                             
    default interface: cisco-router                                             
    default interface: cisco-wireless

[Read more…]

Al hablar de seguridad siempre la consideramos como un proceso en lugar de como un producto, puesto que cada día aparecen nuevas vulnerabilidades y amenazas. Debido a éste proceso continuo, un aspecto crítico es la formación del personal que gestiona cualquier ambito de la seguridad.

Habitualmente, la formación en materia de seguridad (sin entrar en la autoformación), se lleva a cabo mediante cursos o certificaciones, ya sean técnicas o no. Una de las certificaciones mas valoradas (o al menos más solicitadas) es la certificacion CISSP (Certified Information Systems Security Professional) ofrecida por ISC(2) (International Information Systems Security Certification Consortium).

La certificación CISSP la podemos encontrar a medio camino entre una certificación puramente técnica y una dedicada más a aspectos de gestión. El proceso de certificación consta de 250 preguntas tipo test simples basadas en el Common Body of Knowledge (CBK), el cual está compuesto por los siguientes 10 dominios de seguridad:

1. Seguridad de la Información y Gestión de Riesgos (Information Security and Risk Management)
2. Sistemas y Metodología de Control de Acceso (Access Control Systems and Methodology)
3. Criptografía (Cryptography)
4. Seguridad Física (Physical Security)
5. Arquitectura y Diseño de Seguridad (Security Architecture and Design)
6. Legislación, Regulaciones, Cumplimiento de las mismas e Investigación (Legal, Regulations, Compliance, and Investigation)
7. Seguridad de red y Telecomunicaciones (Telecommunications and Network Security)
8. Planes de continuidad del negocio y de Recuperación Frente a Desastres (Business Continuity and Disaster Recovery Planning)
9. Seguridad de Aplicaciones (Applications Security)
10. Seguridad de Operaciones (Operations Security)

En España hay dos convocatorias, una en Barcelona (abril-mayo) y otra en Madrid (octubre-noviembre), pudiendo elegir el examen en inglés con la ayuda de un diccionario o en doble traducción inglés-español.

Dentro de los problemas que podemos encontrarnos a la hora de preparar esta certificacion destacaría:

• La duración del examen. El examen dura 6 horas, más el tiempo de registro previo, que suele ser entre 30 minutos y 1 hora.
• La multitud de documentación existente en el mercado. Existe gran cantidad de libros sobre la certificación, algunos de lectura más comoda que otros, y que, por muchos que leas, siempre te dejarás algo. Cuando piensas que ya te lo sabes, aparece una nueva referencia a un nuevo libro que debes revisar (y así sucesivamente).
• No todas las preguntas tienen el mismo valor, ni todas puntuan, por lo que vas un poco a ciegas a la hora de hacer cálculos sobre la nota (en este caso, al menos las incorrectas no restan).

Una vez que finalizas el examen, se tarda entre 4 y 6 semanas en obtener el resultado. Si has tenido la suerte de aprobar (tienes que sacar un mínimo de 700 puntos sobre 1000), empieza el proceso de certificación, donde tienes que demostrar detalladamente tu formación y experiencia en seguridad (mínimo 5 años en al menos dos dominios del CBK). También debes adherirte al codigo ético de (ISC)2. Los resultados de este proceso tambien tardan varias semanas en comunicarlos. Si finalizas de forma correcta todo el proceso, deberás acreditar una cierta cantidad minima de CPE (120 cada 3 años) para mantener la certificación, como ya sucede en muchas de las certificaciones existentes en el mercado.

Si están preparando la certificación y tienen alguna duda en la que podamos ayudarles, tienen los comentarios a su disposición.

Como vimos hace tiempo en el post sobre Checkpoint SYN Defender, cada vez es mas habitual encontrar fabricantes que añaden funcionalidad para mitigar algunos ataques de denegación de servicio en sus dispositivos de seguridad. En la ocasión anterior nos centramos en la solución SynDefender de Checkpoint y en esta ocasión, será en la característica TCP Intercept de los dispositivos routers de Cisco.

Como su nombre bien indica, Cisco TCP Intercept Feature es una característica de seguridad capaz de proteger y mitigar posibles ataques DoS basados en inundaciones TCP SYN contra nuestros servidores, monitorizando para ello el numero de intentos de conexión y en caso de ser necesario, reducir el número de conexiones TCP incompletas.

Cisco TCP Intercept se puede configurar en dos modos de funcionamiento, el modo intercept y el modo watch.

El modo intercept es un modo de funcionamiento proactivo, donde el dispositivo almacena en sus buffers internos los intentos de establecimiento de conexión de modo que hasta que la conexión no está totalmente establecida (3-way handshake), el dispositivo no establece la conexión contra el servidor final. Puesto que el dispositivo realiza el seguimiento y mantiene todas las conexiones, éste requiere de una gran cantidad de memoria y CPU. Este comportamiento es similar al modo relay de SynDefender de Checkpoint.

Por el contrario, El modo watch es un modo reactivo, donde se monitorizan pasivamente las solicitudes de conexión de forma que, si una conexión no se establece en un intervalo concreto de tiempo (30 segundos por defecto), el dispositivo envía un paquete TCP Reset al origen finalizando el intento de conexión y elimina la conexión half-open. La configuración de esta característica es sencilla, solo debemos seguir los siguientes pasos:

1. Definir una lista de acceso extendida
2. Habilitar la funcionalidad TCP intercept sobre dicha lista de acceso
3. Parametrizar, si es necesario, las posibles opciones de la funcionalidad (modo de funcionamiento, intervalos de tiempo, umbrales, etc.)

Una vez habilitada, podemos monitorizar su uso con los habituales comandos show y debug de Cisco. Como hemos visto y vimos en el post anterior, cada vez mas los dispositivos implementan mayores y mejores medidas para proteger nuestros sistemas de los posibles ataques.

Como sabrán, la semana pasada se celebró el IX Foro de Seguridad de Rediris en la Universidad Politécnica de Valencia, que ya presentamos en otra entrada con el lema “Seguridad en el Cloud Computing”, en las que S2 Grupo ha participado tanto como organizador como ponente. Este es un pequeño resumen de lo visto estas dos jornadas:

Sobrevolando el cloud computing. Seguridad y cumplimiento normativo.

Ramón Martín (Cloud Security Alliance, Autoritat Catalana de Protecció de Dades) nos hizo una breve introducción al Cloud Computing, enfocando las cuestiones relevantes en materia de seguridad de la información y definiéndolo como un modelo evolutivo de prestación de servicios, potenciado por distintos factores entre los que encontramos la conjunción de distintas tecnologías (virtualización, velocidad de acceso, uso dispositivos móviles), socialización de las tecnologías con un uso intensivo por parte de los usuarios y como casi siempre, la cuestión económica. Ramón nos mostró la arquitectura del cloud basada en componentes: características esenciales del servicio (acceso a red, velocidad, elasticidad), modelos de servicio (Saas, Paas, Iaas) y modelo de despliegue (publico, privado, publico, híbrido, comunitario) junto con distintas gráficas de beneficios, amenazas y retos existentes en el cloud.

La presentación está disponible para su descarga en la página del evento: descargar (PDF, 10.6MB)

[Read more…]

Hace ya algún tiempo, Toni Villalón nos hacia referencia a una técnica habitual en las auditorías de seguridad hace algunos años, el basureo (trashing), a partir de la cual podíamos obtener gran cantidad de información a partir de una papelera o cubo de basura. Sin embargo, ¿por qué ir rebuscando en la basura (que es algo sucio, desagradable y no sabemos con que podemos encontrarnos) si existen maneras mucho más fáciles, cómodas y limpias de obtener información? Además, sin ir muy lejos ni que te miren raro.

¿Dónde? En su impresora más cercana. Levántese, diríjase a ella y observe la documentación que nadie recoge, bien porque la envió a imprimir y olvidó que la había enviado, porque ya no la necesita, o por cualquier otra razón que se le ocurra. En realidad, el porqué no nos importa, lo que nos interesa es la información que contiene. Cójala y llévela a su sitio. Quizá le preocupe que su dueño legítimo aparezca de repente y le vea hacerlo, pero no se preocupe; lo más probable es que la haya abandonado, y en cualquier caso si acude a la impresora y ve que no está, la volverá a mandar imprimir, y probablemente volverá a olvidarla.

Una vez en su sitio, observe detalladamente la información que acaba de obtener. Con un poco de suerte, a lo largo de un par de semanas, habrá podido hacerse con información como la siguiente:

• Contratos para la prestación de servicios a clientes junto con sus acuerdos de confidencialidad. También ofertas para el suministro de material, donde indicaba precios y tarifas ofertadas.
• Listado de nombres, apellidos, teléfonos y correo electrónico de todo el personal de la empresa.
• Manuales de instalación de software junto con sus números de licencia.
• Informes para clientes, correos electrónicos impresos, correspondencia postal, etc.
• Documentación generada por los clientes de la empresa, donde aparecen las incidencias reportadas.

Además, si tiene la fortuna de que la impresora dispone de funciones de fax y servidor de correo electrónico, también podrá obtener sin demasiados problemas los listados de faxes enviados y recibidos durante los últimos meses, con los teléfonos de destino, cuentas de correo y nombres de usuario, junto con algunos reportes de faxes enviados, donde aparece la propia información enviada de forma parcial.

Quizá le parezca que la información que le comento no tiene apenas valor, pero lo cierto es que piensa eso porque probablemente no la tenga para usted. Ese es, entre otros, el propósito de un sistema de clasificación de la información: identificar y clasificar la información en base a criterios objetivos, evitando que cada uno valore la información con la que trabaja según le afecte más o menos. Ahora, para acabar esta pequeña simulación, imagine ahora que usted no trabaja allí. Usted es “sólo” un externo que trabaja allí de manera temporal. Dentro de un par de semanas se irá de allí, con una carpeta llena de información que nadie jamás echará de menos (sus dueños piensan, extrañamente, que se la comió la impresora, por lo que la volvieron a imprimir).

La conclusión lógica a este pequeño episodio es que dedicamos muchos esfuerzos en implantar medidas de seguridad técnicas, como cortafuegos, controles de acceso lógico, sistemas de monitorización, o detectores de intrusos, para asegurarnos de que las personas no autorizadas puedan acceder a información sensible de la empresa. Sin embargo, muchas veces nos olvidamos o dedicamos menos esfuerzos en la implantación de medidas menos técnicas y más organizativas, como podrían ser destructoras de papel, controles de acceso físico, políticas para el uso correcto de las impresoras y faxes, política de mesas limpias…

Ahora, acérquese a su impresora. Quizá descubra algún tesoro oculto sin dueño.