lunes, 24 de junio de 2013

Vmware Esxi 5.1 Hardening & Hacking casero.

Vmware Esxi 5.1 el Hiper Visor de máquinas virtuales gratuito hasta 32 gigas de ram...
En casa he montado un pequeño sistema Host con Esxi 5.1 en un pc clónico con 16 gigas de ram, un procesador I5, 3 tarjetas de red y unos cuantos gigas de HD. Ya había tocado cosas con la virtualización bajo entornos Hiper V y el viejo Esxi 4.0 y pensé montar todos los laboratorios con los que trabajo y escribo esos post que tanto os gustan sobre esta plataforma, y así no cargar tanto el portátil que se queda corto con 3 máquinas trabajando, y aparte, es interesante apagarlo de vez en cuando :-).

Hay muchas guías en Internet sobre su instalación y administración, por lo que no voy a hablaros de las ventajas, usos, guías y demás. Voy a intentar acercar el mundo de la seguridad a esta plataforma, al menos para una implementación básica como es la mía, un laboratorio, así como un despliegue sencillo en una empresa con uno o varios sistemas anfitriones/Host Esxi 5.1

Lo primero que debemos hacer es crear una contraseña robusta. Para estas pruebas con el usuario Root me basta, y confío en mi contraseña fuerte y compleja. Si prefieres habilitar una política de contraseñas robustas puedes editar el fichero /etc/pam.d/passwd y editar la línea password requisite /lib/security/$ISA/pam_passwdqc.so retry=N min=N0,N1,N2,N3,N4 con los valores que deseamos. Cuales son?

RETRY es el número de veces que un usuario se le solicita una contraseña nueva si el candidato contraseña no es suficientemente fuerte.
N0 es el número de caracteres requeridos para una contraseña que utiliza caracteres de una sola clase de caracteres.Por ejemplo, la contraseña sólo contiene letras minúsculas.
N1 es el número de caracteres requeridos para una contraseña que utiliza caracteres a partir de dos clases de caracteres.
N2 se utiliza la contraseña de frase. ESXi requiere tres palabras para una contraseña. Cada palabra en la frase debe ser 8-40 caracteres de longitud.
N3 es el número de caracteres necesarios para la contraseña que utiliza personajes de tres clases de personajes.
N4 n es el número de caracteres requeridos para una contraseña que utiliza caracteres de todas las cuatro clases de caracteres.n partido es el número de caracteres permitidos en una cadena que se reutiliza de la contraseña anterior


Para crear un usuario, otorgarle permisos de una manera gráfica muy descriptiva podemos seguir las siguientes pantallas.






Una de las cosas que he hecho es habilitar el servicio SSH para poder administrar la consola de Esxi en el caso de caídas del algún servicio crítico que no me permita usar el Client.


Entramos en Configuration y en Security Profile en la parte de Services configuramos la manera de arrancar el servicio, indicando que se inicie con el inicio del Host. Con esto ya tenemos acceso SSH al Host Esxi.


En la parte de abajo de Services aparece Firewall. Entramos en sus propiedades y configuramos una regla para permitir solo acceso ssh a través de una Ip concreta o un conjunto de redes. Interesante para limitar el tráfico desde Internet, aunque no tengo expuesto el servicio sino que me conecto por VPN.


Me voy al mundo de las pantallas negras y veo como se ve en mi red local el equipo.


Otra de las cosas que hago es parar el servicio servidor HTTP ya que no voy a realizar ninguna gestión mediante interface Web.


A continuación voy a cambiar el banner del servicio SSH por si las moscas, cosas que me da por hacer. Para ello editamos el fichero /etc/issues con nuestro banner favorito. El editor que lleva Esxi es VI.


De momento no he podido tapar mucho el equipo, pero voy a repasarme Metasploit por si puedo jugar un rato y probar alguna vulnerabilidad. Para ello, como no tengo mucha memoria, entro en Metasploit en mi máquina Backtrack y hago "Search esxi" para ver los módulos.


Uso un módulo específico para lo que estoy buscando, identificar el Esxi.


Lo pilla al momento. Que buena herramienta...
Puesto con Metasploit, lanzo otro módulo que trata de enumerar las características de las máquinas virtuales instaladas sabiendo el password. No es muy atractivo como herramienta de explotación pero si post-explotación en un supuesto de penetrar en un sistema y conseguir la clave. Si estás en una sesión mediante Pivoting no tienes a mano el Client gráfico.



Muestra toda la información de las VM.
Leyendo documentación y foros descubro un servicio denominado MOB que permite navegar mediante interface web por todos los objetos de nuestro sistema, por lo que deshabilito este servicio. Lo podemos comprobar en https://IP /MOB
vim-cmd proxysvc/remove_service "/mob" "httpsWithRedirect"


Vamos a configurar los archivos temporales y sobre todo los Logs del sistema. Por defecto los Logs estarán disponibles solo hasta que se reinicie el servidor, por lo que debemos conectarlos a un servidor remoto syslog o indicarle una ruta persistente dentro del sistema de almacenamiento.

Entramos en Configuration-Storage. En nuestro sistema de almacenamiento disponible hacemos botón derecho, examinar. Creamos un directorio para almacenar los Logs.


Seguimos en Configuration-Advanced Setting y configuramos la ruta de la carpeta creada en la sección ScratchConfig.


