Security Art Work

Tras los comentarios recibidos sobre el post “De que hablo cuando hablo de…”, he creído conveniente dedicar a nuestros lectores una segunda parte del mismo. Me gustaría matizar que en esta ocasión la entrada está más enfocada al mundo legal y normativo relacionado con las TIC. Por otra parte intentaré ser más descriptivo en las definiciones de estos términos. Así que sin más dilación prosigamos con el mundo de los acrónimos TIC:

BCMS/SGCN (Business Continuity Management System / Sistema de Gestión de Continuidad de Negocio): Sistema de gestión definido en el marco de la norma ISO 22301, anteriormente BS25999-1, que se implementa siguiendo el ciclo de Deming también conocido como PDCA (Plan-Do-Check-Act) que comprende la política, la estructura organizativa, los procedimientos, los procesos y los recursos necesarios para implantar la continuidad de negocio en una entidad.

[Read more…]

Supongo que todos nuestros lectores habrán oído hablar de un programa televisivo llamado Gran Hermano. Ese programa en el que un número de individuos entran a una casa en la que serán constantemente grabados y observados las 24 horas del día. ¿Les suena? Bien pues la semana pasada fue la final de Gran Hermano 14, se nombró a la ganadora y se cerró la casa.

Esto me ha hecho reflexionar… Todos los que nunca nos hemos presentado a un casting de Gran Hermano porque no queremos ser grabados las 24 horas del día, no queremos que se escuchen nuestras conversaciones… ¿Lo conseguimos?

Pensemos en un día totalmente normal en la vida de cualquiera de nosotros, ayer, por ejemplo:

“Salgo de casa por la mañana para venir hacia el trabajo y entrando a Valencia quedo registrada en las cámaras de videovigilancia de tráfico; desde que aparco el coche hasta que entro en S2, si paso por la fachada de algún edificio oficial, también seré grabada; y en mi lugar de trabajo hay cámaras de seguridad. Después de mi jornada laboral, si voy de compras, muy posiblemente también sea grabada; incluso si pago con tarjeta quedarán registrados mis datos… Si voy al gimnasio (en muchos de ellos también las encontramos) también puedo ser grabada, si cojo un taxi, (Como comentó Manuel Iranzo en su entrada Regulación de la Videovigilancia) o si voy al cajero automático.”

[Read more…]

(Volvemos a la carga con la undécima entrega de la serie GOTO, que teníamos algo olvidada. Como ya saben, basada en las polémicas instrucciones GOTO de programación. En anteriores ocasiones hablamos de I: Consultores de Seguridad, II: Consultores LOPD, III: Análisis de Riesgos, el IV: Open Source, V: ¿Quién se ha llevado mi queso?, VI: Auditores vs. Consultores, VII: Privacidad vs. todo lo demás , VIII: LOPD a “coste cero” (¿y?), IX: El negocio de la seguridad y X: Periodistas)

Para cualquiera que haya estudiado una carrera universitaria de informática o algún programa educativo similar es evidente que en sus contenidos no se tratan, en la mayor parte de los casos, las tecnologías específicas de fabricantes como Microsoft, CISCO, HP, EMC2 etc. Asimismo, por lo general la formación en materia de seguridad suele brillar por su ausencia, tanto en el ámbito de la gestión (SGSIs, Análisis de riesgos, etc.) como en la parte más técnica (pentesting, análisis forense, etc.). En definitiva, que una vez acabada la fase eminentemente académica y ya de pleno en el mundo laboral, puede ser interesante ampliar los conocimientos, algo que puede hacerse a través de la experiencia a lo largo de los años, autoformación y buenos profesionales en los que apoyarse, a través de formación reglada (esto ya lo vimos el otro día con Joel y hace bastante tiempo publicamos una entrada con certificaciones interesantes) o ambos.

Afortunadamente, para solventar este problema la informática cuenta con un abanico bastante amplio de certificaciones, dirigidas a aquellos profesionales con necesidades específicas en ésta o aquélla tecnología, en éste o aquél ámbito. He de confesar no obstante que yo nunca he sido un gran fan de la formación reglada y menos si es necesario hacer acto de presencia, algo que considero en general una absoluta pérdida de tiempo (evidentemente, no siempre). Lo cual incluye, todo sea dicho, la formación universitaria. Esa es, supongo, una de las razones entre otras de que únicamente disponga de una certificación CISA y una CRISC. La primera la saqué yendo al examen sin haber acabado de leer el temario y la segunda la tengo gracias al programa de grandfathering y evidentemente a mi experiencia en la realización de análisis de riesgos. Voy a serles sincero: no creo que ninguna de ellas me haya aportado absolutamente nada, pero bueno, ahí están; al fin y al cabo, cumplí con los requisitos necesarios para su obtención y tengo totalmente justificadas mis horas de formación.

