Llevo muchos años siendo docente en diferentes universidades con temáticas de ciberseguridad. He tenido la suerte de poder conocer a muchos alumnos, de poder motivar a muchos de ellos y de poder hacerme amigos de mucha gente con un gran potencial. Para mí ha sido y es un orgullo poder decir que he tenido muchas horas de vuelo en las clases y que creo que un porcentaje alto de alumnos han estado contentos conmigo y con lo que he podido transmitirles.
Figura 1: La importancia de los laboratorios para aprender
hacking y un WAF como modSecurity a prueba
Siempre he hablado de la importancia que tiene que un alumno no se limite a observar al profesor, cuando éste les muestra un ejemplo para afinar el conocimiento. El alumno debe actuar y poner a prueba lo que le cuentan, lo que le muestran, lo que le enseñan. Es importante que los alumnos levanten sus contenedores de Docker, sus máquinas virtuales, sus entornos privados para probar sobre sus recursos lo que les enseñan.
Muchos me habrán escuchado decir que no vale de nada que yo lo haga, que yo ya lo hice muchas veces, que tienes que probarlo tú, hacer el conocimiento tuyo, hacerlo interno, entenderlo a base de encontrarte problemas cuando al profesor no se le presentaron dichos problemas. Creo que en algún minuto de este video se puede ver justo lo que comento.
Figura 3: Pablo González en CiberCamp 2018: Aquellos años locos
No creáis que hoy me he levantado nostálgico o que voy a dejar algo que me llena tanto como seguir conociendo al talento, al potencial que hay detrás de cada historia que se sienta a ver lo que éste joven les tiene que contar. Solo quería dar pie al artículo técnico que quería contar hoy y es que hoy quiero hablar de la importancia de montarte tus laboratorios y aprender. Hoy quiero dar respuesta a algunas consultas que me llegan y que me preguntan por mi buzón de MyPublicInbox por algún consejo para aprender, para iniciarse, para entrar en este mundo tan apasionante, por consultas de alguno de mis libros, etcétera.
 |
| Figura 2: Libro de Docker: SecDevOps de Fran Ramírez, Rafael Troncoso y Elías Grande |
Muchos me habrán escuchado decir que no vale de nada que yo lo haga, que yo ya lo hice muchas veces, que tienes que probarlo tú, hacer el conocimiento tuyo, hacerlo interno, entenderlo a base de encontrarte problemas cuando al profesor no se le presentaron dichos problemas. Creo que en algún minuto de este video se puede ver justo lo que comento.
Figura 3: Pablo González en CiberCamp 2018: Aquellos años locos
No creáis que hoy me he levantado nostálgico o que voy a dejar algo que me llena tanto como seguir conociendo al talento, al potencial que hay detrás de cada historia que se sienta a ver lo que éste joven les tiene que contar. Solo quería dar pie al artículo técnico que quería contar hoy y es que hoy quiero hablar de la importancia de montarte tus laboratorios y aprender. Hoy quiero dar respuesta a algunas consultas que me llegan y que me preguntan por mi buzón de MyPublicInbox por algún consejo para aprender, para iniciarse, para entrar en este mundo tan apasionante, por consultas de alguno de mis libros, etcétera.
(Revisada y Ampliada) de Carlos Álvarez y Pablo González en 0xWord
Muchos no saben que simplemente con su curiosidad y con sus ganas ya están dentro de este mundo. Aprovechando que acaba de salir la 4ª Edición del libro de Hardening Servidores GNU/Linux donde yo participo, hoy quiero hablar de ModSecurity, quiero montarme mi laboratorio con dos, tres máquinas y mostrar cómo sería eso de “móntate tu entorno y prueba, aprende”. Lo primero es tener claro que queremos montar:
- Una máquina Ubuntu a la que instalaremos modsecurity.
- Una máquina Kali Linux 2020 a la cual llamaremos “la mala”.
- Un entorno web vulnerable al que ayudaremos a proteger.
Hay que tener en cuenta que poner un WAF (Web Application Firewall) no es exactamente solventar los problemas de seguridad. Los problemas de seguridad del entorno web seguirán estando ahí, aunque el WAF nos proteja de ciertas situaciones. Por esto, es interesante que en las auditorías web se prueben con y sin WAF activado. La falsa sensación de seguridad que nos puede dar un WAF puede ser un fallo de concepto de nuestra apreciación.
Instalando ModSecurity: Manos a la obra
Vamos a instalar ModSecurity. Haremos un resumen y una instalación sencilla, ya que el proceso se puede complicar hasta límites, en algunos casos, insospechados. A continuación, se resumen el proceso de instalación de un Apache con :
Instalando ModSecurity: Manos a la obra
Vamos a instalar ModSecurity. Haremos un resumen y una instalación sencilla, ya que el proceso se puede complicar hasta límites, en algunos casos, insospechados. A continuación, se resumen el proceso de instalación de un Apache con :
- Instalar apache2 y modsecurity a través de Ubuntu con apt install. Ejemplo: apt install apache2 libapache2-mod-security2.
- Tras instalar apache2 y la librería de modsecurity hay que verificar que modsecurity está habilitado. Para ello se puede hacer uso de apachectl -M. con esta instrucción podemos verificar que modsecurity se encuentra instalado, incluso podríamos filtrar con un grep para encontrar entre todo lo disponible.
Figura 5: Instalación de Apache
- Encontramos el módulo security2 con el valor “(shared)”.
- Si es así, parece que todo ha ido bien, toca configurar modsecurity.
La configuración de modsecurity se puede llevar a cabo a través del fichero /etc/modsecurity/modsecurity.conf. Hay varias cosas que debemos mirar y revisar en este fichero que vamos a ver a continuación.
Figura 6: modsecurity.conf
La primera regla y la más importante es SecRuleEngine que habilita modsecurity. Después, modsecurity tiene un conjunto de reglas por defecto, las cuales se encuentran en el directorio /usr/share/modsecurity-crs. Es altamente recomendable descargar reglas actualizadas desde repositorios de Github, con ejemplos para aprender.
Un ejemplo de repositorio a tener localizado es el de SpiderLabs con Owasp-modsecurity-crs. Ahora se conoce como OWASP Modsecurity Core Rule Set. Para poder descargarlo se puede hacer uso de git clone. Una vez descargado se puede copiar el fichero de configuración a /usr/share/modsecurity-crs/crs-setup.conf.
Figura 7: modsecurity core rule set en Git Hub
Ahora se puede configurar dichas reglas editando el fichero security2.conf que se encuentra en el directorio /etc/apache2/mods-enabled. Debemos añadir un par de IncludeOptional en el fichero security2.conf.
o IncludeOptional /usr/share/modsecurity-crs/*.conf.
o IncludeOptional /usr/share/modsecurity-crs/rules/*.conf.
Una vez hecho todo esto, debemos reiniciar el servicio de Apache2 y tendremos listas las nuevas reglas descargadas y ModSecurity.
Probando ModSecurity: Entorno con dos máquinas
Lo primero es definir qué tendremos en la máquina Ubuntu, en este caso tenemos una aplicación web vulnerable y nuestro apache con la librería de modsecurity. Hemos montado un DVWA sobre Ubuntu, la instalación se puede encontrar fácilmente. Nuestro modsecurity protegerá al DVWA y se podrá estudiar el funcionamiento del WAF in situ. En este ejemplo vamos a utilizar uno de los ataques a aplicaciones web más conocidos y del que Chema Alonso escribió un libro junto con Enrique Rando: Los ataques de SQL Injection.
Lo primero es definir qué tendremos en la máquina Ubuntu, en este caso tenemos una aplicación web vulnerable y nuestro apache con la librería de modsecurity. Hemos montado un DVWA sobre Ubuntu, la instalación se puede encontrar fácilmente. Nuestro modsecurity protegerá al DVWA y se podrá estudiar el funcionamiento del WAF in situ. En este ejemplo vamos a utilizar uno de los ataques a aplicaciones web más conocidos y del que Chema Alonso escribió un libro junto con Enrique Rando: Los ataques de SQL Injection.
 |
| Figura 8: Libro Hacking de Aplicaciones Web: SQL Injection 3ª Edición de Chema Alonso y Enrique Rando en 0xWord |
Esto es algo vital, enfrentarse a las situaciones, a los entornos, es una forma interesante de aprender y encontrarse con la realidad, por compleja que pueda parecernos. DVWA (Damn Vulnerable Web Application) es un entorno de pruebas para practicar y entender las vulnerabilidades web. Una de las cosas interesantes de este entorno es que se puede ver el código web con diferentes niveles. Es decir, si tenemos un SQL Injection se puede ver en diferentes dificultades, diferentes errores en el código que introducen en la aplicación el SQL Injection. Sin duda, interesante para aprender.
Con la configuración de DVWA en modo fácil, en la última versión hay 4 niveles, introduciendo una comilla veremos como se genera un error de sintaxis. Si aplicamos un ‘or’1’=’1 veríamos los datos de la tabla a la que se consulta. Seguramente sea el SQL Injection más sencillo y más intuitivo. Perfecto para aprender.
Ahora habilitamos modsecurity a través del fichero /etc/modsecurity/modsecurity.conf. Habilitamos la opción SecRuleEngine y la ponemos a ON. A partir de aquí todo el tráfico pasará por las reglas de modsecurity que descargamos y añadimos en los apartados anteriores. Ahora veremos que cuando se intenta llevar a cabo la misma operación el resultado es un “forbidden”.
Una forma de aprender cómo funcionan, no solo los ataques de SQL Injection, sino todas las técnicas de Hacking Web Technologies, e incluso se pueden ver los ataques Client-Side que pasan por un servidor web, y como un WAF puede ir trabajando sobre ellos para protegernos es éste. Aplicando a diferentes tipos de ataques en plataformas como DVWA se puede aprender y mucho. Siempre pensando en el ataque y en la protección. En la vida real te encontrarás protecciones y tendrás que conocer cómo funcionan para poder aplicar bypasses. Eso lo dejamos para otra historia.
Figura 9: Aplicación DVWA
Con la configuración de DVWA en modo fácil, en la última versión hay 4 niveles, introduciendo una comilla veremos como se genera un error de sintaxis. Si aplicamos un ‘or’1’=’1 veríamos los datos de la tabla a la que se consulta. Seguramente sea el SQL Injection más sencillo y más intuitivo. Perfecto para aprender.
Figura 10: Resultado del SQL Injection Level 1
Ahora habilitamos modsecurity a través del fichero /etc/modsecurity/modsecurity.conf. Habilitamos la opción SecRuleEngine y la ponemos a ON. A partir de aquí todo el tráfico pasará por las reglas de modsecurity que descargamos y añadimos en los apartados anteriores. Ahora veremos que cuando se intenta llevar a cabo la misma operación el resultado es un “forbidden”.
Figura 11: modsecurity funcionando
Una forma de aprender cómo funcionan, no solo los ataques de SQL Injection, sino todas las técnicas de Hacking Web Technologies, e incluso se pueden ver los ataques Client-Side que pasan por un servidor web, y como un WAF puede ir trabajando sobre ellos para protegernos es éste. Aplicando a diferentes tipos de ataques en plataformas como DVWA se puede aprender y mucho. Siempre pensando en el ataque y en la protección. En la vida real te encontrarás protecciones y tendrás que conocer cómo funcionan para poder aplicar bypasses. Eso lo dejamos para otra historia.
Saludos,
Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root", “Pentesting con Powershell”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica. 
Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox
Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox |
| Contactar con Pablo González |
No hay comentarios:
Publicar un comentario