Necesitamos reiniciar el HOST para que los cambios surjan efecto.


Vamos a configurar en Configuration-Networking las propiedades de nuestro Virtual Switch para denegar el modo promiscuo para cualquiera de las máquinas virtuales y el cambio de dirección MAC.


Esto es todo lo que he ido probando de aspectos de seguridad de mi ESXi casero, que tengo que decir que me funciona de las mil maravillas.

Como siempre, gracias por leerme y espero que os guste este artículo.



Google +

jueves, 20 de junio de 2013

The Master of Disaster. Parte III FSMO Windows Server 2012.

Empezamos el artículo poniéndonos en situación. Tenemos dos controladores de dominio,uno de ellos alberga todos los roles FSMO. Tenemos una caída irrecuperable de ese servidor, y no tenemos copia de seguridad. Vamos a trabajar.

Vamos a intentar asumir los roles de Active Directory tras la caída del controlador de dominio principal. Lo que debemos hacer es en el controlador de dominio disponible: Entramos en una consola e iniciamos la herramienta NTDSUTIL. Entramos en ROLES, Connections, Connect to server "nombre del servidor destino".  Quit para salir de las conexiones y escribimos Seize Schema Master. Nos hará la típica pregunta de advertencia.


Este mismo procedimiento sirve para transferir los roles, al igual que hacíamos mediante las consolas gráficas. Como estamos en un caso en el que no están disponibles los roles FSMO, nos advierte de la situación y pasa a tomar el control del Role, en este caso el Esquema.


Si todo ha ido bien, debemos tener asumido ese Role FSMO en el servidor destino. Ejecutamos una PowerShell para comprobar la ubicación de los Maestros de operaciones.


Para recuperar/asumir el resto de roles repetimos la acción con Seize Domain Naming Master, Seize RID Master, Seize PDC Master y Seize Infraestructure Master.

Si tienes ciertas experiencia en el mundo de los sistemas, sabrás que esto no es tan bonito, y a partir de una restauración como esta, seguramente tengas problemas con ID de objetos, sobre todo, si se han hecho cambios en Active Directory durante la caída del Server ( en el caso de tener los FSMO repartidos, se pueden efectuar cambios en Active Directory, dependiendo de la partición sobre la que trabajen/role instalado). No es una solución estable al 100%, por lo que debemos realizar copias de seguridad del estado de Active Directory.

En próximos artículos veremos como restaurar objetos concretos en Active Directory mediante otros procesos.

Como siempre, espero que os guste y gracias por leerme.


Google +

miércoles, 19 de junio de 2013

The Master of Disaster. Parte II FSMO Windows Server 2012.

Como hablábamos en el anterior artículo sobre los FSMO de Active Directory, tenemos 5 particiones o maestros de operaciones disponibles en un dominio Active Directory.
Una parte importante de la estrategia de recuperación de desastres de Active Directory es la ubicación distribuida de los maestros, con el fin de proporcionar tolerancia a fallos en el caso de una caída de un controlador de dominio que alberga Maestros de operaciones. Imaginemos un escenario de un dominio con dos controladores de dominio, replicando Catálogo Global. Debemos repartir los Maestros de operaciones entre los dos controladores de dominio.

El primer Maestro de operaciones que vamos a ubicar/mover es el Esquema. Debemos entrar en el complemento Esquema de Active Directory y en la raíz hacer botón derecho Maestros de operaciones. En el caso de disponer un segundo controlador de dominio podremos cambiar su ubicación.


Maestro de nombres de dominio, ubicado en Dominios y confianzas de Active Directory. Realizamos el mismo procedimiento que para el Esquema, nos situamos sobre la raíz del dominio, botón derecho, nos conectamos al controlador de dominio destino y luego cambiar.


Maestro de ID relativo. Emulador de PDC y Maestro de infraestructura podemos configurarlos desde la consola de Usuarios y equipos de Active Directory.


Vamos a comentar un pequeños aspecto del RID Master o Maestro de ID relativos. Esta partición de Active Directory se encarga de identificar cada objeto en el dominio mediante un identificador. Esta asignación de identificadores la realiza reservando bloques de Identificadores en bloques de 500, lo que se denomina RID Pool. Por defecto tenemos disponibles 1 073 741 823 Identificadores disponibles. Cada vez que se incremente el Pool de Identificadores usados en 10 % de esta cuota, tendremos un evento de advertencia en el visor de eventos con el número 16658. Podemos modificar la reserva de Identificadores para el RID master para que la realice en bloques mayores de 500. Esto nos permitirá optimizar el rendimiento de este Maestro de operaciones, ya que deberá realizar esta tarea con menos frecuencia. Para cambiar el valor debemos entrar en la rama de registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\RID Values

RID Block Size

Podemos pensar que el 2 elevado a 30 ID disponibles es más que suficiente para nuestras organizaciones, pero hay que tener en cuenta que por cada objetos borrado y restaurado se crea un nuevo ID. Podemos ampliar un bit más, es decir 2 elevado a 31, 2147483647 ID disponibles mediante el atributo oculto SidCompatibilityVersion. Lo primero que vamos a hacer es visualizar el estado de la asignación de Identificadores mediante el comando: DCDIAG.exe /TEST:RidManager /v


