Administracin de la seguridad

SEGURIDAD EN LA TRANSMICIN
La confidencialidad de la informacin, especficamente de los usuarios que utilizan Internet es fundamental. La comunicacin entre las sucursales de una empresa u organizacin, la publicacin de informacin confidencial de una empresa, el compartir informacin estratgica, el ingreso en sitios Web, son solamente algunos ejemplos de contenido sensible que debe contar con las medidas de seguridad adecuadas para evitar problemas y no perder la privacidad y confianza. La seguridad de este tipo se basa en el hecho de poder encriptar los mensajes que se intercambian a travs de la red entre los servidores y los clientes, y que solo ellos puedan descifrar los contenidos a partir de una clave comn conocida solo por los dos. Para llevar a cabo esta seguridad se crearon diversos protocolos basados en esta idea, como son: PROTOCOLO SSH SSL Y TSL HTTPS IPSec DESCRIPCION
Usado exclusivamente en reemplazo de TELNET Usado principalmente en comunicaciones de hipertexto pero con posibilidad de uso en otros protocolos Usado exclusivamente para comunicaciones de hipertexto Usado como protocolo de seguridad de Internet

Tabla 3.1 Protocolos de Seguridad de Comunicacin

PROTOCOLO SSH (Secure Shell)

Este protocolo fue diseado para dar seguridad al acceso a computadores en forma remota. A diferencia de FTP o Telnet, SSH encripta la sesin de registro imposibilitando que alguien pueda obtener contraseas no encriptadas. SSH utiliza el puerto 22 para la comunicacin y la forma de efectuar su trabajo es muy similar al efectuado por SSL. SSH est diseado para reemplazar los mtodos ms viejos y menos seguros para registrarse remotamente en otro sistema a travs de la shell de comando, tales como telnet o rsh. Un programa relacionado, el scp, reemplaza otros programas diseados para copiar archivos entre hosts como rcp. Ya que estas aplicaciones antiguas no encriptan contraseas entre el cliente y el servidor, evite usarlas mientras le sea posible. El uso de mtodos seguros para registrarse remotamente a otros sistemas har disminuir los riesgos de seguridad tanto para el sistema cliente como para el sistema remoto Para su uso se requiere que por parte del servidor exista un demonio que mantenga continuamente en el puerto 22 el servicio de comunicacin segura, el sshd. El cliente debe ser un software tipo TeraTerm o Putty que permita hacer pedidos a este puerto 22 de forma cifrada. La forma en que se entabla una comunicacin es en base la misma para todos los protocolos seguros: El cliente enva una seal al servidor pidindole comunicacin por el puerto 22.

Administracin de la seguridad
El servidor acepta la comunicacin en el caso de poder mantenerla bajo encriptacin mediante un algoritmo definido y le enva la llave publica al cliente para que pueda descifrar los mensajes. El cliente recibe la llave teniendo la posibilidad de guardar la llave para futuras comunicaciones o destruirla despus de la sesin actual.

CARACTERISTICAS DE SSH SSH (o Secure SHell) es un protocolo para crear conexiones seguras entre dos sistemas usando una arquitectura cliente/servidor. El protocolo SSH proporciona los siguientes tipos de proteccin: Ofrece un mecanismote autentificacin de servidor a cliente adems de cifrado. Se utiliza cifrado asimtrico al comienzo, y simtricos una vez negociados y autentificados el cliente y el servidor. Da soporte a la integridad de los datos Despus de la conexin inicial, el cliente puede verificar que se est conectando al mismo servidor al que se conect anteriormente. El cliente transmite su informacin de autenticacin al servidor usando una encriptacin robusta de 128 bits. Todos los datos enviados y recibidos durante la conexin se transfieren por medio de encriptacin de 128 bits, lo cual los hacen extremamente difcil de descifrar y leer. El cliente tiene la posibilidad de enviar aplicaciones lanzadas desde el intrprete de comandos de la shell. Esta tcnica proporciona una interfaz grfica segura (llamada reenvo por X11), proporciona un medio seguro para usar aplicaciones grficas sobre una red.

Ya que el protocolo SSH encripta todo lo que enva y recibe, se puede usar para asegurar protocolos inseguros. El servidor SSH puede convertirse en un conducto para convertir en seguros los protocolos inseguros mediante el uso de una tcnica llamada reenvo por puerto, como por ejemplo POP, incrementando la seguridad del sistema en general y de los datos. Red Hat Linux contiene el paquete general de OpenSSH (openssh), el servidor de OpenSSH (openssh-server) y los paquetes de clientes (openssh-clients). Una gran cantidad de programas de cliente y servidor puede usar el protocolo SSH. Muchas aplicaciones SSH cliente estn disponibles para casi todos los principales sistemas operativos en uso hoy da, como por ejemplo el cliente Putty. POR QUE USAR SSH? Los usuarios tienen a su disposicin una variedad de herramientas interceptar y dirigir el trfico de la red para ganar acceso al sistema. En trminos generales, estas amenazas se pueden catalogar del siguiente modo: Intercepcin de la comunicacin entre dos sistemas: En este escenario, existe un tercero en algn lugar de la red entre entidades en comunicacin que hace una copia de la informacin que pasa entre ellas. La parte interceptora puede interceptar y conservar la informacin, o puede modificar la informacin y luego enviarla al recipiente al cual estaba destinada. Este ataque se puede montar a travs del uso de un paquete sniffer, una utilidad de red muy comn. Personificacin de un determinado host: con esta estrategia, un sistema interceptor finge ser el receptor a quien est destinado un mensaje. Si funciona la estrategia, el cliente no se da cuenta del engao y contina la comunicacin con el interceptor como si su mensaje hubiese llegado a su destino satisfactoriamente.

Administracin de la seguridad
Esto se produce con tcnicas como el envenenamiento del DNS o spoofing de IP. Ambas tcnicas causan que se intercepte informacin, posiblemente con propsitos hostiles. El resultado puede ser catastrfico. Si se utiliza SSH para inicios de sesin de shell remota y para copiar archivos, estas amenazas a la seguridad se pueden disminuir notablemente. Esto es porque el cliente SSH y el servidor usan firmas digitales para verificar su identidad. Adicionalmente, toda la comunicacin entre los sistemas cliente y servidor es encriptada. No servirn de nada los intentos de falsificar la identidad de cualquiera de los dos lados de la comunicacin ya que cada paquete est cifrado por medio de una clave conocida slo por el sistema local y el remoto. SSH VERSIN 1 Y SSH VERSIN 2 Como nada en este mundo es perfecto, existen dos versiones incompatibles del protocolo SSH: la versin 1.x (1.3 y 1.5) y la versin 2.0. Pasar de una versin a la otra no es complicado para el usuario, teniendo a mano el cliente correcto y el servidor correcto compatible con la versin. La versin 1 del protocolo SSH est integrada, mientras que la versin 2 ha definido el protocolo anterior en tres "capas": 1. Capa de transporte del protocolo SSH (SSH-TRANS) 2. Autentificacin del protocolo SSH (SSH-AUTH) 3. Conexin del protocolo SSH (SSH-CONN) Cada capa del protocolo est definida especficamente en un documento (borrador) normalizado por la IETF, seguido de un cuarto borrador que describe la arquitectura (Arquitectura del protocolo SSH, SSH-ARCH). Algunas caractersticas de SSHv2: 1. La capa de transporte proporciona integridad, cifrado, y compresin, la autentificacin de sistemas 2. La capa de autentificacin proporciona ... autentificacin (contrasea, basada en mquina, clave pblica) 3. La capa de conexin que gestiona el tnel (shell, agente SSH, redireccin de puertos, control del flujo). Las principales diferencias tcnicas entre la versin 1 de SSH y la versin 2 son: SSH Versin 1
Diseo monoltico (integrado) Integridad via CRC32 (no seguro) Un nico canal por sesin

