miércoles, 10 de julio de 2013

Post personal.Si estás a dieta no me leas. Vacaciones !!!!

Amigos de Inseguros. Hace unos meses publiqué una encuesta para intentar mejorar, en la medida de lo posible, mi aventura bloguera. He aprendido mucho de vuestros comentarios, sugerencias y críticas.

Una de las cosas que más me demandabais era conocer aspectos personales mios. Imagino que simple curiosidad.

Aprovecho este post para disculpar mi ausencia de post porque...me voy de vacaciones !!! Aunque como sabéis llevo 3 meses en el paro, pero necesito vacaciones xD.


Es curioso pero no creáis que tengo mucho tiempo libre. Durante estos 3 meses de paro, he escrito 37 artículos técnicos en Inseguros. Si soléis leerlos, no se si os hacéis cuenta del trabajo que lleva montar los laboratorios, documentar de la mejor manera los procesos, aportar algo de valor con mi experiencia etc etc.

Aparte de escribir artículos, durante estos 3 meses me he dedicado a formarme un poco, una miaja decimos en Murcia. Me certifiqué en ITIL última versión, para dar algo de "formalidad" a los procesos de gestión en la administración de sistemas. Como técnico que me considero, me he certificado de MCSA de Windows Server 2012. Tres exámenes. Ni muy difíciles ni muy fáciles. Todo reside en las horas de laboratorios que le dediques, y la experiencia que tengas. He tenido suerte ya que me certifiqué con el mismo título hace más de 10 años, en Windows 2000 Server, por lo que me ha sido asequible. Mi idea es, si no encuentro trabajo en Murcia, dedicarme hasta septiembre/octubre formándome y certificándome en distintas tecnologías. Quiero hacer el MCSE (dos exámenes más). Comptia Security + y posiblemente me certifique en Vmware.


Creo que después de 16 meses de Inseguros, mas de 150 artículos, ponencias, quedadas etc algo me vais conociendo. Mi vida es muy sencilla. Informática, familia y comida. De la informática no voy a hablar en este post. De la familia decir que para mi son el pilar de mi vida, que todo lo que hago lo hago porque ellos vivan mejor, y que sin mi mujer no sería ni la mitad de lo que soy. Además, como tiene el pelo muy largo, compensamos mi ausencia de cabellera xD. Podría seguir hablando de pelos, porque tenemos 4 gatos...pero corto.

Quería hablaros de la comidaaaaaa !!! que lujo, que pasión, que hambre tengo siempre !!!!
Al ritmo que voy, creo que voy a tener que trabajar de cocinero o camarero, eh !! eh !!
Me gusta mucho cocinar, me relaja, y como soy un gordo mental, pues practico bastante xD.
Una de las cosas que mas me apasiona es la comida asiática.
Para este post quería compartir con vosotros alguna de las recetas que cocino para mi familia. No son fotos preparadas, ni retocadas. Podéis ver los platos de la abuela xD.
Espero que os gusten los platos, al menos, si creéis que están buenos xD Seguro que más de uno esta noche se cene un "chino" xD.
No piloto tanto como 1Gb de información, que nos consta que cocina bastante, pero ahí esta el reto.
Master Cheff Security !!!
Volveré en agosto con más material para Inseguros. Disfrutar de este verano, y darme trabajo !!!!
Si alguien está interesado en cocinar estás cosas, puede contactar conmigo para lo que necesite. Nos leemos !!












lunes, 8 de julio de 2013

Certificate Services en Windows Server 2012 r2 Parte 3

Seguimos hablando de Certificate Services en Windows Server 2012 R2, después del éxito mundial de los artículos uno y dos

Cuando hablábamos de organizaciones con diferentes sedes y la posibilidad de implementar una estructura compleja PKI basada en distintas CA subordinadas halábamos de rendimiento. Al publicar los servicios de Certificate Services dentro de Active Directory estamos extendiendo el esquema AD por ejemplo las propiedades del usuario, con información acerca de sus certificados. Esta información se va a almacenar también en el catálogo global (leíste la seria de artículos sobre FSMO y catálogo global?).También debemos estar en comunicación rápida con una entidad emisora de certificados para comprobar la validez de los certificados. Tenemos que tener en cuenta esto para calcular el aumento de datos en la replicación entre controladores de dominio, y debemos pensar en establecer distintas CA asociadas a Sitios de Active Directory.