Como podéis ver, aún no hemos consumido apenas ID y tenemos disponibles los 30 bits. Podemos modificar el atributo entrando en el editor LDP.exe. Conectamos con el controlador de dominio que alberga el maestro RID, en examinar pinchamos en modificar, y escribimos el valor como lo veis en la imagen. Esto no se debe hacer si no hemos detectado, mediante eventos o mediante monitorización manual, que tenemos cerca el límite de ID disponibles. Cuando tengamos usados un 90% el sistema nos responderá con un evento . Esta función no es compatible con versiones previas a Windows 2008 R2, y en este caso, debemos tener instalado un Hotfix para poder habilitar ese Bit extra que multiplica por dos el espacio disponible.

El Maestro emulador PDC es el encargado de proporcionar el sincronismo horario entre los controladores de dominio, por lo que debemos sincronizar el servidor que tenga esta maestro instalado con una fuente externa. No es necesario sincronizar externamente el resto de controladores de dominio. Importante, en el caso de mover el Maestro PDC hacia un controlador de dominio, Active Directory no mueve "el servicio de tiempo para los controladores de dominio". Por ejemplo, en un dominio con dos controladores de dominio DC1 y DC2 en el que inicialmente todos los roles están disponibles en DC1, incluido el PDC emulator, si movemos el Maestro PDC hacia DC2, DC2 no será el responsable del tiempo para los controladores de dominio, seguirá siendo DC1.

El Maestro de operaciones el partición de Active Directory que se encarga de dar coherencia a las réplicas de los objetos entre controladores de dominio. Lo hace mediante USNs Update Sequence Numbers. es decir, identificando la "versión" del objeto en base a su actualización. Para forzar la replicación entre controladores de dominio mediante PowerShell, y no gráficamente mediante Sitios y servicios de Active Directory podemos usar Repadmin /Syncall.


Si lo que queremos es ver simplemente el estado de las replicas con fecha y hora, podemos usar el siguiente PowerShell.


Ya tenemos cierta información sobre los maestros de operaciones y sus características principales dentro de Windows Server 2012. Como hicimos al principio del último artículo, vamos a ejecutar una consulta PowerShell para comprobar la ubicación de los Maestros de operaciones.


Con esto hemos movido todos los Maestros desde DC1 que era mi primer controlador de dominio, hacia RDP.

En próximos artículos intentaremos "romper" RDP y dejaremos al dominio huérfano de Maestros de operaciones, para ver si podemos restaurar el dominio en DC1.

Como siempre, espero que os guste el artículo y gracias por leerme.





martes, 18 de junio de 2013

The Master of Disaster. Catálogo Global y FSMO Windows Server 2012.

Para comprender el funcionamiento básico de un dominio Active Directory tenemos que conocer el funcionamiento de los maestros de operaciones, que podríamos definir como particiones que albergan información del dominio.


Es necesario conocer las estrategias de colocación de dichos maestros de operaciones en nuestra infraestructura de dominio para garantizar la disponibilidad de todos los elementos y configurar un acceso ágil y seguro para la replicación entre controladores de dominio.

Los 5 +1 maestros de operaciones disponibles en Active Directory son:

Maestro de esquema. Solo existe uno para todo el bosque.
Maestro de nombres de dominio. Solo existe uno para todo el bosque.
Maestro ID relativo (RID). Disponible para cada dominio.
Emulador PDC. Disponible para cada dominio.
Maestro de infraestructura. Disponible para cada dominio.
Catálogo Global

Al promocionar un servidor a controlador de dominio en una nueva infraestructura, todos los maestros de operaciones recaen sobre ese servidor. Para comprobar la ubicación de los maestros de operaciones en un bosque o dominio podemos usar el comando PowerShell. Netdom Query FSMO.


Otro elemento vital para un dominio Active Directory es el Catálogo Global o CG. El CG es una copia de ciertos atributos de una clase en objetos Active Directory y es el componente encargado de proporcionar validez a los mecanismos de Login del dominio. Cuando examinamos la red para detectar impresoras y equipos, recursos estamos consultando al CG. Cuando tenemos una instalación de Exchange Server y queremos consultar los buzones de un usuario...etc etc etc.

No toda la información del dominio se almacena en el Catálogo Global, no tendría sentido. Se almacena solo una copia de lectura de ciertos atributos "importantes" de nuestro Schema Ldap en entornos multidominio, y una copia de lectura y escritura de atributos completos del dominio en el que se encuentra.


En un bosque o dominio Active Directory puede haber tantos CG como controladores de dominio existan, pero hay que tener en cuenta que la tasa de replicación entre CG es alta, por lo que si bien tener varios CG en un mismo Site garantiza el correcto y rápido proceso de Login de los equipos, estaremos cargando la red de tráfico de replicación de los CG. Pero si es necesario en un entorno multi-site ( varias delegaciones conectadas por un enlace WAN) que al menos exista un CG en cada Site para evitar el tráfico Wan.

El puerto encargado de la comunicación de los CG es el 3268 como identifica el standard LDAP. En caso de usar mecanismos SSL-Ldap las consultas se realizarían al puerto 3269.

Service Name UDP TCP
LDAP

3268 (global catalog)
LDAP

3269 (global catalog Secure Sockets Layer [SSL])
LDAP
389
389
LDAP

636 (SSL)
RPC/REPL

