David Guerrero
1.- Introducción
Cuando hace casi 2 años acometimos el proyecto de modernizar las comunicaciones del Ministerio de Educación, uno de los hitos más importantes que surgió fue la conexión a Internet. Lo que al principio era un problema sobre qué servicios ofrecer de todos los existentes, enseguida giró hacia otra dirección. Los condicionantes de seguridad eran tan altos, que, justificadamente, se convirtieron en los protagonistas a partir de ese momento. Además aparecían condicionantes económicos de importancia a la hora de ofrecer determinados servicios debido a la infraestructura física de nuestras comunicaciones.
Dichos condicionantes obligaron a la elaboración de una política de seguridad específica para nuestra organización, en la que se consideraron los múltiples aspectos a proteger y los procedimientos que se articularían para llevar a cabo satisfactoriamente todos estos objetivos.
2.- Expectativas de la conexión a Internet
La idea de la conexión a Internet abría nuestras instalaciones a un abanico extraordinario de servicios, pero a la vista de las limitaciones que íbamos a tener que imponer en función de los condicionantes de seguridad y economía, decidimos concretarlos en unos pocos :
- Servicio de correo electrónico para todos los usuarios.
- Acceso a las NEWS de Internet, así como grupos locales, para todos los usuarios.
- Difusión a la comunidad académica y al resto de Internet de las Bases de Datos residentes en los hosts de nuestra red interna, así como de información de carácter general del MEC.
- Otros servicios, como telnet a sistemas externos, y como no, el servicio estrella de cualquier conexión a Internet que se precie, acceso a la WWW.
3.- Estructura de la red
Para entender el desarrollo y topología de la red del MEC, en primer lugar se ha de comprender mínimamente la estructura funcional de la organización. Por una parte se encuentra lo que denominamos Servicios Centrales, una serie de edificios situados en varios puntos de Madrid, relativamente distantes entre sí. Entre estos edificios se encuentra el más conocido de ellos: la sede central del MEC en la calle Alcalá, con el gabinete del ministro y otras subdirecciones. Por otra parte, como principal centro informático y de comunicaciones del ministerio, se encuentra el edificio de la S.G.T.I. (Subdirección General de Tratamiento de la Información) , sito en la calle Vitruvio. Además de estos dos edificios principales, existen otras 8 ó 9 dependencias más, que albergan otras unidades funcionales del MEC, repartidas por toda la capital.
Por otra parte, el MEC dispone de una serie de delegaciones en cada una de las provincias que administrativamente gestiona, en el llamado territorio MEC. A cada una de estas delegaciones se las denomina Direcciones provinciales. Concretamente, en la actualidad existe conectividad con la totalidad de estas 26 provincias. Como caso especial, se sitúa nuevamente Madrid, que en lugar de disponer de una Dirección Provincial, dispone de 5 Subdirecciones territoriales, igualmente conectadas al grueso de la red del MEC.
La topología de la red con las Direcciones Provinciales es de una doble estrella, con centros en Alcalá y Vitruvio, basada en líneas X.25 de 9.600 bps en su gran mayoría, con los nodos centrales de 64 Kbps. El protocolo que circula por ellas es IP, encapsulado por encima de X.25.
La conectividad con los edificios de Madrid está basada en líneas punto a punto, de varias velocidades, con backups basados en RDSI, configurados en modo bandwidth on-demand.
La conectividad con el resto del mundo Internet es proporcionada por RedIRIS, que como es sabido, tiene ubicados sus nodos centrales en su sede de la calle Serrano, a escasos metros de las instalaciones de esta S.G.T.I. Esta afortunada coincidencia geográfica es la que nos ha permitido realizar una conexión a sus instalaciones vía fibra óptica. Y así, incorporarnos a la denominada red del Campus de Serrano, que ya estaba integrada por la propia RedIRIS y el CSIC, algunas de cuyas instalaciones también están situadas en las proximidades.
Es importante remarcar en este punto, que la conexión del MEC a esta red del Campus de Serrano, se realiza a velocidad ethernet (10 Mbps), dado que la capacidad de la fibra óptica tendida entre ambas organizaciones es claramente superior a esta última, pero que la salida internacional y al resto de universidades se realiza por un enlace serie con velocidad fijada a 500 Kbps, perteneciente al mismo router ubicado en RedIRIS, para evitar agravios comparativos con el resto de organizaciones afiliadas a RedIRIS y que por situación geográfica no les sea posible disponer de este tipo de enlaces.
Aún con esta limitación de la velocidad de salida en la línea internacional, ésta es plenamente suficiente hasta el momento y no parece que vaya a convertirse en un cuello de botella en un futuro cercano.
4.- Direccionamiento
Cuando acometimos el Plan de Comunicaciones que pretendía modernizar las infraestructuras de comunicaciones y establecer la mencionada conexión a Internet, nos encontramos con una red que había crecido muy rápidamente, y a la vez, de forma bastante anárquica. Por ella circulaban básicamente dos protocolos: IP y VINES. El tráfico VINES se centraba fundamentalmente en los enlaces punto a punto entre los edificios de Madrid, por los que también circulaba protocolo IP encapsulado. Las comunicaciones con las Direcciones Provinciales se basaban únicamente en TCP/IP encapsulado encima de conexiones X.25 conmutadas por Iberpac.
Lo peor vino con el direccionamiento utilizado en la anterior estructura: se había utilizado para cada red, ya fuera de unos cuantos sistemas o de algunos cientos, una clase A completa, haciéndolas coincidir con los códigos postales de las provincias, y otros números para las distintas redes de Madrid.
Dado que el espacio de direcciones utilizado, o mejor dicho, malgastado, por nuestra organización coincidía con buena parte de las direcciones en uso en Internet, esta forma de direccionamiento nos obligó a acometer un cambio de direccionamiento generalizado en todo el Territorio MEC, incluyendo todos los edificios de Madrid.
Puestos al habla con RedIRIS, nos pusieron al corriente de la dificultad de conseguir por parte de los organismos internacionales correspondientes, una cantidad de direcciones oficiales, que tras nuestras estimaciones, sería de una clase B aproximadamente. Una vez llegados a este punto, nos planteamos utilizar un esquema mixto de direccionamiento privado RFC-1597 y direccionamiento NIC. Con el inestimable apoyo y asesoramiento de RedIRIS, paralelamente al comienzo de la renumeración de nuestras redes con direccionamiento privado, iniciamos las gestiones para conseguir por parte de RIPE el máximo número de clases C. Al final, y después de varios meses de peticiones rechazadas y revisadas, logramos conseguir un bloque de 85 clases C, que progresivamente iremos aplicando en nuestras redes internas y externas.
5.- Políticas de seguridad
Administrativamente, y a la hora de plantear el proyecto, se nos impusieron unos criterios de seguridad muy estrictos. La conexión a Internet sólo debía realizarse cuando los riesgos de posibles problemas de seguridad, tales como accesos no autorizados o robos de información, fuesen absolutamente minimizados.
A la vista de que la red actual estaba basada en un host IBM principal razonablemente seguro, y una serie de sistemas Unix de producción y desarrollo con una seguridad bastante más relajada, además de los innumerables PC's de usuarios finales, se llegó a la conclusión de que una conexión directa a Internet, por mucho que se mejorase la seguridad en cada uno de los sistemas pertenecientes a nuestra red, nunca llegaría a cumplir los requisitos mínimos de seguridad que nos fueron encomendados.
Para la elaboración de la política de seguridad, el primer paso fue hacer una relación de los aspectos sensibles dentro de la organización, tanto físicos (equipos Unix, routers, etc.), como no materiales (aplicaciones, bases de datos, etc...).
Una vez realizada esta lista de puntos sensibles a proteger, se pondera cada uno de ellos con un peso específico, y se calcula la posibilidad de que sea vulnerado, ya sea por ataques intencionados o por causas meramente accidentales.
Conocer los puntos a proteger es el primer paso a la hora de establecer normas de seguridad. También es importante definir los usuarios contra los que proteger cada recurso. Las medidas diferirán notablemente en función de los usuarios de los que se pretenda proteger el recurso.
Las tres preguntas fundamentales que debe responder cualquier política de seguridad son:
Según nuestra política de seguridad : Se deberían proteger todos los elementos de la red interna, incluyendo hardware, software, datos, etc. de cualquier intento de acceso no autorizado desde el exterior y contra ciertos ataques desde el interior que puedan preverse y prevenir. Sin embargo, podemos definir niveles de confianza, permitiendo selectivamente el acceso de determinados usuarios externos a determinados servicios o denegando cualquier tipo de acceso a otros.
La respuesta a la tercera pregunta es la más difícil de resolver y la que requiere unas soluciones más dinámicas y cambiantes en lo que se refiere a la vigencia de dicha política de seguridad.
Se pueden plantear distintas soluciones u opciones en varios aspectos :
- Paradigmas de seguridad:
- Todo lo que no se prohibe expresamente está permitido
- Todo lo que no se permite expresamente está prohibido
- Estrategias de seguridad:
- Paranoica
- Prudente
- Permisiva
- Promiscua
- Métodos de defensa:
- En profundidad
- Perimetral
Optamos por una estrategia "prudente", sin caer en lo "paranoico" (técnicamente hablando...), pero tampoco en lo "permisivo". Se adopta esta solución a la vista de la dificultad de mantener un sistema de seguridad de este nivel (paranoico) con los medios tanto técnicos como humanos de los que disponemos.
Por otra parte, y para forzar el cumplimiento obligado de las medidas adoptadas, se opta por un modelo "todo lo que no se permite expresamente está prohibido", especialmente en el punto único de entrada y salida del perímetro interior.
Otros aspectos muy importantes a incorporar en la política de seguridad son :
- Procedimientos para reconocer actividades no autorizadas.
- Definir acciones a tomar en caso de incidentes.
- Definir acciones a tomar cuando se sospeche de actividades no autorizadas.
- Conseguir que la política sea refrendada por el estamento más alto posible dentro de la organización.
- Divulgar la política de forma eficiente entre los usuarios y administradores.
- Articular medidas de auditoría de nuestro propio sistema de seguridad.
- Establecer plazos de revisión de la política en función de resultados obtenidos.
6.- Seguridad perimetral
Las directivas marcadas por la política de seguridad definida, nos fuerzan a diseñar nuestra red como dos perímetros claramente definidos.
Un perímetro interior, en el que se situarán todos los recursos sensibles a un posible ataque, aislado del perímetro exterior donde se situarán los recursos menos sensibles, o que inevitablemente por motivos funcionales deban estar en contacto con el mundo exterior de forma menos rígida. El perímetro interior está aislado o protegido del perímetro exterior y del resto de Internet, por medio de un dispositivo en el que se centralizarán la mayoría de las medidas: el firewall.
En nuestro caso, en el perímetro exterior es necesario ubicar dos servidores para poner a disposición de Internet determinada información de interés general. Se trata de nuestros servidores WWW y Wais.
Será necesario aplicar otra serie de medidas completamente diferentes a estos servidores externos. Dado que están mucho mas directamente expuestos a posibles ataques externos, será necesario utilizar en ellos medidas típicas de seguridad en profundidad.
6.1.- El Firewall
La herramienta fundamental que nos va a permitir implementar el modelo de seguridad definido por la política de seguridad es un dispositivo que se sitúe entre el perímetro interior y el exterior de nuestra red. A este dispositivo, tradicionalmente, en la jerga informática se le denomina firewall, que se podría traducir al castellano como cortafuegos. Dado que es el componente más crítico e importante en todo el diseño del sistema de seguridad, la elección de este elemento debe ser muy concienzuda. Generalizando un poco, los firewalls se pueden dividir en tres grandes categorías :
Firewalls basados en filtrado de paquetes:
Son aquellos dispositivos que estando conectados a ambos perímetros (interior y exterior), dejan pasar a su través paquetes IP en función de unas determinadas reglas. Estos firewalls conceptualmente trabajan a nivel de red, y son capaces de filtrar tráfico en función de direcciones de IP, protocolos, y números de puerto de TCP o UDP.
Normalmente, esta misión la pueden desempeñar tanto hosts con dos tarjetas de red, como routers. En el caso de firewalls basados en filtrado de paquetes, los dispositivos de la red interna han de configurarse con la ruta por defecto apuntando a este dispositivo, que en función de sus reglas, dejará pasar estos paquetes o los rechazará.
El principal problema de este tipo de firewalls es la limitación a la hora de configurar reglas complejas y la falta de flexibilidad en la capacidad de log, o registro de actividad. Otra limitación fundamental es la imposibilidad de filtrar tráfico en función de información contenida en niveles superiores, tales como URL's, o esquemas de autenticación fuertes.
- Firewalls basados en proxies:
Son aquellos dispositivos que estando conectados a ambos perímetros (interior y exterior), no dejan pasar a su través paquetes IP. Esto en jerga informática se denomina ip-forwarding desactivado. La comunicación se produce por medio de programas denominados proxies, que se ejecutan en el firewall. Este tipo de sistemas también se denominan bastion host. Desde el punto de vista conceptual, este tipo de firewalls funciona a nivel de aplicación.
Un usuario interior que desee hacer uso de un servicio exterior, deberá conectarse primero al firewall, donde el proxy atenderá su petición, y en función de la configuración impuesta en dicho firewall, se conectará al servicio exterior solicitado y hará de puente entre el servicio exterior y el usuario interior. Es importante notar que para la utilización de un servicio externo, dos conexiones o sockets han de establecerse. Uno desde la máquina interior hasta el firewall, y otro desde el firewall hasta la máquina que albergue el servicio exterior.
En el caso de este tipo de firewalls, los programas clientes deben estar configurados para redirigir las peticiones al firewall en lugar de al host final. Esto es trivial en navegadores WWW, como Netscape, Internet Explorer o Lynx, y en clientes FTP, como WS_FTP y otros. En cambio, aplicaciones tipo TELNET, no suelen incluir este tipo de soporte, y para ello, lo habitual es conectar directamente con el firewall y desde allí, el proxy nos permite especificar el destino final de nuestro telnet, que en este caso, sería encadenado.
La capacidad de logging o registro de actividad es mucho mayor con este tipo de dispositivos. Información típica registrada por estos sistemas va desde el nombre de usuario que ha conseguido autentificarse satisfactoriamente, hasta los nombres y tamaños de ficheros transmitidos vía FTP, pasando por los URL's solicitados a través del proxy HTTP.
- Firewalls con transparencia o de tercera generación:
Recientemente han aparecido en el mercado dispositivos que van un paso más allá en la tecnología de firewalls. Se trata de los firewalls de tercera generación o transparentes. La característica primordial de estos sistemas es que admiten paquetes no destinados a ellos mismos, de forma similar a como lo hacen los routers, y en función de una serie de reglas y configuraciones, son capaces de arrancar los proxies correspondientes automáticamente y conectar con el destinatario inicial.
Aparentemente para el usuario, ha conectado con el servidor final, aunque realmente lo ha hecho con el proxy, que le devuelve los paquetes con dirección IP origen la del servidor final. Esto implica, que el programa cliente del usuario no requiere ningún tipo de configuración. En definitiva, se trata de firewalls basados en proxies, pero con apariencia y funcionalidad similar a los basados en filtrado de paquetes.
En esta línea se sitúan productos como BorderWare o Gauntlet [1], elegido este último como el firewall a utilizar por nuestra organización.
Gauntlet es un sistema complejo de proxies y programas auxiliares, que corre en sistemas SunOS con algunas modificaciones al kernel. Desarrollado por TIS (Trusted Information Systems), nace como versión avanzada del Firewall-Toolkit, software de libre distribución muy utilizado en Internet para la construcción de firewalls. Las ventajas fundamentales de Gauntlet frente al Toolkit son que incluye un programa de administración centralizado, una gestión de logs mucho más eficiente, soporte de proxies transparentes, y como ventaja fundamental para la organización, está soportado comercialmente.
6.2.- Estructura final con filtrado de paquetes en el router externo + Gauntlet
Como ya se vio en la sección dedicada a la definición de la política de seguridad, quedan claros dos perímetros físicos en nuestra red. Por una parte, el perímetro interno, con todos los servidores tanto de desarrollo como de explotación de la organización, así como todas las WAN que interconecta el resto de edificios y direcciones provinciales. Por otra parte, se plantea la necesidad de constituir un perímetro externo en el que se ubicarán los dos servidores necesarios actualmente para proveer al exterior los servicios de Bases de Datos, DNS y WEB.
Entre ambos perímetros se situará convenientemente un firewall de nivel de aplicación con soporte de proxies transparentes, concretamente Gauntlet. El perímetro interno, se considerará razonablemente seguro con las medidas dispuestas en el firewall.
En este punto nos aparece la problemática de la seguridad de la red externa. En esta red habrá que aplicar una serie de medidas completamente distintas a las aplicadas en el perímetro interno.
Dado que los servidores externos necesitan conectividad directa con Internet, y que están relativamente desprotegidos ante posibles ataques provenientes del exterior, se decide utilizar el router externo que nos comunica con RedIRIS, y por ende, con el resto del mundo, como firewall de filtrado de paquetes y establecer en él algunas reglas que impidan determinado tipo de ataques.
En la actualidad, las medidas impuestas en el router externo se orientan a defender los servidores del perímetro externo frente a ataques de tipo IP-Spoofing, en los cuales el atacante falsea la dirección de origen de los paquetes IP, haciéndola coincidir con la de alguna máquina interna, para así vulnerar las protecciones basadas en dirección de origen. Estas reglas consisten simplemente en no dejar pasar a través del router paquetes con dirección IP origen perteneciente a alguna de las redes internas, y que provengan del interfaz conectado al mundo exterior.
Adicionalmente se planteó la necesidad de conectar una de las puertas ethernet del host principal del MEC a la red externa para la utilización de una aplicación de transferencia de ficheros con las Universidades vía Internet, que sustituye a un sistema de comunicaciones basado en X.25. En este caso, el host articula mecanismos considerados seguros tanto de autenticación, como de control de acceso basado en direcciones IP. Como medida de seguridad adicional, este modelo impone que todas las transferencias, tanto de entrada como de salida sean iniciadas por el host.
Aún con las medidas de protección tomadas tanto en router externo, como en el host, se hace necesario aplicar medidas de seguridad en profundidad en todos y cada uno de los sistemas conectados a este perímetro exterior.
6.3.- Seguridad en profundidad en la red externa
Las medidas fundamentales tomadas en el perímetro exterior se pueden resumir en :
- Reducción al mínimo de los servicios TCP/IP ofrecidos por cada sistema.
- Reducción al mínimo de los usuarios en cada uno de los sistemas.
- Uso extensivo de tcp-wrappers en los servicios necesarios.
- Monitorización de routers en alerta de tráfico sospechoso.
- Escaneos periódicos de todo el perímetro en busca de posibles problemas.
- Sincronización de relojes en todos los sistemas para poder hacer un seguimiento fiable de logs en el caso de posibles incidentes.
- Reducción al mínimo de los servicios TCP/IP ofrecidos por cada sistema:
- Reducción al mínimo de los usuarios en cada uno de los
sistemas:
Los servidores externos tienen la responsabilidad de mantener activos distintos servicios TCP/IP, que sustentan las aplicaciones encargadas de publicar la información pública del ministerio. Estas aplicaciones son fácilmente mantenidas con un único usuario o como mucho dos (root y un usuario no-privilegiado), y dado que se supone que ningún usuario dispone de correo en ellos y que nadie desarrolla directamente sobre dichas máquinas, no hay necesidad de mantener más cuentas de usuarios que las estrictamente necesarias.
Determinadas aplicaciones precisan que todos sus ficheros sean poseídos por un determinado usuario, o que se arranquen en modo set-uid con la identidad de este usuario. En estos casos, el usuario debe existir en el fichero general de usuarios /etc/passwd, pero con shell nula, normalmente /bin/false.
- Uso extensivo de tcp-wrappers en los servicios necesarios:
Los tcp-wrappers[3] son un conjunto de utilidades de libre distribución, escrito por Wietse Venema, que permite un control de accesos bastante exhaustivo de los servicios que corren bajo inetd, además de buena capacidad de log de peticiones a dichos servicios, ya sean autorizados o no.
Básicamente consiste en un programa llamado tcpd, que se ejecuta cuando llega una petición a un puerto específico. Éste, una vez comprobada la dirección de origen de la petición, la verifica contra unas reglas simples, almacenadas en los ficheros /etc/hosts.allow y /etc/hosts.deny, y en función de ellas, decide o no dar paso al servicio. Adicionalmente, registra, utilizando la utilidad syslog del sistema, la petición y su resolución.
Una de las configuraciones avanzadas de este paquete, permite también ejecutar comandos en el propio sistema operativo, en función de la resolución de la petición. Por ejemplo, es posible que interese hacer un finger a una posible máquina atacante, en el caso de un intento de conexión, para tener más datos a la hora de una posible investigación. Este tipo de comportamiento raya en la estrategia paranoica, que ya vimos cuando se definió la política de seguridad.
Las modificación al fichero /etc/inetd.conf son muy sencillas y aparecen perfectamente especificadas en el trabajo "Seguridad en Redes" de Francisco Cruz Agudo, publicado en el número 35 del Boletín de RedIRIS, que analiza extensamente la instalación y operación de algunas de las herramientas descritas aquí.
Una de las ventajas de tcp-wrappers es que al compilarlo es posible indicar la categoría de syslog sobre la cual realizar el registro de actividad, con lo que resulta bastante sencillo dirigir toda esta información sobre un único fichero, que puede ser monitorizado regularmente para detectar intentos de accesos no permitidos.
En nuestro caso, los dos servidores externos, únicamente aceptan conexiones provenientes del firewall, es decir, del interior (ya que desde el exterior la conexión al firewall está muy restringida). Sólo tienen activos los servicios telnet y ftp, aparte de los específicos de su misión (WEB, WAIS, DNS, NEWS, etc...). La desconfianza llega al punto de no permitir las conexiones entre ellos, de forma que si uno de ellos se ve comprometido, el otro podría mantener su integridad, mientras el firewall no fuese vulnerado.
- Monitorización de routers en alerta de tráfico sospechoso
:
Se han instalado una serie de scripts que obtienen datos de tráfico del router externo a través de SNMP, a intervalos regulares y los van representando gráficamente a través de unas páginas HTML, que permiten tener una idea bastante aproximada del nivel de carga de la red en los distintos periodos del día. Esta monitorización del tráfico permite detectar tanto averías en el caso de ausencia de tráfico, como actividades sospechosas si se detecta mucho tráfico a horas no habituales.
- Escaneos periódicos de todo el perímetro en busca de
posibles problemas :
Circulan por Internet una serie de programas denominados escaneadores. Se trata de programas en los que una vez definido un host, o un conjunto de ellos (ya sea por direcciones de IP o por dominios de DNS), se dedican metódicamente a probar uno por uno todos estos sistemas, intentando penetrarlos o al menos chequear si poseen vulnerabilidades. Los dos escaneadores más utilizados en Internet son: ISS de Christopher Klaus, y SATAN de Dan Farmer y Wietse Venema. ISS[4] se ha convertido en un producto comercial en sus últimas versiones, pero las antiguas siguen siendo interesantes.
SATAN [5] es hoy por hoy el escaneador más avanzado. Además de poseer un entorno gráfico basado en WEB bastante potente, contiene una base de datos de vulnerabilidades muy completa.
Es muy importante utilizar periódicamente estas herramientas, dado que nos permitirán conocer la información que un posible atacante obtendría de nuestra red en el caso de que utilizase dichos programas contra nuestros sistemas.
- Sincronización de relojes en todos los sistemas :
Teniendo en cuenta que una de las tareas más importantes a la hora de vigilar la seguridad de nuestros sistemas es la revisión de logs, es fundamental que los relojes de los servidores que realizan estos logs estén sincronizados al objeto de poder hacer el seguimiento de un posible incidente, y también el poder concretar el orden en que sucedieron los hechos. Esto es también fundamental a la hora de contrastar logs con otras organizaciones, en el caso de que hubiese que hacer una investigación coordinada con terceras partes.
Dentro de los protocolos de sincronización en Internet, existen dos variantes: el antiguo protocolo TIME (puerto 37), y el más moderno NTP, que permite una sincronización mucho más precisa. En nuestro caso, nos hemos sincronizado vía protocolo TIME con un servidor de tiempo en RedIRIS (chico.rediris.es) desde el firewall, y éste se ha convertido en servidor de tiempo para el resto de las máquinas tanto del perímetro exterior como interior. En un futuro cercano se plantea crear una estructura basada en NTP con un servidor y múltiples clientes.
Habitualmente los sistemas Unix vienen configurados "de fábrica" con una serie de servicios TCP/IP activados, que en la gran mayoría de los casos nunca se utilizan, o en otros casos, pueden servir como puerta de acceso relativamente fácil a posibles intrusos. Entre estos servicios no necesarios, o potencialmente peligrosos, se desactivaron echo, discard, daytime, chargen, time, nntp, rlogin, rsh, talk, pop3, tftp, bootp, systat, netstat, y los aún más peligrosos, sendmail, finger, rexec, NFS, etc.
La mayoría de estos servicios puede desactivarse simplemente comentando su línea correspondiente en el fichero /etc/inetd.conf. Los servicios que no corren bajo inetd, normalmente se desactivan en los ficheros de arranque (/etc/rc2.d/*, /etc/rc.d/*, etc.).
Una utilidad muy interesante para chequear que servicios tiene activos un sistema es strobe[2], programa escrito por Julian Assange que escanea todos los puertos, tanto TCP como UDP, de un sistema, de forma rápida y efectiva.
6.4. - Seguridad en profundidad en la red interna
Debido al modelo de seguridad perimetral definido en la política de seguridad, la red interior queda razonablemente protegida de posibles ataques externos. De todas formas, es importante no olvidar los posibles problemas de seguridad que pueden originarse desde el interior de nuestro perímetro. Entre este grupo de problemas podemos clasificar los provocados por usuarios internos o por intrusiones realizadas desde puntos no controlados de nuestra propia red.
Contra este tipo de problemas, sensiblemente menos probables que los externos, se deberían aplicar medidas parecidas a las mencionadas en el perímetro externo, añadiendo el uso de programas de chequeo de la seguridad de las passwords elegidas por los usuarios. En este aspecto, el mejor programa existente en la red es Crack [6], de Alec Muffet, que permite utilizar un gran número de diccionarios y reglas de inferencia a la hora de verificar la calidad de una contraseña.
Otra medida fundamental a la hora de prevenir accesos desde el exterior por puntos no controlados de nuestra red, es establecer la prohibición del uso de modems con capacidad de llamada entrante. Si este uso fuese inevitable, como norma, al menos, deberían utilizarse para ello, sistemas no conectados físicamente a la red o realizarse bajo la estricta vigilancia del administrador de red responsable.
7.- Procedimientos generales de seguridad
Las normas dictadas en la elaboración de la política de seguridad, en algunos casos de forma concreta y en otros de forma más abstracta, pero igualmente concluyentes, han de materializarse en una serie de procedimientos y normas a seguir en la operación y mantenimiento de las tareas diarias del MEC, al menos en lo relacionado con las actividades que de una forma u otra tienen que ver con Internet.
7.1.- Restricciones en el firewall
La parte más importante de estas tareas se realizan en el firewall, concretamente la de permitir o denegar determinados servicios en función de los distintos usuarios y su ubicación. Definimos tres grandes grupos de usuarios :
- Usuarios internos con permiso de salida para servicios restringidos
- Resto de usuarios internos con permiso de salida para servicios no restringidos
- Usuarios externos con permiso de entrada desde el exterior
7.1.1.- Usuarios internos con permiso de salida para servicios restringidos
Gauntlet nos permite especificar una serie de redes y direcciones de IP a los que denomina trusted. Estos usuarios cuando provengan del interior van a poder acceder a unos determinados servicios que hemos definido como caros :
- Acceso a la WWW vía browser (HTTP)
- FTP
- Telnet
7.1.2.- Resto de usuarios internos con permiso de salida para servicios no restringidos
Estos usuarios más desfavorecidos geográficamente, aún pueden utilizar algunos de los servicios que nos ofrece la conexión a Internet, como :
- Correo electrónico
- Acceso a NEWS locales y externas
- Finger
- Whois
7.1.3.- Usuarios externos con permiso de entrada desde el exterior
Este es el caso menos habitual dentro de nuestros usuarios y además el más sensible a la hora de vigilarse. Suele tratarse de usuarios que por algún motivo han debido trasladarse a algún lugar remoto y deben acceder para consultar su correo electrónico o similares. También es habitual utilizarlo por parte de terceras empresas para dar servicios de tele-mantenimiento a equipos situados en nuestro perímetro interior. Para darles acceso hay que mantener una lista de dichos usuarios en el firewall, con sus correspondientes passwords, normalmente activados y desactivadas bajo demanda, únicamente el tiempo que sean necesarias.
Se impone como norma que estos usuarios han de utilizar autenticación fuerte para poder entrar desde el exterior. Esta autenticación fuerte consiste en un esquema de passwords de un solo uso que impiden ataques exteriores por robo de contraseñas.
Es de dominio público que Internet no es un canal seguro sobre el que transmitir información sin el peligro de que ésta pueda ser espiada. Este problema es aún mucho más sensible cuando la información a transmitir se trata de nombres de usuarios y sus passwords correspondientes.
El sistema de passwords de un solo uso utilizado por Gauntlet, se denomina S/KEY [7], y consiste en un procedimiento de desafío/respuesta, en el que al realizar la conexión e introducir el usuario, el sistema devuelve un número de secuencia decreciente en cada acceso y una semilla. En el punto remoto, el usuario, con la ayuda de un pequeño programa y su password (que sólo él conoce), genera una cadena de palabras seleccionadas de un diccionario inglés, que debe teclear en el prompt del sistema al que llama. Si todo va bien, se permite el acceso, y la próxima vez que decida acceder al sistema el número de secuencia habrá decrecido y tendrá que generar una nueva cadena de palabras cortas con ayuda de su programa, ya que la anterior habrá dejado de tener validez.
Por supuesto, como en cualquier esquema de passwords, el secreto (la password), debe cumplir las normas de cualquier buena password: no debe revelarse a nadie, no debe escribirse en papel, no debe ser fácilmente predecible, etc.. La ventaja de este sistema es que así nunca viaja por un canal inseguro.
7.2.- Política de gestión de Bases de Datos públicas
Como ya se comentó anteriormente, uno de los objetivos del proyecto de conexión a Internet era poder hacer disponibles las Bases de Datos del MEC al resto de la comunidad académica y de Internet. Actualmente la gran mayoría de bases de datos, residen, se mantienen y se consultan en el host principal, que aún siendo un ordenador enormemente potente, su interfaz de acceso no es todo lo amigable que se pudiera desear.
Para publicar toda esta información se pensó utilizar las propias herramientas que Internet proporcionaba en forma de paquetes software de libre distribución. Concretamente las herramientas elegidas fueron un servidor WEB (Apache) y un sistema de indexación de bases de datos documentales WAIS (freeWAIS-sf).
Se decidió que las máquinas que albergaran estos servicios deberían estar en el perímetro exterior para evitar accesos innecesarios desde el exterior a nuestra red interna. Por seguridad, todo desarrollo que se fuese a implantar en estas máquinas externas, se realizaría en sistemas internos y desde allí sería copiado al exterior, al objeto de que ante un ataque en el que estos programas se viesen dañados, poder disponer en el interior de una copia fiable.
Lo mismo ocurre con las bases de datos. Absolutamente ninguna de estas bases ha de modificarse en la red exterior y transmitir esa modificación a la copia interna, con lo que la copia externa sería refrescada periódicamente por la copia interna. Esto nos aseguraría la integridad de los datos aún en el caso de que alguna de las máquinas exteriores fuese comprometida.
7.3.- Uso de criptografía
Dentro de las tareas habituales del sistema informático del MEC, se incluyen múltiples transmisiones de ficheros de Servicios Centrales con las Direcciones Provinciales y el grueso de las universidades. Las consecuencias de que esta información pudiese alterarse en este trasiego, o por algún motivo fuese robado su contenido serían muy graves, por lo que habían de articularse mecanismos que asegurasen la integridad y la confidencialidad de la información. Este riesgo aumenta considerablemente si el canal de comunicación es Internet, como en el caso de las comunicaciones con las universidades.
Se optó por utilizar técnicas de encriptación o cifrado basadas en clave pública, dado que el riesgo de la transmisión de la clave secreta en sistemas de criptografía convencional era demasiado alto.
El software elegido para ello fue PGP [8], cuya versión 2.6.3i, no parece tener los problemas legales de exportación por parte del gobierno americano de otras versiones. Por otra parte, este software está comenzando a ser ampliamente usado y aceptado por la comunidad académica, gracias al apoyo que se le está prestando por parte de RedIRIS y otros grupos.
En este punto es importante reseñar que también se está comenzando a evaluar la instalación de un servidor seguro HTTP (https), que utilizando la especificación SSL 3.0 [9], proporcionaría una seguridad similar a los procedimientos de transmisiones de ficheros sensibles, simplificando el interfaz con el usuario final de forma considerable.
8.- Fuentes de información
En el cambiante mundo de Internet, y mucho más en el ámbito de la seguridad, lo que un día se considera imposible, el siguiente puede ser completamente normal y asequible a cualquiera. Es por esto que muchos de los mecanismos articulados pueden quedar desfasados en cualquier momento, ya sean aplicaciones, servicios, sistemas operativos, etc. De aquí la necesidad de mantenerse permanentemente informado de las novedades que surgen en este campo.
Así pues la mejor política al respecto es mantenerse actualizado con las últimas versiones tanto de sistemas operativos como de aplicaciones sensibles (servidor WEB, sendmail, servidor DNS, etc...).
Para finalizar, existen en la red varias listas de correo, grupos de NEWS, etc. que conviene monitorizar periódicamente. Las más interesantes son:
Referencias
[1] http://www.tis.com/docs/products/gauntlet/index.html
[2] ftp://ftp.cert.dfn.de/pub/tools/net/strobe
[3] ftp://ftp.win.tue.nl/pub/security/tcp_wrappers_7.4.tar.gz
[4] http://iss.net/iss
[5] ftp://ftp.win.tue.nl/pub/security/satan.tar.Z
[6] ftp://coast.cs.purdue.edu/pub/tools/unix/crack
[7] ftp://ftp.bellcore.com/pub/nmh/skey
[8] http://www.ifi.uio.no/pgp
[9] http://home.netscape.com/eng/ssl3/ssl-toc.html
[10] Mensaje a 
cert-advisory-request [at] cert [dot] org, con la direccion de e-mail en el
cuerpo del mensaje.
[11] Mensaje a listserv [at] netspace [dot] orgcon "subscribe bugtraq" en el cuerpo del
mensaje.
[12] Mensaje a linux-security-request [at] redhat [dot] com con "subscribe linux-security"
en el cuerpo del mensaje.
[13] Mensaje a majordomo [at] suburbia [dot] netcon "subscribe best-of-security" en el
cuerpo del mensaje.
[14] Mensaje a majordomo [at] greatcircle [dot] comcon "subscribe firewalls" en el cuerpo
del mensaje.
David Guerrero
Ministerio de Educación y Cultura
Subdirección Gral. de Tratamiento de la Información
david [at] mec [dot] es
Las transparencias de esta ponencia pueden ser consultadas en:http://www.mec.es/~david/papers/politicas/slides
![[Índice General]](../logopuente_boletin.gif){kind=small}