Los equipos que intenta inscribirse en el servicio de Certificate Services para adquirir, renovar o validar un certificado emplean una función denominada DsGetSiteName.
DWORD DsGetSiteName(
  _In_   LPCTSTR ComputerName,
  _Out_  LPTSTR *SiteName
);
Esta función no es nueva, está presente desde  Windows Server 2000 (Normal, antes no existía el concepto de Site) pero es en Windows Server 2012 y los clientes Windows 8 cuando entra en escena para los servicios de Certificate Services. Recordar brevemente que es un Site dentro de Active Directory, es un conjunto de servidores y clientes conectados por un enlace de alta velocidad. Por ejemplo, es una empresa con dos sedes, se debería configurar un Site para cada sede, a nivel de Active Directory (independientemente de la tecnología subyacente de Networking para conectarlas) para optimizar la replicación. El cliente Windows 8 utilizará esta función para saber en que Site se encuentra. A bajo nivel lo que está haciendo es acceder al atributo de Active Directory msPKI-Site-Name que debe estar informado en los atributos del servidor con el role de Certificate Services. Por defecto al instalar Certificate Services no se completa este atributo en el servidor. Podemos hacer una prueba. Ejecutamos Certutil.exe -setcasites para comprobar el atributo de nuestra CA. Nos informa que está en estado Empty, es decir, no hemos configurado el atributo. Volvemos a ejecutar el mismo comando, y al no disponer de varios Sites en esta demo, configura el valor de msPKI para nuestra CA con el valor del Site por defecto de Active Directory.


En el caso de disponer de una infraestructura algo más avanzada, con varios Site Active Directory, el comando para identificar nuestra CA dentro del Site que le corresponde sería: certutil -setcasites -f -config "nombre de la CA" nombre del site.

Una vez que el cliente conoce la ubicación del Site de la entidad emisora de certificados, emplea otra función denominada DsQuerySitesByCost para calcular el coste de acceso a la CA.

DWORD DsQuerySitesByCost(
  _In_   HANDLE hDS,
  _In_   LPTSTR pwszFromSite,
  _In_   LPTSTR *rgwszToSites,
  _In_   DWORD cToSites,
  _In_   DWORD dwFlags,
  _Out_  PDS_SITE_COST_INFO *prgSiteInfo
);
En caso de no haber configurado el atributo msPKI de la entidad emisora de certificados dentro del Site, automáticamente se le proporcionará un valor alto al coste de enlace Active Directory. Típico ejemplo de ubicar una entidad emisora de certificados subordinada para delegación, se mueve el servidor miembro con Certificate Services al Site que le corresponde, pero no se informa de este valor. Los clientes al preguntar el coste del enlace obtendrán el mismo valor para una CA instalada en un Site, por ejemplo local, que para una  CA instalada en un Site a miles de kilómetros. Esto proporcionaría balanceo de carga ya que se comunicará con ambas CA indistintamente. Importante configurar estos parámetros para proporcionar rendimiento.
Podemos comprobar el coste de enlace contra varias entidades emisoras de certificados mediante el comando : certutil.exe -ping "ca1, ca2"

Otra de las funciones que trae bajo el brazo Certificate Services en Windows Server 2012 es la de poder renovar certificados de clientes con la misma clave. Esto agilizada enormemente la administración de certificados. Es posible generar nuevos certificados basados en la misma clave gracias al uso de plantillas predefinidas.

