Próximos eventos de formación presencial de seguridad en Securízame

A lo largo de 2017, en Securízame, hemos ido planificando un buen calendario de capacitaciones presenciales en la academia de nuestras instalaciones en Madrid. Así, hemos impartido dos sesiones de Gestión y Respuesta ante Incidentes en GNU/Linux, que han aportado un muy buen feedback por parte de los alumnos.  

26, 27 y 28 de Mayo de 2017: DFIR y Análisis Forense en Windows (8 plazas disponibles a la fecha) 

Como complemento al curso de Gestión de Respuesta ante Incidentes y Análisis Forense de Linux, surge este otro curso con el mismo objetivo para Windows. Preparar al alumno para que sea capaz de enfrentarse ante un incidente de seguridad, pero en este caso en el que las víctimas sean ordenadores con sistema operativo Windows.

En la misma línea, se entregará una imagen para un USB de Incident Response con herramientas para Windows, que utilizamos en Securízame para cuando nos toca hacer este tipo de actuaciones. Asimismo se detallarán los diferentes artifacts y elementos del sistema operativo, susceptibles de contener información valiosa en un incidente o a la hora de realizar un peritaje informático forense en Windows.

Los profesores que estaremos encargados de llevar a cabo esta formación somos Pedro Sánchez Cordero y yo (Lorenzo Martínez Rodríguez), que contamos con amplia experiencia en impartir este curso a diferentes empresas y organizaciones, de forma conjunta, con muy buenos resultados.   

Tienes la información y acceso al registro de este entrenamiento en este enlace: DFIR y Análisis Forense en Windows.

Las plazas, son limitadas a 20 alumnos, y en general un alto porcentaje de ellas suelen ser ocupadas por antiguos alumnos a los que, por su fidelidad, les enviamos la información para acceso al curso 24 horas antes de que el acceso sea público. De hecho, primera edición de este curso, planificada para el 5, 6 y 7 de Mayo, ya se llenó, y es por eso que tuvimos que abrir una nueva.

Aunque te parezca que algunas fechas están muy lejos en el calendario, no te descuides porque se suelen llenar pronto.

En caso que no puedas asistir a nuestras formaciones por no encajarte las fechas o por la distancia a Madrid, tienes alternativas online en https://cursos.securizame.com/cursos, que no están sujetas a ningún tipo de agenda, puesto que se trata de cursos pre-grabados. Esto significa que si quieres hacer cualquiera de los cursos que están disponibles en la página, simplemente te registras, efectúas el pago del mismo y te generamos todo el material de forma personalizada. 

Si tienes cualquier duda, o requieres más información respecto a alguna de los cursos o el entrenamiento, puedes contactar con nosotros a través del formulario en https://www.securizame.com/contacto

Leer más...

Security Onion: Distribución GNU/Linux para análisis de red

Muchas veces nos toca analizar el tráfico de red intercambiado entre una máquina e Internet, o incluso comprobar si un equipo tiene alguna variedad de malware que lleve a cabo actividad de red, ya sea para atacar a otras máquinas o para comunicarse con el C&C de una botnet.

En esas situaciones, o simplemente en un despliegue preventivo de sondas IDS, la distribución Linux opensource Security Onion,  de la que hablo en este post, puede servir de gran utilidad. 

Básicamente, incorpora de forma preinstalada, diversas herramientas ampliamente conocidas, un IDS como Snort y/o Suricata (nos da a elegir qué herramienta deseamos usar), GUIs para monitorizar los eventos de forma automática (Squert, Sguil), herramientas específicas para análisis de PCAPs (Wireshark, NetworkMiner) y herramientas populares de análisis forense de red como (Bro o Xplico). De algunas de ellas hemos hablado ampliamente en SbD en vidas pasadas.

En muchas ocasiones, pensamos que puede resultarnos interesante montar y elegir qué herramientas queremos habilitar para nuestro despliegue de sondas, y generalmente cuando me preguntan o en diversas formaciones, recomiendo hacer siempre una instalación mínima e instalar las herramientas justas y necesarias para cada caso. 

