Fundamentos sobre Certificados Digitales: Normativa y Legislación propia de Autoridades de Certificación en España (2ª parte)

Seguimos con el análisis de la Ley de Firma electrónica que nos quedó pendiente de la anterior entrada de esta serie (Entrada previa: “Fundamentos sobre Certificados Digitales: Normativa y Legislación propia de Autoridades de Certificación en España (1ª parte)”).

Pasando ya al Título III, está centrado en la regulación de la actividad de los prestadores de servicios de certificación digital, distinguiendo entre las obligaciones requeridas para las autoridades de certificación consideradas reconocidas y las que no; así como la responsabilidad aplicable en cada caso.

El primero de los puntos destacables de este título lo constituyen las obligaciones propias de este tipo de entidades. Se detalla cada uno de los puntos de interés junto a un pequeño resumen a continuación:

  • Protección de Datos de Personales: Los prestadores de servicios de certificación están obligados a cumplir con los requisitos necesarios en amparo de la Ley Orgánica 15/1999 de Protección de Datos de Carácter Personal (en adelante LOPD), así como a su reglamento de desarrollo (Real Decreto 1720/2007) dentro de sus atribuciones y funciones como CA. Adicionalmente, se complementa lo contenido en esta legislación con algunos matices:
    • Los datos de carácter personal que se recopilarán para la emisión del certificado, sea cual sea el nivel de seguridad requerido por la LOPD, se deberán recopilar solicitando el consentimiento expreso al afectado.
    • En ningún caso se incluirán dentro del propio certificado datos especialmente protegidos por la LOPD (Artículo 7 de la misma).
  • Obligaciones de los prestadores de servicios de certificación: En este artículo se fijan las obligaciones comunes a todas las CA, se detallan algunas de ellas a continuación:
    • No almacenar ni copiar cualquier dato relacionado con los certificados expedidos.
    • Facilitar de forma gratuita al solicitante una información mínima previamente a la expedición del certificado (Como las obligaciones del firmante, las condiciones de uso del certificado, etc.).
    • Mantener un directorio actualizado con todos los certificados expedidos, así como su estado de vigencia.
    • Mantener disponible un mecanismo de Validación de Certificados.
  • Declaración de Prácticas de Certificación (DPC): Todo prestador de servicios de certificación deberá emitir una Declaración de Prácticas de Certificación. La declaración de prácticas de certificación debe estar publicada en un medio gratuito y a disposición pública, así como se considerará el documento de seguridad de la CA de acuerdo a lo dispuesto en la LOPD. Así mismo, se detalla el contenido indispensable que debe incluir la DPC, como por ejemplo las obligaciones asumidas con los datos empleados para la creación, las condiciones de uso de los certificados, los mecanismos de validación publicados, etc. La estructura habitual de las declaraciones de prácticas de certificación serán objeto de próximas entradas de esta serie.
  • Obligaciones de los prestadores de servicios de certificación reconocidos: Adicionalmente a los requisitos comunes a todas las los prestadores de servicios de certificación nacionales, se añaden los siguientes requisitos:
    • Demostrar fiabilidad para prestar servicios de certificación.
    • Mantener un registro con fecha y hora exactas de expedición de certificados, así como para su extinción o suspensión.
    • Emplear personal cualificado en seguridad y gestión de servicios de de certificación electrónica.
    • Emplear dispositivos y sistemas criptográficos fiables para los procesos de certificación que soporten.
    • Tomar medidas contra la falsificación de certificados, asegurando la confidencialidad de la información durante todo el proceso de generación y entrega de los mismos.
    • Mantener en un medio seguro todos los datos y documentación requeridos para la generación y gestión de los certificados, así como las Declaraciones de Prácticas de Certificación vigentes en cada momento en un plazo mínimo de 15 años desde su expedición.
    • Emplear sistemas seguros para almacenar los certificados reconocidos, de modo que se pueda certificar su autenticidad si fuera necesario, impidiendo accesos y modificaciones no autorizadas.
    • Por último, todos los prestadores de servicios de certificación reconocidos deberán suscribir un seguro de responsabilidad civil por una cuantía de cómo mínimo 3 millones de euros, para afrontar el riesgo de daños y perjuicios que puedan ser causados por los certificados expedidos.
  • Cese de actividad: Cuando un prestador de servicios de certificación decida cesar su actividad deberá notificarlo a todos los suscriptores (personas físicas o jurídicas) que posean un certificado expedido por dicha entidad. Adicionalmente, y para los certificados que aún tengan vigencia, puede ofrecer transferir su gestión a otro prestador de servicios, siempre con el consentimiento expreso del suscriptor. Se deberá realizar la comunicación de cese con al menos dos meses de antelación. En caso de que no se acuerde una transferencia de certificados, será el Ministerio de Ciencia y Tecnología el encargado de mantener mecanismos de validación de certificados necesarios hasta que expiren.

El segundo gran punto del título hace referencia a la responsabilidad de los prestadores de servicios de certificación. Se resumen brevemente los puntos considerados:

    Responsabilidad de los Prestadores de Servicios: Principalmente, y como resumen, los prestadores de servicio responderán de todos los daños y perjuicios que puedan causar mientras ejercen su actividad. Concretamente, también se les insta a cubrir los daños causados a los suscriptores o terceros por la ausencia o indisponibilidad de los mecanismos de validación de certificados requeridos.
    Limitaciones en la responsabilidad de los Prestadores de Servicio: En este artículo se exime de la responsabilidad al prestador de servicios en casos concretos como, por ejemplo, si cuando se emite el certificado no se ha facilitado información real o completa, o cuando el suscriptor gestiona negligentemente el certificado.

