Proyecto Integración Servidor Proxy en una red emulada PDF

Title Proyecto Integración Servidor Proxy en una red emulada
Author Laura Gimeno
Course Informatica
Institution UNED
Pages 70
File Size 6.8 MB
File Type PDF
Total Downloads 28
Total Views 145

Summary

Download Proyecto Integración Servidor Proxy en una red emulada PDF


Description

Integración de un servidor proxy en una red emulada con una DMZ bastionada Proyecto de final de curso. Formación de grado profesional superior en Adminstración de sistemas informáticos y redes Autora: Laura Gimeno Villanueva

ÍNDICE DE CONTENIDOS ÍNDICE DE CONTENIDOS.......................................................................................................................................... 1 1- DEFINICIÓN DEL TEMA O PROBLEMA.................................................................................................................. 1 2- RESOLUCIÓN Y JUSTIFICACIÓN............................................................................................................................ 2 3- ESTUDIO DE VIABILIDAD DEL PROYECTO............................................................................................................. 4 3.1 – Definición de las características específicas del proyecto..........................................4 3.1.1 – Elementos de la red............................................................................................................................4 DMZ.......................................................................................................................................................4 Servidores Internos...............................................................................................................................5 Usuarios de cable y wifi-staff................................................................................................................5 Firewall..................................................................................................................................................5 Seervidor Proxy.....................................................................................................................................5 3.2 – Necesidades del mercado o sector productivo...........................................................5 3.3– Fases........................................................................................................................... 6 3.1 – Recursos necesarios................................................................................................... 6 3.5 – Presupuesto................................................................................................................ 7 3.1 – Financiación............................................................................................................... 8

4- IMPLEMENTACIÓN (PUESTA EN FUNCIONAMIENTO)........................................................................................... 9 4.1 – Prevención de riesgos laborales................................................................................. 9 4.2 – Procedimientos de actuación o ejecución.................................................................10 4.2.1 – Desarrollo técnico............................................................................................................................10 4.2.1.1 – Desarrollo del escenario y creación de la red...............................................................................10 4.2.1.1.1 – Configuración de las máquinas.........................................................................................13 Sistema operativo instalado................................................................................................................13 Instalación de las Guest Additions......................................................................................................13 Nombres de equipo proporcionados..................................................................................................14 Direccionamiento IP............................................................................................................................14 Servidor de correo..............................................................................................................................17 Servidor ftp.........................................................................................................................................20 Servidor web.......................................................................................................................................21 Servidor DNS.......................................................................................................................................21 4.2.1.1.2 - Configuración de los firewall.............................................................................................23 Firewall externo.................................................................................................................................27 Firewall interno..................................................................................................................................31 4.2.1.2 – Configuraciones en los Firewall para la integración del servidor proxy........................................33 4.2.1.2.1 – Firewall externo................................................................................................................33 4.2.1.2.1 – Firewall interno.................................................................................................................39 4.2.1.3 – Configuración del proxy.................................................................................................................40

4.2.1.3.3 – Pruebas de funcionamiento y análisis del tráfico......................................................................48 4.3 – Control de calidad, cumplimiento del pliego de condiciones....................................48

5- CONCLUSIONES................................................................................................................................................. 56 BIBLIOGRAFÍA Y WEBGRAFÍA................................................................................................................................. 58 ANEXO I................................................................................................................................................................. 60 I.1 – FIREWALL O CORTAFUEGOS....................................................................................... 60 I.1.1 – Definición..........................................................................................................................................60 I.1.2 – Tipos de Firewall...............................................................................................................................60 Firewall de Software:..........................................................................................................................61 Firewall de Hardware:.........................................................................................................................61 Firewall de filtrado de paquetes:........................................................................................................61 Firewall de nivel de aplicación:...........................................................................................................61 Firewall híbrido...................................................................................................................................62 Firewall de inspección de estados o Stateful Inspection Firewall.......................................................62 I.2 – SERVIDOR PROXY....................................................................................................... 62 I.2.1 – Definición..........................................................................................................................................62 I.2.2 – Tipos de proxy...................................................................................................................................63 Proxy local o dedicado:.......................................................................................................................63 Proxy compartido:...............................................................................................................................63 Proxy caché:........................................................................................................................................64 Proxy web:...........................................................................................................................................64 Proxy SSL:............................................................................................................................................64 I.3 – DMZ........................................................................................................................... 65 I.3.1 – DMZ bastionada................................................................................................................................67

Laura Gimeno Villanueva

