1 Aspectos de Seguridad y Desempeño en Sistemas Distribuidos Emilio Hernández Universidad Simón Bolívar

2 Aspectos de Seguridad y Desempeño en Sistemas Distribuidos Parte I: Breve introducción a seguridad en redes y en sistemas distribuidos basados en Corba Parte II: Introducción a algunos problemas que limitan el modelo y el alcance de la conectividad en Internet Parte III: Cómo afectan estos problemas la implementación y el desempeño de sistemas distribuidos, especialmente en Corba

3 Parte I: Breve introducción a seguridad en redes y en sistemas distribuidos basados en Corba

4 Aspectos de seguridad " Ha habido mucho énfasis en aspectos de seguridad para información que circula en Internet, especialmente las transacciones comerciales. " Los aspectos principales considerados en seguridad son: " Confidencialidad " Integridad " Auditabilidad (importante para “non-repudiation”) " Disponibilidad " En sistemas distribuidos esta perspectiva es muy importante, por ejemplo en Corba se ha definido CORBAsec (Corba Security Service)

5 CORBAsec: algunos principios  Al igual que todas las especificaciones de la OMG, la de CORBAsec es larga y tediosa " Un agente usuario de Corba (en nomenclatura CORBAsec un principal) debe " Para esto presenta sus credenciales, es decir, sus atributos de seguridad " Identificación " Privilegios " Se maneja el concepto de dominios de seguridad y de políticas de seguridad

6 Modelo de seguridad de CORBAsec Servicio de seguridad Petición Cliente Objeto Corba Código de implemen- tación de seguridad IdentificaciónPrivilegios Credencial Contexto de seguridad Políticas de seguridad Dominio de seguridad

7 Otros aspectos de CORBAsec " Otros aspectos inherentes a seguridad en sistemas distribuidos: " Seguridad al nivel de granularidad de los objetos " Delegación " Definición de dominios de seguridad que no corresponden con dominios de administración de sistemas (jerarquías, federaciones) " Interoperabilidad con otros sistemas de objetos (DCOM, EJB) " Si las aplicaciones incluyen acciones relacionadas con seguridad o no.

8 Modelo de capas de seguridad " Uno de los modelos que se maneja, especialmen- te en las propuestas relacionadas con objetos dis- tribuidos, es el modelo de capas (tiers) Bases de datosRed internaInternet Firewall Capa 3 Capa 2Capa 1

9 Seguridad a todo nivel " Las propuestas de la OMG para proveer seguridad en Corba se centran en definir mecanismos para el acceso seguro a objetos " La necesidad de proteger todo tipo de información (no sólo la que se provee por medio del modelo de objetos distribuidos) hace necesario pensar en protecciones más generales " Estos mecanismos de protección general afectan la implantación y el desempeño de sistemas distribuidos

10 Aspectos de seguridad y expansión en redes (agenda) " Seguridad en redes " Breve resumen de riesgos " Políticas estándares de seguridad " Conexiones seguras y canalización (tunneling) " Una mirada a los proxies y firewalls " NAT (Network Address Translation) " En qué consiste " Qué limitaciones trae

11 Breve resumen de riesgos (perspectiva del administrador de sistemas) " Seguridad de datos " Integridad: " Que se borren los datos " Que se alteren " Privacidad " Que alguien no autorizado los vea " Acceso a sistemas de computación " Que no se pueda usar el sistema (denial of service) " Que no funcione del modo esperado " Que se use con propósitos no permitidos

12 Mecanismos estándares de seguridad " Respaldos (backups) " Sistema de cuentas con contraseña " Acceso limitado a datos y programas " Uso de niveles de registro (logging) detallados " Vigilia permanente en Internet sobre huecos de seguridad del software usado " Ejecución de programas que verifican la integridad del sistema

13 Mecanismos estándares de seguridad " Uso de firewalls y uso de proxies de servicios " Uso de envoltorios (wrappers) para servicios TCP/UDP " Uso de encriptamiento " Certificados digitales " Conexiones seguras (SSL, TSL) " Uso de sistemas de autenticación (ej. kerberos)

14 Políticas estándares de seguridad " Negar acceso por defecto " Usuarios: sólo acceden quienes tienen cuenta " Servicios: sólo se instalan los estrictamente necesarios " Firewalls: sólo dejan pasar conexiones a puertos establecidos " Proteger información de acceso " Archivo de contraseñas " Proteger cuenta de supuerusuario " Forzar el uso de ssh, sftp, scp.

15 Parte II: Introducción a algunos problemas que limitan el modelo y el alcance de la conectividad en Internet

