Archivo

Archivo para mayo, 2016

Herramienta de descifrado para el Ransomware TeslaCrypt

jueves, 19 de mayo de 2016 Comments off

Fecha aviso: 19/05/2016

El CCN-CERT avisa a todos los posibles afectados por el Ransomware TeslaCrypt que tienen a su disposición una herramienta de descifrado desarrollada por la compañía ESET. En concreto para las variantes v3 o v4 de este código dañino diseñado para instalarse en el sistema, comunicarse con un dominio de Internet, cifrar ciertos archivos y extorsionar a la víctima mostrando una notificación con el procedimiento de pago para rescatar los archivos cifrados.

Si los archivos de su organización cifrados tenían las extensiones .xxx, .ttt, .micro, .mp3 o no tuvieron cambios, la herramienta de ESET gratuita consigue descifrar los archivos afectados por estas variantes.

Al parecer, los analistas de ESET consiguieron la clave maestra universal de descifrado de este Ransomware lo que les ha permitido desarrollar la herramienta.

El CCN-CERT desea señalar que el Ransomware es, a día de hoy, una de las ciberamenazas más detectadas por lo que es necesaria una correcta prevención frente a este tipo de ataques. En su informe público CCN-CERT IA-01/16 Medidas de Seguridad contra Ransomware pueden encontrar las principales medidas para protegerse de estas amenazas.

Más información:

Comunicado de ESET

Instrucciones para el uso de la herramienta

El CCN-CERT (www.ccn-cert.cni.es) es la Capacidad de Respuesta a Incidentes de Seguridad de la Información del Centro Criptológico Nacional, CCN (www.ccn.cni.es). Este servicio se creó en el año 2006 como el CERT Gubernamental/Nacional español y sus funciones quedan recogidas en la Ley 11/2002 reguladora del Centro Nacional de Inteligencia, el RD 421/2004 regulador del CCN y en el RD 3/2010, de 8 de enero, regulador del Esquema Nacional de Seguridad (ENS), modificado por el RD 951/2015 de 23 de octubre.

De acuerdo a todas ellas, es competencia del CCN-CERT la gestión de ciberincidentes que afecten a sistemas clasificados, de las Administraciones Públicas y de empresas y organizaciones de interés estratégico para el país. Su misión, por tanto, es contribuir a la mejora de la ciberseguridad española, siendo el centro de alerta y respuesta nacional que coopere y ayude a responder de forma rápida y eficiente a los ciberataques y a afrontar de forma activa las ciberamenazas.

Categories: Varios Tags:

Internet Information Server: ARR (Application Request Routing)

domingo, 15 de mayo de 2016 Comments off

He estado unos días configurando, con la ayuda del inestimable José Manuel Tella, el servicio de enrutamiento en IIS, de tal forma que nos va a permitir tener un servidor IIS de cara a Internet mostrando el frontend de varios sitios web que vamos a poder tener instalados en diversos servidores de nuestra red interna.

En el servidor que vamos a tener de cara a Internet vamos a montar un Server 2012 R2, y una vez finalizada la instalación del server le añadimos el rol de IIS. En principio le añadí todas sus características, aunque en un servidor en producción podemos afinar más e instalarle sólo aquello que vayamos a necesitar. Así mismo, en las pruebas le instalé un servidor DNS para resolver correctamente los dominios internos, aunque también se puede emplear un DNS ya existente.

Una vez instalado IIS, el siguiente paso es instalar ARR. Para ello lo primero es instalar Web Platform Installer, que podemos encontrar en el siguiente enlace:

https://www.microsoft.com/en-us/download/details.aspx?id=6164 

image 

Tras completar la instalación, abrimos la consola de administración de IIS y veremos que nos ha aparecido un nuevo icono para administrar la instalación de componentes de la plataforma web.

image

Lo ejecutamos y en “Productos” buscamos el complemento “Enrutamiento de solicitud de aplicaciones 3.0” (Application Request Routing 3.0 si el servidor lo tenemos en inglés). Tras la instalación reiniciamos el servicio IIS.

image

En el árbol de la izquierda vemos que nos ha aparecido una rama “Server Farms”, que aunque no es objeto de este artículo, nos permitirá distribuir la carga de trabajo recibida en el servidor web frontend entre varios servidores. La opción que nos interesa ahora es la de “Reescritura de dirección URL”, dentro de la web por defecto.

 image

Una vez estamos dentro de “Reescritura de dirección URL” seleccionamos en “Acciones” del panel derecho la opción “Ver variables de servidor”

image