SSH Versin 2
Separacin de las funciones de autentificacin, conexin y transporte en capas Integridad via HMAC (cifrado hash) Un nmero ilimitado de canales por sesin

Negociacin usando nicamente cifrado simtrico en Negociacin ms detallada (cifrado simtrico, llave el canal, identificacin de sesin con una nica clave pblica, compresin, ...), y una clave de sesin en ambos lados independiente, compresin e integridad en ambos lados Slo RSA para el algoritmo de clave pblica Clave de sesin transmitida por el cliente RSA y DSA para el algoritmo de clave pblica Clave de sesin negociada por el protocolo DiffieHellman Clave de sesin renovable

Clave de sesin vlida para toda la sesin

Tabla 3.2 Diferencias entre SSH1 y SSH2

Administracin de la seguridad
TIPOS DE CLAVES SSH Clave de usuario: un par de claves compuestas de una clave pblica y otra privada (ambas asimtricas), definidas por el usuario y permanentes (se guardan en el disco). Estas claves permiten la autentificacin de usuario si se utiliza el mtodo de autentificacin de clave pblica. Clave de mquina: tambin un par de claves compuestas de una llave pblica y otra privada (ambas asimtricas), pero definidas al instalar/configurar SSH por el administrador del servidor y permanentes (guardadas en el disco). Esta clave permite la autentificacin entre sistemas. Clave de servidor: de nuevo un par de claves compuestas de una clave pblica y otra privada (ambas asimtricas), pero generadas por un demonio al iniciarse y renovadas regularmente. Esta clave permanece en memoria para asegurar el intercambio de la clave de sesin en SSHv1 (con SSHv2, no hay clave de servidor ya que el intercambio se asegura con el protocolo Diffie-Hellman). Clave de sesin: esta es una clave secreta usada por el algoritmo de cifrado simtrico para cifrar el canal de comunicacin. Como es en todos los productos modernos de criptografa, la clave es aleatoria y perecedera. SSHv1 tiene una clave por sesin, en ambos lados. SSHv2 tiene dos claves de sesin regeneradas, una en cada lado. El usuario aade una frase de paso (pass phrase) que protege la parte privada de las anteriores claves. Esta proteccin se asegura cifrando el fichero que contiene la clave privada con un algoritmo simtrico. La clave secreta usada para cifrar el fichero se deriva de esta frase de paso. METODOS DE AUTENTIFICACIN Hay varios mtodos de autentificacin de usuario, la eleccin depende de la necesidades definidas en las polticas de seguridad. Los mtodos autorizados se activan o no en el fichero de configuracin del servidor. Aqu estn las principales categoras: "Similar a telnet": Este es el "tradicional" mtodo de la contrasea: al conectar, despus de haber introducido nuestro identificador, se le pide al usuario que introduzca una contrasea que se enva al servidor que la compara con la que tiene asociada a dicho usuario. El problema residual (el que causa una cifra astronmica actos delictivos en Internet) es que la contrasea se enva a la red en claro, y por lo tanto puede ser interceptada por cualquiera que tenga un simple "sniffer" (capturador de paquetes). En este caso SSH tiene la misma apariencia (es un modo fcil usuarios inexpertos que migran de telnet a SSH, ya que no hay nada nuevo que aprender ...), no obstante el protocolo SSH cifra el canal y la contrasea en claro se encapsula. Una variante incluso ms segura, configurable si uno tiene lo necesario en el servidor es el uso de una "Contrasea de un solo uso -- One time password" (S/Key por ejemplo): seguramente es mejor, obviamente ms seguro, pero las limitaciones de ergonoma lo hacen aplicable nicamente a situaciones particulares. Este sistema opera como sigue: despus de introducir nuestro identificador, en vez de preguntar al usuario una contrasea (esttica), el servidor enva un "desafo" al que el usuario debe responder. Dado que el desafo debe ser diferente, la respuesta debe tambin cambiar. En consecuencia, la interceptacin de la respuesta no es importante ya que no puede ser rehusada. La limitacin, como se mencion, viene esencialmente de la codificacin de la respuesta que debe ser calculada (por un token, software en el lado cliente, etc.), y la entrada es bastante "cabalstica" (seis monoslabos ingleses, en el mejor de los casos).

Administracin de la seguridad
FORMA DE OPERACIN DE SSH 1. Identificacin del servidor con su clave publica (no se debe confiar en una IP). Atencin a la primera vez 2. El cliente le pide una prueba 3. El servidor responde correctamente (EL SERVIDOR YA ESTA AUTENTICADO)

Fig. 3.1 Mecanismo de Operacin de SSH (I)

Una vez autenticado el servidor, y slo entonces, el cliente se autentifica: 4. El servidor, ya con una conexin segura (negociada antes) pide al cliente autenticarse. 5. El cliente le responde, puede autenticarse mediante: Keberos, publickey, y contrasea entre otros. 6. Si el cliente responde de forma correcta, la conexin se permite y esta ser cifrada, y con verificacin de integridad.

Administracin de la seguridad
Por lo tanto SSH nos ofrece un servicio de acceso seguro y con garanta de integridad.

Fig. 3.2 Mecanismo de Operacin SSH (II)

El protocolo SSH nos protege fsicamente de un corte de comunicacin y a nivel de transporte de que se resetee una conexin falsificando segmentos TCP de forma adecuada. REDIRECCIONAMIENTO DE PUERTOS SSH permite la redireccin (forwarding) de cualquier flujo de datos TCP a travs de un "tnel" en una sesin SSH. Esto significa que el flujo de datos de la aplicacin, en vez de ser gestionada directamente por los puertos del servidor y el cliente, es "encapsulada" en un "tnel" creado al conectar (inicio de sesin). Esto mismo se hace con el protocolo X11 sin ningn esfuerzo especial (por parte del usuario), con un manejo transparente de los displays y la capacidad de propagarse continuamente cuando se realizan varias conexiones Existen muchos protocolos que no tienen implementados mecanismos de cifrados. Se puede bien utilizar un protocolo nuevo que soporten cifrados, o bien protocolos de nivel inferior (SSL o IPSec). El problema es que estas soluciones requieren o bien un protocolo nuevo, o bien una configuracin ms o menos complicada en el extremo servidor y en el extremo cliente. Mediante SSH, sabemos que podemos crear una conexin segura o tnel entre el

Administracin de la seguridad
cliente SSH y el servidor SSH; de lo que se trata es de usar esa conexin para crear un tnel por el que pueda transportar una conexin no segura. Ejemplo de Redireccionamiento de puerto utilizando POP El primer paso consiste en realizar la conexin con los parmetros que permitan crear el tnel.

Fig. 3.3 Parmetros para crear una conexin

En un extremo (Cliente o Servidor) se crea la cabecera del tnel en el otro la salida.