El siguiente punto a tratar es el Título IV, y hace referencia a los dispositivos de creación, y verificación de firma; así como la propia certificación de los propios prestadores de servicios de certificación y la propia certificación de los dispositivos.

En esencia, se requiere el uso de dispositivos criptográficos seguros; este punto se trató en mayor detalle en otra entrada de esta serie “Fundamentos sobre certificados digitales (V) – Dispositivos físicos para gestión y custodia de claves”; donde se tuvieron en cuenta requisitos más restrictivos a los impuestos en esta ley, como los propuestos por el estándar FIPS-130.

Respecto a la certificación de entidades, especifica que la certificación es completamente voluntaria, y deberá llevarse a cabo por una entidad de certificación reconocida. Esta certificación no se requiere, pero puede servir al prestador de servicios para demostrar buenas prácticas aplicadas en la gestión de los certificados digitales.

El Título V hace referencia a la supervisión y control. En este punto se establece que todo prestador de servicios de certificación será controlado directamente por el Ministerio de Ciencia y Tecnología, de modo que podrá realizar las inspecciones necesarias para poder ejercer dicho control. Del mismo modo, y si lo considerara oportuno, el ministerio podría recurrir a terceros independientes y técnicamente cualificados para asistirles en dichas revisiones.

Adicionalmente, el título establece la obligación de informar y colaborar del prestador de servicios de certificación con el Ministerio de Ciencia y Tecnología con toda la información y colaboración necesarias para el desempeño de sus funciones (acceso total a instalaciones, información y documentación).

Por último, el Título VI hace referencia a infracciones y sanciones, estableciendo una clasificación como muy graves, graves y leves; fijando cuantías de las sanciones para cada una de estas tipificaciones. No se entra en detalle de esta sección por considerarse menos relevante para la finalidad del artículo, se refiere a la propia ley para más información.

Para finalizar y como aclaración, en ningún caso la intención de la presente entrada es contener todas las regulaciones incluidas en la Ley de Firma Electrónica, sino dar una idea de cuáles son los principales requisitos y normativa destinada a regular este tipo de actividad en España, así como informar a los usuarios de los servicios de las fuentes de información a su disposición y las obligaciones del prestador de servicio y suscriptor. En caso de que se desee implementar y certificar una Autoridad de Certificación, se refiere directamente al texto literal de la ley. Muchas gracias por leernos como siempre, próximamente nuevas entradas.

Enlaces de Complementarios:
Ley Orgánica 15/1999 de Protección de Datos de Carácter Personal
Real Decreto 1720/2007 de Desarrollo de la Ley Orgánica de Protección de Datos de Carácter Personal

Jugando con Cisco EEM (I)

Habitualmente, solemos monitorizar sucesos en routers (en este caso C1800) mediante traps snmp o agentes que procesan el log y tras evaluarlo, generan acciones. Cisco IOS Embedded Event Manager (EEM) nos da la posibilidad de definir acciones a eventos concretos generados en el sistema.

Por ejemplo, si usamos syslog para detectar accesos privilegiados a un router, tendríamos que tener un script que procese en tiempo real cada línea de log para buscar una cadena similar a “Privilege level set to 15 by“. Una vez detectada, un agente podría abrirnos una alerta en nuestro sistema de monitorización indicando del acceso privilegiado al router.

Una alternativa posible sería definirnos en EEM una entrada que recoja la información del susbsistema syslog y lance una acción al detectar un patrón concreto, en este caso el acceso privilegiado, por ejemplo enviar un trap SNMP o un correo electrónico de aviso.

