Fugas de Información en los Routers Mikrotik

Cuando se quiere realizar un APT (Advanced Persistent Threat) a una empresa o a una organización, uno de los aspectos fundamentales es conocer su esquema de direccionamiento IP interno que utiliza y, si es posible, cuál es su arquitectura de red para, por ejemplo, ver si tienen zonas desmilitarizadas y a partir de ahí poder inferir cuántos routers/firewall configuran su sistema de protección perimetral.

Figura 1. Fugas de Información en routers MikroTik.

A parte de lo anterior, resulta muy interesante conocer, si es posible, el nombre de alguno de sus empleados y, por qué no, también el del administrador o administradores de la propia red.

Con toda esta información se puede plantear incluso el realizar algún ataque de Ingeniería Social.

Router Mikrotik

Estos routers son muy conocido dentro de las redes debido a su buen funcionamiento y bajo coste y son una alternativa a otro tipo de marcas en elementos de electrónica de red como puede ser CISCO. El sistema operativo que incorporan estos dispositivos es RouterOS y trae muchas características avanzadas de configuración.

Figura 2. Sistema operativo RouterOS y servicio asociado al puerto 80 TCP.

Entre las característica que incorpora RouterOS, cuenta con un servidor web que sirve para una configuración más cómoda con un entorno gráfico bajo HTTP más agradable, en lugar de utilizar los comandos propios del sistema operativo a través de una shell.

Es precisamente la configuración por defecto de este servicio el que va a permitir realizar el descubrimiento de recursos de la red de la organización como veremos a continuación.


Búsqueda de un patrón para realizar Dorking

Para poder aplicar técnicas de dorking, el primer paso es buscar un patrón común a estos dispositivos a partir del cual poder extraer más información utilizanzo los principales motores de búsqueda. Para ello, lo primero es obtener direcciones IP de estos dispositivos, por ejemplo, utilizando Shodan.

Figura 3. Búsqueda de routers Mikrotik.

Una vez localizados estos dispositivo, lo siguiente será tratar de obtener el nombre de los recursos que están en su servidor web, como pueden ser nombres de ficheros, de directorios, etcétera. El nombre de estos recursos y el comportamiento del servidor web serán quiénes nos den el patrón para las técnicas posteriores de dorking.
Para el descubrimiento de estos recursos, empleamos técnicas de spidering. ZAProxy es una buena herramienta para realizar el descubrimiento de recursos:

Figura 4. Recursos descubiertos por el spider de ZAProxy.

La petición que genera la respuesta anterior es http://115.x.x.x/graphs/, luego un posible patrón a utilizar en las técnicas de dorking puede ser para el texto “Traffic and system resource graphing” y para la url “graphs”. Usando Google, podemos emplear el siguiente dorking:

Figura 5. Resultados después de realizar Google Hacking.

Uno de los resultados devueltos por Google es el siguiente:

Figura 6. Router Mikrotik con 5 interfaces de red.

Observamos cómo, debido a una configuración insegura por defecto del servidor web del router, podemos ver el número de las interfaces de red y el nombre de cada una de las redes que comunica. De la información anterior, podemos inferir que es un único router quien comunica la red interna de la organización con la DMZ y los recursos de la DMZ con Internet.
Además, es muy probable que tenga un firewall con reglas de entrada y salida para el tráfico de la organización. Si pinchamos encima de una de las interfaces, podemos ver el tráfico de red que pasa por ella:

Figura 7. Tráfico de red que atraviesa la interfaz de la DMZ de la organización

Es más, a partir de la información de las interfaces de red podemos inferir un posible esquema perimetral de defensa de la organización:

Figura 8. Diagrama “retro” de la posible defensa perimetral de la red de la organización.

IP  Private Disclosure políticas

Los resultados anteriores son consecuencia de una mala configuración por defecto del servidor web que permite hacer un listing de los recursos que almacena.
Esta situación se puede aprovechar para intentar extraer también cuál es el esquema de direccionamiento interno de la organización aplicando técnicas de hacking con buscadores con los dorkings que hemos comentado anteriormente.
Sólo tenemos que añadir los prefijos de direccionamiento privado que queramos encontrar. Por ejemplo, si queremos extraer el esquema de direccionamiento privado sobre IPv4 para una red de clase C, podemos emplear el siguiente dorking:

Figura 9. Extracción de direccionamiento privado de clase C sobre IPv4.

Seleccionando uno de los resultados devueltos por Google, podemos ver cuál es el esquema de direccionamiento interno de la red interna, así como tener acceso a datos referentes a uso de CPU, memoria y almacenamiento en disco.

Figura 10. Información de la red interna de la organización.

En la figura anterior puede verse que, asociada a cada una de las direcciones IP de la red interna, es posible que éstas tengan algún tipo de política en las colas relacionada con la QoS (Quality of Service), seguramente relacionadas con la velocidad de subida y de bajada.

Figura 11. Política de velocidad de transferencia asociada a una dirección IP (I).

Si consultamos cuál es la política asociada a otra de las direcciones IP interna de la organización, observamos cómo, en este caso, la velocidad de transferencia es diferente:

Figura 12. Política de velocidad de transferencia asociada a una dirección IP (II).

Observamos como la velocidad máxima permitida para la máquina con dirección IP 192.168.0.5 es mayor que la vinculada a la 192.168.0.14. Si alguien dentro de la organización quisiera tener más velocidad de transferencia, únicamente tendría que consultar cuáles son las direcciones IP que disfrutan de este privilegio, y cambiar su dirección IP, siempre y cuando se tengan los permisos para modificar la configuración de la interfaz de red, la dirección IP no esté ocupada, etcétera.

Extracción del nombre de los posibles trabajadores de la organización

Hay veces en que los administradores de red ponen nombres de personas a las políticas aplicadas a cada una de las colas asociadas a las direcciones IP de las máquinas. 

Es por ello que si probamos con los dorkings anteriores a buscar el nombre de personas, es posible que encontremos el de alguno de los posibles miembros de esa organización, como se muestra en las siguientes figuras:

Figura 13. Nombres de personas vinculados a las políticas de las colas (I).

Figura 14. Nombres de personas vinculados a las políticas de las colas (II).