[Read more…]

Tras la publicación y los comentarios surgidos a raíz del post donde comentábamos una serie de medidas para aumentar la seguridad del CMS WordPress (Securizando WordPress), me di cuenta que la inquietud y el interés en este tema es muy elevado. Por ese motivo queremos recoger en este artículo las recomendaciones que nuestros lectores han realizado a través de los comentarios a lo largo de estas semanas, y además añadir alguna otra que consideramos de interés y que no queremos dejar de compartir. Agradecemos desde aquí la colaboración de los lectores que con vuestros comentarios aportáis un valor añadido a este blog.

[Read more…]

Al hilo de posts anteriores sobre continuidad de negocio (tipos de proyectos, pruebas, aspectos a tener en cuenta, tiempos, UNE 71599/BS 25999, …), hoy vamos a centrarnos en la realización de las pruebas, pero no de planes de prueba de esos que se revisan simbólicamente una vez al año para cumplir con requisitos de auditoría. Hablaremos de porqué hace falta hacer pruebas de verdad.

Y es que si algo tiene que fallar algún día, está claro que fallará durante una presentación en directo, durante una importante migración o, como no, durante una contingencia.

Empecemos por la parte organizativa:

Uno de los grandes errores de los planes de continuidad es tener únicamente una serie de documentos técnicos para restaurar HW/SW. Evidentemente esto no podemos considerarlo como un plan de continuidad TIC (véase este post sobre los tipos de los proyectos: https://www.securityartwork.es/2013/04/04/continuidad-de-negocio-tipos-de-proyectos/) ya que se habrá quedado fuera toda la parte organizativa, pero es una situación que encontramos bastante frecuentemente. Esto suele ocurrir cuando no se aborda la tarea como un proyecto en condiciones, sino que se le encarga al departamento de TI “Hacer un plan de esos por si esto explota. Y rapidito que tenéis más cosas que hacer”.

Pues bien, dependiendo de la naturaleza del negocio, la parte organizativa seguramente será mucho más importante que la parte técnica, ya que de nada sirve documentar como restaurar equipos si no hay un local donde hacerlo, si no hay personal de respaldo, o nadie que pueda tomar decisiones relevantes. Por culpa de este tipo de documentos puede pasar que ante una contingencia se dediquen recursos a recuperar antes la aplicación de gestionar las vacaciones del personal que la centralita de atención al usuario u otras situaciones similares.

Al respecto, además de crear la política y establecer prioridades, se tienen que crear los planes clásicos de continuidad organizativa como pueden ser reubicación de personal, sustitución de personal, contacto con proveedores y clientes, etc., los cuales deben ir acompañados de un Plan de Pruebas. Puede parecer que estos planes al no tener componente tecnológica no pueden fallar, pero fallan, y lo peor, hacen que otros planes no puedan ejecutarse. Puede parecer que un plan de reubicación de personal no puede fallar ya que solo hace falta tener, por ejemplo, comunicación con el CPD de respaldo, pero en el momento de la contingencia podemos darnos cuenta de que necesitábamos una impresora con la que no habíamos contado, que las comunicaciones no son suficientes, que el local no tiene mesas, que sin la libreta del 2º cajón del administrador de sistemas no se puede acceder a X servidor, o que nadie recuerda la IP a la que conectar para hacer una tarea ya que todo el mundo la tenía en favoritos y sus equipos están en la ubicación a la que no se puede acceder.

Por otro lado, además de probar los planes con el fin de buscar errores o detalles que hayamos dejado fuera, las pruebas de la parte organizativa sirven como entrenamiento por si llega el día en que hay que utilizarlos. Para un técnico restaurar un sistema puede ser algo relativamente rutinario, pero seguramente la responsabilidad de activar la contingencia y de empezar a lanzar planes recaerá en alguien que no se dedica a hacer esto frecuentemente. El cómo se actúe durante la primera hora será decisivo para el buen funcionamiento del plan ya que una mala decisión puede retrasar todo el restaurado, por lo que es imprescindible que quien tenga que tomar las decisiones tenga cierta soltura y que conozca perfectamente el plan, y esto solo se consigue practicándolo.

¿Y qué ocurre con la parte técnica?

Si en la parte organizativa lo más importante es probarlo todo para familiarizarse con el entorno y ver que no se han dejado cabos sueltos, en la parte técnica nuestro peor enemigo es el “pues esto tendría que funcionar, peeeero…. Por desgracia hoy en día tenemos un montón de tecnologías que nos deberían facilitar la vida ante una contingencia como pueden ser SAIs monstruosos, cabinas de discos inmensas, virtualización por todas partes, sistemas de alta disponibilidad, grupos electrógenos, etc. los cuales nos dan una (falsa) sensación de tranquilidad que puede hacer cundir el pánico si no todo es tan maravilloso como nos han prometido.

Todo es superseguro pero, ¿cuántos se atreven a cortar la luz del CPD sin avisar a nadie confiando en que los SAIs harán su trabajo y que los aires aguantarán? ¿Tirarías del cable de red del cortafuegos principal confiando en que el secundario balanceará perfecto? ¿Borrarías un servidor crítico tranquilamente sabiendo que según el fabricante del robot de copias en 20 minutos lo tienes restaurado? Si alguien contesta a todo que sí o es un valiente o lo tiene todo muy atado (lo cual efectivamente puede suceder).

En la práctica es relativamente frecuente encontrar copias de seguridad corruptas, lentitud en los restaurados o comunicaciones, backups de configuraciones de electrónica de red desactualizados o scripts de restaurado que ya no funcionan con el último cambio que se hizo, y la única forma de detectar estas situaciones es, una vez más, probar que todo funciona.

Resulta además muy recomendable (por no decir necesario) hacer las pruebas técnicas junto con la parte organizativa ya que, por ejemplo, ni se trabaja igual ni se dispone de los mismos recursos en la oficina y en la ubicación alternativa. Detalles como no tener una copia de los certificados de la VPN o del fichero de contraseñas disponible desde una ubicación alternativa, haber olvidado abrir algún puerto en el cortafuegos, o tener las instrucciones técnicas de cómo restaurar una copia dentro de la propia copia, son situaciones que se pueden solventar muy fácilmente, pero que se tienen que detectar antes… ¡PROBÁNDOLO!

¿Y si montamos un teatrillo?

A alguno le parecerá que esto es cosa de modernos, pero una buena forma de hacer las pruebas de la forma más realista posible es hacerlas sin avisar a nadie y añadir dramatismo teatrero como si algo realmente hubiese pasado (aunque todos sepan que no es así): en lugar de convocar una reunión para ver cómo se planifica la puesta en marcha de los planes, se puede montar un pequeño circo en la oficina un día que nadie lo espere y llegar a escenificar que ha sucedido alguna catástrofe y que el negocio no puede operar normalmente. También se puede activar el plan antes de la hora de entrar a la oficina llamando por teléfono a los implicados en las pruebas para que acudan directamente al centro de respaldo, de modo que a nadie le dará tiempo de “hacer trampas” y llevarse la documentación que necesita en un USB, o enviarse al correo la última versión del fichero de claves que ha olvidado actualizar en el repositorio de backup.

Para los más imaginativos se puede incluso montar un pequeño juego de rol, donde un “master” va lanzando cataclismos naturales sobre el CPD, o hace que los técnicos enfermen misteriosamente a medida que los pobres contingente recuperan servicios, pero eso lo contaremos en otra ocasión.

Esperamos que haya quedado claro que si realmente queremos que un plan de pruebas tenga sentido y queremos ver como funcionaríamos ante una contingencia real, no nos vale con restaurar un servidor de forma muestral, o firmar un contrato con un proveedor que nos garantiza el suministro: hay simular que el negocio no puede operar y no quedarse en pruebas de concepto o soluciones a medias.

Ahora con la llegada del buen tiempo es el momento de que los recién graduados en informática escojan entre las opciones disponibles para seguir formándose. Desde este blog queremos aportar nuestro granito de arena recordando algunas de las opciones disponibles:

• Seguridad de las tecnologías de la información y la comunicación (MISTIC). Máster oficial no-presencial impartido por la UOC junto a profesores de la UAB y la URV. La duración estimada es de 1 año (60 créditos), y aunque los idiomas oficiales son el castellano y el catalán, los estudiantes no-parlantes de este último idioma no tendrán ningún tipo de problema. El precio se sitúa sobre los 4100 €.
• Máster universitario en seguridad de tecnologías de la información y comunicaciones. Máster oficial presencial (viernes tarde y sábados) impartido por la UEM. Al igual que el anterior, son 60 créditos. Para más información, consultar su página web.
• Máster en Seguridad Informática. Máster oficial no-presencial impartido por la UNIR. Cómo todos los anteriores, son 60 créditos. Para más información, consultar su página web.

Por otra parte, existen otras certificaciones no-universitarias que son más que interesantes:

• Offensive Security Certified Professional. Consta del curso “Penetration Testing with Backtrack”, cuya duración y precio es variable. Durante el curso, el alumno tendrá acceso a una red de ordenadores (averiguar cuántos es parte del curso), dónde se practicarán todas las fases de un pentest, atacando sin distinguir entre servidores, máquinas de cliente, y distintos sistemas operativos. Desde la experiencia, es posible sacárselo en 2 meses, aunque depende de lo agobiado que quiera y pueda ir cada uno. Los precios oscilan entre los 750 $ (1 mes) y 1100 $ (3 meses). Una vez finalizado el curso, el alumno tiene un periodo de 3 meses para realizar el examen de certificación, que dura 24 horas y en el que debe hacerse con el control de varias máquinas. Finalizadas las 24 horas, tiene otras 24 horas para realizar y entregar el informe. Un curso extremadamente divertido, dónde dormir no es una opción.
• Cracking the perimeter. Es la versión avanzada del curso anterior. Para acceder es necesario superar unas pruebas de admisión, y desembolsar entre 1200 y 1500 $, dependiendo de si se opta por realizarlo en uno o dos meses. En este caso, la duración del examen es de 48 horas.
• Cursos prácticos también son los ofrecidos por www.securitytube.net. Son cursos prácticos bastante asequibles económicamente. Personalmente, me gustan los de desarrollo en Python y ensamblador. También ofrecen de manera gratuita un curso (sin certificación) de Metasploit.

Y cómo siempre está la opción de la autoformación, de la que se ha hablado largo y tendido. Por suerte hoy día existen multitud de sites que ofrecen CTF (Capture The Flags), máquinas virtuales y multitud de documentación de forma totalmente gratuita y desinteresada.

Entiendo que nos dejamos muchas certificaciones (y muy buenas) en el tintero, pero con esta entrada sólo pretendíamos acercar a la gente al mundillo de la seguridad. Por este motivo, no hemos indicado ninguna certificación que requiera su renovación, como pueden ser SANS, CEH, CISSP, y un largo etc.

Cada día vemos aparecer en el mercado nuevas tecnologías que permiten nuevas formas de desarrollo para la innovación. Sin ir más lejos, en el mundo de la web, la innovación conduce a la popularidad, haciendo que sitios como Google, Twitter y Facebook triunfen.

El principal problema de las nuevas tecnologías es que, aún teniendo la posibilidad de evitar problemas de seguridad conocidos, desafortunadamente, la mayoría de las veces esta no es el objetivo principal, por lo que estos errores se vuelven a repetir una y otra vez. Además de esto, las nuevas tecnologías también tienden a inventar nuevas clases de vulnerabilidad, o nuevas formas para explotar problemas de seguridad conocidos.

Un ejemplo práctico de que lo estoy diciendo es Node.js

¿Qué es Node.js?

El 8 de noviembre de 2009, Ryan Dahl presentó Node.js como un entorno de desarrollo en JavaScript de lado de servidor, totalmente asíncrono y orientado a eventos. Usa el motor de JavaScript V8 de Google, dotando a este entorno de una gran velocidad y agilidad, y sumando además una capacidad de Entrada/Salida realmente ligera y potente. Esto permite construir aplicaciones altamente escalables y escribir código que maneje miles de conexiones simultáneas en un solo equipo. Entre las compañías que usan esta tecnología destacamos LinkedIn, eBay, Yahoo!, Microsoft y nosotros mismos (S2 Grupo).

¿Qué es el V8?

V8 es el motor de JavaScript que Google usa en su navegador Chrome. Un motor normal de JavaScript, interpreta el código y lo ejecuta. El V8 es ultra-rápido, está escrito en C++ y se puede descargar por separado e incorporarlo a cualquier aplicación. Así nace Node.js, cambiando el propósito por el que se creó V8 y usándolo en el lado del servidor.

¿Para qué JavaScript en el lado del servidor?

La meta principal de Node.js es la de proporcionar una manera fácil de construir programas de red escalables. En lenguajes como Java™ y PHP, cada conexión genera un nuevo hilo con su respectiva reserva de memoria. Esto limita la cantidad de peticiones concurrentes que puede tener un sistema. Por ejemplo, un servidor muy común es Apache, el cual crea un nuevo hilo por cada conexión cliente-servidor. Esto funciona bien con pocas conexiones, pero a partir de 400 conexiones simultáneas, el número de segundos para atender las peticiones crece considerablemente. Así pues, Apache funciona bien en entornos clásicos, pero no es el mejor servidor para lograr máxima concurrencia.

Node.js resuelve este problema cambiando la forma en que se realiza una conexión con el servidor. En lugar de generar un nuevo hilo de SO para cada conexión, cada conexión entra en el bucle de ejecución y dispara el evento dentro del “pool” de trabajadores. De esta forma, nunca se quedará en punto muerto, dado que no se permiten bloqueos y no se bloquea directamente las llamadas de E/S, permitiendo así miles de sesiones concurrentes (en un sistema UNIX este límite puede rondar por las 65.000 conexiones).

¿Cuándo usar Node.js?

Node.js está extremadamente bien diseñado para situaciones en la que se espere una gran cantidad de tráfico y donde la lógica del servidor y el procesamiento requeridos sean sencillas para dar una respuesta lo antes posible. Node.js es especialmente bueno en aplicaciones web que necesiten conexiones persistentes con el navegador del cliente. Usando ciertas librerías, en concreto socket.io, puedes hacer que una aplicación envíe datos al usuario en tiempo real; es decir, que el navegador mantenga la conexión siempre abierta y reciba continuamente nuevos datos cuando se requiera. Hay que entender que, aunque se puede usar como servidor de páginas web “clásicas”, no se diseñó para ese fin. Algunos ejemplos de uso:

• Servicios Web que proporcionen APIs RESTful.
• “Timelines” de Twitter.
• Aplicaciones de única página.
• Videojuegos de varios jugadores.
• Aplicaciones tiempo real (Chats, cuadros de mando).

Node.js dispone de un gestor de módulos (librerías, plugins, frameworks) npm (Node Package Manager), que amplían la funcionalidad de este y facilitan tareas. En otro futuro post trataremos de hablar de varios frameworks típicos de Node.js, en concreto de Fusker, que es un firewall de aplicación que previene y maneja una gran cantidad de ataques en Node.js.

Entre estas librerías, destacaremos la ya nombrada Socket.io, que es una librería que nos permite manejar eventos en tiempo real mediante una conexión TCP. Socket.io la cual tiene como objetivo hacer que las aplicaciones en tiempo real sean posibles en todos los navegadores y dispositivos móviles, borrando las diferencias entre los mecanismos de transporte (WebSocket, Adobe® Flash® Socket, AJAX long polling, AJAX multipart streaming, Forever Iframe, JSONP Polling).

Estas comunicaciones se pueden poner detrás de un servidor clásico como podría ser Apache o Nginx tal y como explica Vicente Domínguez en su post.

Un poco de código

Para comenzar, podemos descargar Node.js de la página de la aplicación http://nodejs.org/, para varios sistemas. En mi caso he realizado las pruebas con la última versión (tar.gz) para Linux.

Una vez descargado y funcionando vamos a comenzar escribiendo la aplicación en un fichero js. Editamos un archivo “ejemplo-1.js” y escribimos el siguiente código:

var http = require('http');
http.createServer(function (req, res) {
     res.writeHead(200, {'Content-Type': 'text/plain'});
     res.end('Hello World\n');
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');

Ahora desde la consola lanzamos la aplicación:

$ node ejemplo-1.js

Para los que no estéis familiarizados con JavaScript, existen multitud de tutoriales en internet, no es el propósito de este post explicar línea por línea que hacen los programas. En resumen, vemos que “ejemplo-1.js” crea un servidor que escucha en el puerto 1337 y, ante cualquier petición a http://127.0.0.1 devuelve un texto plano “Hello World”.

En el siguiente post, apoyándome en la presentación que hizo Sven Vetsch (Redguard AG – www.redguard.ch) para el Application Security Forum de 2012, trataré de mostrar cómo pueden afectar las clásicas vulnerabilidades (XSS reflejado, inyección de JS en el servidor, ejecución de código remoto).

Una de las cosas que más le llamó la atención a mi compañero de mesa en la oficina (quién venía de trabajar en el ámbito de la ingeniería industrial), fue la increíble capacidad que tenemos los profesionales del sector de las Nuevas Tecnologías para encadenar siglas en una misma frase, como en la siguiente frase: Las copias de respaldo se hacen en un dispositivo NAS que implementa RAID 5 configurado con cifrado AES de 256 bits, con mantenimiento NBD.

El objetivo de este post es tratar de hacer un pequeño repaso de algunos términos que habitualmente se escuchan en el mundillo de las TIC, los cuales se refieren a aspectos como control de acceso, redes, cifrado, cumplimiento legal, cumplimiento de la normativa, entre otros. Les pido a nuestros estimados lectores que me concedan la licencia de resumirles de un modo breve y sencillo cada uno de estos conceptos:

AD/DA (Active Directory / Directorio Activo): Sistema proporcionado por Microsoft para la gestión centralizada de recursos de red, incluyendo la gestión de políticas aplicables, gestión de usuarios y equipos, sistema de autenticación, etc.

AES (Advanced Encryption Standard): Algoritmo de cifrado simétrico con tamaño de llave de 128 a 256 bits.

[Read more…]

Ahora que la W3C y el IETF están cerrando la normalización de toda la implementación de websockets, no cabe duda de que el futuro RFC6455 está siendo cada vez más utilizado en multitud de plataformas donde la experiencia de usuario es un plus más sobre su oferta de servicios.

El protocolo implementado ya en todos los navegadores permite unas nuevas líneas de comunicación cliente-servidor bidireccionales que desde el punto de vista de la seguridad se deben tener en cuenta. Además, desde la administración de sistemas (que es lo que toco), sí existe la responsabilidad de diseñar una buena arquitectura que ayude a la seguridad de todo el conjunto aunque al final uno queda a merced del buen código del propio desarrollo.

Mirando desde el lado del cliente ya existen en la red ciertos documentos (véase Shekyan Toukharian – Hacking Websocket Slides) de cómo cualquier ejecución no autorizada sobre protocolos embebidos en el navegador, como puede ser javascript, pueden lanzar comunicaciones que vayan por estos canales bidireccionales que proporciona los websockets en background. Todo ello sin el conocimiento del usuario.

Por otro lado, desde el punto de vista del servidor, la perspectiva puede ser otra.

Como la comunicación entre el cliente (navegador) y el servidor es necesariamente directa para mantener esos canales, ciertas instalaciones acaban exponiendo sus servidores sobre los que se soportan los websockets. Realmente esto no sería mayor problema si se realizase correctamente pero sí que lo puede ser cuando dicha exposición, para permitir la comunicación, conlleva que el backend quede alcanzado desde fuera para que los navegadores, y desde ese momento todo Internet, puedan acceder a él.

Los inconvenientes son dos muy claros:

• No es posible la aplicación eficiente de reglas cuando son los navegadores de móviles, navegadores de portátiles y n-mil dispositivos de internet los que tienen que acceder al server vía websockets.
• Multitud de servidores necesitan de extensiones no instaladas en los ISPs para su uso.

La conclusión de estos inconvenientes es que en ocasiones se opta por la exposición directa del backend como ya comentábamos (o la no implementación de websockets, con la renuncia evidente a sus características). Sin embargo, hay multitud de LB (loadbalancers) que SÍ soportan websockets: haproxy, nginx desde hace poquillo, varnish…. y también los hay que hasta la fecha usaban implementaciones más controvertidas: apache con mod_pywebsocket, que no obstante, no es de todos los gustos.

Realmente hay cientos de arquitecturas pero para hoy vamos a elegir como ejemplo Nginx con Node.js y Sockect.io.

Las implementaciones de Socket.io son sencillas. Es autocontenido y el trabajo con sockets del propio Socket.io permite que se pueda optar por un acceso directo contra el puerto del Node.js. No obstante, si el despliegue de Node.js lo hacemos desde el backend (por un tema de intercomunicación y escalabilidad) exponemos un servicio que tal vez no era necesario. La alternativa tal vez podría ser optar por “encapsular”, y por tanto abstraer el acceso al Node.js a través de un segundo dominio y gracias a un nginx por ejemplo.

Nginx nos permite también una exquisita creación de hilos en caso de picos y nos proporciona un buen nivel de abstracción para websockets desde su versión 1.3.x (que no recomiendo porque anda con algún importante bug de seguridad). Así que nos metemos en la 1.4.1 ya que las versiones anteriores no soportan estas comunicaciones.

El proceso es sencillo. Únicamente vamos a necesitar un nombre de dominio adicional a nuestra config (si ya hubiera una). Esto nos permite de forma muy sencilla desmarcarnos del resto de funciones que esté realizando nginx (web, vídeo, etc etc) y usar la funcionalidad de websockets únicamente para ese nombre de dominio (servers en nginx).

Tenemos que crear un upstream para el control de los backends y creamos sock.midominio.es

Al final la implementación sería algo como:

upstream websockets_nodejs {
        server backend:9090;
}

server {
        listen       80;
        server_name  sock.midominio.es;
        root   /usr/local/app/sock/app/webroot;
        keepalive_timeout  512;

        location / {
                proxy_pass  http://websockets_nodejs;
                proxy_redirect off;
                proxy_http_version 1.1;
                proxy_set_header        Host            $http_host;
                proxy_set_header        X-Real-IP       $remote_addr;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header        Upgrade $http_upgrade;
                proxy_set_header        Connection "upgrade";
        }
}

Varias anotaciones:

• server backend:9090: backend es un nombre de /etc/hosts y 9090 es el puerto por defecto donde se levanta nodejs.
• keepalive_timeout: mejor corto que largo por tema de recursos pero si el código no es capaz de controlar la conexión es posible indicar un número superior para evitar algunos comportamientos anómalos.
• El resto de líneas son de manual. Únicamente faltaría indicar en nuestro desarrollo como acceder al server que gestiona los websockets indicando nuestro nuevo dominio y si, todo por el puerto 80.

Con esto acabamos de incorporar un nivel de abstracción más sobre nuestra arquitectura delegando al buen hacer de nginx el control y gestión de las conexiones contra el backend Node.js+Socket.io.

Evidentemente es posible configurarlo sobre SSL sin problemas:

upstream websockets_nodejs {
        server backend:9090;
}

server {
        listen       443;
        server_name  sckts.midominio.es;
        root   /usr/local/app/sock/app/webroot;
        index index.php;
        keepalive_timeout  512;

        ssl                  on;
        ssl_certificate      /etc/nginx/server.crt;
        ssl_certificate_key  /etc/nginx/server.key;

        ssl_session_timeout  5m;

        ssl_protocols  SSLv2 SSLv3 TLSv1;
        ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
        ssl_prefer_server_ciphers   on;

        location / {
                proxy_pass  http://websockets_nodejs;
                proxy_redirect off;
                proxy_http_version 1.1;
                proxy_set_header        Host            $http_host;
                proxy_set_header        X-Real-IP       $remote_addr;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header        Upgrade $http_upgrade;
                proxy_set_header        Connection "upgrade";
        }
}

Ahora en la configuración de vuestro desarrollo deberéis conectar sobre https.
En nuestro entorno de pruebas ha ido de maravilla aunque siempre habrá alguien que podrá apuntar más datos interesantes sobre estas arquitecturas. En ese caso, bienvenido sea.

Siguiendo en la línea de los anteriores posts (Fundamentos sobre certificados digitales, primera y segunda parte), continuamos hablando de firma y certificación digital. En este caso, y a mi ver, siguiendo un orden lógico para la explicación, en la entrada de hoy nos centraremos en la cadena de confianza.

Como ya se comentó en entradas anteriores de este hilo, de cara a emplear o validar un certificado o firma digital, uno de los puntos más importantes es la confiabilidad del mismo, ya que, como se comentó, cualquiera puede generar una clave asimétrica e incluir los campos que desee en el certificado. De nuevo en base a este hecho surge la necesidad de la existencia de Autoridades de Certificación (CA), quienes se encargan de emitir certificados confiables y reconocidos. Pero, ¿como sabemos que el certificado que tenemos entre las manos ha sido emitido por una de estas entidades?

Aunque se comentará en próximas entradas el formato X.509 como estándar de generación de certificados digitales, es importante destacar que, como es natural, dicho formato contiene campos para introducir los datos del emisor (issuer). Es obvio que estos campos nos pueden parecer útiles para este fin; pero del mismo modo que el resto de campos del certificado pueden ser fijados al gusto de quien lo genere, por lo que en absoluto suponen una garantía de procedencia y autenticidad del certificado digital.

Para cubrir estas necesidades surge el modelo de cadena de confianza. Este modelo establece una relación entre certificados que permite asegurar, sin duda alguna, que dicho certificado ha sido emitido por una Autoridad de Certificación. Veamos en primer lugar como se implementa este modelo.

Como algunos habrán adelantado, la solución más obvia será firmar el certificado emitido con un certificado que “represente” a la CA. De este modo, si el certificado que firma es confiable, tenemos total certeza de que el certificado ha sido emitido por una CA, y por tanto quien lo emplea debería ser quien dice ser (siempre y cuando no se vulnere su clave privada, en la próxima entrada veremos de qué mecanismos se vale la CA para revocar y validar certificados, así como cómo dispone esta información al alcance de los usuarios finales de los mismos). Todo esto parece que suena bien, sin embargo, nos sigue dejando en el mismo punto del que partimos, ¿cómo sé que el certificado que firma el anterior es válido?

En el modelo de cadena de confianza jerárquico, las Autoridades de Certificación disponen de un certificado conocido como Certificado Raíz (Root CA), y como su nombre indica es el certificado que validará todos y cada uno de los certificados emitidos por la CA; sin embargo, este certificado no es el que firmará los certificados de suscriptor (o certificados finales), sino se empleará únicamente para firmar los denominados Certificados Subordinados (Sub-CA), y estos últimos firmarán los certificados de suscriptor (o finales). Se muestra un diagrama ejemplo del modelo jerárquico para ilustrar el funcionamiento de la cadena de confianza de certificados:

Es importante destacar que, en general, las Autoridades de Certificación emiten los certificados intermedios orientados a generar certificados de suscriptor en base a distintas tipologías, usos o unidades de negocio (por ejemplo certificados de persona física, persona jurídica, SSL, firma de código, etc.).

Sin embargo, el principal motivo de tomar esta decisión es proteger al máximo Certificado Raíz de la jerarquía. En base a los conceptos explicados en entradas anteriores, si un tercero consiguiera la clave privada de un Certificado Raíz, se comprometerían todos y cada uno de los certificados emitidos con la misma (es más sería capaz de emitir certificados en nombre de la CA). Visto de este modo, cobra sentido que los certificados finales no estén firmados con esta clave; además que en base a éste modelo jerárquico, un certificado de suscriptor firmado por el raíz no sería de suscriptor sino subordinado, con todo lo que conllevaría dar esa clave a un usuario. Este hecho propicia que se considere normalmente la clave privada del certificado raíz como la información de mayor valor y más crítica de la CA. Debido a ello, es habitual que la clave privada del certificado raíz se encuentre offline, en un dispositivo de seguridad cifrado y con medidas de alta seguridad (que también se comentarán en próximas entradas).

De cara a la validación del certificado firmado tanto por el certificado raíz como su subordinado, la CA mantiene online todas las claves públicas de su jerarquía; aunque habitualmente se suelen adjuntar al certificado de suscriptor (como se muestra en el ejemplo posterior). De modo que para validar un certificado de un suscriptor, se deberá comprobar la firma para toda la cadena de confianza de la CA emisora, quedando así clara la procedencia del mismo.

Por último, y siguiendo con la línea de ejemplos planteada en entradas anteriores, se muestra la información de la cadena de confianza del certificado SSL de www.bankia.es, que en este caso ha sido generado por VeriSign, Inc. (autoridad de certificación propiedad de Symantec).

Como se puede observar en la imagen, se describe la jerarquía de certificados de VeriSign que ha generado este certificado se suscriptor. Lo detallamos a continuación:

• Certificado Raíz: VeriSign Class 3 Public Primary Certification Authority
• Certificado Subordinado: VeriSign Class 3 Extended Validation SSL SGC CA
• Certificado de Suscriptor: www.bankia.es

El proceso de validación lo suelen realizar de forma automática los navegadores web, de modo que aunque el certificado no estuviera auto firmado (self signed), si detectara una incoherencia en la cadena de certificación consideraría el certificado no confiable y avisaría al usuario como se detalló en la entrada Fundamentos sobre Certificados Digitales (II).

A modo de curiosidad, dejo unos cuantos enlaces que os ayudarán a ver un ejemplo práctico de jerarquía de certificados, concretamente la de Verisign (Symantec):

• Listado de Certificados Raíz de Verisign: http://www.verisign.com/repository/root.html
• Descarga de certificados Raíz de Verisign: https://www.symantec.com/page.jsp?id=roots
• Listado de Certificados Subordinados de Verisign: http://www.verisign.com/support/verisign-intermediate-ca/index.html
• Jerarquía de Certificados de Verisign: http://www.verisign.com/repository/hierarchy/hierarchy.pdf

Dejo también una entrada referente al escándalo de TURKTRUST, en el que por error se firmaron dos certificados de suscriptor directamente con el certificado raíz, lo que tuvo consecuencias desastrosas: http://www.securitybydefault.com/2013/01/algunas-reflexiones-sobre-el-ultimo-ca.html

Gracias de nuevo por leernos y como siempre quedo a la espera de vuestros comentarios.