Fig. 3.4 Redireccionamiento completo para POP

Administracin de la seguridad
La figura 3.5 presenta una forma mas simplificada de un redireccionamiento de un servidor de correo.

Fig. 3.5 Simplificacin del Redireccionamiento

El tnel de comunicacin se puede iniciar en el cliente ssh (como se ha visto anteriormente) o tambin en el servidor (Hacia el cliente ssh) El redireccionamiento de puertos puede plantear problemas de seguridad.[www.006]

PROTOCOLO SSL (Secure Socket Layer)

Son protocolos criptogrficos que proporcionan comunicaciones seguras en Internet. Existen pequeas diferencias entre SSL 3.0 y TLS 1.0, pero el protocolo permanece sustancialmente igual. El trmino "SSL" segn se usa aqu, se aplica a ambos protocolos a menos que el contexto indique lo contrario. Secure Socket Layer es un sistema de protocolos de caracter general diseado en 1994 por la empresa Nestcape Communcations Corporation, y est basado en la aplicacin conjunta de Criptografa Simtrica, Criptografa Asimtrica (de llave pblica), certificados digitales y firmas digitales para conseguir un canal o medio seguro de comunicacin a travs de Internet. De los sistemas criptogrficos simtricos, motor principal de la encriptacin de datos transferidos en la comunicacin, se aprovecha la rapidez de operacin, mientras que los sistemas asimtricos se usan para el intercambio seguro de las claves simtricas, consiguiendo con ello resolver el problema de la Confidencialidad en la transmisin de datos. SSL implementa un protocolo de negociacin para establecer una comunicarcin segura a nivel de soket (nombre de la maquina mas puerto) de forma transparente al usuario y a las aplicaciones que lo usan, trabaja una capa por debajo de HTTP por lo que permite ser usado no tan solo para proteger documentos de hipertexto sino tambin servicios como FTP, SMTP, TELNET entre otros. La idea que persigue SSL es encriptar la comunicacin entre servidor y cliente mediante el uso de llaves y algoritmos de encriptacin. Actualmente es el estndar de comunicacin segura en los navegadores Web ms importantes (protocolo HTTP), como Nestcape Navigator e Internet Explorer, y se espera que pronto se saquen versiones para otras otros protocolos de la capa de Aplicacin (correo, FTP, etc.).

Administracin de la seguridad
La identidad del servidor Web seguro (y a veces tambin del usuario cliente) se consigue mediante el Certificado Digital correspondiente, del que se comprueba su validez antes de iniciar el intercambio de datos sensibles (Autenticacin), mientras que de la seguridad de Integridad de los datos intercambiados se encarga la Firma Digital mediante funciones hash y la comprobacin de resmenes de todos los datos enviados y recibidos. Desde el punto de vista de su implementacin en los modelos de referencia OSI y TCP/IP, SSL se introduce como una especie de nivel o capa adicional, situada entre la capa de Aplicacin y la capa de Transporte, sustituyendo los sockets del sistema operativo, lo que hace que sea independiente de la aplicacin que lo utilice, y se implementa generalmente en el puerto 443.

Fig. 3.6 Aplicacin de SSL en el modelo OSI y TCP/IP

SSL proporciona servicios de seguridad a la pila de protocolos, encriptando los datos salientes de la capa de Aplicacin antes de que estos sean segmentados en la capa de Transporte y encapsulados y enviados por las capas inferiores. Es ms, tambin puede aplicar algoritmos de compresin a los datos a enviar y fragmentar los bloques de tamao mayor a 214 bytes, volvindolos a reensamblarlos en el receptor. Habitualmente, slo el servidor es autentificado (es decir, se garantiza su identidad) mientras que el cliente se mantiene sin autentificar; la autentificacin mutua requiere un despliegue de infraestructura de claves pblicas (o PKI) para los clientes. Los protocolos permiten a las aplicaciones cliente-servidor comunicarse de una forma diseada para prevenir escuchas (eavesdropping), la falsificacin de la identidad del remitente y mantener la integridad del mensaje. El protocolo TLS esta basado en SSL y son similares en el modo de operar. Es importante sealar que ambos protocolos se ejecutan sobre una capa de transporte definida, pero no determinada. Esto indica que pueden ser utilizados para cualquier tipo de comunicaciones. La capa de transporte ms usada es TCP cobre la cual pueden implementar seguridad en HTTP. Como punto de diferencia se puede mencionar que existen protocolos implementados sobre la capa de red, por ejemplo sobre IP. Tal es el caso de IPSec. SSL implica una serie de fases bsicas: Negociar entre las partes el algoritmo que se usar en la comunicacin Intercambio de claves pblicas y autenticacin basada en certificados digitales Encriptacin del trfico basado en cifrado simtrico

Durante la primera fase, el cliente y el servidor negocian qu algoritmos criptogrficos se van a usar. Las implementaciones actuales proporcionan las siguientes opciones:

Administracin de la seguridad
Para criptografa de clave pblica: RSA, Diffie-Hellman, DSA (Digital Signature Algorithm) o Fortezza; Para cifrado simtrico: RC2, RC4, IDEA (International Data Encryption Algorithm), DES (Data Encryption Standard), Triple DES o AES (Advanced Encryption Standard); Con funciones hash: MD5 o de la familia SHA.

La versin ms actual de SSL es la 3.0. que usa los algoritmos simtricos de encriptacin DES, TRIPLE DES, RC2, RC4 e IDEA, el asimtrico RSA, la funcin hash MD5 y el algoritmo de firma SHA-1. Los algoritmos, longitudes de clave y funciones hash de resumen usados en SSL dependen del nivel de seguridad que se busque o se permita, siendo los ms habituales los siguientes: RSA + Triple DES de 168 bits + SHA-1: soportado por las versiones 2.0 y 3.0 de SSL, es uno de los conjuntos ms fuertes en cuanto a seguridad, ya que son posibles 3.7 * 1050 claves simtricas diferentes, por lo que es muy dificil de romper. Por ahora slo est permitido su uso en Estados Unidos, aplicndose sobre todo en transacciones bancarias. RSA + RC4 de 128 bits + MD5: soportado por las versiones 2.0 y 3.0 de SSL, permite 3.4 * 10 38 claves simtricas diferentes que, aunque es un nmero inferior que el del caso anterior, da la misma fortaleza al sistema. Anlogamente, en teora slo se permite su uso comercial en Estados Unidos, aunque actualmente ya es posible su implementacin en los navegadores ms comunes, siendo usado por organismos gubernamentales, grandes empresas y entidades bancarias. [www.009] RSA + RC2 de 128 bits + MD5: soportado slo por SSL 2.0, permite 3.4 * 10 38 claves simtricas diferentes, y es de fortaleza similar a los anteriores, aunque es ms lento a la hora de operar. Slo se permite su uso comercial en Estados Unidos, aunque actualmente ya es posible su implementacin en los navegadores ms comunes. RSA + DES de 56 bits + SHA-1: soportado por las versiones 2.0 y 3.0 de SSL, aunque es el caso de la versin 2.0 se suele usar MD5 en vez de SHA-1. Es un sistema menos seguro que los anteriores, permitiendo 7.2 * 10 16 claves simtricas diferentes, y es el que suelen traer por defecto los navegadores Web en la actualidad (en realidad son 48 bits para clave y 8 para comprobacin de errores). RSA + RC4 de 40 bits + MD5: soportado por las versiones 2.0 y 3.0 de SSL, ha sido el sistema ms comn permitido para exportaciones fuera de Estados Unidos. Permite aproximadamente 1.1 * 10 12 claves simtricas diferentes, y una velocidad de proceso muy elevada, aunque su seguridad es ya cuestionable con las tcnicas de Criptoanlisis actuales. RSA + RC2 de 40 bits + MD5: en todo anlogo al sistema anterior, aunque de velocidad de proceso bastante inferior. Slo MD5: usado solamente para autentificar mensajes y descubrir ataques a la integridad de los mismos. Se usa cuando el navegador cliente y el servidor no tienen ningn sistema SSL comn, lo que hace imposible el establecimiento de una comunicacin cifrada. No es soportado por SSL 2.0, pero si por la versin 3.0. La clave de encriptacin simtrica es nica y diferente para cada sesin, por lo que si la comunicacin falla y se debe establecer una nueva sesin SSL, la contrasea simtrica se generar de nuevo. SSL proporciona cifrado de alto nivel de los datos intercambiados (se cifran incluso las cabeceras HTTP), autenticacin del servidor (y si es necesario tambin del cliente) e integridad de los datos recibidos. Durante el proceso de comunicacin segura SSL existen dos estados fundamentales, el estado de sesin y el estado de conexin. A cada sesin se le asigna un nmero identificador arbitrario, elegido por el servidor, un mtodo de compresin de datos, una serie de algoritmos de encriptacin y funciones hash, una clave secreta maestra de 48 bytes y un flag de nuevas conexiones, que indica si desde la sesin actual se pueden establecer nuevas conexiones. Cada conexin incluye un nmero secreto para el cliente y otro para el servidor, usados para calcular los MAC de sus mensajes, una

