KERBEROS. Un Sistema de Autenticacion para Redes. ANDREA PAOLA ALONSO DE ARMIÑO. PROFESOR: JORGE EDUARDO SZNEK MATERIA: SEGURIDAD INFORMÁTICA.

Tamaño: px
Comenzar la demostración a partir de la página:

Download "KERBEROS. Un Sistema de Autenticacion para Redes. ANDREA PAOLA ALONSO DE ARMIÑO. PROFESOR: JORGE EDUARDO SZNEK MATERIA: SEGURIDAD INFORMÁTICA."

Transcripción

1 KERBEROS Un Sistema de Autenticacion para Redes. ANDREA PAOLA ALONSO DE ARMIÑO. PROFESOR: JORGE EDUARDO SZNEK MATERIA: SEGURIDAD INFORMÁTICA. UNIVERSIDAD NACIONAL DEL COMAHUE

2 Página 2 KERBEROS: UN SERVICIO DE AUTENTICACIÓN PARA REDES....3 RESUMEN... 3 INTRODUCCIÓN... 4 OBJETIVOS: AUTENTICACIÓN, INTEGRIDAD, CONFIDENCIALIDAD Y PERMISO(AUTORIZACIÓN)... 5 Debilidades de KERBEROS:... 6 QUÉ HACE KERBEROS, CÓMO TRABAJA... 6 Cross Realm Authentication... 9 Los tres pasos de KERBEROS:... 9 USANDO KERBEROS Aplicaciones Kerberizadas OTRAS FORMAS DE MEJORAR LA SEGURIDAD DISEÑANDO UN SISTEMA DE AUTENTICACIÓN Diálogo en cuatro escenas VERSIÓN 4 DE KERBEROS Y VERSIÓN Limitaciones de la versión 4 de Kerberos Cambios en la Versión 5: Nuevas características de la V Implementación V Interacción del Usuario Compatibilidad con la versión Comparación entre la V4 de Kerberos y la V PROBLEMAS TÉCNICOS Y LIMITACIONES DE KERBEROS Trabajo futuro CONCLUSIÓN REFERENCIAS:... 28

3 Página 3 KERBEROS: Un Servicio de autenticación para redes. Resumen Los métodos de autenticación que se basan en la criptografía, evitan que un atacante que esté escuchando en la red pueda entender lo que se está transmitiendo y por lo tanto no sabrá cómo enmascararse y hacerse pasar por otro. En la actualidad los sistemas de computación brindan servicios a muchos usuarios, cada uno con ciertos permisos y restricciones, por lo que es necesario identificarlos de manera confiable. En los sistemas tradicionales bastaba con chequear un password en el momento del login para determinar los privilegios que le correspondían y definir las operaciones que tenía permitidas cada usuario. Pero esta forma de autenticación no es útil en los sistemas actuales que hacen uso de las conexiones de redes...un password viajando a través de la red podría ser interceptado por un atacante y luego ser usado para enmascararse como si fuera el usuario legítimo. KERBEROS provee una forma de verificar la identidad de un principal(ej. un usuario de una workstation o un servidor de red) en una red abierta (desprotegida). Esto es logrado sabiendo que no se puede confiar de la dirección del host, sin requerir seguridad física de los host de la red, y bajo la suposición de que los paquetes que viajan en la red pueden ser leídos, modificados e incluso insertados. Así, bajo éstas características, KERBEROS hace la autenticación, que consiste en un servicio de autenticación de tres partes y usando la criptografía convencional (es decir compartiendo claves secretas). Un caso concreto es el del U.S. Departament of Energy (DOE), que requiere acceso a un gran número de sistemas y fuentes de información externas a sus propios laboratorios. La comunicación electrónica y el uso de Internet han pasado a ser una necesidad para lograr la colaboración entre Universidades, industrias, gobiernos. DOE s Energy Sciences Network (Esnet) necesita esta comunicación asegurando a la vez la protección de los recursos computacionales del gobierno de usos no autorizados. La información sensitiva y las propiedad intelectual deben ser protegidas de modificaciones, destrucción o alteración. En 1993, DOE funda 4 sitios Esnet para comenzar a implementar y evaluar el servicio de autenticación Esnet basado en Kerberos V5. El propósito de este proyecto era identificar, entender y resolver las cuestiones de autenticación técnicas, procedurales, culturales y políticas en una Internet inter-organización.. Como conclusión se llegó a que la V5 de Kerberos es una tecnología que permite a los usuarios Esnet compartir libremente los recursos e información sin comprometer la integridad de los sistemas y datos. En éste trabajo comenzaremos con una introducción en la que explicaremos brevemente de que se trata Kerberos, basándonos sobre todo en la versión 5. Comentaremos los objetivos definiendo cada uno y las debilidades del protocolo. Seguidamente pasaremos a ver cómo trabaja Kerberos y que cosas se asumen para su funcionamiento, veremos gráficamente el intercambio de mensajes que hay entre clientes y servidores para hacer la autenticación. Dentro de esta sección veremos también la Cross

4 Página 4 Realm Authentication, es decir cómo funciona Kerberos cuando el cliente y servidor pertenecen a distintas organizaciones (remotos). Luego veremos algunas cuestiones de Implementación y qué pasa con las aplicaciones que quieran usar la autenticación. Finalmente incluimos un diálogo ficticio que permite, a través de un supuesto diálogo entre dos desarrolladores, ver como se van individualizando problemas y ajustando las soluciones para llegar finalmente al protocolo de autenticación Kerberos (éste diálogo solo incluye hasta la versión 4 ya que la 5 incluye otras características que surgieron luego al ir detectándose nuevas necesidades y deficiencias). Luego explicaremos algunas debilidades de la versión 4 para ver como evolucionó hacia la 5. Introducción Varios mecanismos han sido desarrollados con el propósito de evitar los posibles ataques a los que se expone la información al viajar en una red abierta (por ej. ser capturada, lo cuál es inaceptable cuando se trata de información sensitiva o en el caso de información de autenticación) pero segmentar la red y el uso de passwords de una vez obstruyen el paso no solo a los usuarios no autorizados sino también a los usuarios legítimos. KERBEROS es un servicio de autenticación desarrollado por el MIT a mediados de los 80, fue usado por mas de 5 años en varias organizaciones de gobierno, educación y comerciales para autenticar el acceso de los usuarios a los recursos dentro de los confines de la organización. Sin embargo el problema de autenticación entre organizaciones en un área de red grande, tal como Esnet llevó a que se siga trabajando. Hoy la versión V5 es considerada el estándar- desarrollada en El nombre KERBEROS proviene del mitológico perro de tres cabezas guardián de la entrada del infierno; el sistema de seguridad Kerberos sería el guardián de las transmisiones electrónicas que viajan a través de Internet, autenticando tanto a usuarios como servidores con el uso de claves y encriptado. Es decir, que hace que la autenticación sea mas confiable, ya no basta que un usuario diga quién es para creerle (Authentication by assertion). Por ejemplo, un usuario que hace un rlogin, no necesitaría reingresar su password para loguearse en la nueva máquina, ya que ésta confiaría en su identidad por estar logueado en una máquina que ya lo ha verificado, pero otro podría estar haciéndose pasar por el verdadero usuario. Hacer que el usuario reingrese su password cada vez que necesita un servicio tiene otros inconvenientes: por un lado lleva tiempo al usuario, además es inseguro cuando el servicio está en una máquina remota. KERBEROS evita tener que divulgar esta información privada, se basa en el modelo de distribución de claves de Needhan y Schroeder. Otras características de KERBEROS son el uso de timestamps, el ticket-granting service que permite hacer la autenticación sin tener que reingresar el pasword cada vez., y otros procedimientos de cross-realm authentication. Con el uso de claves se encripta un mensaje (texto plano), y se obtiene el texto cifrado, cualquiera que lo vea pensará que es basura ya que no podrá entenderlo. Solo con una rutina de desencriptación sobre el texto cifrado y usando una clave para ello, se obtendrá el texto plano nuevamente. En KERBEROS ambas claves son la misma, similar a la encriptación tradicional; en cambio en la criptografía de clave pública hay dos claves, una usada durante la encriptación y la otra en el proceso inverso, pero no hay forma de obtener una a partir de la otra.

5 Página 5 El protocolo KERBEROS consiste de varios sub-protocolos (o exchanges). Hay dos métodos por los cuales un cliente puede pedir su credencial a los servidores KERBEROS. En el primero el cliente manda en texto plano una solicitud por un ticket para un servidor dado al authentication server(as). La respuesta vuelve encriptada con la clave del usuario. Usualmente esta solicitud es por el ticket-granting ticket (TGT) que luego podrá usarse con el ticket-granting server(tgs). En el segundo caso el cliente manda un request al TGS igual que si estuviera tratando de conectar un servidor de aplicación cualquiera que requiere credenciales. La respuesta va encriptada con la clave de sesión que va en el TGT. Una vez obtenidas las credenciales pueden usarse para verificar la identidad del principal en una transacción, para asegurar la integridad de los mensajes intercambiados en ellas o para preservar la privacidad de los mensajes. La aplicación verá que tipo de protección necesita. Para verificar la identidad del principal en una transacción, el cliente manda el ticket al server. Pero para evitar que el ticket sea captado y vuelto a usar por otro, es necesaria información adicional para probar que el mensaje fue enviado por el principal para el cuál el ticket fue creado. Esta información es el autenticador que incluye un timestamp y va encriptado con la clave de sesión. Con el timestamp se asegura que el mensaje fue generado recientemente y no está siendo reutilizado. Como la clave de sesión solo la conocen el servidor y el principal que hizo el requerimiento, se garantiza la identidad del cliente. La integridad de los mensajes intercambiados entre el cliente y servidor también puede ser garantizada usando la clave de sesión. En los mensajes iría un checksum (encriptado con la clave de sesión) que permitiría detectar alteraciones. Se podría lograr privacidad e integridad encriptando los datos con la clave de sesión. Estos intercambios mencionados antes, requieren un acceso de solo lectura a la base de datos de KERBEROS. Sin embargo algunas veces es necesario cambiar alguna clave o agregar otra en caso por ej. de un nuevo usuario. Esto se hace usando un protocolo entre un cliente y un tercer servidor KERBEROS: el Servidor de Administración de Kerberos (KAS). Aunque el tema de administración no será desarrollado aquí. Objetivos: Autenticación, Integridad, Confidencialidad y Permiso(Autorización) Autenticación: es la verificación de la identidad de alguien, es decir: la comprobación de que realmente es quién dice ser. Llamamos principal a la parte cuya identidad quiere ser verificada, y verifier a quién requiere o necesita esta validación. La Integridad de los datos es la garantía de que los datos recibidos son los mismos que fueron enviados. Los diferentes métodos de autenticación ofrecen distintos grados de confianza, por ejemplo unos solo garantizan que los datos fueron generados por el principal. También hay otras características que los diferencian, una muy importante es si soportan no repudiación, es decir la habilidad de probar que alguien fue realmente el generador de un mensaje. Estas características afectan la performance, así es necesario contemplar cuáles son las que necesita la aplicación.

