Blog de Seguridad de la Información de S2 Grupo
La semana pasada estuvimos viendo LightSquid y SquidAnalyzer como herramientas de análisis de logs para Squid. Una tercera herramienta interesante es:
Esta aplicación se encuentra implantada en multitud de organizaciones y al igual que SquidAnalyzer se encuentra actualmente en desarrollo. Como punto fuerte, podemos señalar la velocidad de procesamiento, gracias a que se trata de una aplicación compilada.
La necesidad de colaboración para atajar las amenazas de seguridad de la información es una obviedad de la cual tanto organismos públicos como empresas privadas se están dando cuenta y están tomando cartas en el asunto. Esta semana ha saltado la noticia sobre una red colaborativa nacida de las manos de Facebook cuyo objetivo es el de compartir fácilmente información de amenazas informáticas entre organizaciones, y aprender de los descubrimientos de otros con el fin de hacer los sistemas más seguros. Así lo define Mark Hammel, Responsable de ThreatExchange.
A esta iniciativa de Facebook se unieron en primer lugar Pinterest, Tumblr (cuyo propietario es Yahoo!), Twitter y Yahoo!. Posteriormente se han sumado empresas como Bitly y Dropbox. Los promotores de esta iniciativa pretenden que se unan más empresas y expertos en seguridad para compartir de forma ágil la información sobre las amenazas a las que todos estamos expuestos en la red.
En primer lugar lo que solicitan para el registro es el nombre y una dirección de correo corporativa, imagino para posteriormente establecer un acuerdo con cada uno de las organizaciones adheridas. Resulta importante saber qué se puede hacer con esa información y qué medidas de seguridad hay implantadas para garantizar que el uso que se haga de esa información sea legítimo. Por lo que he podido comprobar, no aparecen las condiciones de la plataforma aunque aseguran que hay implantados controles de privacidad para que cada participante pueda compartir la información solo con el grupo o grupos que desee. Pero no puedo evitar preguntarme… ¿quién será el responsable de la información compartida? ¿Qué uso se podrá hacer de la misma? ¿Realmente van a compartir estas grandes empresas las amenazas que pueden vulnerar o han podido vulnerar sus sistemas?
Desde luego considero que es un avance esta conciencia de seguridad y que las grandes empresas colaboren por la seguridad de las organizaciones y de los propios ciudadanos pero, sin querer ser desconfiado, me llama la atención que esta iniciativa salga de Facebook. Sin lugar a dudas, es una empresa con unos números impresionantes, más de 1.350 millones de usuarios activos, pero la cual también ha sido noticia en otras ocasiones por su política de privacidad y el uso que hace de los datos personales de sus usuarios. No seré yo el que reniegue de este paso que han dado con el ThreatExchange pero estoy expectante para ver si organismos públicos o CERTs respaldan y colaboran con esta iniciativa.
Esta última semana también se ha publicado una noticia de que el gobierno de Estados Unidos ha dado un paso más en la lucha antiterrorista en la red. Ha creado una agencia cuyo objetivo es conectar las acciones de las diferentes agencias federales que actualmente se ocupan de la ciberseguridad. La agencia se llama Cyber Threat Intelligence Integration Center (CTIIC) [2]. Un movimiento más de los que vienen dando los estados en este sentido, que desde luego demuestran la importancia de la seguridad en Internet y van dando pasos en esta dirección.
Veremos cómo evoluciona la iniciativa ThreatExchange y los efectos que ésta tiene. Sinceramente ojalá tenga éxito y el verdadero objetivo sea mejorar entre todos la seguridad.
La doble autenticación es uno de esos mecanismos de protección muy familiares para la gente relacionada con ciberseguridad pero que, sin embargo, es una gran desconocida para el gran público. Este artículo pretende llegar a ese sector, cuyas cuentas de usuario son cada vez más interesantes para posibles atacantes. En futuras entradas ya me meteré más en harina y veremos aspectos más interesantes.
Para acceder a cualquier servicio es necesario que el usuario se identifique, proporcionando un identificador único en el dominio, como por ejemplo un nombre de usuario (o nickname), dirección de correo electrónico, documento nacional de identidad, número de seguridad social, etc. Esta información identifica al usuario, pero no lo autentifica, puesto que esta información no es secreta y cualquiera podría saberla.
Al identificador de usuario le debe acompañar algo más para que el sistema confíe en él y le permita el acceso. Hay tres factores de autenticación:
Los métodos tradicionales de autenticación, familiares ya para todos, se basan en el uso de un identificador único de usuario acompañado de una contraseña que solo el usuario conoce. Pero, ¿qué pasa cuando la contraseña es interceptada o robada por otro usuario? Nadie quiere comprobarlo en primera persona.
El doble factor de autenticación, conocido también como 2FA o TFA, se basa en el uso conjunto de dos de los factores anteriormente mencionados; el ejemplo más usado es la generación de claves basadas en tiempo, donde el usuario debe introducir su password seguido de una clave temporal. Ésta es de un solo uso, tiene una validez de pocos segundos y es generada generalmente en el teléfono móvil, el cual ha sido previamente configurado con una semilla para generación de claves. En este caso un atacante podría interceptar la clave del usuario y el código temporal, pero ésta última, al tratarse de una clave temporal de un sólo uso no le resultaría útil. El atacante necesitaría la semilla con la que se generan las claves temporales, pero ésta no circula por la red, por lo que un man-in-the-middle resulta inútil.
Otras veces la clave temporal se genera en el servidor y se le envía al usuario en un mensaje SMS al teléfono movil, o por correo electrónico.
Si piensas que las claves temporales no son algo práctico ahora también es posible comprar llaves de seguridad en Internet. Se trata de llaves USB que contienen un certificado, y que tienes que insertar en un puerto de usb en el momento de introducir tu password.
A pesar de todo, la doble autenticación no es infalible, y como suele ser habitual el eslabón más débil suele ser el usuario, aunque este tipo de soluciones se lo ponen técnicamente muy difícil a los posibles atacantes. Kevin Mitnick cuenta en su libro “Ghost in the wires” como engañó a un operador de red de una importante multinacional para saltarse esta protección, haciéndose pasar por un empleado que no encontraba su tarjeta de claves.
A estas alturas puede que ya te haya convencido para usar el doble factor de autenticación, y te estés haciendo la pregunta: ¿dónde lo puedo usar?
Por suerte cada vez más servicios ofrecen esta posibilidad, aunque por el momento no todos. Algunos ejemplos son Google, Dropbox, Facebook, PayPal, eBay y Twitter. En https://twofactorauth.org/ puedes consultar una tabla de servicios y, en caso de ofrecer la posibilidad del doble factor de autenticación, los mecanismos que ofrecen.
Para hacer un resumen, la doble autenticación:
Entonces es cuando les puedes soltar este rollo que acabas de leer, o incluso escribir un artículo. Hasta el próximo post :)
Uno de los elementos principales a la hora de gestionar el tráfico de una red es mediante la implantación de un proxy. De manera muy simple podemos considerarlo como un sistema que hará de “intermediario” entre clientes y servidores. Es decir, el cliente no accederá directamente a Internet, sino que a la hora de visitar un sitio web, realizará una petición al proxy y será éste el que navegue hacia el sitio web y le reenvíe la respuesta al cliente.
Tener implantado un proxy implica que todo el tráfico de los clientes que accedan a Internet, pasará a través de él y (por tanto) estará siendo monitorizado. Podemos pensar que la implantación de un proxy en una organización tiene como objeto llevar un control de la navegación de los usuarios, y aunque en parte puede ser cierto (lo que tiene sus implicaciones legales que no vamos a tratar aquí), también hay que decir que mediante una configuración adecuada de éste se puede evitar que los empleados accedan a sitios no permitidos, ya sea porque no sean recursos necesarios para el desempeño correcto de su trabajo o porque conlleven un peligro para la seguridad de la infraestructura de la organización.
Debemos recordar que con el simple hecho de acceder a un sitio web, si éste está contaminado y alberga un kit de exploits para diferentes navegadores y versiones, el cliente puede quedar automáticamente infectado en el caso de que su navegador o alguno de sus plugins posea alguna vulnerabilidad no parcheada. Lo que, como todos sabemos, es más frecuente de lo deseable.
Entremos en materia. Imaginemos que hace unos días, a partir de una revisión rutinaria del log del proxy, se detectó que varios empleados de la empresa estaban haciendo un consumo de decenas de gigabytes diarios cada uno. Lógicamente, esta revisión no se hace de manera manual y para ello existen diferentes alternativas que podremos usar para tener la información del proxy categorizada y ordenada. En este y el siguiente post veremos tres aplicaciones de análisis de logs para squid. Para llevar a cabo las pruebas se ha utilizado Kali sobre la que se han desplegado las aplicaciones. El objeto de este post no es detallar el proceso de instalación por lo que este paso queda como ejercicio para el lector (ejercicio sencillo, en cualquier caso).
LightSquid se trata de un conjunto de cgi y scripts en perl que se despliegan en el servidor web, y aunque a priori no ofrezca una interfaz muy moderna ni elegante, se trata de un buen aliado por rapidez y sencillez.
Si accedemos al día en particular nos aparecerá un listado con los usuarios.
Una funcionalidad interesante de lightsquid es que muestra una tabla con las horas de navegación de cada usuario.
La aplicación también mantiene listados de sitios navegados por mayor número de usuarios, ficheros de mayor tamaño descargado, así como listados de usuarios que han visitado determinado sitio. Lamentablemente es una aplicación sin desarrollo actualmente.
SquidAnalyzer es otro analizador de logs de squid hecho en perl, con mayores funcionalidades que el anterior y con una interfaz más elegante y cuidada (que vale, eso tampoco es muy difícil). Una vez seleccionado el periodo, nos aparecerá una pantalla resumen de la actividad durante el mismo.
En la parte superior, tendremos un menú en el que se nos mostrarán estadísticas de usuarios, URLs, dominios, recursos (agrupados por mimetype).
Una de las características más interesantes de este analizador es que es capaz de agrupar las peticiones por segmento de red, con lo que obtendremos un punto más de granularidad a la hora de hacer estadísticas de uso.
Accediendo a través de las subredes, obtendremos un listado de actividad de usuarios, tiempos de navegación, peticiones realizadas…
Una vez seleccionado el usuario, nos mostrará en detalle la actividad del mismo.
Aparte, podemos obtener estadísticas de tipo de ficheros mas descargados.
Por último podremos tener una vista general de sitios web con mayor actividad.
En la próxima entrada veremos SARG (Squid Analysis Report Generator) y analizaremos cómo encaja todo esto con el mundo de la seguridad.
En esta entrada vamos a ver de una manera muy rápida como hacer un análisis de un fichero OLE y analizar los streams que contenga (en este caso se trata de una macro) con la herramienta y reglas de Didier Stevens. El documento no es muy complejo pero nos sirve para ilustrar cómo utilizar esta herramienta.
Hash del fichero cazado en un correo:
e4e46f746fffa613087bba14666a3ceec47e145f Transferencia_Interbancaria.doc
Paso 1: Lanzamos yara con nuestra reglas:
Hace unos meses, llegó a España la aplicación Secret, tanto para Android como para iOS. Y eso ¿de qué va? Para quien no la conozca, las bases de esta aplicación son muy sencillas: puedes publicar mensajes cortos (similar a Twitter) con la peculiaridad de que nadie sabrá que los has escrito tú. Y claro, tampoco sabrás quién escribe las cosas que lees.
Una vez que has incorporado un cierto número de amigos (usando los contactos de tu móvil y tus amigos de redes sociales), podrás ver si las publicaciones que lees son de un amigo o del amigo de un amigo. Con eso se protege el anonimato de tus amigos (si sólo tienes 5 y lees una publicación de uno de ellos, es probable que adivines de quién se trata). También puedes ver las publicaciones de desconocidos sabiendo únicamente su localización.
Contado así no suena mal ¿no? De hecho, en las preguntas frecuentes de la propia aplicación ensalzan que el anonimato que ofrecen permite que la gente se muestre tal y como es y exprese sus verdaderos pensamientos. Incluso dan unas pequeñas indicaciones a sus usuarios para que se sientan libres de expresar lo que piensan, siempre respetando a los demás. Todo muy idílico.
Un flujo de datos alternativo (ADS – Alternate Data Stream) es una característica del sistema de ficheros NTFS que consiste en incluir metainformación en un fichero. Podríamos decir que son ficheros secundarios “ocultos” guardados dentro de otros ficheros. El objetivo inicial es almacenar información extra acerca del fichero principal, pero esta técnica también fue muy usada para propagar virus de forma transparente para el usuario.
Aclarar que en este artículo me voy a centrar sólo en el sistema de ficheros NTFS sobre Windows 8 en concreto. En otros sistemas de ficheros existen técnicas similares; el símil con sistemas de ficheros como ext3, ext4, JFS, HFS+, etc., serían los atributos extendidos (EAs – Extended Attributes). La limitación de los EAs es que no se puede incluir una imagen o un archivo ejecutable como sí puede almacenarse en los ADS. Pero como he comentado, en este artículo sólo nos centraremos en NTFS y los ADS.
Hay que tener en cuenta algunas consideraciones de los flujos de datos alternativos:
La finalidad de los flujos de datos alternativos es asociar ficheros o información que pueda ser confidencial, a ficheros de forma que queden ocultos a usuarios. Pero de la misma forma se puede usar esta técnica para alguna actividad maliciosa.
Como particularidad, mencionar que cuando descargamos un fichero de Internet, lleva asociado un flujo alternativo llamado “Zone.Identifier”, que indica la zona desde donde se ha descargado el fichero. Windows después utiliza dicho valor para abrir o ejecutar los ficheros. El significado de los valores es:
Después de la introducción, vamos a ver un ejemplo de cómo crear y ver el contenido de un flujo de datos alternativo. Para el ejemplo vamos a tomar dos ficheros:
Ejecutamos dir para el contenido de la carpeta. Importante, fijaos en los tamaños de los ficheros:
Creamos ahora el flujo de datos alternativo, el comando sería el siguiente:
type img_oculta.jpg > principal.pdf:img_oculta.jpg
¿Qué ocurre si volvemos a hacer un dir? Aparentemente nada ha cambiado…
Se puede observar que el tamaño del fichero principal.pdf no ha cambiado absolutamente nada. Ejecutemos ahora el comando dir /r:
Como se ve en la imagen, el fichero principal.pdf tiene un flujo alternativo identificado como :img_oculta.jpg. Este flujo de datos alternativo coincide en tamaño con el original img_oculta.jpg, de hecho éste se podría eliminar, pero el flujo de datos alternativo seguiría existiendo. También, como ya hemos comentado antes, el tamaño del fichero principal.pdf tampoco se ha alterado.
Para abrir el contenido del flujo de datos alternativo utilizaríamos el comando:
Nombre_de_la_aplicacion fichero.extension:alternativo.extension
En nuestro caso vamos a abrir la imagen oculta con el editor de imágenes de Windows Paint:
mspaint principal.pdf:img_oculta.jpg
En sistemas operativos antiguos como Windows XP, la ejecución de un flujo de datos alternativo se hacía mediante el comando start, pero a partir de Windows 7 esto no está permitido, por lo que se cambió a invocar directamente la aplicación para abrir el fichero.
Supongo que ya os habréis hecho la pregunta: ¿qué ocurre si añado un “.exe” como flujo alternativo? En este caso, nos encontramos con que a partir de Windows 7 no está permitido (por motivos de seguridad) ejecutar un “.exe” como flujo alternativo. Veamos un ejemplo.
Vamos a asociar a un fichero llamado principal.txt la calculadora de Windows:
type c:\Windows\System32\calc.exe > principal.txt:calc.exe
Ahora ejecutamos mediante el comando start:
start .\principal.txt:calc.exe
Y el resultado es un mensaje de error que dice “Windows no puede encontrar el archivo”. Tal y como esperábamos, no podemos ejecutar un fichero “.exe” en un flujo de datos alternativo. Pero como esperábamos, eso no es del todo cierto. Para saltarnos esta medida vamos a crear un script en Python, y mediante este script llamaremos al ejecutable. Por cambiar un poco del típico ejemplo, he decidido iniciar una instancia Google Chrome.
Creamos un fichero llamado script_py.txt con el siguiente contenido:
#!/usr/bin/env python
# -*- coding: utf-8 -*-
import sys, string, os
os.system('"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"')
Ahora asociamos el fichero como flujo de datos alternativo de un fichero de texto llamado principal.txt.
type script_py.txt > principal.txt:script_py.txt
Para ejecutar el script de Python lo haremos mediante la sentencia:
C:\Python27\python.exe principal.txt:script_py.txt
Si todo ha ido bien, con esto lograremos ejecutar un fichero “.exe” a partir de un flujo alternativo. En este caso, se abrirá una nueva instancia del navegador Google Chrome.
Esta técnica era muy utilizada por atacantes para insertar malware en flujos alternativos. Aunque hemos visto que en los sistemas operativos actuales no se puede hacer directamente, sí se puede de forma indirecta, por lo que sigue siendo un aspecto a tener en cuenta para garantizar la seguridad.
Aunque no se ha visto en el artículo, existen herramientas para ver los flujos de datos alternativos en modo gráfico. Una herramienta es AlternateStreamView de Nirsoft, la cual te permite escanear carpetas en busca de ficheros alternativos.
Sin lugar a dudas, hay que tener en cuenta los flujos de datos alternativos para garantizar la seguridad de los sistemas, y no ejecutar código malicioso que permanezca oculto. Además, este tema resulta muy interesante a la hora de realizar un análisis forense para una pericial, ya que podríamos obtener información relevante que a simple vista no está accesible.
Existen ideas que se resisten a desaparecer. Y entre ellas hay un tipo especial, las que se basan en la confusión entre los propios deseos y la realidad. En ocasiones estas ideas se convierten en entes que sobreviven a su propia refutación. Durante siglos el ser humano ha ambicionado construir una máquina que sea capaz de funcionar continuamente, produciendo trabajo y sin aportes energéticos del exterior. Tanto la ha buscado que tiene hasta nombre: el móvil perpetuo de primera especie.
Durante siglos mentes por lo demás lúcidas han luchado contra la implacable realidad construyendo modelos que, una y otra vez, han fallado en el momento de ponerlos a prueba. Pero claro, sería tan maravilloso que semejante máquina pudiese existir… Tal vez con esta o aquella mejora pudiese funcionar. Hay que pulir esto y esto, refinar aquello. Todo en aras de la promesa de la liberación energética. Pero no. Es imposible una máquina tal en nuestro universo porque su mera existencia violaría una ley esencial del mismo: el primer principio de la termodinámica. Ante esta evidencia la Academia Nacional de las Ciencias de Paris decidió en 1775 que no aceptaría más proyectos de móviles perpetuos. Tal era el grado de consolidación de la termodinámica entonces que se adoptó como criterio infalible, ahorrando la necesidad de poner a prueba una y otra vez los dispositivos surgidos de la mente de gente con más buena intención que conocimientos físicos.
El caso es que hoy en día nos encontramos ante un caso similar. Cuando se trata de auditar la ciberseguridad de un sistema de control industrial, no importa el propietario, la tecnología o su propósito, en un gran número de casos acabamos topando con un ente al que podríamos denominar ‘el móvil perpetuo de los sistemas de control’ pero que se conoce habitualmente como ‘el sistema de control industrial aislado’. Y es que, efectivamente, si mi sistema de control estuviese efectivamente aislado y funcionase produciendo trabajo sin intercambiar información con el exterior, no tendría que preocuparme por su ciberseguridad, ¿no es cierto? Estaría asegurada de forma intrínseca.
Una y otra vez los ‘móviles perpetuos de los sistemas de control’ no resisten una investigación en profundidad. En el caso de los sistemas físicos basta definir un volumen de control en torno a nuestro móvil perpetuo y verificar si existe intercambio de energía con el exterior a través de esa frontera. En el caso de los sistemas industriales el concepto es el mismo, pero lo que buscamos son intercambios de información, de un tipo u otro. Siempre los hay: permanentes o temporales, síncronos o asíncronos, cableados o no, tontos (pendrives) o inteligentes (portátiles de mantenimiento). Y es que, ¿para qué sirve un sistema con el que no me puedo comunicar y que no puedo modificar de forma alguna?
La refutación caso por caso supone un importante gasto de energía desde el principio mismo del proyecto. Sería bastante útil que se adoptase un criterio equivalente al de la Academia de las Ciencias de Paris. De esta forma podríamos rechazar a priori cualquier reivindicación de aislamiento y podríamos ponernos a trabajar desde el principio.
Aunque, por otra parte, si configurase mi sistema de esa manera quizá entonces… sí, quizá…
Nota: la ilustración reproduce el ‘recipiente de flujo continuo’ de Robert Boyle. A nuestros ojos modernos puede producir hasta risa, que sin duda se tornará en sonrojo al pensar la opinión que tendrán los humanos del futuro al rememorar como en el siglo XXI se podía intentar defender el concepto de ‘sistema de información digital aislado’ (IMHO).
Vivimos en un mundo “conectado” digitalmente, en el que se distinguen distintos tipos de habitantes, principalmente aquellos que lo vieron “nacer” y los que han nacido como “ciudadanos digitales”.
Pero bien sea en el caso de los primeros por la forma en que se han relacionado habitualmente entre ellos o, en el caso de los segundos por esa confianza infundada de ser nativos, la cuestión está en que en muchas ocasiones se expone lo privado, propio y ajeno, ante el público en general, sin ser conscientes de estar haciéndolo o, peor aún, con indiferencia por el riesgo que entraña.
En la “prehistoria digital”, la gente más abierta se juntaba en parques mientras los niños o las mascotas jugaban, en bares para tomar una copa y poder departir con otros tertulianos, en asociaciones ya fueran culturales o de otra índole y allí, en un foro controlado, compartían historias sobre hechos acaecidos propios o de la familia y amigos. Había una “exposición” pública de la privacidad, pero con un alcance, que normalmente no era un problema, más allá de que a partir de ese momento podía ponerse en marcha la maquinaria de los chismosos y cotillas y, salvo que la historia tuviese meollo, raro era que llegase a más de tres pueblos de distancia. No es que no se obviase ya la privacidad propia, o que no se estuviese faltando a la privacidad ajena sin permiso del interesado, pero digamos que los riesgos eran en cierta manera “controlados” por el propio límite físico de la comunicación.
En la actualidad y, con el auge de todo tipo de redes sociales, las cosas han cambiado y mucho. Se tiende a publicar, sin ni siquiera controlar el alcance con el que se hace, todo tipo de detalles propios. Y lo que es peor, se publica información que atañe a terceros sin una mera consulta previa para ver si el interesado está por la labor. Está claro que ese ansia de ser “reportero” de tabloide es algo innato a muchos humanos, que se afanan por crear toda una serie de noticias sociales, más o menos interesantes, sobre el resto de mortales y de aderezarlas con la correspondiente información propia para mejorar la “calidad” de sus publicaciones.
Pongamos por caso ese afable amigo que nos hace una foto en una cena del grupo de antiguos alumnos y que luego, sin más, la sube a su perfil de Facebook. Y no contento con ello, nos etiqueta en la misma para que todavía sea mayor la probabilidad de que no se pierda entre la jungla de posts que a diario se publican en la red. A ver, que sí, que uno es consciente de que le han hecho una foto. Y que posiblemente, hasta esté agradecido si la misma se la hacen llegar por correo electrónico para poder tener un recuerdo de la ocasión. Pero ¿en qué momento ha autorizado que se le exponga públicamente en la red?
Este tema de publicar fotos de ajenos para la contemplación pública es algo que, al menos yo, no había visto tan extendido como en la actualidad. Con la salvedad de aquellos casos, en que los “amigos” de una pareja se dedicaban a colgar fotos de la misma por los postes del pueblo, indicando que se casaban y otras lindezas. Sinceramente, creo que esto de “colgar” fotos ajenas parece una moda que se nos ha ido de las manos. Parece como, si con el auge de los dispositivos que incorporan una cámara digital, la facilidad de uso de la misma y el coste insignificante de obtener capturas, todo el mundo se hubiese infundido de cierto “espíritu Cartier-Bresson”.
Quizá es necesaria una nueva asignatura en las escuelas y colegios, una asignatura en donde se complemente la enseñanza del uso de las nuevas tecnologías, con la enseñanza de la responsabilidad que supone el uso de las mismas y la necesidad del respeto a uno mismos y a los demás. Quizá sea necesaria la expedición de un carnet de ciudadano digital, que nos reconozca el conocimiento de lo que tan sólo debiera de ser usar el sentido común, y que sin el cual, no se nos permita transitar por este mundo digital.
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”):
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]
suppress gen_id 1, sig_id 1852
event_filter gen_id 1, sig_id 1852, type limit, track by_src, count 1, seconds 3600
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.