Sin embargo, a veces la configuración de determinadas herramientas como Bro, o la integración con PF_RING, para entornos de grandes necesidades de tráfico, pueden resultar problemáticas, y se agradece tener un punto de partida desde el cuál empezar con varias herramientas ya integradas, pudiendo deshabilitar aquello que no nos interese, dejando el resto.

En estos casos, es cuando Security Onion me ha resultado de gran utilidad, puesto que en pocos minutos ya trae todo lo necesario y con un único wizard se configura la mayoría de los productos. 

Está basada en Ubuntu y viene con entorno gráfico, así como varias herramientas que se pueden gestionar vía web. 

Una de las herramientas más interesantes que trae es ELSA (Enterprise Log Search and Archive), que permite hacer la vida cómoda al analista, de forma gráfica, cuando tiene que interactuar con Bro.

Con esta solución, se puede llegar a hacer un buen NSM (o sistema de gestión de red) permitiendo configurar un nodo como servidor y el resto como sondas, de manera que se pueda consultar toda la información recopilada desde un mismo punto centralizado.   

Por buscarle una pega, en la última versión de Security Onion, han eliminado de la lista de herramientas una de las interfaces para Snort que más me gustan, que es Snorby. Aun así, supongo que puede seguirse instalando manualmente.

Y si ya tengo un despliegue de sondas hecho, pero me interesan algunas de Security Onion ¿Qué hago?

Bueno pues otra de las ventajas que tiene Security Onion, es que no es necesario que instales la distribución entera y partas de ella, sino que puedes incorporar únicamente los repositorios al sources.list de otra distribución basada en Debian/Ubuntu e instales aquellos paquetes que te interesan, o todos juntos.

Para el nuevo curso de Análisis Forense Digital en Profundidad que vamos a dar en Securízame, en el módulo I, en la parte en la que daré pautas sobre cómo construir un Laboratorio Forense, demostraré cómo incorporar y configurar las herramientas de Security Onion en una distribución específica para forense como es Caine, de la que ya hemos hablado en SbD.

Bajo estas líneas, os dejo una lista de videos de Security Onion, en el que hay un How-to de cómo hacer la instalación, configuración y parte de la operación. 

Leer más...

Buenas prácticas de seguridad en Docker

Docker es una plataforma abierta que permite construir, portar y ejecutar aplicaciones distribuidas, se basa en contenedores que corren en Linux y funcionan tanto en máquinas físicas como virtuales simplemente usando un runtime. Está escrito en Go y usa librerías del sistema operativo así como funcionalidades del kernel de Linux en el que se ejecuta. Consta de un engine con API RESTful y un cliente que pueden ejecutarse en la misma máquina o en máquinas separadas. Es Open Source (Apache 2.0) y gratuito.

Los contenedores existen desde hace muchos años, Docker no ha inventado nada en ese sentido, o casi nada, pero no hay que quitarles mérito, están en el momento adecuado y aportan las características y herramientas concretas que se necesitan en la actualidad, donde la portabilidad, escalabilidad, alta disponibilidad y los microservicios en aplicaciones distribuidas son cada vez más utilizados, y no sólo eso, sino que también son mejor entendidos por la comunidad de desarrolladores y administradores de sistemas. Cada vez se desarrollan menos aplicaciones monolíticas y más basadas en módulos o en microservicios, que permiten un desarrollo más ágil, rápido y a la vez portable. Empresas de sobra conocidas como Netflix, Spotify o Google e infinidad de Start ups usan arquitecturas basadas en microservicios en muchos de los servicios que ofrecen.

Te estarás preguntando ¿Y no es más o menos lo mismo que hacer un chroot de una aplicación? Sería como comparar una rueda con un coche. El concepto de chroot es similar ya que se trata de aislar una aplicación, pero Docker va mucho más allá, sería un chroot con esteroides, muchos esteroides. Por ejemplo, puede limitar y controlar los recursos a los que accede la aplicación en el contenedor, generalmente usan su propio sistema de archivos como UnionFS o variantes como AUFS, btrfs, vfs, Overlayfs o Device Mapper que básicamente son sistemas de ficheros en capas. La forma de controlar los recursos y capacidades que hereda del host es mediante namespaces y cgroups de Linux. Esas opciones de Linux no son nuevas en absoluto, pero Docker lo hace fácil y el ecosistema que hay alrededor lo ha hecho tan utilizado. 