Y añadimos las dos que muestro a continuación:

HTTP_ACCEPT_ENCODING

HTTP_X_ORIGINAL_ACCEPT_ENCODING

y volvemos a reglas

image

Es el momento de añadir la primera regla, que nos permitirá redirigir las solicitudes http que entren en nuestro frontend con el encabezado “http://www.gericom.es/” al servidor interno 192.168.1.32. Si al añadir la regla nos pide confirmación para iniciar el proxy de enrutamiento, le decimos que sí.

Creamos una regla en blanco, le damos un nombre y le indicamos que la url solicitada coincide con el patrón, usando expresiones regulares y poniendo como patrón (.*)

Con esto conseguimos que lo que se solicite en la url de entrada tras el primer “/” coincida exactamente con lo que se redirige al servidor interno.

En cuanto a las condiciones, le agregamos una de tipo {HTTP_HOST} que coincida con el patrón “www.gericom2.es”. Este es el dominio que tendremos que tener registrado en Internet apuntando a la IP de nuestro servidor web frontend y que vamos a redirigir al servidor interno 192.168.1.32.

En variables de servidor añadimos a la regla las dos que hemos definido anteriormente, como podemos ver en la imagen. Por fin, añadimos una acción de tipo reescribir que apunte a la dirección de nuestro servidor interno

http://192.168.1.32/{R:1} 

image

image

No debemos olvidar pinchar en “Aplicar” para que se guarden los cambios.

Seguidamente creamos una regla de salida en blanco que relacione los nombres de dominio internos (o direcciones ip del servidor interno) al nombre de la url externa que nos habían solicitado. Le ponemos como condición “ResponseIsHtml1”, marcamos todas las coincidencias de contenido y le ponemos como patrón ^http(s)?://192.168.1.32/(.*) y como acción que reescriba a  http{R:1}://gericom2.es/{R:2}

 

image

image

 

Volvemos a crear una nueva regla en blanco, ahora con condición “NeedsRestoringAcceptEncoding”, y los valores que vemos a continuación.

image 

image

Una vez hecho todo lo indicado, veremos que el servidor web enruta las solicitudes que recibe de la dirección “www.gericom2.es” al servidor interno, que las resuelve y las devuelve al frontend para que las devuelva a su vez al cliente que las solicitó. El cliente siempre ve en su navegador que la url coincide con “www.gericom2.es”, y no ve la url o dirección del servidor interno que ejecuta la aplicación web.

Podemos realizar esto para múltiples aplicaciones web soportadas por más de un servidor web interno, añadiendo al servidor frontend tantas reglas de entrada y salida como necesitemos.

Como resultado de lo indicado en este artículo, el web.config del sitio por defecto del servidor frontend queda como sigue:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="ReverseProxyInboundRule4" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Rewrite" url="http://192.168.1.32/{R:1}" />
                    <conditions>
                        <add input="{HTTP_HOST}" pattern="www.gericom2.es" />
                    </conditions>
                    <serverVariables>
                        <set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING" value="{HTTP_ACCEPT_ENCODING}" />
                        <set name="HTTP_ACCEPT_ENCODING" value="" />
                    </serverVariables>
                </rule>
            </rules>
            <outboundRules>
                <rule name="ReverseProxyOutboundRule4" preCondition="ResponseIsHtml1">
                    <match filterByTags="A, Area, Base, Form, Frame, Head, IFrame, Img, Input, Link, Script" pattern="^http(s)?://192.168.1.32/(.*)" />
                    <action type="Rewrite" value="http{R:1}://gericom2.es/{R:2}" />
                </rule>
                <rule name="RestoreAcceptEncoding" preCondition="NeedsRestoringAcceptEncoding">
                    <match serverVariable="HTTP_ACCEPT_ENCODING" pattern="^(.*)" />
                    <action type="Rewrite" value="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" />
                </rule>
                  <preConditions>
                    <preCondition name="ResponseIsHtml1">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                    </preCondition>
                    <preCondition name="NeedsRestoringAcceptEncoding">
                        <add input="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" pattern=".+" />
                    </preCondition>
                </preConditions>
            </outboundRules>
        </rewrite>
        <httpErrors>
            <remove statusCode="404" subStatusCode="-1" />
            <error statusCode="404" prefixLanguageFilePath="" path="http://www.gericom2.es" responseMode="Redirect" />
        </httpErrors>
        <urlCompression doStaticCompression="false" doDynamicCompression="false" />
    </system.webServer>
</configuration>

Categories: Server 2012, Server 2012 R2 Tags: