Mi5terio resuelto

Día típico de otoño, por la ventana solo se aprecia un cielo gris. Es el típico día en el que crees que no va a suceder nada extraño. De repente nuestro sistema de vigilancia alerta de unas conexiones anómalas: un equipo ha intentado conectarse contra unas direcciones IP de origen desconocido. Estas direcciones IP son públicas y, según la configuración establecida en la organización, toda conexión HTTP hacia el exterior debe pasar a través de un proxy.

Las conexiones se buscan en los registros del proxy y no se encuentran, por lo tanto este equipo ha intentado conectarse directamente, haciendo caso omiso a la configuración del sistema. [Read more…]

Plantillas con malas intenciones

Hace unos días analizando varios correos di con uno que contenía un adjunto sospechoso. Era un documento .docx que a simple vista no tenia nada dentro pero ocupaba 10 kb.

El correo había pasado todas las barreras, tanto SPF, como los dos antivirus que tienen las pasarelas, y también el filtro anti spam.

El fichero .docx se puede tratar como un comprimido. Una vez extraído su contenido, me puse a analizar todos los ficheros del directorio en busca de dominios o direcciones IP que se pudiesen ver en claro:

Y logré encontrar algo interesante dentro de la ruta word/_rels/document.xml.rels donde aparece lo siguiente:
[Read more…]

Volvamos al Collins

En la actualidad, el tráfico http cada vez es menos visible para un analista de seguridad ya que ahora, en muchos casos, los servidores web obligan a usar https y por lo tanto, dejamos de tener mucha visibilidad.

En este aspecto, algunas organizaciones optan, o bien por «romper” el tráfico ssl gracias al uso de un certificado impuesto, o bien solo permiten acceso https para algunos servicios determinados. Algunos de estos servicios, como es el caso de Google, suelen estar permitidos.

Hablemos entonces, por ejemplo, del traductor de Google. Se me ocurrió la idea de hacer bypass a las conexiones a través de un traductor, en este caso de Google. [Read more…]

¿Sueñan los analistas con Exploit Kits?

img0Muchas de las web que se visitan a diario están comprometidas, y el usuario corriente navega por ellas sin tener conocimiento alguno del peligro que supone no tener el navegador o la versión de Adobe Flash  actualizada. A continuación vamos a ver un análisis de este tipo de compromisos que por desgracia, cada día es más habitual.

En el análisis de tráfico HTTP se pueden usar herramientas como Burp o  Fiddler.

En este ejemplo he usado Fiddler y en navegador Iceweasel con un plugin para simular distintos User Agent (Switch  user agent), para en momentos determinados emular Internet Explorer.

Si se quiere instalar Fiddler bajo Linux con mono, se puede seguir este manual:

http://fiddler.wikidot.com/mono

[Read more…]

Cita a ciegas con Darkleech


al0(Los dominios y nombres de usuario que se describen en este post son ficticios, con el fin de proteger la identidad de los reales)

Una de las tareas habituales a la hora de buscar posibles infecciones es analizar el trafico de navegación web (proxy) en busca de contactos con dominios de carácter dinámico (dyndns, no-ip.org, etc…).

En una de estas búsquedas se ve el contacto con un dominio dinámico sospechoso desde la página www.hospitales.com:

2015-08-09 10:53:40 191.226.176.112 Pgarcia - "none" http://www.hospitaless.com/en/index.php  0 - GET http yyuewv.hopto.org 80 /wordpress/ 633 409

El dominio está inactivo, pero queremos analizar las peticiones que se hacen al visitar esta web. Para ello, uso un analizador como Burp:

al1

[Read more…]

BRO IDS: “el ojo que todo lo ve…”

broidsBRO es una herramienta open-source para el análisis de tráfico de red cuyo objetivo es reconocer actividades sospechosas.

El análisis de red reporta varios tipos de registros divididos según el protocolo y características como puede ser HTTP, DNS, SSL, FTP, sesiones IRC, SMTP, etc.

Para la captura de paquetes utiliza libpcap. Es capaz de analizar y detectar túneles (incluyendo Ayiya, Teredo, GTPv1) además de desencapsularlos para luego analizar su contenido.

Arquitectura