10

Administracin de la seguridad
clave secreta de encriptacin particular para el cliente y otra para el servidor, unos vectores iniciales en el caso de cifrado de datos en bloque y unos nmeros de secuencia asociados a cada mensaje. ARQUITECTURA DE SSL SSL trabaja sobre el protocolo TCP y por debajo de protocolos como HTTP, IMAP, LDAP, etc., y puede ser usado por todos ellos de forma transparente para el usuario. Opera entre la capa de transporte y la de sesin del modelo OSI (o entre la capa de transporte y la de aplicacin del modelo TCP) y est formado, a su vez, por dos capas y cuatro componentes bien diferenciados.

Fig. 3.7 Arquitectura SSL

1. El protocolo de registro (Record Protocol) es inmediatamente superior a TCP y proporciona una comunicacin segura, se encarga de encapsular el trabajo de los elementos de la capa superior, construyendo un canal de comunicaciones entre los dos extremos objeto de la comunicacin. Principalmente esta capa toma los mensajes y los codifica con algoritmos de encriptacin de llave simtrica como DES, RC4 aplicndole una MAC (Message Authentication Code) para verificar la integridad , logrando as encapsular la seguridad para niveles superiores. 2. El verdadero corazn de SSL est en el protocolo de Handshake que es el encargado de intercambiar la clave que se utilizar para crear un canal seguro

11

Administracin de la seguridad
mediante un algoritmo eficiente de cifrado simtrico. Tambin es responsabilidad de este protocolo coordinar los estados de ambos extremos de la transmisin. 3. El protocolo de Alerta es el encargado de sealizar problemas y errores concernientes a la sesin SSL establecida. 4. Por ltimo, el Change Cipher Spec Protocol est formado por un nico mensaje consistente en un nico byte de valor 1 y se utiliza para notificar un cambio en la estrategia de cifrado. A grandes rasgos, podramos decir que SSL trabaja de la siguiente forma: En primer lugar intercambiamos una clave de longitud suficiente mediante un algoritmo de cifrado asimtrico. Mediante esa clave establecemos un canal seguro utilizando para ello un algoritmo simtrico previamente negociado. A continuacin, toma los mensajes a ser transmitidos, los fragmenta en bloques, los comprime, aplica un algoritmo hash para obtener un resumen (MAC) que es concatenado a cada uno de los bloques comprimidos para asegurar la integridad de los mismos, realiza el cifrado y enva los resultados. El estado de todas estas operaciones son controladas mediante una mquina de control de estados.

Una sesin SSL puede comprender mltiples conexiones. Adicionalmente, se pueden establecer mltiples sesiones SSL simultaneas. [www.010] FUNCIONAMIENTO DE SSL 1. El protocolos SSL esta basado en capas, al igual que la familia de protocolos de TCP/IP. 2. La capa de los mensajes incluye longitud, descripcin y contenido. 3. SSL toma los mensajes que debe transmitirse, divide los datos en bloques manejables, comprime los datos si se los desea, aplica un MAC, cifra y transmite el resultado en forma de un registro SSL 4. El receptor debe procesar los datos de forma anloga, es decir son descifrados, verificados y descomprimidos (si fueron comprimidos) y reensamblarlos.

Fig. 3.8 Funcionamiento de SSL

En resumidas cuentas, despus que se solicita una comunicacin segura, servidor y el cliente se deben poner de acuerdo en como se comunicaran (SSL Handshake) para luego comenzar la comunicacin encriptada. Luego de terminada la transaccin, SSL termina. Solicitud de SSL:

12

Administracin de la seguridad
Tpicamente este proceso ocurre en el momento que un cliente accede a un servidor seguro, identificado con "https://...". pero como se mencion, no necesariamente es usado para HTTP. La comunicacin se establecer por un puerto distinto al utilizado por el servicio normalmente. Luego de esta peticin, se procede al SSL Handshake. SSL Handshake: En este momento, servidor y cliente se ponen de acuerdo en varios parmetros de la comunicacin. Se puede dividir el proceso en distintos pasos: Client Hello: El cliente se presenta. Le pide al servidor que se presente (certifique quien es)y le comunica que algoritmos de encriptacin soporta y le enva un nmero aleatorio para el caso que el servidor no pueda certificar su validez y que aun as se pueda realizar la comunicacin segura. Server Hello: El servidor se presenta. Le responde al cliente con su identificador digital encriptado, su llave pblica, el algoritmo que se usar, y otro nmero aleatorio. El algoritmo usado ser el ms poderoso que soporte tanto el servidor como el cliente. Aceptacin del cliente: El cliente recibe el identificador digital del servidor, lo desencripta usando la llave pblica tambin recibida y verifica que dicha identificacin proviene de una empresa certificadora segura. Luego se procede a realizar verificaciones del certificado (identificador) por medio de fechas, URL del servidor, etc. Finalmente el cliente genera una llave aleatoria usando la llave pblica del servidor y el algoritmo seleccionado y se la enva al servidor. Verificacin: Ahora tanto el cliente y el servidor conocen la llave aleatoria (El cliente la gener y el servidor la recibi y desencript con su llave privada). Para asegurar que nada ha cambiado, ambas partes se envan las llaves. Si coinciden, el Handshake concluye y comienza la transaccin.

Intercambio de Datos: Desde este momento los mensajes son encriptados con la llave conocida por el servidor y el cliente y luego son enviados para que en el otro extremo sean desencriptados y ledos Terminacin de SSL Cuando el cliente abandona el servidor, se le informa que terminara la sesin segura para luego terminar con SSL.