16 Conexiones en Internet: Sockets " Socket: un par de pares ((IP_fuente,Puerto_fuente),(IP_destino,Puerto_destino)) " Ej.: socket de una conexión http ((159.90.10.150,1077), (200.21.83.137,80)) " Una conexión simultánea podría ser ((159.90.10.150,1078), (200.21.83.137,80)) " Los servidores esperan por conexiones en puertos bien conocidos (http=80, telnet=23, ssh=22,…) " El protocolo de conexión de un socket sobre TCP es de 3 mensajes (3-way handshake)

17 Conexiones seguras: SSL " Objetivo: encriptar el tráfico que pasa por un socket " Soporta cerca del 98% del tráfico de web seguro " Se establece sobre una conexión estándar de tipo socket. " La conexión se establece en dos fases " “Handshake”: autenticación e intercambio de claves " “Tunneling”: paso de información encriptada en ambas direcciones

18 SSL: Handshake - Dime quién eres - Estos son los protocolos que soporto Cliente Servidor - Aquí está mi certificado digital (CD) - Estos son los protocolos que he elegido - Te envío un identificador aleatorio - Con tu CD, ya se quién eres y además ya se tu clave pública - Aquí te envío una clave secreta encriptada con tu clave pública - Te envío un copia de lo que hemos acordado, encriptada con la clave secreta - Te envío una copia de lo que hemos acordado, encriptada con la clave secreta Intercambio de datos encriptados con SSL Hello Server-hello Client-master-key Server-verify Client-finished TCP 3-way handshake

19 SSL: intercambio de datos " Todos los mensajes deben encriptarse y desen- criptarse, con la clave maestra acordada en el handshake " El tipo de algoritmo usado para encriptar/desen- criptar emplea mucho tiempo de CPU " Existen coprocesadores que se dedican exclusivamente a esta labor

20 SSL: degradación de desempeño " La degradación de desempeño es muy alta

21 SSL: desempeño " Estudio del impacto de SSL en Corba (abril 2000) en http://cgi.omg.org/meetings/docsec/presentations/iep.htm " El estudio se hizo en una red LAN 100mbps " Conclusiones: " La degradación al usar SSL es significativa (más del doble de tiempo) " El impacto en desempeño es muy sensible a " El lenguaje de implementación: en Java es mucho más lento que en C++ " El método de encriptamiento usado (variantes de RSA)

22 TSL " TSL = Transport Security Layer " Es una evolución de SSL y de PCT (definido por Microsoft) " Incluye compresión de datos " Es similar a SSL 3.0 " Tiene un protocolo de “handshake” similar al de SSL, pero intercambia mas información

23 Protección contra accesos ilegales " Restricción de servicios de red (ejemplo, restricción a ssh, sftp, https) " Redes con IP´s privados " Firewalls " Envoltorios de servicios " Proxies de aplicaciones

24 Proxies & Firewalls Por diversas razones, el tráfico desde y hacia Internet, se hace pasar por un proceso de filtraje y modificación " Por seguridad " Por falta de direcciones IP " Para priorizar el tráfico

25  Enrutador con filtro (EF): enrutador (router) que provee filtrado de paquetes  Máquina con capacidad de enrutamiento (MCE): máquina con varias conexiones a la red, puede tener software de filtrado de paquetes  Bastión: servidor expuesto al ataque (típicamente desde “afuera”)  Firewall: solución integrada al problema de seguridad. Es una combinación de EF´s, MCE´s y bastiones. Proxies & Firewalls: definiciones básicas

26  Seleccionan los paquetes que cruzan desde Internet hacia la red interna y viceversa  Funcionan típicamente en los niveles de capa de red (IP) y transporte (TCP/UDP)  Los paquetes que no pueden cruzar son descartados  Pueden hacer ligeras modificaciones a los paquetes que las cruzan Filtros de red

27  Red interna con IP´s privados  Proxies  No transparentes  Transparentes  Enmascaramiento (NAT) de números IP  Red interna con IP´s públicos  Enrutadores con filtro (EF´s)  MCE´s con filtrado de paquetes Operaciones de Filtraje

28 10.0.0.1 10.0.0.510.0.0.710.0.0.410.0.0.310.0.0.210.0.0.6 159.90.10.3 150.188.1.7 10.0.0.5 10.0.0.1 (address.dom) 10.0.0.6 150.188.1.7 159.90.10.3 Proxies no transparentes

29 10.0.0.1 10.0.0.510.0.0.710.0.0.410.0.0.310.0.0.210.0.0.6 159.90.10.3 150.188.1.7 10.0.0.5 159.90.10.3 10.0.0.6 150.188.1.7 159.90.10.3 Proxies transparentes