Se basa en dos componentes:

  1. Motor de eventos (event engine): Reduce el flujo de paquetes, organizándolos para ser llevados a un nivel superior.
  2. Interprete de Scripts (policy script interpreter): acciones a tomar cuando se detecta una actividad determinada.

[Read more…]

PFsense: firewall perimetral (VI)

En este último capítulo sobre Pfsense (ver I, II, III, IV y V) se explica la configuración de un servidor proxy como Squid en modo transparente para no tener que configurar todos los equipos de la red.

La tarea de este proxy será registrar todas las conexiones HTTP, hacer estadísticas de navegación y denegar ciertos dominios.

El primer paso es instalar estos 3 paquetes: Squid, SquidGuard y Ligthsquid.

[Read more…]

PFsense: firewall perimetral (V)

En este quinto capítulo sobre Pfsense (ver I, II, III y IV) se explicará la instalación y configuración de Snort, con el fin de incluir un NIDS en nuestro firewall.

Para instalar Snort en system > packages


Una vez instalado, en services > snort, se procede a su configuración:

-= Pestaña iface settings =-

Es donde se elige el lugar en el que Snort va a esnifar. wlan0 en caso de querer que actúe entre internet y la entrada del firewall, o ya si se quiere algo mas interno seria en opt1 para la DMZ o LAN para la red interna. En este caso para ver todo el tráfico hacia Internet lo mejor es elegir wlan0.

Respecto a la variable home_net y external_net se pueden dejar por defecto ya que home_net englobará a todas las direcciones IP internas y external_net a todas las que sean diferentes de home_net.

-= Pestaña WAN barnyard2 =-

Barnyard2 permite procesar los log de Snort e insertarlos en una base de datos externa:

En el apartado “MYSQL Database Output settings” es donde se configura el servidor MySQL externo, donde barnyard2 insertará los Log de Snort. Previamente en este servidor externo se debe crear la base de datos snort y dar permisos al usuario snort y a la dirección IP de Pfsense (192.168.1.2) para que pueda acceder a la bbdd:

mysql -u root -p

CREATE DATABASE  snort;

grant INSERT,SELECT,UPDATE,CREATE,DELETE,EXECUTE on snort.* to snort@192.168.1.2
Set password for snort@192.168.1.2=PASSWORD('snortpass');
flush privileges;

y posteriormente crear el esquema de esta base de datos (se puede descargar desde aquí):

mysql -D snort -u root -p < ./schemas/create_mysql

-= Pestaña Global Settings =-

Las reglas de detección del IDS tienen un papel importante y en este apartado es donde se configuran. Para incluir las reglas VRT se debe incluir un código, que se consigue al registrarse en la web de Snort.

Al registrarse envían un correo con el enlace para entrar logeado en la web de snort.org, luego en nuestro perfil conseguimos el oinkcode.

-= Pestaña updates =-

Por último en la pestaña updates se procede a la descarga de las reglas:


-= Pestaña Suppress =-

Al igual que en el fichero threshold.conf de Snort, es aquí donde se puede limitar las alertas, por origen, destino,o por el numero de coincidencias en un determinado tiempo. Veamos un ejemplo:

Se tiene primero que buscar el sig_id (identificador único de cada regla), para poder limitar las alertas (para el ejemplo “1852”):

  • No alertar cuando el origen sea 192.168.3.0/24.
  • No alertar cuando el destino sea 192.168.1.10 y 192.168.1.11:
    suppress gen_id 1, sig_id 1852, track by_src, ip [192.168.3.0/24] 
    suppress gen_id 1, sig_id 1852, track by_dst, ip [192.168.1.10,192.168.1.11]
  • Suprimir directamente toda la regla:
    suppress gen_id 1, sig_id 1852
  • Solo alertar de una de las alertas de la firma cada 3600 segundos:
    event_filter gen_id 1, sig_id 1852, type limit, track by_src,  count 1, seconds 3600
  • Suprimir cualquier regla para un origen concreto:
    suppress gen_id 1, sig_id 0, track by_src, ip [192.168.1.1]

Para mas información sobre las configuraciones, se puede visitar el siguiente link.

-= Pestaña Pass list y Blocked =-