6 Página 6 En cuanto a Confidencialidad se refiere a no revelar la información, y Autorización es comprobar si un principal está autorizado a llevar a cabo un proceso. KERBEROS permite la autenticación de un cliente a un servidor y brinda integridad y confidencialidad para los datos que se mandan entre ellos. Los distintos métodos de autenticación aseguran distintas cosas, según su capacidad variará también su performance; por ello es necesario entender lo requerimientos de una aplicación cuando se va a elegir uno de estos métodos. Por ejemplo en el caso del correo electrónico es necesario asegurar la no repudiación, pero en este caso no es tan importante la performance. Debilidades de KERBEROS: Cómo una limitación de KERBEROS podemos decir que no puede hacer nada si un atacante logra adivinar un password, es decir no logra reconocer al impostor cuando se enmascara y logra servicios haciéndose pasar por otro. Para evitar esto KERBEROS debe ser combinado con otras herramientas. Qué hace KERBEROS, cómo trabaja... Podríamos decir que KERBEROS se parece a un carnet de conductor, reúne una cantidad de información, algunos datos serán únicos para cada uno, puede haber también alguna restricción (en el ejemplo edad mayor que 21) y un lapso de vida o de validez. Este método de autenticación será usado cada vez que un usuario de una red, solicite un servicio de red y éste necesite verificar la identidad del cliente. El usuario recibe desde el authentication server un ticket (análogo a la licencia de conducir) que servirá para que el verifier compruebe su identidad. El ticket debe llevar el password del usuario para identificarlo unívocamente. Un atacante que capte el ticket no debe poder obtener información sobre el usuario que luego le permita enmascararse. Kerberos lo evita usando encriptado. Agrega también el uso de timestamps, y el ticket-granting service para soportar subsecuentes autenticaciones de un usuario sin que tenga que reingresar su password. Kerberos hace algunas Asunciones sobre el medio en el que puede funcionar apropiadamente : Los ataques que producen la denegación de servicios no son tratados por Kerberos. Un intruso podría afectar la participación de una aplicación en el proceso de autenticación. Las claves deben ser mantenidas en secreto, tanto de los usuarios como de los servidores, para que un atacante no logre enmascararse. Los password no son malos, así no se considera el problema de que sean adivinados.

7 Página 7 Cada host debe tener un reloj cercanamente sincronizado con los de los otros host, para poder distinguir el reenvío de los mensajes. Verificar que un usuario es quién dice ser, es ver que conoce el password (que a la vez es la clave de encriptación) que solo él puede saber y el authentication server (AS). El AS tiene registrados a todos los usuarios; de cada uno guarda una clave que obtiene desde su password. Además cada application server comparte una clave con el AS: server key. Kerberos se basa en el método de encriptación DES, los datos son desencriptados con la misma clave con la que se los encriptó (si no se conoce la clave o los datos fueron alterados no se logra desencriptar: integridad y confiabilidad). En rasgos generales podemos describir los pasos que lleva a cabo el método de autenticación: 1. El usuario manda un mensaje al AS diciendo qué usuario es y cuál es el servicio que quiere. 2. El AS recibe el mensaje y crea una clave, que será compartida entre cliente y servidor: session key. 3. El AS pone una copia de la session key en un mensaje, junto con el nombre del servidor y un tiempo de expiración fuera del cuál la session key no será valida, y encripta todo con la clave del usuario (podemos verlo como una caja: C1, que cierra con una llave). 4. Toma una segunda copia de la session key mas el nombre del usuario, y encripta con la clave del servidor (C2 cerrada con otra llave). 5. Envía las dos cajas al usuario. 6. Con su clave el usuario puede abrir la C1 donde lee el nombre del servidor. 7. La caja C2 no la puede abrir, así crea una tercera caja donde pone la hora actual y encripta con la session key que obtuvo al abrir la C1. Envía las cajas 2 y 3 al server. 8. El server recibe las cajas, con su clave puede abrir la 2 y leer el nombre del usuario, ahora con la session key abre la tercera y ve la hora que allí se indica. De esta forma ha comprobado la identidad del usuario. La hora que lleva C3 sirve por si mas tarde un atacante intenta usar una copia de C2, ya no será valida. En KERBEROS la caja 2 es el ticket y la 3 el authenticator : éste contiene otra información como un checksum, tiempo actual y una clave de encriptación opcional (que serviría para los sucesivos diálogos entre el cliente y el servidor). Gráficamente el intercambio de mensajes:

8 Página 8 1 AS C V En algunas aplicaciones el cliente necesita autenticar también al server, así éste crea el application response en el que incluye información (como el tiempo que venía en el auntheticator), y lo envía todo encriptado con la session key. El cliente necesita un ticket y session key por cada servicio con el que se quiera comunicar, y lo obtiene a través de una solicitud al AS, para luego mandar su request al verifier. Tenemos así el protocolo básico de autenticación: authentication request and response y application request and response. Vemos que cada vez que el usuario quiera contactar un nuevo server debe enviar un request al AS, presentando así, cada vez, su password; lo que amenaza su seguridad, ya que puede ser robado. Aunque el ticket y la clave asociada tienen un tiempo de expiración corto, el password del usuario podría ser usado para obtener nuevos tickets y lograr así el enmascaramiento. Kerberos soluciona el problema incorporando otro elemento, el ticket granting server (TGS). Cuando el usuario quiera obtener un servicio, primero debe autenticarse ante el TGS. Se pide un ticket para el TGS, igual que se hace para cualquier servicio, obteniéndose el ticket granting ticket (TGT). Una vez hecho esto, cada vez que el usuario quiera pedir un servicio, le pide un ticket al TGS, no al AS: la respuesta ahora no va encriptada con la clave del usuario sino con la session key que el AS mandó para usar con el TGS. Así se evita que el usuario esté reingresando su password cada vez y que pueda ser robado. Además el TGT es válido por un tiempo corto (no así el password). AS TGS 1 2 C V

9 Página 9 En la figura se ve el protocolo completo, los mensajes 1 y 2 solo ocurren cuando el usuario se loguea con el sistema, el 3 y 4 cada vez que se deba autenticar a un verifier. Cross Realm Authentication Cuando la red crece mucho, el AS / TGS pueden volverse un cuello de botella en el proceso de autenticación. Es decir que se ve afectada la escalabilidad, uno de los principales objetivos de los sistemas distribuidos. Además, cuando un sistema sobrepasa los límites organizacionales, no es apropiado tener a todos los usuarios registrados en el mismo servidor de autenticación. El protocolo KERBEROS fue diseñado para operar aún entre límites organizacionales. Un cliente dentro de una organización puede ser autenticado ante un servidor en otra organización. Cada organización con su propio servidor KERBEROS establece su Realm. El nombre del realm al que pertenece un cliente es parte de su propio nombre y puede ser usado por el servidor para decidir brindar el servicio o no. Entonces la alternativa es dividir la red, cada uno con su AS y TGS responsables de una parte de los usuarios y servers. A un subconjunto de éstos lo llamamos Realm. Estableciendo claves inter-realm, los administradores de dos realms pueden permitir que los clientes autenticados en uno de ellos puedan usar su autenticación en el realm remoto. El intercambio de claves inter-realm requiere registrar el ticket-granting service de cada realm en el otro. Así un cliente es capaz de obtener un TGT para el ticket-granting service remoto(rtgs) desde su realm local. Cuando el ticket-granting ticket es usado, el ticket-granting service remoto usa la clave inter-realm para desencriptar el TGT y autenticar al usuario, los ticket para los servicios que él provea dirán que el cliente pertenece a otro realm. Ahora a nuestro protocolo de comunicación se agrega un nuevo intercambio de mensajes. Primero el usuario contacta al AS para acceder al TGS. Luego contacta al TGS para acceder al RTGS, y finalmente se contacta con éste para llegar al service. En la versión 4 de KERBEROS era necesario que cada server se registre con cada realm con el que necesite Cross realm authentication, lo que hace que el número de interconexiones crezca exponencialmente (dos realm se podían comunicar si compartían un clave inter-realm, o si entre ambos existía un realm intermedio). En la versión 5 en cambio existe un jerarquía entre los realms, cada uno comparte una clave con sus hijos y padre; por ello, para contactar un service de otro realm puede ser necesario atravesar varios realms intermedios. Hay también mecanismos que permiten acortar el camino en el proceso de autenticación para mejorar la performance. Cada verifier hace la validación del ticket analizando el camino de realms que se ha atravesado (ya que se van registrando en el ticket). Los tres pasos de KERBEROS: 1. Intercambio de mensajes para la autenticación: Esta comunicación entre el cliente y el servidor de autenticación de Kerberos comienza cuando el cliente solicita una credencial de autenticación. La clave del cliente es usada para la encriptación y desencriptación. Generalmente este paso se da al comienzo de una sesión para obtener la credencial para acceder al ticket-granting service y así a través de él obtener los tickets que permitan usar