30 10.0.0.1 10.0.0.510.0.0.710.0.0.410.0.0.310.0.0.210.0.0.6 159.90.10.3 150.188.1.7 10.0.0.5 159.90.10.3 10.0.0.6 150.188.1.7 159.90.10.3 Enmascaramiento (NAT)

31 150.1.1.1 150.1.1.5150.1.1.7150.1.1.4150.1.1.3150.1.1.210.0.0.6 159.90.10.3 150.188.1.147 150.1.1.5 159.90.10.3 10.0.0.6 150.1.1.5 159.90.10.3Firewalls

32 Filtrado de paquetes Policy-based routing

33 EF Filtrado con EF

34 MCE Filtrado con MCE

35  Ipchains ( ejemplos de uso del comando)  adentro="150.1.0.0/16"  afuera="159.90.0.0/16"  ipchains -P input ACCEPT  ipchains -P output ACCEPT  ipchains -P forward DENY  ipchains -A forward -p TCP -s $adentro 1024: -d $afuera 22 -j ACCEPT  ipchains -A forward -p TCP -s $afuera 22 -d $adentro 1024: -j ACCEPT  ipchains -A forward -p TCP -d $afuera 1024: -d $adentro 22 -j ACCEPT  ipchains -A forward -p TCP -s $adentro 22 -d $afuera 1024: -j ACCEPT Filtrado de paquetes en Linux: ipchains

36 (Esquema débil) MCE Uso de un bastión

37  Puede haber más de un bastión, si se desea repartir los servicios  No es buena idea que el bastión sea la misma MCE que realiza el filtrado, a menos que haya un filtrado interno adicional  Eliminar los servicios innecesarios dentro del bastión  Usar wrappers para los servicios, como barricada de seguridad adicional Sugerencias para uso de bastiones

38 (Esquema fuerte) Red protectora

39 (Esquema fuerte) Red protectora (II)

40 (Esquema débil) Red protectora (débil)

41 Envoltorios: TCP-wrappers " Intermediarios para acceso a servicios, por ejemplo, para el uso de ftp, la secuencia: cliente/usuario -> cliente FTP -> inetd host -> ftpd -> transferencia de archivos cambia por cliente/usuario -> cliente FTP -> tcpd -> ftpd -> transferencia de archivos " Estos envoltorios permiten: " monitorear y almacenar información con respecto a conexiones " negar el acceso según ciertos criterios (ej. por procedencia) " Los envoltorios se instalan típicamente en los bastiones

42 Proxies a nivel de aplicación " No requieren servicios especiales del sistema operativo " Ejemplo: SOCKS (RFC 1928) " Es un protocolo que permite utilizar un proxy para obtener acceso a máquinas, sin que se requiera acceder directamente a estas máquinas " Los procesos cliente deben estar adaptados al uso de un intermediario SOCKS, por ejemplo telnet para socks, ftp para socks, etc. " El proxy de SOCKS accede a servicios no modificados para llevar los resultados de las peticiones al cliente " SOCKS V5 trabaja con TCP y UDP

43 PARTE III: PARTE III: Cómo afectan estos problemas la implementación y el desempeño de sistemas distribuidos, especialmente en Corba

44 Implementación de un sistema distribuido en una LAN " Todas las máquinas son accesibles desde todas " Todos los puertos (superiores a 1024) son utilizables para iniciar servicios " Puede no ser necesario usar SSL, y en caso de ser necesario el retraso de conexión es corto " Podemos distribuir las bases de datos sin impactar mucho el desempeño (a menos que las aplicaciones iteren muchas veces con accesos en cada vuelta)

45 Implementación de un sistema distribuido en Internet " No todas las máquinas son accesibles " Los puertos utilizables para iniciar servicios especialmente si se definen estáticamente " Es necesario establecer conexiones seguras, digamos con SSL " En Internet puede tener gran impacto en desempeño la distribución de datos en muchos sitios

46 Particularidades de sistemas de objetos distribuidos " En un esquema cliente/servidor la conexión es iniciada siempre por el cliente, digamos, usando sockets directamente, RPC, RMI, etc. " En Corba, al ser un conjunto de objetos distribui- dos interoperando libremente, el cliente y el ser- vidor pueden intercambiar roles dinámicamente " Al momento de establecer cada conexión se debe localizar el objeto referenciado, resultando en operaciones de consulta a servidores de nombres

