Gestión de acceso remoto a una Intranet través de web. Omar Walid Llorente omar@dit.upm.es. dit UPM

Transcripción

1 Gestión de acceso remoto a una Intranet través de web Omar Walid Llorente omar@.upm.es

2 Objetivos Acceso virtual: remoto seguro controlado registrado compartido universal idéntico

3 Objetivos (+) Acceso virtual, además: múltiple temporalmente limitado autenticado en Unix gráfico razonable en: coste tiempo ancho de banda

4 Medios de Acceso Directos: Módem privado personal: Módem público xdsl [...] Indirectos: Directos + VPN Wi-Fi + n*vpn

5 Implicaciones VPNs => Autenticación de usuario no Unix VPNs => Requerimientos fuertes en cliente VPNs => Rendimiento pobre en clientes módem n*vpn => Ineficiencias GRAVES por cabeceras Módems => Necesita BW configurable Módems => IPs dinámicas xdsl => IPs dinámicas [...] => Desconocidas, BW variable,

6 Necesidades generales No requerimientos fuertes en cliente BW configurable: mayor si mejor resolución No basado en IP, sino en usuario Universalizar el acceso: navegadores web + java Coste Bajo => Código Abierto o Libre Control temporal de los accesos (expiración) Gestión automática y, a ser posible, sencilla SW estable, probado y conocido

7 Necesidades de seguridad Seguridad en el almacenamiento de datos Frente a destrucción => BACKUPs Frente a intrusos => Firewalls Seguridad en la transmisión de los datos Integridad => Encriptación (túnel o SSL) Privacidad => Autenticación + Encriptación No repudio : no se considera necesario

8 Solución adoptada Basada en VNC, más: Túneles SSH Control de acceso: 1. Apertura sesión 2. Cierre sesión Autoconfig. recursos Transferencia ficheros Control de tiempos

9 Túneles SSH Configuración de SSH como túnel y redirección de puertos Puerto 5934 Xvnc SSH Puerto 22 Puerto >1024 SSH vnc Puerto 5934 Estación de trabajo Máquina cliente

10 Control de Acceso Interfaz Web, basado en formularios Seguridad basada en HTTPS Gestión de sesiones a través de CGIs Distribución de información a través de web Centralización débil del sistema: Base de datos de sesiones: centralizada Control del sistema: descentralizado Tecnología PULL (el servidor facilita la información bajo demanda al resto del sistema)

11 Autoconfiguración Configuración descentralizada de los servicios: si la estación de trabajo funciona, se configura de forma autónoma, sino, no afecta al gestor de sesiones Si el servicio falla, el alumno puede cerrar la sesión y crear una nueva (sin depender del estado de la estación de trabajo) Se evita el problema de las conexiones de control en TCP (timeouts, interbloqueos, etc). El usuario tiene que esperar

12 Otros detalles Transferencia de ficheros: A través de SCP Posibilidad de interfaz gráfico (applet o aplicación) Control temporal de sesiones (expiración): Importancia: aumenta la seguridad del servicio Se realiza de forma centralizada Diferentes duraciones: 2, 4, 6 u 8 horas

13 Esquema de la solución Servidor Web Router Estaciones de Trabajo Firewall automático

14 Gestión de sesiones Servidor Web 1º) Petición de sesión Router Estaciones de Trabajo Firewall automático

15 Gestión de sesiones Servidor Web Estaciones de Trabajo Firewall automático 2º) Establecimiento Router de sesión

16 Distribución de información Servidor Web 3º) Peticiones de sesiones establecidas Router Estaciones de Trabajo Firewall automático

17 Distribución de información Servidor Web 4º) TX sesiones establecidas Router Estaciones de Trabajo Firewall automático

18 Configuración automática Servidor 5a) Conf. Web Xvnc sesiones establecidas Router Estaciones de Trabajo Firewall 5b) automático Conf. filtro de sesiones establecidas

19 Establecimiento del servicio Servidor 6º) Config. Web túnel SSH -VNC Router Estaciones de Trabajo Firewall automático

20 Establecimiento del servicio 7º) Establecimiento servicio VNC sobre SSH Servidor Web Router Estaciones de Trabajo Firewall automático

21 Acceso Gestión de acceso: HTTPS (seguridad) A Navegador Web (+ Javascript) A Usuario + Clave Gestión del servicio: túnel SSH para aplicación (ssh tunnel) transferencia de ficheros (scp, sftp) Cliente VNC => escritorio remoto y gráfico (a) todo-web (navegador + java + applets) (b) basado en aplicaciones (SSH + SCP + VNC)

22 Interfaz

23 Interfaz (+)

24 Servicio todo-web A navegador con: A 0. (+ Javascript) 1. SSL 2. Máquina virtual java 3. Applets java: VNC sobre SSH SSH + SCP

25 Servicio todo-web (+)

26 Servicio todo-web (++) Ventajas: Sólo un punto de acceso al servicio: navegador Acceso prácticamente universal Inconvenientes: Es más lento que el sistema no basado en java Puede tener peor seguridad o resolución gráfica dependiendo de los applets java utilizados Se necesitarían certificados para autenticar los applets y añadir seguridad al sistema Los applets pueden ser caros o muy pesados

27 Servicio basado en aplicaciones Misma funcionalidad que en servicio todo-web Aplicaciones diferentes para cada S.O. Aplicaciones diferentes para transferencia de ficheros y para visión del VNC Disponibilidad de aplicaciones muy variadas Mayor agilidad de servicio (se evita java) Mejor rendimiento (no hay que descargarse la aplicación a ejecutar cada vez que se accede)

28 Servicio basado en aplicaciones (+) Aplicación gráfica de copia de ficheros con SCP

29 Servicio basado en aplicaciones (+) Aplicación gráfica cliente para VNC (vncviewer) Gestión gráfica del túnel SSH (putty)

30 Ventajas del sistema desarrollado Gestión de sesiones: control temporal autenticación Unix interfaz gráfica idéntica independencia del S.O. Gestión de usuarios: mismas claves idéntico entorno de acceso y trabajo Gestión segura de archivos y conexiones

31 Futuras mejoras Generación de estadísticas (para controlar mejor el número de accesos fallidos y permitidos y detectar ataques) Muestra del estado del sistema (indicar a los usuarios cuántas y de quién son las sesiones establecidas en un momento dado) Distribución de automática de carga (indicar al usuario cuál estación es la menos cargada) Single-Sign-On?!? (gestionar una única autenticación para todos los sistemas)