135 (endpoint mapper)
Kerberos
88
88
DNS
53
53
SMB over IP
445
445

Como comentaba más arriba, en entornos multi dominio ( miempresa.com / tuempresa.com) un Catálogo Global ubicado en el controlador de dominio del dominio miempresa.com tendrá cierta información perteneciente al dominio tuempresa.com, pero mentes inquietas... qué atributos?
Imaginemos que habéis seguido la práctica del artículo Dynamic Access para proporcionar un sistema de control documental de nuestros archivos. Imaginemos que extendemos el schema de Active Directory, o simplemente usamos un campo "no habitual" de la ficha de usuario para realizar una clasificación de los ficheros ( recomiendo leer el artículo que os indico ). Seguimos imaginando, y todo esto se efectúa en un bosque multi-dominio. Puede ser que ese atributo de Active Directory no se replique entre Catálogos Globales y tengamos problemas para ver/clasificar documentos entre dominios. Los problemas no van a ser de caída de servicio, sino de aumento de tráfico entre la estación de usuario y el controlador de dominio que ubica el catálogo global completo del dominio en cuestión.

Vamos a comprobar que atributos se están replicando entre CG y como modificar /añadir atributos. Algo peligroso no, lo siguiente, pero es necesario conocer un poco la estructura interna de Active Directory.

Lo primero que vamos a hacer es instalar el Snap In o complemento para nuestra MMC (Microsoft Management Console) de Esquema de Active Directory. Si ejecutamos MMC -> Control + M  no aparecerá disponible este componente para su administración ( al igual que ocurría con versiones anteriores en las que había que instalarlo desde las Support Tools). Para poder añadir dicho complemento debemos registrar la librería mediante: regsvr32 schmmgmt.dll
Ya podemos agregar nuestro complemento a la MMC.


Vamos a comprobar un atributo de la clase USER, denominado Car License que nos permite guardar el número de licencia de conducir de un empleado, para ver si se replica en el Catálogo Global.
Imagina una empresa de nivel nacional de transporte. Mediante el número de licencia de conducir establecemos que los empleados con un número de licencia inferior a 5.000 ( más viejos) pueden ver ciertos documentos y los empleados con un número de licencia superior a 5.001 no pueden ver todos los documentos. Necesitaremos este atributo LDAP replicándose entre Catálogos globales.
Buscamos la clase USER y el atributo, pinchamos botón derecho y propiedades. Añadimos el campo: isMemberOfPartialAttributeSet que es el que identifica que objetos serán replicados entre Catálogos Globales.


Ya sabemos algo más sobre el Catálogo Global y su arquitectura básica. Ahora vamos a comprobar su ubicación. Ejecutamos la consola de administración de Sitios y Servicios de Active Directory.


Expandimos las ramas dentro del Site, hasta llegar al controlador de dominio que queremos habilitar como Catálogo Global y hacemos botón derecho--> propiedades.


Marcando o desmarcando simplemente podemos habilitar/Deshabilitar el Catálogo Global para ese Controlador de Dominio.

Según lo comentado en este artículo, y según el diseño de tu infraestructura A. Directory deberías habilitar al menos un segundo CG en tu dominio.

Espero que os haya gustado este primer capítulo sobre FSMO (Flexible Single Master Operations).

Como siempre, gracias por leerme.





RECON-NG OSINT técnicas legales para descubrir el tesoro

OSINT Open Source Intelligence. Que nombre más cañero !!! Un marco de prácticas y herramientas para recopilar información pública de nuestros "objetivos" en un proceso de Pen Testing. Ya hemos hablado mucho en este blog sobre la necesidad de construir nuestro Test de Intrusión bajo una metodología más o menos formal que incluya todas las fases. La recopilación de inteligencia suele ser la primera fase, y debemos prestar mucha atención. Ejemplo sencillo, sabiendo los gustos musicales y cinéfilos de nuestra "víctima" podremos preparar un mejor diccionario para realizar un ataque de fuerza bruta contra un servicio de red...

Si quieres ampliar tus conocimientos en la fases de Pentesting, en castellano, te invito al recopilatorio que poco a poco voy construyendo.

Hoy vamos a hablar de un framework muy conocido, RECON-NG.
Similar en presentación y comandos a Metasploit. La instalación es tan sencilla como descargarnos el proyecto mediante GIT y ejecutar el script.
  • git clone https://LaNMaSteR53@bitbucket.org/LaNMaSteR53/recon-ng.git
  • cd recon-ng
  • ./recon-ng.py
Una vez ejecutado podemos ver que los módulos se dividen en varias grupos, según la fase de nuestro Test de intrusión.


Vamos a probar un módulo de reconocimiento como use recon/hosts/gather/http/web/google_site para buscar subdominios mediante Google. Ejecutamos info para ver las variables. Escribimos SET "nombre del dominio" y a continuación RUN. Aconsejo dominios, www.miempresa.com es un SUB-dominio, mejor miempresa.com


Otro módulo curioso está orientado para buscar un dominio en www.malwaredomainlist.com usándolo desde modules/recon/hosts/enum/http/web/malwaredomain.py y estableciendo SET dominio y luego RUN.


Otro módulo interesante es comprobar mediante NameCHK, como ya vimos en otro artículo, la disponibilidad de un nick en varias redes sociales y plataformas on-line. El módulo se encuentra en modules/recon/contacts/enum/http/web/namechk.py. Ejecutamos info. y establecemos Set Nickname "kino,,," Run.