10 Página 10 otros servicios sin tener que volver a ingresar el password del usuario. También sirve para obtener credenciales que sirvan para acceder a servicios que no requieran al ticketgranting service como intermediario (por ej. el password-changing service). En el request el cliente manda en texto plano su identidad, la respuesta (en la que va el ticket y la clave de sesión) está encriptada con la clave del usuario. Otra información que va en el mensaje de vuelta sirve para detectar los reusos. En verdad el servidor de autenticación no sabe si el cliente que hizo el request se corresponde con el nombre de usuario dado, pero no le afecta ya que si no es, no le va a servir la respuesta porque no conocerá la clave para desencriptarlo. 2. Intercambio de mensajes con el Ticket-Granting Service (TGS): Se llega a esta etapa cuando un cliente quiere obtener un ticket para algún servicio y ya posee el ticketgranting ticket. El intercambio de mensajes es similar al anterior, solo que ahora no se usa como clave de encriptación el password del cliente sino la clave de sesión que se ha obtenido junto con el ticket-granting ticket. En el request va información de autenticación, que en este caso es el ticket. La respuesta va encriptada con la clave de sesión para este servicio y llevará la credencial solicitada. Antes de enviar su request el cliente debe ver en que realm el servidor está registrado. Si el cliente no posee un ticket-granting ticket apropiado para el realm debe primero obtener uno, así un ticket de estos es requerido al realm destino desde el realm local (se puede tener que atravesar varios realms intermedios hasta obtener finalmente el TGT deseado). Una vez conseguido puede solicitar el ticket para el servicio que quiera. Al recibir la solicitud el ticket-granting service hace algunos chequeos mas, por un lado debe ver cuál es el servicio solicitado para determinar la clave con que debe desencriptar. En general se trata del ticket-granting service por lo que usa la clave del TGS, pero si el mensaje es remoto debe usar una clave inter-realm. Una vez desencriptado el ticket obtiene la clave de sesión con la que desencripta el autenticador y comprueba la identidad del usuario. En la respuesta envía el ticket para el servicio solicitado encriptado con la clave para éste. Si el request es para un ticket-granting ticket para un realm remoto, y no se comparte una clave con él, se elige el realm mas cercano con el que se comparte una clave y se lo usa. 3. Comunicación cliente-servidor : Este intercambio de mensajes es usado por las aplicaciones de red para autenticar a los clientes frente a los servidores y viceversa. El cliente para esto ya debe haber obtenido el ticket desde el AS y el ticket para el servicio desde el TGS. La información que va en el request es el ticket, un autenticador y alguna información extra. El autenticador servirá para que otros no puedan reutilizar tickets haciéndose pasar por el cliente legítimo que lo obtuvo (ya que solo éste puede conocer la clave de sesión). El cliente puede reusar los tickets hasta su expiración, pero creará cada vez un autenticador (lleva la hora, un número de secuencia inicial que se elige aleatoriamente, etc.) todo encriptado con la clave de sesión. El servidor desencripta el ticket con su clave (debe ver cuál usar por el caso de que la solicitud provenga de un realm remoto). Ahora que ha obtenido la clave de sesión puede desencriptar el autenticador y comprobar la identidad del usuario (comparando el nombre del cliente y su realm), controla también la hora.

11 Página 11 En todos los mensajes request desde un cliente a cualquiera de estos servidores se pueden setear ciertas banderas para solicitar ciertas características de los tickets, por ej. una bandera que indique que un ticket es renovable, etc. Usando KERBEROS La implementación consiste de uno o varios authenticator servers que deben mantener una base de datos con los passwords (claves de encriptación) para todos los principals (usuarios y servers), es importante que estas máquinas sean seguras. En lo posible dedicadas a correr el server de autenticación. Para agregar autenticación a las transacciones, una aplicación de red debe agregar llamadas a las librerías de KERBEROS (librerías de código que proveen encriptación e implementan el protocolo), lo que resulta en la transmisión de los mensajes necesarios para lograr la autenticación. Un usuario que quiera usar KERBEROS debe primero establecerse como un principal, en general como una cuenta en una máquina, el nombre del principal consiste del nombre mas el realm al que pertenece: Con cada principal hay asociada una clave almacenada en la Base de datos de Kerberos junto con alguna otra información (todo encriptado con una clave privada de Kerberos). Para el usuario Kerberos es casi transparente. Muchos servicios requieren de la autenticación. Por ej. rlogin, para poder usarlas es necesario obtener un TGT primero, el comando para esto es kinit. %kinit Password para Al ingresar el password el programa kinit hace un request al AS por un TGT, con la clave desencriptará la respuesta (en verdad al password se le aplica una función con la que se obtiene la clave real con la que se ha encriptado y con la cuál se hará la desencriptación). Para verificar que se ha obtenido el TGT se puede usar el siguiente comando: %klist Ticket cache: /var/tmp/krb5cc_1234 Default principal: your Valid starting Expires Service principal 24-Jul-95 12:58:02 24-Jul-95 20:58:15 El ticket cache dice que archivo contiene la credencial, el default principal es el principal para el cuál es el TGT, el resto es la lista de los ticket que se poseen. Si ahora se usa el rlogin, este programa usará el TGT para obtener el ticket para el rlogin, esto ocurre automáticamente al ejecutar: %rlogin newhost.domain Last login: Fri Jul 21 12:04:40 from etc etc Ahora si se ejecuta Klist aparecerá el nuevo ticket en la lista. Para destruir credenciales que no se van a necesitar se puede usar el comando:

12 %kdestroy %Klist Klist: No credential cache file found while setting cache flags (ticket cache /var/tmp/krb5cc_1234) Página 12 Se eliminan todos los tickets incluso el TGT. El administrador del sistema debe configurar el AS y TGS, los principal deben ser registrados y los servicios deben hacerse disponibles. Aplicaciones Kerberizadas Las aplicaciones cliente/servidor deben ser modificadas para soportar el uso de Kerberos para la autenticación. Las aplicaciones deben generar y enviar Kerberos application request al server de aplicación, y éste debe verificar la información de autenticación. En versiones recientes de Kerberos, existe la Generic Security Application Programmer Interface (GSSAPI). GSSAPI provee una interface de programación estándar independiente del mecanismo de autenticación. Esto permite al programador de aplicación diseñar una aplicación y protocolo de aplicación que puede usar tecnologías de autenticación diferentes (incluso Kerberos). Las aplicaciones deben : 1. Obtener la identidad del usuario. 2. Obtener la credencial para el usuario. 3. Verificar si existe un ticket para un servicio dado. 4. Si no está presente usar el TGT y la clave de sesión para pedir uno. Otras formas de mejorar la seguridad Kerberos no es una solución total para todos los problemas de seguridad en redes, pero puede convinarse con otras herramientas, por ej. one-time passwords y publickeycryptography. Un mecanismo de autenticación con passwords de una sola vez usa un password distinto cada vez que se necesite autenticación. Aunque un método como éste presenta otros inconvenientes, no es bueno almacenar información en cada server con el que un cliente interactúa, pero tampoco es práctico que un usuario tenga que reingresar su password cada vez. En la criptografía de clave pública, la encriptación y la desencriptación se hacen usando un par de claves, una pública y la otra privada (no se puede obtener una a partir de la otra). Algunas ventajas frente a la criptografía tradicional cuando es usada para la autenticación es la no repudiación y la eliminación de la clave de encriptación secreta para el authenticator server. Una desventaja sería la performance (por ello es necesario considerar en cada aplicación cual es el nivel de seguridad que se quiere frente al costo de lograrlo).

13 Página 13 Diseñando un Sistema de Autenticación Diálogo en cuatro escenas El siguiente diálogo es un cuento ficticio del diseño de un sistema de autenticación para una red abierta que se llamará Charon. A medida que el diálogo avanza, los involucrados van descubriendo los problemas de seguridad en un medio de red abierto. Cada problema debe ser resuelto en el diseño de Charon. El diseño final del sistema es el que conocemos como KERBEROS. Introducción: Los dos personajes que participan son desarrolladores de sistemas. Escena 1: Athena y Euripides trabajan en terminales vecinas. Hey Rip, este sistema de tiempo compartido es muy lento. No puedo hacer nada porque cualquiera se logue y entra. No te quejes a mi, yo solo estoy trabajando acá. Sabes que necesitamos?, que cada uno tenga su estación de trabajo y así evitamos compartir ciclos de CPU. Y usaríamos la red para comunicarnos unos a otros. Si...pero necesitaríamos muchas workstations... Además el tamaño de la unidad de disco de una workstation típica no es suficiente para todo el software que hay en una máquina de tiempo compartido. Podría estar fuera, tener máquinas servidoras con copias del software del sistema. Cuando uno se loguea en una workstation, ésta se conecta a un server y accede al software. Además facilitaría el hecho de la actualización. Y qué pasa con los archivos personales?, en un sistema de tiempo compartido yo puedo loguearme y obtener mis archivos desde cualquier terminal conectada al sistema. Podría seguir haciendo eso? o tendría que hacer como los usuarios de PC y cargar mis archivos en disquetes? Pienso que podría haber otras máquinas que provean el almacenamiento de los archivos personales. Así uno podría loguearse desde cualquier workstation y obtener los archivos. Y que pasa para imprimir?, cada uno tendría que tener su impresora?. Y que pasa con el correo electrónico? cómo harías para distribuirlo a cada workstation? Bueno, sería costoso tener tantas impresoras, pero se podrían dedicar algunas máquinas al servicio. Lo mismo para el correo, para obtener los mails habría que loguearse a una máquina que diera tal servicio.

14 Página 14 La verdad que este sistema de workstation suena bien, pero hay algo...alguien podría usar mi nombre de usuario y hacerse pasar por mi, y obtener por ejemplo mi correo electrónico... Los servers no podrían distinguir esto. Es verdad...hay que pensar algo. Escena 2: La mañana siguiente. Ya pense la forma de brindar seguridad en un ambiente de red tal que nadie pueda hacerse pasar por otro. En serio?, y en qué consiste? En uno de éstos sistemas es necesario que las máquinas servidoras sean capaces de confirmar la identidad de las personas que requieren sus servicios. Si yo solicito al servidor de correo mis mails, él debe poder verificar que soy quien digo que soy, no es así? Estoy de acuerdo. El problema se resolvería haciendo que el servidor de correo requiera un password antes de que alguien pueda usarlo, para demostrarle así quien es. Pero así cada server debería conocer todos los passwords de todos los clientes, además si se cambia el password habría que avisar a todos los servers. El sistema es así, no solo los clientes tienen password sino también los servers. Cada usuario conoce su password, y hay un SERVER DE AUTENTICACION que conoce todos los passwords (de usuarios y servidores) almacenados en una base de datos centralizada. Y que nombre le diste a este servicio de autenticación? Aún no tiene uno. Que te parece Charon. Okay, es un lindo nombre...aunque no describe de que se trata el sistema. Supongamos ahora que vos queres usar un servicio, la única forma sería que Charon le diga al server que sos quien decís. Cuando le pedís a Charon que corrobore tu identidad tenes que decirle cuál es el servicio que queres. Charon te solicita que pruebes tu identidad, así vos le mandas tu password secreto. Charon lo compara con el que tiene registrado en su BD, si son iguales considera que tu identidad es la verdadera. Ahora debe convencer al server que solicitas que sos vos. Ya que Charon conoce todos los password conoce también el de este server (por ej. el servidor de mails). Así si te lo da y vos se lo mandas en tu request, él confiaría en tu identidad, porque si sabes ese password secreto es porque te lo dio el servidor de autenticación.