1- DEFINICIÓN DEL TEMA O PROBLEMA De forma generalizada los servidores ubicados en una DMZ son accesibles desde el exterior de la red en la que se encuentran, convirtiéndose, en consecuencia, en uno de sus puntos más vulnerables y expuestos. Establecer políticas y medidas de seguridad sobre cómo se accede a los servicios que proporcionan es un imprescindible, esto es, hay que controlar las conexiones desde el exterior hacia la DMZ; a ello se le añade que, las necesidades reales que pueden ocasionarse en el día a día o momentos puntuales conllevan a que sean estos quienes inicien una comunicación con el exterior. Sucede ello también con servidores de redes internas, los cuales, a diferencia de la zona desmilitarizada, nunca deberían poder ser accedidos desde fuera. Este último hecho -el inicio de una comunicación por parte de un servidor, bien situado en la DMZ o en una zona interna- que no es en absoluto deseable y no debería darse, es el eje central sobre la problemática que se va a abordar en el presente trabajo. El escenario en el que se inserta es el existente en una hipotética organización, es decir, es un entorno con una red ya creada, configurada y en pleno funcionamiento. En la misma existen principalmente tres zonas diferenciadas: la red interna, compuesta por la zona de servidores internos, usuarios de cable y wifi staff; la red “externa”, compuesta por la conexión a la red pública de Internet; y la DMZ, ubicada entre la zona externa e interna.

Imagen 1: Esquema de red en capa 3

Es en la zona DMZ y la de servidores internos dónde existen una serie de servicios y/o softwares que necesitan ser actualizados y dónde, evidentemente, se presenta la problemática anteriormente descrita. Hasta ahora, en el escenario supuesto tales actualizaciones se venían realizando de manera manual en aquellos casos posibles o a

Implementación de un servidor proxy en una red emulada con una DMZ bastionada

través de un proxy apt-cacher; sin embargo, cómo abordar las actualizaciones basadas en repositorios pip (pyton), gems (ruby), npm (node.js), entre otros, manteniendo una coherencia en las dependencias y sin que ello suponga una dedicación de tiempo excesivo y evitable para la persona encargada de su administración y mantenimiento, o cómo gestionar las consultas a servidores externos necesarias, periódicas y constantes, sin que suponga una falta de control y seguridad, son sólo algunos de los ejemplos existentes necesarios a tratar y aún por abordar. Por este motivo, la organización busca una solución a adoptar y una evaluación de la misma de forma que pueda valorar si desarrollarla.

2- RESOLUCIÓN Y JUSTIFICACIÓN Como modo de gestionar las salidas de los servidores de la DMZ y de la red interna, se opta por la utilización de un servidor proxy de aplicación, tendrá que ser capaz de entender los protocolos HTTP y HTTPS, tener funcionalidad caché y se convertirá en transparente. El software que se utilizará será proxy Squid sobre Ubuntu 18.04, Squid se trata de un software libre bajo licencia GPL que cumple y amplía estos requisitos. Las propias características de este tipo de servidores (ver anexo1 de este mismo documento) lo convierten en una solución óptima: - Al actuar como intermediario en las peticiones, los servidores no estarán nunca en contacto directo con el exterior, de forma que se establece una capa añadida de seguridad a las ya existentes y se resuelve el problema principal. - Se podrán anonimizar las direcciones ip reales de los servidores, no dejando rastro de ellas e impidiendo así su identificación. (En lo real, las ip’s que identifican los “servicios” de los servidores de la DMZ en Internet, son ip’s públicas nateadas que en ningún caso dan acceso al servidor en su completo) - Se podrá configurar un mantenimiento adecuado de la memoria caché del proxy para acelerar las consultas y evitar salidas a internet innecesarias. - Se podría monitorizar de manera centralizada el flujo del tráfico y tener un control de los logs, así como combinar su uso junto con un IDS, en consecuencia, ello también supone un mayor control sobre lo que ocurre en la red y permitirá actuar ante posibles vulneraciones de la seguidad. - Ante futuras necesidades, bastará modificar la configuración del proxy para satisfacerlas. Ya que ofrece la posibilidad de extender su utilización más allá de las necesidades iniciales que motivan su implementación.

Respecto a dónde se propone ubicar el servidor proxy, se muestra a continuación el esquema de red en capa 3 de la imagen 1, con la que se ha valorado la mejor ubicación:

Laura Gimeno Villanueva

Imagen 2: Esquema de red en capa 3 con servidor proxy

Los motivos de la elección son varios y están determinados por la idea de que a través del servidor proxy debe pasar sí o sí todo el tráfico que deba salir desde los servidores de la DMZ y de la red de servidores internos hacia la red externa. Con esta ubicación: - Con un correcto añadido de reglas en el Firewall externo se podrá redirigir el tráfico proveniente y deseado de estas dos zonas, de forma que esté siempre obligado a pasar a través del proxy y sea, en principio, ineludible. - Al no tratarse de un “camino” de paso obligatorio de todo el tráfico generado en la red, sino que, como se decía en el punto inmediatamente previo, se escoge, se evita un exceso de peticiones y una sobrecarga del servidor. - El servidor proxy no está conectado directamente al router, sus dos interfaces se conectan al firewall que actúa como una barrera de seguridad también para él. Para valorar el impacto de la implementación del servidor y analizar la configuración más óptima a adoptar según el escenario existente, se desarrollará una emulación parcial de la infraestructura haciendo uso de la virtualización, construyendo y generando un escenario de pruebas. Las construcción de un escenario paralelo al entorno de producción permite no interferir en el normal funcionamiento de este último, proporciona flexibilidad a la hora de realizar configuraciones así como la posibilidad de construir distintas versiones, posibilita someter a ataques o probar la correcta configuración del servicio con anterioridad a un despliegue en el entorno real y, ante fallos o la adopción de configuraciones inadecuadas se podrá proceder a su completitud y corrección previa. Todo ello sin exponer lo real a ningún tipo de riesgo y detención en ningún momento.