Adicionalmente, la flexibilidad, comodidad y ahorro de recursos de un contenedor es mayor a la que aporta una máquina virtual o un servidor físico, esto es así en muchos casos de uso, no en todos. Por ejemplo, tres servidores web para un cluster con Nginx en una VM con una instalación de Linux CentOS mínima ocuparía unos 400MB, multiplicado por 3 máquinas sería total de uso en disco de 1,2 GB, con contenedores serían 400MB las mismas 3 máquinas corriendo ya que usa la misma imagen para múltiples contenedores. Eso es sólo por destacar una característica interesante a nivel de recursos. Otro uso muy común de Docker es la portabilidad de aplicaciones, imagina una aplicación que solo funciona con Python 3.4 y hacerla funcionar en un sistema Linux con Python 2.x es complicado, piensa en lo que puede suponer en un sistema en producción actualizar Python, con contenedores sería casi automático, descargar la imagen del contenedor y ejecutar la aplicación de turno. 

Solo por ponernos en situación de la envergadura Docker, unos números alrededor del producto y la compañía (fuente aquí):

• 95 millones de dólares de inversión.
• Valorada en 1.000 millones de dólares.
• Más de 300 millones de descargas en 96 releases desde marzo de 2013

Pero un contenedor no es para todo, ni hay que volverse loco “dockerizando” cualquier cosa, aunque no es este el sitio para esa reflexión. Al cambiar la forma de desarrollar, desplegar y mantener aplicaciones, también cambia en cierto modo la forma de securizar estos nuevos actores.

Docker aporta seguridad en capas, aísla aplicaciones entre ellas y del host sin usar grandes recursos, también se pueden desplegar contenedores en máquinas virtuales lo que aporta otra capa adicional de aislamiento (estaréis pensando en VENOM pero eso es otra película que no afecta directamente a Docker). Dada la arquitectura de Docker y usando buenas prácticas, aplicar parches de seguridad al anfitrión o a aplicaciones suele ser más rápido y menos doloroso.

Buenas Prácticas de Seguridad:

Aunque la seguridad es algo innato en un contenedor, desde Docker Inc. están haciendo esfuerzos por la seguridad, por ejemplo, contrataron hace unos meses a ingenieros de seguridad de Square, que no son precisamente nuevos en el tema. Ellos, junto a compañías como VMware entre otras, han publicado recientemente un extenso informe de sobre buenas prácticas de seguridad en Docker en el CIS. Gracias a este informe tenemos acceso a más de 90 recomendaciones de seguridad a tener siempre en cuenta cuando vamos a usar Docker en producción. En la siguiente tabla podemos ver las recomendaciones de seguridad sugeridas, algunas son muy obvias pero un check list así nunca viene mal:

1. Recomendaciones a nivel de host

1.1. Crear una partición separada para los contenedores 

1.2. Usar un Kernel de Linux actualizado 

1.3. No usar herramientas de desarrollo en producción

1.4. Securizar el sistema anfitrión 

1.5. Borrar todos los servicios no esenciales en el sistema anfitrión

1.6. Mantener Docker actualizado 

1.7. Permitir solo a los usuarios autorizados controlar el demonio Docker

1.8. Auditar el demonio Docker  (auditd)

1.9. Auditar el fichero o directorio de Docker - /var/lib/docker 

1.10. Auditar el fichero o directorio de Docker - /etc/docker 

1.11. Auditar el fichero o directorio de Docker - docker-registry.service 

1.12. Auditar el fichero o directorio de Docker - docker.service 

1.13. Auditar el fichero o directorio de Docker - /var/run/docker.sock 

1.14. Auditar el fichero o directorio de Docker - /etc/sysconfig/docker 

1.15. Auditar el fichero o directorio de Docker - /etc/sysconfig/docker-network 

1.16. Auditar el fichero o directorio de Docker - /etc/sysconfig/docker-registry 

1.17. Auditar el fichero o directorio de Docker - /etc/sysconfig/docker-storage 

1.18. Auditar el fichero o directorio de Docker - /etc/default/docker 

2. Recomendaciones a nivel de Docker Engine (daemon)

2.1 No usar el driver obsoleto de ejecución de lxc 

2.2 Restringir el tráfico de red entre contenedores 

2.3 Configurar el nivel de logging deseado 

2.4 Permitir a Docker hacer cambios en iptables 

2.5 No usar registros inseguros (sin TLS)

2.6 Configurar un registro espejo local

2.7 No usar aufs como driver de almacenamiento

2.8 No arrancar Docker para escuchar a  una IP/Port o Unix socket diferente

2.9 Configurar autenticación TLS para el daemon de Docker

2.10 Configurar el ulimit por defecto de forma apropiada



3. Recomendaciones a nivel de configuración de Docker

3.1 Verificar que los permisos del archivo docker.service están como root:root 

3.2 Verificar que los permisos del archivo docker.service están en 644 o más restringidos 

3.3 Verificar que los permisos del archivo docker-registry.service están como root:root 

3.4 Verificar que los permisos del archivo docker-registry.service están en 644 o más restringidos

3.5 Verificar que los permisos del archivo docker.socket están como root:root 

3.6 Verificar que los permisos del archivo docker.socket están en 644 o más restringidos

3.7  Verificar que los permisos del archivo de entorno Docker (/etc/sysconfig/docker o /etc/default/docker) están como root:root 

3.8 Verificar que los permisos del archivo de entorno Docker (/etc/sysconfig/docker o /etc/default/docker) están en 644 o más restringidos

3.9 Verificar que los permisos del archivo /etc/sysconfig/docker-network (si se usa systemd) están como root:root 

3.10 Verificar que los permisos del archivo /etc/sysconfig/docker-network están en 644 o más restringidos

3.11  Verificar que los permisos del archivo /etc/sysconfig/docker-registry (si se usa systemd) están como root:root

3.12 Verificar que los permisos del archivo /etc/sysconfig/docker-registry (si se usa systemd) están en 644 o más restringidos

3.13 Verificar que los permisos del archivo /etc/sysconfig/docker-storage (si se usa systemd) están como root:root 

3.14 Verificar que los permisos del archivo /etc/sysconfig/docker-storage (si se usa systemd) están en 644 o más restringidos 

3.15 Verificar que los permisos del directorio /etc/docker están como root:root 

3.16 Verificar que los permisos del directorio /etc/docker están en 755 o más restrictivos 

3.17 Verificar que los permisos del certificado del registry están como root:root 

3.18 Verificar que los permisos del certificado del registry están en 444 o más restringidos 

3.19 Verificar que los permisos del certificado TLS CA están como root:root 

3.20 Verificar que los permisos del certificado TLS CA están en 444 o más restringidos 

3.21 Verificar que los permisos del certificado del servidor Docker están como root:root 

3.22 Verificar que los permisos del certificado del servidor Docker están en 444 o más restringidos 

3.23 Verificar que los permisos del archivo de clave del certificado del servidor Docker están como root:root 

3.24 Verificar que los permisos del archivo de clave del certificado del servidor Docker están en 400 

3.25 Verificar que los permisos del archivo de socket de Docker están como root:docker 

3.26 Verificar que los permisos del archivo de socket de Docker están en 660 o más restringidos 

4. Imágenes de Contenedores y Dockerfiles

4.1 Crean un usuario para el contenedor

4.2 Usar imágenes de confianza para los contenedores 

4.3 No instalar paquetes innecesarios en el contenedor

4.4 Regenerar las imágenes si es necesario con parches de seguridad

5. Runtime del contenedor

5.1 Verificar el perfil de AppArmor (Debian o Ubuntu) 

5.2 Verificar las opciones de seguridad de SELinux (RedHat, CentOS o Fedora) 