Entraremos en detalle de EEM más adelante, no obstante, vamos a ver un ejemplo más práctico donde podríamos usar o no EEM. Por ejemplo, queremos disponer de un sistema automático para almacenar de forma periódica la configuración de nuestro router. Para abordar esta tarea, ahora mismo se me ocurren varias soluciones (quizás hay más que desconozco), por ejemplo:

  • Disponer de un script externo que obtiene la configuracion del sistema y la almacena en un fichero de forma periódica. Esto es bastante fácil de hacer, ya sea haciendo nosotros mismos el script, por ejemplo con expect o las librerias de Cisco de Perl, o con aplicaciones ya creadas como Rancid.
  • Usar el comando archive para guardar una copia de la configuración:
  • S2router(config)#archive                                                                                                 
    S2router(config-archive)# path flash:COPIA.txt                                                                                  
    S2router(config-archive)# time-period 1                                                                                         
    S2router(config-archive)# write-memory                                           
    S2router(config-archive)# exit              
    

    Una vez configurado, comienza a guardar copias cada minuto:

    S2router#show  archive                                                          
    
    There are currently 1 archive configurations saved.                             
    The next archive file will be named flash:COPIA.txt-1                           
     Archive #  Name                                                                
       0                                                                            
       1       flash:COPIA.txt-1                                                    
       2       flash:COPIA.txt-2                                                    
       3       flash:COPIA.txt-3                                                    
       4       flash:COPIA.txt-4                                
    
    S2router#dir                                                                    
    Directory of flash:/                                                            
                                                                                    
        1  -rw-    18716748  Dec 16 2008 08:40:28 +00:00  c1841-advsecurityk9-mz.12n
        2  -rw-        2746  Dec 16 2008 08:55:52 +00:00  sdmconfig-18xx.cfg        
        3  -rw-      931840  Dec 16 2008 08:56:14 +00:00  es.tar                    
        4  -rw-     1505280  Dec 16 2008 08:56:36 +00:00  common.tar                
        5  -rw-        1038  Dec 16 2008 08:56:54 +00:00  home.shtml                
        6  -rw-      112640  Dec 16 2008 08:57:12 +00:00  home.tar                  
        7  -rw-      527849  Dec 16 2008 08:57:30 +00:00  128MB.sdf                 
        8  -rw-    21169140  May 26 2010 18:20:18 +00:00  c1841-advsecurityk9-mz.12n              
        9  -rw-        5638  Dec 27 2013 15:58:54 +00:00  COPIA.txt-1                              
       10  -rw-        5638  Dec 27 2013 15:59:52 +00:00  COPIA.txt-2               
       11  -rw-        5615  Dec 27 2013 16:00:36 +00:00  COPIA.txt-3               
       12  -rw-        5615  Dec 27 2013 16:00:52 +00:00  COPIA.txt-4  
    
    
  • Disponer de una tarea periódica configurada en el router para volcar la configuración a un sitio remoto por ejemplo por TFTP o guardarla en flash (que es lo que vamos a hacer). Tenemos que tener en cuenta que cuando ejecutamos algunos comandos, el sistema nos solicita confirmación del mismo, por lo que para automatizar tareas y evitar esto, tendremos que usar el comando file prompt quiet, ya sea en modo de configuración global, o en cada tarea activándolo y desactivándolo. Para tareas periódicas, IOS dispone de un scheduler (kron) donde podríamos configurar lo siguiente:
    1. Creamos una policy-list de kron especificando las acciones a llevar a cabo:

        S2router(config)# kron policy-list copia                                         
        S2router(config-kron-policy)# cli copy running-config flash:copia.txt           
        S2router(config-kron-policy)# exit      
    

    2. Creamos una entrada en kron indicando la frecuencia de ejecución, por ejemplo cada minuto:

        S2router(config)# kron  occurrence  copia in 00:01 recurring                     
        S2router(config-kron-occurrence)#policy-list copia     
    

    3. Verificamos que la tarea esta en ejecución y cuando finaliza, tenemos nuestra copia almacenada en flash:

    S2router#show kron schedule                                                     
    Kron Occurrence Schedule                                                        
    copia inactive, will run again in 0 days 00:00:45  
    
    S2router#dir                                                                    
    Directory of flash:/                                                            
                                                                                    
        1  -rw-    18716748  Dec 16 2008 08:40:28 +00:00  c1841-advsecurityk9-mz.12n
        2  -rw-        2746  Dec 16 2008 08:55:52 +00:00  sdmconfig-18xx.cfg        
        3  -rw-      931840  Dec 16 2008 08:56:14 +00:00  es.tar                    
        4  -rw-     1505280  Dec 16 2008 08:56:36 +00:00  common.tar                
        5  -rw-        1038  Dec 16 2008 08:56:54 +00:00  home.shtml                
        6  -rw-      112640  Dec 16 2008 08:57:12 +00:00  home.tar                  
        7  -rw-      527849  Dec 16 2008 08:57:30 +00:00  128MB.sdf                 
        8  -rw-        5702  Dec 27 2013 10:21:18 +00:00  copia.txt        
    
    

Las situaciones vistas, implican que de forma periódica vamos almacenando las copias de seguridad, no obstante, en muchas ocasiones la configuración no cambia tanto como para requerir de la misma copia de seguridad todos los días, y menos si la copia se almacena en local, por lo que lo ideal sería disponer al menos de una copia cuando un administrador entra al sistema (aunque no realice ningún cambio). Es aquí donde podemos usar Cisco IOS EEM.

Cisco IOS Embedded Event Manager (EEM) es un sistema de Cisco IOS que permite recolectar datos de distintos subsistemas y llevar a cabo acciones, de forma que mediante la automonitorización reduce la necesidad de hacer polling al dispositivo y por lo tanto, podría reducir el ancho de banda usado por un NMS.

Su arquitectura es sencilla y consta de tres componentes:

  • Event detectors: recolectan información de los distintos subsistemas de IOS, como registros de syslog, comandos CLI, variables SNMP, registros Netflow, eventos de Routing, etc.
  • EEM Server: el sistema central que recibe la información, la procesa, y lanza una o varias acciones.
  • Policies: secuencias de comandos almacenados en memoria llamados applets o también scripts TCL definidos por el administrador.

Con EEM podemos generar copias periódicas por el vencimiento de timers o eventos de kron de forma similar a los vistos anteriormente, pero al darnos la potencia de poder detectar eventos y generar acciones concretas, podríamos hacer copias de seguridad únicamente cuando se detecte un acceso privilegiado al sistema. Vamos a verlo tanto con applets y acciones como con un script TCL.

Lo primero que debemos hacer es crear el applet:

S2router(config)# event manager applet ACCESOS  

A continuación, seleccionamos el patrón que buscamos dentro del susbistema syslog:

                           
S2router(config-applet)# event syslog pattern "Privilege level set to 15 by"    

Finalmente, indicamos las acciones a llevar a cabo cuando se detecta el patrón anterior. Estas serán por ejemplo registrar el acceso en el log (aparecerá en consola si lo tenemos configurado así) y realizar una copia de seguridad en flash:

S2router(config-applet)# action 1.0 cli syslog priority debugging msg "ACCESO PRIVILEGIADO"   
S2router(config-applet)# action 2.0 cli command "enable"                        
S2router(config-applet)# action 3.0 cli command "copy running-config flash:backup.txt"    
S2router(config-applet)# action 4.0 cli command "exit"   

Una vez creado, lo vemos registrado correctamente:

S2router# show  event manager policy registered                                  
No.  Class   Type    Event Type          Trap  Time Registered           Name   
1    applet  system  syslog              Off   Fri Dec 27 10:24:51 2013  ACCESOS
 pattern {Privilege level set to 15 by}                                         
 action 1.0 syslog priority debugging msg "ACCESO PRIVILEGIADO"                 
 action 2.0 cli command "enable"                                                
 action 3.0 cli command "copy running-config flash:backup.txt"                  
 action 4.0 cli command "exit"   