47 Implementación de llamadas CORBA " GIOP: General Inter ORB Protocol " Es orientado a conexión: se realizan intercambios de mensajes sobre una conexión establecida (no necesariamente TCP) " Funciona en general como un protocolo de pregunta-respuesta " Define el formato de mensajes para invocación, respuesta, localización de objetos y cierre de conexión " Se define un formato llamado CDR (Common Data Represen- tation) para codificar los datos de forma independiente de las plataformas. " CDR provee codificación para ciertos tipos básicos de datos, como enteros, reales, y datos estructurados, como arreglos

48 Implementación de llamadas CORBA: IIOP " IIOP: Internet Inter ORB Protocol " IIOP = GIOP (+ CDR) + TCP/IP " Se define una estructura de localización en Internet, llamada IOR (Internet Object Reference) " Los tipos de mensaje definidos en GIOP están mapeados en funciones que realizan el envío sobre TCP/IP, típicamente usando la interfaz de sockets " No se define un puerto “bien conocido” para el servidor, más bien se establece que puede haber varios servidores en el mismo “host” " IIOP puede ir codificado sobre SSL

49 Implementación de llamadas CORBA: IIOP bidireccional " Un ORB puede realizar conexiones TCP y dejarlas abiertas durante un tiempo para intercambio de varios mensajes GIOP " Una conexión TCP puede ser utilizada para intercambio de información en ambas direcciones, con ambos extremos funcionando a la vez como cliente y servidor. " Esta es una posible solución para permitir callbacks desde atrás de un firewall " Sin embargo, se abre la puerta a un potencial problema de seguridad, si no se autentifica la conexión de vuelta

50 IIOP seguro: SECIOP " Está especificado en CORBAsec " Define extensiones a IIOP que lo hacen “consciente” de aspectos de seguridad " El protocolo incluye aspectos de autentificación basado en credenciales, para establecer asociaciones " El tráfico se encripta en una subcapa del protocolo SECIOP llamada GSSAPI, por lo que no se requiere de SSL debajo

51 SECIOP vs. IIOP/SSL " IIOP/SSL tiene un mayor nivel de difusión, debido a que SSL es una tecnología madura " SECIOP permite autentificar a nivel de objetos, SSL a nivel de conexión " En casos en que el acceso a cada objeto va por una conexión separada, ambos ofrecen el mismo poder " En caso de hacer canalización (tunneling) debido, por ejemplo, a restricciones de NAT, SECIOP sigue man- teniendo la granularidad a nivel de objetos, SSL no

52 Implementación de llamadas CORBA " Puede haber otras formas de codificación, por ejemplo XIOP, inspirado en SOAP " XIOP usa XML en lugar de CDR y usa HTTP en lugar de IIOP. " Por seguridad HTTP (al igual que IIOP) puede ir codificado sobre SSL

53

54 ¿Qué puertos usa Corba? " No se establece como estándar " En común que los ORB´s creen los servicios en puertos diferentes > 1204, elegidos dinámica- mente " Otros ORB´s proveen herramientas de canaliza- ción y se puede especificar un puerto fijo para todas las conexiones

55 Impacto sobre desempeño " Codificación (CDR, XML u otra), necesaria por diversidad de plataformas " Implementación sobre SSL " El handshake tiene alto impacto si hay muchas invocaciones a métodos (llamadas IIOP) que no se canalizan sobre una o pocas conexiones SSL " La codificación/encriptamiento tiene impacto en transferencias largas de datos

56 ¿Cómo afecta la implementación de NAT en sistemas basados en Corba? " Normalmente las llamadas a Corba desde una red con IPs privados detrás de un dispositivo NAT van a funcionar " El uso de NAT afecta principalmente a los callbacks " Una llamada al IP del dispositivo NAT no va a funcionar a menos que éste la pase hacia adentro

57 ¿Cómo afecta la implementación de NAT en sistemas basados en Corba? " Soluciones: " Instruir al dispositivo NAT para que las llamadas a ciertos puertos los reenvíe “hacia adentro”, haciendo NAT, a las máquinas que tienen los servicios " Utilizar algún tipo de canalización que permita conexiones “hacia adentro” por el mismo canal abierto desde adentro. " Algunos ORB´s proveen herramientas de canalización que permiten hacer los callbacks en las conexiones de entrada ya establecidas (ej. Firetunnel de Orbacus)

58 ¿Cómo afecta la presencia de firewalls a los sistemas distribuidos basados en Corba? " En el cliente un firewall/dispositivo NAT deja pasar conexiones hacia afuera, en el servidor el firewall restringe la entrada a ciertos puertos " Muchas implementaciones de ORBs no pueden funcionar a través de firewalls, a menos que el administrador de seguridad abra los puertos > 1024 " Idealmente se debe canalizar las conexiones a través de un sólo puerto y pedirle al administrador que lo abra " Preferiblemente se debe hacer las conexiones sobre SSL o TSL