15 Página 15 El problema es que ahora conociendo el password podrías pedir otra vez algo al server sin hacer la autenticación correspondiente, y lo que es peor hacerte pasar por otro. La opción sería que el autenticador no de los passwords sino un ticket para el servidor solicitado, que contenga tu nombre de usuario encriptado con la clave de tal server. Con el ticket podes solicitar ahora el servicio al servidor dado, diciendo que usuario sos. Con su password el server desencripta el ticket y verifica tu identidad con la que dice allí, si son iguales brindará el servicio. Una pregunta, puede saber el server si el ticket se ha desencriptado bien o no? No lo sé... Podría incluirse en el ticket también el nombre del servidor, así podría darse cuenta si la desencriptación fue mal hecha. Suena bien (y anota en un papel: Ticket(username:servicename)) No creo que el hecho de que vaya todo encriptado sea suficiente. Mira si yo me hago una copia de un ticket que te manda el autenticador mientras viaja por la red. Y yo hago creer a mi insegura workstation que mi nombre de usuario es el tuyo, luego pediría el servicio a tu nombre y con el ticket robado, obteniendo así el servicio. Oh! que mal! Pero se me está ocurriendo algo para solucionar el problema. Charon debería incluir mas información en los tickets, como una DIRECCION DE RED desde donde proviene la consulta, lo que nos daría un nivel de seguridad mayor. En el caso anterior, como el ticket llevaba tu dirección de red, mi intento de hacerme pasar por vos fallaría ya que el server podría ver que la dirección que lleva el ticket no es la mía y rechaza el pedido. Bárbaro!: (el formato del ticket sería ahora: Ticket(username:ws_address:servicename)) Otra duda...cada vez que necesite un servicio tendría que solicitar un ticket, incluso aunque repita algunos servicios (por ej. si quiero pedir mis mails mas de una vez en el día)? Este...no veo porqué no podrían rehusares los tickets...por ej. si vos obtenes un ticket para el servidor de mails deberías poder usarlo una y otra vez, tal vez almacenando una copia. Pero aún hay problemas. Yo debería mandar mi password al autenticador cada vez que necesite un servicio distinto para el que no tenga un ticket.

16 Página 16 Además enviar un password al autenticador por la red en texto plano no es nada seguro, cualquiera que esté monitoreando la red podría captarlo y copiarlo, e incluso enmascararse... Escena 3: La siguiente mañana se encuentran Athena y Euripides... Tengo una versión nueva de Charon que resuelve nuestros problemas! En serio!, tan rápido? Comencé a ver los problemas como requerimientos del sistema. El primero: Los usuarios deben ingresar su password una sola vez, cuando comienzan sus sesiones en las workstations. Es decir que no será necesario ingresar el password cada vez que se requiera un ticket para un servicio. Segundo: Los password no deben viajar por la red en texto plano. Veamos el primer requerimiento, el problema de que el usuario solo tenga que hacer uso de su password una vez. Para esto inventé un nuevo servicio de red, el ticket-granting service, un servicio que emitirá tickets a usuarios que ya han probado su identidad. Es decir que ya han obtenido previamente un ticketgranting ticket. El ticket-granting service es una versión de Charon que permite autenticarse con un ticket en lugar de con un password. Ahora el sistema de autenticación funciona así: vos te logueas en una workstation y usas un programa llamado kinit para contactar el servidor Charon. Vos probas tu identidad a Charon, y el programa kinit obtiene un ticket-granting ticket. Ahora si vos queres pedir al servidor de correo que te de tus mails, usando el ticket-granting ticket pedís a este nuevo servidor un ticket para ese servicio, sin tener que usar de nuevo tu password. Pero tendría que pedir un nuevo ticket-granting ticket cada vez que quiera pedir un ticket para un nuevo servicio que quiera usar... No, los tickets se podrían rehusar, una vez que obtenes un ticket-granting ticket no necesitas pedir otro, y con el obtenes los tickets para los servicios que precisas. Y ya que los tickets se pueden rehusar, si obtengo un ticket para un servicio particular, como el de correo o cualquier otro, no necesito seguir pidiendo nuevos tickets para ese servicio. Segundo: cuando se envía el password al server Charon para obtener el ticketgranting ticket, no debería viajar en texto plano. El tema es que, cuando usas el programa kinit para obtener el ticket-granting ticket, kinit no manda tu password al server Charon sino solo tu username. Charon conoce tu password conociendo quién sos, luego arma un paquete que contiene el ticket-granting ticket, y antes de enviarlo de vuelta lo encripta con tu clave. Cuando recibís el paquete ingresas tu password, kinit trata de desencriptarlo usando esa clave, si es la correcta tendrá éxito y habrás sido autenticado,

17 Página 17 sino...no. Con el ticket-granting ticket podrás pedir los tickets que necesites para acceder a los otros servicios. Que te parece? Estoy pensando en el hecho de identificarme solo una vez y que Charon sea capaz de darme tickets sin que yo me entere. Está relacionado con poder rehusar tickets, es algo necesario pero peligroso. A dónde queres llegar? Supone que estás usando una workstation insegura. Durante tu sesión obtenes varios tickets, y quedan allí luego de tu logout. Ahora yo ingreso a la workstation y los encuentro. Hago creer a la workstation que soy vos, y como los ticktes están a tu nombre puedo usarlos. Se podría resolver con un programa que destruya todos los tickets cada vez que un usuario salga de su sesión. No podemos confiar en que los usuarios no olviden destruir sus tickets cada vez que dejan su sesión, y aún cuando lo hagan mira esta situación: Tengo un programa que espía la red y copia los tickets que viajan por ella. Supongamos que mi víctima vas a ser vos, espero que inicies tu sesión en una workstation y copio tus tickets. Espero que termines tu sesión, y cambio mi dirección de red con la tuya para que coincida con la información que va en los tickets. Hago creer a mi workstation que soy vos, tengo tus tickets y nombre de usuario, y la dirección de red correcta; puedo usar los servicios en tu nombre. Ahora veo el problema, está en el hecho de que los tickets no tienen un límite de vida... Si, yo pienso que deberían tener información adicional: un tiempo por el cuál se considere un ticket válido(lifespan), y la fecha y hora en la cuál Charon emitió el ticket(timestamp). TICKET(username:address:servicename:lifespan:timestamp) Así cuando un servidor recibe un ticket debería chequear el nombre de usuario y dirección que dicen en el ticket con el nombre y dirección del que emite el pedido de servicio, y controlar la expiración del ticket mirando el timestamp y lifespan. Y en que como determinar el lifetime? No lo se...tal vez debería ser el tiempo de duración normal de una sesión: 8 horas. Así si me excedo de ese tiempo todos mis tickets expirarían, incluso el ticketgranting ticket, y yo tendría que volver a autenticarme con Charon. Es razonable, o no?

18 Página 18 Si, pero... Supongamos que yo hice copias de tus tickets, y vos abandonas tu sesión tras un par de horas de trabajo, aún los tickets seguirán siendo válidos por unas horas mas, y yo podría usarlos como antes. Es verdad! Habrá que seguir pensando una nueva solución.. Escena 5: La siguiente semana Athena se dirige a la oficina de Euripides... Lograrse encontrar alguna solución anoche? Pienso que si. Habíamos quedado en que los tickets serían reusables por un tiempo, pero el problema seguía si el usuario no completaba ese lapso y otro lo aprovechaba para enmascararse. No tendríamos ese problema si los tickets no fueran reusables. Pero estaríamos de nuevo en la situación de tener que solicitar un ticket cada vez que se quiera usar un servicio. Es verdad, pero planteemos el problema como un requerimiento: un servicio de red debe poder probar que una persona usando un ticket es la misma persona por la cual el ticket será usado. Es decir: yo quiero usar un cierto servicio, accedo al mismo a través a un programa cliente de mi workstation que envía a la máquina servidora mi nombre, dirección de red, y el ticket. necesario. En el ticket figuran el nombre de la persona que solicitó el ticket y la dirección de red desde donde lo hizo. También contiene el momento de expiración (lifespan y timestamp), todo encriptado por Charon. Respondamos las siguientes preguntas: Puede el servidor desencriptar el ticket? Ha expirado el ticket? Matchean el nombre de usuario y dirección de red del ticket con la persona que mandó el pedido? Con la primera pregunta se sabe si el ticket proviene de Charon, ya que él lo encripta con la clave del servicio especificado en la solicitud del cliente. La segunda pregunta nos dirá si sigue siendo válido el ticket o no. Si la tercer pregunta falla podría significar que otra persona ha captado el ticket. Pero si el nombre y dirección matchean, realmente no hay nada probado. Alguien podría cambiar su dirección de red y username apropiadamente para pasar como el usuario legítimo. La única forma de estar seguros sería mantener un secreto entre el servidor y el usuario en la forma de un password. O, porqué no, hacer que Charon mantenga un password entre el dueño legítimo de un ticket y el servidor. Charon envía una copia al servidor y una al usuario (una clave de sesión) así cuando el servidor recibe un ticket desde un usuario podría corroborar su identidad usando esta clave.

19 Pero como haría Charon para darle la clave a los dos? Página 19 El dueño del ticket obtendría la clave de sesión como parte de la respuesta de Charon: CHARON-REPLY [sessionkey ticket] Para el servidor la clave de sesión iría dentro del ticket: TICKET {sessionkey:username:address:servicename:lifespan:timestamp} Así un usuario que quiera un servicio debe construir algo así como un autenticador, éste contendría su nombre y la dirección de la workstation, todo encriptado con la clave de sesión (que recibiría al solicitar el ticket). AUTHENTICATOR {username:address} encriptado con la clave de sesión. El cliente envía el ticket mas el autenticador al servidor; éste primero desencripta el ticket (con su clave privada) y obtiene la siguiente información: El lifespan y timestamp del ticket. El nombre del dueño del ticket. La dirección de red del dueño del ticket. La clave de sesión. Si el ticket no ha expirado, el servidor usa la clave de sesión para desencriptar el autenticador, obteniendo el nombre de usuario y dirección de red, datos que compara con los obtenidos del ticket y con el nombre y dirección de la persona que envió el ticket y el autenticador. Si todo coincide el servidor puede concluir que el usuario es el dueño real del ticket. Estoy pensando que..., para romper el sistema necesitaría tener el autenticador correcto para el servicio... No, no solo necesitas tener el autenticador sino también el ticket, ya que el servidor necesita obtener de éste la clave de sesión para poder desencriptar el otro. Ok, pero...alguien podría robar tanto el ticket como el autenticador, y usarlos mientras el ticket no expire cambiando la dirección de red y nombre de usuario apropiadamente. O no? Es posible... Aunque, no necesitamos que los autenticadores sean reusables, y así evitamos ese problema! Entonces, el programa cliente crea el autenticador y lo manda junto con el ticket al servidor. Vos logras copiar ambos, pero ellos llegan al servidor antes de que vos alcances a usar las copias, como el autenticador solo sirve para una vez tu copia es inútil. Ahora la cuestión es cómo hacer para que el autenticador sirva para una sola vez...