De forma que cuando accedemos por SSH, en la consola del sistema podríamos ver el mensaje anterior:

*Dec 27 10:27:31.643: %SYS-5-PRIV_AUTH_PASS: Privilege level set to 15 by jose )
*Dec 27 10:27:31.651: %HA_EM-7-LOG: ACCESOS: ACCESO PRIVILEGIADO                

Y comprobar que disponemos de la copia correcta almacenada en flash:

S2router#dir                                                                    
Directory of flash:/                                                            
                                                                                
    1  -rw-    18716748  Dec 16 2008 08:40:28 +00:00  c1841-advsecurityk9-mz.12n
    2  -rw-        2746  Dec 16 2008 08:55:52 +00:00  sdmconfig-18xx.cfg        
    3  -rw-      931840  Dec 16 2008 08:56:14 +00:00  es.tar                    
    4  -rw-     1505280  Dec 16 2008 08:56:36 +00:00  common.tar                
    5  -rw-        1038  Dec 16 2008 08:56:54 +00:00  home.shtml                
    6  -rw-      112640  Dec 16 2008 08:57:12 +00:00  home.tar                  
    7  -rw-      527849  Dec 16 2008 08:57:30 +00:00  128MB.sdf                 
    8  -rw-        5644  Dec 27 2013 10:27:32 +00:00  backup.txt                
    9  -rw-        5702  Dec 27 2013 10:21:18 +00:00  copia.txt      

Con esto, ya disponemos de una copia de seguridad previa a los posibles cambios del administrador (lo mejor sería copiarla también a un sitio remoto). Lógicamente, si volvemos a entrar los cambios se perderán, pero podríamos disponer de variables de entorno definidas (show event manager environment) y guardar las copias con distintos nombres en base a la fecha de acceso. También podríamos enviar un correo electrónico o generar un trap SNMP para notificar del acceso.

En unos días la segunda parte con más opciones en EEM.

2013 se nos va…

Y con él, muchas noticias relacionadas con la seguridad. Los casos de ciberacoso, la evolución del cloud computing, las dichosas cookies, los chinos haciendo de las suyas por un lado, la NSA haciendo de las suyas por otro… una año realmente movido en nuestro ámbito.

Pero sin solución de continuidad nos llega 2014. ¿Qué nos traerá?

Pues me temo que algunos de los temas que he citado antes seguirán con nosotros. Pero sin duda nos traerá nuevos retos. Algunos ya los prevemos: el desarrollo del BYOD y los riesgos que implica para las organizaciones, la ciberseguridad industrial, las smart cities… Otros retos, aún no acertamos ni a imaginarlos.

Pero lo que es seguro es que aquí en SAW seguiremos para contárselos, y para seguir haciendo lo que nos apasiona: hablar, compartir y seguir aprendiendo sobre seguridad, en todas sus vertientes. Y, si es posible, con su compañía.

Con nuestros mejores deseos para el año entrante.

Seguridad Wi-Fi empresarial – Servidores radius (III)

En esta tercera y última parte sobre seguridad Wi-Fi empresarial se detalla como conectar con diferentes clientes, desde varios sistemas operativos al servidor radius.

Primero se empezará a detallar como conectarse desde Windows 7:

Lo primero que hay que hacer es instalar la autoridad certificadora o CA.

De los certificados que se crearon en el artículo anterior tenemos root.pem, que es el que hay que instalar:

[Read more…]

Fundamentos sobre Certificados Digitales: Legislación propia de Autoridades de Certificación en España (1ª parte)

Ya hemos recorrido gran parte de los puntos fundamentales a tener en cuenta para la constitución e implementación de una Autoridad de Certificación (en adelante CA), y a pesar de que una CA es básicamente técnica, es fundamental tener en cuenta cuáles son los requisitos legales y normativos propios para cada uno de los tipos y usos previstos. Así como para implantar y certificar el nivel de confianza objetivo.

Si existen unos requisitos fundamentales e ineludibles para establecer una CA en España, son los establecidos por la Ley de Firma Electrónica. Daremos un repaso a su contenido destacando los puntos de mayor importancia o interés para los usuarios o para cualquiera que esté considerando crear una Autoridad de Certificación en España.

Es evidente que en cada país se establecerán requisitos distintos, basados en legislación o normativa propia en cada caso, así como existen estándares aceptados internacionalmente y por las compañías. En España, la ley establece los requisitos y regula el cumplimiento de los mismos es La Ley 59/2003, denominada Ley de Firma Electrónica. Esta ley surge como una modificación de una ley previa para el uso de Certificados Digitales y gestión de Autoridades de Certificación (Real Decreto Ley 14/1999).

Dentro de los puntos clave del texto vigente es que incluye, como cambio de mayor trascendencia respecto al texto anterior, otorgar la misma validez funcional a la firma electrónica y la firma manuscrita. Este hecho es determinante, ya que es un incentivo para el uso de la firma electrónica para la realización de trámites oficiales, así como abre la posibilidad del establecimiento de contratos, obligaciones y compromisos validados empleando firma digital. Para que se pueda considerar dicha equivalencia, la ley especifica qué únicamente será equivalente a una firma manuscrita un certificado reconocido, así como establece los requisitos para que un certificado se considere reconocido. Por lo que este tipo de certificados deben haber sido expedidos garantizando una serie de requisitos específicos de contenido, tratamiento de los mismos, las garantías prestadas por la CA que los emite y la jerarquía de certificación a la que pertenezca (Más información en: “Fundamentos sobre certificados digitales (III): Cadena de confianza”).

