miércoles, 29 de abril de 2015

Como crear un Failover Cluster con Windows 2012 R2

Este manual es el primero de tres partes. La primera parte son los pasos para crear un Failover Cluster con Windows Server 2012 R2, y la segunda parte incluiremos un disco de Quorum y en la tercera parte indicaremos los pasos para instalar el SQL 2014 en este clúster.

No voy a detallar los motivos, ventajas e inconvenientes de porque montar Windows Server Failover Clúster, no estoy aquí para juzgar solo para alimentar la locura de haberse convertido en un Admin. Para cualquier detalle sobre el funcionamiento de Failover Clúster, podéis consultarlo en la documentación oficial de Microsoft .  

Como crear un Failover Cluster con Windows 2012 R2

Requisitos: 
  • 2 Nodos: 2 servidores idénticos: con los mismos recursos, las mismas unidades de disco, conexiones de red, etc...
  • SO: Windows Server 2012 R2 Standard es la versión necesaria para montar el clúster
  • Tener el Windows Update al mismo nivel en ambos nodos.
  • 2 tarjetas de red conectadas a dos redes diferentes. 
    • Una interfície para dar servicio
    • la otra para comprobar el estado del clúster (la llamaré Heartbeat).
  • 2 Discos mapeados en las dos servidores. 
    • Un disco lo usaremos para una unidad de Quorum
    • El otro disco será el recurso que queremos mostraremos en el clúster.
  • 5 IPs 
    • 3 IPs en la red de servicio. 2 para los nodos y 1 para la instancia del clúster.
    • 2 IPs en la la red Hearbeat
  • Todo el proceso hay que realizarlo con servidores dentro del dominio y desde una cuenta con privilegios para crear objetos en el Active Directory. 
Configuración de la red: 

Para configurar la red he optado por llamar a las dos interfícies con los nombres:
LAN: para la red que esta conectada al dominio
Heartbeat: para una red privada entre los dos nodos que se usara solo para comprobar el estado.
Una cosa importante a tener en cuenta es la prioridad de las redes. La red de dominio siempre tiene que tener prioridad sobre la red de Heartbeat, ya que los servicios del clúster serán ofrecidos a los equipos del dominio.

Una vez tenemos las dos interficies configuradas, en la ventana de Network Connections apretando la tecla Alt del teclado desplegamos el menú. Clicamos en la opción Advanced > Advanced Settings... 


En la ventana de Advances Settings solo tenemos que mover la red del dominio (LAN) a lo alto de la lista.




Configuración de los discos:

Para poder pasar los test de validación previos a la creación del clúster es necesario que tengamos los discos que van a formarlo presentados y activos en ambos nodos. Para hacerlo solo tenemos que ir a la ventana de Computer Management y en la seccion de Disk Management poner los discos Online y después inicializarlos.




Pasos: 

1. El primer paso es instalar los Features necesarios para montar el clúster. En este caso necesitamos el Failover Clustering en los dos nodos.





2. Una vez instalado el Feature, abrimos la consola y con el botón derecho sobre el Manager clicamos sobre la opción de Validate Configuration... para comprobar que los servidores cumplen los requisitos para crear un clúster. 






3. Indicamos los nombres de los dos servidores/nodos que formaran el clúster.






4. Una vez completada la verificación con todos los checks OK, proseguimos a crear el clúster.


5. Indicamos en nombre que hemos escogido para el clúster y la IP que tenemos reservada.








Y ya tenemos la estructura del Failover Cluser. 



El siguiente paso es crear un disco de Quorum para garantizar la integridad del servicio. Pero eso lo incluiré en el próximo post.

Links:


martes, 24 de marzo de 2015

INCIDENCIA 24/3/2014: Virus Cryptolocker secuestra datos

Esta mañana me he encontrado con uno de esos días "divertidos" de los departamentos de IT.

Alguien ha decidido que era un buen día lanzar un ataque masivo del virus Cryptolocker, como mínimo no lo ha hecho en lunes o en fin de semana, es todo un detalle. Este virus responde a la categoría de ransomware, que básicamente lo que hace es impedir de alguna manera que trabajes o tengas acceso a tu equipo y te fuerza a pagar un rescate para recuperarlo.

El ciclo de vida del virus es el siguiente: 