5.3 Verificar que los contenedores esten ejecutando un solo proceso principal

5.4 Restringir las Linux Kernel Capabilities dentro de los contenedores 

5.5 No usar contenedores con privilegios   

5.6 No montar directorios sensibles del anfitrión en los contenedores

5.7 No ejecutar ssh dentro de los contenedores

5.8 No mapear puertos privilegiados dentro de los contenedores

5.9 Abrir solo los puertos necesarios en un contenedor

5.10 No usar el modo “host network” en un contenedor 

5.11 Limitar el uso de memoria por contenedor 

5.12 Configurar la prioridad de uso de CPU apropiadamente 

5.13 Montar el sistema de ficheros raíz de un contenedor como solo lectura

5.14 Limitar el tráfico entrante al contenedor mediante una interfaz específica del anfitrión

5.15 Configurar la política de reinicio 'on-failure' de un contenedor a 5 

5.16 No compartir PID de procesos del anfitrión con contenedores

5.17 No compartir IPC del anfitrión con contenedores 

5.18 No exponer directamente dispositivos del anfitrión en contenedores

5.19 Sobre-escribir el ulimit por defecto en tiempo de ejecución solo si es necesario



6. Operaciones de Seguridad en Docker

6.1 Realizar auditorías de seguridad tanto en el anfitrión como en los contenedores de forma regular

6.2 Monitorizar el uso, rendimiento y métricas de los contenedores

6.3 Endpoint protection platform (EPP) para contenedores (si las hubiese) 

6.4 Hacer Backup de los datos del contenedor 

6.5 Usar un servicio centralizado y remoto para recolección de logs

6.6 Evita almacenar imágenes obsoletas, sin etiquetar correctamente o de forma masiva.   

6.7 Evita almacenar contenedores obsoletos, sin etiquetar correctamente o de forma masiva.

En algunos casos, hay recomendaciones que merecen un artículo por si solas. Si quieres profundizar más en este tema recuerda que los pormenores de estos aspectos de seguridad y auditoría los ampliaremos durante el curso online de Securízame "Hardening de Windows, Linux e Infraestructuras" en el que colaboraré junto a Lorenzo Martínez, Yago Jesús, Juan Garrido y Pedro Sanchez, todo un lujo de curso en el que aportaré mi granito de arena con seguridad en Docker completando el módulo de Hardening Linux. Más información aquí: https://www.securizame.com/curso-online-hardening-sistemas-windows-linux-infraestructuras/

Para otros posibles artículos en el futuro me parece interesante ver algunas consideraciones de seguridad en Docker Hub y otros componentes relacionados, así como auditorías de contenedores con Lynis.

Recursos y referencias:

https://d3oypxn00j2a10.cloudfront.net/assets/img/Docker%20Security/WP_Intro_to_container_security_03.20.2015.pdf

https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.6_Benchmark_v1.0.0.pdf

Contribución por Toni de la Fuente (@toniblyx y blyx.com)

Leer más...

Extrayendo datos MRU en Linux de escritorio

MRU. ¿Qué son?

Los archivos MRU, por sus siglas en inglés Most Recently Used [files] son de gran ayuda en un análisis forense a la hora de averiguar cuáles fueron los últimos ficheros que se manipularon en un espacio de tiempo determinado. Si bien es verdad que para sistemas Windows hay, desde hace muchísimo tiempo, innumerables herramientas que facilitan la labor de extracción, parseo y presentación de este tipo de información (en su mayoría del registro de Windows), no hay tantas para sistemas Linux de escritorio.

Aunque no es un escenario frecuente, puede darse el caso de que el perito/analista forense se tenga que enfrentar a una máquina Linux con KDE, Gnome o cualquiera de los múltiples escritorios disponibles. Por ello decidí empezar a escribir MRUTools, y al hacerlo descubrí algunos hechos que no saltan inmediatamente a la vista.