En el caso de que Snort también funcione como IPS, es decir no solo alerte, sino que pueda bloquear, en estas dos pestañas se elige qué direcciones están exentas de bloqueo o cuáles bloquear. Por defecto las direcciones WAN, los gateway, servidores DNS, VPN, etc. están en la lista de no bloqueo.

Dentro de Services > snort > snort interfaces se edita (botón a la derecha con la letra “e”) en la pestaña WAN Categories:

Se pueden escoger qué reglas usar como se muestra en la imagen.

En la siguiente y última entrada de la serie sobre Pfsense veremos el tema de Squid como proxy HTTP. Espero que os haya parecido interesante.

pfSense: firewall perimetral (IV)

Volvemos a la carga con la cuarta parte de nuestra serie sobre pfSense. En el anterior capítulo explicamos cómo configurar las opciones avanzadas del sistema (ver también la primera entrada y la segunda, para los despistados). En esta cuarta parte vamos a explicar cómo configurar “el corazón del firewall”, es decir las reglas de pfSense.

Lo primero, para facilitar la creación de reglas, es importante saber lo que son los “alias” y qué posibilidades brindan. Vamos a la pestaña superior, Firewall → Aliases.

Dentro podemos crear diversos alias como Hosts, subredes, puertos y URLs. Este es un ejemplo de creación de alias para los servidores que pertenecen a la red DMZ:

Así es como se vería un resumen de todos los Alias creados:

Ahora se trata de usar estos alias para configurar las reglas en el apartado Firewall → Rules. Lo más importante que debemos tener en cuenta al crear una regla es que prevalece la prioridad de la regla que se sitúa por encima de otra regla.

En nuestro ejemplo (y en general, en cualquier entorno en producción) la red DMZ no debe tener acceso a la red interna, ya que la DMZ es la que albergará los servidores que están expuestos a Internet y esta red no debe tener ningún tipo de comunicación hacia la red interna. Por otro lado, sí que nos interesa que se puedan gestionar los servidores desde la red interna hacia la DMZ, por lo que podemos crear una regla que permita el trafico por el puerto 22 (SSH) desde la red interna hacia la DMZ.

En el apartado Rules, la interfaz que pertenece a DMZ es “OPT1”, desde allí, existe un botón con el símbolo “+” para añadir reglas. Por tanto, creamos una regla que deniegue el acceso desde la DMZ a red interna, donde en “Destination” usamos el alias “Subnet_lan” creado anteriormente.

Exactamente de la misma forma pero desde la interfaz LAN (red interna) crearemos una regla que deniegue todo el tráfico desde red interna (LAN) a la subred DMZ (más adelante se superpondrán reglas que prevalezcan sobre esta). A continuación, creamos una regla por encima de la anterior que permita la comunicación SSH desde red interna (LAN) hasta los servidores en DMZ:

Ahora en las reglas del firewall de la interfaz LAN (nótese que el deny de DMZ hacia LAN está en el interfaz OPT1, por eso no se muestra) se vera así:

En la regla de más arriba (la más prioritaria) están permitidos dos puertos 10443 y 10022, que son los que se usan para administrar PFsense por HTTPS y SSH. Esta regla se crea por defecto y es importante que exista ya que en caso contrario, se estaría denegando el acceso al propio firewall.

El siguiente paso es configurar NAT (Network Address Traslation). Para ello en la sección NAT en Port Forwarding, configuraremos que nos permitan acceder al servidor web y al servidor FTP desde internet a estos dos equipos situados en la DMZ. En el caso del HTTP sería como se muestra en la imagen.

Tras aplicar ambas reglas, tendríamos una situación como la siguiente:

Es importante saber que al crear esta regla en NAT automáticamente se crean las reglas del firewall asociadas, de forma que se pueda hacer efectivo el acceso desde fuera hacia dentro. Por tanto, así quedarían las reglas del firewall en la interfaz WAN ahora:

Con estos ejemplos básicos ya podemos comenzar a «trastear» con pfSense y un mayor número de reglas. En el siguiente artículo veremos la implementación de herramientas como un IDS (Snort) o un proxy (Squid), dentro de pfSense.

PFsense: firewall perimetral (III)

En esta tercera parte de la serie sobre el firewall perimetral PFSense vamos a ver las configuraciones avanzadas del sistema. Para nos que no han seguido la serie, aquí tienen la primera entrada y la segunda.

La manera más habitual de acceder a estas configuraciones es a través del navegador. Es importante que al acceder al navegador lo hagamos de manera segura (por https), para ello ya existe un certificado creado por defecto en nuestro pfsense, pero es recomendable que nos creemos uno nosotros, para ello se accede al siguiente bloque:

   system –> cert manage

En esta pestaña CAs crearemos primero la CA, llamada “my_cert

Ahora con esta CA podemos crear un certificado llamado “mycert”, en la pestaña Certificates:

Con el certificado ya creado, lo podemos usar en las configuraciones de acceso de administrador:

   system -> advanced -> admin access

En la sección web configurator elegimos protocolo https, mi certificado (“mycert”) y un puerto diferente al 443, por ejemplo 10443.

  • Max processes pondremos un valor de 1, ya que solo queremos que a la configuración vía https acceda una sola persona a la vez.
  • WebGUI redirect debe estar marcado para deshabilitar la escucha por el puerto 80, a la vez que escucha por el 10443, ya que solo se quiere acceso exclusivo por https.
  • WebGUI Login Autocomplete se selecciona para deshabilitar el autocompletado por parte del navegador ya que es preferible que éste no guarde las credenciales por seguridad.

Las demás opciones se dejan por defecto.

Ahora una vez guardados los cambios ya se puede acceder al navegador con la URL https://192.168.1.2:10443/

Sección secure shell

Activamos el acceso por ssh a través del puerto 10022

Sección Serial communications y console options

En Console menú seleccionamos la opción de que pida password al acceder a la consola y configuración desde el equipo local (serán las mismas credenciales que usamos para acceder con el navegador). Para configurar las opciones del Firewall y NAT accedemos al siguiente bloque:

   system -> advanced -> Firewall NAT

Sección Firewall Advanced

Existen 4 tipos de optimización:

  • Normal: optimización equilibrada.
  • Alta latencia: para conexiones lentas, como las satelitales.
  • Agresiva: las conexiones inactivas expiran más rápido, mayor eficiencia en el uso de CPU.
  • Conservativa: más uso de CPU con el fin de alargar una conexión inactiva.

También se pueden configurar el tamaño de las tablas del sistema:

  • Firewall Maximum States: número máximo de conexiones en la tabla del firewall. Digamos que es como un netstat de la propia máquina, por defecto el tamaño máximo es de 10000 estados. En este caso ya depende mucho del entorno donde se va a usar, si es algo casero lo ponemos a 4000 para optimizar.
  • Firewall Maximum Tables: máximo número de tablas posibles (en pfsense se usan tablas, para crear alias, snort, reglas del firewall…). Por defecto el valor es de 3000 tablas, pero para optimizar, se puede poner 500, ya que no llegaremos a muchas más.
  • Firewall Maximum Table Entries. Por defecto viene con 20000 y lo ponemos a 10000. Es el número de entradas por cada tabla que antes hemos comentado.

Las demás opciones definen el comportamiento multiwan o la generación de auto reglas de filtrado del firewall a la hora de configurar una VPN o red privada virtual.

De momento se dejan las demás opciones por defecto.

En la sección NAT, también se puede agregar la generación automática para la traducción de direcciones de red de forma automática, según las reglas creadas en el firewall, pero se recomienda hacer después de forma manual.

En el bloque system -> advanced -> networking no tocamos nada, a no ser que exista incompatibilidad con alguna interfaz de red.

En el bloque system -> advanced -> miscellaneous es donde podemos configurar la conexión de nuestro pfsense con un proxy, el balanceo de carga, sensores de temperatura y cómo actuar según ésta, ahorros de energía, disminuyendo usos de CPU, opciones IPsec, así como usar parte de la memoria física para emularse como memoria RAM. Estas opciones no son demasiado importantes así que no se detallarán.

En el bloque system -> advanced -> notifications podemos hacer que las notificaciones nos lleguen por correo, via SMTP.

Hasta aquí se explican las opciones avanzadas del sistema. El próximo articulo estará relacionado con la creación de reglas de filtrado del firewall pfsense.