59 ¿Cómo afecta la presencia de firewalls a los sistemas distribuidos basados en Corba? " Algunas opciones de implementación: " Se instalan los servicios Corba como bastiones dentro de la red de seguridad, es decir, con filtro interno " Se canaliza todo el tráfico a través de una sola conexión, (tunneling) " Se instala un firewall o proxy especialmente destinado para los servicios Corba

60 Firewalls de Corba " El problema de dejar pasar conexiones sólo a los servicios permitidos (incluyendo el acceso a objetos Corba) no es el único " ¿Cómo podemos garantizar que acceden sólo clientes autorizados? " Certificación del cliente con SSL " Firewalls de Corba (a nivel de IIOP o a nivel de objetos Corba)

61 Problemas genéricos al usar firewalls para Corba " Direccionamiento: la creación de objetos y posterior exportación del IOR puede tener que tomar en cuenta que debe pasar la dirección IP del proxy, no la local " Si usamos un firewall transparente, entonces los servicios deben estar en puertos bien conocidos " Corba es dinámico, se puede iniciar servicios constantemente, luego el firewall puede tener que ser actualizable dinámicamente " Puede haber varios firewalls/proxies en el camino entre el cliente y el servidor (firewall cascading)

62 Protección en Corba Filtro de Paquetes (están puestos por otras razones) Encabezado IPIP Proxy/envoltorios (wrappers) de TCP, SOCKS SocketFlujo de TCP Proxy de IIOPSocket, encabezado de la petición Mensaje IIOP Proxy de ObjetosSocket, encabezado y cuerpo de la petición Petición al ORB Tipo de Firewall Información Disponible CAPA

63 Proxies de Corba a nivel de TCP " Un proxy que acepte conexiones de Corba y las reenvíe al servidor real que contiene el objeto permite un nivel mínimo de chequeo " Puede restringir la conexión dependiendo de la información que tiene: números IP y puertos " No dispone del contenido de los mensajes, de modo que no podría autentificar por usuario " Si se utiliza SSL para conectarse al proxy se agregaría un nivel de autentificación

64 Proxies SOCKS para Corba 1 El cliente se autentica en el servidor 2 El cliente solicita uns conexión en el servidor de aplicaciones 3 El proxy SOCKS concede el permiso 4 El proxy SOCKS realiza la conexión al servidor de aplicaciones 5 Cliente y servidor intercambian datos transparentemente Cliente ORB adaptado para usar SOCKS Servidor Proxy de SOCKS Servidor de aplicaciones 1 2 3 5 4 5

65 Proxies a nivel de GIOP " El proxy en este caso recibe los mensajes GIOP y los puede examinar, en particular elñ encabezado, que contiene: " La operación invocada " La clave que identifica el objeto referenciado " El cliente " Se puede tomar decisiones con base en esta información detallada " El cuerpo del mensaje no es entendible por el proxy, ya que sólo el servidor tiene la definición de la interfaz de este objeto

66 Proxies a nivel de GIOP " Podemos clasificar los proxies de GIOP en dos grupos " De modo “normal” " El cilente le hace la solicitud al proxy, que la recibe como si fuera el servidor " Examina la solicitud y aplica las medidas de seguridad " Genera una solicitud similar para el servidor real " De modo transparente o “passthrough” " El cliente le hace la solicitud al servidor real " El proxy está en el camino, como un firewall, recibe el mensaje, aplica las medidas de seguridad y lo envía al servidor real como si su procedencia fuera el cliente original.

67 Recapitulemos " Hablamos de la importancia los aspectos de seguridad concernientes al acceso seguro a objetos " Examinamos la perspectiva general de protección de información " Analizamos el funcionamiento de varios de los mecanismos de protección que existen en redes " Examinamos cómo estos mecanismos pueden tener impacto en la implementación y el desempeño de sistemas distribuidos " Examinamos mecanismos de protección orientados a sistemas distribuidos basados en Corba

68 Conclusiones " Los mecanismos de protección general en redes tienen influencia en el desarrollo y desempeño de sistemas distribuidos " Estos mecanismos no se pueden obviar y con frecuencia su implantación no está en nuestras manos " Sin embargo estos mecanismos no son suficientes para atender los requerimientos de seguridad en sistemas distriubuidos

69 Conclusiones " Agregar mecanismos de seguridad al nivel de detalle de acceso a objetos tendrá un impacto aún mayor en desempeño " Hay aspectos que traen mayor complejidad al problema, como son los de interoperabilidad entre sistemas distribuidos basados en objetos (DCOM, EJB)

70 Gracias por su atención! Emilio Hernández Universidad Simón Bolívar