20 Página 20 No hay problema, le agregamos un lifespan y timestamp lo suficientemente cortos. Cuando el server desencripta el autenticador chequea esos tiempos, si no ha expirado y todo lo demás es correcto te habrá autenticado. Si alguien hace una copia y cambia su dirección y nombre de usuario, el autenticador debería vencerse. Pero aquí hay otro problema, supongamos que lo que copio es el paquete que te manda Charon y que contiene dos copias de la clave de sesión: una para vos, y otra que va dentro del ticket. La que va dirigida a vos es la que usas para construir el autenticador, es decir que ahora lo podría construir yo y romper el sistema! Sobre eso también estuve pensando anoche. Cuando entras en una workstation usas el programa kinit para obtener un ticket-granting ticket, éste te pide nombre de usuario y se lo manda a Charon. Charon sabiendo quien sos conoce tu password, construye el ticket-granting ticket para vos, además crea una clave de sesión para que compartas con el ticket-granting service. Esta clave la pone en el ticket-granting ticket y otra copia en el paquete que va para vos, que además encripta con tu clave antes de mandártelo, así cualquiera que lo copie no podrá desencriptarlo si no conoce tu password. Kinit te pide ingresar tu password al recibir el paquete, al desencriptarlo obtiene la clave de sesión para el ticket-granting service.. Con el ticket-granting ticket un cliente puede solicitar un ticket para algún servicio. El cliente construye el autenticador para el ticket-granting service y lo encripta con la clave de sesión (ticket-granting session key), luego se lo manda junto con el ticket, nombre y dirección de red a Charon. El ticket-granting service recibe todo esto, luego de hacer los chequeos llega a obtener la clave de sesión que comparte con el usuario. Finalmente construye el ticket para el servicio requerido y una clave de sesión para que comparta con él. Arma el paquete para el usuario con el ticket y la clave de sesión para el servicio solicitado y lo manda todo encriptado con la ticket-granting session key. Así cualquiera que copie éste paquete no podrá conseguir el ticket para el servidor dicho porque no conocerá la clave de sesión que ha usado el grantingservice para encriptar el paquete. Creo que de esta manera logramos la seguridad, que te parece? Este sistema de claves de sesión parece aceptable. Ahora mirando desde otro punto de vista creo que sería necesario la autenticación mutua, que hay si información importante va a un servidor erróneo. Supongamos que todos los pasos se dan bien y el servidor llega a comprobar mi identidad, luego debería enviarme un mensaje de vuelta que confirme a mi (cliente) su identidad. Usando la sesión key encriptaría el mensaje de vuelta, yo podría desencriptarlo con la misma clave y comprobar así su identidad también. Un servidor falso no podría generar la respuesta correcta ya que no podría desencriptar el ticket y obtener la session key. Creo que tenemos la base para construir un Sistema de Autenticación. Luego de discutir sobre el nombre Athena y Euripides acuerdan en llamarlo Kerberos.

Autentificación Kerberos

Autentificación Kerberos Autentificación Kerberos Tabla de Contenidos 5. Accesos autentificación. Kerberos... 2 Supuestos... 3 Nombres... 3 Proceso de autentificación en Kerberos... 4 Resumamos los puntos centrales de este esquema:...

Más detalles

Single-Sign-On Índice de contenido

Single-Sign-On Índice de contenido Single-Sign-On Índice de contenido Introducción...2 Que es Single Sign-On...2 Descripción del esquema y componentes...2 Kerberos...3 LDAP...5 Consideraciones de Seguridad...6 Alcances de la solución implementada...7

Más detalles

Criptografía. Kerberos PGP TLS/SSL SSH

Criptografía. Kerberos PGP TLS/SSL SSH Criptografía Kerberos PGP TLS/SSL SSH Kerberos Kerberos - Características Protocolo de autenticación. Pensado para cliente-servidor. Acceso a servicios distribuidos en una red no segura. Provee autenticación

Más detalles

Cómo funciona Solución mwatcher Let's connect

Cómo funciona Solución mwatcher Let's connect Cómo funciona Solución mwatcher Let's connect Introducción En este documento vamos a explicar cuáles son las problemáticas que nos encontramos a la hora de realizar un telemantenimiento o acceso remoto

Más detalles

Sistemas Operativos Distribuidos

Sistemas Operativos Distribuidos Fiabilidad y Seguridad Fallos Conceptos Básicos Diversos elementos de un sistema distribuido pueden fallar: Procesadores, red, dispositivos, software, etc. Tipos de fallos: Transitorios: Falla una vez

Más detalles

Fig. 1: Secuencia de mensajes de la autenticación Kerberos

Fig. 1: Secuencia de mensajes de la autenticación Kerberos PROTOCOLO KERBEROS (Administración Avanzada de Sistemas Operativos. Grado en Ingeniería Informática. Facultad de Informática. Universidad de Murcia. Curso 2011/12). PARTICIPANTES: - Un servidor Kerberos,

Más detalles

CRIPTOGRAFIA. Qué es, usos y beneficios de su utilización. Universidad Nacional del Comahue

CRIPTOGRAFIA. Qué es, usos y beneficios de su utilización. Universidad Nacional del Comahue CRIPTOGRAFIA Qué es, usos y beneficios de su utilización Introducción Antes, computadoras relativamente aisladas Hoy, computadoras en redes corporativas conectadas además a Internet Transmisión de información

Más detalles

Qué es el protocolo SSH y cómo configurarlo para mejorar la seguridad de acceso a los servidores Linux

Qué es el protocolo SSH y cómo configurarlo para mejorar la seguridad de acceso a los servidores Linux Qué es el protocolo SSH y cómo configurarlo para mejorar la seguridad de acceso a los servidores Linux Cardenal Gardoki, 1 48008 BILBAO (Vizcaya) Teléfono: 902 012 199 www.hostalia.com Cuando uno contrata

Más detalles

TALLER DE DETECTIVES: DESCIFRANDO MENSAJES SECRETOS. 1. Introducción

TALLER DE DETECTIVES: DESCIFRANDO MENSAJES SECRETOS. 1. Introducción TALLER DE DETECTIVES: DESCIFRANDO MENSAJES SECRETOS charamaria@gmail.com Resumen. Notas del taller para estudiantes Taller de Detectives: descifrando mensajes secretos dictado durante el tercer festival

Más detalles

HERRAMIENTAS DE SEGURIDAD

HERRAMIENTAS DE SEGURIDAD Seguridad Informática I M.C. Cintia Quezada Reyes HERRAMIENTAS DE SEGURIDAD Siempre es conveniente instalar herramientas de seguridad y es aconsejable que éstas sean las que se consideren necesarias después

Más detalles

Introducción a la Firma Electrónica en MIDAS

Introducción a la Firma Electrónica en MIDAS Introducción a la Firma Electrónica en MIDAS Firma Digital Introducción. El Módulo para la Integración de Documentos y Acceso a los Sistemas(MIDAS) emplea la firma digital como método de aseguramiento

Más detalles

Redes de Computadores

Redes de Computadores Redes de Computadores Jorge Baier A. y Álvaro Soto Departamento de Ciencia de la Computación Escuela de Ingeniería Pontificia Universidad Católica de Chile [jabaier,asoto]@ing.puc.cl Diseño de Redes En

Más detalles

Lista de verificación norma ISO 17799 (Realizada con base en la lista de chequeo del instituto SANS, la cual fue elaborada por Val Thiagarajan)

Lista de verificación norma ISO 17799 (Realizada con base en la lista de chequeo del instituto SANS, la cual fue elaborada por Val Thiagarajan) Lista de verificación norma ISO 17799 (Realizada con base en la lista de chequeo del instituto SANS, la cual fue elaborada por Val Thiagarajan) 3. Política de seguridad 3.1. Política de seguridad de la

Más detalles

Seguridad en la transmisión de Datos

Seguridad en la transmisión de Datos Seguridad en la transmisión de Datos David Peg Montalvo Santiago de Compostela Noviembre 2005 Índice 01 Seguridad. Ámbito de aplicación 02 Control de acceso 03 Conceptos básicos de criptografía 04 PKI

Más detalles

! Sección 1 Acceso a llaves

! Sección 1 Acceso a llaves ! Sección 1 Acceso a llaves Este es el programa que guarda todas nuestras contraseñas, se encuentra en la sección utilidades. Por ejemplo, cuando en el programa Adium o Skype ( o tantos otros ) usamos

Más detalles

9243059 Edición 1 ES. Nokia y Nokia Connecting People son marcas comerciales registradas de Nokia Corporation

9243059 Edición 1 ES. Nokia y Nokia Connecting People son marcas comerciales registradas de Nokia Corporation 9243059 Edición 1 ES Nokia y Nokia Connecting People son marcas comerciales registradas de Nokia Corporation Cliente de VPN Guía de usuario 9243059 Edición 1 Copyright 2005 Nokia. Reservados todos los

Más detalles

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO Facultad de Ingeniería Redes de Datos Práctica 11 Capa6 Modelo OSI. PRÁCTICA 11 SSH: Secure Shell

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO Facultad de Ingeniería Redes de Datos Práctica 11 Capa6 Modelo OSI. PRÁCTICA 11 SSH: Secure Shell 1.- Objetivos de Aprendizaje El alumno: UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO PRÁCTICA 11 SSH: Secure Shell Al finalizar la práctica, conocerá la importancia de utilizar el protocolo SSH (Secure Shell)

Más detalles

Kerberos. Fernando Martínez. 11 de diciembre de 2006. Departament de Matemàtica Aplicada II Universitat Politècnica de Catalunya

Kerberos. Fernando Martínez. 11 de diciembre de 2006. Departament de Matemàtica Aplicada II Universitat Politècnica de Catalunya Kerberos Fernando Martínez Departament de Matemàtica Aplicada II Universitat Politècnica de Catalunya 11 de diciembre de 2006 ( MA2 UPC) Kerberos 11 de diciembre de 2006 1 / 13 Introducción Perro mitológico

Más detalles

Escritorios Remotos 1. RDP

Escritorios Remotos 1. RDP Escritorios Remotos 1. RDP RDP (Remote Desktop Protocol = Protocolo de Acceso a un Escritorio Remoto) es un protocolo desarrollado por Microsoft que permite manipular, de manera remota, el escritorio de

Más detalles

MENSAREX: SISTEMA DE MENSAJERÍA DEL MINREX Gretel García Gómez gretel@minrex.gov.cu Ministerio de Relaciones Exteriores Cuba.

MENSAREX: SISTEMA DE MENSAJERÍA DEL MINREX Gretel García Gómez gretel@minrex.gov.cu Ministerio de Relaciones Exteriores Cuba. MENSAREX: SISTEMA DE MENSAJERÍA DEL MINREX Gretel García Gómez gretel@minrex.gov.cu Ministerio de Relaciones Exteriores Cuba Resumen El presente trabajo da solución a dos de los problemas informáticos

Más detalles

Seguridad del Protocolo HTTP