Otro punto fundamental de la ley es la regulación del uso del DNI Electrónico, fijando el marco para su uso. Gracias a esta ley, hoy el DNI Electrónico se puede emplear para realizar trámites con la administración, así como para poder firmar cualquier documento digital; en esencia, el DNI electrónico implementa y contiene un certificado digital de persona física reconocido.

Por último, y antes de comenzar con un resumen de los puntos más importantes de su contenido, en esta revisión del texto legislativo se consideran también certificados de persona jurídica, sin hacer perder valor a los certificados de persona física que puedan emplear como representantes de una entidad.
Es importante destacar que en el análisis de la legislación se referirá a la Autoridad de Certificación indistintamente como CA o prestador de servicios de certificación, así como se referirá a los propietarios de los certificados como suscriptores o como solicitantes si aún no han obtenido el certificado.

Una vez introducidos en la temática y siendo conscientes de la finalidad y principales modificaciones establecidas por la Ley, se procede a detallar los requisitos fundamentales de la misma siguiendo su estructura. La ley se distribuye en 6 títulos principales, que se resumen a continuación:

  • Título I: Disposiciones Generales
  • Título II: Certificados Electrónicos
  • Título III: Prestación de Servicios de Certificación
  • Título IV: Dispositivos de Firma Electrónica y Sistemas de Certificación de Prestadores de Servicios de Firma Electrónica y Dispositivos de Firma Electrónica
  • Título V: Supervisión y Control
  • Título VI: Infracciones y Sanciones

Se va a proceder a resumir los puntos de fundamentales o de mayor interés contenidos en cada uno los títulos de la Ley con el fin de ilustrar a grandes rasgos sus requisitos.

En el Título I, se describe el ámbito y objeto de aplicación de la ley; así como el contexto de interacción entre CA y administraciones públicas y los medios de acceso de la administración en estos casos. El ámbito de esta ley regula el uso de la firma electrónica, su validez jurídica y a los prestadores de servicios de certificación que desempeñen su actividad en España. En este título se aprovecha también para definir términos como firma electrónica y sus variantes, como la firma electrónica reconocida. Otra definición de importancia es la de documento electrónico, que se define como un documento firmado digitalmente; detallando los soportes y formatos aceptados jurídicamente. Adicionalmente, en el presente título se detalla el uso de certificados en administraciones públicas, así como las condiciones generales para la prestación de servicios de certificación en territorio Español.

Pasando al Título II, se establece quien puede ser titular de un certificado digital, así como se establecen detalles sobre su vigencia; por otro lado, en su segundo apartado se detalla la regulación de certificados reconocidos como un subconjunto de mayor confianza sobre todos, y en su tercera se fijan las características del DNI Electrónico. Entrando en detalle, se distingue entre certificado digital y firmante, siendo este último la persona que posee el dispositivo de firma, y actúa en nombre propio o representación de una persona o entidad jurídica.

Uno de los puntos más importantes del título son las especificaciones concretas respecto a los certificados digitales de persona jurídica, entrando en detalles como quién los puede solicitar, quién es la persona física responsable de su custodia, así como el método para establecer limitaciones sobre su uso. Adicionalmente, se detallan los motivos para la extinción de la vigencia o suspensión de la vigencia de un certificado, así como las circunstancias que deben producirse o los organismos que lo pueden solicitar. Se entiende como extinción de la vigencia una retirada del certificado forzada, teniendo en cuenta factores como órdenes judiciales, uso indebido, caducidad o constancia de que se haya podido vulnerar el certificado. La vigencia máxima para un certificado digital amparado por la presente ley será de 4 años, y se deberá ajustar dicha duración según el uso previsto y la tecnología empleada (como por ejemplo los algoritmos criptográficos empleados, más información en otra entrada de esta serie: “Fundamentos sobre certificados digitales (VI) – Algoritmos Criptográficos”). En cualquier caso el prestador de servicios deberá dar constancia de la revocación del certificado en los medios a su disposición, de modo que cualquier tercero pueda estar al tanto de su estado (Más información en: “Fundamentos sobre certificados digitales (IV): Mecanismos de validación de certificados”).

El segundo de los puntos más importantes es el establecimiento de los requisitos necesarios para considerar un certificado como reconocido. A grandes rasgos, un certificado digital reconocido deberá cumplir las siguientes condiciones:

  • Debe ser un certificado emitido por una CA que cumpla con todos los requisitos de la Ley que nos ocupa.
  • El certificado deberá contener al menos cierta información, entre la que destaca un código identificativo único, la identificación del prestador de servicios que lo expide, acceso al mecanismo de validación del certificado, o fecha de inicio y final de la validez del certificado.

Además, se definen las comprobaciones que debe realizar la CA antes de emitir un certificado reconocido, así como las acciones a llevar a cabo para validar la identidad y circunstancias de los suscriptores de los certificados. Por ejemplo se debe imponer la obligación de que el suscriptor se persone físicamente y se realice una validación de su Documento Nacional de Identidad para la emisión del certificado. La validación de los suscriptores será objeto de futuras entradas de esta serie.

El último punto de este título hace referencia al DNI Electrónico, estableciendo su validez como certificado de confianza; lo que implica la obligación de cualquier entidad pública o privada a aceptar la validez de los datos personales que en él constan, de la identidad del remitente, así como la integridad del mensaje firmado con el mismo.

Espero que la entrada os esté resultando interesante, próximamente seguimos con la segunda parte de la misma, en la que se finalizará la revisión de los puntos más importantes de la Ley de Firma Electrónica. ¡Gracias por leernos!

Enlaces de Complementarios:
Ley 59/2003 de Firma Digital
Real Decreto Ley 14/1999 de Firma Electrónica

Firewalls transparentes