Es más, pulsando en el nombre de las personas anteriores podemos obtener información de su dirección IP interna (direccionamiento privado IPv4 de clase A) y de cuál es la política de velocidad de transferencia que tienen asignada.

Figura 15. Características del tráfico de red para una persona en concreto.

En la figura anterior podemos ver además, para una persona en concreto, en qué franjas horarias se han producido los mayores picos de descarga. Puede que se produzcan al entrar al puesto de trabajo, después de la comida o incluso después del almuerzo.

Y es más, a partir del nombre de posibles miembros de la organización, se podría obtener, por ejemplo, información relativa a una posible matrícula de su posible coche:

Figura 16. Posible personal de la organización.

Figura 17. Posible matrícula de coche relacionada con el auto de una posible infracción.

Conclusiones

Para evitar toda la fuga de información que hemos visto en este artículo y poder obtener información más sensible como el direccionamiento interno de una organización, políticas de calidad de servicio en su red interna, posibles nombres y apellidos de miembros de la organización, inicialmente podría pensase acceder al router para su administración únicamente a través del servicio SSH, es decir, dejar únicamente el puerto 22 TCP abierto para la administración del dispositivo y nunca hacerlo mediante el servicio HTTP. 

Aún así, como vimos los que hicimos el curso Attack and Hardening en GNU Linux,  si se quiere una administración remota del sistema, para cualquier puerto de administración, podría establecerse permisos únicamente para un pool de direcciones IP fijas y de confianza o, simplemente, realizar la administración del dispositivo desde la red interna de la organización, nunca desde Internet.

Colaboración por cortesía de: Amador Aparicio de la Fuente

@amadapa 

Leer más...

Maltrail: Herramienta para monitorización de red y detección de amenazas

Hacía días que tenía echado el ojo a esta herramienta que ví en el twitter de “nosequién” (mis disculpas a quien corresponda, porque suelo poner los créditos de estas cosas, pero sinceramente no recuerdo la fuente).

En este caso, se trata de maltrail, una herramienta opensource, hecha en Python, destinada a analizar el tráfico de red con el fin de detectar y registrar posibles amenazas. Hasta aquí todo bien, y seguro que diréis: pues otro Snort o Suricata, ¿no?. Pues la respuesta es: parcialmente sí.

La diferencia es la categorización de las amenazas, las diversas fuentes de las que tira (si la dirección IP tiene mala reputación en diferentes fuentes abiertas), la inteligencia para identificar actividad sospechosa, la identificación de malware que intenta llamar a casa, así como la presentación de panel de detección que muestra, me ha resultado especialmente interesante, o cuanto menos, complementario a la pila de paneles web de diversas herramientas destinadas a monitorizar la seguridad.

Muestra diversas estadísticas como número de amenazas, tendencias de eventos clasificados como riesgo alto/medio/bajo, gráficas de tarta por severidad, por top de fuentes atacantes, etc,...

El tipo de despliegue es como el de cualquier IDS, es decir, sondas de detección que envían eventos a un único servidor, por lo que es totalmente viable una arquitectura distribuida, o incluso aprovechar, sondas existentes que estén analizando tráfico con otras herramientas open source, para integrar un proceso más. He podido comprobar que no incrementa de forma excesiva los recursos necesarios de la máquina por lo que en un tráfico “normal” es una opción interesante.

Entre los puntos positivos, y a destacar:

• Dispone de una documentación bastante completa. Para lo sencillo que es de configurar (un único fichero con pocas opciones), la documentación existente es muy buena y más que suficiente sobre las virtudes de la herramienta
• Posibilidad de escuchar en un interfaz o en todos los de la máquina sensor.
• Impresionante la GUI. De verdad. Lo que más me gusta es la facilidad de filtrado de eventos, así como la interacción que permite con cada columna, dependiendo de qué se trate. Por ejemplo búsqueda de la dirección IP atacante en duckduckgo para búsqueda de la IP en diferentes fuentes de análisis  de reputación como robtex, whois.domaintools, mxtoolbox, etc,... 
• Plug and play: sólo tiene un paquete como dependencia.
• Open source 

Como puntos mejorables:

• La gestión de usuarios me parece uno de los puntos flacos… Está dentro del único fichero, y para cambiar la contraseña hay que ejecutar un .py que te convierta la contraseña a un hash, que habrá que copiar en el fichero.
• Por defecto, la gestión web viene en HTTP, aunque se puede configurar fácilmente para que sea HTTPS. A mi entender una herramienta de seguridad debería venir en HTTPS por defecto, aunque el certificado sea autofirmado.

Sin duda, una herramienta que merece la pena tener en el kit de elementos de seguridad perimetral

Podéis descargarla directamente de github en: https://github.com/stamparm/maltrail/

Leer más...

Taller de Seguridad Perimetral en Navaja Negra #NN4ED con @cyberoam

Como ya anunciamos en Security By Default, y está ya en boca de todos, la cuarta edición del Congreso de Seguridad Navaja Negra, está a la vuelta de la esquina!! 

Aunque ya lo ha comunicado la organización de Navaja Negra, en la edición de este año, Cyberoam (como patrocinador del evento) y Securízame (como colaborador), tendrán participación activa en un taller de Seguridad Perimetral de dos horas de duración.

En este taller, cuyo título oficial es: "Securízate! Buenas Prácticas de Configuración de Sistemas de Seguridad Perimetral", daré un subset del curso que he dado en otros eventos de seguridad, como el ACK Security Conference en Colombia, PeruhackCON 2013, o No cON Name en 2012, y que está en la web de Securízame para ser impartido online en su totalidad, cuando haya aforo suficiente, así como disponibilidad de fechas en mi agenda, cosa que está bastante complicada últimamente.

En este taller, normalmente, suelo contar cómo configurar o disponer, en la topología de una red, diferentes herramientas, libres o comerciales, que nos ayudan a disponer de un control y de una monitorización mayor de la actividad de nuestras redes, así como la prevención de diversos ataques, a nivel perimetral, no confiando en los posibles fallos de seguridad o defectos en la configuración, que incorporen las aplicaciones o servicios expuestos a Internet tras dichas barreras de contención.