Como podéis ver, esta herramienta tiene mucho juego y constantemente están saliendo módulos para distintas búsquedas.

Espero que os guste el artículo, y sobre todo, que probéis los módulos de RECON-NG.


martes, 11 de junio de 2013

The Master of Disaster. Recuperación de Active Directory

Vamos a hablar en este post sobre como restaurar un controlador de dominio en un ambiente Active Directory basado en Windows Server 2012.

La mejor manera para garantizar disponibilidad en nuestras infraestructuras, como contábamos en el primer artículo de la serie, es implementar servicios redundantes. Para mi, sin duda, el servicio de Active Directory, y en este caso, controlador de dominio es básico ya que estableciendo dos controladores de dominio, replican la información entre ellos y en caso de caída, no perderemos todo el trabajo.

En un ambiente como este, no necesitaríamos realizar una copia de seguridad, sino configurar la restauración que queremos realizar, ya que la información de Active Directory de ese controlador de dominio debe estar replicado en un segundo controlador.

El tipo de restauración como podemos llevar a cabo es autoritativa o no-autoritativa. En el caso de la restauración no autoritativa "subiremos " el controlador de dominio a Active Directory, y este recibirá la información de un segundo controlador de dominio. De la manera autoritativa, será se recuperará el estado del primer controlador de dominio, y este replicará de la manera habitual hacia el resto. Importante estos matices. Imaginemos un caso. Se cae un Controlador de dominio el Viernes por la tarde, nadie se da cuenta, y tenemos a un administrador el sábado modificando objetos de AD sobre otro controlador de dominio.
El lunes cuando nos ponemos en marcha, queremos tener esos datos en el "restaurado" ?.

Lo más sencillo es tener Controladores de dominio dedicados, es decir, que no desempeñan ningún otro rol, ni almacenan datos de usuario, es decir, DC puro y duro. Podemos usar versiones Core virtualizadas para minimizar el gasto de hardware. Con Controladores de dominio dedicados, no importa un caída de uno de ellos, simplemente realizamos una instalación basada en la imagen de un controlador de dominio disponible, y elevamos el nuevo servidor a Controlador de dominio, el cual obtendrá su "configuración" A.Directory de la replica.

Seguro que todos estáis pensando que un servidor DC sin ningún otro rol es tirar un poco el dinero... Según los casos xD.

Si queremos restaurar un servidor Controlador de dominio que alberga otro tipo de roles o datos, debemos realizar una copia de seguridad previa y realizar una restauración al igual que hacemos con cualquier servidor. Debemos tener en cuenta que Active Directory no borra completamente los objetos del dominio, sino que los deja en "stand-by" borrados durante 60 días, para evitar borrados no deseados. Para evitar restaurar objetos borrados, el sistema no nos dejará restaurar copias de seguridad de estado de Active Directory obsoletas ( 60 o más días desde su realización).

Cuando realizamos una restauración autoritativa, en la que vamos a restaurar un Controlador de dominio y posteriormente replicar hacia el resto, debemos de tener en cuenta que la copia de seguridad de estado de Active Directory almacena las claves NTLM de los equipos necesaria para su "unión" o participación en el dominio. Esta clave cambia automáticamente cada 7 días, por lo que si la copia de seguridad del DC contiene información NTLM de un equipo, y la fecha de restauración sobrepasa el límite del cambio de 7 días, podemos encontrarnos con problemas a la hora de iniciar sesión los equipos en Active Directory.
En este caso, debemos situarnos en la consola de administración de Usuarios y Equipos de Active Directory, colocarnos sobre el pc que esté experimentando problemas de inicio, y resetear su cuenta.
En el caso de que esto no fuera suficiente, deberíamos borrar el objeto de Active Directory, y unir de nuevo el pc al dominio.


Vamos a realizar una copia de seguridad del controlador de dominio con la herramienta de Backup de Windows Server 2012 y posteriormente realizar una restauración. Para ello, voy a usar el post sobre la instalación del servicio de backup del amigo Roberto de 1gb de información.

Una vez hecha la copia de seguridad de nuestro controlador de dominio, vamos a restaurar desde ese backup. Reiniciamos el servidor y entramos en las opciones de arranque pulsando la tecla F8. Pulsamos la opción de Reparación de servicios de directorio.


Las credenciales que queremos pasar para iniciar sesión deben ser las del administrador del modo de reparación del dominio ( creada en la instalación de AD), no la del administrador del dominio.

Entramos en una consola PowerShell y lanzamos la herramienta de recuperación de Active Directory Ntdsutil con el parámetro "Activate Instance NTDS". Indicamos que vamos a realizar una Authoritative Restore. Una vez aquí, seleccionamos el objeto que queremos restaurar, ya que nos permite resturar solo una parte del dominio, como por ejemplo, un usuario, una unidad organizativa, etc. Para este caso le voy a decir "Restore subtree dc=miempresa,dc=local" es decir, todo el dominio miempresa.local. Lo lanzamos y en unos segundos se restaura el dominio, y al ser autoritativo, se propagará al resto de controladores de dominio en el caso de que los hubiera.