Implementación de un servidor proxy en una red emulada con una DMZ bastionada

3- ESTUDIO DE VIABILIDAD DEL PROYECTO. 3.1 – Definición de las características específicas del proyecto Como se viene exponiendo, el objetivo del proyecto es valorar cómo realizar la intergración de un servidor proxy squid en un escenario ya existente y analizar la configuración más óptima a adoptar para gestionar las inevitables salidas a Internet por parte de servidores presentes en una DMZ bastionada y la zona de servidores internos. Para ello se emularán parcialmente elementos de la red haciendo uso de la virtualización y, en el escenario virtual, se adoptarán las configuraciones pertinentes para el servidor proxy así como en el resto de host que forman la red. Para su consecución destacan algunos requerimientos: - Comprensión del funcionamiento de las redes informáticas. - La capacidad de identificar, seleccionar y abstraer los elementos necesarios de la red que están relacionados con la materia. - Conocimientos sobre el funcionamiento del sistema operativo ubuntu. - Conocimientos en el funcionamiento del software de virtualización y posibles herramientas adicionales para reproducir los elementos de la red seleccionados. - Entendimiento de los servicios presentes en los elementos de la red así como sus protocolos subyacentes. - La configuración de Firewalls entendiendo iptables. - La configuración de un servidor proxy squid. - El análisis del tráfico a nivel de red.

3.1.1 – Elementos de la red. La topología de red en capa 3 y la solución aportada se puede observar en la Imagen2. Salvo que se indique lo contrario, todos los host utilizan Ubuntu 16.04, sistema operativo de distribución de Linux y basado en la arquitectura de Debian. Tal y cómo ya se ha comentado, en el escenario planteado existen distintas zonas diferenciadas, en este apartado se describen ciertas características específicas de cada una de ellas.

DMZ La zona DMZ posee la dirección de red 172.16.20.0/24. En ella se encuentran distintos servicios que pueden ser accedidos desde el exterior. Por definición, la zona DMZ no podrá acceder a la parte interna de la red ni acceder, excepto las salvedades que se configurarán, a Internet. En ella están presentes un servidor web, un servidor de DNS, un servidor de correo y un servidor FTP. En estos servidores es dónde encontramos aplicaciones y microservicios programados en phyton, nodejs y Ruby que utilizan paquetes y librerías que pueden ser administradas mediante los sistemas de gestión de paquetes que les son propios: pip, npm y RubyGems respectivamente. - Servidor web: configurado con Apache HTTP Server aloja la página web propia de la organización, la misma cuenta con distintos módulos y aplicaciones. Apache HTTP Server, según se traduce de la página web oficial, “es un servidor HTTP de código abierto para sistemas operativos como UNIX, Windows, Mac OS/X y netware. El objetivo de este proyecto es proveer un servidor seguro, eficiente y extensible que provee servicios HTTP de acuerdo con los estándares actuales de HTTP”. Programado en C, consta de una estructura modular, con una sección core y diversos módulos que le aportan funcionalidad, a ellos se le añade la posibilidad de introducir módulos externos para el uso de páginas dinámicas en Perl, PHP, Phyton, Ruby y Mono entre otros. Basándose en el protocolo HTTP el servidor escuchará por el puerto 80 / TCP y por el puerto 443 / TCP cuando se trata de HTTPS. Del protocolo HTTP existen

Laura Gimeno Villanueva distintos documentos para el estudio de su funcionamiento, aquí se plasman únicamente algunas generalidades por su evidente relación con el servidor web, como que está soportado sobre los servicios de conexión TCP/IP y que es un protocolo sin estado, esto es, no guarda información sobre las conexiones anteriores; si bien, se conoce como sesión HTTP a una secuencia de solicitudes entre un cliente y un servidor, estas solicitudes y respuestas es en lo que se basa su funcionamiento. La primera petición por parte de un cliente hacia un servidor web, suele hacerse a través de una URL, de forma cotidiana las URL se componen con el nombre de dominio del servidor web. - Servidor DNS: configurado con bind9, software de licencia BSD altamente utilizado en sistemas operativos UNIX. Se encarga de la resolución de nombres de dominio de los dispositivos de la red. Sus reenviadores apuntan a los servidores DNS de “Comodo Secure DNS” cuyas direcciones de red se corresponden con: 8.26.56.26 y 8.20.247.20 - Servidor FTP: utiliza vsftpd, software de servidor FTP para sistemas UNIX, de licenca GPL y con soporte para SSL.

Servidores Internos La dirección de red de los servidores internos se corresponde con: 172.16.0.0/24. Los servidores internos tienen la función de proporcionar servicios a nivel interno de la organización,...


Similar Free PDFs