miércoles, 27 de noviembre de 2013

WebPlatform Installer, Web Application Firewall y técnicas anti-fingerprint del WAF.


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 !!!


miércoles, 13 de noviembre de 2013

Informe de salud de tu sistema y buenas prácticas. Windows version...

Son las 16:00 de un viernes cualquiera. Has terminado todas tus tareas más inmediatas. Tienes varios proyectos a medio o por empezar, pero te da pereza ponerte el viernes a última hora con algo que posiblemente te "enfrasque" hasta las tantas. Ya has visitado todos los blogs que te interesan, como este :-).


No en todas las empresas se cuenta con un sistema de monitorización, y si lo hay, no siempre se encuentra en condiciones. Todos conocemos las herramientas de monitorización de nuestros servidores y clientes Windows, pero siendo sinceros, quien se pone a añadir 20 contadores que no tenemos muy claro que miden, solo porque no nos apetece leer. También es común el echo de pensar que la monitorización de recursos consume recursos, y suele ser una herramienta para resolución de problemas, mas que de prevención... los informáticos somos así !!!.


Podemos llamar desde ejecutar a perfmon /report, para que automágicamente nuestro Windows nos prepare un informe con los típicos contadores que nos ayudará a detectar el buen o mal estado de salud de nuestros recursos administrados por ese equipo.


Los 60 segundos deben estar expresados en grados Fharenheit o en kilogramos por cm. porque tarda un buen rato.




Si quieres profundizar en los contadores y pruebas que realiza.


Otra herramienta bastante útil para esos momentos de no saber que hacer, y que todo va bien, a priori. Best Practices Analizer (BPA).

Desde el DashBoard de Windows Server 2012, bajo la rama Todos los servidores, podemos ejecutar un analizador de buenas prácticas, al más puro estilo Exchange vieja escuela.




Como podéis ver, ejecuta una seria de comprobaciones para los roles o servicios que tiene instalado el servidor, adecuando las pruebas a los mismos. Todas las advertencias o errores informan en detalle de los elementos de configuración. Seguro que hay consultores que solo hacen esto... aunque es un buen punto de partida.


Si queremos profundizar un poco más vamos a sumergirnos en el mundo de Powershell, realmente en la superficie. Si queremos listar el tipo de BPA que podemos efectuar según el role: Get-BPAModel


Si queremos ejecutar alguno en concreto añadimos pipeline Get-BPAModel Model_ID | Invoke-BPAModel  Si no indicamos el ID, realizará las prácticas por defecto de los roles instalados.

Si queremos recuperar cualquier BPA report generado, tanto por GUI como por Powershell, indicamos:


La salida por pantalla es engorrosa, para eso tenemos el GUI, pero si queremos exportarla podemos hacerlo a HTML por ejemplo: Get-BPAResult Microsoft/Windows/DirectoryServices | ConvertTo-Html | Set-Content C:\bpa-ad-insegutos.htm

Podemos elegir entre formatear el texto con tablas, formato OGV, CSV ( | Export-CSVruta)

Interesante programar un scaneo a los servidores y guardarlo como parte de nuestra documentación de gestión del servicio.

Espero que os guste este pequeño truco para obtener de un vistazo la configuración básica de un equipo, buenas prácticas, así como sus recursos y rendimiento medio.

Gracias por leerme.

Buen Viernes !!! :-)

martes, 5 de noviembre de 2013

Introducción a la virtualización. Un mundo XEN .

Recuerdo los tiempos en los que las discusiones sobre tecnologías se basaban en Spectrum o Amstrad. Con el tiempo cambiaron las tecnologías, y se convirtió en Windows Vs Linux. También aburridas, y sobre todo si pillabas a algún amigo ajeno al mundillo...

Ahora la tendencia suele ser discutir entre tecnologías de virtualización. Los hay del bando VMWare, otros confiesan pasión por Hyper-V, algunos predican con el ejemplo con KVM, y tenemos la religión de XENServer con muchos devotos.

Creo que en el mundo en el que vivimos, cambiante, tanto en tecnologías como en puestos de trabajo, conocer la mayoría de opciones de la industria es algo favorable. Cada uno procesará por dentro su propia religión, o no !!! pero el conocimiento nunca ocupa lugar.

Algunos ejemplos laborales que he podido trazar.





En esta mini serie voy a acercarme a la religión de XENServer y XENDesktop, las soluciones de Citrix para la virtualización, tanto de máquinas como de escritorios.

No es nada complejo iniciarse con estas tecnologías, ya que todas tienen en comun el almacenamiento en red, los switchs virtuales, discos duros, aprovisionamiento de recursos, etc.

Para probar las cosas, que mejor que hacerlas, por lo que he instalado un Hypervisor de tipo 1 XenServer 6.2 de software libre !!! Particularmente lo he hecho sobre mi ESXi físico que tengo en casa con un saco de megas y cables. En tu caso podrás usar tambien un equipo físisco dedicado, y no tengo muy claro si un VirtualBox/VMWARE Workstation. Lo probaremos.

Con unos pantallazos tenemos instalado Xen Server con una ip dedicada y almacenamiento local, que para nuestros despliegues es más que suficiente.










Al igual que hacíamos con el VSphere Cliente para ESXi, introducimos la ip del servidor en un navegador y descargamos el fichero con la instalación del componente cliente en nuestra máquina, Xen Center.


Una vez instalado es muy fácil de investigar. Tiene las mismas opciones, aparentemente, que un ESXi o un Hyper-V de casa.

Antes de indagar más en otras cuestiones, voy a crear una máquina virtual Windows 2012, que es para lo que queremos el Hypervisor, para virtualizar máquinas. El proceso es común que al resto de Hypervisores, salvo que la imagen iso de instalación de la máquina la tenemos que montar previamente en una unidad, o bien NFS o bien CIFS ( carpeta compartida en mi portátil, por ejemplo). Esto es más cómodo que en ESXi, ya que tambien podemos usar la propia unidad de DVD del equipo. En ESXi no podemos usar esa unidad física, y tenemos que usar o una unidad NFS ( tenemos que crear un DATASTORE) o copiar directamente la iso hacia un DATASTORE LOCAL. Recuerdo que una vez usada la unidad virtual para la ISO, debemos de "expulsarla" para no tener problemas en un futuro moviendo máquinas entre HOSTS.










En unos minutos tenemos instalado el Hypervisor tipo 1 y una máquina virtual Windows 2012 virtualizada.

Espero que os guste el mini artículo sobre Xen Server.
Gracias por leerme.