1.264 Tema 18 Seguridad Web: Certificados, autoridades IPsec, PKI Ataques, iniciativas Seguridad del software
Claves públicas y autoridades que expiden certificados Cómo obtener claves públicas: No puede guardar todas las claves posibles de receptores en su sistema. No puede pedirle al receptor que se la envíe, porque podría ser espiado. No tiene ( no puede tener?) una gran base de datos pública: El coste, rendimiento de cientos de millones de claves es un problema. Autoridades que expiden certificados (CA): Entidades comerciales, cuyas claves públicas están en su navegador. Pida al usuario que le envíe su certificado digital, firmado por una CA, antes de comunicarse con él/ella. Con el certificado, verifica su identidad y obtiene su clave pública. La CA encripta el certificado y su hash con su clave privada (de la CA). El usuario (usted) desencripta el certificado con la clave pública de la CA y comprueba el hash para asegurarse de que el certificado no ha sido alterado.
Funcionamento de los certificados digitales 1. Genere un par de claves pública/privada en su sistema. 2. Guarde la clave privada y envíe una solicitud de certificado a la CA: Ésta incluye su clave pública e información identificativa sobre usted. 3. Pague la tasa de la CA. 4. La CA realiza una verificación, rápida o detallada, de su identidad. 5. Si su identidad es correcta, la CA elabora el cuerpo del certificado con su clave pública e ID (de usted): El certificado de navegación ( personal ) incluye su nombre y dirección de correo electrónico. El certificado de servidor ( sitio ) contiene la URL. 6. La CA genera un resumen del mensaje del certificado y firma el hash con su clave privada, creando el verdadero certificado. 7. La CA le envía a usted el certificado.
CA raíz y cadenas de certificados Las CA raíz tienen certificados en el navegador o en el servidor Web: Debe confiar en Microsoft, Netscape y en el distribuidor de su sistema. Las CA raíz pueden firmar las claves públicas de otras CA: La firma incluye el certificado de la CA raíz. Se pueden crear cadenas de certificados: El último certificado contiene los certificados de todas las CA de la cadena, de modo que se puede hacer un seguimiento hacia atrás hasta la CA raíz original. Se utiliza la clave pública de la primera CA para obtener la clave pública de la segunda, que a su vez se utiliza para obtener la de la tercera, etc. Las cadenas se suelen utilizar hoy en día en intranets para verificar los navegadores a través de una cadena de servidores. SET y los esquemas de pagos digitales también utilizan cadenas. Es razonable que genere y administre sus propias claves públicas y privadas cuando el número de sitios es limitado.
Problemas de los certificados Sucesos que invalidan el par de claves pública/privada: Robo, cambio de la información de ID, se compromete la clave... Corrupción del disco (la clave privada está encriptada con contraseña en el disco). Lista de revocación de certificados (CRL) se pretende elaborar una, pero todavía no existe: Técnicamente, se debería contrastar con la CRL antes de iniciar la comunicación. Los certificados suelen caducar en un año, pero eso es mucho tiempo. La privacidad es imposible, porque usted se identifica a la otra parte: El algoritmo de Diffie-Hellman permite encriptación sin autenticación. D-H es susceptible de sufrir ataques de intromisión de terceros: A C ( intromisión de un tercero ) B
IP seguro: IPsec Los protocolos TCP/IP (y el IPpor sí solo) no son seguros: Nunca fueron pensados para el uso que se está haciendo de ellos. IPsec permite la encriptación de las datos y/o cabeceras TCP/IP: IPsec requiere reemplazar toda la información TCP/IP de cada PC que accede al servidor. Nadie quiere costear esto; se producirá poco a poco. IPSec es muy similar a SSL, pero encripta los paquetes IP (que contienen el tráfico HTTP y HTML). IPSec debe funcionr en muchas más situaciones y es mucho más complejo. Las claves, los certificados, etc. componen la Infraestructura de claves públicas (PKI). Los certificados son del estándar X.509, PKI es de otras varias. En todo este tema hemos tratado fundamentalmente la seguridad de las redes: Ahora, hablaremos brevemente de la seguridad de clientes y servidores. La seguridad de un servidor es, en su mayor parte, una cuestión de configuración y cuidado.
Firewalls Sin firewalls, es posible atacar y comprometer a los PC más débiles de una red interna, comprometiendo también al resto. El atacante reemplaza algunas llamadas del sistema operativo del PC por las suyas propias. Es casi imposible monitorizar todos los PC en busca de actividades sospechosas. Los firewalls ubican una máquina especial entre la red interna e Internet: No permiten el tráfico directo de los PC a Internet; todo el tráfico pasa por el firewall. El firewall funciona en versiones 'ligeras' de WinNT o UNIX: Nada de servicios innecesarios ni software sospechoso. Logs de todas las actividades. Los proxies a nivel de aplicación inspeccionan los paquetes: Ej.: el proxy HTTP puede localizar y deshabilitar objetos ActiveX. Los proxies a nivel de paquetes miran las cabeceras, los destinos, etc.
Configuración 1 del firewall Internet Router DMZ LAN Firewall Terminales ( Filtros?) Servidor Web Puede que el control del router lo tenga su proveedor de servicio a Internet (ISP) en lugar de usted. A menudo, el firewall está configurado para permitir sólo tráfico http (puerto 80). Pero usted puede necesitar otros puertos (smtp, ftp, telnet, IIOP, etc.).
Configuración 2 del firewall Internet Firewall/ proxy DMZ LAN Terminales Servidor Web El firewall puede controlar también el proxy de servicio Web, único dispositivo al que se permite el acceso a Internet. El firewall dispone de reglas para permitir que sólo el proxy se conecte a Internet. El firewall y el proxy se pueden ejecutar en la misma máquina. Otra alternativa es que el proxy esté en una LAN.
Problemas de seguridad en la actualidad Denegación de servicio (DoS), denegación de servicio distribuida (DDoS): Lluvia de paquetes (TCP-SYN, ACK, RST; UDP; ICMP-ping). El origen del flujo es a menudo un sistema infectado. A menudo se usa un engaño de IP (dirección IP de origen falsa) TCPv4 no está diseñado con elementos de seguridad/protección. Hay "Kits" en Internet para generar estos ataques: Interfaces de usuario para seleccionar el objetivo, el tipo de ataque y las máquinas a las que comprometer, de ser posible. Antiguamente, el objetivo principal era el sistema UNIX; hoy en día, son los sistemas de Microsoft los más atacados. El chat (IRC) se utiliza para controlar agentes; propagar ataques. En los ataques DoS hay un grado elevado de automatización. Los ataques DoS disponen un margen pequeño para trabajar antes de que se tomen medidas de seguridad.
Problemas de seguridad en la actualidad, 2ª parte Ataques DNS (BIND): La solución es utilizar la última versión de DNS. Agujeros en los script CGI: La mayoría de los ejemplos de script de la Red tienen agujeros de seguridad. No utilice CGI. Llamadas a procedimientos remotos (COM, CORBA, otras): Si no se utilizan, es conveniente deshabilitarlas; cambiar a SOAP. Servidor Web IIS de Microsoft : Algunos recomiendan cambiar a Apache/Tomcat. Microsoft necesita parchear todas las vulnerabilidades. Sendmail (de UNIX) se ejecuta con privilegios de root: Actualizar a la última versión. Se elaboró como un proyecto de doctorado. NFS y mountd: montaje de unidades compartidas por sistemas remotos (UNIX, Win): Otorga privilegios de root (UNIX) y permisos de lectura y escritura por defecto (Win). Cuentas con contraseñas débiles o sin ellas, incluida root/admin. Los protocolos de correo IMAP y POP son poco seguros. SNMP es poco seguro (la contraseña "private" por defecto pocas veces se reajusta). Puede dejar que un hacker controle los routers. Objetivo actual.
Problemas de seguridad en la actualidad, 3ª parte Todas estas debilidades las explotan: Gusanos: el programa hace copias de sí mismo en otras máquinas y se propaga por sí solo. Virus: el programa altera o infecta programas o archivos existentes, que son los que luego lo propagan. Troyanos: programa que no se copia ni se duplica, sino que daña directamente al sistema atacado. Por lo general, se extiende por correo electrónico. Consultar definiciones en: http://www.symantec.com/avcenter/refa.html
Iniciativas de seguridad Proof-carrying code (PCC), proof-carrying authorization: El código enviado por el servidor contiene una prueba segura de que dicho código sigue una política de seguridad determinada. El cliente dispone de un sistema de validación de pruebas. Tarjetas inteligentes, biométrica para autenticación. Estándar de encriptación avanzado (AES) o algoritmo de Rijndael, para reemplazar al DES. Algoritmo de clave simétrica de 128 a 256 bits. Véase nist.gov Twofish perdió frente a Rijndael en la convocatoria AES (véase SSL). Firewalls con análisis criptográficos de programas: ZoneAlarm es gratuito y eficaz. Detección de una intrusión: Analizar el tráfico de red, examinar cada paquete del flujo de datos para identificar amenazas de usuarios no autorizados, hackers que hayan burlado los sistemas de control. Los firewalls no son suficiente.
Iniciativas de seguridad, 2ª parte AAA (autorización, autentificación y administración o gestión de cuentas) para servidores Web y de aplicaciones: RADIUS (Remote Authentication Dial-In User Service): protocolo cliente/ servidor que comunica los servidores de acceso remoto con el servidor central para autentificar las llamadas entrantes o los usuarios remotos y autorizar su acceso al servicio o sistema solicitado. Se empieza aplicar también en servidores de aplicaciones. RADIUS es un estándar de facto de la industria, propuesto por el IETF. TACACS+ (Terminal Access Control 2 System) es un estándar más antiguo. R1 servidor RADIUS PC remoto NAS R2 T1 T2 servidor RADIUS servidor TACACS+ servidor TACACS+ Terminal Recuerde que, como siempre, las personas son el elemento clave: Experiencias del equipo "Tiger". Trabajos "desde dentro".
La seguridad en Java Dos modos: aplicación y applet. Los applets se limitan a la sandbox en el modelo de seguridad original: No es posible leer o escribir desde el disco local. No se puede acceder al hardware físico: memoria, disco, teclado, pantalla, etc. No se puede acceder al entorno del sistema. No es posible llamar a comandos del sistema o ejecutar programas externos. No es posible abrir conexiones de red a ninguna máquina, salvo a la máquina desde la que se realizó la descarga ( limita el envío de datos del usuario ). El gestor de seguridad de Java refuerza la seguridad: Obliga al applet a cancelar si intenta realizar una operación ilegal. Ejecuta un verificador de código byte para contrastar con las rutinas. Modelo original demasiado estricto: Evita muchas cosas malas, pero también muchas buenas. Los applets no pueden imprimir, guardar en disco, convertir archivos ni enviar resultados por red. Los usuarios pueden otorgar a los applets firmados algunos privilegios sobre archivos seleccionados, etc. Los applets pueden estar firmados con certificados de los autores.
Primer(os) modelo(s) de seguridad de Java código local Modelo de seguridad JDK 1.0 código remoto sandbox JVM recursos valiosos (archivos, etc.) código local Modelo de seguridad JDK 1.1 fiables sandbox código remoto JVM recursos valiosos (archivos, etc.)
Modelo actual de seguridad de Java Modelo de seguridad de la plataforma Java 2 código local o remoto (firmado o no) política de seguridad cargador de clases JVM recursos valiosos (archivos, etc.) sandbox el código se ejecuta con diferentes permisos, sin el concepto incorporado de código fiable
Seguridad de ActiveX No se tuvo en cuenta desde el principio, como sí se hizo con la seguridad de Java. ActiveX es un reempaquetado de COM/OLE: Los controles ActiveX disponen de un entorno completo de aplicación. Microsoft y Verisign (CA) utilizan Authenticode para firmar controles, como solución parcial: La mayoría de los agujeros de seguridad los introducen los desarrolladores sin darse cuenta; posteriormente, "los malos" encuentran estos agujeros y los explotan. El modelo de seguridad de ActiveX no ofrece protección frente a este problema. Es inútil: Está bien utilizar controles ActiveX en un entorno de servidor en el que están permenentemente cargados, pero no es razonable obtenerlos desde una red.
Seguridad de JavaScript No se diseñó pensando en la seguridad desde un principio. Presenta problemas muy variados: Puede enviar mensajes de correo electrónico en nombre del usuario. Puede obtener listados de directorios y, luego, poner en una página Web un comando inocente que suba todos los archivos al servidor, sin que el usuario sea consciente de ello. Puede abrir ventanas de dimensión cero y ejecutar scripts para espiar. Denegación de servicio: abrir ventanas más rápido de lo que usted puede cerrarlas. VBScript (y las macros de VB) presentan problemas similares. Tanto VBScript como JavaScript son casos perdidos: Una vez más, se pueden instalar en el servidor, pero no obtenerlos de la red.
Resúmen Infraestructura de claves públicas (PKI) para la seguridad de redes: Certificados, encriptación, CAs e IPsec (futuro). Todavía costoso. Las implementaciones de muchos distribuidores no se llevan bien entre sí. Se espera que experimente un gran aumento en los próximos 12 meses. Paso a XML, XSL y Xlink en detrimento de JavaScript, applets, etc.; para mejorar la seguridad del cliente: XML lo pueden enviar y recibir simétricamente clientes y servidores. Utiliza el puerto 80 (HTTP), un protocolo bastante seguro (restringido). Mejora continua de los sistemas operativos de servidor para incrementar la seguridad de los mismos: CERT (www.cert.org), otros servicios de seguridad: continuas alertas y arreglos.