El usuario recibe un email de un dominio @supportpiece.com con el asunto "carta certificada no entregado a usted" y que tiene que ir a recogerla o pagar una multa de unos 7€ .

08/04/2015 EDITADO: Durante el dia de hoy hemos detectado una nueva oleada del virus enviado desde los dominios @sda-poste.net y @sda-courier.com .

El email parece que se ha colado a traves de la mayoría de los servicios de antispam.


Como es lo mas normal del mundo, la gente hace click en alguno de los links y descarga el virus en cuestión. 

Parece que el ejecutable tambien se les ha colado a la mayoria de antivirus. 

Una vez infectado el equipo, un proceso que cifrará con RSA de 2048bits todos los archivos de Office que encuentre en el equipo y en las unidades de red. 

Allá donde haya pasado el virus cifrando archivos dejará un documento .txt y un .html indicando que te han secuestrado los archivos y que para poder recuperarlos tienes que pagar 299€  a través de un enlace a la red TOR, facilitando las instrucciones para instalar un navegador TOR donde podremos conectarnos y poder pagar el rescate. 


Que hacer como Admin? 

  • Detectar y bloquear los posibles orígenes de los emails.
  • Informar a todo el personal de la empresa que no abran este correo. 
  • Estar a punto para cuando las empresas de antivirus saquen la firma de este nuevo virus y actualizar todos los equipos lo antes posible. 


Y para los equipos ya infectados?

Según parece no queda otra que esperar a la actualización del antivirus para detectar y eliminar el Cryptolocker. 
Para los archivos no he visto ninguna herramienta segura que permita descifrarlos, y las que he visto no tienen buena pinta, así que parece que habrá que tirar de copias de seguridad. 

Como se podría haber evitado?

Por lo que parece, el email se ha colado a través de los antispam y el antivirus ha permitido ejecutarlo, así que las herramientas habituales de prevención no han hecho bien su trabajo. 
Se me ocurren soluciones pero ninguna user-friendly: A parte de sustituir el email por palomas mensajeras o dar manoplas a los usuarios, una buena configuración de las directivas que solo permitiere ejecutar los archivos autorizados podría haber evitado esto.



ANEXO 1:

Solo por curiosidad añado una captura de la web a la que te redirigen para pagar el rescate:


ANEXO 2: 

08/04/2015 EDITADO: Durante el dia de hoy hemos detectado una nueva oleada del virus enviado desde los dominios @sda-poste.net y @sda-courier.com .

27/04/2015 EDITADO: Voy a añadir un listado con los dominios que he detectado que se usan para entregar este ransomware:
@supportpiece.com
@sda-poste.net
@sda-courier.com
@ppt-takip.com
@ppt-takip.net 
@sda-courier.biz 
@sda-courier.nfo 
@sdacourier.net 
@sdacourier.org 
@ptt-esube.com 
@ptt-gonderi.net 
@ptt-gonderi.biz  

viernes, 20 de marzo de 2015

Como gestionar las máquinas virtuales de Java de forma centralizada

No creo que diga ninguna mentira si afirmo que uno de los mayores dolores de cabeza de los Admins son las aplicaciones y webs con módulos de Java. Las directivas de seguridad, la poca integración con las políticas de sistema, el constante cambio de versiones y de criterio convierte en una quimera conseguir que Java se comporte en toda la organización.

Un compañero me ha pasado para el blog el manual que ha creado el para poder gestionar la configuración de Java:

Lo primero que hay que hacer es tener instaladas las versiones de 32 o 64 bits de la Máquina Virtual de Java.

Una vez instaladas las dos versiones, hay que crear el directorio C:\WINDOWS\SUN\Java\Deployment .

Dentro de esta carpeta crear dos archivos Deployment.config y Deployment.properties con los siguientes parámetros:

Deployment.config
deployment.system.config=file\:C\:/Windows/Sun/Java/Deployment/deployment.properties
deployment.system.config.mandatory=true

Deployment.properties
deployment.javaws.shortcut=never
deployment.security.level=MEDIUM
deployment.security.mixcode=DISABLE
deployment.javaws.autodownload=never
deployment.expiration.check.enabled=false
deployment.expiration.check.enabled.locked
deployment.expiration.decision.suppression=true
deployment.expiration.decision.suppression.locked
deployment.expiration.decision=NEVER
deployment.expiration.decision.locked
deployment.user.security.exception.sites=c\:/Windows/Sun/Java/Deployment/exception.sites
deployment.system.security.trusted.certs=C\:\\Windows\\Sun\\Java\\Deployment\\trusted.certs