En esta ocasión, y con una duración de dos horas, mostraré cómo llevar a cabo varias de esas labores, como configurar correctamente, entre otras cosas, una política de reglas de firewall, IPS, WAF, Antispam, análisis de tráfico saliente, QoS, etc,... de la forma más óptima posible (según mi experiencia), utilizando como base un appliance CR25iNG del fabricante Cyberoam.

El taller será de acceso libre y gratuito (hasta llenarse el aforo) e incluido en la entrada, al igual que los demás (que por cierto también tienen una pinta increíble), de manera que permitirá a los asistentes aprender Buenas Prácticas de configuración de sistemas de seguridad perimetral, incluidos dentro de los UTM de Cyberoam.

Como punto importante, es que el sponsor ha ofrecido un dispositivo Netgenie, el hijo menor de Cyberoam, orientado al mercado SOHO o casero, para ser sorteado al final del taller, entre los asistentes al mismo.

Nos vemos en Albacete a primeros de Octubre y espero que disfrutéis el taller!!

Leer más...

"Intrusion Prevention Systems" y "Modern Malware" for Dummies

Seguramente todos conocemos la serie de libros “For Dummies”, que podemos encontrar en cualquier librería y con temáticas muy variadas.

El año pasado, Alex nos hablaba y enlazaba un montón de ejemplares de Libros for Dummies específicos sobre Seguridad  

Curiosamente, en las dos últimas ediciones del Congreso de Seguridad español RootedCon, dos patrocinadores del evento regalaban dos de estos libros en papel: “Intrusion Prevention Systems” for Dummies y “Modern Malware” for Dummies, respectivamente en las ediciones de 2013 y 2014. 

Pasamos mucho tiempo devorando PDFs, y de vez en cuando, me gusta recordar cómo se siente  eso de usar libros en papel. 

Aunque ambos libros no pasan de las 70 hojas, os hago un resumen rápido de cada uno:

“Intrusion Prevention Systems” for Dummies, en su momento estaba patrocinado por Sourcefire, un fabricante de IPS basado en Snort.

En los primeros capítulos habla de topología de red, y nos ayuda a entender las diferencias entre IDS e IPS, así como dónde debe colocarse cada tipo de dispositivo, y las capacidades de cada uno, así como las diferencias teóricas entre NIDS/HIDS o NIPS/HIPS. Igualmente, indican las posibilidades de análisis de tráfico en entornos virtualizados, cloud, así como las diversas normativas internacionales (SOX, PCI-DSS, HIPAA, SAS70, etc,…) que requieren que haya un despliegue de IPS que analicen el tráfico. 

También habla de los diferentes motores existentes para detectar/prevenir ataques utilizados por los principales fabricantes, y lo bien que se adaptan a todos los tipos de malware, APT y detección de Zero-Days. No puedo evitar sonreir y leer con un cierto escepticismo estas cosas cuando ves la cantidad de organizaciones afectadas por vulnerabilidades de tipo Zero-Day que han tenido, más que seguro, despliegues de IPS. 

Que no se me malinterprete por lo que he dicho anteriormente. Por supuesto, no puedo dejar de recomendar que haya configuraciones mixtas de IDS e IPS en las organizaciones, puesto que ayudarán a detectar anomalías, bloquear de forma efectiva muchos ataques, y servir como muy buenas fuentes de información por los logs generados, al hacer un análisis forense, si hay un incidente, pero hay que tener claro que no son efectivos al 100%.

Quiero destacar algo que se menciona en esta obra, con lo que, en mi opinión, estoy de acuerdo pero parcialmente. Típicamente, y por la localización donde va cada dispositivo de seguridad, está claro que un IDS analiza una copia del tráfico y un IPS sobre el tráfico original, pudiendo bloquear lo que considere un ataque. Sin embargo, se dice en este libro, que un IDS sólo permite detectar un ataque y no tomar decisiones de bloqueo de dicho tráfico. Originalmente, esto se pensó así, pero el autor no ha tenido en cuenta la posibilidad que tienen (o tenían algunos IDS como ISS, en su día) de enviar un TCP RST al origen y al destino del ataque detectado. Recuerdo que hace años, en un ISP en el que trabajamos Yago y yo, protegimos del malware MyDoom, los servidores de correo a través de los que se transmitía esta joya. Importamos las reglas SNORT en ISS mediante lo que se conocía como reglas TRONS (SNORT al revés) y disponíamos de una interfaz de red con pila TCP/IP que construía y enviaba paquetes con el flag RST activo, de forma cruzada, spoofeando el origen. Otra opción es que aquellos firewalls que permitan interacción desde otros dispositivos, ya sea por API o por un protocolo bastante antiguo llamado OPSEC, se puede indicar como reacción al IDS que así lo haga.

De complementar funcionalidades de los IPS con WAF (Web Application Firewall) no se habla en este libro.

En mi opinión, por el tiempo que se invierte en leer menos de 70 hojas, merece la pena. Si más o menos el lector se abstrae de cosas enfocadas al fabricante que lo patrocina, para personas que se estén iniciando en el mundo de la seguridad, o reciclando de otros sectores, y que nos soléis preguntar por dónde empezar, es un buen complemento a la formación sobre seguridad perimetral  

 “Modern Malware” for Dummies, patrocinado por Palo Alto, fabricante de UTMs

Este libro, que también recomendó hace una semana nuestro amigo 1gbdeinfo en su blog, sí que lo veo de muchísimo más valor que el anterior. Se habla de diferentes maneras por las que se puede introducir el malware en las redes, que ya no está escrito generalmente por gente ávida de fama, sino por gobiernos, agencias de inteligencia, mafias y grupos organizados de individuos que con motivación, financiación y recursos son capaces de saltarse muchos de los mecanismos de protección actuales. Igualmente se explica diferentes técnicas típicamente utilizadas en malware y botnets, como cifrado y ofuscación, así como el uso de “covert channels” para comunicarse al exterior con su creador, de forma “invisible” o al menos muy complicada de detectar. 

Obviamente, hay un capítulo destinado a explicar cómo un Next Generation Firewall es capaz de ayudar a controlar este tipo de amenazas. 

Sin darle el mismo sesgo que al anterior, lo he visto bastante interesante y muy recomendable para tener cierta cultura sobre esta temática. En menos de 70 páginas no se puede terminar con unos enormes conocimientos, pero se hace bastante agradable de leer.   

Leer más...

Securizando un entorno de máquinas virtuales con Virtualbox

La virtualización ha dejado de ser únicamente una moda, y, con los agravantes de los recortes por la crisis y la conciencia ecológica, se ha convertido en una forma de vida para todo tipo de organizaciones. Por esto, la seguridad ha tenido que reinventarse para poder adaptar conceptos como la correcta segmentación de redes, que anteriormente se hacía mediante diversas interfaces de red, VLANs y cables físicos conectados a una maraña de servidores, para definir políticas de acceso entre máquinas virtuales que corren en un mismo servidor físico.

Dentro de los sistemas de virtualización, hay una amplia elección profesional para elegir, por lo que las organizaciones que dispongan de recursos económicos para ello, pueden acudir a sus supermercado de productos de seguridad favorito, y hacerse con costosas licencias para crear entornos virtuales. En general, estas plataformas profesionales, permiten definir redes virtuales diferenciadas con políticas de seguridad que especifican el tráfico permitido entre ellas.

Como he dicho antes, para una organización más humilde o alguien que esté empezando una aventura empresarial (que las hay, incluso en España en 2012), la solución libre Virtualbox puede cubrir de sobra las necesidades de virtualización.  

Desde el prisma de un purista de la seguridad, tal cual explico en mi curso de Buenas Prácticas de Seguridad en Entornos Corporativos, el primer paso, para segmentar las redes que existirán en una organización, es identificar los diferentes servidores/servicios para decidir su distribución. Aquellos que necesiten tener una puerta por la que entre tráfico desde Internet, deberá ir en una DMZ de servicios públicos o frontend. La ubicación de los servidores que nutren estas aplicaciones públicas deben ir en una red diferente y protegida, o de backend. El tráfico a permitir entre todas estas redes habrá de ser el justo y necesario para evitar exposiciones de servicios/máquinas por error. Más o menos como se puede ver en el dibujo de abajo, y siguiendo los consejos que ya explicamos en "Cómo diseñar una política de cortafuegos"

"Bueno vale, después de la clase de pizarra que nos has soltado… cuéntanos esto del Virtualbox"

El problema de VirtualBox es que no dispone de una consola remota como tal, con la que gestionar las máquinas virtuales y con la que definir diferentes redes virtuales, así como asignar políticas de seguridad, por lo que habrá que inventarse algo por debajo, que supla esta carencia.

Partimos del caso de una organización pequeña en que disponemos de una máquina Linux, con recursos suficientes de RAM y disco duro, en la que instalaremos Virtualbox. Esta máquina dispone de conectividad a Internet (porque esté conectada al router ADSL o a una ONT de fibra óptica), y quizá conexión con una red LAN o wireless. Supongamos entonces que la máquina dispone únicamente de un par de interfaces físicos de red: uno conectado hacia Internet y otro hacia una red privada. 