13

Administracin de la seguridad

Fig 3.9 Esquema del proceso Handshake

PROTOCOLO TLS (Transport Layer Security )

Se construye a partir de las especificaciones de SSL 3.0 y son tan semejantes que a veces se lo conoce como SSL 3.1. Por decirlo con las propias palabras de los autores el protocolo TLS est basado en las especificaciones de SSL 3.0 publicadas por Netscape. Las diferencias entre este protocolo y SSL 3.0 no son grandes, pero si suficientes para que TLS 1.0 y SSL 3.0 no puedan interoperar (aunque TLS incorpora un mecanismo mediante el cual una implementacin de TLS puede trabajar con SSL 3.0).

Las principales diferencias entre SSL 3.0 y TLS 1.0 son las siguientes: En los mensajes Certificate Request y Certificate Verify del protocolo de Handshake. En SSL 3.0 si el servidor solicita un certificado al cliente para que se autentique, este debe de responder con el o con un mensaje de alerta advirtiendo de que no lo tiene. En TLS 1.0 si el cliente no posee certificado no responde al servidor de ninguna forma a este requerimiento. Clculo de las claves de sesin. El mecanismo utilizado para construir las claves de sesin es ligeramente diferente en TLS 1.0. TLS 1.0 no soporta el algoritmo de cifrado simtrico FORTEZZA que si es soportado por SSL 3.0. Esto es debido a que TLS busca ser ntegramente pblico mientras que FORTEZZA es un algoritmo propietario. TLS utiliza un mecanismo diferente y ms seguro en el clculo del MAC.

14

Administracin de la seguridad
TLS 1.0 introduce nuevos cdigos de alerta no contemplados por SSL 3.0 TLS 1.0 introduce un nuevo mecanismo en el relleno de los bloques para frustrar ataques basados en el anlisis de la longitud de los mensajes.

PROTOCOLO SHTTP
El protocolo Secure HTTP fue desarrollado por Enterprise Integration Technologies, EIT, y al igual que SSL permite tanto el cifrado de documentos como la autenticacin mediante firma y certificados digitales, pero se diferencia de SSL en que se implementa a nivel de aplicacin. Se puede identificar rpidamente a una pgina Web servida con este protocolo porque la extensin de la misma pasa a ser .shtml en vez de .html como las pginas normales. El mecanismo de conexin mediante S-HTTP, que ahora se encuentra en su versin 1.1, comprende una serie de pasos parecidos a los usados en SSL, en los que cliente y servidor se intercambian una serie de datos formateados que incluyen los algoritmos criptogrficos, longitudes de clave y algoritmos de compresin a usar durante la comunicacin segura. En cuanto a estos algoritmos, lo usados normalmente son RSA para intercambio de claves simtricas, MD2, MD5 o NIST-SHS como funciones hash de resumen, DES, IDEA, RC4 o CDMF como algoritmos simtricos y PEM o PKCS-7 como algoritmos de encapsulamiento. A diferencia de SSL, el protocolo S-HTTP est integrado con HTTP, actuando a nivel de aplicacin, como ya hemos dicho, negocindose los servicios de seguridad a travs de cabeceras y atributos de pgina, por lo que los servicios S-HTTP estn slo disponibles para el protocolo HTTP. Recordemos que SSL puede ser usado por otros protocolos diferentes de HTTP, pus se integra a nivel de shocked. Las principales ventajas de S-HTTP son su flexibilidad y su integracin dentro de HTML (extensiones al lenguaje similares a las introducidas peridicamente por Netscape Co. en sus navegadores). Entre sus debilidades podemos sealar los efectos derivados de mantener la compatibilidad hacia atrs y la necesidad de implementar servidores que soporten las extensiones a HTML aportadas por el protocolo S-HTTP.

PROTOCOLO DE SEGURIDAD IP (IPSec)

IPSec (Internet Protocol Security) es en realidad un conjunto de estndares abiertos para garantizar comunicaciones privadas y seguras a travs de redes IP mediante el uso de funciones de seguridad basadas en criptografa. Es un estndar de la IETF (Internet Engineering Task Force) definido en el RFC 2401. Provee servicios de seguridad como autenticacin, integridad, control de acceso, confidencialidad, y proteccin frente a reenvo . Combinando tecnologas de clave pblica RSA, algoritmos de cifrado(DES, 3DES, IDEA, Bolwfish), algoritmos de hash (MD5, SHA-1) y certificados digitales. Es implementado en la capa de Red, de tal forma que su funcionamiento es completamente transparente al nivel de aplicaciones, y es mucho ms poderoso. IPSec provee un mecanismo estndar, robusto y con posibilidades de expansin, para proveer seguridad al protocolo IP y protocolos de capas superiores IPSec est soportado en Windows Server 2003, Windows XP, y Windows 2000, y est integrado con el servicio de Directorio Activo. Las polticas IPSec se pueden asignar mediante Polticas de Grupo, lo que permite que los parmetros de IPSec se configuren a nivel de dominio, site o unidad organizativa. El objetivo principal de IPSec es proporcionar proteccin a los paquetes IP. IPSec est basado en un modelo de seguridad de extremo a extremo, lo que significa que los nicos hosts que tienen que conocer la proteccin de IPSec son el que enva y el que recibe. Cada equipo controla la seguridad por s mismo en su extremo, bajo la hiptesis de que el medio por el que se establece la comunicacin no es seguro.

15

Administracin de la seguridad
IPSec aumenta la seguridad de los datos de la red mediante: La autenticacin mutua de los equipos antes del intercambio de datos. IPSec puede utilizar Kerberos V5 para la autenticacin de los usuarios. El establecimiento de una asociacin de seguridad entre los dos equipos. IPSec se puede implementar para proteger las comunicaciones entre usuarios remotos y redes, entre redes e, incluso, entre equipos cliente dentro de una red de rea local (LAN). El cifrado de los datos intercambiados mediante Cifrado de datos estndar (DES, Data Encryption Standard), triple DES (3DES) o DES de 40 bits. IPSec usa formatos de paquete IP estndar en la autenticacin o el cifrado de los datos. Por tanto, los dispositivos de red intermedios, como los enrutadores, no pueden distinguir los paquetes de IPSec de los paquetes IP normales.

VENTAJAS Y DESVENTAJAS DE IPSec Compatibilidad con la infraestructura de claves pblicas. Tambin acepta el uso de certificados de claves pblicas para la autenticacin, con el fin de permitir relaciones de confianza y proteger la comunicacin con hosts que no pertenezcan a un dominio Windows 2000 en el que se confa. Compatibilidad con claves compartidas. Si la autenticacin mediante Kerberos V5 o certificados de claves pblicas no es posible, se puede configurar una clave compartida (una contrasea secreta compartida) para proporcionar autenticacin y confianza entre equipos. Transparencia de IPSec para los usuarios y las aplicaciones. Como IPSec opera al nivel de red, los usuarios y las aplicaciones no interactan con IPSec Administracin centralizada y flexible de directivas mediante Directiva de grupo. Cuando cada equipo inicia una sesin en el dominio, el equipo recibe automticamente su directiva de seguridad, lo que evita tener que configurar cada equipo individualmente. Sin embargo, si un equipo tiene requisitos exclusivos o es independiente, se puede asignar una directiva de forma local. Estndar abierto del sector. IPSec proporciona una alternativa de estndar industrial abierto ante las tecnologas de cifrado IP patentadas. Los administradores de la red aprovechan la interoperabilidad resultante.

