En la aventura de hoy vamos a instalar un entorno de producción Web sencillo. Tan sencillo, que no me voy a preocupar por lo que debo instalar de software base, servidor Web, base de datos, php, extensiones, etc. Simplemente voy a pedir a los señores de Microsoft que quiere instalar un Joomla, y que "su informático" haga el resto.
Al más puro estilo WAMP (Windows Apache Mysql PHP) pero usando la potencia que nos ofrece IIS nativo.
Todo en el mundo de la informática parece que gira últimamente a la desaparición del informático en la empresa, por lo que nos debemos situar en el lado de los que preparamos los sistemas de automatización, y no en el lado de la "víctima" que se va a quedar sin empleo...En unos pocos años nadie va a instalar sistemas operativos en sus empresas, los alquilaran en la famosa nube, por lo que prefiero subirme a ella !!!.
Para eso nos ponen disponible Microsoft Web Platform Installer 4.6. El proceso es tan sencillo como seleccionar el entorno o producto que queremos instalar, descargar el instalador, y listo.
Una vez instalado Platform Installer podremos seleccionar posteriores añadidos de la lista disponible.
Una vez instalado, compruebo que la versión de Joomla que instala está algo caducada...
*** Web Platform Installer es mucho más que un gestor de descargas e instalación. Podemos crear nuestros propios empaquetados, para ofrecer a nuestros clientes todo el despliegue de un aplicativo, incluyendo la infraestructura base y la aplicación en si.
Otra opción muy interesante es la de conectar a nuestra nube pública en Azure con este servicio, y permitir a nuestros usuarios añadir estas aplicaciones a las máquinas virtuales existentes, y no como ahora que debíamos agregar una máquina virtual nueva previamente configurada.
Por último, junto a las capacidades de Virtual Machine Manager podemos usar opciones offline para distribuir nuestras aplicaciones a las nuevas máquinas virtuales.
Espero poder avanzar con estos aspectos en posteriores post.***
El siguiente paso que debemos ejecutar es instalar, mediante el role de Internet Information Services las extensiones y filtros ISAPI.
Ahora que tenemos nuestro portal Joomla preparado, vamos a probar varias URL´s con pinta maliciosa, como www.mihost.com/cmd.exe /../ select * etc. Vemos que no disponemos de ningún sistema para protegernos contra este tipo de solicitudes. Aquí es donde entra el Web Application Firewall o WAF. Como su nombre indica, se trata de un firewall, un sistema de protección, que nos proteja de peticiones maliciosas.
Lo recomendable sería securizar la propia aplicación web, pero de esta manera evitamos en la medida de lo posible (según las reglas del WAF) ataques webs no comunes, o no identificados bajo nuestras plataformas CMS o similares. Otra cuestión es la disuasión. Si tenemos un ataque y nos presentamos con "un palo gordo" al estilo policía, seguramente el atacante desistirá a las primeras de cambio.
Para esta prueba vamos a usar un WAF para Windows software libre llamado AQTRONIX
La instalación es tan sencilla como bajarnos el paquete para nuestra versión de IIS y ejecutar el .msi o el fichero VBS de configuración.
Sin más pasos, podemos observar como en las mismas peticiones malintencionadas, obtenemos el mensaje del "policía con el palo" prohibiendonos el acceso.
Me gusta cambiarle el aspecto a las cosas, por lo que bajo C:\Program Files\AQTRONIX Webknight edito el fichero Denied.htm para cambiar el mensaje a uno un poco más del estilo de Inseguros.
Podemos redirigir al usuario a una web en concreto, interna o externa. Aquí es donde tendría gracia redirigir al atacante a una web por ejemplo Browser autoPwn con Metasploit, para atacar al atacante, pero sospecho que por motivos legales no podemos...
En el fichero de configuración podemos configurar exclusiones para directorios administrativos, ip´s, virtual host y demás configuraciones que imaginemos para poder "granular" el ámbito de aplicación "del palo".
Una interesante es bloquear permanente (durante las horas que hayamos definido) tras n intentos erróneos.
También podemos gestionar una lista estática de Ip´s introducida a mano.
Podemos configurar una ruta distinta para el fichero de log´s, o enviarlo a nuestra herramienta de SIEM o syslog.
Podemos definir una directiva para prohibir los ataques de fuerza bruta contra nuestro sistema de autenticación.
Hay un sinfín de opciones sencillas, desde longitudes de peticiones, navegadores, directorios, usuarios, extensiones de archivos, caracteres codificados y todo o casi todo lo que te imagines controlar sobre un aplicativo web.
La propia aplicación WAF nos acompaña de un gestor de logs para visualizar facilmente los accesos y acciones del sistema.
Vamos a ver como se ve desde fuera, la parte del atacante. Para ello voy a lanzar WAFW00F un script muy útil para identificar WAF.
Y por último voy a lanzar el script NSE de NMap para el mismo propósito.
Revisando el código del script podemos ver que respuestas está interpretando el script para determinar la presencia de nuestro WAF.
match = function(responses)
for name, response in pairs(responses) do
if response.header.server and string.find(response.header.server, 'WebKnight/') then --
stdnse.print_debug("%s WebKnight detected through Server Header.", SCRIPT_NAME)
webknight.version = string.sub(response.header.server, 11)
webknight.detected = true
return
end
if response.status == 999 then
if not webknight.detected then stdnse.print_debug("%s WebKnight detected through 999 response status code.", SCRIPT_NAME) end
webknight.detected = true
end
end
end,
Vamos a hacerle caso al script, y vamos a cambiar el código de respuesta http que muestra por defecto 999 para intentar evadir la detección.
Nmap deja de ser tan eficaz.
Sin embargo WAFW00F sigue detectando el sistema WAF.Pruebo a cambiar el Title Html del Denied.htm, algo muy básico, pero tampoco consigo borrar su huella ( al menos no lo pone en la pestaña del navegador). Vamos a modificar la respuesta, en vez de enviar directamente el contenido del fichero Denied,htm, hacemos una redirección.
BINGO, ya pasamos desapercibidos por las herramientas de detección más habituales ( Backtrack inside).
He probado con otro script de la gente de Insinuator TSAKWAF y detecta la presencia de un WAF, pero no consigue identificarlo.
Viendo las respuestas HTTP y la redirección del contenido se identifica claramente que el fichero de respuesta es Denied.htm, por lo que este análisis debería ser añadido al script NSE para detección. Nosotros que somos "ansin" podemos cambiar el fichero htm por defecto y usar otro, por si mejorar el script NSE :-)
Otra de las ventajas es la sencillez de actualización. Solo tenemos que cambiar los ficheros dll y sobreescribir el fichero Robots.xml con todos los datos públicos que se van actualizando, como blacklist, user-agent conocidos, técnicas de evasión etc.
Si queréis ampliar sobre los WAF, un punto de partida interesante es OWASP.
Otro documento muy interesante es un Paper sobre los criterios a tener en cuenta a la hora de elegir sobre nuestro sistema WAF. Muy importante el primer punto, la sencillez del despliegue.
Como habéis podido observar, instalar este sistema y configurar unos parámetros básicos nos ha tomado unos 5 minutos. Con el mismo Internet Information Services podríamos configurar muchos de los aspectos del WAF, pero el trabajo sería enorme, y muy dificilmente sostenible.
Como siempre, espero que os guste, sigo en el paro, y gracias por leerme !!!