Vamos a crear dos nuevas redes que permitan unir servidores de dos tipos: de frontend y de backend. Para ello, Linux provee de diferentes herramientas que permiten crear interfaces virtuales. En este caso vamos a definir dichos interfaces virtuales como tipo TAP [http://en.wikipedia.org/wiki/TUN/TAP]. 

Para ello, haremos, por cada red que queramos definir los siguientes pasos:

Si necesitamos más interfaces virtuales, repetiremos las dos líneas "tunctl" e "ifconfig" con un nuevo intefaz virtual y el direccionamiento a asignar a sucesivos tap1, tap2, etc,…

Se supone que esto crea un interfaz de red virtual "persistente" asignado al uid 0 (si ejecutamos como root la orden, claro). Sin embargo, deberemos repetir los pasos de la definición de interfaces cada vez que arranque la máquina física. Para ello crearemos un script, en el /etc/rcX.d que corresponda, para que se definan los interfaces de red ANTES de que arranquen las máquinas virtuales. Es decir, no lo hagáis en el /etc/rc.local, que como sabréis, se ejecuta como último script de los de arranque.

Lo siguiente que tenemos que hacer es definir el interfaz de red de la máquina virtual que quedamos, como "Bridged Adapter" y seleccionaremos el interfaz "tap" que hayamos definido para esa red. 

Repetiremos este proceso para todas las máquinas virtuales según nuestras necesidades de pertenecer a la DMZ pública o a la privada. El direccionamiento de red a asignar a las máquinas virtuales de ambas redes, deberá pertenecer al mismo que tiene cada interfaz virtual TAP. En el caso del ejemplo, deberían pertenecer al rango 192.168.5.0/24. 

De esta manera, las máquinas de la DMZ pública, que ofrezcan servicios a Internet, quedarán en una DMZ virtual y las de backend en otra.

Viajando a la paranoia extrema

"Oye, ¿y si me comprometen una máquina, no podrían saltar a otra de la misma red?" Pues la respuesta es "puede". Si te comprometen una máquina virtual, las posibilidades son las mismas que en una red DMZ física, por lo que si la seguridad de cada una de las máquinas, a nivel individual, no ha sido tenido en cuenta convenientemente, podemos tener un problema mayor.

Para reforzar este posible caso, si queremos, podemos darle una vuelta de tuerca más, haciendo incluso que, la opción de máquinas virtuales sea más segura que la opción de redes físicas. Para ello, lo que haremos, en vez de definir un interfaz virtual por cada red, será crear un interfaz TAP por cada máquina virtual. Asignaremos desde el panel de Virtualbox el interfaz TAP, en modo bridge a cada máquina y utilizaremos subnetting para optimizar el espacio de direcciones IP.

Si antes usábamos una red con máscara 24 (255.255.255.0), ahora usaremos una máscara 30 (255.255.255.252). Los 30 bits de máscara nos permite 4 direcciones IP: la primera es la dirección de red, la última el broadcast de esa red y las otras dos son las "usables" para asignar a dos interfaces de red, creando una conexión Punto-a-Punto. Una será para la máquina virtual que montaremos en esa red, y otra para el interfaz tapX de la máquina física (que actuará de default gateway para la máquina virtual).

En el caso de 192.168.5.0/30 por ejemplo, tendríamos la 192.168.5.0 como dirección de red, la 192.168.5.3 como dirección de broadcast y la 192.168.5.1 y 192.168.5.2 como direcciones asignables. Si os liáis con el subnetting, podéis usar este enlace para el cálculo online de direcciones IP

Así, para acceder a otras máquinas, habrá que pasar sí o sí, a través del firewall… por lo que una política de seguridad estricta, asegurará, que si nos comprometen cualquiera de las máquinas virtuales, no será sencillo saltar a una "de las de al lado". Desde el punto de vista de la gestión de máquinas virtuales puede llegar a ser más lioso, pero como siempre, seguridad y usabilidad, se llevan mal. Este esquema es lo más parecido a implementar las Private VLAN que permite la electrónica de red Cisco.

Y ahora me diréis… ¿y si te comprometen la máquina física desde el propio acceso a Internet?  Pues lleváis razón. Quien tenga acceso a la máquina física puede acceder a los datos de todos los servidores contenidos en ella.

De vosotros dependerá securizar convenientemente esa máquina física, o incluso crear una máquina virtual nueva, que sea la que haga las labores de firewall, con un interfaz de red asignado (bridge) a cada una de las nuevas redes que hemos creado.

Así, la máquina física, si logramos que no tenga servicios de ningún tipo hacia el exterior, será un bastión muy difícil de vulnerar.

Leer más...

Llegan los recortes, también a la seguridad

Lamentablemente, nos estamos acostumbrando a que, todos los viernes, tengamos una sorpresa nueva de recortes por parte del gobierno de España. La crisis se ha extendido, con la velocidad de la peste, a todos los sectores. Empresas en las que la seguridad era algo en lo que NO se podía recortar, porque "imagínate si no invertimos en seguridad, nos la pueden liar",… han pasado a tener el presupuesto justo para pagar los mantenimientos de los medios de seguridad más importantes y nada más. He llegado a ver casos extremos en que ni siquiera los discos de una SAN, donde se almacenaba la información más valiosa de la organización, estaban bajo mantenimiento...

En épocas de bonanza en las que las empresas destinaban cantidades ingentes de dinero en adaptarse a la mitigación de las últimas amenazas, se veían grandes infraestructuras formadas por una legión de máquinas especializadas en protección perimetral.

Bueno, y si ahora hubiese que recortar: ¿con qué nos deberíamos quedar?

La verdad es que es difícil para un responsable de seguridad, acostumbrado a "un estado de bienestar" con infraestructuras que le ayudan a su trabajo diario, tener que sacrificar a uno o varios de sus "hijos" para poder seguir adelante. Como cada día, en la vida, las decisiones se toman evaluando los riesgos y priorizando lo que realmente es imprescindible, ante lo que es necesario y lo deseable. 

Después de leer artículos en los que se llega a dudar de la importancia/necesidad de elementos de seguridad como los propios cortafuegos, he querido elaborar mi propia lista de recortes explicando el por qué.

Recortemoshh pueshhh…

• Los cortafuegos, en mi opinión, serían "la Sanidad", y NO deberían "recortarse"/"eliminarse" en ninguno de los casos. En los artículos que menciono anteriormente, los autores se refieren a los firewalls como aquellos elementos que simplemente filtran tráfico en base a origen/destino/puerto… Creo que se plantean la "imprescibilidad" de los firewalls porque tienen en mente la funcionalidad que tenían estos dispositivos de los años 90. En este siglo los firewalls, además de dotar de mecanismos de mitigación de ataques propios de red (SYN-Flood, Land, Smurf, etc,…) comenzaron a incluir en la misma caja montones de funcionalidades: VPN, Antimalware, Antispam, IPS, gestión de ancho de banda, gestión de contenidos y proxy saliente (análisis de tráfico web), etc… es decir, que los UTM (Unified Thread Management) no pueden ser eliminados de las infraestructuras. Una opción de recorte, para evitar pagar altos precios en mantenimiento de estas soluciones, sería buscar una opción libre. Sin embargo, en una sola caja, aún no doy con un pack de funcionalidades UTM con una GUI elaborada, que me convenza totalmente contra soluciones comerciales (aunque típicamente caras) como Checkpoint, Fortinet, Juniper, Stonesoft o NetASQ.

• Antimalware: Aunque hay opciones libres como ClamAV o Avast!, en general las políticas de compras de las grandes y medianas corporaciones, prefieren que estas soluciones sean "de marca". En mi caso, llamadme tradicional si lo preferís, pero yo también lo prefiero. No voy a mostrarme más a favor de unos que de otros: pero mis top serían los que llevan años funcionando durante años: McAfee, Trendmicro, Kaspersky, Symantec, NOD32 o el producto nacional Panda. En general, las buenas prácticas de seguridad, recomiendan que los antimalware que se incluyen en el gateway y en los puestos de trabajo, sean de diferente fabricante/marca/tecnología. Si tuviésemos que recortar en algo, evidentemente no se puede prescindir de solución antimalware, pero sí que se puede aunar en un mismo fabricante (siendo consciente que el nivel de seguridad puede disminuir) a fin de conseguir una mejor oferta.

• Sondas IDS/IPS: Si además de enterarnos/bloquear ataques de aplicación a nivel del firewall, es necesario almacenar eventos de ataque en otro tipo de redes no separadas por algún firewall/UTM (quizá sea un problema de diseño de la red), las sondas IDS/IPS deberían mantenerse, aunque puede migrarse a soluciones libres como Snort, el IDS/IPS libre por referencia.

• Consolidación y correlación de eventos: Típicamente muy caras, las soluciones comerciales tipo RSA Envision o HP Arcsight. Dado el gran número de elementos de una red grande, este tipo de dispositivos, hace manejable el saber "qué está pasando" en la red en todo momento, y ser capaces de encontrar un problema de forma rápida. Sin embargo, en época de recortes, se puede perder calidad de eventos/reporting yendo a herramientas económicas (o gratuitas) como OSSIM o Syslog-NG (salvando las enormes diferencias entre uno y otro) por ejemplo.

• Sistemas de monitorización: Herramientas comerciales conocidas y muuuy caras del estilo de HP Openview, pueden ser sustituidas por opciones libres como Cacti y/o Nagios.

• Sistemas Anti-DoS: Aquellas organizaciones que cuenten con este tipo de soluciones "anti-Anonymous" del estilo de Arbor Networks (siempre he dudado de su efectividad ante un ataque con suficientes seguidores, pero bueno), deberán plantearse, si no suelen aparecer en las charlas de 4Chan, el considerar estas soluciones como algo "deseable" en vez de imprescindible. 

Como vemos, hay tecnologías de seguridad perimetral en las que se puede ir a soluciones más baratas/libres, y aunque es complicado decidir qué piezas sacrificar, cierto es que nos hemos hartado de escribir posts en SbD en los que alertamos que ante ataques dedicados y cuidadosamente preparados, es muy complicado mitigar, incluso no contando con más herramientas que la propia formación y costumbres de los usuarios. Por eso, una vez más repetimos eso de que "no hay que recortar en educación", porque no se saca nada con disponer de herramientas que fortifiquen el acceso externo a una organización, cuando la peor amenaza es tener gente poco formada en seguridad trabajando dentro de ella.

Leer más...

Escaneo remoto de puertos

Muchas veces me ha pasado, que al hacer alguna instalación de un cortafuegos o cuando he hecho alguna modificación/movimiento de reglas con cierta complejidad, me gustaría saber si, al menos desde fuera, no he dejado abierto algo que antes estaba cerrado. En general, me conecto a la máquina de casa por VPN y SSH y lanzo un nmap con un chorro de opciones a la IP objetivo, para asegurar que lo que se ve, es lo que se tiene que ver, y nada más. En mi caso, que la conexión a mi casa requiero mi propio portátil, no siempre es posible en algunos clientes.

En uno de nuestros primeros posts en SbD ya hablamos sobre un sistema de escaneo remoto de puertos, muy útil a la hora de saber "cómo se ve nuestra IP pública desde fuera". De esta manera, y vía web, podemos ver qué puntos de entrada posibles tiene un atacante, así como si tenemos algún socket escuchando hacia Internet que no debería estar ahí. El sistema que mostrábamos en este post te permitía pasar los parámetros que quisieras a NMAP, además de que permite escanear cualquier IP, y no sólo la tuya. En mi caso, que conozco unos cuantos parámetros de la sintaxis más común de nmap, no hay mayor problema, pero ¿y si el cliente hace algún cambio por su cuenta y quiere comprobar si ha dejado abierto algo de más?   

Curiosamente, mi amigo argentino Matías Katz, al que conocí en el ACK Security CON en Colombia, me comentó el otro día que había montado un servicio muy sencillo de descubrimiento de puertos vía web en su servidor https://www.matiaskatz.com/nmap. Lo estuve probando y me resultó bastante interesante, a la par que sencillo.

No deja de ser más que un frontend web, público, que permite efectuar escaneos a la IP desde la que estás navegando, con diferentes tipos de escaneo, el top de puertos más conocidos que deseemos probar… y sin tener que conocer la sintáxis de Nmap. Matías me ha prometido que añadirá más funcionalidad al escaneo, a la hora de identificar servicios mediante NSE, fingerprinting de las aplicaciones, etc…

Una alternativa más a tener en cuenta a la hora de efectuar una buena práctica de seguridad, como puede ser el escaneo externo periódico de vuestras máquinas.

Leer más...

Construyendo tu Host IPS a medida

Sí, bueno, ya sé que igual es un poco ambicioso el título, pero no sé qué nombre puede encajar mejor para el mecanismo de defensa que os voy a proponer a continuación.

Después de muchos años integrando, configurando y afinando este tipo de dispositivos en diferentes organizaciones, me dí cuenta que los IPS comerciales son capaces de detectar/bloquear un amplio porcentaje de ataques dirigidos hacia las redes internas. Sin embargo, debido a que se basan en ataques que son de "sota, caballo y rey", no resultan efectivos para detectar/bloquear aquellos eventos que para mí son una amenaza, aunque para otros puedan no serlo.

Perl es un lenguaje de programación que personalmente me encanta. Con perl eres capaz de hacer lo mismo que en lenguajes de más bajo nivel, siempre y cuando el rendimiento al milisegundo no sea tan importante, permitiéndote lograr tu cometido en pocas líneas de código, con un nivel de abstracción muy grande. Se pensó inicialmente para el tratamiento de cadenas de texto y ficheros por lo que para lo que pensamos hacer, nos viene como anillo al dedo.

Lo primero que debemos saber, es qué queremos proteger, qué servicios tenemos expuestos al exterior, o son importantes y por ello debemos prestarles nuestra máxima atención. El siguiente paso es conocer la ubicación y la estructura de los diferentes ficheros de log en los que estos servicios registran su actividad.

Utilizaremos el módulo File::Tail de Perl para hacer lo mismo que el comando tail en UNIX. Por cada línea escrita en el fichero, nuestro IPS lo monitorizará y podrá reaccionar según definamos.

Vamos allá con un ejemplo práctico. Supongamos que disponemos de un servidor QMail que requiere autenticación para SMTP. Para nosotros una amenaza ante la que reaccionar podría ser un ataque de fuerza bruta que intente averiguar un par de usuario/contraseña válida. 

El formato de una línea de una autenticación errónea es el siguiente:

Nov  8 11:51:52 s_sys@Carmen vpopmail[18129]: vchkpw-smtp: vpopmail user not found guyt@:123.123.123.123

#!/usr/bin/perl

use File::Tail; #el módulo nombrado
my $tail_file_smtp="/var/log/maillog"; #fichero donde se registra la actividad SMTP
my $puerto_destino_smtp=25; #puerto que queremos proteger

$file_maillog=File::Tail->new(name => $tail_file_smtp, maxinterval=>1); 
while (defined($linea=$file_maillog->read))  #si hay linea nueva en el fichero
        {
                if ($linea=~ m/vchkpw-smtp: vpopmail user not found/) #Si coincide con el patrón que queremos bloquear
                {
                        my @trozos=split (/:/,$linea); 
                        my $ip=$trozos[5]; #La IP atacante. En el ejemplo 123.123.123.123
                        chop ($ip) #Eliminamos el retorno de carro
                        blacklistea ($ip,$puerto_destino_smtp,"correla_smtp vpopmail user not found"); #Reaccionamos
                }
        }

En este caso, la reacción es llamar a una función que se llama blacklistea y que recibe como parámetros la IP atacante, el puerto destino, y una descripción. El contenido de la función blacklistea es bastante más complejo, con comprobaciones varias en base a  llamadas a otras cuantas funciones. Fundamentalmente lo que hace es añadir al IPTables de la máquina una regla que bloquea el acceso al puerto 25 desde la IP considerada como atacante y notificar a quien corresponda que se ha bloqueado esa IP a ese puerto por la razón especificada como "Descripción". Asimismo esa misma información queda reflejada junto con la fecha/hora en una base de datos. Hay otro proceso que cada minuto lee de esa base de datos y, si ha pasado un tiempo especificado desde que se añadió esa IP, quita la regla de bloqueo. Si alguien tiene interés en más detalle, que nos lo indique y se lo enviaré o lo publicaré en una segunda parte.

Al igual que se hace con el fichero /var/log/mailog para ese tipo de ataque, se puede proteger los accesos incorrectos a otros servicios como: FTP, POP3, HTTP, HTTPS, etc,… siendo una defensa reactiva fabricada a medida para ajustarse a nuestros servicios según nuestro criterio, ante lo que es un ataque y lo que no lo es.

Para ampliar la detección y reacción a otros servicios, lo mejor será lanzar un thread por cada uno de ellos, además de una adaptación de GeoIPS, y de una rutina de comprobación de diferentes checks de la máquina. Esto quedará de la siguiente manera en el arranque del programa principal:

#MAIN

.... 

<snip>

.... 

$thr_www = threads->new(\&correla_www); #Comprobaciones para el servidor web
$thr_vpop3s = threads->new(\&correla_vpop3s); #Para Pop3s
$thr_qmail_log = threads->new(\&correla_qmail_log); #Antispam
$thr_smtp = threads->new(\&correla_smtp); #SMTP
$thr_ftp = threads->new(\&correla_ftp); #FTP
$thr_geo_firewall = threads->new(\&geofirewall); #Adaptación propia de GeoIPS

$thr_checks=threads->new(\&do_checks); #Checks varios de carga, espacio en particiones,...

#Bucle infinito
for (;;)
{
        chequea_bloqueadas; #Función que valida si una IP en cuarentena debe ser ya desbloqueada o no
        sleep ($frecuencia_chequeo);
}

Leer más...

Sacándole el jugo a los IDS/IPS (II) - Configuración y afinamiento

En posts anteriores explicamos cómo llevar a cabo un despliegue de sondas IDS/IPS de la forma más óptima posible. Como lo prometido es deuda, en este post detallaremos cómo conviene configurar dichos elementos para que la información generada en forma de eventos de seguridad sea aprovechada por los Departamentos de Seguridad de las organizaciones.

La colección de dispositivos IPS/IDS con la que sembramos nuestra arquitectura de red anteriormente son capaces de enviar alarmas en caso de detectar/bloquear tráfico malicioso. En el momento de la configuración de dichos dispositivos (que traen una base de firmas genérica) se suele poner a registrar toda la actividad de la red durante un tiempo suficiente para obtener una muestra de suficiente calidad (generalmente una semana, aunque este tiempo puede variar). Esto se hace con el fin de evaluar los diferentes eventos detectados por las sondas IDS/IPS. A partir de aquí surgen dos posibles filosofías de afinamiento:

• La primera sugiere afinar la política de alertas de red eliminando todos los falsos positivos, y eventos de severidad baja, de manera que solamente genere alertas en caso de ataques que puedan suponer un impacto importante para la organización. Esta filosofía también es conocida como “anomaly detection”. Así los operadores que reciban las alertas deberán poner en marcha un plan de contingencia para mantener el ataque bajo control.
• La otra posible forma de configurar los IDS/IPS es afinar únicamente los falsos positivos y dejar todos los demás eventos activos, de manera que en caso de una intrusión, a la hora de realizar un análisis forense, contar con mucha más información para poder analizar los prolegómenos del ataque.
  

Ambas filosofías son muy opuestas en cuanto a la funcionalidad práctica (la segunda se hace ingestionable por recursos limitados en redes con mucha actividad), el mantenimiento y los costes de almacenamiento (a mayor verbosidad en el registro de eventos mayores necesidades de espacio en disco y mayor frecuencia de rotado de logs para poder manejar la información). Sin embargo la segunda posee como única ventaja el poder contar con un nivel de detalle excelente en casos post-mortem.

Según el ejemplo con el que contábamos en el posts anterior, teniendo mecanismos diferentes de IDS y de IPS, mi experiencia en estas lides me hace recomendar configurar los IPS de forma abnomally detection y los IDS en modo logging completo. De esta manera los IPS no tendrán que analizar una base de datos de ataques tan grande, priorizando también el rendimiento de los mismos, y los IDS guardarán datos de toda la actividad de red con un primer nivel de filtrado (por los IPS en caso de tráfico entrante/saliente).

En la siguiente entrega, aprovecharé para introducir un "juguete" nuevo en la infraestructura de seguridad de la compañía: los centralizadores/correladores de eventos.

Leer más...

Sacándole el jugo a los IDS/IPS

Conocidos como mecanismos de detección o prevención de intrusiones, los IDS/IPS se han convertido en un "must" en el SIMO de dispositivos que han de tener las organizaciones como mecanismos de seguridad en su infraestructura.

Dependerá del uso que se les vaya dando a estos dispositivos, que se conviertan en herramientas útiles que aporten valor en el proceso de la seguridad de las organizaciones, o se conviertan en unos "cacharros" más, cuyo mantenimiento engrose la lista de tareas de los administradores. Ya que todos los dispositivos que forman parte del stuff de una compañía requieren un mantenimiento (backups, actualizaciones, parches, licencias,...) por lo menos vamos a dar las pautas para que la utilización de sondas de detección/prevención de intrusiones puedan resultar útiles en su funcionalidad.

Antes que nada, quiero dejar claro que las sondas IDS son dispositivos que se posicionan offline del flujo de las redes, de manera que reciben una copia del tráfico de cada VLAN (mediante la utilización de TAPs físicos o con la creación de un port mirroring o port span de una VLAN de un switch capaz de hacerlo). Por un interfaz sin pila TCP/IP reciben el tráfico en formato RAW y lo analizan enfrentándolo contra una base de datos de firmas de ataques conocidos, de manera que, a través de otro interfaz, cuando detectan tráfico malicioso, envían señales de alarmas a una base de datos centralizada. Estos dispositivos solamente son capaces de detectar tráfico y, en ciertas ocasiones, pueden llevar a cabo reacciones activas que eviten males mayores en la infraestructura de producción. En este caso nos referimos a IDS de red, puesto que existen (o existieron hace unos cuantos años) los llamados IDS de host. Estos eran agentes software que se instalaban de forma directa en cada uno de los servidores a monitorizar y que enviaban alertas sobre ataques contra los mismos.

Los IPS sin embargo, funcionan de una forma diferente, puesto que se emplazan en modo inline entre las diferentes redes, de modo que el tráfico que pasa hacia y desde una red los ha de atravesar, pudiendo discriminar si el tráfico es malicioso o no. Al encontrarse en modo transparente e inline, este tipo de dispositivo sí que es capaz de bloquear todo tipo de tráfico que se considere un ataque. En líneas generales (aunque los IPS han evolucionado mucho), el funcionamiento principal de los IPS a la hora de identificar ataques es idéntico al de los IDS. Se basan en firmas de ataques conocidos y envían por un tercer interfaz las alertas a una base de datos centralizada.

Como diferencias principales entre ambos, aparte de las ya comentadas referidas a la capacidad de detectar únicamente o de bloquear los ataques, es la cantidad de tráfico a monitorizar por parte de ambos. En el caso de los IPS, sólo son capaces de identificar ataques dentro del tráfico que los atraviesa en ambos sentidos. Sin embargo, los IDS de red van más allá, puesto que al analizar el tráfico de una VLAN completa, es capaz de clasificar ataques entre máquinas de la VLAN, no sólo la que pasa de una red a otra.

Inicialmente, todo despliegue de una plataforma de sondas IDS/IPS, cómo si del apostamiento de francotiradores se hablase, requiere planificar con cierta inteligencia.

Como tónica habitual en la gestión de proyectos de este tipo lo que manda principalmente es el presupuesto asignado para invertir en el análisis de la seguridad de las redes.

Suponiendo que disponemos de algo de presupuesto para equipos con licencias comerciales, mi recomendación sería diversificar entre software comercial y software libre. Si bien como iniciativas libres disponemos del ultraconocido Snort (que puede funcionar como IDS y como IPS inline). Como soluciones comerciales más recomendables podemos contar con ISS (adquirida por IBM), Tipping Point (adquirida por 3Com), McAfee Intrushield (solución IPS basada en ASIC), Sourcefire (spin-off comercial de Snort que se integra sobre máquinas Nokia, aparte de sus propios appliances),...

No obstante, y dependiendo en mayor medida de si se tiene proyectado efectuar cambios en la estructura de cortafuegos de red principales, existen los llamados UTMs (Unified Threat Management) o MFA (Multi Functional Appliances) que son en realidad cajas que aunan las funcionalidades de cortafuegos de red, gestor de túneles VPN, antivirus, proxy, gestor de contenidos e IDS/IPS (dependiendo si solo registran las alarmas detectadas o si bloquean los ataques), entre otros... por lo que no es nada desechable la idea de implantar como pilar central de la seguridad un dispositivo de estas características que sea capaz de detectar y bloquear los ataques que lo atraviesen en dirección desde/hasta cualquiera de las redes que delimitan. Por poner ejemplos de fabricantes de dispositivos comerciales UTM, podríamos indicar: Fortinet, Juniper, NetASQ, Checkpoint, Radware,... De esta manera es posible evitar la inclusión de dispositivos IPS puros en los segmentos más importantes de la red. Huelga decir que si tenemos presupuesto ilimitado para llevarlo a cabo, lo más recomendable es situar elementos de diferentes fabricantes por lo que utilizar uno o varios UTM con la función de IPS activa para separar diferentes redes, y además la inclusión de IPS puros en los segmentos de red que necesitemos.

Supongamos que no contaremos con un dispositivo de estas características como eje central distribuidor de las redes principales de nuestra organización. Lo más normal en estos casos es dimensionar la cantidad de sondas a desplegar en caso de los IDS. Si contamos con instalar Snort como IDS (opción recomendada por ser gratuito y de gran calidad), de manera que podemos darnos el lujo de tener una sonda por cada red que posea la organización. En caso de tener limitación en el número de sondas por el coste del hardware, habremos de priorizar sobre las redes en las que tengamos elementos más críticos para nuestro negocio. Se suelen seguir criterios como "la red con más servicios expuestos a Internet" o "la red donde más información confidencial haya".

En cuanto al despliegue de IPS, supongamos que hemos destinado el grueso del presupuesto del proyecto a comprar equipos comerciales IPS. Lo más recomendable es situar un dispositivo (o clústers en alta disponibilidad si el presupuesto lo permite) justo en el punto de acceso a la red (puede ser en la salida/entrada de cada interfaz del firewall que delimita esa red).

Con esta disposición lograremos tener monitorizado el tráfico que entra a cada una de las redes que separa el firewall principal (y bloquearlo con los UTM o los IPS) y el tráfico que se intercambian las máquinas de cada red entre ellas (mediante el análisis del tráfico interno entre máquinas de un mismo segmento), pudiendo detectar actividad vírica que pudiera dejar fuera de combate una VLAN completa.

En posteriores entregas intentaré detallar lo mejor posible cómo configurar los diferentes elementos de seguridad que hemos incluido en nuestra arquitectura de red.

Leer más...