La nica desventaja que se le ve a IPSec por el momento, es la dificultad de configuracin con sistemas Windows. Windows 2000 y Windows XP proveen herramientas para configurar tneles con IPSec, pero su configuracin es bastante difcil (Microsoft nombra a todas las cosas en forma diferente de lo estndar).

Limitaciones de IPSec IPSec no es seguro si el sistema no lo es: Los gateways de seguridad deben estar en perfectas condiciones para poder confiar en el buen funcionamiento de IPSec. IPSec no provee seguridad de usuario a usuario: IPSec no provee la misma clase de seguridad que otros sistemas de niveles superiores. Por ejemplo, el GPG que se utiliza para cifrar mensajes de correo electrnico, si lo que se necesita es que los datos de un usuario los pueda leer otro usuario, IPSec no asegura esto y se tendr que utilizar otro mtodo. IPSec autentica mquinas, no usuarios: el concepto de identificacin y contrasea de usuarios no es entendido por IPSec, si lo que se necesita es limitar el acceso a recursos dependiendo del usuario que quiere ingresar, entonces habr que utilizar otros mecanismos de autenticacin en combinacin con IPSec.

16

Administracin de la seguridad
IPSec no evita los ataques DoS: estos ataques se basan en sobrecargar la mquina atacada de tal modo de que sus usuarios no puedan utilizar los servicios que dicha mquina les provee.

CARACTERISTICAS DE SEGURIDAD DE IPSec Las siguientes caractersticas de IPSec afrontan todos estos mtodos de ataque: Protocolo Carga de seguridad de encapsulacin (ESP, Encapsulating Security Payload). ESP proporciona privacidad a los datos mediante el cifrado de los paquetes IP. Claves basadas en criptografa. Las claves cifradas, que se comparten entre los sistemas que se comunican, crean una suma de comprobacin digital para cada paquete IP. Cualquier modificacin del paquete altera la suma de comprobacin, mostrando al destinatario que el paquete ha sido cambiado en su trnsito. Se utiliza material de claves diferente para cada segmento del esquema de proteccin global y se puede generar nuevo material de claves con la frecuencia especificada en la directiva de IPSec. Administracin automtica de claves. La claves largas y el cambio dinmico de claves durante las comunicaciones ya establecidas protegen contra los ataques. IPSec usa el protocolo Asociacin de seguridad en Internet y administracin de claves (ISAKMP, Internet Security Association and Key Management Protocol) para intercambiar y administrar dinmicamente claves cifradas entre los equipos que se comunican. Negociacin de seguridad automtica. IPSec usa ISAKMP para negociar de forma dinmica un conjunto de requisitos de seguridad mutuos entre los equipos que se comunican. No es necesario que los equipos tengan directivas idnticas, slo una directiva configurada con las opciones de negociacin necesarias para establecer un conjunto de requisitos con otro equipo. Seguridad a nivel de red. IPSec existe en el nivel de red, proporcionando seguridad automtica a todas las aplicaciones. Autenticacin mutua. IPSec permite el intercambio y la comprobacin de identidades sin exponer la informacin a la interpretacin de un atacante. La comprobacin mutua (autenticacin) se utiliza para establecer la confianza entre los sistemas que se comunican. Slo los sistemas de confianza se pueden comunicar entre s. Los usuarios no tienen que estar en el mismo dominio para comunicar con la proteccin de IPSec. Pueden estar en cualquier dominio de confianza de la empresa. La comunicacin se cifra, lo que dificulta la identificacin e interpretacin de la informacin. Filtrado de paquetes IP. Este proceso de filtrado habilita, permite o bloquea las comunicaciones segn sea necesario mediante la especificacin de intervalos de direcciones, protocolos o, incluso, puertos de protocolo especficos.

ARQUITECTURA DE IPSec La arquitectura de IPSec define la granularidad con la que el usuario puede especificar su poltica de seguridad. Permite que cierto trfico sea identificado para recibir el nivel de proteccin deseado.

17

Administracin de la seguridad

Fig 3.10 Tneles de comunicacin protegidos por IPSec entre redes separadas

IPSec est diseado para proveer seguridad interoperable de alta calidad basada en criptografa, tanto para IPv4 como para IPv6. Est compuesto por dos protocolos de seguridad de trfico, el Authentication Header (AH) y el Encapsulating Security Payload (ESP), adems de protocolos y procedimientos para el manejo de llaves encriptadas. AH provee la prueba de los datos de origen en los paquetes recibidos, la integridad de los datos, y la proteccin contrarespuesta. ESP provee lo mismo que AH adicionando confidencialidad de datos y de flujo de trfico limitado. En la Fig 3.10 se aprecia la arquitectura de IPSec. Al utilizar el mecanismo de AH se aplican algoritmos de autenticacin, con la aplicacin del mecanismo ESP, adems de autenticacin, tambin algoritmos de encriptacin. El esquema de interoperabilidad se maneja a travs de Asociaciones de Seguridad (SA), almacenadas en una base de datos. Los parmetros que se negocian para establecer los canales seguros se denominan Dominio de Interpretacin IPSec (Domain of Interpretation, DOI), bajo polticas pre-establecidas dentro de un esquema de funcionamiento esttico con valores fijos y previamente establecidos, o bien, en un esquema de funcionamiento dinmico utilizando un protocolo de manejo de llaves, Interchange Key Exchange (IKE).

Fig 3.11 Arquitectura de IPSec

18

Administracin de la seguridad
PROTOCOLO AH Es el procedimiento previsto dentro de IPSec para garantizar la integridad y autenticacin de los datagramas IP. Proporciona un medio al receptor de los paquetes IP para autenticar el origen de los datos y para verificar que dichos datos no han sido alterados en transito. Sin embargo no proporciona ninguna garanta de confidencialidad, es decir, los datos transmitidos pueden ser vistos por terceros. Es importante indicar que AH asegura la integridad y autenticidad de los datos transportados y de la cabecera IP.[www. 0.13]

Fig 3.12 Funcionamiento del protocolo AH

PROTOCOLO ESP El objetivo principal del protocolo ESP (Encapsulating Security Payload) es proporcionar confidencialidad, para esto especifica el modo de cifrar los datos que se desean enviar y como este contenido cifrado se incluyen en un datagrama IP. Adicionalmente puede ofrecer los servicios de integridad y autenticacin del origen de los datos incorporando un mecanismo similar al de AH.

Fig. 3.13 Funcionamiento del protocolo ESP

19

Administracin de la seguridad
PROTOCOLO IKE El IETF a definido el protocolo IKE para realizar la funcin de gestin automtica de claves como el establecimiento de las SAs correspondientes. Una caracterstica importante de IKE es que su utilidad no se limita a IPSec, si no que es un protocolo estndar de gestin de claves que podra ser til en otros protocolos como por ejemplo: OSPF, RIPv2. Consiste en establecer una conexin cifrada y autenticada entre dos entidades, a travs de la cual se negocian los parmetros necesarios para establecer una asociacin de seguridad IPSec.

Fig 3.14 Funcionamiento de IKE

Los servicios que ofrecen los componentes principales de IPSec son los siguientes: AH
Control de acceso

ESP (solo encriptacin) X

ESP (encriptacin mas autentificacin) X X X X X X

X X Autentificacin en el origen de X
Integridad de la conexin los datos Rechazo de paquetes retocados Confidencialidad Confidencialidad limitada por el trfico Tabla 3.3 Servicios de IPSec

X X X

FUNCIONAMIENTO DE IPSec

El diseo de IPSec plantea dos formas de funcionamiento para sus protocolos: modo de transporte y modo de tnel, la diferencia se ve en la unidad que se esta protegiendo en modo transporte se protege la carga til IP (capa de transporte), en modo tnel se protegen paquetes IP (capa de red) y se pueden implementar tres combinaciones: AH en modo transporte, ESP en modo transporte, ESP en modo tnel (AH en modo tnel tiene el mismo efecto que en modo transporte).

20

Administracin de la seguridad
Modo Transporte: la encriptacin se realiza extremo a extremo, es decir del host de origen al host de destino. Para extender en una empresa el uso de IPSec en modo transporte es necesario que todos los hosts tengan una implementacin de IPSec.

Fig. 3.15 Aplicacin de IPSec modo transporte

Los paquetes de la capa de transporte como TCP y UDP pasan a la capa de red, que agrega el encabezado IP y pasa a las capas inferiores; cuando se habilita IPSec en modo transporte, los paquetes de la capa de transporte pasan al componente de IPSec (que es implementado como parte de la capa de red, en el caso de sistemas operativos), el componente de IPSec agrega los encabezados AH y/o ESP, y la capa de red agrega su encabezado IP. En el caso que se apliquen ambos protocolos, primero debe aplicarse la cabecera de ESP y despus de AH, para que la integridad de datos se aplique a la carga til de ESP que contiene la carga til de la capa de transporte, esto se muestra en la Fig. 3.13. [www. 012]

Fig. 3.16 Formato del paquete con AH y ESP

Modo Tnel: el encriptado se efecta nicamente entre los routers de acceso a los hosts implicados. En este caso la informacin viaja no encriptada en la parte de la red local. El funcionamiento de IPSec en modo tnel permite integrar de forma elegante IPSec en una VPN, ya que el mismo dispositivo que realiza el tnel VPN se encarga de realizar las labores correspondientes al tnel IPSec

Fig. 3.17 Aplicacin de IPSec modo tnel

IPSec en modo tnel, tiene dos encabezados IP, interior y exterior. El encabezado interior es creado por el host y el encabezado exterior es agregado por el dispositivo que est proporcionando los servicios de seguridad. IPSec encapsula el paquete IP con los encabezados de IPSec y agrega un encabezado exterior de IP como se muestra en la Fig. 3.14

21

Administracin de la seguridad

Fig 3.18 Formato del paquete aplicando IPSec en modo tnel

Evidentemente el modo transporte es ms fiable puesto que ofrece comunicacin segura host a host. Sin embargo el modo tnel tiene la ventaja de que permite incorporar la seguridad sin necesidad de incorporar IPSec en los hosts; aunque la seguridad que se obtiene en este caso no es tan alta la sencillez de implantacin es mucho mayor y se consiguen la mayor parte de los beneficios del modo transporte, ya que se protege la parte ms expuesta del trayecto, que corresponde precisamente a la infraestructura pblica o del operador. En funcin de las circunstancias que rodeen cada caso se deber optar por una u otra, pudiendo haber incluso situaciones hbridas en las que en una misma empresa determinado tipo de informacin baste protegerla con el modo tnel mientras que para algn host concreto, que maneje informacin de mayor importancia, se deba utilizar el modo transporte. Aunque en IPSec se prev la posibilidad de utilizar una amplia diversidad de algoritmos de autentificacin y encriptado el nico exigido para todas las implementaciones es el DES (Data Encription Standard) que utiliza claves de 56 bits. Desde hace unos aos se sabe que DES es relativamente poco seguro, ya que el cdigo puede ser descifrado utilizando fuerza bruta en un tiempo no demasiado grande con un ordenador potente actual, por lo que tambin se suele utilizar bastante Triple DES, que es mucho ms seguro aunque tambin algo ms costoso de calcular.
SINGLE NETWORK MANAGEMENT PROTOCOL - SNMP Qu es SNMP?

SNMP (Single Network Management Protocol) es un estndar de administracin de red. Proporciona un mtodo de gestin de nodos de red (Servidores, estaciones de trabajo, enrutadores, puentes y concentradores) desde un NMS (Network Management Station). Utiliza una estructura de agentes SNMP que encontramos en todos los elementos que administra. Los gestionados y los que gestionan. El NMS es el que conecta con estos agentes instalados en cada uno de los elementos que van a ser administrados. Toda la informacin de los equipos est en una base de datos MIB (Management Information Base). Esta base de datos con estructura de rbol es recogida por el agente SNMP y comunicada al NMS. La ampliacin ms importante de SNMP fue RMON que nos permite monitorizar globalmente una subred, no slo sus dispositivos. Utiliza los puertos 161, 162 y el protocolo UDP. Los agentes escuchan por el puerto 161 y las estaciones gestoras escuchan los Traps en el puerto 162.
Componentes bsicos de SNMP

En cualquier red administrada con el protocolo SNMP encontraremos siempre 3 componentes bsicos: Dispositivos administrativos: Elementos de una red administrada que contienen un agente SNMP. Tales como routers, switches, servidores de acceso, computadores, impresoras, hubs, bridges.

22

Administracin de la seguridad
Agente: Componentes software que se ejecuta en el dispositivo a gestionar, y el que gestiona. Es un elemento pasivo y no origina mensajes si no que responde a las peticiones de los NMSs. nicamente iniciar la comunicacin cuando deba comunicar una alarma porqu el sistema se ha reiniciado o por fallos de seguridad en el sistema. NMS: Ejecuta aplicaciones que supervisan y controlan a los dispositivos administrados mediante SNMP. Estos NMSs conectan con los agentes SNMP para proporcionar volumen de recursos de procesamiento y memoria requeridos para la administracin de la red. Cuando un NMS enva una solicitud el agente devuelve la informacin solicitada desde el MIB. Base de informacin de gestin (MIB): Los recursos de la red que se pueden gestionar se presentan mediante objetos aunque bsicamente son variables. La MIB es bsicamente una coleccin de estos objetos.
DISPOSITIVOS QUE SE PUEDEN GESTIONAR MEDIANTE SNMP ORDENES BSICAS DEL ESTNDAR SNMP

Mostramos los tipos de mensaje que existen en la comunicacin entre el agente y el NMS. GetRequest: Mensaje de solicitud SNMP bsico. Enviado por un NMS, solicita informacin de una sola entrada MIB a un agente. GetNextRequest: Tipo extendido de mensaje que se utiliza para ver la jerarqua completa de objetos de administracin. Se devuelve el valor del siguiente objeto. SetRequest: Es un mensaje para actualizar un valor en el MIB, siempre que exista acceso de lectura. GetBulkRequest: Solicitud de transferencia de datos tan grande como sea posible. Minimiza el nmero de intercambios requeridos para obtener una gran cantidad de informacin. Solo utilizado en versiones 2 y 3 de SNMP. Trap: Mensaje no solicitado por un NMB que enva el agente cuando detecta cierto evento. El tipo de mensaje que inicia el agente cuando se produce una alarma. Formato de un mensaje SNMP