Como hemos visto infinidad de veces en libros o presentaciones de fabricantes, el firewall esta considerado como el elemento principal a la hora de llevar a cabo una correcta segmentación de redes y por lo tanto, habitualmente trabaja a nivel 3 proporcionando filtrado y enrutando entre ellas. Esta sería una arquitectura básica de red: el firewall segmentando una red corporativa en segmentos de DMZ, usuarios, servidores internos y WAN.

No obstante, y aunque nunca he tenido la necesidad de realizar una configuración así, muchos sistemas permiter trabajar a nivel 2 en modo transparente, manteniendo el direccionamiento de red dentro del segmento y siendo una configuración posible cuando se requiere un análisis o filtrado con el menor número de cambios posibles, por ejemplo, para no afectar a la red de servidores de producción. La arquitectura quedaría así:

[Read more…]

Apache: guardar peticiones POST en los logs

De un tiempo a esta parte muchos de los ataques que sufren los portales web se materializan en peticiones POST. Inyecciones SQL, inclusión de ficheros remotos o envenenamiento de parámetros son sólo algunos de los ataques en los que intervienen peticiones POST.

El problema es que por regla general la información de las peticiones POST no se guarda en los logs, por lo que al hacer un análisis forense a un equipo atacado, generalmente nos falta información para poder esclarecer el origen del compromiso o la información que se ha podido ver comprometida.

Por ello vamos a ver, centrados en el servidor web Apache, las posibilidades que existen para guardar el contenido de las peticiones POST que se hacen a nuestro servidor web.

[Read more…]

Firewalls Virtuales

Actualmente, lo habitual en una organización es disponer de un firewall/cluster y mediante el uso de vlans, ir creando nuevos segmentos dependiendo del crecimiento de la red, lógicamente siempre que el sistema a nivel de procesamiento no se vea afectado. No obstante, puede darse el caso de empresas que den servicio a múltiples clientes con el mismo firewall, de forma que se quiera diferenciar cada cliente de forma unívoca. Para ello, cada vez más aparecen en el mercado soluciones de firewalls virtuales y como casi siempre, el uso de una funcionalidad lleva asociada la licencia correspondiente.

Para este post, vamos a crear un firewall virtual en un dispositivo Cisco ASA 5550, no obstante, fabricantes como Fortinet disponen de soluciones similares.

Centrándonos en nuestro sistema, podemos crear múltiples firewalls virtuales llamados contextos, donde cada contexto es independiente del resto, y dispone de su propia política de seguridad, interfaces, usuarios o rutas, aunque hay otras funcionalidades que no vienen soportadas, como VPN o protocolos de enrutamiento dinámico (parece que en versiones actuales mejoran considerablemente estas limitaciones), no obstante, para nuestro caso, será suficiente.

Existen tres tipos de contexto:

  • system: el contexto raíz donde el administrador gestiona el resto de contextos del sistema, interfaces, recursos, etc.
  • admin: igual que cualquier otro contexto pero donde el administrador tiene permisos para acceder a otros contextos.
  • normal: una partición del firewall donde sólo se puede acceder a la información del propio contexto.

En nuestro ejemplo, partimos de un firewall sin configuración previa, si no lo fuera, deberíamos realizar una copia de seguridad previa. Una vez conectados al sistema, debemos asegurarnos de cuantos firewalls virtuales podemos crear con la licencia disponible:

ciscoasa# show version

Licensed features for this platform:                                                                                                    
Maximum Physical Interfaces  : Unlimited                                                                                                
Maximum VLANs                : 250                                                                                                      
Inside Hosts                 : Unlimited                                                                                                
Failover                     : Active/Active                                                                                            
VPN-DES                      : Enabled                                                                                                  
VPN-3DES-AES                 : Enabled                                                                                                  
Security Contexts            : 5                                                                                                        
GTP/GPRS                     : Disabled                                                                                                 
VPN Peers                    : 5000                                                                                                     
WebVPN Peers                 : 2                                                                                                        
Advanced Endpoint Assessment : Disabled           

En éste caso, podríamos tener 5 contextos. Aclarado esto, procedemos con la configuración:

1. Configurar el sistema en modo múltiple:

ciscoasa# show mode                                                             
Security context mode: single  

ciscoasa(config)# mode  multiple                                                
WARNING: This command will change the behavior of the device                    
WARNING: This command will initiate a Reboot                                    
Proceed with change mode? [confirm]                                             
Convert the system configuration? [confirm]   

Tras reiniciar, podemos comprobar que el sistema ya aparece configurado en modo múltiple y dispone de configuración específica para el contexto admin:

ciscoasa# show  mode                                                            
Security context mode: multiple     

ciscoasa# show run
…...
class default                                                                   
  limit-resource All 0                                                          
  limit-resource ASDM 5                                                         
  limit-resource SSH 5                                                          
  limit-resource Telnet 5      
admin-context admin                                                             
context admin                                                                   
  config-url disk0:/admin.cfg 

2. Crear interfaces virtuales y asociarles identificador de vlan. Ya que vamos a usar vlans para confgurar contextos, necesitamos definir trunks en los switches

ciscoasa(config)# mac-address auto                                                                                                                        
ciscoasa(config)# interface GigabitEthernet0/1.1                            
ciscoasa(config-subif)# vlan 100
ciscoasa(config-subif)# no shutdown 
ciscoasa(config-subif)# interface GigabitEthernet0/2.1
ciscoasa(config-subif)# no shutdown
ciscoasa(config-subif)# vlan 200
ciscoasa(config-subif)# interface GigabitEthernet0/3.1
ciscoasa(config-subif)# no shutdown
ciscoasa(config-subif)# vlan 300

3. Definir los contextos (el contexto admin ya existe):

ciscoasa(config)# context Cliente1                                              
Creating context 'Cliente1'... Done. (2)                                        
ciscoasa(config-ctx)# description Contexto1   