exception.sites
<URL QUE QUEREMOS AÑADIR COMO EXCEPCION>

trusted.certs
< Este archivo contiene los certificados de cada URL que queremos añadir para confiar. Este se genera en la carpeta c:\Users\<usuario> \AppData\LocalLow\Sun\Java\Deployment\security al entrar en la web y aceptar el Applet Java. Hay que copiarlo en cada equipo. >

Una vez creado la lista de excepciones que permiten que los applets de java se ejecuten, nos encontramos con los molestos mensajes de advertencia al intentar abrirlos. Yo he contado 5 mensajes de advertencia al abrir la consola de gestión de una VNX de EMC, un infierno...


Para evitar que aparezcan mensajes de advertencia como el anterior tenemos que configurar un conjunto de reglas en las que añadiremos todas las URLs que queremos permitir ejecutar sin preguntar al usuario.

Para poder configurar el ruleset tenemos que crear un archivo ruleset.xml y firmarlo con un certificado para poder distribuirlo en todos los equipos.

ruleset.xml
<ruleset version="1.0+">
<rule>
<id location="http://*.lasendadeladmin.com" />
<action permission="run" />
</rule>
<rule>
<id location="https://*.aeat.es" />
<action permission="run" />
</rule>
<rule>
<id />
<action permission="default">
<message>Este applet ha sido bloqueado por Java. Por favor contacte con su departamento de informatica para recibir ayuda.</message>
</action>
</rule>
</ruleset>

El siguiente paso es copiar este ruleset.xml donde tengamos el SDK (pe. C:\Program Files\Java\jdk1.7.0_71\bin) para poder firmar el archivo y empaquetarlo en un .JAR .

Crear Keystore


Antes de continuar, hay que crear un keystore si no lo teníamos creado de antes. Los pasos para crearlo son los siguientes.

> keytool -genkey -keyalg RSA -alias Areasselfsigned -keystore "C:\Program Files\Java\jre7\lib\security\corporatekeystore.jks" -storepass 123456 -validity 9000 -keysize 2048

Donde 123456 es el password para desbloquear el keystore (no confundir con el password del certificado).

Exportamos el certificado con el comando:
> keytool -export -alias Corporateselfsigned -file c:\Corporateselfsigned.crt -keystore "C:\Program Files\Java\jre7\lib\security\corporatekeystore.jks"
Y lo importamos como entidad certificadora (CA) :
> keytool -importcert -alias Corporateselfsigned -file c:\Corporateselfsigned.crt -trustcacerts -keystore "C:\Program Files\Java\jre7\lib\security\cacerts"
El password por defecto es changeit  


Y podemos distribuir el cacerts del equipo que estamos trabajando en los del resto de servidores y equipos, machacando el que pueda existir en el equipo de destino. Hay que copiarlo en la siguiente ruta:
C:\Program Files (x86)\Java\jre7\lib\security (es necesario copiarlo en la de 32bits)

Ahora que tenemos el certificado y ya lo tenemos distribuido en los equipos de destino podemos proceder a crear el paquete de distribución y firmarlo:

Creamos el jar:
> jar -cvf DeploymentRuleSet.jar ruleset.xml

Y lo firmamos con nuestro certificado:
> jarsigner -verbose -keystore "C:\Program Files\Java\jre7\lib\security\corporatekeystore.jks" -signedjar C:\DeploymentRuleSet.jar DeploymentRuleSet.jar Corporateselfsigned
En cada servidor y equipo de destino hay que copiar este DeploymentRuleSet.jar en la carpeta:

C:\Windows\Sun\Java\Deployment

Modificaciones en el ruleset.xml


Si más adelante es necesario modificar el ruleset.xml para añadir más url, hay que añadir las reglas al archivo y volver a crear, firmar y distribuir un nuevo DeploymentRuleSet.jar:
> jar -cvf DeploymentRuleSet.jar ruleset.xml
> arsigner -verbose -keystore "C:\Program Files\Java\jre7\lib\security\corporatekeystore.jks" -signedjar C:\DeploymentRuleSet.jar DeploymentRuleSet.jar Corporateselfsigned