1. No hay una forma ‘estándar’ de almacenar esta información. Cada aplicación que posee esta funcionalidad, e incluso cada escritorio, lo hace de una forma distinta, si bien algunas aplicaciones integradas, o de uso mayoritario en un escritorio particular se atañen a ciertas ‘reglas’. 
2. Como consecuencia del punto anterior, en muchos casos no basta con ‘eliminar’ las referencias a estos ficheros desde la opción que da el escritorio (lo cual me ha brindado alguna que otra sorpresa al ejecutarlo en mi propia máquina).

Al lío: Buscando información en KDE
Usando el viejo método de ensayo-error, abrimos un fichero de prueba con Kate, el editor de textos por defecto en KDE: prueba.txt
 

Como no sabemos a priori dónde almacena esta información, podríamos ir a la documentación de KDE y buscarlo, pero siendo un poco impacientes, ejecutamos un grep en nuestro $HOME y obtenemos lo siguiente:

 

Vaya, la cosa se pone interesante. Aparecen varias referencias a nuestro fichero de prueba. Tomamos nota de las ubicaciones para inspeccionarlas más a fondo:

• $HOME/.kde/share/apps/RecentDocuments 
• $HOME/.kde/share/apps/kate/katerc 
• $HOME/.kde/share/apps/kate/metainfos 

Si investigamos el contenido de estas ubicaciones, vemos que:

1. El escritorio KDE almacena la información de los ficheros que abrimos desde él en una carpeta llamada RecentDocuments. Cada fichero abierto (más info: ver xdg-open) genera una entrada en este directorio (hasta un máximo de diez, después van rotando) con una estructura definida (¡y parseable! :D). 
2. Parece que cada aplicación independiente que tenga funcionalidad de ‘Recent Files…’ también posee su propio listado de ficheros. Lo interesante aquí es que si pulsamos botón derecho en el menú de KDE ‘Usados Recientemente’ y hacemos click en ‘Limpiar documentos recientes’, éstas entradas efectivamente desaparecen del menú (se vacía el contenido del directorio $HOME/.kde/share/apps/RecentDocuments), pero si ejecutamos de nuevo el grep anterior…

Efectivamente, las referencias a ficheros abiertos permanecen de forma independiente por cada aplicación (por lo que he podido comprobar ocurre en varias como VLC, Dragon Player y como estamos viendo aquí, Kate). MRUTools surge de la idea de automatizar el proceso de extracción, parseo y presentación de este tipo de información:

Ejemplo y Timeline 

Evidentemente al ejecutar la herramienta en un entorno real obtenemos gran cantidad de datos que por sí solos no aportan una visión general de la situación. Es necesario estructurar los datos, por ejemplo en una línea temporal. Para ello nos viene muy bien el proyecto Timeline.

Esta herramienta escrita en Python se adapta perfectamente a nuestras necesidades. Tras leer la documentación disponible en su web y entender cómo funciona, adaptamos MRUTools para que exporte un fichero XML que Timeline sea capaz de entender. Y el resultado final, tras ejecutarlo en una máquina real ejecutando KDE es el siguiente:

Un gran punto a favor de Timeline es que nos permite visualizar de forma interactiva los eventos que hayamos generado, mostrando de una forma muy gráfica y ordenada la salida de MRUTools. 

Conclusiones

A partir de los resultados obtenidos hemos podido comprobar que los archivos MRU son de mucha ayuda en un análisis forense, y además, cada aplicación mantiene los suyos, lo que dificulta el borrado de huellas. No es una fuente del todo fiable, ya que como (casi) todo lo digital, puede ser manipulable, pero eso lo dejamos para otra entrega. 

Artículo cortesía de Ángel Suárez-B. Martín (n0w)
@asuarezbm

Leer más...

Vuelve el curso Attack & Hardening de GNU Linux !

Hace relativamente poco tiempo, tuve la oportunidad de impartir junto a Lorenzo el curso 'Attack & Hardening de GNU Linux' en el que combinábamos dos modalidades: Ataque y defensa.

Por un lado, un módulo de 8 horas en el que se veía de forma extensiva como plantear una auditoría a todos los niveles para un entorno Linux. 