Seguridad del Protocolo HTTP Seguridad del Protocolo HTTP - P R O T O C O L O H T T P S. - C O N E X I O N E S S E G U R A S : S S L, TS L. - G E S T IÓN D E C E R T IF I C A D O S Y A C C E S O --S E G U R O C O N H T T P S Luis

Más detalles

Privacidad.

Privacidad. <Nombre> <Institución> <e-mail> Privacidad Contenido Privacidad Riesgos principales Cuidados a tener en cuenta Fuentes Privacidad (1/3) En Internet tu privacidad puede verse expuesta: independientemente

Más detalles

Cifrado de la información. Guía corporativa

Cifrado de la información. Guía corporativa Cifrado de la información Guía corporativa La encriptación de datos en las empresas 1. Introducción 3 Guía corporativa de encriptación de datos 1. Introducción La información es uno de los recursos más

Más detalles

Seguridad, Web y Java

Seguridad, Web y Java 2 Seguridad, Web y Java Seguridad, Web y Java Daniel López Janáriz d.lopez@uib.es Seguridad, Web y Java 3 1. Introducción: Puntos a tener en cuenta cuando hablamos de seguridad La seguridad al 100% no

Más detalles

http://cartilla.cert.br/

http://cartilla.cert.br/ http://cartilla.cert.br/ Cuanta más información proporcionas en Internet, más difícil es preservar tu privacidad Nada impide que abras las puertas a tu privacidad y que libre y espontáneamente publiques

Más detalles

Seguridad Informática

Seguridad Informática Seguridad Informática Cuando hablamos de Informática nos referimos a todos los recursos que están relacionados con el manejo de la información y, como es de todos conocido la información viene a representar

Más detalles

Internet Firewalls Linux ipchains.

Internet Firewalls Linux ipchains. Internet Firewalls Linux ipchains. I Parte. Firewalls Introducción. Actualmente, Internet es la principal vía para consultar y publicar información de una forma sencilla, económica y revolucionaria. Del

Más detalles

Autenticación Revisitada

Autenticación Revisitada Autenticación Revisitada Kerberos Desarrollado como parte del Proyecto Athena en MIT, con el propósito de autentificar clientes a servidores y vice versa. Se considera que las siguientes amenazas existen:

Más detalles

Transferencia segura de Datos en Línea con SSL

Transferencia segura de Datos en Línea con SSL Transferencia segura de Datos en Línea con SSL Guía para comprender los certificados SSL, cómo funcionan y su aplicación 1. Aspectos generales 2. Qué es SSL? 3. Cómo saber si un sitio web es seguro 4.

Más detalles

QUÉ OCURRE EN LA ACTUALIDAD CON LA SEGURIDAD? INVESTIGA

QUÉ OCURRE EN LA ACTUALIDAD CON LA SEGURIDAD? INVESTIGA QUÉ OCURRE EN LA ACTUALIDAD CON LA SEGURIDAD? INVESTIGA AUTORÍA MARÍA CATALÁ CARBONERO TEMÁTICA SEGURIDAD, REDES ETAPA CICLO SUPERIOR DE INFORMÁTICA Y PROFESORADO Resumen La seguridad en los sistemas en

Más detalles

Seguridad en Internet. Introducción a las Redes e Internet

Seguridad en Internet. Introducción a las Redes e Internet Seguridad en Internet Introducción a las Redes e Internet Suposiciones En cualquier lugar del mundo se puede acceder a protocolos y algoritmos criptográficos. Siempre existe un conjunto de nodos que comparten

Más detalles

1. INTRODUCCION. -ATAQUES A LA SEGURIDAD: Qué acciones pueden comprometer la seguridad de la información que

1. INTRODUCCION. -ATAQUES A LA SEGURIDAD: Qué acciones pueden comprometer la seguridad de la información que TEMA 7: TECNOLOGIAS Y SERVICIOS DE SEGURIDAD EN INTERNET 1. INTRODUCCION Los requisitos en seguridad de la información manejada dentro de una organización han evolucionado sustancialmente en las últimas

Más detalles

VÍDEO intypedia003es LECCIÓN 3: SISTEMAS DE CIFRA CON CLAVE PÚBLICA. AUTOR: Gonzalo Álvarez Marañón

VÍDEO intypedia003es LECCIÓN 3: SISTEMAS DE CIFRA CON CLAVE PÚBLICA. AUTOR: Gonzalo Álvarez Marañón VÍDEO intypedia003es LECCIÓN 3: SISTEMAS DE CIFRA CON CLAVE PÚBLICA AUTOR: Gonzalo Álvarez Marañón Consejo Superior de Investigaciones Científicas, Madrid, España Hola, bienvenidos a intypedia. Conocidos

Más detalles

Delitos. Informáticos GUÍA DE USUARIO DELITOS INFORMÁTICOS

Delitos. Informáticos GUÍA DE USUARIO DELITOS INFORMÁTICOS GUÍA DE USUARIO DELITOS INFORMÁTICOS El uso de Internet, además de darnos mucha información, también nos ofrece algunos peligros. Al igual que nuestro mundo real, en el mundo virtual también hay gente

Más detalles

Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows. Módulo 4: Servicios de Internet. FTP

Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows. Módulo 4: Servicios de Internet. FTP Ministerio de Educación,Cultura y Deporte. Aulas en Red. Windows Módulo 4: Servicios de Internet. FTP Aulas en red. Aplicaciones y servicios. Windows Servicio FTP Con anterioridad, en este mismo módulo

Más detalles

Por criptografía se entiende un conjunto de técnicas que tratan sobre la protección de la información frente a observadores no autorizados.

Por criptografía se entiende un conjunto de técnicas que tratan sobre la protección de la información frente a observadores no autorizados. Criptografía y PGP Criptografía: Introducción. Criptografía simétrica y antisimétrica. PGP: Introducción. Fundamentos de PGP. Tutorial práctico de PGP: Instalación y generación de claves. Uso. Criptografía:

Más detalles

Algunos problemas de ambientes distribuidos. Passwords so bre LAN viajan en texto claro. Pueden ser interceptados o descubiertos

Algunos problemas de ambientes distribuidos. Passwords so bre LAN viajan en texto claro. Pueden ser interceptados o descubiertos ITESM- CEM MCC Sistemas Distribuidos Ambientes DCE Erika MATA SANCHEZ emata@itesm.mx Septiembre 2007 Introducción Algunos problemas de ambientes distribuidos Passwords so bre LAN viajan en texto claro

Más detalles

Seguridad SSL Número: 18 Sección: Artículos.

Seguridad SSL Número: 18 Sección: Artículos. Seguridad SSL Número: 18 Sección: Artículos. Es un hecho de todos conocido que Internet constituye un canal de comunicaciones inseguro, debido a que la información que circula a través de esta vasta red

Más detalles

Capitulo 6 VPN y Firewalls

Capitulo 6 VPN y Firewalls 6. Antecedentes Los empleados móviles, las oficinas en casa y el telecommuter demandan la extensión de los niveles de servicio mas alla de la Intranet VPN es una red que en alguna parte pasa a través de

Más detalles

Rawel E. Luciano B. 2011-2281. Sistema Operativo III 15- SERVIDOR EMAIL. José Doñe

Rawel E. Luciano B. 2011-2281. Sistema Operativo III 15- SERVIDOR EMAIL. José Doñe Nombre: Rawel E. Luciano B. Matricula: 2011-2281 Materia: Sistema Operativo III How to: 15- SERVIDOR EMAIL Profesor: José Doñe Servidor de Correo Un servidor de correo es una aplicación informática ubicada

Más detalles

http://cartilla.cert.br/

http://cartilla.cert.br/ http://cartilla.cert.br/ Las cuentas y las contraseñas son los mecanismos de autentificación más utilizados actualmente en Internet. Las cuentas y las contraseñas permiten que los sistemas sepan quién

Más detalles

Los virus informáticos

Los virus informáticos SEGURIDAD DE LA INFORMACIÓN Es el estudio de los métodos y medios de protección de los sistemas de información y comunicaciones frente a amenazas de los siguientes tipos: - Sin intervención humana Amenazas

Más detalles

Protección de los clientes contra los ataques a la red

Protección de los clientes contra los ataques a la red Protección de los clientes contra los ataques a la red La información incluida en este documento representa el punto de vista actual de Microsoft Corporation acerca de los temas tratados hasta la fecha

Más detalles

Estándares para Sistemas de Tickets Entrantes/Salientes (TITO)

Estándares para Sistemas de Tickets Entrantes/Salientes (TITO) Estándares para Sistemas de Tickets Entrantes/Salientes (TITO) Superintendencia de Casinos de Juego (SCJ) CHILE Santiago de Chile, marzo de 2015 Modificaciones a los Estándares para Sistemas de Tickets

Más detalles

Circular de Tecnología Pautas de seguridad para el desarrollo de aplicaciones Web

Circular de Tecnología Pautas de seguridad para el desarrollo de aplicaciones Web ASIT 20070501 CT Pautas de seguridad para aplicaciones web v1 2007-05-16 Documento de Circular de Tecnología Pautas de seguridad para el desarrollo de aplicaciones Web Versión 01 ARCHIVO: ASIT 20070501

Más detalles

Firebird y Zebedee. Creado por Artur Anjos Trindade artur@arsoft.pt. Traducido por Santiago Russo

Firebird y Zebedee. Creado por Artur Anjos Trindade artur@arsoft.pt. Traducido por Santiago Russo Firebird y Zebedee Creado por Artur Anjos Trindade artur@arsoft.pt Traducido por Santiago Russo Uso de Zebedee con Firebird para cifrar y comprimir el tráfico de red Tabla de contenidos 1. Introducción

Más detalles

Sistema de comunicación móvil con cifrado de seguridad. Hermes es un SISTEMA de COMUNICACIÓN CIFRADA para MÓVILES

Sistema de comunicación móvil con cifrado de seguridad. Hermes es un SISTEMA de COMUNICACIÓN CIFRADA para MÓVILES Qué es Hermes? Hermes es un SISTEMA de COMUNICACIÓN CIFRADA para MÓVILES Para qué sirve Hermes? Hermes nos permite comunicarnos con nuestros contactos con la garantía de que nuestra privacidad no está

Más detalles

Arquitectura y seguridad

Arquitectura y seguridad En el desarrollo del SIGOB nos hemos enfrentado a diversos problemas que nos han llevado a investigar y desarrollar nuestras propias tecnologías. En este documento presentamos cada uno de los desarrollos

Más detalles

FUNDAMENTOS DE COMPUTACION TECNOLOGIA VPN. Integrantes: Luis Mario Galarza, Andrés Santos P. INTRODUCCION ( QUE ES VPN?)