Versi

Comunidad

PDU (GetRequest...)

20

8 bytes

Campo Versin: Toma valores en funcin de la versin de SNMP Campo Comunidad: Se define en el agente y en este mismo se le asigna un perfil a cada comunidad para determinar si tiene permiso de modificacin e incluso lectura sobre las variables de la MIB. Campo PDU: Existen a modo genrico 2 tipos de formatos en las PDU SNMP, aunque luego veremos que se dividen en ms tipos. El primero de estos 2 tipos es general y comn a casi todas ellas, y el segundo tipo corresponde a la PDU Trap. Cabe recordar que las consultas las realiza el NMS y el Trap es la nica que realiza el agente por iniciativa propia por tanto es comprensible que exista un tipo de PDU para cada una de ellas.

23

Administracin de la seguridad
Tipos de PDU: Especifican el tipo de mensaje y los valores posibles son:
Tipo PDU
0 1 2 3 4

Nombre
GetRequest GetNextRequest SetRequest Respone Trap

Identificacin de la peticin: Se utiliza para relacionar peticiones y respuestas. SNMP puede hacer frente a PDUs duplicadas por un servicio de transporte inseguro como UDP gracias a que cada una de estas peticiones va identificada por el emisor. Estado de error: Se emplea para indicar que ha ocurrido una anomala mientras se procesaba una consulta existiendo valores diferentes para cada tipo de error. Tiene diferentes valores tales como:
Tipo de error 0 1 2 3 4 5 Significado No hay error Demasiado grande No existe esa variable Valor incorrecto El valor es de solo lectura Error genrico

ndice de error: Se utiliza cuando el campo estado de error es diferente de 0 y tiene como objetivo proporcionar informacin adicional. Lista de variables: Es una lista de nombres de variables con sus valores correspondientes. Existe tanto en las preguntas como en las respuestas. Estructura de la base de informacin de gestin - MIB MIB es una base de datos en forma de rbol, obtenido una jerarqua para cada uno de los objetos de la base de datos, cada uno de estos tiene un nmero identificador que lo identifica dentro de este rbol.

Como podemos observar en la captura hay dos directorios importantes ya que de estos cuelga toda la informacin importante para la monitorizacin del protocolo.

24

Administracin de la seguridad
SNMPv2 aqu se encuentra la informacin genrica del elemento, fabricante, modelo , etc, podemos observar que su ubicacin es .1.3.6.1.6. En cambio private hay informacin extra que el fabricante proporciona, dependiendo el producto puede ser ms completa o menos, esta es totalmente para uso corporativo donde el fabricante nos ofrece el software de gestin para pode acceder a dicho directorio.
APLICACIONES DEL ESTNDAR SNMP A DIFERENTES ESCENARIOS

SNMP puede utilizarse de varias maneras: Para configurar dispositivos remotos: desde el NMS configuramos los equipos. Para supervisar el rendimiento de la red: se puede hacer un seguimiento de la velocidad de la red. Para detectar fallos de red: Puede llevar una alarma al NMS cuando: o o Se apague un dispositivo. Se detecte un error de enlace con un enrutador.

Para auditar el uso de la red: Se puede auditar el uso de los equipos por sus usuarios.

Simulacin del protocolo SNMP

En este apartado haremos una pequea simulacin con el protocolo SNMP para eso necesitamos un software de gestin y un elemento que monitorizar. La aplicacin que utilizaremos es iReasoning MIB Browser Personal Edition, est tiene una versin de prueba de 30 das. Este punto hay que remarcarlo nosotros realizaremos una prueba, por lo tanto el software de gestin nos era un poco igual cual fuera, cualquiera aplicacin gratuita hubiera echo la funcin pero esto en un entorno corporativo es muy diferente. Aqu interviene otro factor, la marca del hardware instalado, estos productos incorporan en una parte de su MIB datos especficos del fabricante, estos nos dotaran de datos que aran mucho ms eficiente nuestra monitorizacin, por eso siempre se recomienda que todo el hardware instalado sea del mismo proveedor, esta MIB especifica solo puedes acceder a ella con la aplicacin de gestin propietaria de dicho fabricante. El elemento ha monitorizar ser un router CISCO modelo c2691. El router la virtulizaremos con la aplicacin GNS3, este punto podramos haber utilizado el cliente que incorpora Windows pero hemos preferido simular un elemento externo de donde estaba ubicado el cliente SNMP. Lo primero que haremos es instalar la aplicacin y crear la topologa con GNS3. La topologa es muy simple, solo necesitaremos un router conectador a la NIC de nuestro ordenador.

La configuracin del router es muy simple, solo necesitamos configurar la interface Ethernet con una IP del rango de nuestra red, en este caso utilizaremos una 172.16.0.10/16 y activar el cliente SNMP. Para eso hemos utilizado los siguientes comandos:

Router> enable

25

Administracin de la seguridad
Router# configure terminal Router(config)# interface FastEthenert 0/0 Router(config)# ip address 172.16.0.10 255.255.0.0 Router(config)# no shutdown Router(config)# exit Router(config)# snmp-server community public RO Router(config)# snmp-server community private RW Router(config)# exit Router# show running-config | include snmp ;Verdificar ativacin SNMP

Una vez configurado el router con el servici SNMP empezaremos ha enviar algunos comandos al router desde la aplicacin pero previamente haremos un vistazo general al software donde veremos todos los parmetros comentados anteriormente. Captura de la aplicacin iReasoning MIB Browser

Como podemos observar en la captura hay varios campos sealados: Address: La direccin IP del agente en este caso el router . Operation: Una lista de operaciones bsicas, para pode gestionar el contenido de la MIB. SNMP MIBs: Aqu podemos visualizar de una forma la distribucin de los directorios de la MIB del router. Result Table: Este apartado aparecer el contenido de la peticin echa, en este caso el objeto es sysDescr del directorio system.

Vistos los elementos bsicos de la aplicacin procederemos ha hacer una peticion. System sysDescr ubicada en .1.3.6.1.2.1.1, obtenemos la siguiente informacin.
Value: Cisco Internetwork Operating System Software IOS (tm) 2600 Software (C2691-JK9O3S-M), Version 12.2(15)T17, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2005 by cisco Systems, Inc. Compiled Fri 12-Aug-0 Type: OctetString

26

Administracin de la seguridad
Observamos que estamos utilizando una IOS genrica de la serie 2600 de CISCO versin 12.2, para el router C2691, compilada el viernes 12 de agosto del 2000. La informacin subministrada es del tipo OctetString (texto). Vista la peticin vamos ha ver a nivel de trama la informacin para captura la trama utilizaremos la aplicacin Wireshark.

Como se observa en la captura la peticin get-request se ha realizado desde ordenador 172.16.0.4 hacia el agente 172.16.0.10 el cual a respondido con getresponse. Ahora vamos ha entrar con ms detalle.

La peticin al objeto 1.3.6.1.2.1.1.1.0 esta peticin se realizada por el puerto UDP 54374 hacia el 161, estamos utilizando la versin 1 de SNMP.

En la respuesta podemos observar que no habido ningn error, una apartado significativo que no hemos comentado en la parte anterior esta peticin va dirigida a la comunidad pblica.

27