4. Asignar visibilidad sobre las interfaces a cada contexto e indicar el fichero de configuración del mismo:

ciscoasa(config-ctx)# allocate-interface GigabitEthernet0/1.1 inside            
ciscoasa(config-ctx)# allocate-interface GigabitEthernet0/2.1 outside           
ciscoasa(config-ctx)# allocate-interface GigabitEthernet0/3.1 dmz 
ciscoasa(config-ctx)# config-url disk0:/cliente1.cfg     

Una vez configurados los contextos, podemos cambiar a un contexto específico y configurarlo como si de un único firewall se tratara. Una vez nos situamos en el contexto, vemos que el prompt cambia:

ciscoasa# changeto context Cliente1                                     
ciscoasa/Cliente1# show running-config
...
interface inside                                                                
 no nameif                                                                      
 no security-level                                                              
 no ip address                                                                  
!                                                                               
interface outside                                                               
 no nameif                                                                      
 no security-level                                                              
 no ip address                                                                  
!                                                                               
interface dmz                                                                   
 no nameif                                                                      
 no security-level                                                              
 no ip address    

En este punto, podemos volver al contexto system para crear un nuevo contexto:

ciscoasa/Cliente1(config)# changeto system                                      
ciscoasa(config)# context Cliente2                                              
Creating context 'Cliente2'... Done. (3)                                                                                        
ciscoasa(config-ctx)# description Contexto2                                     
ciscoasa(config-ctx)# allocate-interface GigabitEthernet0/1.2 inside            
ciscoasa(config-ctx)# allocate-interface GigabitEthernet0/2.2 outside           
ciscoasa(config-ctx)# allocate-interface GigabitEthernet0/3.2 dmz    
  config-url disk0:/cliente2.cfg          

Una vez creado (no tiene asignadas vlans todavía), podemos ver los contextos definidos en el sistema:

ciscoasa(config)# show context                                                  
Context Name      Class      Interfaces           URL                           
*admin            default                         disk0:/admin.cfg              
 Cliente1         default    GigabitEthernet0/1.1, disk0:/cliente1.cfg          
                             GigabitEthernet0/2.1,                              
                             GigabitEthernet0/3.1                               
 Cliente2         default    GigabitEthernet0/1.2, disk0:/cliente2.cfg          
                             GigabitEthernet0/2.2,                              
                             GigabitEthernet0/3.2                               
                                                                                
Total active Security Contexts: 3    

Antes de entrar a configurar nuestro contexto, si nos fijamos en la salida del comando anterior, vemos que aparece una class definida por defecto. Esta opción es útil si queremos limitar los recursos de nuestros contextos, ya sea para evitar la saturación del sistema, o por que dispongamos de contratos gold/silver y en cada uno de ellos, limitemos los recursos contratados.

Tras esto, volvemos a configurar nuestro contexto de forma independiente:

                                
ciscoasa# changeto context Cliente1
ciscoasa/Cliente1(config)# hostname ASA1   
ciscoasa/Cliente1(config)# domain-name cliente1.com     
ciscoasa/Cliente1(config)# username admin password admin privilege 15                                                               
ciscoasa/Cliente1(config)# interface inside
ciscoasa/Cliente1(config-if)# nameif inside
ciscoasa/Cliente1(config-if)#  security-level 100
ciscoasa/Cliente1(config-if)#  ip address 172.18.0.200 255.255.255.0
ciscoasa/Cliente1(config-if)#  no shutdown
ciscoasa/Cliente1(config)# http server enable                                                    
ciscoasa/Cliente1(config)# crypto key generate rsa                              
ciscoasa/Cliente1(config)# show crypto key mypubkey  rsa                      
Key pair was generated at: 06:14:35 UTC Dec 17 2013                             
Key name:                                                      
 Usage: General Purpose Key                                                     
 Modulus Size (bits): 1024                                                      
 Key Data:                                                                      
                                                                                
  30819f30 0d06092a 864886f7 0d010101 05000381 8d003081 89028181 00d81874       
  dcca041b fbb5752c 5f5562f1 95422b42 e825e7b4 0b7b0aee 5cd90c04 e3302ddc       
  d9ee6c98 8664e8cd 2a3ad611 aa6b9d35 09cc81f3 48eccbe3 129d5483 17170a54       
  b1bef1ca b351ede5 86e3b26b 8f8619f9 b5d928c7 3b391861 8a1c72de 449e0fbc       
  b2acddee 3deaa0ff db55df25 4ba26f7b 6446972c e05e1839 52a09bad 45020301 0001 

ciscoasa/Cliente1(config)# http 172.18.0.150 255.255.255.255 inside             
ciscoasa/Cliente1(config)# ssh 172.18.0.150 255.255.255.255 inside                                                                      
ciscoasa/Cliente1(config)# wr mem

En este punto, ya podríamos acceder de forma remota al dispositivo y gestionarlo de forma independiente.

Desde el contexto admin, podemos ver la configuración de los contextos con el comando show running-config all context [name] y los recursos consumidos con show resource usage context [name]:

ciscoasa(config)#  show resource usage context Cliente1                                                                                 
Resource              Current         Peak      Limit        Denied Context                                                             
ASDM                        1            1          5             0 Cliente1                                                            
Conns                       2            9  unlimited             0 Cliente1                                                            
Hosts                       2            2  unlimited             0 Cliente1                                                            
Conns [rate]                1           11  unlimited             0 Cliente1    

También podemos guardar todos los cambios de los contextos:

ciscoasa(config)# wr mem all                                                                                                            
Building configuration...                                                                                                               
Saving context :           system : (000/003 Contexts saved)                                                                            
Cryptochecksum: 1eb2b9ed bf4f0170 628827cb cda1116d                                                                                     
                                                                                                                                        