Dentro de las copias de seguridad de estado de Windows Server 2012, necesaría para salvaguardar el estado de Active Directory está carpeta SYSVOL, que contiene scripts de inicio, plantillas de seguridad, G.P.O etc. Esta carpeta se almacen automáticamente como he dicho en la copia de seguridad de estado. Como hemos visto, si hacemos una restauración autoritativa, el contenido de esta carpeta será replicado hacia el resto de controladores de dominio, mientras que si hacemos una restauración no autoritativa, aunque se restaure el contenido de dicha carpeta en el controlador de dominio restaurado, será replicada desde otro controlador de dominio hacia el.

*** Cuando realizamos una copia de seguridad de estado de un controlador de dominio estamos salvaguardando, entre otros, estos elementos:
Registry
COM+ Class Registration database
Boot files
Active Directory Certificate Services (AD CS) database
Active Directory database (Ntds.dit)
SYSVOL directory
Cluster service information
Microsoft Internet Information Services (IIS) metadirectory
System files that are under Windows Resource Protection
Active Directory Federation Services
The volume that hosts the boot files, which consist of the Bootmgr file and the Boot
Configuration Data (BCD) store
The volume that hosts the Windows operating system and the registry
The volume that hosts the SYSVOL tree
The volume that hosts the Active Directory database (Ntds.dit)
The volume that hosts the Active Directory database log files ***

Otra manera de resturar un controlador de dominio, sin utilizar una copia de seguridad es mediante la reconstrucción de roles. Mediante shadow Copy, papelera de reciclaje de Active Directory, proceso Tmbstone, etc. En próximas entregas hablaremos de distintos métodos.

Como siempre, espero que os guste y gracias por leerme.


viernes, 7 de junio de 2013

The Master of Disaster. Estrategias para un plan de desastres. 1 de muchos...

Copias de seguridad !! Si la haces 3 veces aparece un personaje de terror tipo Hollywood y se come tus servidores !!!.

No voy a contaros nada nuevo sobre este tema. Suele ser la asignatura pendiente para muchos de nosotros, administradores de redes y sistemas, y se suele confiar en el criterio de cada profesional para establecer los parámetros de los backups.

Mucha gente piensa en copias de seguridad y backup en casos extremos, por ejemplo, una catástrofe natural, un virus potente que infecta equipos y servidores, una caída de un elemento hardware, como pueda ser un servidor... Si te basas en estos términos para establecer tu plan de copias de seguridad, quizás pienses: Yo soy de Murcia, aquí nunca llueve, y en caso de un incendio de la empresa, no pasa nada porque se pierdan dos días de trabajo. Mi servidor es nuevo, y por lo menos va a durar 5 años sin roturas...
Hemos hablado ya en este blog de la diferencia de hacer las cosas, sabiendo o no. A priori puede que a corto plazo los resultados sean parecidos, pero a largo plazo...


La dependencia que se tiene en las empresas de hoy en día con la tecnología hacen que una parada de servicio de una hora, ocasione perdidas importantes para la organización. Debemos estar preparados, en la medida de lo posible, para hacer frente a todas las adversidades conocidas que se nos pueden presentar en en nuestras implantaciones, y así minimizar el impacto sobre el negocio de una caída. Si se rompe la tarjeta de red del servidor, el informático no tiene la culpa. Pero el informático si tiene la culpa de no haber previsto esta cuestión, y tener instalada una segunda tarjeta. El caso intermedio podría ser el contar en almacén con una tarjeta nueva de repuesto, pero esto implicaría perdida de tiempo.

En el mundo de la consultoría, el humo negro de Lost (Perdidos) y demás profesionales no técnicos se ha impuesto la moda de Plan de continuidad de Negocio, donde la parte de sistemas informáticos cuenta con un gran peso. He visto consultores, relacionados con esta materia, realizar guias de mejora, de las típicas checklist, sin tener ni idea de la organización y sus medios.
Con este post no quiero decir que haya que contratar un servicio de este tipo, ni tan siquiera que prepares un plan a modo manual de calidad, con una estructura formal, índice, objeto, alcance, audiencia, cambios de versión etc. Si lo haces así mejor, pero no es la parte que ahora nos toca. Ahora vamos a hablar de las medidas técnicas concretas para garantizar la continuidad de negocio en el ámbito TIC. Si lo quieres formalizar en un documento ofimático, bien, si lo quieres desarrollar como un procedimiento formal dentro de la empresa, bieeeeeen, pero insisto, lo importante es estar preparado.



Entonces, vamos a empezar a pensar en planes de desastres, más que en copias de seguridad, para cubrir la mayor parte del abanico de posibilidades:

Identificación de activos. Esto quizás sea lo más importante. Tener una lista de recursos, bien sean servidores físicos, virtuales, datos, aplicaciones, procesos administrativos,etc es imprescindible. Como vas a proteger lo que no sabes que tienes?. El típico caso de una pequeña aplicación, que se usa los días 5 de febrero solo los años bisiestos... Podrás haber sufrido un percance, haber restaurado datos y servicios como un campeón, que llegaría ese día 5 de febrero, no funcionará el aplicativo y habrás fallado en tu misión. Es interesante realizar unas encuestas a los trabajadores de la organización, sobre todo si llevas poco tiempo en ella, para identificar elementos susceptibles a ser salvaguardados. Hablo de la típica hoja de cálculo con "valiosiiiiiiiiiisima informacion" que tiene el usuario en su Outlook, y que tú no realizas backup de el....

