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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Seguridad en Internet

Seguridad en Internet Seguridad en Internet. Resumen Cuando se realizan pagos en Internet y acceso a sitios Web que requieren certificado, intervienen dos protocolos seguros SSL y SET, ofreciendo confidencialidad, identificación,

Más detalles

1. Qué tipo de información personal reúne Nestlé a través de este sitio en Internet y cómo lo recaba? ( gris bold)

1. Qué tipo de información personal reúne Nestlé a través de este sitio en Internet y cómo lo recaba? ( gris bold) TÉRMINOS DE USO PREGUNTAS Y RESPUESTAS CLAVES Gracias por visitar este sitio en Internet. Esperamos que aprenda más sobre Nestlé y nuestros productos. Nestlé respeta su derecho a la privacidad en el mundo

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

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

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

Criptografía, certificado digital y firma digital. Guía básica de supervivencia. En Internet nadie sabe quién está al otro lado

Criptografía, certificado digital y firma digital. Guía básica de supervivencia. En Internet nadie sabe quién está al otro lado Criptografía, certificado digital y firma digital. Guía básica de supervivencia (adaptación de información extraída de http://www.cert.fnmt.es/popup.php?o=faq) En Internet nadie sabe quién está al otro

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

GRACIAS POR VISITAR ESTE SITIO DE INTERNET.

GRACIAS POR VISITAR ESTE SITIO DE INTERNET. GRACIAS POR VISITAR ESTE SITIO DE INTERNET. Esperamos que aprenda más sobre nuestra marca PRO PLAN y nuestros productos. NESTLÉ PURINA PET CARE DE COLOMBIA S.A. (en adelante NPPC) respeta su derecho a

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

TELEPROCESOS Y SISTEMAS DISTRIBUIDOS

TELEPROCESOS Y SISTEMAS DISTRIBUIDOS TELEPROCESOS Y SISTEMAS DISTRIBUIDOS Semana 11 Integrantes: Cantera Salazar, Julissa A. Yalico Tello, Diana Accho Flores, Wilber En una red Trabajo en Grupo se puede compartir, o hacer disponibles a través

Más detalles

Instituto Tecnológico de Costa Rica Escuela de Ingeniería Electrónica. Programa de Técnico en Mantenimiento de Computadoras. Red Adhoc.

Instituto Tecnológico de Costa Rica Escuela de Ingeniería Electrónica. Programa de Técnico en Mantenimiento de Computadoras. Red Adhoc. Instituto Tecnológico de Costa Rica Escuela de Ingeniería Electrónica. Programa de Técnico en Mantenimiento de Computadoras Red Adhoc. Ver 02_10 Ad hoc es una locución latina que significa literalmente

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

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

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

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción Dato: Hecho o valor a partir del cual se puede inferir una conclusión.

Más detalles

Martus Móvil para Android. Versión 1.2

Martus Móvil para Android. Versión 1.2 Martus Móvil para Android Versión 1.2 Índice Introducción a Martus Móvil... 3 Funcionalidad de Martus Móvil... 3 Crear boletines... 3 Enviar archivo desde otras aplicaciones... 3 Instalación... 4 Requisitos

Más detalles

UPC-DAC/FIB-PTI 1. Seguridad en HTTP

UPC-DAC/FIB-PTI 1. Seguridad en HTTP UPC-DAC/FIB-PTI 1 Introducción Seguridad en HTTP Esta práctica nos introduce en los dos puntos importantes sobre seguridad en HTTP: la autentificación y el transporte seguro de datos. Para el transporte

Más detalles

ASIR. Virtual Private Network

ASIR. Virtual Private Network ASIR Virtual Private Network Introducción: Descripción del problema La red de ASIR se trata de una red local que ofrece unos servicios determinados a los distintos usuarios, alumnos y profesores. Al tratarse

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

INDICE. Entel PCS Email Móvil

INDICE. Entel PCS Email Móvil Manual Email Móvil INDICE 1. DESCRIPCIÓN DEL SERVICIO...3 1.1 EQUIPOS COMPATIBLE....3 1.2 REQUERIMIENTOS BÁSICOS...3 2. CONTRATACIÓN...4 2.1 SELECCIÓN DE EQUIPO...4 2.2 SELECCIONA TU PLAN (SOLO SI NO HAS

Más detalles

Servicio de Acceso Remoto. Usos y configuración.

Servicio de Acceso Remoto. Usos y configuración. Servicio de Acceso Remoto. Usos y configuración. Servicio de Acceso Remoto. Usos y configuración... 1 DESCRIPCIÓN DEL SERVICIO DE ACCESO REMOTO... 3 GESTIÓN DE LA CUENTA DE ACCESO REMOTO... 3 CONFIGURACION

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

Hoy vamos a hablar sobre como instalar y configurar un servidor de DNS en un Microsoft Windows Server 2008 R2.

Hoy vamos a hablar sobre como instalar y configurar un servidor de DNS en un Microsoft Windows Server 2008 R2. El Servicio DNS Hoy vamos a hablar sobre como instalar y configurar un servidor de DNS en un Microsoft Windows Server 2008 R2. Quizá, lo primero que haya que hacer es recordar que es un DNS. Un Domain

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

Como sabemos, en un Sistema de Comunicación de Datos, es de vital importancia

Como sabemos, en un Sistema de Comunicación de Datos, es de vital importancia Encriptación de Datos Como sabemos, en un Sistema de Comunicación de Datos, es de vital importancia asegurar que la Información viaje segura, manteniendo su autenticidad, integridad, confidencialidad y

Más detalles

PROCEDIMIENTO DE INSTALACIÓN EN RED

PROCEDIMIENTO DE INSTALACIÓN EN RED PROCEDIMIENTO DE INSTALACIÓN EN RED VERSIÓN 2010 1. Componentes del Sistema KidsPC El Sistema KidsPC típico instalado en una red local consta de tres elementos principales: El Servidor KidsPC, la Estación

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

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

Compartir impresoras, instaladas tanto en el servidor como en los clientes. Ayudar a los clientes, con visualizador de Clientes de Red.

Compartir impresoras, instaladas tanto en el servidor como en los clientes. Ayudar a los clientes, con visualizador de Clientes de Red. Qué es Samba? Samba es una suite de aplicaciones Unix que habla el protocolo SMB (Server Message Block). Muchos sistemas operativos, incluídos Windows y OS/2, usan SMB para operaciones de red cliente-servidor.

Más detalles

PROBLEMAS CON SU CLAVE? Cliente Nuevo Puedo solicitar acceso a la Banca en Línea (Contrato Uso de Canales de Autoatención) a través del Portal?

PROBLEMAS CON SU CLAVE? Cliente Nuevo Puedo solicitar acceso a la Banca en Línea (Contrato Uso de Canales de Autoatención) a través del Portal? Persona Jurídica o Empresa PROBLEMAS CON SU CLAVE? Cliente Nuevo Puedo solicitar acceso a la Banca en Línea (Contrato Uso de Canales de Autoatención) a través del Portal? Puede obtener toda la información

Más detalles

Servicios remotos de Xerox Un paso en la dirección correcta

Servicios remotos de Xerox Un paso en la dirección correcta Servicios remotos de Xerox Un paso en la dirección correcta Diagnostica problemas Evalúa datos de la máquina Solución de problemas Seguridad de cliente garantizada 701P42953 Acerca de los Servicios remotos

Más detalles

MANUAL DE REGISTRO Y ACREDITACIÓN

MANUAL DE REGISTRO Y ACREDITACIÓN Recaudación Electrónica Versión 5.2 MANUAL DE REGISTRO Y ACREDITACIÓN Versión 5.2 Recaudación Electrónica Versión 5.2 2 ÍNDICE ÍNDICE... 2 CERTIFICACIÓN... 4 Sitio Web Recaudación Electrónica... 6 Home...

Más detalles

INTRODUCCION. Tema: Protocolo de la Capa de aplicación. FTP HTTP. Autor: Julio Cesar Morejon Rios

INTRODUCCION. Tema: Protocolo de la Capa de aplicación. FTP HTTP. Autor: Julio Cesar Morejon Rios INTRODUCCION Tema: Protocolo de la Capa de aplicación. FTP HTTP Autor: Julio Cesar Morejon Rios Qué es FTP? FTP (File Transfer Protocol) es un protocolo de transferencia de archivos entre sistemas conectados

Más detalles

CC es la abreviación de Cyber Café. Es así como nos referimos al programa en este documento.

CC es la abreviación de Cyber Café. Es así como nos referimos al programa en este documento. Preguntas Frecuentes Generales?? Qué significa CC? CC es la abreviación de Cyber Café. Es así como nos referimos al programa en este documento.?? Cuáles son los requerimientos mínimos de hardware para

Más detalles

Unidad 1: Conceptos generales de Sistemas Operativos.

Unidad 1: Conceptos generales de Sistemas Operativos. Unidad 1: Conceptos generales de Sistemas Operativos. Tema 3: Estructura del sistema operativo. 3.1 Componentes del sistema. 3.2 Servicios del sistema operativo. 3.3 Llamadas al sistema. 3.4 Programas

Más detalles

Capítulo 1: Marco teórico

Capítulo 1: Marco teórico Capítulo 1: Marco teórico Área de Soporte Técnico Dentro de Oracle, como en cualquier compañía de software existe el área de Soporte Técnico, cuyo objetivo principal es el de brindar asistencia y proveer

Más detalles

PROCEDIMIENTO ESPECÍFICO. Código G022-02 Edición 0

PROCEDIMIENTO ESPECÍFICO. Código G022-02 Edición 0 Índice 1. TABLA RESUMEN... 2 2. OBJETO... 2 3. ALCANCE... 2 4. RESPONSABILIDADES... 3 5. ENTRADAS... 3 6. SALIDAS... 3 7. PROCESOS RELACIONADOS... 3 8. DIAGRAMA DE FLUJO... 4 9. DESARROLLO... 5 9.1. COMPONENTES

Más detalles

Componentes de Integración entre Plataformas Información Detallada

Componentes de Integración entre Plataformas Información Detallada Componentes de Integración entre Plataformas Información Detallada Active Directory Integration Integración con el Directorio Activo Active Directory es el servicio de directorio para Windows 2000 Server.

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

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

Lineamientos para Terceros Aceptantes Especificaciones Técnicas Versión 1.1

Lineamientos para Terceros Aceptantes Especificaciones Técnicas Versión 1.1 Lineamientos para Terceros Aceptantes Especificaciones Técnicas Versión 1.1 Unidad de Certificación Electrónica Infraestructura Nacional de Certificación Electrónica República Oriental del Uruguay Lineamientos

Más detalles

JUEGOS EN FAMILIA PRIMARIA (6-12 AÑOS) GESTIÓN DE PRIVACIDAD E IDENTIDAD DIGITAL

JUEGOS EN FAMILIA PRIMARIA (6-12 AÑOS) GESTIÓN DE PRIVACIDAD E IDENTIDAD DIGITAL Capacitación en materia de seguridad TIC para padres, madres, tutores y educadores de menores de edad [Red.es] JUEGOS EN FAMILIA PRIMARIA (6-12 AÑOS) GESTIÓN DE PRIVACIDAD E IDENTIDAD DIGITAL 1 La presente

Más detalles

Servidor de claves públicas PGP, Cliente Administrador y Cliente para ciframiento y desciframiento de Correo Electrónico.

Servidor de claves públicas PGP, Cliente Administrador y Cliente para ciframiento y desciframiento de Correo Electrónico. TITULO Servidor de claves públicas PGP, Cliente Administrador y Cliente para ciframiento y desciframiento de Correo Electrónico. AUTORES F. Fabián Redrován Castillo 1, Luis M. Ruiz Ampuero 2, Carmen K.

Más detalles

Información de seguridad en Línea

Información de seguridad en Línea Información de seguridad en Línea Qué es el phishing? El phishing es el nombre dado a la práctica de enviar correos electrónicos al azar que supuestamente afirman ser de una empresa autentica que opera

Más detalles

Software de Comunicaciones. Práctica 7 - Secure Shell. SSH

Software de Comunicaciones. Práctica 7 - Secure Shell. SSH Software de Comunicaciones Práctica 7 - Secure Shell. SSH Juan Díez-Yanguas Barber Software de Comunicaciones Ingeniería Informática - 5º Curso Jdyb - Mayo 2013 Juan Díez- Yanguas Barber Práctica 7 Índice

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

Tasa por Inspección de Higiene, Sanitaria, Profilaxis y Seguridad Aplicativo WEB - Manual de Usuario 1.4

Tasa por Inspección de Higiene, Sanitaria, Profilaxis y Seguridad Aplicativo WEB - Manual de Usuario 1.4 Tasa por Inspección de Higiene, Sanitaria, Profilaxis y Seguridad Aplicativo WEB - Manual de Usuario 1.4 1 de 28 INTRODUCCIÓN...3 CARACTERÍSTICAS GENERALES...3 REQUISITOS PREVIOS A LA INSTALACION...3 ORGANIZACIÓ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

Seguridad de la información: ARP Spoofing

Seguridad de la información: ARP Spoofing ELO322 Redes de Computadores I Seguridad de la información: ARP Spoofing Nombres: Mauricio Muñoz Stephanie Salazar Paola Yang 1 Resumen El protocolo encargado de enviar cada paquete a su destino es el

Más detalles

Fundamentos CAPÍTULO 1. Contenido

Fundamentos CAPÍTULO 1. Contenido CAPÍTULO 1 Fundamentos En este capítulo encontrará instrucciones rápidas y sencillas que le permitirán poner manos a la obra de inmediato. Aprenderá también a utilizar la ayuda en pantalla, que le será

Más detalles

Resumen de Requisitos Técnicos para incorporación de Organismos a la Plataforma Integrada de Servicios Electrónicos del Estado

Resumen de Requisitos Técnicos para incorporación de Organismos a la Plataforma Integrada de Servicios Electrónicos del Estado Resumen de Requisitos Técnicos para incorporación de Organismos a la Plataforma Integrada de Servicios Electrónicos del Estado Ministerio Secretaría General de la Presidencia Unidad de Modernización y

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

Módulo I - Excel. Conociendo la aplicación de Excel... 2. Abriendo una planilla de Excel... 2. Entendiendo el concepto de Libro, hoja y celda...

Módulo I - Excel. Conociendo la aplicación de Excel... 2. Abriendo una planilla de Excel... 2. Entendiendo el concepto de Libro, hoja y celda... Módulo I - Excel Índice Conociendo la aplicación de Excel... 2 Abriendo una planilla de Excel... 2 Entendiendo el concepto de Libro, hoja y celda... 3 Creando el primer libro... 4 Saliendo de Excel...

Más detalles

Política de Privacidad Internet. 3M Chile. Política Global sobre privacidad en internet

Política de Privacidad Internet. 3M Chile. Política Global sobre privacidad en internet Política de Privacidad Internet 3M Chile Política Global sobre privacidad en internet 3M respeta su derecho a la privacidad. Esta política resume la información de identificación personal que podemos obtener

Más detalles

Seguridad de la información

Seguridad de la información Seguridad de la información Se entiende por seguridad de la información a todas aquellas medidas preventivas y reactivas del hombre, de las organizaciones y de los sistemas tecnológicos que permitan resguardar

Más detalles

Arquitectura de seguridad OSI (ISO 7498-2)

Arquitectura de seguridad OSI (ISO 7498-2) Universidad Nacional Autónoma de México Facultad de Ingeniería Criptografía Grupo 2 Arquitectura de seguridad OSI (ISO 7498-2) ALUMNOS: ARGUETA CORTES JAIRO I. MENDOZA GAYTAN JOSE T. ELIZABETH RUBIO MEJÍA

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

3 POLÍTICAS DE SEGURIDAD

3 POLÍTICAS DE SEGURIDAD 3 POLÍTICAS DE SEGURIDAD 3.1 PROPÓSITO Las Políticas de Seguridad son documentos de alto nivel. Representan la filosofía y el talante del ASJ, en materia de seguridad. Es necesario, además, que las Políticas

Más detalles

INTERNET - INTRANET - EXTRANET

INTERNET - INTRANET - EXTRANET INTERNET - INTRANET - EXTRANET Definiciones Internet es "una red de computación de alcance mundial constituida a su vez por miles de redes de computación que conectan entre sí millones de computadoras,

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

Compartir Biblio en una red local con Windows XP

Compartir Biblio en una red local con Windows XP Compartir Biblio en una red local con Windows XP Caso práctico Supongamos que tenemos 2 tipos de personas que van a necesitar acceder remotamente (a través de otro ordenador de la red local) a la base

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

Capítulo 4 Análisis y Resultados

Capítulo 4 Análisis y Resultados 58 Capítulo 4 Análisis y Resultados Al terminar la aplicación desarrollada con Django se han cumplido los objetivos planteados al principio de la propuesta. Los objetivos fueron planteados para cumplir

Más detalles

Operación Microsoft Windows

Operación Microsoft Windows Entornos de red Concepto de red En el nivel más elemental, una red consiste en dos equipos conectados entre sí mediante un cable de forma tal que puedan compartir datos. Todas las redes, no importa lo

Más detalles

Como Suceden los Fraudes

Como Suceden los Fraudes Como Suceden los Fraudes Fraudes en Internet El FPB preparó para usted una guía de orientación para ayudarle en la prevención de fraudes electrónicos. Evite problemas, quede por fuera de la acción de los

Más detalles

- Telnet, Rlogin, SSH - X-Terminal - Escritorio remoto VNC - Terminal Server - Acceso remoto mediante interfaz web

- Telnet, Rlogin, SSH - X-Terminal - Escritorio remoto VNC - Terminal Server - Acceso remoto mediante interfaz web - Telnet, Rlogin, SSH - X-Terminal - Escritorio remoto VNC - Terminal Server - Acceso remoto mediante interfaz web Los Servicios de Escritorio Remoto (del inglés Remote Desktop Services), antiguamente

Más detalles

Módulo III - PowerPoint

Módulo III - PowerPoint Módulo III - PowerPoint Índice Insertando imágenes prediseñadas... 2 Moviendo imágenes insertadas... 3 Copiando y duplicando imágenes insertadas... 4 Eliminando imágenes insertadas... 5 Definiendo una

Más detalles

PROCEDIMIENTO PARA EL ALTA, REHABILITACION, DESBLOQUEO Y BAJA DE USUARIOS UEPEX DE LA DGSIAF- SECRETARÍA DE HACIENDA

PROCEDIMIENTO PARA EL ALTA, REHABILITACION, DESBLOQUEO Y BAJA DE USUARIOS UEPEX DE LA DGSIAF- SECRETARÍA DE HACIENDA DE USUARIOS UEPEX DE LA - 1. Introducción 2 2. Alcance 2 3. Requerimientos 2 4. Procedimiento 3 4.1. Solicitud alta, rehabilitación, desbloqueo y/o baja de usuario 3 4.1.1. Alta de usuario 3 4.1.2. Baja

Más detalles

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS

ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Base de Datos ELEMENTO I INTRODUCCION A LOS SISTEMAS DE BASES DE DATOS Una base de datos es un conjunto de elementos de datos que se describe a sí mismo, con relaciones entre esos elementos, que presenta

Más detalles

MANUAL PARA EL USO DE WIX

MANUAL PARA EL USO DE WIX MANUAL PARA EL USO DE WIX CREA TU PROPIO SITIO WEB CON FACILIDAD ALEX PENSO ROMERO Qué es Wix y de que nos sirve? Wix es un editor online que permite crear y publicar un sitio web en flash indexado en

Más detalles

Creación y administración de grupos de dominio

Creación y administración de grupos de dominio Creación y administración de grupos de dominio Contenido Descripción general 1 a los grupos de Windows 2000 2 Tipos y ámbitos de los grupos 5 Grupos integrados y predefinidos en un dominio 7 Estrategia

Más detalles

Reducir los riesgos conectados a un posible registro o robo en la oficina

Reducir los riesgos conectados a un posible registro o robo en la oficina CAPÍTULO 3.1 Reducir los riesgos cómo conectados a un posible registro o robo en la oficina Un registro se describe perfectamente como la entrada forzada a una casa, oficina o espacio privado. Es legal

Más detalles

SEGURIDAD Y PROTECCION DE FICHEROS

SEGURIDAD Y PROTECCION DE FICHEROS SEGURIDAD Y PROTECCION DE FICHEROS INTEGRIDAD DEL SISTEMA DE ARCHIVOS ATAQUES AL SISTEMA PRINCIPIOS DE DISEÑO DE SISTEMAS SEGUROS IDENTIFICACIÓN DE USUARIOS MECANISMOS DE PROTECCIÓN Y CONTROL INTEGRIDAD

Más detalles

Instituto Tecnológico y de Estudios Superiores de Monterrey Práctica de Laboratorio 4 Implementación de un NAPT

Instituto Tecnológico y de Estudios Superiores de Monterrey Práctica de Laboratorio 4 Implementación de un NAPT Instituto Tecnológico y de Estudios Superiores de Monterrey Práctica de Laboratorio 4 Implementación de un NAPT Marco teórico: La red más grande del mundo, Internet, ha tenido un gran crecimiento en la

Más detalles

TARJETA PROFESIONAL ELECTRÓNICA. FAQs

TARJETA PROFESIONAL ELECTRÓNICA. FAQs TARJETA PROFESIONAL ELECTRÓNICA FAQs 1. UTILIDAD DE LA TPE... 4 1.1. Para qué sirve la tarjeta?... 4 1.2. Qué operaciones puedo realizar con la tarjeta?... 4 2. TRAMITACIÓN DE TPE... 4 2.1. Qué debo hacer

Más detalles

Gestión de cuentas de correo Gestión de cuentas de correo

Gestión de cuentas de correo Gestión de cuentas de correo Gestión de cuentas de correo Introducción...2 Entrando en la aplicación...3 Autenticación...3 Cuentas de e-mail...5 Crear una cuenta de correo electrónico...7 Modificar usuario....9 Borrar usuario...10

Más detalles

TEMA: PROTOCOLOS TCP/IP

TEMA: PROTOCOLOS TCP/IP TEMA: PROTOCOLOS TCP/IP HISTORIA: El Protocolo de Internet (IP) y el Protocolo de Transmisión (TCP), fueron desarrollados inicialmente en 1973 por el informático estadounidense Vinton Cerf como parte de

Más detalles

INSTITUTO NACIONAL DE SEGUROS DIRECCIÓN DE INFORMÁTICA. Manual de Usuario de SeVins Módulo INSonline. Versión: #1

INSTITUTO NACIONAL DE SEGUROS DIRECCIÓN DE INFORMÁTICA. Manual de Usuario de SeVins Módulo INSonline. Versión: #1 INSTITUTO NACIONAL DE SEGUROS DIRECCIÓN DE INFORMÁTICA Manual de Usuario de SeVins Módulo INSonline Versión: #1 Fecha actualización anterior: Fecha última actualización: Página: 2 de 70 Tabla de contenidos

Más detalles

Transport Layer Security (TLS) Acerca de TLS

Transport Layer Security (TLS) Acerca de TLS Transport Layer Security (TLS) Acerca de TLS Contenido Correo electrónico seguro en HSBC... 2 Acerca de Transport Layer Security..... 2 Para establecer una conexión Forced TLS con HSBC... 4 Glosario...

Más detalles

Guía de inicio rápido

Guía de inicio rápido Guía de inicio rápido Tabla de contenido 1. INSTALACIÓN DE ARGUS 2007 - - - - - - - - - - - - - - - - - - - - - - 2. CÓMO INSTALAR ARGUS EN UNA SOLA COMPUTADORA - - - 3. CÓMO INSTALAR ARGUS EN UNA RED

Más detalles

QUÉ ES BAJO LLAVE? POR QUÉ SER CLIENTE DE BAJO LLAVE?

QUÉ ES BAJO LLAVE? POR QUÉ SER CLIENTE DE BAJO LLAVE? QUÉ ES BAJO LLAVE? Bajo Llave es una caja de seguridad electrónica, una aplicación de alta seguridad que usa cifrado de datos y que permite almacenar información personal y profesional, perfectamente clasificada

Más detalles

INTRODUCCIÓN... 3 CONCEPTOS PREVIOS... 3 COMUNICACIÓN SEGURA: PROTOCOLO SSL... 4

INTRODUCCIÓN... 3 CONCEPTOS PREVIOS... 3 COMUNICACIÓN SEGURA: PROTOCOLO SSL... 4 !"!### $%!"!###& V1.Febrero 2015 Contenido INTRODUCCIÓN... 3 CONCEPTOS PREVIOS... 3 COMUNICACIÓN SEGURA: PROTOCOLO SSL... 4! " # ### '()*+*),+ +-.###################################################################&

Más detalles

MANUAL DE ADMINISTRACION

MANUAL DE ADMINISTRACION MANUAL DE ADMINISTRACION Cúcuta: Centro Comercial Bolívar Local B-21 y B-23 Tels.: (7) 5829010 Versión 2012. Fecha de Revisión, Enero 26 de 2012. Registro de Derechos de Autor Libro-Tomo-Partida 13-16-245

Más detalles

Guía nuevo panel de clientes acens

Guía nuevo panel de clientes acens Guía nuevo panel de clientes acens Calle San Rafael, 14 28108 Alcobendas (Madrid) 900 103 293 www.acens.com 1. Estructura del panel de administración El panel de control presenta un diseño renovado y algunas

Más detalles

LA SEGURIDAD EN LAS NUEVAS APLICACIONES DE GESTIÓN DE CENTROS: USUARIOS Y COPIAS DE SEGURIDAD.

LA SEGURIDAD EN LAS NUEVAS APLICACIONES DE GESTIÓN DE CENTROS: USUARIOS Y COPIAS DE SEGURIDAD. 1 LA SEGURIDAD EN LAS NUEVAS APLICACIONES DE GESTIÓN DE CENTROS: USUARIOS Y COPIAS DE SEGURIDAD. Introducción Trata este manual sobre dos aspectos relacionados directamente con la seguridad en el uso de

Más detalles

MANUAL PARA GESTIÓN DE INCIDENCIAS INFORMÁTICAS

MANUAL PARA GESTIÓN DE INCIDENCIAS INFORMÁTICAS MANUAL PARA GESTIÓN DE INCIDENCIAS INFORMÁTICAS En este manual aprenderemos a introducir un Ticket de Soporte (Incidencia Informática) y ver todo el proceso hasta que se resuelve. Para poder escribir Tickets

Más detalles