Congela tu web con SnapWeb y ¡disfruta del fin de semana!

Desde que la mayoría de las empresas piensan en un CMS a la hora de decidir cómo hacer su flamante nueva Web, debo reconocer que de forma casi directamente proporcional han aumentado mis dolores de cabeza: que si un módulo no actualizado había permitido “colar” un shell-remoto, que si habían modificado todos los .js del site, que si Google marca mi sitio como que contiene software malicioso, etc.

Estos nuevos “desafíos” hicieron que recordara una herramienta con la que tropecé hace ya algunos años y que me pareció genial. Dicha herramienta (Deep Freeze) permitía “congelar” todo el disco de tal forma que, cualquier cambio realizado en el equipo (instalación de software, infección de virus,  descargas, etc.), era eliminado automágicamente al reiniciar.  Con este antecedente, pensé en hacer algo parecido. Un sistema que fuera capaz de impedir cualquier cambio en cualquier archivo de mi Web, incluso impedir que se pudiera añadir/eliminar cualquier nuevo fichero/directorio, es decir, una especie de modo "Sólo lectura" para la Web que me permitiera pasar un fin de semana tranquilo y sin llamadas.

Una vez tenía clara la idea feliz, y el nombre: SnapWeb, pensé en realizar una copia del directorio web y, a través de una tarea cron, comprobar si se había realizado cualquier cambio y restaurarlo con la copia. Si bien este sistema funcionaba de forma correcta, tenía dos problemas fundamentales: 

1. ¿Cada cuánto tiempo repito la tarea?
2. El hecho de tener que comprobar TODO el sitio web cada vez; esto es un gran hándicap para los sites hechos con un CMS donde hay múltiples archivos y directorios. 

Con estas debilidades encontradas, recordé un proyecto que vi, allá por el 2010, que permitía analizar ficheros en tiempo real con clamAV + Inotify (También en SbD se han publicado varios post acerca de este asunto: Post 1 y Post 2). En este caso, la API inotify (disponible a partir de linux 2.6.13),  permitía iniciar el antivirus cuando se producía cualquier cambio en el sistema de archivos. 

Puesto que tenía claro que mi sistema iba a estar programado en BASH, busqué en alternativas que implementaran dicha API y que lanzaran mi script cuando se produjera algún evento sobre el directorio del site. 

De las distintas opciones que vi seleccioné incron. Éste programa es una mezcla de cron (programación de tareas) + inotify (detección de eventos en el sistema de archivos), lo que permite que se ejecuten tareas cada vez que se produce un evento sobre el directorio indicado. Una de los hándicaps que tiene incron es la NO recursividad, es decir, que en el fichero de configuración /etc/incron.conf debe contener cada uno de los directorios del site, además, cualquier nuevo directorio que se cree dentro del site debe ser dado de alta en el fichero de configuración.

Para solucionar el problema de la NO recursividad de incron, tenía claro que mi proyecto debía estar divido en dos scripts:

1. snapweb.sh --> Encargado de, dado un directorio pasado como parámetro, dar de alta en el fichero de configuración de incron todos los subdirectorios (Así solucioné los problemas de recursividad). 
2. jack.sh --> Será lanzado por incron cuando se produzca un evento. Dicho script recibirá el nombre del fichero afectado, su ruta y el evento en cuestión.

Pensé en hacer una especie de snapshot del directorio y monitorizar cualquier cambio posterior, denegando dichos cambios; después pensé que denegar siempre sería un poco radical, que lo ideal sería poder configurar varios tipos de bloqueo. Finalmente me decanté por esta segunda opción, con lo que en un fichero de configuración /etc/snapweb/snapweb.conf podremos decidir el tipo de bloqueo, existiendo un valor global que habilita el modo "freeze" del site: site_lock=1.

Está claro que esta solución no resuelve todas la vulnerabilidades que pueden explotarse en un CMS, pero sí permite cierta inmunidad a determinados exploits cuyo “modus operandi” está basado en la modificación de archivos (CryptoPHP), en la subida de Shells remotos o, incluso, en el uso de credenciales FTP robadas para distribuir malware. 

Actualmente una vez implementado correctamente ese “modo candado”, aquí os dejo un link a un vídeo con una prueba de concepto.

Estoy realizando varias mejoras:

• Nuevos modos de "bloqueo":
• Modo automático: Analiza en tiempo real cualquier cambio, categoriza dichos cambios y decide qué hacer.
• Aceptar cambios y guardar réplica.
• Denegar cambios y volver a réplica -> En este caso, para evitar los problemas que pudiera provocar un falso positivo, guardo copia del archivo en “cuarentena”
• Modo semiautomático:
• Si no se detectan indicios de malware, se acepta cambio, se actualiza réplica y se envía correo de notificación.
• Si se detecta malware, por encima de un umbral, se rechazan los cambios y se notifica al administrador.
• Si sólo hay indicios de malware pero no certeza, se envía correo al administrador para que éste decida qué hacer con dicha incidencia.
• Modo candado: No permite ningún cambio en el site, descartando de forma automática cualquier cambio en el site (Nuevas carpetas/archivos, cambios en ficheros existentes, etc.)
• Configuración del modo por site: Ahora los modos de bloqueo pueden indicarse por site, en vez de un único tipo de bloqueo para todos los sites albergados.
• Exclusión de directorios a monitorizar.
• Activación de modo "candado" por horario.
• Administración y monitorización de snapweb vía App.

Espero acabar pronto con esta primera parte del proyecto, publicarlo en github y que esté disponible para todos aquellos que lo consideréis interesante.

Además aprovecho para indicaros que si tenéis cualquier duda, sugerencia o crítica,  estaré encantando de recibirlas... aunque con las críticas habilitaré el modo bloqueo  :P.

[+] Ruta GitHub para su descarga y prueba: https://github.com/wllop/snapweb

Fuente: http://www.securitybydefault.com/2015/07/congela-tu-web-con-snapweb-y-disfruta.html