Tolerancia a fallos en servicios de Networking. DHCP, DNS, Active Directory, Remote Services, etc. Son servicios usados en todo momento dentro de nuestras organizaciones, que no requieren de un Backup clásico para restaurar en caso de accidente. Debemos configurar infraestructuras redundantes, como hicimos aquí con el DHCP, para garantizar el correcto funcionamiento de estos servicios 24/7/365.
Sería interesante, dentro de las posibilidades económicas de la organización, realizar estas acciones, no muy costosas, e incluirlas dentro del plan de contingencia de la empresa.

Seguridad física. Importante documentar las medidas de seguridad físicas implementadas en la organización y elaborar un plan de adecuación. Por ejemplo, imaginamos un CPD bien acondicionado, protegido por una sólida puerta, con una llave, que solo los dos responsables de sistemas tienen en su poder. Llega agosto, ocurre un incidente en el que hay que entrar físicamente al CPD, por ejemplo, por un problema con las baterías de los SAI. El responsable de la llave 1 está en Cancúm y el responsable de la llave 2 está a 800 km de la sede central. Parece una tontería? Esto lo podemos extender a seguridad básica de dispositivos como que en un sitio de publica concurrencia, alguien acceda a una zona restringida y robe un portátil. Ese portátil es el que tiene la aplicación monolítica de Nóminas de la empresa de toda la vida...

Restauración. Imaginémos el caso de un servidor de empresa, en el que realizamos copias de seguridad de todos los ficheros, carpetas de datos, configuraciones de aplicaciones y demás. En caso de una "rotura" del Sistema operativo, o lo que viene siendo una metedura de zarpa, no arranca el servidor. Cuanto tiempo nos va a costar instalar un sistema operativo desde cero, y restaurar los datos?

Política de emergencias. Seguimos pensando en casos disparatados, o no tanto. Una caída de servicio en un aplicativo un sábado a las 18:00 PM. Si es una empresa pequeña o mediana, con un solo responsable de sistemas el teléfono está apuntado en todas las mesas y todo el mundo sabe a quien llamar, pero en el caso de organizaciones con más de un técnico hay que dejar constancia de quienes son los encargados de qué cosas, y no llamar siempre al máximo responsable para solucionar un incidente que podría ser considerado de nivel bajo, y otra persona puede resolver. Contar con los teléfonos de los partners y el horario o el SLA es muy importante si necesitamos ayuda externa. En el momento del incidente lo normal es llamar corriendo. Puede ser que el partner no entienda esa actuación como algo definido en un SLA y que llegue en 10 minutos, el Sr. Lobo, resuelva el problema, y cuando llegue la factura el lunes a gerencia tengas MAS problemas que los ocasionados por la caída... Todas estas cosas parecen triviales,  pero merecen la pena sentar a revisarlas, y trabajar sobre ellas.

BACKUP. No nos vamos a olvidar de las copias de seguridad dentro del plan de desastres de la empresa, pero no olvidemos que es una "pata" más de la mesa. Podríamos contestar estas preguntas, para aproximarnos a una estrategia de copias de seguridad adecuada a la organización:

● ¿Qué importante es el papel de un servidor concreto?
 ¿Qué importancia tienen los datos almacenados en el servidor?
 ¿Son los datos únicoso hay varias ubicaciones disponibles?
 ¿Con qué frecuencia cambian los datos?
 ¿Cuánto tiempo dura cada copia de seguridad?
 ¿Con qué rapidez se necesita la recuperacion de datos?
 ¿Cuántos datos históricos no es necesario almacenar?
 ¿Tiene el equipo los medios necesarios para realizar las copias de seguridad?
 ¿Es necesario almacenar las copias de seguridad fuera del sitio?
 ¿Quién será el responsable de realizar copias de seguridad y sobre todo comprobarlas?


Dentro de las copias de seguridad hay que distinguir entre elementos propios del sistema, como pueda ser la base de datos de usuarios, o datos de usuarios, como puedan ser documentos de hoja de cálculo. Hay que preservar ambos tipos de datos en nuestro plan. Si queremos separar esta visión de copias de seguridad, no sería muy útil la utilización de copias del tipo Imagen completa, ya que estas se suelen hacer en momentos de baja actividad, por la noche, y si bien los datos de Active Directory o sistema en un día no cambian mucho, la perdida de granularidad a la hora de restaurar un dato usado con frecuencia por los usuarios daría como resultado pérdidas de información y tiempo.

Otro caso habitual en las organizaciones es el de ficheros abiertos constantemente, con mucha carga de modificaciones, y encima pesados. Si tenemos un MDB de apoyo para el departamento comercial, que está siendo actualizado constantemente, posiblemente tendremos problemas con nuestra copia de seguridad por estar en uso el fichero. Hablamos de copias de seguridad "echas a mano" como pueda ser un Xcopy *.* /v/e/s en un programador de tareas. Para este tipo de escenarios lo mejor es recurrir a Shadow Copy disponible en los sistemas operativos modernos de Microsoft. De esta manera no solo podemos realizar las copias de seguridad, sino que la restauración por alteraciones indeseadas es prácticamente automática.


