Firewalls software: Estudio, instalación, configuración de escenarios y comparativa

TRABAJO DE FIN DE CARRERA TÍTULO: Firewalls software: Estudio, instalación, configuración de escenarios y comparativa AUTOR: Mònica Ferrer Berbegal DIRECTOR: Marco Antonio Peña Basurto FECHA: 14 de enero de 2006 1 Título: Firewalls software: Estudio, instalación, configuración de escenarios y comparativa Autor: Mònica Ferrer Berbegal Director: Marco Antonio Peña Basurto Fecha: 14 de enero de 2006 Resumen Los usuarios de domicilios particulares y de las empresas disponen de un amplio abanico de comodidades que les permiten gestionar su trabajo a través de la red pública de Internet. Esto puede suponer un problema si no se cumplen ciertas medidas de seguridad y de control para evitar las violaciones de datos que se irrumpen en la red. La confidencialidad de los datos adquiere mayor importancia y dificultad de mantenimiento en el ámbito empresarial, donde la comunicación se establece entre la red privada de la empresa e Internet; así pues, este proyecto se enfoca concretamente en un escenario empresarial. Para garantizar un nivel de seguridad entre dos o más redes debe existir un sistema de aislamiento que evite comunicaciones indeseadas llamado Firewall. Por ello, este proyecto consiste en el estudio, la implementación y el análisis de tres tipos de Firewall sobre una Red Desmilitarizada o DMZ, en la cual se configuran los servicios más comunes que ofrece una empresa y que deberán ser protegidos por el Firewall para un acceso restringido. Los Firewalls se configuran con aplicaciones de distintos sistemas operativos: • Iptables bajo la distribución Debian Sarge de GNU/Linux. • ISA Server 2004 Enterprise bajo Windows Server 2003. • Packet Filter bajo OpenBSD Una vez hecha la implementación y el análisis de las ventajas e inconvenientes de cada uno de ellos se lleva a cabo un análisis de vulnerabilidades con la herramienta Nessus de los servicios de la DMZ, de modo que se pueda hacer un estudio más profundo de su efectividad. Llegados a este punto se establece una comparativa entre los tres y se analiza cuál de ellos es el más adecuado para según qué escenarios empresariales. Todo ello no quita que este proyecto también pueda servir de ayuda para la elección de uno u otro Firewall en una red doméstica. 2 Title: Firewalls software: Study, setup, settings configuration and comparative Author: Mònica Ferrer Berbegal Director: Marco Antonio Peña Basurto Date: 14 th January 2006 Overview HomePC users and office users have a wide range of facilities to manage their work through the public Internet Network. However, this can bring to the problem of data violation in Network, if any security and control measures are not taken. Major is the importance and the difficulty about data confidentiality in office environments to deal with it because the communication is established between the private company network and Internet. Therefore, this Project focuses in a company environment. To guarantee a certain level of security between two or more Networks, Firewalls must be employed to prevent from undesirable communications. This Project consists in the study, the implementation and the analysis of three Firewalls software in a Desmilitarizad Network, which contain common services used in the daily work of an enterprise. This services must be protected with a Firewall for a restricted access. Firewalls are set up with applications of diferent Operating Systems: • Iptables under Debian Sarge de GNU/Linux • ISA Server 2004 Enterprise under Windows Server 2003. • Packet Filter under OpenBSD. The procedure followed has been: Firstly, implementation and analysis of the advantages and disadvantages of each of them. Secondly, with the aim of extracting a deeper study on effectivity, it is done a vulnerability services analysis with Nessus tool. Finally, by the comparison and analysis of the three obtained results, conclude the work designing each Firewall its more efficient in office environments. Notwithstanding, that the above referred study and conclusions of Firewalls analysis could also be applied to a Home networks. 3 ÍNDICE 1. INTRODUCCIÓN...................................................................................................9 1.1 Motivación.......................................................................................................................... 9 1.2 Objetivos generales ........................................................................................................ 10 1.3 Planificación y análisis de costes.................................................................................. 12 1.4 Estructura de la memoria ............................................................................................... 16 2. FIREWALLS ............................................................................................................. 18 2.1 ¿Qué es un Firewall? ...................................................................................................... 18 2.1.1 Firewall de Software............................................................................................. 19 2.1.2 Appliances o “Firewalls físicos” ............................................................................ 19 2.2 Arquitecturas de Firewalls.............................................................................................. 20 2.2.1 Screened Host...................................................................................................... 20 2.2.2 Screened Subset o DMZ ...................................................................................... 21 2.2.3 Dual-Homed Host................................................................................................. 23 2.3 Políticas de seguridad .................................................................................................... 24 2.3.1 ¿Qué se entiende por política de seguridad? ...................................................... 24 2.3.2 Política de seguridad utilizada.............................................................................. 25 3. ATAQUES............................................................................................................ 28 3.1 Antes de un ataque ......................................................................................................... 28 3.2 Escaneo de puertos ........................................................................................................ 28 3.3 Negaciones de Servicio (DoS)........................................................................................ 29 3.3.1 Barridos PING ...................................................................................................... 30 3.4 Spoofing ........................................................................................................................... 30 3.5 Sniffing ............................................................................................................................. 30 3.6 Herramienta de escaneo de vulnerabilidades .............................................................. 30 3.6.1 Configuración de Nessus ..................................................................................... 31 3.6.2 Parámetros de las pruebas .................................................................................. 31 3.6.3 Estructura del informe de vulnerabilidades .......................................................... 32 4. ESCENARIO........................................................................................................34 4.1 Esquemas ilustrativos .................................................................................................... 34 4.1.1 Esquema funcional............................................................................................... 34 4.1.2 Esquema de direcciones ...................................................................................... 36 4.2 Descripción del escenario.............................................................................................. 37 4 4.3 Configuración de la red .................................................................................................. 38 4.3.1 Configuración con Debian Sarge ......................................................................... 38 4.3.2 Configuración en Windows 2003 Server.............................................................. 39 4.3.3 Configuración en OpenBSD 3.6 ........................................................................... 39 4.3.4 Configuración de la red del atacante.................................................................... 39 4.4 Servidor Web....................................................................................................................40 4.4.1 Servicio................................................................................................................. 40 4.4.2 Configuración ....................................................................................................... 40 4.5 Servidor de Correo.......................................................................................................... 41 4.5.1 Servicio................................................................................................................. 41 4.5.2 Configuración ....................................................................................................... 41 4.6 Servidor Secure Shell ..................................................................................................... 42 4.6.1 Servicio................................................................................................................. 42 4.6.2 Configuración ....................................................................................................... 43 4.7 Servidor FTP ....................................................................................................................43 4.7.1 Servicio................................................................................................................. 43 4.7.2 Configuración ....................................................................................................... 44 4.8 Servidor de Nombres DNS.............................................................................................. 44 4.8.1 Servicio................................................................................................................. 44 4.8.2 Configuración ....................................................................................................... 45 4.9 Servidor DHCP................................................................................................................. 46 4.9.1 Servicio................................................................................................................. 46 4.9.2 Configuración ....................................................................................................... 46 5. Firewall: Iptables sobre Debian Sarge.................................................................48 5.1 Seguridad en el Kernel.................................................................................................... 48 5.1.1 Paquetes ICMP .................................................................................................... 48 5.1.2 Información de Enrutamiento ............................................................................... 49 5.1.3 Deshabilitación Spoofing...................................................................................... 49 5.1.4 SYN cookies ......................................................................................................... 49 5.1.5 Martians................................................................................................................ 50 5.2 Descripción del Firewall con Iptables ........................................................................... 50 5.2.1 Cadenas ............................................................................................................... 50 5.2.2 Tablas................................................................................................................... 50 5.2.3 Sintaxis de las reglas............................................................................................53 5.2.4 Acciones para cada regla..................................................................................... 53 5.2.5 El entorno Iptables................................................................................................ 54 5.3 Configuración de las reglas del Firewall....................................................................... 55 5.4 Pruebas de vulnerabilidad.............................................................................................. 55 5.5 Valoración ........................................................................................................................ 62 6. Firewall: ISA Server 2004 Enterprise sobre Windows 2003 Server..................... 65 6.1 Descripción del Firewall ISA Server .............................................................................. 65 6.1.1 Arquitectura servidor ISA...................................................................................... 67 6.2 Configuración del Firewall..............................................................................................69 5 6.2.1 Publicación de un servidor ................................................................................... 70 6.2.2 Accesos a los arrays ............................................................................................ 72 6.3 Pruebas de vulnerabilidad.............................................................................................. 73 6.4 Valoración ........................................................................................................................ 79 7. Firewall: Packet Filter sobre OpenBSD 3.6 .........................................................82 7.1 Descripción del Firewall con Packet Filter ................................................................... 82 7.1.1 Sintaxis de las reglas............................................................................................82 7.1.2 Calidad de Servicio (QoS).................................................................................... 84 7.2 Configuración de las reglas del Firewall....................................................................... 85 7.3 Pruebas de vulnerabilidad.............................................................................................. 85 7.4 Valoración ........................................................................................................................ 91 8. BALANCE EN BASE AL ESTUDIO PRÁCTICO.................................................. 93 8.1 Análisis comparativo de los tres Firewalls................................................................... 93 8.2 Adecuación de los Firewalls según el escenario empresarial ................................... 96 9. CONCLUSIONES ................................................................................................ 98 9.1 Revisión de objetivos...................................................................................................... 98 9.2 Revisión de la planificación y costes............................................................................ 99 9.2.1 Planificación temporal .......................................................................................... 99 9.2.2 Análisis económico............................................................................................. 102 9.3 Líneas de trabajo futuro................................................................................................ 104 9.4 Conclusiones personales............................................................................................. 104 LEYENDA................................................................................................................... 107 GLOSARIO................................................................................................................. 108 BIBLIOGRAFÍA...........................................................................................................110 ANEXO I: POLÍTICA DE SEGURIDAD .......................................................................... 2 B. Política regida por el Firewall............................................................................................... 3 ANEXO II: FICHEROS DE CONFIGURACIÓN.............................................................. 4 A. Configuración de las redes................................................................................................... 4 A.1 CONFIGURACIÓN CON DEBIAN SARGE ................................................................. 4 A.2 CONFIGURACIÓN DE LAS REDES CON OpenBSD................................................. 6 B. Configuración de los servicios ............................................................................................ 7 6 B.1 CONFIGURACIÓN SERVIDOR DE CORREO. SENDMAIL ....................................... 7 B.2 CONFIGURACIÓN SERVIDOR FTP. PROFTPD........................................................ 8 B.3 CONFIGURACIÓN SERVIODR DNS. BIND ............................................................. 10 B.4 CONFIGURACIÓN SERVIDOR DHCP ..................................................................... 14 C. Configuración de los Firewalls........................................................................................... 14 C.1 CONFIGURACIÓN FIREWALL IPTABLES............................................................... 14 C.2 CONFIGURACIÓN FIREWALL ISA SERVER 2004 ENTERPRISE ......................... 20 C.3 CONFIGURACIÓN FIREWALL PACKET FILTER .................................................... 23 ANEXO III: TABLAS DE DETECCIÓN DE VULNERABILIDADES .............................. 25 A. Tabla de detección de vulnerabilidades Firewall Iptables .............................................. 25 B. Tabla de detección de vulnerabilidades Firewall ISA Server Enterprise 2004............... 30 C. Tabla de detección de vulnerabilidades Firewall Packet Filter........................................ 35 7 ÍNDICE DE ILUSTRACIONES Ilustración 2. Modelo de capas de la torre OSI.............................................................20 Ilustración 3. Arquitectura Screened Host ....................................................................21 Ilustración 4. Arquitectura de red perimetral (DMZ)...................................................... 23 Ilustración 5. Arquitectura Dual-Homed........................................................................ 24 Ilustración 6. Telnet al puerto FTP................................................................................29 Ilustración 7. Esquema funcional del escenario ........................................................... 35 Ilustración 8. Esquema de direcciones del escenario.................................................. 36 Ilustración 9. Resolución servidor DNS de la DMZ....................................................... 46 Ilustración 10. Flujo de paquetes a través de Iptables ................................................. 52 Ilustración 11. Análisis del tráfico de la red perimetral con Iptables............................. 57 Ilustración 12. Gráfica del porcentaje de riesgo en los servicios del host con Iptables 58 Ilustración 13. Gráfica de los servicios con agujeros de seguridad.............................. 59 Ilustración 14. Modelo de servidores ISA Server Enterprise en Array.........................68 Ilustración 15. Modelo de servidor ISA Server independiente (single Array) ..............69 Ilustración 16. Escenario implementado en ISA Server ............................................... 69 Ilustración 17. Publicación de un servidor con ISA Server........................................... 71 Ilustración 18. Regla publicación de un servidor con ISA Server................................. 71 Ilustración 19. Acceso a un array con ISA Server ........................................................ 73 Ilustración 20. Análisis del tráfico de la red perimetral con ISA Server ........................ 74 Ilustración 21. Gráfica del porcentaje de riesgo en los servicios con ISA Server......... 75 Ilustración 22. Análisis del tráfico de la red perimetral con Packet Filter...................... 86 Ilustración 23. Gráfica del porcentaje de riesgo en los servicios con Packet Filter ...... 87 Ilustración 24. Gráfica de los servicios con agujeros de seguridad.............................. 88 Ilustración 25. Planificación temporal real del Proyecto .............................................101 8 ÍNDICE DE TABLAS Tabla 1. Análisis de costes previstos............................................................................ 15 Tabla 2. Análisis del escaneo de puertos de la DMZ ................................................... 56 Tabla 3. Vulnerabilidades en el servidor Web con Iptables......................................... 60 Tabla 4. Vulnerabilidades en el servidor de correo con Iptables .................................. 60 Tabla 5. Vulnerabilidades en el servidor SSH con Iptables.......................................... 61 Tabla 6. Vulnerabilidades en el servidor FTP con Iptables ..........................................61 Tabla 7. Vulnerabilidades en el servidor DNS con Iptables..........................................62 Tabla 8. Análisis del escaneo de puertos de la DMZ con ISA Server .......................... 74 Tabla 9. Vulnerabilidades en el servidor WEB con ISA Server ....................................76 Tabla 10. Vulnerabilidades en el servidor de correo con ISA Server ...........................77 Tabla 11. Vulnerabilidades en el servidor SSH con ISA Server.................................. 78 Tabla 12. Vulnerabilidades en el servidor FTP con ISA Server.................................... 78 Tabla 13. Vulnerabilidades en el servidor DNS con ISA Server................................... 78 Tabla 14. Análisis del escaneo de puertos de la DMZ ................................................. 86 Tabla 15. Vulnerabilidades en el servidor WEB con Packet Filter................................88 Tabla 16. Vulnerabilidades en el servidor de correo con Packet Filter......................... 89 Tabla 17. Vulnerabilidades en el servidor SSH con Packet Filter ................................ 90 Tabla 18. Vulnerabilidades en el servidor FTP con Packet Filter................................. 90 Tabla 19. Vulnerabilidades en el servidor de FTP con Packet Filter............................ 91 15 Euros por unidad Euros totales Item Descripción Unidades HARDWARE Pentium IV clónico 4 850,00 € 3.400,00 € Switch 8 puertos 3 20,00 € 60,00 € Cable Ethernet 10Base-T. Par trenzado UTP cat 5. (unidad metro) 10 0,45 € 4,50 € Conector RJ-45 20 0,30 € 6,00 € Cd´s vírgenes 10 0,60 € 5,38 € Hardware Total 3.475,88 € SOFTWARE Windows 2003 Server con licencia 1 841,51 € 841,51 € ISA Server 2004 Enterprise 1 5.053,32 € 5.053,32 € Software Total 5.894,83 € MANO DE OBRA Ingeniero Técnico Euros por hora 724 15,00 € 10860,00 € COSTE TOTAL Coste total proyecto Proyecto global 20230,71 € Tabla 1. Análisis de costes previstos 16 1.4 Estructura de la memoria La memoria del proyecto se estructura en varios capítulos que se distribuyen de la siguiente manera: Es fundamental en cualquier proyecto, situar al lector aún sin haberse leído la memoria entera y para ponerle en contexto; por ello hacemos una introducción. En el apartado de Introducción (Capítulo 1) se explica el porqué del proyecto, las motivaciones que nos mueven a hacer toda esta labor y los objetivos a los que se quieren llegar. Además se debe dar unas pautas temporales y económicas sobre lo que va a costar llevar este proyecto a priori. Una vez leída esta parte el lector debe tener ya una idea concreta y bien formada del trabajo sin tener que leerse todo su contenido. A continuación, el Capítulo 0 se refiere con mayor detenimiento lo que es un Firewall, su taxonomía y las políticas de seguridad por las que se rigen. En este apartado lo que se pretende es facilitar la comprensión del concepto de Firewall, clave para el entendimiento de todo el proyecto. Una vez explicado de manera teórica el concepto de la temática principal del proyecto, describimos en un tercer Capítulo (Ataques) los diferentes modos de detectar un ataque, además de explicar algunos de los que utilizaremos en la práctica para comprobar el funcionamiento del Firewall que configuramos. A continuación, en el Capítulo 4 (Escenario) detallamos la configuración del escenario en el que nos encontramos; pues seguirá la misma estructura de una de las arquitecturas que ya habremos explicado en el Capítulo 2. De esta manera el lector puede ir entrelazando todo aquello que va leyendo e irse ubicando en todo el contexto del proyecto. Este capítulo consta de varios puntos: • Esquemas ilustrativos • Descripción del escenario • Configuración de la red • Servidores En el primer apartado mostramos el escenario en modo esquemático para un mayor entendimiento. A continuación explicamos las diferentes redes y elementos que forman parte del escenario. Un tercer apartado para desarrollar la configuración de la red siendo que intervienen tres subredes distintas. Finalmente en el apartado de Servidores describimos todos los servicios que va a disponer nuestra empresa y la configuración pertinente. Seguidamente, encontramos en tres capítulos distintos (Capítulo 5, 6 y 7 ) implementación de los tres Firewalls (Iptables, ISA Server 2004 Enterprise y Packet Filter) respectivamente. Todos ellos siguen una misma estructura que consiste en los siguientes puntos: 17 • Descripción del Firewall • Configuración del Firewall • Análisis de vulnerabilidades • Valoración del Firewall En este punto estudiamos más a fondo de cada uno de los Firewalls, puesto que teniendo el conocimiento teórico y la experiencia práctica podremos extrapolar conclusiones que describiremos en el punto de Valoración del Firewall. A continuación nos disponemos a detallar los puntos en base a los cuales hacemos la valoración del Firewall ya que son varios los factores que nos ayudan a hacer esta valoración. • Sistema Operativo: S.O sobre el que se trabaja. • Política de seguridad: Tenemos que tener en cuenta cual es la política por defecto del Firewall para modificarla si es necesario. • Configuración de las reglas: Describimos si la configuración es sencilla o compleja. • Tipo de filtrado: Cada Firewall se identifica por el nivel de filtrado que utiliza. • Calidad de Servicio: Determinamos cómo es capaz el Firewall de realizar si es posible priorizar de tráfico. • Características: Describimos más características encontradas en base al estudio teórico y práctico. • A modo de conclusión: Como resumen conclusivo. Para terminar el Capítulo 8. se centra en hacer un balance sobre las conclusiones en base al estudio práctico. Éste consta de dos apartados: • Análisis comparativo de los tres Firewalls • Adecuación de los Firewalls según el escenario empresarial En el primero extrapolamos las conclusiones en base a las valoraciones descritas de cada uno de los Firewalls. Mientras que en el segundo apartado presentamos posibles escenarios empresariales y hacemos un estudio sobre cual de los Firewalls sería el más adecuado. Seguidamente, en el Capítulo 9. se resumen las conclusiones alcanzadas en el proyecto, se revisa la planificación temporal y los costes y se apuntan algunas líneas futuras de investigación relacionadas con el estudio de estos Firewalls. Por último, en los anexos del proyecto se recogen los ficheros de configuración creados y las tablas de los análisis de vulnerabilidades. 18 2. FIREWALLS En este capítulo explicamos con mayor detenimiento lo que es un Firewall, su taxonomía y las políticas de seguridad por las que se rigen. El capítulo consta de varios apartados: • ¿Qué es un Firewall? • Arquitecturas de Firewalls • Políticas de seguridad 2.1 ¿Qué es un Firewall? Un Firewall o Cortafuegos es un sistema de seguridad de redes en el que se protege una máquina o subred de servicios que desde el exterior puedan suponer una amenaza a su seguridad. Dicho en otras palabras, es un sistema de aislamiento entre dos o más redes para evitar comunicaciones indeseadas. El Firewall actúa de filtro, de manera que examina todos y cada uno de los paquetes de información en base a unas reglas definidas. Es bajo una política de seguridad que decide qué paquetes puede aceptar, cuáles modificar o cuáles bloquear. Según como realice el filtrado, un Firewall puede configurarse de varios modos: • Firewall de filtrado de paquetes: Normalmente es un router que selecciona según las IPs y los puertos de salida. Éstos Firewalls trabajan a nivel de red. • Servidores Proxy: Trabajan a nivel de aplicación. Hay de dos tipos: o Proxy Caché. Transparentes + aplicación. Se mira a nivel de aplicación. o Proxy Socks: Filtrado a nivel de TCP (transporte). Un Firewall no tiene porque ser una sola máquina sino que se compone de varios elementos: • Bastion host. Máquina que debemos proteger. Se realiza el filtrado a nivel de aplicación y normalmente se conecta en la zona interior con la zona exterior. Es aquí donde se sitúan los servicios. • Choke. Filtro de paquetes. • Proxy Uno de los inconvenientes de los Firewalls es que no aíslan de los ataques de dentro de la misma red, por ello es conveniente utilizar Firewalls internos. Por ejemplo, para una gran empresa puede haber diferentes Firewalls para cada departamento y así hay mayor seguridad ante un daño generalizado. En cuanto a la taxonomía de Firewalls, existen dos grandes tipos de Firewall: • Firewall de software • Appliance 19 2.1.1 Firewall de Software Un Firewall de software es una aplicación que puede estar integrada en el mismo sistema operativo (Iptables y Packet Filter) o puede instalarse independientemente (ISA Server). Estos Firewalls se configurarán en base a la política de acceso que desee el usuario y su implementación dependerá de la dificultad que tenga el propio Firewall, de la velocidad de la máquina, de la memoria, etc. Las actualizaciones de los bugs de seguridad que van apareciendo deberán ser configuradas manualmente, que en según qué casos no es una tarea sencilla. A parte de estos Firewalls mencionados, existen los llamados Firewalls personales que son mucho más sencillos para uso doméstico. 2.1.1.1 Firewalls personales En las redes personales o conexiones permanentes domésticas, lo habitual es que el ordenador esté conectado directamente a Internet, de ahí la necesidad de un Firewall por software. Éstos Firewalls no son tan complejos como otras soluciones profesionales pensadas para empresas _los Firewalls que analizaremos en el proyecto_ pero en general cumplen bien con su cometido y son suficientes para la seguridad de un ordenador conectado a Internet o una red doméstica. Siendo que son unos Firewalls más limitados, su funcionalidad se basa en bloquear popup’s. 2.1.2 Appliances o “Firewalls físicos” Un Firewall físico o appliance es un sistema hardware y software cuya única función es la de implementar una política de acceso. A diferencia de los Firewalls de Software estos suelen estar ya preconfigurados, de tal manera que sólo sea necesario conectarlos en la red. A parte, a diferencia de los Firewalls de software las actualizaciones de bugs son automáticas. Un appliance bien equipado debe incluir la implementación NAT (Network Address Translation), DMZ (De-Militarized Zone), VPN (Virtual Private Network), detección de intrusos y un programa de auditoría con alarmas. 20 2.2 Arquitecturas de Firewalls Existen tres grandes tipos de Firewalls: • Firewalls de la capa de red o Screened Host o Screened Subnet • Firewalls de la capa de aplicación o Dual-Homed Host • Firewalls híbridos Éstos Firewalls tienen claras diferencias lo que no significa que uno sea mejor que otro, puesto que cada uno de ellos es apropiado para un entorno específico. Lo que los diferencia unos de otros es el mecanismo que utiliza para dejar pasar el tráfico de una zona a otra. El modelo de International Standards Organization (ISO) Open Systems Interconnect (OSI) define siete capas, donde cada una de ellas proporciona los servicios que capas superiores requieren de ellos. Ilustración 2. Modelo de capas de la torre OSI Es importante tener en cuenta que cuanto más bajo sea el nivel al que pertenece el mecanismo de forwarding, menos sofisticada será la inspección del paquete, con lo cual estos Firewalls serán más rápidos pero más sensibles ante una amenaza. Hoy en día existen los Firewalls híbridos que hacen el filtrado por red y algunas inspecciones a nivel de aplicación cuya examinación del paquete dependerá del vendedor, del producto, del protocolo y la versión. 2.2.1 Screened Host Este tipo de cortafuegos pertenece al grupo perteneciente a la capa de red, de manera que filtra por direcciones origen y destino, por protocolo o por puertos origen y destino; es decir parámetros de la capa TCP/IP. 21 La arquitectura con la que se forma combina un router con un host bastión donde el principal nivel de seguridad proviene del filtrado de paquetes (Packet Filter), es decir, el router es la primera y más importante línea de defensa. En la máquina bastión, único sistema accesible desde el exterior, se ejecutan los proxies de las aplicaciones, mientras que el choke se encarga de filtrar los paquetes que se puedan considerar peligrosos para la seguridad de la red interna, permitiendo únicamente la comunicación con un número reducido de servicios. Esta arquitectura está cada vez más en desuso debido a que presenta dos puntos únicos de fallo, el choke y el bastión: si un atacante consigue controlar cualquiera de ellos, tiene acceso a toda la red protegida; por tanto, es más recomendable una arquitectura de red perimetral, de la que vamos a hablar a continuación. Ilustración 3. Arquitectura Screened Host 2.2.2 Screened Subset o DMZ De la misma manera que la arquitectura anterior Screened Subnet red perimétrica pertenece al grupo de Firewalls que filtran según el nivel de red. La red perimétrica también conocida como De-Militarized Zone o Screened Subnet, es la más utilizada e implantada hoy en día. Ésta añade un nivel de seguridad en las arquitecturas de cortafuegos situando una subred (DMZ) entre las redes externa e interna, de forma que se consiguen reducir los efectos de un ataque exitoso: como hemos venido comentando, en los modelos anteriores toda la seguridad se centraba en el bastión, de forma que si la seguridad del Router Choke Bastion Firewall 22 mismo se veía comprometida, la amenaza se extendía automáticamente al resto de la red. Como la máquina bastión es un objetivo interesante para muchos piratas, la arquitectura DMZ intenta aislarla en una red perimétrica de forma que un intruso que accede a esta máquina no consiga un acceso total a la subred protegida. Este tipo de arquitectura es con la que nos disponemos a trabajar, pues la seguridad se ve aumentada si se diseñan redes perimétricas o DMZ protegidas por Firewalls. Con este tipo de arquitectura los servicios de acceso al público y por lo tanto los servidores donde están configurados se encuentran protegidos por un Firewall externo o bastion y la red interna por un Firewall interno o de contención. Si ponemos los servidores en la red interna, sabiendo que pueden acceder usuarios de la red externa es mucho más fácil que haya un agujero que permita al usuario de la red externa entrar en el sistema de la red interna. Pues lo que sí puede suceder es que haya un acceso no autorizado a uno de los servidores localizados en la DMZ. A parte podría ocurrir que un intruso coloque una herramienta de monitorización de red o sniffer, lo cual provocaría que los paquetes IP que pasen de la red DMZ a la red interna fueran capturados y analizados, permitiendo al intruso conseguir información para poder hacer un ataque a la red interna. Este modelo se puede diseñar en dos modos distintos: • Dos Firewalls, cada uno con dos adaptadores de red instalados. El Firewall externo que comunica la DMZ y uno interno que comunica la DMZ con la red interna. • Un sólo Firewall, con tres adaptadores de red (nuestro caso); con el que se comunica la red externa, la zona desmilitarizada y la red interna. 23 Ilustración 4. Arquitectura de red perimetral (DMZ) 2.2.3 Dual-Homed Host Este modelo de Firewall perteneciente al grupo de filtrado a nivel de aplicación está formado por máquinas equipadas con dos o más tarjetas de red y en las que una de las tarjetas se suele conectar a la red interna a proteger y la otra a la red externa a la organización. En esta configuración el choke y el bastión coinciden en el mismo equipo. El sistema debe ejecutar al menos un servidor proxy para cada uno de los servicios que deseemos pasar a través del Firewall y también es necesario que el IP Forwarding esté deshabilitado en el equipo, pues aunque una máquina con dos tarjetas puede actuar como un router para aislar el tráfico entre la red interna y la externa es necesario que el choke no enrute paquetes entre ellas. Así, los sistemas externos `verán' al host a través de una de las tarjetas y los internos a través de la otra, pero entre las dos partes no puede existir ningún tipo de tráfico que no pase por el Firewall. Por otra parte, el hecho de que haya un Proxy existirá una aplicación de software que permitirá un amplio número de procesos de carga y de control de acceso, lo que obliga un filtrado mucho más elaborado y consecuentemente un mayor tiempo de carga. Choke 1 Choke 2 DMZ 24 El tráfico cruzará de una red a la otra después de un “enmascaramiento” efectivo de la conexión inicial. Los Firewalls a nivel de aplicación permiten un refuerzo en la seguridad debido a una auditoría mucho más detallada que los Firewalls de nivel de red. Ilustración 5. Arquitectura Dual-Homed 2.2.3.1 Proxy Server Un Proxy Server (a veces referido a una aplicación gateway o de reenvío) es una aplicación que controla el tráfico entre una red protegida e Internet. Muy a menudo, los proxies sustituyen los routers de control de tráfico para prevenir el tráfico que pasa directamente entre las dos redes. Además muchos proxies contienen soporte adicional para la autenticación de usuarios. Desde que los proxies tienen la capacidad de controlar el protocolo de aplicación que se utiliza pueden implementar una seguridad específica para ese protocolo (por ejemplo un Proxy FTP debe estar configurado para permitir el tráfico FTP de entrada y bloquear el de salida). 2.3 Políticas de seguridad 2.3.1 ¿Qué se entiende por política de seguridad? Todo Firewall, sea del tipo que sea, se rige por una política de seguridad definida previamente a su configuración. Cuando hablamos de política de seguridad nos referimos a tener una directiva predeterminada y una colección de acciones a realizar en respuesta a tipos de mensajes específicos. Cada paquete se compara, uno a uno, con cada regla de la lista hasta que se PC Bastion Choke Proxy 31 Los ataques que vamos a realizar van a ser contra la red perimetral, concretamente con la máquina donde se ubican todos los servidores. El ataque lo haremos a la IP pública de la DMZ porque es ésta la que conocerá el atacante (192.168.16.214). De este modo podremos ver no sólo los puertos que están o no habilitados sino también las vulnerabilidades de los servicios que hay detrás. Para hacer todas estas pruebas utilizaremos la herramienta Nessus 2.2.4 sobre un sistema operativo GNU/Linux Knoppix 3.9. 3.6.1 Configuración de Nessus Nessus es uno de los auditores de seguridad más potentes ya que es una herramienta modular y extensible con mucha versatilidad. Esta aplicación no es tan sólo un escaneador de puertos sino que también detecta las vulnerabilidades que hay en los servicios detrás del Firewall. Entre otras muchas cosas, esta herramienta trata de abrir los puertos y busca qué versión del servicio está funcionando, para luego ofrecer recomendaciones para atajar cualquier vulnerabilidad que pueda tener el servicio. Para configurarlo debemos primero crear un usuario: nessus-adduser con su login y password y a continuación activamos el daemon. /usr/sbin/nessus start Posteriormente se configura la parte cliente indicando el servidor (el propio localhost) y el puerto al que se va a conectar #1241; y nos autenticamos. Una vez se ha establecido la sesión se puede empezar a configurar las características de las pruebas que se van a llevar a cabo. 3.6.2 Parámetros de las pruebas Para efectuar los ataques con la herramienta Nessus, hemos habilitado todos los plugins disponibles (FTP. CISCO, DoS, Firewalls, General, SNMP, Windows, etc). Como opciones de escaneo hemos designado un rango de puertos amplio que englobe todos los servicios más comunes (1-8000) pues las herramientas que utiliza Nessus para el escaneo son las siguientes: • Scan for LaBrea tarpitted hosts Esta herramienta detiene los ataques de gusanos mediante una “trampa virtual” impidiendo que se extienda. Los servidores que tengan instalado este software simulan la presencia de una máquina que posee las características propias de un sistema vulnerable. Aunque realmente no existe ésta máquina puede ser detectada por escaneadores de puertos, sniffers y otras herramientas de 32 hacking. Cuando un hacker intenta conectarse a ella, esta ”trampa virtual” bloquea su conexión. • Nessus TCP Scanner Realiza un análisis de los puertos del host, una vez se establece la conexión obtiene los banners de los servicios para los plugins de identificación de servicios. • SYN Scan Se realiza un análisis de las direcciones IP destino teniendo en cuenta el RTT (Round Trip Time), que será el tiempo total de ida y vuelta de los paquetes que lanza el host de Nessus hasta el host remoto. • Exclude toplevel domain wildcard host Verificamos que se lanza Nessus contra un dominio de primer nivel. • Nmap (NASL Wrapper). Es la herramienta Nmap en formato Nessus Attack Scripting Language. Las opciones de esta herramienta son varias y las que rigen nuestros chequeos son las siguientes: o Xmas Bree Sian que envía los paquetes con los flan FIN, URG, y PUSH activados. o UDP port scan o Service scan o RPC port scan o Identify the remote OS o Fragmented IP packets (bypasses firewalls) o Get identd info Por otra parte todas nuestras pruebas estarán sometidas a un escaneo AGRESIVO. • Netstat ‘scanner’ Con este plugin Nessus hará un Netstat para ver los puertos que tiene abiertos el sistema. En nuestro caso no hemos habilitado ni el SYN Scan ni el Nessus TCP Scanner porque la funcionalidad de estos la incluye el plugin de Nmap. 3.6.3 Estructura del informe de vulnerabilidades Nessus nos ofrece los informes en varios formatos, siendo que el más completo es en formato HTML más gráficos más gráficos es con el que vamos a trabajar. Para estudiar las vulnerabilidades de cada Firewall seguiremos las mismas pautas que sigue el informe de Nessus. 33 En primer lugar adjuntaremos una tabla a modo resumen de los servicios que Nessus detecta en la red junto con el tipo de mensaje que tiene sobre vulnerabilidad para cada uno de ellos. Tabla de servicios del host A continuación añadiremos las estadísticas de seguridad extraídas por la aplicación en modo gráfico, pues incluiremos tres gráficas: • Una gráfica de barras en la que se muestra el tráfico que hay en la red del host, que viene dada a través del escaneo de puertos Nmap comprobando así cuáles son los que tiene habilitados la máquina a través del Firewall. Gráfica del tráfico en la red • A continuación podemos ver una gráfica de disco (Gráfica de los riesgos de seguridad) en la que Nessus nos muestra el porcentaje de información de riesgo a través de una escala de tres niveles: o Bajo o Medio o Alto • En el caso de que haya un porcentaje de alto riesgo provocado por algún agujero de seguridad, Nessus crea una gráfica en la que muestra qué servicio o servicios generan el problema de seguridad. Gráfica de bugs Finalmente, Nessus genera una tabla en la que describe las vulnerabilidades de cada servicio según dos tipos de mensajes: o Bugs o Agujeros de seguridad. Security holes (riesgo de seguridad alto) o Avisos de seguridad. Security Warnings (riesgo de seguridad medio) o Notificaciones de seguridad (riesgo de seguridad bajo) Esta misma la adjuntaremos en el Anexo III además, de analizarla en los Firewalls pertinentes. 34 4. ESCENARIO En este capítulo definimos la configuración del escenario en el que nos encontramos; por ello describimos cada una de las máquinas y dispositivos que forman parte del escenario, el software que disponen y los servicios que implementamos en cada una de las redes, junto con la configuración pertinente. De esta manera, la estructura del capítulo es la siguiente: • Esquemas ilustrativos • Descripción del escenario • Configuración de la red • Servidores 4.1 Esquemas ilustrativos Para un mejor entendimiento, nos disponemos a ver en modo gráfico el escenario en el que vamos a realizar todas las pruebas. 4.1.1 Esquema funcional Como hemos explicado en el anteriormente, vamos a diseñar una red perimetral, ya definida en el apartado 2.2.2. 35 De manera ilustrativa, nuestro escenario sigue el siguiente esquema Ilustración 7. Esquema funcional del escenario 36 DMZ 4.1.2 Esquema de direcciones El esquema de direccionamiento IP y las interfaces de cada una de las máquinas es el siguiente: Ilustración 8. Esquema de direcciones del escenario FIREWALL : Iptables ISA Server Packet Filter 192.168.16.66 192.168.16. X Switch Belkin 192.168.100.1 192.168.100.2 eth1 eth2 192.168.200.1 RED EXTERNA RED INTERNA eth3 Netgear FS524 3Com Super Slack Servidor DHCP 192.168.200.2 Servicios: Web Correo DNS FTP SSH Servidor DHCP Trendnet TE100 DMZ Medion 192.168.16. X ATACANTE 37 4.2 Descripción del escenario Como podemos observar en las dos ilustraciones y siguiendo el esquema clásico de una arquitectura perimetral, nuestro escenario consta de varias subredes: Red Externa (192.168.16.0/24) Es la que nos conecta directamente a la red pública de Internet atravesando la una máquina que hace de gateway cuya IP es 192.168.16.66. A parte, como podemos ver en la Ilustración 8. es en esta misma red desde la que se conectará el intruso para hacer los ataques a nuestra red interna y a la DMZ; pues simulamos que es “la red pública” a pesar de su direccionamiento privado. Red Interna (192.168.100.0/24) La interfaz 1 del Firewall (192.168.100.1) es la entrada a la red interna, la cual está formada por una sola máquina, la de Medion 192.168.100.2, que actuará también como servidor de DHCP. El motivo por el que ubicamos este servidor en este punto es porque lo que se quiere es poder tener un servidor que ofrezca única y exclusivamente IPs a máquinas de la red interna, sin tener la necesidad de que alguien de fuera pueda acceder a este servidor. Ambas máquinas se conectan a través del switch Belkin, así podríamos conectar más máquinas que formen la LAN privada, las cuales obtendrán una dirección IP de manera dinámica. Red Desmilitarizada o Perimetral (192.168.200.0/24) Una tercera subred será la que la forme la máquina de la DMZ junto con el switch Trendnet. De esta manera en un futuro siempre se pueden conectar más máquinas que ofrezcan otro tipo de servicios. La DMZ es una zona neutral en la que un cliente podrá acceder a los servicios de la empresa sin entrar en la red interna y peligrar su integridad. Además será accesible para los miembros de la empresa de la propia red interna; pero en contrapartida desde la red perimetral no se podrá conectar a la red interna ya que podría ser un bug para los atacantes. En este punto es donde situamos l os servicios de la empresa que a nosotros en particular nos interesa que sean accesibles desde el exterior, lo que lo diferencia de situarlos en la propia red interna, que únicamente tendrán acceso los trabajadores. Así pues los servicios que se ofrecen son los siguientes: 38 La página Web de la empresa, para que cualquier cliente o persona interesada pueda ver las posibilidades que le ofrece nuestra empresa. El servidor de correo. En una empresa no todos los trabajadores se ubican siempre en el mismo lugar de trabajo, ya sea porque debe ir a casa del cliente, por tener que ir a otras sedes de la empresa, etc. Por eso, es importante que el trabajador pueda mantenerse al corriente de todo lo sucedido vía mail y así estar en constante comunicación. Es por eso que el servidor de correo interno se encuentra en esta misma subred, para que pueda ser consultado desde la red externa. Por otra parte, habilitamos los servicios de conexión remota mediante la aplicación Secure Shell; pues también es útil el poderse conectar remotamente a los servidores; eso sí en este caso, únicamente a personal autorizado desde el propio Firewall o la red interna. Además, en este punto instalamos el servidor de ficheros FTP para la descarga de ficheros que puedan ser de interés público. Finalmente, otro de los servicios necesarios es el servidor de resolución de nombres DNS, el cual asocia una IP con un nombre de host; Pues es aquí donde le damos un “nombre canónico” al dominio del correo interno “@tfc.es” y a la página web de la empresa www.tfc.es. (Véase 4.8 Configuración Servidor DNS) 4.3 Configuración de la red Una vez ilustrado el escenario que se va a diseñar y conociendo todos los dispositivos que se usan en la implementación describiremos la configuración de red que se ha llevado a cabo. 4.3.1 Configuración con Debian Sarge Los sistema Unix disponen de un daemon para cargar la red y éste se configura en el /etc./network/interfaces que podemos ver descrito en el Anexo II-A.1. Además se adjunta la tabla de encaminamiento de cada una de las máquinas. Para comprobar la conectividad hemos hecho un ping a los correspondientes gateways de cada una de las subredes. Claro que entre diferentes subredes aún no se conectan ya que no se ha configurado la herramienta que traduce las IP’s. 39 4.3.2 Configuración en Windows 2003 Server La configuración con Windows 2003 Server es mucho más simple que en un sistema Unix pues se configura de la misma manera que en un Windows clásico para usuarios. Para establecer la conectividad entre las tres redes, nos dirigimos a cada una de las tarjetas de red y configuramos la IP, la máscara, la puerta de enlace y los servidores DNS. Todo ello se encuentra en el Panel de control en Conexiones de Red. A parte, añadimos una ruta en la tabla de enrutamiento para definir la puerta de enlace a la red externa (192.168.16.16) como gateway predeterminado. route add 0.0.0.0. mask 0.0.0.0 192.168.16.66 metric 1 De la misma manera que con la distribución de Debian, con los paquetes ICM comprobamos la conectividad. 4.3.3 Configuración en OpenBSD 3.6 La configuración de red en el sistema BSD es ligeramente distinta a la configuración de un sistema GNU/Linux. Para empezar debemos crear para cada tarjeta de red un archivo que incluirá la IP, la máscara y distintas opciones. El archivo se edita en el directorio /etc con el nombre hostname.if. Éstos seguirán la siguiente estructura: inet IP netmask OPTIONS Para ello hemos editado los tres archivos correspondientes a cada una de las tarjetas de red que conectarán las tres subredes (véase Anexo II-A.2). 4.3.4 Configuración de la red del atacante Como ya hemos comentado en la descripción de las redes, nuestra máquina intrusa formará parte de la red pública, por ello se le asignará una IP de forma dinámica del servidor DHCP gateway de nuestra red externa 192.168.16.66. Paralelamente, para ver la conectividad entre subred y subred debemos añadir dos rutas en la tabla de encaminamiento para que los paquetes con destino alguna de las redes interna o DMZ tengan como gateway nuestro Firewall y no el gateway a la red externa (192.168.16.66). route add 192.168.200.0 mask 255.255.255.0 192.168.16.214 metric 1 40 route add 192.168.100.0 mask 255.255.255.0 192.168.16.214 metric 1 4.4 Servidor Web 4.4.1 Servicio La aplicación utilizada para publicar el servidor Web de la empresa es el servidor Apache. El porqué de esta elección se debe a que este servidor es de libre distribución con un uso superior al 50% y ha servido y sigue sirviendo de referencia para muchos de los servidores comerciales que existen actualmente. Siendo un servidor muy completo, no nos hemos dedicado a hacer un estudio profundo sobre sus capacidades, pues tampoco es el objetivo del trabajo, sino que nos hemos limitado a hacer una configuración básica. 4.4.2 Configuración Para configurar el servicio hemos seguido los siguientes pasos: Primero nos descargamos el paquete mediante el comando: apt-get install apache A continuación hemos modificado el fichero /var/www/index.html para escribir lo que queríamos que apareciera en la IP PÚBLICA de nuestro servidor, que se encuentra en la DMZ. Finalmente hemos arrancado el servicio con el comando: /etc/init.d/apache restart Para comprobar que el proceso se está ejecutando hemos hecho un netstat –ln para ver que el daemon de Apache está escuchando por el puerto 80 (puerto del servicio Web) para cualquiera de las interfaces. A continuación hemos accedido link de nuestra máquina-servidor Web y nos ha aparecido su contenido. Una vez configurado el servidor DNS, la IP para acceder al servidor Web pasa a tener un nombre de host asociado (www.tfc.es). 47 servidor DNS asignado a esta red; el cual será el ubicado en la DMZ de la empresa (192.168.200.2). Véase Anexo II-B.4 Cabe decir, que si tuviésemos más máquinas y fuera de nuestro interés, se podría especificar para una dirección MAC a IP determinada. Una vez escrito el fichero de configuración arrancamos el servicio desde el directorio /etc/init.d en el que se carga de nuevo el sistema. /etc/init.d/dhcp start Finalmente para comprobar el buen funcionamiento del servidor, conectamos una máquina a la subred 192.168.100.0 (switch Trendnet) y teniendo la aplicación de dhcp cliente, vemos que dispone de una IP, un gateway y un servidor DNS de esa red. 48 5. Firewall: Iptables sobre Debian Sarge Una vez situados en todo el contexto del Proyecto empezamos a estudiar el primer Firewall software basado en Iptables con la distribución Debian Sarge del sistema operativo GNU/Linux. En este capítulo desarrollaremos todo el estudio teórico y práctico que se ha hecho para la configuración y el análisis del Firewall. En primer lugar describimos las herramientas de seguridad que nos ofrece el núcleo del sistema operativo GNU/Linux (Kernel). A continuación estudiamos la herramienta Iptables a nivel teórico para luego poder configurar las reglas que definen nuestro Firewall con las pertinentes pruebas que verifican el correcto funcionamiento. Llegados a este punto hacemos un estudio de vulnerabilidades de los servicios que se sitúan detrás del Firewall para ver cómo éste actúa y así luego poder hacer un análisis de los resultados. El capítulo consta de varios apartados: • Seguridad en el Kernel • Descripción del Firewall con Iptables • Configuración de las reglas del Firewall • Pruebas de vulnerabilidad • Valoración . 5.1 Seguridad en el Kernel La distribución de Linux que usamos es la estable de Debian Sarge ya que nos garantiza mayor seguridad. Antes de sumergirnos en la herramienta de las Iptables podemos establecer ciertos parámetros del Kernel que nos ayudan a incrementar la seguridad ante los ataques explicados en el Capítulo 3. Accediendo a /proc/sys/net/ipv4 nos detenemos en los siguientes parámetros: 5.1.1 Paquetes ICMP Como hemos descrito en el Capítulo 3. donde definimos los posibles ataques, una de las violaciones de servicio más comunes es la de los barridos ICMP. Además, los paquetes ICMP echo pueden ser una herramienta de gran utilidad para cualquier atacante y con este comando se evita una respuesta a estos pings de manera que la máquina aparece como invisible. 49 • icmp_echo_ignore_all=1 De la misma manera para los paquetes broadcast. • icmp_echo_ignore_broadcasts=1 5.1.2 Información de Enrutamiento En IP source routing, cada paquete contiene la información del camino a seguir hasta llegar al host de destino. El peligro reside en que de acuerdo con el RFC 1122, el camino de ida debe ser el mismo que el de vuelta y si un intruso envía un paquete source routing podrá saber por qué hosts de nuestra red interna pasará; por ello deshabilitamos el parámetro correspondiente. • conf.eth#.accept_source_route=0 5.1.3 Deshabilitación Spoofing Haciendo referencia a los ataques de Spoofing del Capítulo 3, Kernel nos ofrece la posibilidad de deshabilitarlo con el parámetro de configuración Reverse Path Filtering: • conf.eth#.rp_filter=1 De esta manera verificamos en la tabla de encaminamiento que para cada interfaz no se estén recibiendo paquetes de direcciones origen no legítimas. 5.1.4 SYN cookies El ataque DoS por excelencia es el ataque SYN Flood y puede ser evitado utilizando las SYN cookies que es un método que consiste en continuar aceptando peticiones cuando la cola SYN está llena. Esto se consigue generando unos pequeños paquetes de información, las cookies, que contienen información sobre las cabeceras TCP de los paquetes recibidos, denegando así los paquetes originales. Aún así, el activar las SYN cookies no puede proporcionar inmunidad contra ataques DoS, especialmente cuando el ancho de banda atacante es más importante del que puede gestionar el servidor. Por otra parte es una opción muy recomendada el activar éste parámetro especialmente en la implementación de la pila TCP/IP de Linux, enfocada en el rendimiento y no en la seguridad. El parámetro a modificar es: • net.ipv4.tcp_syncookies=1 50 5.1.5 Martians Habilitamos que se guarde en el registro log los paquetes que hayan sido “esnifados” de source_route (Véase apartado 5.2). • net.ipv4.conf.eth#.log_martians= 1 Donde # es el número de interfaz. En nuestro caso lo habilitamos para todas. 5.2 Descripción del Firewall con Iptables La aplicación de filtrado más utilizada con Linux es Netfilter cuya herramienta de trabajo es Iptables. Es un sistema de Firewall vinculado al Kernel de Linux, integrado en él. Funciona en base a unas reglas que permitirán bloquear o modificar la salida y entrada de todos los paquetes. Si hacemos referencia a la torre OSI este Firewall realiza el filtrado a nivel de red (IPv4 o IPv6) y de transporte (TCP, UDP, ICMP). Para ponerlo en funcionamiento se ejecuta el comando Iptables en el que creamos las reglas; por eso, podemos definir un Firewall de Iptables como un simple script de shell en el que se van ejecutado las reglas. La manera de administrar el conjunto de condiciones por las que queremos que se rija nuestro Firewall es mediante las cadenas, donde éstas a su vez de agrupan en tablas. 5.2.1 Cadenas Cuando hablamos de cadenas, nos referimos a una lista de reglas agrupadas lógicamente. Cada regla de una cadena es una prueba que aplicar contra la cabecera de una IP para buscar su correspondencia. Las cadenas contienen reglas que están numeradas a partir de uno. Se puede referir o bien por la especificación de regla o bien por el número de regla. Una especificación de regla es el conjunto de condiciones que tiene que tener un paquete; pues la misma regla básica puede existir en múltiples cadenas (INPUT/OUTPUT y FORWARD) como explicaremos en el siguiente punto; por eso el parámetro cadena es obligatorio. 5.2.2 Tablas Netfilter se define por tres tipos de tablas: • Tabla filter: Actúa como filtro de paquetes 51 • Tabla mangle: Altera los paquetes • Tabla NAT: Traduce direcciones de red La tabla filter es la que se utiliza por defecto. Dispone de tres cadenas distintas para diferenciar el tráfico de entrada, el de salida y el que se enruta por el propio Firewall: • INPUT: Se definen las reglas de los paquetes recibidos para nuestro sistema • OUTPUT: Son las reglas de los paquetes que se generan en nuestro servidor local y son enviados. • FORWARD Definida para los paquetes que vayan a ser enrutados. Dado que los paquetes irán a una de las cadenas INPUT o FORWARD (pero no a ambas), cualquier regla que quiera aplicar igualmente a ambas tendrá que residir en las dos cadenas. La tabla mangle, no muy utilizada se usa para alterar o modificar los bits de tipo de servicio (TOS) del encabezado del paquete IP. De la misma manera, consta de dos cadenas: • PREROUTING: Para alterar los paquetes entrantes antes de enrutar. • POSTROUTING: Para alterar los paquetes generados localmente antes de enrutar. Esta tabla permite marcar los paquetes para poder ofrecer QoS con un módulo adicional pero no para priorizar dentro de la propia configuración de Iptables. Así pues esta tabla consta de tres parámetros de marca: o TOS (Type of Service): Se utiliza para identificar el tipo de servicio del paquete. Es útil en el momento que se hace un control de policía en cuanto cómo se debe enrutar el paquete, así pues se necesita el paquete iproute2 1 para hacer estas funciones de enrutamiento. o TTL (Time to live): Parámetro que se utiliza para cambiar el valor del TTL de determinados paquetes que no interesan que tengan un tiempo de vida largo. o MARK: Esta marca se utiliza cuando se quieren hacer limitaciones de ancho de banda para determinado tráfico con el algoritmo CBQ 2 (Class Based Queueing). Del mismo modo que en los dos parámetros anteriores, se utilizará únicamente será considerada por iproute2. 51 1 Módulo que permite el manejo de múltiples tablas de enrutado y soporta controles de policía de enrutado de acuerdo con las marcas en los paquetes. 2 Algoritmo de formación de colas que divide el ancho de banda de una conexión de red entre varias colas o clases. A cada cola se le asigna un tráfico basándose en la dirección de origen o de destino, el número de puerto, protocolo, etcétera. 52 En cuanto a la tabla NAT o MASQUERADING permite añadir una conversión de IP privada a pública o al revés donde se usarán las dos cadenas adicionales, POSTROUTING y PREROUTING, que vienen definidas por el mismo criterio explicado en las cadenas de la tabla mangle. Éstas se usan con DNAT y SNAT (destino y fuente NAT). Para entenderlo mejor, se puede pensar en que estas dos cadenas se encuentran fuera de la máquina, de modo que podemos imaginar que la conversión se hace justo antes de que el paquete llegue a la interfaz de entrada o salida. En modo gráfico se ve de la siguiente manera: Ilustración 10. Flujo de paquetes a través de Iptables Todos los paquetes fluyen de izquierda a derecha y pasan a través de la cadena INPUT o la cadena FORWARD, pero nunca por ambas a la vez. Cuando un paquete llega a un interfaz, primero llega a la cadena PREROUTING (si existe). Aquí las direcciones de destino se cambian (DNAT) para indicar otro servidor diferente. Si por ejemplo, el tráfico al puerto 80 del servidor local se va a mandar a un servidor interno, el destino se cambia aquí. El paquete llega entonces a la interfaz y el Kernel hace la búsqueda en la tabla de encaminamiento para ver a dónde tiene que ir el paquete (al servidor local o a otra interfaz). Entonces el código de Netfilter toma el paquete basándose en su destino (servidor local o interfaz de salida) y ejecuta la cadena INPUT o la FORWARD. Si el paquete pasa por la cadena FORWARD y no se rechaza, se le vuelve a pasar por la tabla de encaminamiento del Kernel y se le envía a la interfaz apropiada. Mientras el paquete sale de la interfaz, Netfilter hace pasar el paquete otra vez por las reglas de POSTROUTING. Todos los paquetes que vienen o van experimentar el mismo proceso básico. El proceso también se aplica a paquetes que utilicen la interfaz de servidor local, que pasan por las reglas INPUT y OUTPUT. 53 5.2.3 Sintaxis de las reglas La sintaxis básica a la que responden todas las reglas para definir los paquetes es la siguiente: iptables [-t tabla] cadena regla [opciones] Donde: • [–t tabla] es el tipo de tabla si es filter, NAT o mangle. • La cadena (INPUT, OUTPUT, FORWARD...) • A continuación se escribe la regla que se quiere definir, pues viene en función de lo que el administrador desee configurar. Se basa en unos parámetros como son el protocolo del paquete (-p), el puerto destino (- dport) u origen (-sport), etc. • Finalmente, como [opciones] aparecen una serie de parámetros que se pueden definir como por ejemplo añadir una regla (--append), borrar una cadena (--delete), definir la política de la cadena (--policy), listar las regla de una cadena (--list),etc. Entre todas ellas, hay una opción llamada (-- jump) con la que podemos especificar la acción que se va a llevar a cabo con esa regla. Mediante el comando de ayuda: man iptables se puede visualizar con mayor detalle todas las posibilidades que nos ofrece esta herramienta. 5.2.4 Acciones para cada regla Como hemos podido ver en el anterior apartado 5.2.3, cada una de éstas describen las características del paquete diciendo el tipo de protocolo, la interfaz de salida o de entrada, la IP origen o destino, etc; es decir existen una serie de parámetros con los que definir la regla, [opciones]; pero a parte debemos especificar el objetivo de esa regla. Hay varias acciones que se pueden ver explicadas en el manual de iptables, pero queremos hacer destacar cuatro de ellas debido a su uso: • ACCEPT: El paquete se acepta y sale de la cadena INPUT • DROP: El paquete se descarta • LOG: Permite que los paquetes con los que se ha establecido una correspondencia sean registrados. (Útil para registrar ataques maliciosos). • REJECT: Se envía un paquete ICMP de rechazo. La principal diferencia entre el modo DROP y REJECT es que cuando se rechaza un paquete, éste se descarta y se devuelve un mensaje de error ICMP al remitente. En cambio, cuando se deniega un paquete, simplemente se descarta el paquete sin ningún tipo de notificación al remitente. 54 La denegación es casi siempre la mejor elección, debido a tres razones: Primero, enviar una respuesta de error duplica el tráfico de red. La mayoría de los paquetes se descartan porque son malévolos, no porque representen un intento inocente de acceder a un servicio que no se le ha ocurrido ofrecer. Segundo, cualquier paquete al que responda se puede usar en un ataque por denegación de servicio. Como tercera y última razón, cualquier respuesta, incluso un mensaje de error ofrece información potencialmente útil a quien podría ser un hacker. Por todo ello, adoptamos la política regida por DROP y no por REJECT. 5.2.5 El entorno Iptables Antes de configurar el Firewall debemos familiarizarnos en los parámetros de configuración de las reglas en el entorno de Iptables, siendo que es una aplicación muy completa requiere cierta habilidad para configurar las reglas; por eso, corroboraremos en la práctica todo lo comentado en los puntos anteriores. Para empezar, mediante el comando: iptables –L podemos ver que por defecto la política de seguridad con la que se rige la herramienta es de aceptar todos los paquetes. • Iptables –P INPUT ACCEPT • Iptables –P OUTPUT ACCEPT • Iptables –P FORWARD ACCEPT Si no se especifica ningún parámetro se da a entender que se aceptará todo paquete de la interfaz que provenga, sea cual sea su protocolo o su puerto origen y destino, etc. Por ello, lo modificamos en modo DROP dado que nuestra política a seguir es la de denegar todo. Por otro lado, si listamos las cadenas de la tabla nat mediante el comando: iptables –t nat –L vemos que también las tres cadenas están en modo ACCEPT y no hay ninguna regla definida. En este caso, ninguna de las tres subredes (interna, externa o DMZ) se podrá intercomunicar puesto que no se aplica la traducción de IP’s. Para ello debemos hacer un enmascaramiento de estas a través de la “acción” MASQUERADE. iptables –t nat –A POSTROUTING –s 192.168.100.0/24 –j MASQUERADE #LAN interna iptables –t nat –A POSTROUTING –s 192.168.200.0/24 –j MASQUERADE #DMZ Ahora sí que existe la conectividad entre ellas, pues con estas reglas decimos que para cualquier máquina de una de las dos subredes aplique una traducción de IP en la salida (POSTROUTING). 55 Por otra parte, hemos querido comprobar a nivel práctico que las cadenas INPUT y OUTPUT son independientes de la cadena FORWARD (como hemos explicado teóricamente en el punto (5.2.2. Tablas). Si partimos de la base en poner las cadenas INPUT y OUTPUT en modo DROP y la cadena FORWARD en modo ACCEPT, podemos seguir conectándonos desde la red interna a la red externa, independientemente de si la cadena OUTPUT o INPUT está habilitada; es por eso que no será necesario repetir las reglas para ambas cadenas. Luego probamos el caso contrario y efectivamente vemos que desde la red interna o desde la DMZ no podemos acceder a la red externa, si no es habilitando la cadena FORWARD. A continuación nos disponemos ya a configurar las reglas de nuestro Firewall 5.3 Configuración de las reglas del Firewall Para empezar, nos disponemos a crear un archivo llamado Firewall en el que configuraremos las reglas. Haremos que se cargue cada vez que se reinicia la máquina desde el directorio /etc/init.d. A parte, debemos darle los permisos de lectura y escritura necesarios. chmod 0755 /etc/init.d/firewall Por otra parte, para administrar el runlevel utilizamos el programa de Debian update-rc.d. Primero borramos todos los enlaces en los directorios rc.d al guión /etc/init.d/firewall. update-rc.d –f /etc/init.d/firewall remove A continuación creamos los enlaces que inician Firewall en los runlevels 2345. update-rc.d /etc/init.d/firewall start 99 2 3 4 5 . Una vez creado el fichero configuramos el Firewall en base a la política de seguridad definida (véase Anexo II-C.1). 5.4 Pruebas de vulnerabilidad Para comprobar el correcto funcionamiento del Firewall accedemos a los servicios desde cada una de las subredes para verificar que el Firewall habilita o deshabilita el tráfico en base a las reglas definidas en su configuración; o sea que intentamos violar aquellos accesos no permitidos y comprobamos que habilita el tráfico permitido. 56 Para ello hemos hecho las mismas pruebas que hacíamos al comprobar que los servicios funcionaban correctamente pero ahora desde las 3 subredes y así ver qué tráfico deja o no pasar nuestro Firewall. Una vez comprobado el correcto funcionamiento del Firewall comprobando si sólo permite el paso del tráfico estipulado por las reglas nos disponemos a hacer un escaneo de vulnerabilidades con Nessus en los servicios de la DMZ. Tabla de los servicios del host (DMZ) Los servicios que están habilitados por el Firewall Iptables son los que detectan Nessus y los lista junto con el tipo de mensajes que tiene sobre cada uno. Análisis del Host Puerto/Servicio Mensaje según el puerto ssh (22/tcp) Notas de seguridad smtp (25/tcp) Agujero de seguridad domain (53/udp) Notas de seguridad www (80/tcp) Avisos de seguridad pop3 (110/tcp) Notas de seguridad ftp (21/tcp) Avisos de seguridad general/tcp Avisos de seguridad general/udp Notas de seguridad Tabla 2. Análisis del escaneo de puertos de la DMZ Gráfica del tráfico en la red En esta gráfica adjunta podemos ver el tráfico que generan los servicios y sus respectivos puertos (eje X) en base al número de ocurrencias (eje Y). Podemos comprobar que hay una sola ocurrencia por servicio puesto que se analiza un sólo host que es el que dispone de ese servicio. 63 otra parte, los conocimientos requeridos de GNU/Linux para trabajar con Iptables no son muy extensos. Política de seguridad La política de seguridad que sigue Iptables es de aceptación de todo tráfico entrante y saliente. Siendo que esta política no es la más segura, la hemos modificado por la que deniega todo tráfico entrante y/o saliente. Configuración La configuración de las reglas la podemos calificar como una configuración sencilla, pues por lo general todas las reglas siguen el mismo modelo, cambiando los parámetros TCP/IP. La dificultad viene cuando hay un gran número de reglas por configurar debido a que el mantenimiento del Firewall resulta ser mucho más complejo y pesado. Siendo que esto es fácil que ocurra ya que debemos configurar para cada tipo de tráfico una regla que le haga referencia; es recomendable seguir una política de negación de tráfico para sólo habilitar única y exclusivamente el tráfico deseado y de esta manera minimizar el máximo número de reglas posibles. Además de que sin lugar a dudas esta política es la más segura. Por otro lado, es fundamental tener claro cómo funciona el establecimiento y la finalización de las conexiones en una red. Por ejemplo con el servidor POP3; dejamos pasar el tráfico por el puerto 110 pero debemos tener en cuenta que únicamente permitimos el tráfico del cliente al servidor, no en el sentido inverso. Tipo de filtrado Como ya hemos comentado a lo largo de este capítulo Iptables inspecciona los paquetes a nivel TCP/IP. Por eso nuestras reglas filtran en base a las direcciones origen o destino a los puertos origen y destino o al tiempo de ida y vuelta del paquete o TTL (Time To Live) y no en base a la capa de aplicación, lo que impide hacer un filtrado menos granulado. Características Una de las ventajas que caracteriza esta herramienta es que permite la instalación de stateful Firewalls. Esto significa que el Firewall tiene una memoria para cada una de las conexiones, esencial para la configuración de FTP activo (Véase apartado 4.7.1) y para el servicio DNS. Además, de que podemos bloquear algunos de los ataques DoS más comunes sin tener que incluirlo como regla en el Firewall. (Véase apartado 5.1). En cuanto a la carga de las reglas, ésta es muy flexible y fácil de configurar, lo que mejora las antiguas ipchains, a parte de que el tipo de Firewall de Packet Filter permite que sea mucho más rápida debido a que el filtrado es menos exhaustivo. 64 Como ya hemos dicho anteriormente, este tipo de Firewalls tiene la carencia de no inspeccionar el payload del paquete, algo que sí hacen los Proxies (Véase Apartado 2.2.3.1 está experimentando un nuevo módulo de Kernel llamado string matching match que permite una inspección limitada del payload del paquete impidiendo la entrada de ciertas peticiones al servidor Web que no interesan. Este módulo amplía ligeramente las fronteras de un filtrado de este tipo pero no llega a la cima para inspeccionar los paquetes más allá de este nivel. Cabe decir que este estudio no lo hemos hecho en la práctica porque tampoco nos ha sido imprescindible para el estudio de nuestro Firewall. Calidad de Servicio (QoS) Si hacemos referencia a la Calidad de Servicio, la herramienta Iptables en sí no ofrece la posibilidad de priorizar el tráfico, únicamente permite marcar el tráfico con la tabla mangle. Por defecto los paquetes que entran o salen a través del Firewall siguen una disciplina de cola FIFO y para poder priorizar el tráfico es necesario el paquete Iproute2 que añade control de tráfico TCP/IP. Análisis de vulnerabilidades Por lo que respecta al análisis de vulnerabilidades con Nessus, comprobamos que no cubre al 100% la seguridad exigida puesto que se ha encontrado un agujero de seguridad en el servidor de correo. A modo de conclusión En definitiva, el Firewall configurado con Iptables es poco granulado ya que los parámetros de filtrado no van más allá de la cabecera IP con lo que Iptables es un buen comienzo para crear un Firewall más o menos sencillo en una red. 65 6. Firewall: ISA Server 2004 Enterprise sobre Windows 2003 Server Del mismo modo que en el capítulo anterior desarrollaremos todo el estudio teórico y práctico que se ha hecho para la configuración y el análisis del Firewall de Microsoft. En un primer apartado hacemos una descripción de las características del propio Firewall. A continuación, dedicaremos un segundo apartado lo para definir la configuración llevada a cabo y finalmente en un tercer punto hacemos el estudio de vulnerabilidades. 6.1 Descripción del Firewall ISA Server Microsoft Internet Security and Acceleration Server (ISA) es un producto que tiene como funcionalidades las de servidor Firewall, servidor caché o ambas integradas. Este Firewall permite filtrar los paquetes a nivel de aplicación de la torre OSI lo que permite hacer un filtrado mucho más granulado. Este tipo de filtrado permite utilizar los puertos “universales” para pasar todo el tipo de tráfico. Es decir, si en un cortafuegos de una empresa no dejan abierto un puerto determinado, con ISA Server es posible pasar el tráfico del protocolo correspondiente por uno de los puertos que sí tenga habilitado. El estudio de nuestro Firewall se basará en las funcionalidades como servidor Firewall; es decir, cuando ISA es capaz de asegurar la red mediante la configuración de reglas que controlen las comunicaciones entre varias redes. Algunas de las características más relevantes son: • Filtrado a nivel de aplicación: ISA Server 2004 va más allá del filtrado básico al controlar el tráfico específico de una aplicación con filtros de datos, comandos y aplicaciones. Mediante el filtrado inteligente de VPN, HTTP, FTP, SMTP, POP3, DNS, conferencia H.323, transmisión de multimedia y tráfico RPC, ISA Server 2004 puede aceptar, rechazar, redirigir y modificar el tráfico en función de su contenido. • Filtración dinámica de paquetes: Abre puertos en solicitud a la respuesta del usuario y cierra los puertos cuando termina la comunicación. • Publicación de servidores: Permiten el acceso a servidores de una red interna o perimetral desde una red externa agregando un nivel de seguridad. Las reglas de publicación en servidores protegen los servidores internos del acceso no deseado por parte de usuarios externos. El filtrado inteligente de aplicaciones protege a todos los servidores publicados de ataques procedentes del exterior. 66 • Redes privadas virtuales integradas: ISA Server 2004 permite proporcionar acceso remoto seguro basado en estándares para conectar las sucursales y los usuarios remotos a las redes corporativas. Además da la posibilidad de ofrecer prioridades en el ancho de banda de manera que ofrece calidad de servicio (QoS). • Detección de Intrusos. Integra una herramienta de detección que puede alertar sobre ataques a los que pueda estar sometido la red interna, por ejemplo si alguien intenta hacer una exploración de puertos. • Autenticación. Se pueden establecer diferentes modos de autenticación, ya sea utilizando la autenticación de Windows o a través del cifrado hashing. Además ISA Server puede autenticar a los usuarios con RADIUS (Remote Authentication Dial-In User Service). • Servidor de almacenamiento en caché Web: ISA Server 2004 usa un almacenamiento en caché RAM que resulta muy rápido y una caché de disco optimizada con el objeto de aumentar el rendimiento en Web, tanto en el caso de los clientes internos que tienen acceso a servidores Web en Internet como para los usuarios externos de Internet que visitan el servidor Web corporativo. • Política de acceso. El servidor ISA se puede configurar para ejecutar reglas de acceso a protocolos, contenidos y sitios por parte de los clientes de la red interna a Internet, permitiendo o no el acceso; pues la reglas especifican el sitio y el contenido al que se puede tener acceso. • Plataforma extensible. Escalabilidad o Rendimiento por escalamiento vertical. ISA Server está diseñado para trabajar con múltiples procesadores al optimizarse para Windows 2000. A diferencia de muchos otros productos, ISA emplea el potencial de procesamiento adicional para mejorar el rendimiento. (ISA Server Standard Edition tiene capacidad para un máximo de cuatro procesadores). o Escalabilidad horizontal (clustering y balanceo de carga). ISA Server utiliza Windows NLB (Network Low Balancing) Services de Microsoft con el clustering (agrupamiento de varios equipos que reciben un mismo trato) y con Enterprise Edition, puede aprovechar las ventajas del CARP (Cache Array Routing Protocol) para proporcionar tolerancia en fallos, alta disponibilidad, mayor eficiencia y rendimiento por medio del clustering de múltiples equipos de ISA Server. 67 6.1.1 Arquitectura servidor ISA El servidor ISA se puede configurar como servidor independiente o como un servidor integrado en un array. Estos arrays incluyen uno o más servidores ISA que tienen la misma configuración, una administración centralizada y una política de seguridad centralizada. En nuestro caso configuramos ISA como servidor array y configuraremos un único servidor para analizar más a fondo todas sus posibilidades y poder permitir en un futuro el configurar más de un servidor si fuera necesario; pues de la otra manera no sería posible. 6.1.1.1 Servidores en Array Un array es un grupo de servidores ISA que se utilizan para implementar tolerancia a fallos, balanceo de carga y caché distribuido. Esto permite que el array sea tratado y administrado como una sola entidad lógica. Si se diera el caso de instalar más de un servidor ISA, los servidores en el array tienen una misma configuración, permitiendo administrar centralizadamente todos los servidores en el array y todos los arrays dentro de una misma empresa. Cuando se modifica la configuración de un array, todos los servidores ISA que lo componen son modificados, incluyendo las políticas de acceso y las políticas de caché. Esto nos puede servir de ayuda para si en un futuro, necesitamos añadir otro Firewall. Las políticas de acceso de un array o políticas de array tal cual se denomina en el programa, pueden crear reglas de acceso a sitios, contenidos, protocolos, filtrado de paquetes, publicaciones Web, etc. Estas políticas tienen como ámbito de aplicación a los sistemas que pertenecen a un mismo array. Por otra parte, las políticas de empresa son las que engloban las políticas de acceso de diferentes arrays. 68 MS SQL Server Ilustración 14. Modelo de servidores ISA Server Enterprise en Array ISA Server Array ISA Server Array Workstations Workstations ISA Servidor Array 69 6.1.1.2 Servidores independientes El segundo tipo de arquitectura ISA es ISA como servidor independiente, que se caracteriza por: • Está limitada únicamente a un servidor • No tiene por qué ser miembro de un dominio de Windows a diferencia de los servidores array. • No se implementan políticas de empresa, solamente se implementan políticas de servidor. Ilustración 15. Modelo de servidor ISA Server independiente (single Array) 6.2 Configuración del Firewall La configuración con ISA Server es con interfaz gráfica lo que ayuda a crear las reglas de manera más clara y pautada. Ilustración 16. Escenario implementado en ISA Server ISA Servidor independiente (Single Array) (MS Access database) MS SQL Server database Workstations 70 La política utilizada por defecto de ISA Server es de denegar todo tipo de tráfico, por eso nosotros habilitamos el tráfico que nos interese. En primer lugar definimos el escenario perimétrica de nuestra red junto con los rangos de las distintas subredes. A continuación creamos las reglas. ISA Server permite configurar las reglas de dos modos correlacionados entre sí: • Publicación de un servidor • Accesos a un array 6.2.1 Publicación de un servidor Esta regla permite que los usuarios de una red externa puedan acceder a través del natting, que lo ejecuta esta misma regla implícitamente, al servidor que se publica en la red interna o en la DMZ. Cuando creamos una regla de publicar un servidor, no sólo habilitamos el servidor que está detrás del Firewall sino que podemos filtrar los paquetes según el protocolo (filtering). Para cada uno de los servicios de la DMZ creamos una regla de publicación que viene definida por los siguientes parámetros: • General • Acción • Desde • Hacia • Tráfico • Horas • Redes Listener • Nombre público • Bridging • Usuarios 71 Ilustración 17. Publicación de un servidor con ISA Server Para el caso del Nombre público, Bridging y Usuarios es únicamente para los servidores Web y FTP. Cabe decir que con el parámetro Bridging definimos el tipo de “Servidor Web” que habilitamos (“www o Ftp”), y es aquí donde les especificamos el puerto en el que se redireccionarán las peticiones. Mediante el Bridging HTTPS se puede cifrar: • Cifrado entre cliente-firewall y firewall-servidor • Cifrado entre cliente-firewall • Cifrado entre firewall-servidor Ilustración 18. Regla publicación de un servidor con ISA Server 72 En el Anexo II-C.2 podemos ver en forma esquemática la descripción de cada uno de los parámetros según el servicio al que hacen referencia. 6.2.2 Accesos a los arrays Además de publicar los servicios que hay detrás del Firewall, debemos crear las reglas para habilitar los puertos pertinentes de los servicios en cada una de las subredes. Estas reglas que filtran a nivel de red y aplicación utilizan un sistema encadenado, es decir la primera que se cumpla es la que se ejecuta. La configuración de cada uno de los servicios se basa en los siguientes parámetros: • General • Acción • Tráfico • Desde • Hacia • Horas • Protocolos • Usuarios • Contenido 79 Una vez descritas las vulnerabilidades de los servidores y habiendo corregido aquellas que pueden ser una amenaza para la seguridad del sistema podemos sacar conclusiones sobre el comportamiento de nuestro Firewall. 6.4 Valoración Sistema Operativo En este caso, no hemos tenido que estudiar el funcionamiento del Sistema Operativo sobre el que trabajamos porque Windows es la plataforma usada comúnmente a nivel doméstico, y las funcionalidades que difieren Windows Server 2003 del Windows de uso doméstico no han sido necesarias para la configuración del Firewall, con lo cual no hemos tenido que invertir tiempo en ello. Política de seguridad ISA Server tiene por defecto deshabilitados todos sus puertos. De ninguna de las maneras puede ningún tipo de tráfico atravesar el Firewall; pues ésta política es la más segura, con lo que es la que hemos escogido en la configuración de los Firewalls. Configuración Para empezar, debemos definir la puesta a punto de ISA Server Enterpise como una aplicación sencilla de instalar. Ésta es una aplicación ideal para ámbitos empresariales, siendo que tiene un gran abanico de posibilidades que no se aprovecharían para una pequeña red doméstica. La configuración de las reglas es aparentemente sencilla gracias a la interfaz gráfica, pero por la misma razón que ISA Server tiene múltiples aplicaciones, también complica ligeramente su configuración. Tipo de filtrado Como ya hemos comentado al comienzo del capítulo, este Firewall tiene la posibilidad de examinar el contenido del paquete y filtrar según el protocolo de usuario, lo que hace que el filtrado sea mucho más exhaustivo a la par que sofisticado. Sin embargo, a priori, la configuración de las reglas, parece ser sencilla pero si tenemos en cuenta el gran abanico de posibilidades de filtrado que puede llevar a cabo, su configuración deja de ser trivial. Para cada una de las reglas que se configuran existe una opción para filtrar según el protocolo referente a esa regla. Como por ejemplo, la inspección de los paquetes RPC de HTTP. 80 Características ISA Server como Firewall supervisa las solicitudes y las respuestas transmitidas entre Internet y los equipos cliente internos, y controla quién tiene acceso a qué equipos de la red corporativa. Del mismo modo que también controla a qué equipos de Internet tienen acceso los clientes internos asegurando un elevado grado de seguridad. Una de las ventajas que caracteriza ISA Server que hemos podido comprobar es que permite la publicación segura en Internet; pues se puede utilizar ISA Server para definir una directiva de publicación, proteger los servidores de publicación internos y permitir que los clientes de Internet tengan acceso seguro a los mismos. Además hemos podido comprobar que podemos colgar un servidor en un puerto no estándar. A más a más, esta aplicación es capaz de abrir conexiones mediante el tunneling. Para el caso de una empresa, cada vez más empleados trabajan desde sus casas y utilizan desde sus equipos domésticos el acceso telefónico a la red corporativa. Por ello, es también cada vez más habitual que los empleados establezcan una conexión de red privada virtual (VPN). En esta situación, el usuario llama a su ISP local. En el otro extremo, uno de los servidores de la red corporativa está conectado a su ISP y se establece un túnel entre ambos, el cual ISA Server es capaz de aceptar siempre y cuando se cumplan unas condiciones de seguridad. Este estudio no hemos podido valorarlo a la práctica lo que no descarta que lo dejemos de tener en cuenta. Por otra parte, aunque no lo hemos desarrollado en este proyecto debemos considerar para líneas de trabajo futuro que ISA Server es capaz de implementar una caché para los objetos que se solicitan con más frecuencia. Puede configurar la caché para asegurarse de que contiene los datos utilizados con más frecuencia en una organización o los datos a los que los clientes de Internet tienen acceso con más frecuencia. Es importante mencionar la capacidad de ISA Server de agregar hosts que conectados entre ellos se puedan sincronizar para hacer un balanceo de carga. Una empresa que se está extendiendo continuamente requiere que su sistema de seguridad sea escalable e ISA Server lo permite con el clustering. Uno de los inconvenientes que tiene este Firewall es su elevado coste con lo cual para según que nivel de seguridad se quiera ofrecer puede o no compensar este gasto. Esta aplicación Servidor de la multinacional Microsoft cuesta 5053,32 Euros por procesador. Calidad de servicio ISA Server tiene la posibilidad de priorizar el tráfico en las conexiones ya mencionadas de VPN. 81 Análisis de vulnerabilidades Por otra parte, en este caso no se encuentra ninguna vulnerabilidad en el servidor de correo, pues ISA no permite el envío del comando MAIL FROM. En este punto hemos observado que ISA Server no ha cubierto el 100% de la seguridad (sin agujeros ni notificaciones ni avisos), lo cual nos ha hecho llegar a la conclusión de que al no tener implementados los servidores de Microsoft, como Microsoft IIS de servidor Web o Microsoft Exchange de servidor de correo, ISA Server no cubre las garantías de seguridad ante los EXPLOITS de Nessus de la misma manera. A modo de conclusión En definitiva ISA Server ofrece un gran abanico de posibilidades que ayudan a poder decir que las garantías de seguridad se cumplen a muy alto nivel. Además de que tenemos que tener en cuenta que ISA Server es una plataforma no sólo utilizada con funcionalidades de Firewall, con lo cual la hace ser muy potente. 82 7. Firewall: Packet Filter sobre OpenBSD 3.6 El capítulo 7 va a estar definido del mismo modo que los capítulos 5. y 6. desarrollando un estudio teórico, una configuración práctica y un análisis de vulnerabilidades del Firewall basado en Packet Filter. Los apartados de este capítulo serán los siguientes: • Descripción del Firewall con Packet Filter • Configuración de las reglas de Firewall • Pruebas de vulnerabilidad • Valoración 7.1 Descripción del Firewall con Packet Filter Packet Filter (PF) es el paquete de filtrado de OpenBSD. Los criterios que usa Packet Filter para inspeccionar los paquetes los toma de la información existente en el nivel 3 y 4 de la torre OSI o sea nivel de red (IP) y transporte (TCP, UDP, ICMP) respectivamente, como también filtra según las cabeceras de los paquetes. Los criterios que más se utilizan son los de la dirección de origen y de destino, el puerto de origen y de destino, y el protocolo. El Firewall se configura en base a unas reglas de filtrado que especifican los criterios con los que debe concordar un paquete y la acción a seguir, bien sea bloquearlo o permitir su salida. Estas reglas se evalúan por orden de secuencia. 7.1.1 Sintaxis de las reglas La sintaxis general para las reglas de filtrado es la siguiente: action direction [log] [quick] on interfaz [af] [proto protocol] \ from src_addr [port src_port] to dst_addr [port dst_port] \ [tcp_flags] [state] A continuación explicaremos los distintos parámetros de la regla: • action La acción a seguir para los paquetes que concuerden, ya sea pass o block . La acción pass permitirá el paso al paquete de vuelta hasta el núcleo del sistema, para que éste lo procese, mientras que la acción block actuará según se indique en la configuración de la opción de la política de bloqueo, blockpolicy . La acción predeterminada se puede anular especificando block drop (bloquear y eliminar el paquete) o block return (bloquear y devolver el paquete). 83 • direction La dirección en la que se mueve el paquete en una interfaz, que será in (entrante) o out (saliente). • log Indica que se debe registrar el paquete. Si la regla especifica la opción keep state , modulate state , o synproxy state entonces sólo se registrará el paquete que establezca el estado. Para registrar todos los paquetes hay que usar la opción log-all . • quick Si un paquete concuerda con una regla que especifique la opción quick , entonces esa regla se considera como la regla final de concordancia para el paquete, y se tomará la acción que esté especificada en action . • interfaz El nombre o el grupo de la interfaz de red a través del cual se mueve el paquete. • af La familia de direcciones del paquete, que será inet para IPv4 ó inet6 para IPv6. Generalmente, PF es capaz de determinar este parámetro basándose en la dirección, o direcciones, de origen y/o de destino. • protocol El protocolo de la capa 'Layer 4' del paquete: o TCP o UDP o ICMP o ICMP6 Un nombre de protocolo válido del fichero /etc/protocols Un número de protocolo entre 0 y 255 Un grupo de protocolos que usen una lista. • src_addr, dst_addr La dirección de origen y/o de destino en la cabecera IP. Las direcciones se pueden especificar como: • src_port, dst_port El puerto de origen y/o de destino en la capa 'Layer 4' de la cabecera IP. Los puertos se pueden especificar como: o Un número entre el 1 y el 65535 o Un nombre de servicio válido del fichero /etc/services o Un grupo de puertos que usen una lista o Un indicador de campo (<,=,>, etc) 84 • tcp_flags Especifica los indicadores que deben existir en la cabecera TCP cuando se usa proto tcp . Los indicadores se especifican como flags check/mask . Por ejemplo, flags S/SA instruye a PF para que sólo mire los indicadores S y A (SYN y ACK), y que acepte la concordancia si el indicador SYN está activo ("on"). • state Especifica si se guarda la información sobre el estado en paquetes que concuerden con esta regla. 7.1.2 Calidad de Servicio (QoS) En la versión 3.0 de OpenBSD, se ha implementado la plataforma ALTQ (Alternate Queueing) de manera que encontramos integrado en la propia herramienta de Packet Filter la posibilidad de priorizar el ancho de banda. La implementación de ALTQ de OpenBSD tiene soporte para schedulers de Colas Basadas en Clase (CBQ) y Colas Basadas en Prioridades (PRIQ). También tiene soporte para Pronta Detección Aleatoria (RED) y Notificación Explícita de Congestión (ECN). Por defecto, OpenBSD utiliza un scheduler FIFO (First in, First Out). Siendo que se desvía del tema principal de este proyecto, nos disponemos a explicar brevemente y a groso modo en qué consisten estos schedulers para tener una visión general, por si en líneas de trabajo futuro se decide trabajar con Packet Filter y QoS. First In-First Out (FIFO) Algoritmo que consiste en generar una cola de manera que el primer paquete que entra es el primero de la cola en salir, y así sucesivamente para el resto de paquetes. Colas Basadas en Clase (CBQ) CBQ (Class Based Queueing) es un algoritmo de formación de colas que divide el ancho de banda de una conexión de red entre varias colas o clases. A cada cola se le asigna un tráfico basándose en la dirección de origen o de destino, el número de puerto, protocolo, etcétera. Colas Basadas en Prioridades (PRIQ) Las PRIQ (Priority Queueing) asignan colas múltiples a una interfaz de red, y dan a cada cola un nivel de prioridad único. Una cola con un nivel de prioridad más alto se procesa siempre antes que una cola con un nivel de prioridad más bajo. Pronta Detección Aleatoria (RED) 85 RED (Random Early Detection) es un algoritmo que se utiliza para evitar la congestión. Su trabajo es evitar la congestión en la red, asegurándose de que la cola no se llene. 7.2 Configuración de las reglas del Firewall Para empezar, antes de crear las reglas por las que se regirá el Firewall debemos activar la opción de enrutamiento y así la máquina sea capa de redireccionar el tráfico de las distintas redes. Para ello nos editamos el fichero /etc/sysctl.conf net.inet.ip.forwarding=1 #1=Permit Además habilitamos en el archivo de la configuración del sistema localhost /etc/rc.conf el paquete de Packet Filter, valga la redundancia. pf=YES Una vez habilitados estos parámetros configuramos las reglas del Firewall editando el fichero /etc/pf.conf (véase Anexo II-C.3). A continuación, para cargar el archivo pf.conf debemos hacerlo con la utilidad pfctl. Si consultamos su manual (man pfctl) vemos que debemos utilizar el comando: pfctl –f /etc/pf.conf 7.3 Pruebas de vulnerabilidad De la misma manera que con los Firewalls de Iptables e ISA Server verificamos el correcto funcionamiento del Firewall antes de disponernos al estudio de vulnerabilidades. Una vez hecha la comprobación testeamos los servicios de la DMZ con la aplicación Nessus. 86 Tabla de los servicios del host (DMZ) Los servicios que están habilitados por el Firewall de Packet Filter son los que detecta Nessus y los lista junto con el tipo de mensajes que tiene sobre cada uno. Análisis del Host Puerto/Servicio Mensaje según el puerto general/tcp Notas de seguridad ftp (21/tcp) Avisos de seguridad ssh (22/tcp) Notas de seguridad smtp (25/tcp) Agujero de seguridad www (80/tcp) Avisos de seguridad pop3 (110/tcp) Notas de seguridad domain (53/udp) Notas de seguridad general/udp Notas de seguridad Tabla 14. Análisis del escaneo de puertos de la DMZ Gráfica del tráfico en la red En esta gráfica adjunta podemos ver el tráfico que generan los servicios y sus respectivos puertos (eje X) en base al número de ocurrencias (eje Y). Ilustración 22. Análisis del tráfico de la red perimetral con Packet Filter 87 Gráfica de los riesgos de seguridad Como podemos ver en la Figura 2 el porcentaje de alto riesgo (agujero de seguridad) es del 3% donde en la gráfica 3 podemos ver cual es el servicio o servicios que lo provocan (el de correo). Por otra parte, el grado de riesgo medio es del (27%) respecto el grado de riesgo bajo (70%). Ilustración 23. Gráfica del porcentaje de riesgo en los servicios con Packet Filter Agujeros de seguridad en el escenario Como vemos en la figura 3, según el eje de las X (nombre del servicio) y el eje de las Y (número de agujeros de seguridad), el único agujero que Nessus ha detectado se ve provocado por el servicio de correo. 88 Ilustración 24. Gráfica de los servicios con agujeros de seguridad Vulnerabilidades en los servicios En base a la tabla adjunta en el Anexo III-C. podemos sacar los siguientes informes de vulnerabilidad para cada uno de los servicios: Servidor Web Mensaje Contenido Problema Solución Notificación Existe un servidor web en este puerto - - Aviso El servidor intenta esconder su versión y su nombre, sin embargo Nessus ha sido capaz de identificarlo Apache/ 1.3.33 No hay riesgos Fijar la configuración Bug - - - Tabla 15. Vulnerabilidades en el servidor WEB con Packet Filter 95 determinado tráfico es fundamental en los casos en el que el ancho de banda es limitado. Escalabilidad Por lo que respecta a la escalabilidad de los Firewalls el tener que generar una regla por cada tipo de tráfico (en el caso de Iptables) provoca que al final de la configuración del Firewall haya un cúmulo de reglas que dificultan la gestión y el mantenimiento en el caso que se quiera ampliar la red. Este tipo de Firewalls adolecen de problemas de escalabilidad. En cambio ISA Server permite la agregación de hosts conectados entre ellos y su sincronización, de manera que se puede generar un balanceo de carga. Por lo que respecta a Packet Filter el caso es similar que Iptables pero en menor grado, puesto que podemos agrupar un número de reglas con distintos protocolos en una sola. Características Otra de las características que nos ofrece la plataforma ISA Server que no disponen Iptables y Packet Filter es el permitir tener acceso remoto seguro a la red corporativa mediante VPN’s; • ISA Server 2004 permite proporcionar acceso remoto seguro basado en estándares para conectar las sucursales y los usuarios remotos a las redes corporativas. Además da la posibilidad de ofrecer prioridades en el ancho de banda de manera que ofrece calidad de servicio (QoS). Es importante destacar la posibilidad de que para ISA Server se pueden publicar servidores en puertos no estándares, con lo cual si un puerto estándar de determinado servicio está deshabilitado se podría colgar ese mismo servicio en el puerto 80 por ejemplo. Esto es una mejora que no disponen los otros dos Firewalls. Análisis de vulnerabilidades En cuanto al análisis de vulnerabilidades, hemos podido corroborar que ninguno de los tres Firewalls cumple una garantía de seguridad al 100%, pero cabe decir que los avisos que genera Nessus al respecto son irrelevantes, puesto que la mayoría se pueden corregir de manera trivial. Únicamente hay que considerar con mayor detenimiento el agujero encontrado en el servidor de correo, pues existe tanto en el Firewall de Iptables como en el de Packet Filter . Según estas pruebas hemos podido comprobar que difícilmente se pueden sacar diferencias entre los tres Firewalls porque los resultados son muy parecidos. Si bien esperábamos que esto ocurriese con los Firewalls Iptables y Packet Filter _ambos tienen unas funcionalidades de filtrado muy similares y hemos seguido un mismo modelo de configuración para los dos_ nos ha sorprendido que también sucediera con ISA Server. Ante esto, hemos llegado a la conclusión que si hubiéramos configurado los servidores de Microsoft, como son Microsoft IIS de servidor Web o Microsoft Exchange de servidor de correo, ISA Server hubiera cubierto al 100% las garantías de seguridad ante los EXPLOITS de Nessus. 96 Llegados a este punto sería interesante de cara a líneas de trabajo futuras un seguimiento rehacer estas mismas pruebas con dichos servidores. A modo de conclusión Tras los tests realizados los Firewalls se revelan como pieza fundamental para garantizar un alto nivel de seguridad en la red. Es indudable que Iptables o Packet Filter tienen carencias que ISA Server cubre pero todos ellos aseguran una protección mínima que en algunos casos ya es suficiente. 8.2 Adecuación de los Firewalls según el escenario empresarial Empresa con sedes por toda España En este caso el Firewall más adecuado es sin lugar a dudas ISA Server Enterprise porque en este caso se pueden aprovechar muchas de las funcionalidades de la plataforma. Para empezar sería necesaria la configuración de VPN´s para que usuarios de otras sedes se conecten de manera remota a un punto concreto de la red de la empresa. Además de ser fundamental poder ofrecer calidad de servicio en el tráfico priorizando aquel tráfico que proviene de una jerarquía más alta por ejemplo, o bien para priorizar aquel en el que el retraso es crítico para la buena comunicación. En este caso, suponiendo que la red es extensa también sería adecuado aprovechar la posibilidad de ISA Server como Caché de manera que haga disminuir tráfico innecesario en la red. Otra de las ventajas que se podría aprovechar en este caso es la posibilidad de hacer clustering y balanceo de carga, siempre y cuando la empresa extienda sus sedes y se fuerce la agregación de un nuevo host. El único inconveniente que pudiera haber es el coste de la aplicación, que de alguna manera si es una gran empresa puede compensar y más si tenemos en cuenta que el mantenimiento no tiene porque suponer un gran gasto. Si la empresa no fuerza a tener grandes cambios, las pequeñas modificaciones que se tuvieran que hacer no obligarían a tener que pagar el desplazamiento de un técnico, pues como hemos dicho en la valoración de ISA Server, la propia configuración de las reglas es más trivial que la del resto de Firewalls. 97 Pequeña empresa Para un escenario de este tipo, una pequeña red con una sola sede en una misma oficina no compensa el tener que pagar tanto por el Firewall si muchas de las facilidades que se ofrecen no se utilizarán al completo. Es una inversión inefectiva, puesto que un Firewall del tipo Packet Filter bien configurado será mucho más útil y eficaz. Podrá garantizar un elevado nivel de seguridad con menor coste. Además también se podrá ofrecer Calidad de servicio si fuera necesario. Por otra parte el mantenimiento sí que resultaría ser costoso si tenemos en cuenta que este sistema de seguridad requiere ciertas nociones que no cualquiera podría hacer sin una ayuda. Así pues, por cualquier cambio sí que se verá la empresa obligada a pagar un técnico. 98 9. CONCLUSIONES Este capítulo corresponde a las conclusiones que lo conforman los siguientes puntos: • Revisión de los objetivos • Revisión de la planificación y los costes • Líneas de trabajo futuro • Conclusiones personales Es importante tener en cuenta lo que se consideró al empezar cualquier proyecto para luego revisar si se ha cumplido. Además de proponer una líneas de trabajo futuro de manera que todo este trabajo sirva de base para un emprender un nuevo tema. Finalmente el último apartado corresponde a las conclusiones personales. 9.1 Revisión de objetivos En todo proyecto es fundamental hacer un análisis sobre el cumplimiento o no de los objetivos propuestos en su comienzo. A medida que hemos ido trabajando hemos intentado tener siempre presente los objetivos de este proyecto puesto que cuanto más profundizamos en algo en concreto más se abre el abanico de temas que se pueden considerar, pero a veces es difícil saber acotar; pues un tema tan extenso como la Seguridad en Redes, Firewalls , el cual ofrece un gran número de fuentes de información, ralentiza la elaboración de la memoria y no permite seguir con alguno de los objetivos marcados. Si revisamos el apartado 1.2 donde aparecen la lista de objetivos a cumplir vemos que hemos cumplido todos ellos a excepción de la configuración y test de los Firewalls de más de un escenario. Los motivos que han llevado al no poder cumplir los objetivos se describen en el apartado 9.4 (Conclusiones personales). 99 A continuación adjuntamos una tabla donde listamos los objetivos propuestos en un comienzo y definimos si han sido o no cumplidos. Objetivo Alcanzado Configuración de los servicios del escenario (DNS, SSH, Correo, Web, WINS, DHCP). Sí exceptuando el servidor WINS Estudio de la taxonomía de Firewalls. Sí Análisis en profundidad a nivel teórico de los tres Firewalls con Iptables, ISA Server 2004 Enterprise y Packet Filter. Sí Configuración de los tres Firewalls en base a una política de negación de servicio Simulación de ataques y análisis de vulnerabilidades mediante el escaneo de puertos con la herramienta Nessus. Sí Sí No No Configuración para distintos escenarios: - Escenario con DMZ. - Escenario sin DMZ - Escenarios en los que combinamos los servicios entre la DMZ y la Interna. - Valorar cada escenario y hacer una comparativa No Redacción de esta memoria escrita con objeto de documentar las conclusiones alcanzadas tras cumplir los anteriores objetivos. Sí Tabla 20. Tabla de los objetivos propuestos y alcanzados. 9.2 Revisión de la planificación y costes 9.2.1 Planificación temporal No es una tarea fácil el poder cumplir rigurosamente los objetivos propuestos en las fechas previstas. En la teoría, aún dejando cierto margen para posibles problemas o imprevistos que puedan aparecer en la práctica, se dejan de 100 prever cosas que con mayor o menor importancia pueden entorpecer la labor del proyecto. Hasta que no se adentra a fondo no se puede predecir de manera exacta lo que le te va a llevar; claro que también es fundamental compensar esas demoras no previstas para no seguir atrasando la labor del proyecto. A continuación se muestra el esquema del desarrollo temporal real donde se podrá comprobar que ambos no se ajustan exactamente el uno con el otro. Las causas son muy variadas, algunas de ellas están explicadas en el apartado de conclusiones personales, y otras son las mismas que causan las demoras en cualquier proyecto de empresa dirigido a un cliente, la no rigurosa previsión. 101 Ilustración 25. Planificación temporal real del Proyecto 102 9.2.2 Análisis económico Por lo que respecta al análisis económico, los precios que contemplamos en un principio difieren de la realidad, a causa de un incremento de horas invertidas en la elaboración del proyecto. Según la planificación temporal llevada a cabo hay un incremento de 400 horas, que proviene de una duración del trabajo de 174 días a una media entre 6 y 7 horas, dando un total de 1100 horas. Además de haber tenido que utilizar un equipo más del previsto, pues hemos tenido que instalar Nessus desde una aplicación Knoppix y hemos necesitado el equipo en el que estaba la Debian. Es en éste donde supuestamente debíamos instalar OpenBSD. Por eso decidimos utilizar otra máquina donde configurar el tercer Firewall. En definitiva el coste del proyecto aumenta de manera considerable, un 32% respecto al coste previsto en un primer momento, con lo cual el valor total de este proyecto es de 26.720,71 € A continuación, del mismo modo que en el análisis de costes previstos que hicimos en el comienzo de este proyecto, adjuntamos la tabla Excel donde se describen estos costes. 103 Euros por unidad Euros totales Item Descripción Unidades HARDWARE Pentium IV clónico 5 850,00 € 4.250,00 € Switch 8 puertos 3 20,00 € 60,00 € Cable Ethernet 10Base-T. Par trenzado UTP cat 5. (unidad metro) 10 0,45 € 4,50 € Conector RJ-45 20 0,30 € 6,00 € Cd´s vírgenes 10 0,60 € 5,38 € Hardware Total 4.325,88 € SOFTWARE Windows 2003 Server con licencia 1 841,51 € 841,51 € ISA Server 2004 Enterprise 1 5.053,32 € 5.053,32 € Software Total 5.894,83 € MANO DE OBRA Ingeniero Técnico Euros por hora 1100 15,00 € 16500,00 € COSTE TOTAL Coste total proyecto Proyecto global 26.720,71 € Tabla 21. Coste real del Proyecto 104 9.3 Líneas de trabajo futuro La temática de este proyecto es muy extensa y como ya hemos dicho hemos tenido que acotar la cantidad de fuentes de información de las que disponemos y las distintas ramas a las que desencadena un tema como éste. No obstante, los objetivos han sido ambiciosos, pero indudablemente el proyecto deja abiertas varias líneas futuras de investigación. A continuación, se destacan las que a mi juicio tienen una mayor relevancia: • Estudio de los Firewalls con servidores Microsoft. • Estudio de los Firewalls aplicando QoS. • Estudio de los Firewalls utilizando VPNs. La primera línea de investigación es la que guarda una relación más directa con este proyecto pues la estructura de trabajo sería la misma pero con un escenario en el que los servidores sean Microsoft; de tal manera que se puedan ver las diferencias entre un Firewall y otro. Como hemos podido comprobar el análisis de vulnerabilidades de ISA Server ha resultado ser muy parecido a los otros dos, la cual cosa no nos ha permitido comprobar que ISA Server está preparado para proteger la red de determinados EXPLOITS que otros no lo están. Este proyecto carece de un profundo análisis de los Firewalls cuando se ejecutan funcionalidades de calidad de servicio, pues sería interesante analizar los comportamientos del Firewall para poder compararlos a este nivel. Finalmente, una tercera línea propuesta es la creación de VPNs para poner a prueba el funcionamiento del Firewall con este tipo de conexiones. En definitiva, este proyecto puede servir de base de cualquier otro que tenga como punto de salida algún tema que venga relacionado con cualquiera de estos Firewalls, puesto que todo el estudio previo y de comparación está aquí realizado y justificado habiendo partido de cero. 9.4 Conclusiones personales En cualquier proyecto sea o no para una empresa, uno de los objetivos a los que fundamentalmente se debería llegar siempre es a poder cumplir la planificación temporal que se hace previa al comienzo; siendo que muchas veces aparecen inconvenientes que no se puedan contemplar a priori, resulta difícil poder conseguirlo. Durante la elaboración de mi proyecto me he encontrado con algunos imprevistos y con las propias dificultades de algunos temas que han supuesto una dedicación más duradera en ello. 111 • http://mail.linux.org.mx/pipermail/ayuda/2002-August/004408.html • http://www.espaciolinux.com/artitecid-24.html • http://iptables-tutorial.frozentux.net/spanish/chunkyhtml/x4996.html • http://www.seguridad.unam.mx/eventos/admin-unam/FirewallsLinux.pdf Capítulo 6. Firewall: ISA Server Enterprise 2004 sobre Windows 2003 Server • http://www.microsoft.com/spain/servidores/isaserver/info/features.aspx • http://www.microsoft.com/spain/servidores/isaserver/info/competitive.asp x#Cost Capítulo 7. Firewall: Packet Filter sobre OpenBSD 3.6 • http://www.openbsd.org/faq/es/faq4.html#Start • http://www.openbsd.org/3.6_packages/i386.html • http://www.muine.org/~hoang/openpf.html • http://mirror.etf.bg.ac.yu/openbsd/snapshots/cats/INSTALL.cats • http://www.muine.org/~hoang/openpf.html • http://www.bgnett.no/~peter/pf/en/ • http://www.openbsd.org/faq/pf/es/filter.html#example • http://www.inestable.org/apuntes/openbsd_secure.pdf • http://www.openbsd.org/faq/pf/queueing.html Capítulo 8. Balance en base al estudio práctico • http://www.laflecha.net/canales/seguridad/200410253/ • http://www.bgnett.no/~peter/pf/en/bsdvslinux.html • http://www.freebsd.org/doc/es_ES.ISO8859-1/articles/explainingbsd/x99.html 1 ANEXOS TÍTULO DEL TFC: Firewalls software: Estudio, instalación, configuración de escenarios y comparativa TITULACIÓN: Ingeniería Técnica de Telecomunicaciones AUTOR: Mònica Ferrer Berbegal DIRECTOR: Marco Antonio Peña Basurto DATA: 14 de enero de 2006 2 ANEXO I: POLÍTICA DE SEGURIDAD A. Política de negación de servicio ¿Coincide con la regla 1? Cadena de Firewall Paquete IP ¿Coincide con la regla 2? ¿Coincide con la regla 3? Directiva DROP Sí No Sí No No Aceptar Aceptar Sí Aceptar 3 B. Política regida por el Firewall Servidor Web Correo Acceso remoto Resolución de Nombres Ficheros DHCP Protocolo HTTP HTTPS SMTP POP3 SSH DNS FTP DHCP Puerto # 80 443 25 110 22 53 20 68 ExternaÆDMZ Sí Sí Sí Sí No Sí Sí No DMZÆExterna No No No No No Sí No No InternaÆDMZ Sí Sí Sí No Sí Sí Sí No DMZÆInterna No No No No No No No No ExternaÆInterna No No No No No No No No InternaÆExterna Sí Sí Sí Sí Sí No Sí No Local HostÆDMZ No No No No Sí No No No Local HostÆInterna InternaÆLocal Host No No No No No No No No LocalHostÆExterna LocalHostÆExterna No No No No No No No No 4 ANEXO II: FICHEROS DE CONFIGURACIÓN A. Configuración de las redes A.1 CONFIGURACIÓN CON DEBIAN SARGE Firewall • /etc/network/interfaces #The loopback network interface auto lo iface lo inet loopback #The primary network interface (externa) auto eth0 iface eth0 inet static address 192.168.16.214 netmask 255.255.255.0 network 192.168.16.0 gateway 192.168.16.66 #será la salida por defecto #The internal network interface (LAN privada) auto eth1 iface eth1 inet static address 192.168.100.1 netmask 255.255.255.0 network 192.168.100.0 broadcast 192.168.100.255 #The desmilitarized network interface (DMZ) auto eth2 iface eth2 inet static address 192.168.200.1 netmask 255.255.255.0 network 192.168.200.0 broadcast 192.168.200.255 5 • Tabla de Encaminamiento Destination Gateway Netmask Iface 192.168.100.0 * 255.255.255.0 eth1 192.168.16.0 * 255.255.255.0 eth0 192.168.200.0 * 255.255.255.0 eth2 default 192.168.16.66 0.0.0.0 eth0 Red interna • /etc/network/interfaces #The loopback network interface auto lo iface lo inet loopback #The primary network interface (interna) auto eth0 iface eth0 inet static address 192.168.100.2 netmask 255.255.255.0 network 192.168.100.0 broadcast 192.168.100.255 • Tabla de encaminamiento La tabla de encaminamiento en este caso es sencillamente que todo lo enviado se remita a la única salida (tarjeta de red) que conecta con el Firewall (192.168.100.1), que será la salida por defecto. Destination Gateway Netmask Iface 192.168.100.0 * 255.255.255.0 eth0 default 192.168.100.1 0.0.0.0 eth0 6 Red perimétrica (DMZ) • /etc/network/interfaces #The loopback network interface auto lo iface lo inet loopback #The primary network interface (interna) auto eth0 iface eth0 inet static address 192.168.200.2 netmask 255.255.255.0 network 192.168.200.0 broadcast 192.168.200.255 Tabla de encaminamiento De la misma manera que en la máquina del usuario de la LAN privada, al tener una sola tarjeta de red, hay un solo gateway, el cual se conecta con el firewall (192.168.100.1) Destination Gateway Netmask Iface 192.168.200.0 * 255.255.255.0 eth0 default 192.168.200.1 0.0.0.0 eth0 A.2 CONFIGURACIÓN DE LAS REDES CON OpenBSD Firewall • /etc/hostname.rl0 inet 192.168.200.1 255.255.255.0 NONE • /etc/hostname.rl1 inet 192.168.100.1 255.255.255.0 NONE • /etc/hostname.xl0 inet 192.168.16.214 255.255.255.0 NONE 7 Tabla de encaminamiento Destination Gateway Interface default 192.168.16.66 xl0 192.168.16/24 link#1 Xl0 192.168.100/24 link#3 rl1 192.168.200/24 link#2 rl0 B. Configuración de los servicios B.1 CONFIGURACIÓN SERVIDOR DE CORREO. SENDMAIL • /etc/mail/sendmail.mc #Definimos los macros para identificar la versión de sendmail y la distribución Linux. #dnl dice al procesador de macros m4 que no procese el rsto de la línea (comentario). define(`_USE_ETC_MAIL_')dnl include(`/usr/share/sendmail/cf/m4/cf.m4')dnl VERSIONID(`$Id: sendmail.mc, v 8.13.4-3 2005-06-03 16:49:22 cowboy Exp $') OSTYPE(`debian')dnl DOMAIN(`debian-mta')dnl FEATURE(`no_default_msa')dnl Addr=192.168.200.2')dnl DAEMON_OPTIONS(`Family=inet, Name=MTA-v4, Port=smtp, Addr=192.168.200.2')dnl Port=submission, Addr=192.168.200.2')dnl DAEMON_OPTIONS(`Family=inet, Name=MSP-v4, Port=submission, Addr=192.168.200.2')dnl Especificamos que escuche no por la interfaz eth1.Por defecto tiene la de localhost o sea que sólo podría recibir mails de la propia máquina. define(`confPRIVACY_FLAGS',dnl `needmailhelo,needexpnhelo,needvrfyhelo,restrictqrun,restrictexpand,nobodyret urn,authwarnings')dnl define(`confCONNECTION_RATE_THROTTLE', `15')dnl define(`confCONNECTION_RATE_WINDOW_SIZE',`10m')dnl FEATURE(`access_db', , `skip')dnl FEATURE(`greet_pause', `1000')dnl 1 seconds FEATURE(`delay_checks', `friend', `n')dnl define(`confBAD_RCPT_THROTTLE',`3')dnl FEATURE(`conncontrol', `nodelay', `terminate')dnl 8 FEATURE(`ratecontrol', `nodelay', `terminate')dnl LOCAL_CONFIG EXPOSED_USER(root uucp)dnl # users exempt from masquerading LOCAL_USER(root)dnl MASQUERADE_AS(`tfc.es')dnl FEATURE(`allmasquerade')dnl FEATURE(`masquerade_envelope')dnl FEATURE(`nullclient', +)dnl dnl #MAILER_DEFINITIONS dnl #MAILER (‘local’)dnl dnl #MAILER(‘smtp’)dnl Cwtfc.es dnl Definimos que tfc.es se trata de un dominio local. • /etc/mail/local-host-names DAEMON_OPTIONS ('Port=smtp,Add=192.168.200.2,Name=MTA') tfc.es mail.tfc.es • /etc/mail/relay-domains tfc.es mail.tfc.es gmail.com • /etc/mail/access localhost.localdomain RELAY localhost RELAY 192.168.200.0/24 RELAY #Subred de la DMZ 192.168.100.0/24 RELAY gmail.com RELAY hotmail REJECT #Lo consideramos SPAM B.2 CONFIGURACIÓN SERVIDOR FTP. PROFTPD • /etc/proftpd.conf # /etc/proftpd.conf – This is a Basic ProFTPD configuration file. # ServerName “ftp” ServerType inetd #no es standalone DeferWelcome off #No muestra ningún mensaje ServerIdent on ftp.tfc.es #Identificador del servidor 9 # Esto hará que nuestro servidor ftp sea compatible con casi todos los clientes ftp. MultilineRFC2228 on DefaultServer on #Toma las opciones default de un servidor ftp #el número es el máximo número de segundos que puede estar un cliente en el servidor sin haber transferencia de información. TimeoutNoTransfer 600 # el número máximo de segundos que puede estar cliente-servidor sin recibir información de una transferencia (atascado). TimeroutStalled 90 TimeoutIdle 200 #el número máximo de segundos que puede estar un usuario sin hacer nada DisplayLogin inicio.msg #Mensaje de bienvenida DisplayFirstChdir .message ListOptions “-l” denyFilter \*.*⁄ #Es un filtro de protección para el ProFTPd Port 21 #Puerto FTP registrado por la IANA 3 MaxInstances 30 #Número de conexiones al ftp que se pueden hacer a la vez User nobody Group nogroup #Mensajes que se mostrarán si la conexión del usuario es correcta o incorrecta AccessGrantMsg “Login y Password correctos” AccessDenyMsg “Login y password incorrectos” #Número máximo de clientes que pueden estar a la vez en el servidor MaxClients 30 “30 clientes como máximo en el servidor” #Número máximo de clientes por host MaxClientsPerHost 12 “12 clientes como máximo en el servidor” #Número máximo de clientes por usuario MaxClientsPerUser 2 “2 conexiones por usuario” #Le decimos que el directorio del ftp es /home/ftp y a continuación le damos los permisos de lectura y escritura (4+2) al usuario y a los miembros del grupo. Estipulamos que el propietario no tiene ningún permiso (0). <Directory /home/ftp/> Umask 066 066 9 3 IANA: Internet Assigned Numbers Authority 16 iptables -t nat -A PREROUTING -p tcp -d 192.168.16.214 --dport 25 -j DNAT -- to-destination 192.168.200.2:25 iptables -t nat -A PREROUTING -p tcp -d 192.168.16.214 --dport 110 -j DNAT -- to-destination 192.168.200.2:110 # HABILITAMOS SERVICIOS DESDE LA RED INTERNA A LA EXTERNA # DNS # Habilitamos únicamente la consulta DNS a la red externa desde la DMZ donde se encuentra nuestro servidor DNS iptables -A FORWARD -p udp --dport 53 -s $DMZ -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -p udp --sport 53 -d $DMZ -m state --state ESTABLISHED -j ACCEPT # WEB # HTTP 80 iptables -A FORWARD -o eth0 -p tcp --dport 80 -s $INTERNA -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth0 -p tcp --sport 80 -d $INTERNA -m state --state ESTABLISHED -j ACCEPT # HTTPS 443 iptables -A FORWARD -o eth0 -p tcp --dport 443 -s $INTERNA -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth0 -p tcp --sport 443 -d $INTERNA -m state --state ESTABLISHED -j ACCEPT # FTP # Acceso a los servicios FTP de la red externa, aunque en nuestro escenario no va ser posible. # Puerto de datos 20 iptables -A FORWARD -o eth0 -p tcp --dport 20 -s $INTERNA -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth0 -p tcp --sport 20 -d $INTERNA -m state --state ESTABLISHED -j ACCEPT # Puerto de datos 21 iptables -A FORWARD -o eth0 -p tcp --dport 21 -s $INTERNA -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth0 -p tcp --sport 21 -d $INTERNA -m state --state ESTABLISHED -j ACCEPT # SSH # Habilitamos el acceso remoto de la red interna a la red externa 17 iptables -A FORWARD -o eth0 -p tcp --dport 22 -s $INTERNA -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth0 -p tcp --sport 22 -d $INTERNA -m state --state ESTABLISHED -j ACCEPT # CORREO # Habilitamos el servicio SMTP para los usuarios de la red interna iptables -A FORWARD -o eth0 -p tcp --dport 25 -s $INTERNA -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth0 -p tcp --sport 25 -d $INTERNA -m state --state ESTABLISHED -j ACCEPT # Habilitamos el servicio POP3 para los clientes de la red interna iptables -A FORWARD -o eth0 -p tcp --dport 110 -s $INTERNA -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth0 -p tcp --sport 110 -d $INTERNA -m state --state ESTABLISHED -j ACCEPT # HABILITAMOS SERVICIOS DE ENTRADA A LA DMZ DESDE LA EXTERNA (eth0) Y LA INTERNA (eth1) # DNS # Acceso al servidor DNS de la dmz iptables -A FORWARD -p udp --dport 53 -d $servidorDNS -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -p udp --sport 53 -s $servidorDNS -m state --state ESTABLISHED -j ACCEPT # Acceso desde el localhost del firewall iptables -A OUTPUT -p udp --dport 53 -d $servidorDNS -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p udp --sport 53 -s $servidorDNS -m state --state ESTABLISHED -j ACCEPT # WEB # Acceso al servidor WEB de la DMZ desde la red externa y la interna iptables -A FORWARD -i eth0 -p tcp --dport 80 -d $servidorWEB -m state -- state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth1 -p tcp --dport 80 -d $servidorWEB -m state -- state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth2 -p tcp --sport 80 -s $servidorWEB -m state --state ESTABLISHED -j ACCEPT 18 # FTP # Acceso al servidor FTP de la DMZ desde la red externa y la interna puerto de datos #20 iptables -A FORWARD -i eth0 -p tcp --dport 20 -d $servidorFTP -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth1 -p tcp --dport 20 -d $servidorFTP -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth2 -p tcp --sport 20 -s $servidorFTP -m state --state ESTABLISHED -j ACCEPT Puerto de comandos #21 iptables -A FORWARD -i eth0 -p tcp --dport 21 -d $servidorFTP -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth1 -p tcp --dport 21 -d $servidorFTP -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth2 -p tcp --sport 21 -s $servidorFTP -m state --state ESTABLISHED -j ACCEPT # SSH # Acceso al servidor SSH desde la red interna iptables -A FORWARD -i eth1 -p tcp --dport 22 -d $servidorSSH -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth2 -p tcp --sport 22 -s $servidorSSH -m state --state ESTABLISHED -j ACCEPT # Acceso al servidor SSH desde el propio localhost con las cadenas INPUT y OUTPUT iptables -A OUTPUT -p tcp --dport 22 -d $servidorSSH -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --sport 22 -s $servidorSSH -m state --state ESTABLISHED -j ACCEPT # CORREO # Acceso al servidor de correo SMTP de la DMZ desde la red externa y la interna iptables -A FORWARD -i eth0 -p tcp --dport 25 -d $servidorSMTP -m state -- state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth1 -p tcp --dport 25 -d $servidorSMTP -m state -- state NEW,ESTABLISHED -j ACCEPT iptables -A FORWARD -i eth2 -p tcp --sport 25 -s $servidorSMTP -m state -- state ESTABLISHED -j ACCEPT # PROTECCIONES REDUNDANTES # Limitamos el número de conexiones de entrada a 5 conexiones por segundo # Creamos una nueva cadena 19 iptables -N syn-flood iptables -A INPUT -i eth0 -p tcp --syn -j syn-flood iptables -A syn-flood -m limit --limit 1/s --limit-burst 5 -j RETURN iptables -A syn-flood -j DROP # Descartamos los paquetes que no tengan el flag SYN de tcp activado iptables -A INPUT -i eth0 -p tcp ! --syn -m state --state NEW -j DROP iptables -A FORWARD -i eth0 -p tcp ! --syn -m state --state NEW -j DROP Después de hacer el primer test de vulnerabilidades añadimos al Firewall las siguientes líneas: #Deshabilitamos los SYN. iptables –A INPUT –p tcp –d 192.168.200.2 –tcp-flags SYN, FIN SYN,FIN –j LOG –m limit –limit 10/m –log-prefix=”boguspacket” iptables –A INPUT –p tcp –d 192.168.200.2 –tcp-flags SYN, FIN SYN,FIN –j DROP #Nos aseguramos de cerrar puertos que puedan ser una amenza de seguridad iptables –A FORWARD –p tcp –dport $portAUTH –m state –state NEW –j DROP iptables –A FORWARD –p tcp –dport $portNETBIOS_ssn –m state –state NEW –j DROP iptables –A FORWARD –p tcp –dport $portMICRO_ds –m state –state NEW –j DROP 20 C.2 CONFIGURACIÓN FIREWALL ISA SERVER 2004 ENTERPRISE Publicación de los servicios Servidor Web Servidor de correo Servidor SSH Servidor de FTP Servidor DNS General Servidor WEB dmz Servidor MAIL SMTP Server Servidor MAIL POP3 Server Acceso SSH dmz Servidor FTP dmz Acceso DNS dmz Acción Desde Interna Perimetral Externa Interna Externa Interna Externa Interna Local Host Interna Perimetral Externa Interna Perimetral Externa Hacia 192.168.200.2 192.168.200.2 192.168.200.2 192.168.200.2 192.168.200.2 192.168.200.2 Tráfico http SMTP Server POP3 Server Telnet Server FTP DNS Server Horas Siempre Siempre Siempre Siempre Siempre Siempre Redes Listener Externa Interna Perimetral #80 Externa Interna Perimetral Externa Interna Perimetral Interna Local Host Externa Interna Perimetral #21 Interna Perimetral Externa Nombre público http://www.tfc.es http://ftp.tfc.es Bridging http port: 80 ssl port: 443 ftp port: 21 Usuarios Todos Todos 21 Política de reglas del Firewall y política aplicada por defecto Servidor Web Servidor de correo Servidor SSH Servidor FTP Servidor DNS Regla por defecto General Acceso web DMZ Acceso web externo Acceso mail DMZ Acceso mail externo Acceso ssh DMZ Acceso ftp DMZ Acceso ftp externo Acceso dns Denegación Acción Desde Interna Perimetral Externa Interna Interna Perimetral Externa Interna Interna Local Host Interna Local Host Perimetral Externa Interna Perimetral Interna Local Host Perimetral Todas las redes (incluida Local Host) Hacia Perimetral Externa Perimetral Externa Perimetral Externa Perimetral Externa Externa Perimetral Todas las redes (incluida Local Host) Horas Siempre Siempre Siempre Siempre Siempre Siempre Siempre Siempre Siempre Protocolos HTTP HTTPS HTTP HTTPS POP3 SMTP POP3 SMTP SSH FTP FTP DNS Todo el tráfico Usuarios Todos Todos Usuarios autenticados Todos Usuarios autenticados Todos Todos Todos Todos Tipos de contenido Todos Todos Todos Todos Todos Todos Todos Todos Todos 22 Como podemos ver en la tabla anterior hemos configurado dos reglas de acceso para todos los servicios a excepción del servidor dns y del ssh; una que habilita el tráfico al mismo servicio pero en la red externa y otro a nuestro servidor de la DNS. Sin embargo, para los servicios de dns y ssh no es necesario crear dos reglas porque en el primero también permitimos el tráfico de la red perimetral a la externa, y para el segundo caso lo deshabilitamos. 23 C.3 CONFIGURACIÓN FIREWALL PACKET FILTER # Declaración de variables # Interfaces int_externa=”xl0” int_dmz=”rl0” int_interna=”rl1” # Redes red_externa=”192.168.16.0/24” red_dmz=”192.168.200.0/24” red_interna=”192.168.100.0/24” # Definimos lista de servicios de la DMZ a los que se podrá acceder; servicios TCP y UDP serv_TCP= { www, ssh, ftp, smtp, pop3 }” serv_UDP=”{ domain }” servidorDMZ=”192.168.200.2” # 1.OPCIONES # Definimos el comportamiento de la política de negación, para que cuando se bloquee un paquete TCP se envíe un paquete RSP y para el resto un paquete ICMP Unrecheable. set block-policy return # 2. SCRUB # Normalización de los paquetes scrub in all # 3. NAT # Servicio NAT en la red DMZ nat on $int_externa from $int_dmz:network to any Æ $int_externa # Servicio NAT en la red interna nat on $int_externa from $int_interna:network to any Æ $int_externa # 4. REGLAS DE FILTRADO # Establecemos la política por defecto block log all # Habilitamos el tráfico en el localhost del firewall pass quick on lo0 all 24 # Habilitamos los servicios TCP y UDP de la DMZ tanto para clientes de la red interna como de la externa # Servicios TCP { www, ssh, ftp, smtp, pop3 } pass in quick on $int_externa inet proto tcp from $red_externa to $servidorDMZ port $serv_TCP flags S/SA keep state pass in quick on $int_interna inet proto tcp from $red_interna to $servidorDMZ port $serv_TCP flags S/SA keep state #Habilitamos el tráfico de vuelta pass out quick on $int_dmz inet proto tcp from $red_externa flags S/SA keep state pass out quick on $int_dmz inet proto tcp from $red_interna flags S/SA keep state # Servicios UDP { domain } pass in quick on $int_externa inet proto udp from $red_externa to $servidorDMZ port $serv_UDP keep state pass in quick on $int_interna inet proto udp from $red_interna to $servidorDMZ port $serv_UDP keep state # Habilitamos el tráfico de vuelta para los puertos estándares de los servicios UDP de la DMZ tanto para la red externa como para la interna pass out quick on $int_dmz inet proto udp from $red_externa keep state pass out quick on $int_dmz inet proto udp from $red interna keep state # Habilitamos el tráfico en los puertos TCP al exterior para los usuarios de la red interna pass out quick on $int_externa from any keep state pass out on &int_externa proto tcp from $red_interna to $red_externa port $serv_TCP flags S/SA keep state # Habilitamos además que el servidor DMZ pueda hacer consultas NDS p pass out on $int_externa proto udp from $servidorDMZ to $red_externa port $serv_UDP keep state # Tráfico de vuelta por el puerto 53 a servidores secundarios pass in on $int_interna from $int_interna:network to any keep state pass in on $int_dmz from $int_dmz:network to any keep state # Antispoof, para las interfaces externa, interna y dmz antispoof log quick for { $int_externa, $int_interna, $int_dmz } 25 ANEXO III: TABLAS DE DETECCIÓN DE VULNERABILIDADES A. Tabla de detección de vulnerabilidades Firewall Iptables Servidor Web Type Port Issue and Fix Informational www (80/tcp) A web server is running on this port Nessus ID : 10330 Informational www (80/tcp) An HTTP proxy is running on this port Nessus ID : 10330 Informational www (80/tcp) The following directories were discovered: /cgi-bin, /icons, /images While this is not, in and of itself, a bug, you should manually inspect these directories to ensure that they are in compliance with company security standards Other references : OWASP:OWASP-CM-006 Nessus ID : 11032 Informational www (80/tcp) The remote webserver supports the TRACE and/or TRACK methods. TRACE and TRACK are HTTP methods which are used to debug web server connections. It has been shown that servers supporting this method are subject to cross-site-scripting attacks, dubbed XST for "Cross-Site-Tracing", when used in conjunction with various weaknesses in browsers. An attacker may use this flaw to trick your legitimate web users to give him their credentials. 32 Informational smtp (25/tcp) smtpscan was not able to reliably identify this server. It might be: Sendmail 8.11.0/8.9.3 Sendmail 8.11.6 Sendmail 8.12.3 Sendmail 8.12.11/8.12.11 Sendmail Switch-2.2.0 Sendmail 8.11.6p2/8.11.6 -112Sendmail 8.12.8/8.11.6 -72Postfix 2.0.7 Sendmail 8.11.6/8.11.6 -34Sendmail 8.12.6/8.12.6 Sendmail 8.11.6+Sun/8.9.3 Sendmail 8.11.6p2/8.11.6 Sendmail 8.11.0/8.11.0 Sendmail 8.12.3/8.12.3/SuSE Linux 0.6 Sendmail 8.12.8/8.11.6 -68Sendmail 8.11.6 Sendmail 8.11.6p2/8.11.6 -145Sendmail 8.12.2/8.12.2/SideWinder Firewall Sendmail 8.12.8/8.11.4 (2Fast Internet Services) Sendmail 8.11.6p2/8.11.6 -134The fingerprint differs from these known signatures on 2 point(s) If you known precisely what it is, please send this fingerprint to [email protected] : :503:501:501:250:553:250:550:502:252:250:502:502:502:250:250 Nessus ID : 11421 Servidor SSH Type Port Issue and Fix Informational ssh (22/tcp) An ssh server is running on this port Nessus ID : 10330 Informational ssh (22/tcp) Remote SSH version : SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4 Remote SSH supported authentication : publickey,keyboard-interactive 33 Nessus ID : 10267 Informational ssh (22/tcp) The remote SSH daemon supports the following versions of the SSH protocol : . 1.99 . 2.0 SSHv2 host key fingerprint : 49:5b:16:2f:52:14:c1:85:3d:67:fd:1c:66:1c:cb:5d Servidor FTP Type Port Issue and Fix Informational ftp (21/tcp) An FTP server is running on this port. Here is its banner : 220 ProFTPD 1.2.10 Server (ftp) Nessus ID : 10330 Warning ftp (21/tcp) The remote ProFTPd server is as old or older than 1.2.10 It is possible to determine which user names are valid on the remote host based on timing analysis attack of the login procedure. An attacker may use this flaw to set up a list of valid usernames for a more efficient brute-force attack against the remote host. Solution : Upgrade to a newer version Risk factor : Low CVE : CAN-2004-1602 BID : 11430 Nessus ID : 15484 34 Servidor DNS Type Port Issue and Fix Informational domain (53/tcp) A DNS server is running on this port. If you do not use it, disable it. Risk factor : Low Nessus ID : 11002 Informational domain (53/tcp) BIND 'NAMED' is an open-source DNS server from ISC.org. Many proprietary DNS servers are based on BIND source code. The BIND based NAMED servers (or DNS servers) allow remote users to query for version and type information. The query of the CHAOS TXT record 'version.bind', will typically prompt the server to send the information back to the querying source. The remote bind version is : 8.4.6-REL-NOESW Solution : Using the 'version' directive in the 'options' section will block the 'version.bind' query, but it will not log such attempts. Nessus ID : 10028 35 C. Tabla de detección de vulnerabilidades Firewall Packet Filter Servidor Web Type Port Issue and Fix Informational www (80/tcp) A web server is running on this port Nessus ID : 10330 Warning www (80/tcp) It seems that your web server tries to hide its version or name, which is a good thing. However, using a special crafted request, Nessus was able to determine that is is running : Apache/1.3.33 Risk factor : None Solution : Fix your configuration. Nessus ID : 11239 Servidor Correo Type Port Issue and Fix Informational smtp (25/tcp) An SMTP server is running on this port Here is its banner : 220 localhost.localdomain ESMTP Sendmail 8.13.4/8.13.4/Debian-3; Tue, 9 Aug 2005 23:58:17 +0200; (No UCE/UBE) logging access Nessus ID : 10330 Warning smtp (25/tcp) 36 The remote SMTP server answers to the EXPN and/or VRFY commands. The EXPN command can be used to find the delivery address of mail aliases, or even the full name of the recipients, and the VRFY command may be used to check the validity of an account. Your mailer should not allow remote users to use any of these commands, because it gives them too much information. Solution : if you are using Sendmail, add the option : O PrivacyOptions=goaway in /etc/sendmail.cf. Risk factor : Low CVE : CAN-1999-0531 Nessus ID : 10249 Vulnerability smtp (25/tcp) The remote SMTP server did not complain when issued the command : MAIL FROM: |testing This probably means that it is possible to send mail that will be bounced to a program, which is a serious threat, since this allows anyone to execute arbitrary commands on this host. *** This security hole might be a false positive, since *** some MTAs will not complain to this test, but instead *** just drop the message silently Solution : upgrade your MTA or change it. Risk factor : High CVE : CVE-1999-0203 BID : 2308 Nessus ID : 10258 37 Servidor FTP Type Port Issue and Fix Informational ftp (21/tcp) An FTP server is running on this port. Here is its banner : 220 ProFTPD 1.2.10 Server (ftp) Nessus ID : 10330 Warning ftp (21/tcp) The remote ProFTPd server is as old or older than 1.2.10 It is possible to determine which user names are valid on the remote host based on timing analysis attack of the login procedure. An attacker may use this flaw to set up a list of valid usernames for a more efficient brute-force attack against the remote host. Solution : Upgrade to a newer version Risk factor : Low CVE : CAN-2004-1602 BID : 11430 Nessus ID : 15484 Servidor SSH Type Port Issue and Fix Informational ssh (22/tcp) An ssh server is running on this port Nessus ID : 10330 Informational ssh (22/tcp) Remote SSH version : SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.4 38 Remote SSH supported authentication : publickey,keyboard-interactive Nessus ID : 10267 Informational ssh (22/tcp) The remote SSH daemon supports the following versions of the SSH protocol : . 1.99 . 2.0 SSHv2 host key fingerprint : 49:5b:16:2f:52:14:c1:85:3d:67:fd:1c:66:1c:cb:5d Servidor DNS Type Port Issue and Fix Informational domain (53/tcp) A DNS server is running on this port. If you do not use it, disable it. Risk factor : Low Nessus ID : 11002 Informational domain (53/tcp) BIND 'NAMED' is an open-source DNS server from ISC.org. Many proprietary DNS servers are based on BIND source code. The BIND based NAMED servers (or DNS servers) allow remote users to query for version and type information. The query of the CHAOS TXT record 'version.bind', will typically prompt the server to send the information back to the querying source. The remote bind version is : 8.4.6-REL-NOESW Solution : Using the 'version' directive in the 'options' section will block the 'version.bind' query, but it will not log such attempts. Nessus ID : 10028 39