Hablamos de cómo obtener información de un sistema, cómo evaluar su nivel de riesgo, lanzamos ataques de red, atacamos el sistema por fuerza bruta, vimos en profundidad cómo explotar un entorno web y finalmente tratamos el tema del exploiting de binarios 'setuid'.

Después de eso, otro imponente módulo en el que se valoraba como evitar lo anteriormente expuesto aplicando las técnicas más modernas y completas de 'hardening'

A todo esto, se sumó el gran DAVID HERNÁNDEZ que impartió un seminario sobre optimización de entornos GLAMP.

Hoy puedo anunciar que el curso VUELVE A ESTAR DISPONIBLE. De hecho, va a ser el mismo curso, exactamente igual a como se impartió ya que ahora está disponible en su modalidad offline, es decir, el acceso a las sesiones que se grabaron cuando se impartió.

Pero esto no significa que vaya a ser como los capítulos de ' Los Simpson', un formato enlatado no interactivo. No, el grueso del curso va a ser offline, pero todos los alumnos van a contar con atención individualizada por correo para resolver CUALQUIER duda. 

Además también habrá tutorías 'en directo' para poder repasar los conceptos en los que los alumnos quieran hacer hincapié.

El curso cuenta con documentación técnica y hasta una máquina virtual con un entorno creado ad-hoc para auditar las vulnerabilidades vistas en el training.

Los interesados, dirigirse aquí

Leer más...

No me toques la web, que me entero

Uno de los problemas de seguridad más comunes es la modificación de un website por parte de un atacante. Tanto en su versión 'deface' como en otras vertientes mucho peores.

Hoy día es muy común sufrir un ataque a un CMS como Joomla o Wordpress y que la web termine sirviendo para distribuir malware mediante la inyección de alguna suerte de código en HTML/Javascript.

Hace unos días leí en NIXCRAFT un interesante artículo donde reseñaban la herramienta incron. Una herramienta que, aprovechando Inotify(), permite detectar en tiempo real cuando se modifica un fichero o directorio y lanzar un comando.

Con esta herramienta resulta muy fácil crear un pequeño sistema HIDS para que nos avise en tiempo real si algún fichero del directorio que contiene nuestra web sufre algún cambio (o aparece un nuevo fichero)

Lo primero que hemos de hacer es instalar dicha herramienta. Vamos a usar Fedora como sistema base aunque trasladar el concepto a un entorno Debian resulta trivial.

# yum -y install incron

Con esto ya tendremos instalado el software base para poder configurar nuestro mini-HIPS.

Ahora vamos a instalar ciertos módulos Perl para poder generar correos electrónicos cuando se detecte un evento

# yum -y install perl-Email-MIME

# yum -y install perl-Email-Sender

Y usaremos este simple script para enviar correos:

#!/usr/bin/perl
use strict;
use warnings;
use Email::MIME;

my $message = Email::MIME->create(
  header_str => [
    From    => 'alerts@example.com',
    To      => 'yjesus@example.com',
    Subject => 'Alerta cambio WEB',
  ],
  attributes => {
    encoding => 'quoted-printable',
    charset  => 'ISO-8859-1',
  },

  body_str => "Cambio de tipo @ARGV[0] en fichero @ARGV[1]"
);

use Email::Sender::Simple qw(sendmail);
sendmail($message);

Tan solo hay que 'customizar' el correo origen y el destino.

Copiamos dicho script a /usr/local/bin y le damos el correspondiente chmod +x 

# cp sendalert.pl /usr/local/bin/

# chmod +x /usr/local/bin/sendalert.pl

Y arrancamos incrond

# service incrond start

Ahora vamos a crear la correspondiente entrada para monitorizar el directorio /var/www/html (donde típicamente se almacena un site web ...)

# incrontab -e

Y en el editor pulsamos 'a' para poder escribir y añadir:

/var/www/html IN_MODIFY,IN_ATTRIB,IN_CREATE,IN_DELETE /usr/local/bin/sendalert.pl "$% $#"

Luego pulsamos 'Esc' y :wq 

Con esto ya tendremos nuestro sistema de alerta temprana para cambios en el sitio web. Una vez algo se modifique recibiremos un correo parecido a este:

Leer más...