Vuelvo a subir las instrucciones completas en la versión 2, espero les sea de
utilidad.
Se descarga ORACLE Virtualbox desde la liga proporcionada:
http://www.oracle.com/technetwork/es/server-
storage/virtualbox/downloads/index.html
Se procede con la instalación de Virtual Box.
Se descarga la máquina virtual lamp desde la liga:
https://drive.google.com/open?id=0Bz7Tp_tMynwpTVJSZWxYS3RXOHc
Una vez descargada la máquina virtual y después de haber instalado virtual box, se
procede a agregar la máquina virtual, seleccionando el archivo donde se ubica la
máquina virtual, seleccionando la opción agregar del menú Máquina.
Con esto ya se tendrá disponible en virtual box la máquina virtual lamp.
Configuración de Adaptador de Red.
Se configura el adaptador de red virtual de la máquina local con la dirección
192.168.2.4, se selecciona la opción Herramientas globales – Propiedades y se
selecciona VirtualBox Host-Only Ethernet Adapter.
Se selecciona la pestaña Adaptador y se selecciona la opción Configurar
adaptador manualmente, donde se configura la IP 192.168.2.4.
Clonación de VM.
Se procede al clonado de la máquina virtual, dando clic derecho en la máquina que
se cargó previamente y se selecciona la opción clonar.
Se define el nombre de la VM fwmodsecurity y se selecciona el tipo de clonación
el cual se deja en la opción Clonación completa.
Una vez terminado el proceso de clonado la VM fwmodsecurity aparecerá
disponible.
Instalación del Firewall.
En la máquina virtual fwmodsecurity, se procede con la instalación del firewall, se
arranca la vm y se accede con el usuario root y contraseña root en la consola de
Linux.
Se procede con la actualización del sistema mediante la instrucción sudo apt-get
update.
Ahora se procede con la instalación del firewall mediante la instrucción sudo apt-
get install libapache2-mod-security2 libapache2-modsecurity libapache2-
mod-evasive.
Habilitación de Reglas.
Se continua con la habilitación de las reglas de mod_security, para lo cual se copia
el archivo de configuración mediante la instrucción sudo cp
/etc/modsecurity/modsecurity.conf{-recommended,}, para posteriormente
editarlo con sudo nano /etc/modsecurity/modsecurity.conf.
Ahora se procede a la edición del archivo donde se modificarán los siguientes
parámetros:
SecRuleEngine On
SecRequestBodyLimit 32768000
SecRequestBodyInMemoryLimit 32768000
SecResponseBodyAccess Off
Se procede con el guardar los cambios realizados en el archivo.
Instalación de OWASP modsecurity Core Rule Set.
Ahora se realiza la descarga del OWASP modsecurity Core Rule Set, mediante
las siguientes instrucciones.
sudo git clone https://github.com/SpiderLabs/owasp-modsecurity-crs.git
Se realiza una copia de seguridad del achivo modsecurity-crs con el comando sudo
mv /usr/share/modsecurity-crs /usr/share/modsecurity-crs.bak.
Y se reemplaza el archivo modsecurity-crs con el archivo owasp-modsecurity-crs
usando el comando sudo mv owasp-modsecurity-crs /usr/share/modsecurity-
crs.
Ahora se renombra el archivo modsecurity_crs_10_setup.conf.example usando
sudo mv /usr/share/modsecurity-
crs/modsecurity_crs_10_setup.conf.example /usr/share/modsecurity-
crs/modsecurity_crs_10_setup.conf, sin embargo, el sistema marca un error de
que el archivo origen no existe.
Como el único archivo existente en la ruta dada es crs-setup.conf.example, se
decide utilizar este archivo.
Ahora se definen los enlaces entre las carpetas de base_rules y activated_rules de
los archivos .conf dentro de la ruta /usr/share/modsecurity-crs/ utilizando el
comando sudo ln -s /usr/share/modsecurity-crs/base_rules/*.conf
/usr/share/modsecurity-crs/activated_rules/
Utilizando el editor nano ahora se procede a editar el archivo
modsecurity_crs_35_bad_robots.conf.
Se procede a comentar las líneas:
SecRule REQUEST_HEADERS:User-Agent "@pmFromFile
modsecurity_35_scanners.data" \
SecRule REQUEST_HEADERS:User-Agent "@pmFromFile
modsecurity_35_bad_robots.data" \
SecRule REQUEST_HEADERS:User-Agent “(?i:?:c … \
Se continua con la edición del archivo modsecurity_40_generic_attacks.conf.
Y se comenta la línea SecRule
REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|!REQUEST_COOKIES:/_pk
_ref/|REQUEST_COOKIES_NAMES|ARGS_NAMES|ARGS|XML:/* "@pmFromFile
modsecurity_40_generic_attacks.data" \
Ahora el archivo modsecurity_50_outbound.conf.
Y se comenta la línea SecRule RESPONSE_BODY "!@pmFromFile
modsecurity_50_outbound.data" \
Ahora se realiza la edición del achivo security2.con ubicado en la ruta
/etc/apache2/mods-enabled/ utilizando el editor nano.
Y se añaden las siguientes líneas en el archivo:
IncludeOptional /etc/modsecurity/*.conf
IncludeOptional /usr/share/modsecurity-crs/*.conf
IncludeOptional /usr/share/modsecurity-crs/activated_rules/*.conf
Se configura el archivo mod_evasive. usando el comando nano
/var/log/apache2/evasive.log.
Y se modifican los siguientes parámetros:
DOSHashTableSize 3097
DOSPageCount 10
DOSSiteCount 30
DOSPageInterval 1
DOSSiteInterval 3
DOSBlockingPeriod 3600
DOSLogDir /var/log/apache2/mod_evasive.log
Ahora se configura el archivo mod_evasive.log en la ruta /var/log/apache2/.
Se crea el archivo con el comando touch /var/log/apache2/mod_evasive.log.
Y cambiamos el propietario del archivo usando sudo chown www-data:www-data
/var/log/apache2/mod_evasive.log.
Ahora se cargan los siguientes módulos en apache:
sudo a2enmod headers
sudo a2enmod evasive
sudo a2enmod security2
Se reinicia el servicio de apache.
Y se comprueba que se hayan habilitado los módulos.
3. Instalación de HOIC y LOIC.
Ahora se 3 procede a instalar las herramientas HOIC, LOIC en la máquina anfitriona
desde las ligas proporcionadas:
HOIC: http://sourceforge.net/projects/highorbitioncannon/?source=typ_redirect
LOIC: http://sourceforge.net/projects/loic/
Una vez descargados los archivos simplemente se descomprimen y se pueden
utilizar los programas.
Considerar que, si se tiene anti virus o el Windows defender activado, estos
detectaran los archivos de HOIC y LOIC como amenaza, por lo cual es
recomendable desactivarlos durante las pruebas.
4. Pruebas de Funcionamiento de Modsecurity y Ataques a VM’s.
4.1 Comprobación de Instalación de Modsecurity.
Para comprobar de que modsecurity se instaló correctamente se accede al servidor
Apache desde el navegador de la máquina local mediante la dirección IP de la
máquina de Ubuntu server donde está instalado el servidor Apache, se deberá
prohibir el acceso, ya que existe una regla que impide acceder mediante dirección
IP.
Como se puede observar no se tiene acceso al servidor. Para poder permitir el
acceso mediante dirección IP se deshabilita la regla que lo impide, para lo cual se
confirma en el archivo de log modsec_audit.log la regla que está impidiendo el
acceso.
Ahora se procede a editar el archivo modsecurity_crs_21_protocol_anomalies.conf
línea 98, como se indica en el archivo de log.
Se comenta la línea 98.
Se realiza un segundo acceso por IP al servidor apache y en esta ocasión se logra
tener acceso.
4.2 Auditoria de Vulnerabilidades.
Se realiza un análisis de vulnerabilidades a la aplicación mutillidae utilizando la
herramienta ZAP.
Se descarga ZAP desde la liga:
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Y se procede con su instalación.
Ahora se inicia un ataque a la página de la aplicación mutillidae con el siguiente
resultado.
1. Se realiza la revisión de SQL injection (Bypass Authentication) en la página
Login.
Por medio de la herramienta zap se puede hacer un ataque de fuzzing para
poder accesar utilizando un archivo payload para SQL Injection, en el campo
usuario se pueden usar datos de inyección sql como or 1=1 – ó ' and 1=0 --.
2. Ahora se auditará la vulnerabilidad A4 – Insecure Direct Object References –
Cookies, para elevar privilegios de usuario.
Se genera un usuario y por medio de ZAP se revisa la información que se envía
al servidor encontrando un campo llamado csrf-token.
Al momento de hacer log in, revisando la respuesta del servidor se logra obtener
el valor del token, para confirmarlo se crea un usuario adicional y se repiten los
mimos pasos.
Al revisar la respuesta el servidor en el momento del log in del segundo usuario
se logra confirmar que se asigna un dato uid que se incrementa por cada usuario
registrado, con esto se puede cambiar este valor para elevar el privilegio del
usuario que se está intentando firmar en el sistema.