Puede ser que os  aburra todo esto, porque todos conocéis este aspecto, el de los planes de contingencia. Lleváis años haciendo vuestras copias de seguridad en la unidad de cintas que comprasteis hace 5 años... Has cambiado las cintas? Es importante la rotación de medios de almacenamiento empleados en las copias de seguridad. Cada organización tiene sus características y sobre todo presupuestos, pero si estás escribiendo tus backups en una NAS o en un disco externo conectado a un servidor, compra alguno más e intercala su uso para garantizar que cuando lo necesites, funcionará. Hay soluciones NAS compatibles con tráfico SMB y NFS con estructuras de disco en RAID por menos de 200€ ( D-Link) que para pequeñas y medianas empresas puede servir como un medio de almacenamiento más para nuestras copias de seguridad. Si quereís aprovechar un sistema antiguo, e instalar un servidor Linux con FreeNas para aprovechar el almacenamiento disponible, no es mala opción, y sobre todo barata. Aquí tienes como iniciarte con FreeNas.

Después de esta introducción a los planes de desastres, en próximos artículos hablaré de copias de seguridad con el servicio de backups de Windows Server 2012, el típico documento de recuperación de Active Directory mediante los FSMO y Ntdsutil, y más cosas que no os podéis perder !!!.

Como siempre, espero que os guste y gracias por leerme.

jueves, 6 de junio de 2013

Tips & Tricks. NIC Teaming en Windows Server 2012.

Vamos a configurar un servidor Windows Server 2012 con dos tarjetas de red como una sola conexión. Las razones son obvias, podemos usarlo para garantizar disponibilidad en el caso de una rotura de una de las tarjetas, o podemos usarlo para aumentar el ancho de banda disponible para nuestras operaciones.


Un concepto sencillo, que hasta ahora requería de cierta complejidad como tener tarjetas de red "buenas" o caras, de un mismo fabricante...

Cuando hablamos de dos interfaces de red me refiero a físicos, no sobre máquinas virtuales configuradas en Hiper V, ya que esta configuración virtual de balanceo, suma incluso port mirroring y demás opciones se realiza en las opciones del VSwitch de Hiper V.

En Windows Server 2012 basta con entrar en el administrador del servidor, marcar el servidor local, y nos muestra el estado de los adaptadores de red y el Teaming.


En la pantalla específica de configuración de Teaming, seleccionamos dos o más tarjetas, solo hasta 32, que queramos configurar, botón derecho, agregar a nuevo equipo.

Le ponemos un nombre al grupo y seleccionamos las propiedades avanzadas.


Debemos configurar el comportamiento de este grupo y lo hacemos en Modo Formación de equipos. Formacion de equipos estática compatible con el standard IEEE 802.3 No requiere configuración adicional del Switch, pero deben estar en Switch diferentes. Usaremos este opción para proporcionar redundancia activo/pasivo y no para sumar la capacidad.Independiente del conmutador, para conectar las tarjetas del Team al mismo Switch y que sume la capacidad .LACP emplea este protocolo y emplea la suma de capacidad.



El resultado del Teaming viene dado por la combinación de estos dos elementos de configuración, por lo que en este escenario vamos a hablar de Formación de equipos estática.

Podemos elegir el Modo de equilibrio de carga entre Hash de dirección y Puerto Hiper V. 

Hash de dirección emplea un hash sobre un componente de red, por decirlo de alguna manera y lo comprueba en los paquetes de entrada y salida para dirigir todo el tráfico hacia el mismo adaptador dentro del TEAM. Esos componentes de red que menciono pueden ser una dirección MAC, en la que coincida el HASH dentro de esa parte de la pila TCP/IP, encaminara el tráfico hacia la tarjeta concreta. La IP también puede ser usada para el balanceo entre tarjetas dentro del TEAM. Por último, se puede usar esta comparación de HASH a nivel protocolo TCP y/o UDP, en el que se comparará el HASH de todo el flujo. Esta opción es la mas granular a la hora de implementar correctamente el balanceo.

Por defecto emplea la comparación de HASH para puertos TCP e ip. La dirección MAC del Team será única, por lo que si se emplea la MAC toda la información entraría hacia un adaptador siempre, por lo que la cantidad total del team de entrada quedaría reducida a la velocidad máxima del adaptador principal. Para las conexiones salientes no tendríamos problemas con el ancho de banda.

Puerto Hiper V lo utilizaríamos para dar soporte a infraestructuras de VM sobre Hiper-V que generalmente contenga más máquinas que adaptadores físicos. Cada puerto Hiper V se conecta con un Team "físico" sin importar la Mac, por lo que si se podrá aprovechar la suma de capacidad de las dos tarjetas. 
El comando Powershell para crear un Team con estas características sería:

Set-VMNetworkAdapter -VMName "Team de tarjetas" -AllowTeaming On

Una vez aceptamos podemos comprobar en la configuración del red que nos aparece un nuevo adaptador.


Para configurar esas opciones que comentaba sobre HASH podemos configurar todo el Teaming con PowerShell. Los parámetros del comando son:


Si observamos las propiedades del adaptador (botón derecho ) podemos observar el conmutador.


Y sin configuramos el Team con la opción de suma de capacidad podemos observar el estado.


Configuramos una nueva dirección IP para el Team y listo.

Espero que os haya gustado este artículo sobre Nic Teaming en Windows Server 2012.
Como siempre, gracias por leerme.