Para no aburriros más con estos conceptos, vamos a seguir configurando nuestra implementación de Certificate Services. Vamos a configurar el componente Web Enrollment para poder solicitar certificados desde el interface Web ( Recuerda https://servidor/certsrv). Para ello debemos configurar el acceso HTTPS. Por defecto se comunica mediante HTTP, por lo que debemos generar un certificado para nuestro servidor http. Lo primero que haremos será entrar al complemento de administración de Certificate Services.


Expandimos la parte de plantillas.


Botón derecho, administrar. En la documentación indica que si no aparece la opción administrar, carguemos el complemento de certificados desde una MMC. Mi recomendación es que dejéis tiempo al sistema, si acabáis de instalar Certificate Services para que se genere toda la estructura y replique con Active Directory. Esta recomendación es extensible para todos los procedimientos que detallamos en el blog. A veces las cosas necesitan su tiempo.


Nos situamos sobre servidor Web y hacemos botón derecho duplicar plantilla ( vivan las traducciones ).


En la pestaña general le vamos a proporcionar un nombre de certificado.


En la pestaña de seguridad le vamos a dar permisos tanto a los usuarios como al equipo que ejecuta Certificate Services para inscribirse. Para ello aparte del grupo de usuarios, debemos seleccionar una cuenta de equipo e indicar el nombre del servidor.



Ahora vamos a configurar las opciones relativas a la identificación del objeto dentro de Active Directory y el uso de DNS.


Una vez definida la plantilla, volvemos a la raíz del complemento de administración de Certificate Services y nos posicionamos sobre Plantillas, botón derecho, y creamos uno.


Ya que tenemos la plantilla para nuestro certificado, vamos a instalarlo. Para ello, en el servidor que tiene instalada la función de Web Enrollment ejecutamos MMC y añadimos el complemento Certificados para el equipo local.


Desplegamos el árbol de certificados y colocándonos sobre Personal hacemos botón derecho, todas la tareas, solicitar un nuevo certificado.


Seleccionamos la directiva de inscripción basada en Active Directory.


Una vez inscrito el certificado para nuestro servidor, es hora de acceder a Internet Information Services y configurar en la rama del sitio por defecto las opciones de bindings o enlaces.


Añadimos un enlace hacia HTTPS o modificamos el actual y configuramos el certificado emitido.


Podemos probar a acceder al servidor CA mediante HTTPS.


Con esto ya tenemos habilitado el acceso mediante HTTPS a nuestro servidor de inscripción web. El proceso para proporcionar comunicación HTTPS a cualquier servidor web de nuestra organización sería el mismo.

Con esto es suficiente por hoy. Como siempre, espero que os guste. Intentaré seguir con los servicios de Certificate Services en Windows Server 2012 y desplegar mas funciones que hagan uso de el.

Gracias por leerme !!!















Google +

domingo, 7 de julio de 2013

Certificate Services en Windows Server 2012 r2 Parte 2

Después de la introducción e instalación básica del anterior artículo, seguimos con servicios de certificados de Windows Server 2012 R2.

En la instalación básica, hemos instalado una entidad emisora de certificados raíz, ya que partíamos de la base de que nunca habíamos usado Certificate Services.

Hay que comprender la base de una infraestructura de clave pública o PKI, la confianza, para comprender todos los demás conceptos subyacentes. Cuando accedemos a un servidor HttpS(Secure) entre otras cosas, el certificado digital lo que hace es garantizar que ese servidor web es quien dice o parece ser, pero quien lo dice? La entidad emisora de certificados. Si la entidad emisora de certificados se llama Casa Real de la Moneda y Timbre de España, suena a serio. Si lo firma Verisign, también suena serio. Dentro de los limites de nuestra organización, los equipos y usuarios confiaran en los certificados emitidos por nuestra entidad emisora de certificados. Cuando un servicio ofrece un certificado como medida de autenticación, como es el caso de las comunicaciones cifradas con IPSEC, el cliente debe poseer un certificado válido de cliente, aparte del certificado válido de servidor, para que este confie en el cliente.


Imaginemos una infraestructura de empresa internacional, con sedes repartidas por todos los continentes. Podría existir una entidad emisora de certificados global para la empresa, por ejemplo CA.empresa.com pero por motivos de seguridad y disponibilidad se delegue la gestión de los certificados a una entidad emisora de certificados subordinada, que se hará cargo de todas las transacciones y validaciones de certificados, por ejemplo repartida por continentes. Una costumbre habitual es desconectar la entidad emisora de certificados raíz para preservar la seguridad de la clave privada raíz. Como veis en la imagen anterior del certificado para https de Google, existe una ruta de certificación que representa la jerarquía empleada por distintas entidades de certificación. La entidad emisora de certificados raíz será siempre la que posea en última instancia un servicio auto-firmado.También informa de la validez del certificado y su caducidad. Os suena la advertencia en los navegadores de esta página no es segura cuando intentamos entrar a un servicios https? Suele ser por la caducidad del certificado o la imposibilidad de validar la "confianza" de la entidad emisora de certificados que expidió el certificado.



En este caso el problema es que Netgear firma su certificado, pero... quien es Netgear en el "world wide web" para que yo confíe en ellos? 

En la instalación básica que hicimos en el primer artículo dejamos la ubicación por defecto para almacenar la clave privada de la CA. Para organizaciones complejas existe la posibilidad de utilizar proveedores criptrograficos externos, elementos hardware, para proporcionar el almacenaje de nuestra valiosa clave privada. Se denominan HSM. No solo almacenan la clave privada, sino que algunos son capaces de cifrar las comunicaciones que así lo requieran, para proporcionar un rendimiento superior al uso de CPU en un servidor corriendo ya un sistema. Un ejemplo de un appliance de Realsec.

Otro dato interesante a tener en cuenta en la ubicación que le demos a la clave privada es el rendimiento. Cuando hablamos de Certificate Services no solo hablamos de certificados, sino de todos los procesos de gestión asociados. Hay varios ficheros, a modo de base de datos (transacciones, datos, logs) implicados en la gestión, por lo que debemos planear la ubicación separada de los ficheros en discos duros rápidos para evitar cuellos de botella en este aspecto, como hacemos con los ficheros de nuestras bases de datos "Oracles, Sql Server y demás". La ubicación de estos ficheros la tenemos en la siguiente rama del registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration


Los ficheros son: 

  • DBDirectory
  • DBLogDirectory
  • DBSystemDirectory
  • DBTempDirectory

El proceso para cambiar la ubicación de los ficheros de la base de datos de Certificate Services implica copiar manualmente el fichero original a su nueva ubicación, detener el servicio, modificar la clave del registro e iniciar el servicio. 

El nombre que le dimos a la CA de ejemplo fue modificado por una regla, no puede tener el mismo nombre NETBIOS ni DNS del servidor. No sé si es un problema con la resolución de nombres o una medida de seguridad extra, pero en el caso de que use una infraestructura PKI de otro fabricante o tecnología, no uses el mismo nombre FQDN para la entidad emisora de certificados para evitar dar más información a un supuesto atacante de la que debiera. Por ejemplo, si tu server se llama CA.miempresa.local la CA puede llamarse ENTIDAD CERTIFICADORA DE MIEMPRESA sin dar más datos.

Importante recordar una regla básica, si en el principio del artículo hablábamos de confianza, no podemos cambiarle el nombre al servidor que alberga los servicios de Certificate Server por las razones obvias que os imaginais: si yo confío en un certificado emitido para "servidor x" no es lo mimos que para "servidor y".

Cuando instalamos un servidor miembro ( no se recomienda instalar Certificate Services en un controlador de dominio) para ser la Raíz CA de la empresa, vamos a tener un problema si queremos mantener este servidor OFFLINE por seguridad. Simplemente el echo de tener más de 30 días el servidor miembro desconectado nos va a generar problemas por la caducidad automática de la clave de la cuenta de equipo dentro del dominio Active Directory. Podríamos instalar la entidad emisora de certificados raíz en un grupo de trabajo, pero no estaríamos usando la capacidades de Certificate Services integradas en Active Directory.

Por hoy es suficiente con Certificate Services en Windows Server 2012 R2. Por cierto, SI, trae botón de Inicio.
Como siempre gracias por leerme y espero que os guste. Atentos a próximas entregas.

***
He empezado la casa por la ventana, instalando el role en el servidor en el primer artículo para que la gente comprenda que se pueden hacer las cosas de varias maneras, leyendo, informándose y haciéndose la cosas medio bien, o haciendo Siguiente Siguiente Siguiente. He aquí la diferencia entre hacer las cosas mal, o medio bien xD
***



Google +