1612 bytes copied in 3.300 secs (537 bytes/sec)                                                                                         
Saving context :            admin : (001/003 Contexts saved)                                                                            
Cryptochecksum: d367f98b 4f1280c6 2a3275f4 5e0df5eb                                                                                     
                                                                                                                                        
1313 bytes copied in 0.200 secs                                                                                                         
Saving context :         Cliente1 : (002/003 Contexts saved)                                                                            
Cryptochecksum: fc0590ec a8514229 3d126e92 4052d174                                                                                     
                                                                                                                                        
1572 bytes copied in 0.210 secs                                                                                                         
Saving context :         Cliente2 : (003/003 Contexts saved)                                                                            
Cryptochecksum: 81553ccc ebd17807 b63b1f4b ee30b125                                                                                     
                                                                                                                                        
1432 bytes copied in 0.200 secs                                                                                                         
[OK]              

Finalmente, podemos borrar contextos o volver a dejar el sistema en modo single:

ciscoasa(config)#  no context Cliente2                                                                                                  
WARNING: Removing context 'Cliente2'                                                                                                    
Proceed with removing the context? [confirm]                                                                                            
Removing context 'Cliente2' (3)... Done  


ciscoasa(config)# show  context                                                                                                         
Context Name      Class      Interfaces           URL                                                                                   
*admin            default                         disk0:/admin.cfg                                                                      
 Cliente1         default    GigabitEthernet0/1.1, disk0:/cliente1.cfg                                                                  
                             GigabitEthernet0/2.1,                                                                                      
                             GigabitEthernet0/3.1                                                                                       
                                                                                                                                        
Total active Security Contexts: 2            

Para restaurar el sistema, debemos recuperar la copia de seguridad previa si disponemos de ella, en otro caso, perderemos los cambios iniciales:

ciscoasa(config)# mode single                                                                                                           
WARNING: This command will change the behavior of the device                                                                            
WARNING: This command will initiate a Reboot                                                                                            
Proceed with change mode? [confirm]                                                                                                     
Security context mode: single    

Tras reiniciar, podremos borrar los ficheros generados anteriormente

                                                                                        
ciscoasa# delete disk0:/cliente1.cfg                                                                                                    
Delete filename [cliente1.cfg]?                                                                                                         
                                                                                                                                        
Delete disk0:/cliente1.cfg? [confirm]                                                                                                   
                                                                                                                                        
ciscoasa# delete disk0:/cliente2.cfg                                                                                                     
Delete filename [cliente2.cfg]?                                                                                                          
Delete disk0:/cliente2.cfg? [confirm]    

ciscoasa# delete disk0:/admin.cfg                                                                                                        
Delete filename [admin.cfg]?                                                                                                             
Delete disk0:/admin.cfg? [confirm]  

De esta forma, y salvado las limitaciones existentes, podríamos disponer de mútiples firewalls independientes para dar soporte a distintos clientes en una única plataforma.

Bastionado de sistemas Linux

(N.d.E. Hoy les traemos una presentación que nuestro compañero José Luis Chica, @bufferovercat, realizó en la MurciaLanParty’13, sobre el Bastionado de sistemas Linux. Esperamos que les guste.)

Liberada Guía Nmap 6 de CSIRT-cv y CCN

Hoy os traemos una guía muy interesante, realizada por @BufferOverCat y un servidor (@jovimon), que se ha liberado en los últimos días. La guía, fruto de la colaboración del Centro Criptológico Nacional (CCN) y el Centro de Seguridad TIC de la Comunidad Valenciana (CSIRT-cv), muestra de forma útil y práctica el funcionamiento de Nmap, detallando las técnicas que se pueden utilizar con este analizador de redes.

La guía se finalizó el verano del año pasado, poco tiempo después de la publicación de la versión 6.01 de Nmap, y ha estado hasta ahora únicamente disponible a través del portal del CCN para usuarios de administraciones públicas. Con la liberación de esta guía, única de este tipo que existe en Español, para el público general, se cubre un hueco que hasta ahora únicamente se podía cubrir con textos en otros idiomas.

Por si a estas alturas alguien aún no conoce Nmap, destacar que es sin lugar a dudas la herramienta más utilizada para realizar análisis de redes. Con ella se pueden realizar todo tipo de tareas, desde el descubrimiento de equipos y servicios disponibles en una red, a análisis avanzados que incluyan auditorías tanto a los equipos y servicios descubiertos como a cortafuegos o elementos intermedios de red que puedan interponerse en la comunicación. Es por ello que tanto por administradores de red como auditores de seguridad la utilizan de forma habitual.

La guía se compone de una completa documentación sobre las funcionalidades disponibles, que cubre las técnicas, tanto básicas como avanzadas, de: descubrimiento de equipos, análisis de puertos, optimización, rendimiento, etcétera, y se muestran procedimientos recomendados de actuación dependiendo de la tarea que se quiera realizar.

Además, se cubren dos de las principales mejoras que incluye esta versión: el soporte completo para IPv6 y el motor de scripting de Nmap (NSE: Nmap Scripting Engine), al que se dedica un tema entero. En este tema, se detalla el funcionamiento del motor y se dan directrices detalladas, tanto para entender los scripts ya creados como para crear nuevos scripts.

Aunque la versión actual de Nmap disponible para descarga es la 6.40, las diferencias con la versión de la guía son mínimas, ya que en los últimos tiempos los esfuerzos se centran en aumentar la cantidad de sistemas y servicios diferentes detectados, así como aumentar también las capacidades del motor NSE y el número de scripts que se ofrecen por defecto (actualmente más de 450).

La Guía Avanzada de Nmap está disponible en la sección de descargas del portal de CSIRT-cv y en la web del CCN.