|
|
|
Seguridad en WINDOWS
2000 Herramientas de configuración de seguridad En los últimos años se ha revolucionado el concepto de red y de trabajo en grupo. Una de las novedades es la base de datos de directorio, o más genéricamente, el Directorio. Para Windows 2000 el término es Directorio Activo. Un directorio o base de datos de
directorio no es más que una simple base de datos que almacena distintos
tipos de objetos. Su objetivo es centralizar todos los recursos que hay en
una red en un único sitio para su administración. Otra de sus grandes
ventajas es que los usuarios de dicha red podrán acceder al Directorio
para consultas sobre los recursos existentes.
|
|
Veamos algunos conceptos del Directorio activo de Windows 2000:
Este manual no pretende dar una explicación detallada del Directorio Activo de Windows 2000, simplemente introducirlo para ver los aspectos de seguridad que provee. Los diferentes tipos de objetos del directorio permiten estructurarlo de forma eficaz para la administración. Así, los diferentes objetos que
viene por defecto en él son:
Cada objeto se podrá añadir en la rama del árbol que se desee, aunque es muy importante pensar en la organización del directorio antes de crearlo.
Por otro lado, al ámbito de influencia de los grupos se divide en:
Estás limitados al dominio al que pertenecen y tan solo se pueden asignar permisos a recursos de ese dominio. Sus miembros pueden ser de cualquier dominio dentro del mismo bosque.
Se usarán para garantizar permisos en múltiples dominios y son visibles en todos los dominios con relaciones de confianza. Sus miembros solo pueden ser del dominio en el que se crea el grupo.
Son similares a los anteriores en
el sentido que pueden verse en todos los dominios con confianza, pero sus
miembros pueden pertenecer a cualquier dominio de un bosque. Su objetivo
es garantizar permisos para todo el bosque (conjunto de arboles que
definen la estructura total del Directorio
Activo).
Cada objeto dentro del directorio tiene un identificador único que se crea al añadirlo al directorio activo. Este identificador es el ya mencionado SID. Es este identificador el que el sistema maneja en vez del nombre. Mediante este SID y las ACL vistas para la versión NT 4.0 el Directorio Activo mantiene la seguridad. Así, cada objeto en el Directorio Activo tiene una ACL donde se definen las entradas de los usuarios o grupos que tienen acceso a dicho objeto.
|
|
De forma similar a como se realiza para el sistema de ficheros NTFS, en la página de Seguridad de las propiedades de cada objeto se abre la ventana de la figura. En ella, se puede observar como para cada grupo o usuario definido en la lista superior se pueden ver los permisos de acceso que tiene en la lista inferior. Mediante el botón Advanced... se puede especificar detalladamente los permisos hasta un nivel absoluto de detalle. Veamos esto. Mediante las ACL se puede controlar el acceso a un objeto contenedor y sus hijos, a un objeto concreto e incluso a determinadas propiedades de un objeto. En la figura se puede observar una caja de selección que define si este objeto hereda los permisos de sus objetos contenedores. Si deshabilitamos esta caja no se heredarán permisos de los objetos padres. Al pulsar deshabilitarla nos
aparecerá un mensaje para que indiquemos que operación deseamos
realizar.
|
|
Podremos o copiar los permisos heredados para usarlos como plantilla o eliminar dichos permisos, quedándonos únicamente con los especificados para el objeto. Si pulsamos el botón de Advanced.. veremos lo siguiente:
|
|
Podemos especificar los permisos de forma detallada y al mismo tiempo podemos especificar la auditoria y la propiedad del objeto. Para especificar detalladamente
un permiso debemos editarlo o añadir uno nuevo. Si pulsamos el botón
editar veremos la siguiente ventana:
|
|
En esta ventana existen dos páginas. La página Objeto, especifica los permisos detallados que se asignan al grupo o usuario a editar para el objeto concreto. En esta página podemos detallar los permisos para el objeto en cuestión o para otro tipo de objetos. Para cada tipo de objeto los permisos difieren y son muy detallados. Mediante la otra página, Propiedades podemos especificar los permisos concretos para cada una de las propiedades del objeto. Al igual que lo dicho anteriormente esto permite especificar las propiedades para este objeto o para otro tipo de objetos. Cuando un permiso aparece en gris quiere decir que es un permiso heredado y por lo tanto no se puede editar en el objeto presente y tan solo podrá ser modificado en el original. En la figura siguiente podemos
ver los permisos que se pueden aplicar a las propiedades de un objeto
Usuario. |
|
Otro factor de seguridad que incluye el Directorio Activo es la Delegación de Control. Mediante esta propiedad se puede asignar por parte de una autoridad administrativa de nivel superior la capacidad de realizar tareas administrativas a objetos contenedores y subárboles. Esta característica permite eliminar el grupo Administradores de Dominio para realizar tareas administrativas a lo largo del dominio. Así, mediante la Delegación de Control podemos delegar la administración de forma estructurada y sin dar excesivos permisos no deseados. Esta característica esta únicamente presente en los objetos contenedores. Al accionar esta característica se nos abre un Asistente que primero nos pide los grupos y/o usuarios a los que deseamos Delegar el control. Una vez especificados los grupos y/o usuarios a los cuales deseamos delegar el control nos pide si deseamos delegar el control para una serie de tareas estándar o si queremos determinar con exactitud las tareas a delegar.
|
| Si especificamos que deseamos configurar una tarea determinada nos pedirá si lo deseamos hacer para el objeto en cuestión y todos sus hijos o para un determinado tipo de objeto que nos encontremos en el contenedor: |
|
Una vez que determinamos el tipo de objeto sobre el cual queremos delegar el control debemos especificar que tipo de tareas deseamos delegar. Para ello nos permite seleccionar hasta el punto más detallado. Y nos da tres posibilidades complementarias:
|
|
Una vez especificado el tipo de
tarea a delegar, el Asistente finaliza dándonos un resumen del tipo de
Delegación que hemos determinado y la posibilidad de modificarla o
Aceptarla definitivamente. Como se repetirá en este manual, la seguridad de nuestra información dependerá del numero de barreras que pongamos para que nuestros atacantes no puedan violar la seguridad del sistema. Si pese a poner barreras, un atacante consigue entrar en nuestro sistema a través de Internet, dependerá de la seguridad del propio sistema el que su ataque sea un éxito o no. Una de las medidas de seguridad más importantes que se puede llevar a cabo para proteger información es encriptarla. Hasta ahora, Windows NT no tenía un sistema de encriptado de información integrado en el propio sistema operativo y, lo que es más importante, en el sistema de archivos. A este sistema de encriptación se le conoce por el nombre de EFS – Encrypted File System. Este sistema de encriptado de archivos está totalmente integrado con la infraestructura de clave pública (PKI) que viene con Windows 2000. Esto quiere decir que utiliza las rutinas y funciones del API del sistema operativo como cualquier otra aplicación externa. La diferencia esencial es que esas llamadas se hacen desde el propio sistema dando una transparencia total al usuario. Veamos como funciona el encriptado de un archivo. Cuando solicitamos encriptar un archivo (se verá más adelante), lo primero que hace EFS es asignar una clave privada y una clave pública a nuestra cuenta. Si nuestra cuenta ya tiene un certificado asociado se usará su clave pública, si no es así, EFS generará un par de claves nuevas para su uso en la encriptación del archivo. Realmente genera un certificado X509 (ya se verá su estructura cuando se hable de SSL) y utilizará la clave pública de este certificado. Realmente el encriptado que utiliza EFS no es de clave pública, sino de clave simétrica. Los ficheros son encriptados utilizando el DESX, una variante del DES estándar. Los motivos por los que se usa un cifrado simétrico son dos. El primero es que el encriptado usando algoritmos simétricos en mucho más rápido. El segundo motivo es la necesidad de compartir ficheros entre varios usuarios. Si dichos ficheros estuvieran encriptados con la clave pública de un usuario, tan solo él podría descifrarlo con su clave privada o dar a conocer a todo el mundo su clave privada (absurdo). El mecanismo que se sigue es el siguiente. Una vez que se tiene la clave pública del usuario que desea encriptar la información, el sistema EFS genera un número aleatorio que denominaremos FEK ( File Encryption Key). Esta será la clave usada en el algoritmo DESX para encriptar el fichero. Posteriormente se guardan lo que se denomina Campos de desencriptación de datos. Cada entrada de estas estructuras corresponderá a un usuario que tiene acceso al fichero. De cada usuario se guarda su SID y alguna información del Certificado. Aunque el sistema está preparado
para la compartición de archivos encriptados mediante el uso del anillo de
entradas DDF, en las primeras versiones no se acepta esta
posibilidad.
|
|
Como se pude observar cada entrada DDF guarda información del Certificado del usuario y del SID del mismo. La información del Certificado la guarda para en el proceso de desencriptación poder solicitar la clave privada del usuario. La firma del certificado (hash) se guarda para saber con que certificado y par de claves asociado, se encriptó el fichero. También se guardan las entradas DRF (Data Recovery Field). Estas entradas tienen la misma estructura que las anteriores. Su objetivo es que si un usuario se despide o se produce cualquier error al manejar sus certificados sea posible recuperar los archivos encriptados por él. Para ello existen lo que se denomina Agentes de recuperación. Son certificados de usuarios que pueden desencriptar los ficheros. Para establecer un Agente de recuperación se debe definir en el Directorio Activo, en las Directivas de grupo. Se podrá tener por dominio o local. Por defecto en un controlador de dominio el Agente de recuperación es el Administrador del dominio. Se pueden tener varios agentes de
recuperación y así, se insertarán tantas entradas DRF como Agentes existan
y estén activos.
|
|
El proceso de desencriptado es totalmente transparente al usuario. En definitiva, EFS lo que hace es comprobar que el SID del usuario que accede al fichero está en las entradas DDF. Si es así, comprueba que certificado se usó y solicita la clave privada asociada a dicho certificado para desencriptar la FEK. Una vez, desencriptada la FEK tan solo debe descifrar el fichero mediante DESX y la FEK obtenida. El proceso de recuperación
funciona igual que el de desencriptado, con la diferencia que desencripta
la FEK con alguna entrada de las DRFs. Este proceso se muestra en la
figura de la página siguiente:
|
|
Para encriptar un archivo debemos hacerlo desde el Explorador de Windows o desde una utilidad del modo comandos denominada cipher. Desde el Explorador debemos pulsar el botón de Avanzado de las propiedades del archivo y nos saldrá la siguiente ventana: |
|
Al decir OK el sistema encriptará el archivo. Si quitamos el atributo el archivo se desencriptará, obviamente si tenemos permiso para ello. Desde la línea de comandos un archivo o directorio se encripta usando la siguiente instrucción: D:\>cipher /e /s:"D:\Basura" Los parámetros posibles
son: |
|
Veamos ahora que es lo que pasa cuando se mueve o copia un fichero encriptado. Primero veamos que pasa cuando se copia un fichero o directorio encriptado desde un equipo Windows 2000 a:
Veamos que pasa ahora cuando lo movemos o renombramos a
Por último decir que un fichero o
directorio encriptado puede ser borrado por otro usuario siempre y cuando
tenga el permiso para hacerlo. Esto es muy importante y conviene recordar
que no es lo mismo los permisos NTFS que el encriptado de
archivos. Windows NT 4.0 tiene un conjunto de características de seguridad que le hacen un sistema operativo seguro. No obstante, la administración de dicha seguridad requería la utilización de diferentes programas y había que configurar distintas opciones en varios sitios. Para hacer la labor de configurar un sistema seguro más sencilla, se ha incluido en Windows 2000 (era un componente en NT 4.0) lo que se denomina Herramientas de configuración de seguridad. Utilizando la tecnología de las MMC (Microsoft Management Console – Consolas de Administración Microsoft) permite al administrador configurar la seguridad del sistema desde un único sitio y de forma sencilla e intuitiva. Los objetivos de estas herramientas de seguridad son:
Estas herramientas permiten configurar al detalle todos los aspectos de la seguridad y está clasificado en los siguientes puntos:
Las herramientas de seguridad se componen de seis elementos interconectados unos con otros:
Las posibles tareas que se pueden
realizar con este conjunto de herramientas son las
siguientes: Definir configuraciones de seguridad Mediante el editor de configuraciones de seguridad podemos crear distintas configuraciones donde se almacenarán todos los parámetros de seguridad. El Editor trae una serie de configuraciones estándar que pueden usarse si así se desea. Dichas configuraciones se almacenan en ficheros de texto tipo .inf con lo que pueden ser modificadas con cualquier editor de texto. Esto último no es recomendable para prevenir la alteración del formato del fichero que pueda producir errores. Para definir las distintas configuraciones está el propio Editor de configuraciones de seguridad que es una Consola de Administración con la misma interfaz que todas como puede observarse en la figura de la página siguiente.
|
|
Configurar el sistema Para configurar un sistema el conjunto de herramientas de seguridad nos permite hacerlo desde tres sitios diferentes:
|
Permite realizar diferentes tareas al introducirle parámetros: secedit {/analyze | /configure | /generate | /refreshPolicy | /validate}
Para analizar la seguridad del
sistema se utiliza el Administrador de configuraciones de seguridad o
desde la línea de comandos. El análisis consiste en revisar los parámetros
reales de la maquina y compararlos con aquellos definidos en la base de
datos. El resultado nos lo da el sistema en el Administrador y nos resalta
aquellos parámetros que no coinciden. |
| Una vez que el sistema ha finalizado el análisis nos muestra la configuración indicándonos para cada parámetro la configuración de la base de datos y el parámetro efectivo. Nos lo resaltará mediante iconos. Nos permitirá modificar los valores que deseemos y corregir lo que sea necesario Configurando el sistema de nuevo. |
|
Kerberos es un nombre de la
mitología griega y era el perro de tres cabezas que guardaba la entrada a
las profundidades. También es el nombre usado para el RFC1510 que define
un sistema de autenticación de usuarios.
Entre las ventajas añadidas del protocolo Kerberos sobre el NTLM podemos destacar que es mucho más rápido ya que una vez que un cliente se ha autenticado con un determinado servidor no requiere en ningún momento conectarse con el controlador del dominio. Otra ventaja es que permite la autenticación mutua, esto es, cliente y servidor tienen la garantía de que el otro extremo es quien dice ser. El protocolo está pensado para funcionar en una red absolutamente pública, es decir, se considera que todos los elementos intervinientes son inseguros. Se duda de todo, de la autenticidad del servidor y del cliente y que en el trayecto alguien puede estar escuchando y capturando paquetes que puedan revelar información. El sistema se basa en el concepto de que para autenticar la identidad mutua entre dos personas deben conocer un secreto entre ambas. Si ambas personas conocen un secreto y nadie más lo conoce, les resultará muy fácil autenticarse una a la otra diciendo simplemente el secreto. Hasta aquí todo va muy bien. El problema surge en como notificar el secreto a la otra parte sin darlo a conocer al resto de posibles atacantes. La solución vuelve a ser sencilla, se encripta con una clave. Al encriptarlo con una clave el secreto se manda de un extremo a otro y la autenticación se produce al encriptarla y si el otro es capaz de desencriptarla podrá verificarla. Para este proceso de encriptado es necesario usar un sistema de clave simétrica para que ambos interlocutores puedan encriptar y desencriptar con la misma clave. Esto hace que el secreto compartido pase a ser la clave y al mismo tiempo el envío de dicho secreto es confidencial. Según lo dicho hasta ahora si Alice quiere enviar un mensaje a Bob añadirá al mensaje un bloque cifrado con la clave secreta que comparten ambos. Cuando Bob lee el mensaje debe verificar que viene efectivamente de Alice. Para ello descifra el bloque cifrado con la clave secreta que comparte con Alice. Si logra descifrarlo tendrá la garantía que el remitente del mensaje es Alice. Ahora quedaría por saber como Alice sabe que el que recibió el mensaje es Bob. Para ello, Bob puede cifrar con la clave compartida parte del bloque encriptado por Alice. Si cifrara todo, podría ser alguien que ha capturado el bloque completo y lo ha reenviado. Solo cifra, con la clave secreta compartida, parte del bloque. Cuando este nuevo bloque cifrado llega a Alice lo desencripta con la clave compartida y puede comprobar que la parte cifrada corresponde a lo que él mando inicialmente. En esto consiste el protocolo Kerberos. Aunque todavía faltan un par de cabos por atar. Entre la información que contiene el bloque cifrado que Alice manda inicialmente a Bob, va la hora del reloj de su ordenador (se supondrá que los equipos tienen los relojes sincronizados). Bob al descifrar el mensaje comprueba que la hora es la correcta y reenvía dicha hora cifrada de nuevo a Alice para autenticarse. El problema surge porque los relojes no estén sincronizados. Para ello el protocolo mantiene un valor que indica el error posible. Cuando Bob descifra el bloque cifrado por Alice comprueba que la hora esta en ese intervalo y además, como guarda una lista de las sesiones anteriores y sus tiempos, podrá comprobar que el tiempo enviado por Alice es superior al último enviado. Si es inferior o igual la conexión será rechazada. Al bloque de información cifrada
que Alice manda a Bob y viceversa se le denomina
Autenticador. |
|
Nos falta por resolver como Alice y Bob se ponen de acuerdo para la clave secreta a compartir. Es importante saber que dicha clave deberá ser única entre cada dos entidades, esto es, Alice deberá usar otra clave para hablar con Jonh y Bob también. El nombre de Kerberos define un poco la solución. Como se ha dicho era un perro de tres cabezas, como es este protocolo en el que intervienen siempre tres elementos: un cliente, un servidor y una tercera entidad de confianza que media entre ambos. esta entidad intermediaria es conocida como KDC (Key Distribution Center). El Servicio KDC se ejecuta en un servidor seguro y mantiene una base de datos con las credenciales de toso los participantes en lo que se denomina su Reino (realm) o lo que en Windows 2000 es equivalente, en su dominio. Junto con información relativa a cada participante se guarda lo que se denomina Clave de larga duración que comparte con cada participante y solo el KDC y el participante conocen. Esta clave se deriva de la contraseña de usuario. Cuando el cliente quiere hablar
con el servidor envía una petición al KDC. Este distribuye una clave
secreta para ambos, denominada clave de sesión. De esta forma se puede
establecer la comunicación como se había explicado antes.
|
|
Esto es solo la teoría. En realidad no se hace así porque esto supondría un gasto de recursos excesivo por parte de los servidores al tener que almacenar todas las claves de sesiones de todos los clientes que deseen acceder a ellos. Se hace de otra manera más eficaz. Lo que en realidad se hace es que cuando el cliente quiere contactar con un servidor realiza una petición al KDC. Este en vez de enviar la clave de sesión a cada interlocutor, envía la clave de sesión al cliente. Además, de la clave de sesión le envía lo que se denomina ticket de sesión. Este ticket contiene información sobre el propio cliente y la copia de la clave de sesión correspondiente al servidor. Esta información se envía
encriptada. LA clave de sesión del cliente se encripta con la clave de
sesión entre el KDC y el cliente (siempre existe). El ticket de sesión se
encripta con la clave de sesión existente entre el servidor y el KDC. Todo
esto lo guarda el cliente.
|
|
Cuando el cliente recibe la
respuesta completa del KDC puede iniciar la conversación con el servidor.
Para ello extrae desencriptando con su clave de sesión compartida con el
KDC la nueva clave de sesión para las conversaciones con el servidor en
cuestión. Cuando el servidor recibe las
credenciales del cliente desencripta el ticket con su clave de sesión
compartida con el KDC. Una vez desencriptado extrae la clave de sesión
para la conversación con el cliente. Con ella desencripta el autenticador
enviado por el cliente y responde con el tiempo recibido otra vez
encriptado con la clave de sesión.
|
|
Cuando el servidor no necesita la clave de sesión la desecha. El cliente podrá reutilizar la clave de sesión cuantas veces quiera. Tienen un periodo de validez que normalmente se estipula en 8 horas y cuando el usuario sale del dominio se desechan todas sus claves de sesión. Solo queda ver como tanto el servidor como el cliente comparten sus respectivas claves de sesión con el KDC. Cuando un usuario por vez primera entra en la red calcula (su servicio Kerberos cliente) su clave de larga duración (Windows 2000 usa el sistema DES-CBC MD5). Una vez calculada dicha clave solicita un ticket de sesión y una clave de sesión para sus conversaciones con el propio KDC. Como para cualquier petición el KDC le responde con el envío de una clave de sesión y de un ticket de sesión. A este ticket de sesión se le llama TGT (ticket-granting ticket). Como cualquier ticket de sesión contendrá la clave de sesión para la conversación entre ambos y estará encriptado con la clave de larga duración del KDC. Al mismo tiempo el cliente recibirá la clave de sesión para las conversaciones con el KDC encriptada con su clave de larga duración. A esta clave de sesión se la denomina clave de sesión de logon debido a que se desecha cuando el usuario sale de la red. Realmente, Kerberos está compuesto de tres subprotocolos:
Cuando Alice entra en la red teclea su nombre y contraseña. Su servicio Kerberos cliente generará la clave de larga duración para usarla en la solicitud de claves de sesión.
|
|
Una vez generada, envía una petición KRB_AS_REQ al KDC. Una parte del mensaje identifica al usuario, Alice y al nombre del servicio para el cual desea una clave de sesión, en este caso el servicio TGS Exchange. La segunda parte del mensaje se utiliza para probar que Alice conoce su clave ( es decir que es Alice). Normalmente es el tiempo del ordenador encriptado con la clave de larga duración de Alice.. A este campo se le llama Datos de preAutenticación. Cuando el KDC recibe la petición comprueba cual es la clave de Alice en su base de datos y con ella desencripta el campo de preAutenticación. Si el tiempo que se encuentra entra en los límites establecidos el servidor establece que el mensaje proviene de Alice. El KDC entonces genera la clave
de sesión o clave de sesión de entrada para las futuras conversaciones con
Alice y también generará el ticket encriptado con su propia contraseña
para dichas conversaciones. |
|
Cuando Alice necesita conectarse con el servidor Bob envía un mensaje de petición de ticket al KDC (KRB_TGS_REQ). Este mensaje incluye el nombre del usuario, un autenticador encriptado con la clave de sesión de entrada del usuario, el TGT obtenido del KDC para las conversaciones entre ambos y el servicio al que Alice se desea conectar. Cuando el KDC lo recibe, desencripta el TGT con su propia clave y extrae la clave de sesión para hablar con Alice. Con esta clave desencripta el autenticador y lo evalúa. Si el autenticador es correcto, el KDC genera la clave de sesión para las conversaciones entre Bob y Alice. Una copia de esta clave la encripta con la clave de sesión de logon de Alice. Otra copia la inserta en un ticket junto con información relativa a Alice y encripta todo el ticket con la clave de larga duración de Bob. Todo ello se lo envía a Alice en un mensaje (KRB_TGS_REP).
Cuando Alice desea conectar con
Bob le envía un mensaje de petición de conexión (KBR_AP_REQ). El mensaje
contiene un autenticador encriptado con la clave de sesión para las
conversaciones entre ambos, el ticket obtenido del KDC para estas
conversaciones y un indicador de si el cliente (Alice) quiere
autenticación mutua o no. |
|
El servicio Bob recibe el mensaje y desencripta el ticket usando su clave de larga duración. Al desencriptarlo extrae la clave de sesión a usar con Alice. Con dicha clave desencripta el autenticador de Alice y lo evalúa. Si la evaluación sale con éxito, Bob comprueba si el indicador de autenticación mutua esta puesto. Si es así, enviará el tiempo introducido en el autenticador de Alice encriptado con la clave de sesión a Alice. El protocolo Kerberos en Windows 2000 se configura usando la Política de grupo para el dominio y sus parámetros son:
|
IPSec es un estándar para incluir funciones de seguridad en el nivel IP. Esto permitirá usar la seguridad por cualquier nivel superior de aplicación sin preocuparse de nada. Existen varios documentos RFC que definen este estándar:
Es obligatorio que IPv6 incluya estas características y opcional para IPv4 (IPSec). En ambos casos, las características de seguridad se implantan como cabeceras de ampliación que siguen a la cabecera IP principal. La cabecera de ampliación para autenticación se conoce como Cabecera de Autenticación (AH – "Authentication Header") y la correspondiente para seguridad como Cabecera de Encapsulado de seguridad de la Carga Útil (ESP – "Encapsulating Security Payload), o lo que es lo mismo, encapsulado de los datos. Como en toda comunicación encriptada, autenticada o donde se verifique la integridad de los datos, ambos extremos de la comunicación deben usar los mismos protocolos o mecanismos para implantar estas características. Esto hace posible la transmisión y recepción de la información. Ahora, podemos pensar, que cada sentido de la comunicación entre dos extremos es diferente. Veamos un ejemplo para entenderlo mejor. Higinio envía una carta de amor a su mujer Ana y no se fía de la profesionalidad del servicio de correos. Por este motivo, pone cada palabra sustituyendo cada letra por la inmediatamente siguiente en el alfabeto. Es decir, aplica un algoritmo de encriptado que en este caso no tiene clave. En destino, Ana leerá la carta si sabe el algoritmo de encriptado usado por su marido, sino sabe que algoritmo ha usado no podrá descifrarla. Por otro lado, Ana desea contestar a Higinio pero sospecha que el algoritmo usado por Higinio es fácilmente descifrable. Esto le lleva a usar otro algoritmo. Para ello suma a cada letra un número (clave) y el resultado será otra letra que sustituirá a la original en el texto cifrado. Si Higinio conoce el mecanismo/protocolo usado por Ana (suma de un número) y conoce la clave (número aplicado) podrá leer el contenido de las cartas que le lleguen procedentes de su mujer. A partir de este momento ambos podrán intercambiar cartas de amor y/o otra información confidencial confidencialmente y, además, ambos sentidos de la comunicación utilizan características de seguridad diferentes. En el IPSec a estas características de seguridad se le llama Asociación de seguridad. Una Asociación de seguridad es una relación en un solo sentido entre un emisor y un receptor. Si se necesita una relación paritaria, para un intercambio seguro en dos sentidos, entonces se requieren dos asociaciones de seguridad. No es ni más ni menos que identificar la forma y fondo de cómo realizar la seguridad (autenticación y/o privacidad) entre dos extremos. En IPSec se traduce en un campo denominado SPI (Security Parameter Index – Indice de parámetro de seguridad). Cuando a un extremo llega un paquete IPSec con cabeceras de seguridad, el receptor debe saber como obtener la información en claro. Para ello la cabecera lleva el SPI (Security Parameter Index) que le servirá para identificar la asociación de seguridad para descifrar la comunicación. En definitiva, cualquier implantación de IPSec debe proveer un mecanismo para almacenar la tabla (cuyo índice serán los SPI) con las asociaciones de seguridad que se estén usando. Así, una asociación de seguridad vendrá unívocamente determinada por la dirección destino y el SPI que es un valor de 32 bits. Como la especificación IPSec permite que las Asociaciones de seguridad puedan hacerse por host o por usuario. Aparece otro concepto que denominaremos Política de Seguridad. Mediante ella se establecerán las posibilidades de uso de cada Asociación de seguridad por parte de cada usuario o por parte de un host. Así, será tarea de dicha política especificar que Asociaciones de seguridad utiliza cada usuario. Una asociación de seguridad se compone fundamentalmente de estos elementos:
Una Asociación de seguridad podría ser la siguiente:
El intercambio de claves y el
negociado de la Asociación de seguridad se hace mediante los protocolos
ISAKMP/Oakley e IKE. Que veremos tras analizar el IPSec en
si. Autenticación IPSec – Opción AH La cabecera de autenticación proporciona un medio para garantizar la integridad de los datos y la autenticación de los paquetes IP. La cabecera de autenticación consta de los siguientes campos:
El contenido del campo de datos de autenticación dependerá del algoritmo usado al efecto. En cualquier caso, los datos de autenticación se calculan utilizando el paquete IP entero, poniendo a cero todos aquellos campos susceptibles de cambio en el transito. Por defecto, el algoritmo utilizado es el MD5. Se aplica sobre el paquete IP junto con una clave secreta y después se inserta en el paquete IP. En el destino, se llevan a cabo los mismos cálculos sobre el paquete IP con la clave secreta, obtenida del vinculo del SPI con una asociación de seguridad. Así, se proporciona integridad y autenticación.
El uso de esta cabecera proporciona privacidad e integridad de los datos de los paquetes IP. Dependiendo de los requisitos del usuario, este mecanismo se puede utilizar para encriptar bien el segmento de la capa de transporte (por ejemplo, TCP, UDP, ICMP), conocido como modo de transporte ESP o bien el paquete IP completo, conocido como túnel ESP. La cabecera ESP comienza con el valor SPI de 32 bits que identifica la asociación de seguridad. El resto de la cabecera puede contener parámetros del algoritmo de cifrado que se esta empleando. Parte de esta cabecera será transmitida en claro y parte cifrada. Modo transporte ESP El modo transporte ESP se utiliza para encriptar datos transportados por IP. Normalmente, estos datos son un segmento de la capa de transporte, como segmentos TCP o UDP, que a su vez contienen datos de la capa de aplicación. El funcionamiento es el siguiente: En el origen, el bloque de datos que consta de la parte final (la que va encriptada) de la cabecera ESP más el segmento entero de la capa de transporte, se encriptan y se reemplaza el texto original por el encriptado. El paquete es entonces encaminado al destino. Los nodos intermedios no necesitan saber el contenido encriptado. El nodo destino examina y procesa
la cabecera IP más cualquier cabecera de adicional. Obtiene el SPI de la
cabecera ESP y junto con la dirección destino determina la asociación de
seguridad con la que desencriptar la información. Este modo se utiliza para encriptar el paquete IP completo. Para este modo, el ESP se incorpora como prefijo al paquete y después, el paquete más una parte final de la cabecera, se encripta. Mediante este método es imposible realizar un análisis del tráfico. Como los datos de encaminamiento (dirección destino y opciones diversas) van encriptados es imposible transmitir el paquete tal cual. Para ello se encapsula en otro paquete IP con la información necesaria para realizar el encaminamiento pero no con información que sirva para analizar el tráfico. El algoritmo por defecto y
obligatorio para cualquier implantación de las cabeceras ESP es el
DES-CBC. Antes de que los datos sean
intercambiados de forma segura se debe iniciar una negociación entre las
partes para determinar la Asociación de seguridad que van a usar o, lo que
es lo mismo, los parámetros de seguridad que se van a usar.
Para esta negociación se utiliza el protocolo ISAKMP/Oakley. El ISAKMP centraliza la administración de las Asociaciones de seguridad y el Oakley genera y administra las claves usadas para proteger la información. El intercambio de claves y su generación se hacen usando el algoritmo Diffie-Hellman. Este algoritmo define como generar claves secretas entre dos o más entidades de forma segura. ISAKMP/Oakley funciona en dos fases diferentes. La primera fase se dedica a establecer un canal seguro entre ambos interlocutores, generando una asociación de seguridad denominada ISAKMP SA. En definitiva son los parámetros de seguridad que se van a usar en este protocolo. Una vez establecida esta fase, se negocian las Asociaciones de seguridad necesarias, en la segunda fase. En la primera fase se producen
los pasos siguientes:
Son cuatro parámetros obligatorios que son parte indiscutible de la ISAKMP SA:
Se realiza el intercambio de
claves según el algoritmo DH. Una vez realizado este intercambio ambas
partes generaran una clave que tan solo ellos conocen y que usaran para
el encriptado de la información, incluido el siguiente paso de esta
primera fase. 3. Autenticación. Se usa la clave generada en el paso anterior junto con los algoritmos y métodos especificados en la primera fase para autenticar a cada extremo de la comunicación. El iniciador ISAKMP presenta una oferta de Asociación de seguridad a su interlocutor. El que contesta puede aceptar la propuesta tal y como está o ofrecer una respuesta con alternativas. En la segunda fase se negocia la Asociación de seguridad necesaria para realizar la comunicación. Y sus pasos son:
Debe definir lo siguiente:
Llegan a un acuerdo sobre lo que se va a usar y se establecen dos Asociaciones de seguridad, una para cada sentido. 2. Refresco de las claves de sesión. Se refrescan las claves si es necesario 3. La Asociación de seguridad y las claves se pasa al driver IPSec junto con el SPI. Todo lo acontecido en esta fase se encripta usando la ISAKMP SA negociada en la primera fase. Se encripta toda la carga útil de los paquetes ISAKMP excepto su cabecera. Veamos ahora como se implanta
todo esto dentro de Windows 2000.
|
|
Para comunicarse con un ordenador remoto usando una política de seguridad IPSec podemos optar por tres configuraciones por defecto que trae Windows 2000:
Para determinar cuando se aplica la seguridad a los paquetes que se envían o reciben, existen el filtrado de paquetes y las reglas. Una regla define como y cuando IPSec es aplicada y contiene una lista de filtros IP y un conjunto de acciones de seguridad a realizar en el caso de que un paquete IP coincida con la lista de filtrado: Acciones de filtrado. Define si
se aplica una determinada política IPSec basándose en en la dirección IP
origen, destino y tipo de tráfico IP.
|
|
Cada uno de los filtros se deberá configurar en cada extremo de una comunicación. Cada filtro tiene los siguientes parámetros:
Las Acciones de filtrado lo que
definen son las características que se negocian en la segunda fase del
protocolo ISAKMP que hemos explicado. Puede definir, o que no se permite
el acceso a ningún paquete, o que se permite todo o que se negocia la
seguridad mediante los parámetros disponibles o que
configuremos:
|
|
Resumiendo, podemos definir que paquetes debemos asegurar mediante IPSec y que hacer con dichos paquetes. Dentro de una política podemos también definir el tipo de conexión (red de área local, acceso remoto o todas las conexiones), el método de autenticación que podrá ser por Certificados, Kerberos o por clave compartida.
|