FUNDAMENTOS DE COMPUTACION TECNOLOGIA VPN. Integrantes: Luis Mario Galarza, Andrés Santos P. INTRODUCCION ( QUE ES VPN?) FUNDAMENTOS DE COMPUTACION TECNOLOGIA VPN Integrantes: Luis Mario Galarza, Andrés Santos P. INTRODUCCION ( QUE ES VPN?) La Red Privada Virtual (VPN), cuyo nombre deriva del inglés Virtual Private Network,

Más detalles

Tecnologías De La Información Y Comunicación I. Firewall Y Proxy. Integrantes: Héctor Duran. Katherine Zumelzu

Tecnologías De La Información Y Comunicación I. Firewall Y Proxy. Integrantes: Héctor Duran. Katherine Zumelzu Firewall Y Proxy Integrantes: Héctor Duran Katherine Zumelzu Fecha: 15/04/2015 Índice Qué es un firewall?... 3 Tipos de Firewall... 4 -Nivel de aplicación de Pasarela:... 4 -Circuito a nivel de Pasarela:...

Más detalles

Encriptación en Redes

Encriptación en Redes Encriptación en Redes Integrantes: Patricio Rodríguez. Javier Vergara. Sergio Vergara. Profesor: Agustín González. Fecha: 28 de Julio de 2014. Resumen Un tema importante actualmente en la redes de computadores,

Más detalles

2.3.5 Capa de sesión. Protocolos

2.3.5 Capa de sesión. Protocolos 2.3.5 Capa de sesión Protocolos RPC El RPC (del inglés Remote Procedure Call, Llamada a Procedimiento Remoto) es un protocolo que permite a un programa de computadora ejecutar código en otra máquina remota

Más detalles

CRIPTOGRAFÍA SIMÉTRICA Y ASIMÉTRICA

CRIPTOGRAFÍA SIMÉTRICA Y ASIMÉTRICA CRIPTOGRAFÍA SIMÉTRICA Y ASIMÉTRICA Para generar una transmisión segura de datos, debemos contar con un canal que sea seguro, esto es debemos emplear técnicas de forma que los datos que se envían de una

Más detalles

Seguridad en redes -309-

Seguridad en redes -309- Problema 1. Teniendo en cuenta que una organización, conectada a Internet, desea controlar ciertas operaciones en unos determinados servicios y, además, ocultar las direcciones IP privadas utilizadas en

Más detalles

REDES DE COMPUTADORES I INFORME ESCRITORIO REMOTO

REDES DE COMPUTADORES I INFORME ESCRITORIO REMOTO REDES DE COMPUTADORES I INFORME ESCRITORIO REMOTO Nombres: Diego Carvajal R. Sebastian Valdes M. Ayudante: Evandry Ramos Profesor: Agustín J. González Fecha: 6 / 09 / 2013 1. Resumen: Este informe, se

Más detalles

Laboratorio de Computación IV. Clase 6. Andrés Fortier

Laboratorio de Computación IV. Clase 6. Andrés Fortier Laboratorio de Computación IV Clase 6 Andrés Fortier Consultas? Comando: ssh. Contenidos web: PAAS (Openshift). Herramienta: github (+remotes +issues). Tarea Jugar un poco con openshift Ahora pueden romper

Más detalles

Software de Cifrado de Ficheros AxCrypt para Windows. Guía Rápida de Instalación. Versión 1.6.1 2005-03

Software de Cifrado de Ficheros AxCrypt para Windows. Guía Rápida de Instalación. Versión 1.6.1 2005-03 Software de Cifrado de Ficheros AxCrypt para Windows Guía Rápida de Instalación Versión 1.6.1 2005-03 Copyright 2004 Svante Seleborg, Axantum Software AB 2(24) Esta guía describe como instalar y rápidamente

Más detalles

AUTENTIFICACIÓN HTTP

AUTENTIFICACIÓN HTTP AUTENTIFICACIÓN HTTP Emilio Casbas. 18/1/2006 INTRODUCCIÓN. 1. Autentificación digest 2. Autentificación básica 2.1Ejemplo práctico. 3. Autentificación proxy 3.1Ejemplo práctico 4. Conclusiones INTRODUCCIÓN.

Más detalles

Capítulo 4: Diseño de la solución basada en software. 4.1 Diseño general del sistema y especificaciones de los componentes

Capítulo 4: Diseño de la solución basada en software. 4.1 Diseño general del sistema y especificaciones de los componentes Capítulo 4: Diseño de la solución basada en software 4.1 Diseño general del sistema y especificaciones de los componentes El sistema constará de tres elementos fundamentales: los clientes, el punto de

Más detalles

Bitácora del sistema - Introducción

Bitácora del sistema - Introducción Bitácora del sistema M A T E R I A : A R Q U I T E C T U R A A V A N Z A D A P R O F E S O R : J U A N J O S E M U Ñ O Z A L U M N O : F E D E R I C O D I B E N E D E T T O M A T R I C U L A : 7 6 5 6

Más detalles

Problemas sobre DNS y HTTP Sistemas Telemáticos I

Problemas sobre DNS y HTTP Sistemas Telemáticos I Problemas sobre DNS y HTTP Sistemas Telemáticos I Universidad Rey Juan Carlos Mayo de 2005 Problema 1 A las 9 de la mañana, cuando la red aún va rápida (aunque las caches están todas vacías), Juan hace

Más detalles

Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA)

Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA) Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA) SOLUCIÓN (más completa que el mínimo requerido para obtener los máximos puntajes) Pregunta 1 En el sistema de nombre de dominio (DNS): a)

Más detalles

Funcionamiento de los dispositivos de un sistema microinformático.

Funcionamiento de los dispositivos de un sistema microinformático. Funcionamiento de los dispositivos de un sistema microinformático. En esta sección nos centraremos en los conceptos más generalizados sobre el disco duro: Las particiones Formatos Sector de arranque Se

Más detalles

ADMINISTRACIÓN FEDERAL DE INGRESOS PÚBLICOS GUÍA PARA GESTIÓN DE CERTIFICADOS DIGITALES

ADMINISTRACIÓN FEDERAL DE INGRESOS PÚBLICOS GUÍA PARA GESTIÓN DE CERTIFICADOS DIGITALES ADMINISTRACIÓN FEDERAL DE INGRESOS PÚBLICOS AUTORIDAD CERTIFICANTE GUÍA PARA GESTIÓN DE CERTIFICADOS DIGITALES Versión 2.07 27/06/2012 ADMINISTRACION FEDERAL DE INGRESOS PUBLICOS Página 1 de 23 INDICE

Más detalles

SSL: Secure Sockets Layer Kerberos PGP Millicent

SSL: Secure Sockets Layer Kerberos PGP Millicent Seguridad: Ejemplos de aplicación César Llamas Bello Sistemas Distribuidos Curso 2003-2004 Departamento de Informática de la Universidad de Valladolid Índice SSL: Secure Sockets Layer Kerberos PGP Millicent

Más detalles

SIOM-Interfaz AM Manual de Usuario

SIOM-Interfaz AM Manual de Usuario SIOM-Interfaz AM Manual de Usuario Alfonso XI, 6 28014 Madrid F(+34) 91 524 03 96 www.omie.es Ref. MU_InterfazAM.doc Versión 5.0 Fecha: 2014-09-10 ÍNDICE 1 INTRODUCCIÓN 3 2 REQUISITOS PREVIOS 4 2.1 COMPONENTES

Más detalles

Protocolos de Seguridad

Protocolos de Seguridad Protocolos de Seguridad Un escenario típico consiste de un número de principales, tales como individuos, compañías, computadoras, lectores de tarjetas magnéticas, los cuales se comunican usando una variedad

Más detalles

EVALUACIóN DE LA ACTIVIDAD 5.8: Configuración router ADSL.

EVALUACIóN DE LA ACTIVIDAD 5.8: Configuración router ADSL. EVALUACIóN DE LA ACTIVIDAD 5.8: Configuración router ADSL. 1.- Qué diferencia hay entre NAT y PAT? NAT: Network Adress Translation. El router enmascara la dirección IP origen de los paquetes poniendola

Más detalles

Implementando iphone e ipad Administración de dispositivos móviles

Implementando iphone e ipad Administración de dispositivos móviles Implementando iphone e ipad Administración de dispositivos móviles ios es compatible con la administración de dispositivos móviles, brindando a las empresas la capacidad de administrar implementaciones

Más detalles

Seguretat en xarxes. Tallafocs, IDS, IPS, filtrat de continguts

Seguretat en xarxes. Tallafocs, IDS, IPS, filtrat de continguts Seguretat en xarxes. Tallafocs, IDS, IPS, filtrat de continguts Índice de contenido Seguretat en xarxes. Tallafocs, IDS, IPS, filtrat de continguts...1 Licencia...1 Cortafuegos...1 Sin estado...2 Con estado

Más detalles

Capítulo 4. Análisis de protecciones de redes inalámbricas

Capítulo 4. Análisis de protecciones de redes inalámbricas Capítulo 4. Análisis de protecciones de redes inalámbricas Análisis de algunas herramientas de apoyo que muestran las vulnerabilidades de seguridad en las redes WIFI. 4.1 Qué son los sniffers? Ethernet

Más detalles

ESCUELA POLITECNICA DEL EJERCITO

ESCUELA POLITECNICA DEL EJERCITO ESCUELA POLITECNICA DEL EJERCITO Carrera de Ingeniería a de Sistemas e Informática Desarrollo de una aplicación Sign On en Smart Cards Vinicio Ramirez M. SEGURIDAD INFORMÁTICA La Seguridad Informática

Más detalles

Ing. Cynthia Zúñiga Ramos

Ing. Cynthia Zúñiga Ramos Ing. Cynthia Zúñiga Ramos Criptografía Criptografía Datos Datos Encriptación ase4bhl Desencriptación Datos cifrados Confidencialidad en las comunicaciones Algoritmos Hash de una dirección Algoritmos

Más detalles

Tema 41.- Medidas de seguridad en conectividad de redes: Cortafuegos, IDS, IPS, filtro de contenidos.

Tema 41.- Medidas de seguridad en conectividad de redes: Cortafuegos, IDS, IPS, filtro de contenidos. Tema 41.- Medidas de seguridad en conectividad de redes: Cortafuegos, IDS, IPS, filtro de contenidos. Introducción...1 1 Cortafuegos Firewall-... 3 1.1 Políticas de control de acceso... 4 1.2 Órganización

Más detalles

Tu administrador te dirá la dirección en la cual entrarás. La pantalla para acceder es como esta:

Tu administrador te dirá la dirección en la cual entrarás. La pantalla para acceder es como esta: Indice Manual de uso de la interfaz web de RT...2 Entrando al sistema...2 Página de inicio...3 RT en un vistazo...3 Barra de navegación superior...4 Barra de navegación izquierda...4 Interfaz de los tickets...5

Más detalles

Tutorial Redes Privadas Virtuales (VPNs sobre ADSL)

Tutorial Redes Privadas Virtuales (VPNs sobre ADSL) Tutorial Redes Privadas Virtuales (VPNs sobre ADSL) Cuando su empresa cuenta con más de una sucursal o mantiene intercambio constante de información entre sus proveedores y clientes, es vital encontrar

Más detalles

Trabajo elaborado para el área de Gestión de Redes y Datos

Trabajo elaborado para el área de Gestión de Redes y Datos WINDOWS ESSENTIALS David Stiven Monsalve Juan Pablo Franco Marcela Aguirre Sebastián Cardona FICHA: 625354 Trabajo elaborado para el área de Gestión de Redes y Datos Alejandro Gómez Martínez Ingeniero

Más detalles

CAPÍTULO II USO Y RESPONSABILIDADES DE LA RED

CAPÍTULO II USO Y RESPONSABILIDADES DE LA RED CAPÍTULO II USO Y RESPONSABILIDADES DE LA RED Existen numerosas cuestiones que deben abordarse al elaborar una política de seguridad: 1. Quién esta autorizado para usar los recursos? 2. Cuál es el uso

Más detalles

TEMA 2 - parte 3.Gestión de Claves

TEMA 2 - parte 3.Gestión de Claves TEMA 2 - parte 3.Gestión de Claves SEGURIDAD EN SISTEMAS DE INFORMACIÓN Libre Elección http://ccia.ei.uvigo.es/docencia/ssi 1 de marzo de 2011 FJRP, FMBR 2010 ccia SSI 1. Gestion de claves Dos aspectos

Más detalles

Práctica GESTIÓN Y UTILIZACIÓN DE REDES LOCALES. Curso 2001/2002. Monitorización de una LAN

Práctica GESTIÓN Y UTILIZACIÓN DE REDES LOCALES. Curso 2001/2002. Monitorización de una LAN Práctica GESTIÓN Y UTILIZACIÓN DE REDES LOCALES Curso 2001/2002 Monitorización de una LAN Introducción Un monitor de red es un programa que nos permite observar el tráfico de la red, conocer el estado

Más detalles

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO Facultad de Ingeniería Redes de Datos Práctica 10 Capa 5 Modelo OSI

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO Facultad de Ingeniería Redes de Datos Práctica 10 Capa 5 Modelo OSI PRÁCTICA 10 Filtrado de puertos TCP/UDP mediante un firewall 1.- Objetivo de Aprendizaje El alumno: Al finalizar la práctica el alumno comprenderá algunos conceptos de la Capa 5 del Modelo OSI. Manejará

Más detalles

El MODEM es el gestor de la conexión a Internet, el medio para repartir Internet a las terminales es por medio del ROUTER.

El MODEM es el gestor de la conexión a Internet, el medio para repartir Internet a las terminales es por medio del ROUTER. En el siguiente informe intentaré explicarles que es y como funciona un sniffer, pero para poder comprenderlo tenemos que tener idea de cómo esta diagramada una red con sus componentes básicos como ser

Más detalles

1.1. Características del sistema... 2

1.1. Características del sistema... 2 1.1. Características del sistema... 2 1.2. Instalación del sistema... 3 1.2.1. Carpetas del sistema... 9 1.2.2. Reparación del sistema... 10 1.2.3. Eliminación del sistema... 11 1.3. Abrir el sistema...

Más detalles

LABORATORIO DE FTP. PRESENTADO POR: Diana Maritza Aragón Marta Moreno Luis Miguel Pérez. PRESENTADO A: Marcelo Utard Javier Bozzuto

LABORATORIO DE FTP. PRESENTADO POR: Diana Maritza Aragón Marta Moreno Luis Miguel Pérez. PRESENTADO A: Marcelo Utard Javier Bozzuto LABORATORIO DE FTP PRESENTADO POR: Diana Maritza Aragón Marta Moreno Luis Miguel Pérez PRESENTADO A: Marcelo Utard Javier Bozzuto ESCUELA DE GRADUADOS DE ELECTRÓNICA Y TELECOMUNICACIONES LABORATORIO DE

Más detalles

Técnicas de cifrado. Clave pública y clave privada:

Técnicas de cifrado. Clave pública y clave privada: Técnicas de cifrado. Clave pública y clave privada: - Pretty Good Privacy (PGP). GNU Privacy Good (GPG). - Seguridad a nivel de aplicación: SSH ( Secure Shell ). - Seguridad en IP (IPSEC). - Seguridad

Más detalles

Capítulo 2: El protocolo WEP. Capítulo 2. El protocolo WEP

Capítulo 2: El protocolo WEP. Capítulo 2. El protocolo WEP Capítulo 2 El protocolo WEP 23 Capítulo 2: El protocolo WEP 2.0 Introducción La seguridad es un aspecto que cobra especial relevancia cuando hablamos de redes inalámbricas. Para tener acceso a una red

Más detalles

Seguridad y Alta Disponibilidad

Seguridad y Alta Disponibilidad Seguridad y Alta Disponibilidad Virtual Private Networks Félix Villanueva Molina Escuela Superior de Informática Universidad de Castilla-La Mancha Introducción Introducción Definición: Transportar datos

Más detalles

COMUNICACIÓN PARA TECNIMAP 2000 PRESENTADA POR SIA, SISTEMAS INFORMÁTICOS ABIERTOS.

COMUNICACIÓN PARA TECNIMAP 2000 PRESENTADA POR SIA, SISTEMAS INFORMÁTICOS ABIERTOS. COMUNICACIÓN PARA TECNIMAP 2000 PRESENTADA POR SIA, SISTEMAS INFORMÁTICOS ABIERTOS. Correspondiente al punto del temario: Aspectos tecnológicos de la Administración Electrónica.- Infraestructura tecnológica

Más detalles

HOW TO SOBRE REMOTE ACCESS VPN MODE EN LINUX

HOW TO SOBRE REMOTE ACCESS VPN MODE EN LINUX HOW TO SOBRE REMOTE ACCESS VPN MODE EN LINUX 1- En este how to realizaremos una conexión remota mediante vpn; lo que haremos es comprobar primero que las maquinas que vamos a conectar, se puedan ver y

Más detalles

CAPÍTULO VI. RESULTADOS, PRUEBAS Y CONCLUSIONES DE LA APLICACIÓN.

CAPÍTULO VI. RESULTADOS, PRUEBAS Y CONCLUSIONES DE LA APLICACIÓN. CAPÍTULO VI. RESULTADOS, PRUEBAS Y CONCLUSIONES DE LA APLICACIÓN. Finalmente en este último capítulo se conocen los resultados, las pruebas y las conclusiones finales de la aplicación Web para el monitoreo

Más detalles

Introducción. Introducción. Seguridad y Alta Disponibilidad Virtual Private Networks. Definición:

Introducción. Introducción. Seguridad y Alta Disponibilidad Virtual Private Networks. Definición: Seguridad y Alta Disponibilidad Virtual Private Networks Félix Villanueva Molina Escuela Superior de Informática Universidad de Castilla-La Mancha Introducción Definición: Transportar datos privados sobre

Más detalles

Protocolo: POP3: Post Office Protocol Versión 3.

Protocolo: POP3: Post Office Protocol Versión 3. Protocolo: POP3: Post Office Protocol Versión 3. Es un protocolo para la gestión de correo en Internet. Es el más utilizado junto con SMTP, porque aunque en algunos nodos menores de Internet normalmente

Más detalles

Seguridad Wi-Fi. Seguridad Wi-Fi

Seguridad Wi-Fi. Seguridad Wi-Fi Cuando Ud. se comunica a través de Internet usando una conexión cableada o inalámbrica, querrá asegurar que sus comunicaciones y ficheros tienen privacidad y están protegidos. Si sus transmisiones no son

Más detalles

AVG File Server. Manual del usuario. Revisión del documento 2015.08 (22.09.2015)

AVG File Server. Manual del usuario. Revisión del documento 2015.08 (22.09.2015) AVG File Server Manual del usuario Revisión del documento 2015.08 (22.09.2015) C opyright AVG Technologies C Z, s.r.o. Reservados todos los derechos. El resto de marcas comerciales son propiedad de sus

Más detalles

Redes Privadas Virtuales (VPN)

Redes Privadas Virtuales (VPN) Redes Privadas Virtuales (VPN) Integrantes: - Diego Álvarez Delgado - Carolina Jorquera Cáceres - Gabriel Sepúlveda Jorquera - Camila Zamora Esquivel Fecha: 28 de Julio de 2014 Profesor: Agustín González

Más detalles

Verificación de usuario integrada Guía de implementación del Cliente 2015-05-04 Confidencial Versión 2.9

Verificación de usuario integrada Guía de implementación del Cliente 2015-05-04 Confidencial Versión 2.9 Verificación de usuario integrada Guía de implementación del Cliente 2015-05-04 Confidencial Versión 2.9 TABLA DE CONTENIDOS Introducción... 2 Propósito y destinatarios... 2 Sobre Este Documento... 2 Términos

Más detalles

Auditoría de un PC con el pograma Aida32(ahora se llama EVEREST)

Auditoría de un PC con el pograma Aida32(ahora se llama EVEREST) Auditoría de un PC con el pograma Aida32(ahora se llama EVEREST) Cuando hablamos de auditoría lo primero que nos viene a la cabeza es una pregunta: por qué necesito auditar un ordenador? Son varios los

Más detalles

Seguridad en UDCWIFI

Seguridad en UDCWIFI Seguridad en UDCWIFI Índice Introducción Seguridad en redes inalámbricas WIFI WEP, WPA Y 802,11i: Descripción, Debilidades y Ataques Caso concreto: UDCWIFI Introducción Hablar de seguridad en redes inalámbricas,

Más detalles

El contenido de este fichero está publicado bajo una licencia Creative Commons. Reconocimiento-NoComercial-SinObraDerivada 2.

El contenido de este fichero está publicado bajo una licencia Creative Commons. Reconocimiento-NoComercial-SinObraDerivada 2. El contenido de este fichero está publicado bajo una licencia Creative Commons. La licencia bajo la que se encuentra este fichero es: Reconocimiento-NoComercial-SinObraDerivada 2.1 España Puede ver el

Más detalles

Seguridad en sistemas distribuidos

Seguridad en sistemas distribuidos Seguridad en sistemas distribuidos 1. Introducción 2. Amenazas y ataques 3. Políticas de seguridad 4. Mecanismos de seguridad 5. Ejemplo de servicio de seguridad: Kerberos Bibliografía: [OU05] ap. 7 [TAN02]

Más detalles