Estudio, diseño e implantación de un cortafuegos UTM libre para pequeñas organizaciones

ESCUELA DE INGENIER´ IA INFORM´ ATICA GRADO EN INGENIER´ IA INFORM ´ ATICA MENCI´ ON EN INGENIER´ IA DE SOFTWARE Estudio, dise˜no e implantaci´on de un cortafuegos UTM libre para peque˜nas organizaciones Alumno: Patricia Sanz Marcos ESCUELA DE INGENIER´ IA INFORM´ ATICA GRADO EN INGENIER´ IA INFORM ´ ATICA MENCI´ ON EN INGENIER´ IA DE SOFTWARE Estudio, dise˜no e implantaci´on de un cortafuegos UTM libre para peque˜nas organizaciones Alumno: Patricia Sanz Marcos Tutor: Jes´us M. Vegas Hern´andez A todos con los que he compartido esta etapa, pero en especial a Fran y a David. I II AGRADECIMIENTOS Agradecimientos En primer lugar, a ISEND por haberme ofrecido esta oportunidad y por las facilidades aportadas, y a mi tutor Jes´us M. por toda la ayuda y consejos que me ha dado durante esta etapa. En segundo lugar, a mi familia, que me ha estado apoyando durante todo momento, en especial a mi hermano. Tambi´en me gustar´ıa expresar a mi agradecimiento a mi pareja, Fran, y mis amigos que no ha dejado que me desmotive en ning´un momento. A todos ellos, mil gracias. III AGRADECIMIENTOS IV RESUMEN Resumen Este documento describe el proceso de an´alisis e implantaci´on de seguridad en una infraestructura real, en la cual, despu´es del router de entrada, todo el tr´afico es gestionado a trav´es de un firewall. Este documento se centrar´a en las carencias de la infraestructura, siendo la mayor de estas un firewall propiamente configurado y actualizado. Se realizar´a un estudio con el objeto de aportar una soluci´on de bajo coste al problema. Para ello se estudiar´an diferentes firewalls open source y gratuitos que hay en el mercado, y se instalar´a y realizar´a la configuraci´on adecuada para disponer de todos los servicios necesarios de una red, donde los usuarios puedan trabajar de forma c´omoda, segura, y controlada. V ´ INDICE GENERAL 4.10.Gruposdeusuarios................................. 65 4.11.CasosdeUso .................................... 66 5. Dise˜no de la Soluci´on 77 5.1. Introducci´on..................................... 77 5.2. Elecci´ondelaUTM ................................ 77 5.3. Elecci´ondelHardware ............................... 78 5.4. Arquitectura .................................... 79 5.5. Elementosdelared ................................ 80 5.6. Configuraci´on de los elementos principales . . . . . . . . . . . . . . . . . . . . 82 5.7. Accesos al equipo pfSense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 5.7.1. Acceso seguro al configurador web de pfSense . . . . . . . . . . . . . . 82 5.8. Acceso a pfSense mediante ssh y ssh-agent . . . . . . . . . . . . . . . . . . . 84 5.9. Reglasdefirewall.................................. 85 5.10. Reglas de redirecci´on NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.11. Acceso a la red por parte de los usuarios: Asignaci´on de direcciones . . . . . . 87 5.11.1. Conexi´on remota: OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 88 5.12. Limitadores de ancho de banda . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.13. Control de tr´afico web: Squid, SquidGuard . . . . . . . . . . . . . . . . . . . . 89 5.13.1. Control del tr´afico por capa de aplicaci´on: IDS . . . . . . . . . . . . . 90 5.13.2. Bloqueador de malware: pfBloquerNG . . . . . . . . . . . . . . . . . . 90 6. Implantaci´on en el Entorno de Pruebas 91 6.1. Preparaci´on del entorno de pruebas . . . . . . . . . . . . . . . . . . . . . . . . 91 6.2. Configuraci´on de las interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 92 6.2.1. Acceso seguro al configurador web de pfSense . . . . . . . . . . . . . . 93 6.3. Acceso a pfSense mediante ssh y ssh-agent . . . . . . . . . . . . . . . . . . . 98 XII ´ INDICE GENERAL 6.4. Reglasdefirewall.................................. 99 6.5. Reglas de redirecci´on NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 6.6. Asignaci´on de direcciones a usuarios y WoL . . . . . . . . . . . . . . . . . . . 102 6.6.1. Conexi´on remota: OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 102 6.7. Limitadores de ancho de banda . . . . . . . . . . . . . . . . . . . . . . . . . . 104 6.8. Control de tr´afico web: Squid, SquidGuard . . . . . . . . . . . . . . . . . . . . 105 6.8.1. Configuraci´on de Squid cache . . . . . . . . . . . . . . . . . . . . . . . 105 6.8.2. Configuraci´on del modo transparente en Squid . . . . . . . . . . . . . 106 6.8.3. Configuraci´on de SquidGuard . . . . . . . . . . . . . . . . . . . . . . . 108 6.8.4. Configuraci´on de LightSquid . . . . . . . . . . . . . . . . . . . . . . . 108 6.9. Control del tr´afico por capa de aplicaci´on: IDS . . . . . . . . . . . . . . . . . 109 6.10. Bloqueador de malware: pfBlockerNG . . . . . . . . . . . . . . . . . . . . . . 110 7. Integraci´on, Pruebas y Evaluaci´on 113 7.1. Integraci´on ..................................... 113 7.1.1. Integraci´on: Fase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 7.1.2. Integraci´on: Fase 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 7.2. Test ......................................... 114 7.3. Evaluaci´on comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 8. Conclusiones y Trabajo Futuro 121 A. Adjuntos 123 Bibliograf´ıa 125 XIII ´ INDICE GENERAL XIV ´ INDICE DE FIGURAS ´ Indice de figuras 2.1. Fases de un Plan Director de Seguridad . . . . . . . . . . . . . . . . . . . . . 6 2.2. Desarrollo legal de ciberseguridad en pymes. Espa˜na.[8] . . . . . . . . . . . . 8 2.3. Relaci´on entre amenaza, vulnerabilidad y riesgo dentro de un sistema[11] . . 10 2.4. Fases del an´alisis de riesgos[11] . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. Niveles de defensa en profundidad[11] . . . . . . . . . . . . . . . . . . . . . . 15 2.6. Esquema org´anico de una UTM . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.7. Flujo de datos y operaci´on en una UTM . . . . . . . . . . . . . . . . . . . . . 17 2.8. Clasificaci´on de los IDS[12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.9. Flujo de funcionamiento en NIDS [15] . . . . . . . . . . . . . . . . . . . . . . 20 2.10. Alcance de los modos de Squid [16] . . . . . . . . . . . . . . . . . . . . . . . . 22 2.11. Arquitectura HTTPS[53] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.12. Flujo de operaciones SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.13. Flujo operaciones SSH con autenticaci´on de usuario por clave . . . . . . . . . 25 2.14. Vulnerabilidades por a˜no FreeBSD[43], Linux[44] seg´un el CVE . . . . . . . . 26 2.15. Vulnerabilidades por a˜no Snort[45], Suricata[46] seg´un CVE . . . . . . . . . . 28 3.1. CiclodevidaUP.................................. 33 3.2. Diagrama Gantt de las fases del proyecto . . . . . . . . . . . . . . . . . . . . 35 3.3. Remuneraciones medias en ciberseguridad, Espa˜na 2021[19] . . . . . . . . . . 39 XV ´ INDICE DE FIGURAS 4.1. arquitectural´ogica ................................. 44 4.2. arquitecturadelared ............................... 48 4.3. Conexionesentreracks............................... 48 4.4. Conexiones al switch central . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.5. FiltradomedianteACL .............................. 57 4.6. Vulnerabilidades CVE - infodesain . . . . . . . . . . . . . . . . . . . . . . . . 59 4.7. Vulnerabilidades CVE por tipo - infodesain . . . . . . . . . . . . . . . . . . . 60 4.8. Vulnerabilidades test OpenVas Default - infodesain . . . . . . . . . . . . . . . 60 4.9. Vulnerabilidades en puerto 443 y 8000 - infodesain . . . . . . . . . . . . . . . 62 4.10. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 4.11. Diagrama de casos de uso, detalle gesti´on y monitorizaci´on de las ´areas . . . 67 5.1. Red interna para pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 5.2. Cadena de confianza de certificados[54] . . . . . . . . . . . . . . . . . . . . . . 84 5.3. Acceso al webconfigurator mediante HTTPS . . . . . . . . . . . . . . . . . . . 84 5.4. conexi´on VPN empleado con escritorio remoto . . . . . . . . . . . . . . . . . 88 5.5. Repartici´on del ancho de banda para usuarios de la red 5.1 . . . . . . . . . . 89 6.1. Configuraci´on de interfaces mediante consola . . . . . . . . . . . . . . . . . . 92 6.2. wizardconfiguraci´on ................................ 94 6.3. Configuraci´on CA ra´ız para HTTPS . . . . . . . . . . . . . . . . . . . . . . . 95 6.4. Configuraci´on CA intermedia ra´ız para HTTPS . . . . . . . . . . . . . . . . . 96 6.5. Configuraci´on certificado de servidor para HTTPS . . . . . . . . . . . . . . . 97 6.6. Configuraci´on acceso t´unel SSH + par-clave . . . . . . . . . . . . . . . . . . . 98 6.7. Acceso mediante SSH + par-clave . . . . . . . . . . . . . . . . . . . . . . . . . 98 6.8. Reglas de firewall en la interfaz LAN . . . . . . . . . . . . . . . . . . . . . . . 99 6.9. Reglas de firewall en la interfaz DMZ . . . . . . . . . . . . . . . . . . . . . . . 100 XVI ´ INDICE DE FIGURAS 6.10. Reglas de firewall en la interfaz WAN . . . . . . . . . . . . . . . . . . . . . . 100 6.11. Reglas de Port Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 6.12. Reglas de firewall para poder realizar port forward . . . . . . . . . . . . . . . 102 6.13. configuraci´on de OpenVPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.14. asignaci´on de certificado a usuario. . . . . . . . . . . . . . . . . . . . . . . . . 104 6.15. Alias para las direcciones del limiter . . . . . . . . . . . . . . . . . . . . . . . 105 6.16. Patr´on para cachear actualizaciones de Windows . . . . . . . . . . . . . . . . 106 6.17. Configuraci´on General de Squid 1 . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.18. Configuraci´on General de Squid 2 . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.19. Regla para forzar el paso por DNS de pfSense . . . . . . . . . . . . . . . . . . 108 6.20.Gruporestringido.................................. 108 6.21. WAN configuraci´on Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.22.LicenciaGeoIP ................................... 111 6.23. Selecci´on de pa´ıses a bloquear con GeoIP . . . . . . . . . . . . . . . . . . . . 111 XVII ´ INDICE DE FIGURAS XVIII ´ INDICE DE TABLAS ´ Indice de tablas 2.1. Comparativa de UTMs libres [38, 40, 41, 42] . . . . . . . . . . . . . . . . . . . 26 2.2. Comparativa de caracter´ısticas principales . . . . . . . . . . . . . . . . . . . . 28 2.3. Comparativa de caracter´ısticas principales de protocolos VPN[47] . . . . . . . 29 3.1. Acr´onimos...................................... 32 3.2. Tabla de resumen temporal del proyecto . . . . . . . . . . . . . . . . . . . . . 35 3.3. R01 - Error en la planificaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.4. R02 - P´erdida de datos y/o documentos . . . . . . . . . . . . . . . . . . . . . 36 3.5. R03 - Conocimiento insuficiente sobre las tecnolog´ıas . . . . . . . . . . . . . . 37 3.6. R04 - Problemas de integraci´on del nuevo sistema . . . . . . . . . . . . . . . . 37 3.7. R05 - Indisponibilidad del trabajador . . . . . . . . . . . . . . . . . . . . . . . 37 3.8. R06 - enfermedad del trabajador . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.9. R07 - P´erdida de comunicaci´on con cliente . . . . . . . . . . . . . . . . . . . . 38 3.10. R08 - Cambio de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.11. Ordenador port´atil: caracter´ısticas. . . . . . . . . . . . . . . . . . . . . . . . . 40 3.12. Servidor para el entorno de test:caracter´ısticas . . . . . . . . . . . . . . . . . 40 3.13. Servidor entorno real: caracter´ısticas. . . . . . . . . . . . . . . . . . . . . . . . 41 3.14.Presupuesto..................................... 41 4.1. Direccionamiento.................................. 45 XIX ´ INDICE DE TABLAS 4.2. Referencias ..................................... 46 4.3. equiposprincipales................................. 49 4.4. switchGS748T-500EUS .............................. 50 4.5. Switch TP-Link TL-SG105 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.6. Switch TP-Link TL-SG108 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.7. SwitchYS082G-P.................................. 51 4.8. SwitchTL-SF1005P ................................ 52 4.9. RouterPRV3399B-B-LT.............................. 52 4.10.ServidorDL140G3 ................................. 53 4.11.IMTinfodesain................................... 53 4.12. Vlans en switch central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.13. Lista de vulnerabilidades encontradas . . . . . . . . . . . . . . . . . . . . . . 61 4.14. funciones actuales de la red . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.15.Requisitos...................................... 64 4.16. Descripci´on del caso de uso: Acceso a la red . . . . . . . . . . . . . . . . . . . 67 4.17. Descripci´on del caso de uso: Acceso a la red externa . . . . . . . . . . . . . . 67 4.18. Descripci´on del caso de uso: Acceso al servidor de email . . . . . . . . . . . . 68 4.19. Descripci´on del caso de uso: Acceso remoto VPN . . . . . . . . . . . . . . . . 68 4.20. Descripci´on del caso de uso: Acceso por ssh-agent . . . . . . . . . . . . . . . . 68 4.21. Descripci´on del caso de uso: Acceso f´ısico . . . . . . . . . . . . . . . . . . . . 69 4.22. Descripci´on del caso de uso: Loguearse en consola . . . . . . . . . . . . . . . . 69 4.23. Descripci´on del caso de uso: Loguearse en consola . . . . . . . . . . . . . . . . 69 4.24. Descripci´on del caso de uso: Restablecer valores configuraci´on a versiones anteriores ....................................... 70 4.25. Descripci´on del caso de uso: Acceso al configurador web mediante HTTPs . . 70 4.26. Descripci´on del caso de uso: Gesti´on/monitorizaci´on de las ´areas . . . . . . . 70 4.27. Descripci´on del caso de uso: Crear backup de configuraci´on . . . . . . . . . . 71 XX ´ INDICE DE TABLAS 4.28. Descripci´on del caso de uso: Gestionar permisos de conexi´on entre interfaces . 71 4.29. Descripci´on del caso de uso: Wake on Lan . . . . . . . . . . . . . . . . . . . . 71 4.30. Descripci´on del caso de uso: Registrar conexiones de equipo . . . . . . . . . . 72 4.31. Descripci´on del caso de uso: Registrar conexiones VPN . . . . . . . . . . . . . 72 4.32. Descripci´on del caso de uso: Crear usuarios . . . . . . . . . . . . . . . . . . . 72 4.33. Descripci´on del caso de uso: Crear usuarios . . . . . . . . . . . . . . . . . . . 73 4.34. Descripci´on del caso de uso: Gestionar permisos de los usuarios de la intranet arecursosweb ................................... 73 4.35. Descripci´on del caso de uso: Cambiar el ancho de banda percibido por usuario 74 4.36. Descripci´on del caso de uso: Bloquear tr´afico en funci´on listas IP, pa´ıs . . . . 74 4.37. Descripci´on del caso de uso: Cambiar elementos a almacenar en cach´e por el sistema ....................................... 74 4.38. Descripci´on del caso de uso: Monitorizaci´on por capa de aplicaci´on . . . . . . 75 4.39. Descripci´on del caso de uso: Actualizar ´areas del sistema . . . . . . . . . . . . 75 5.1. ServidorDL360e .................................. 79 5.2. Direccionamientored ............................... 80 5.3. Servidor para el entorno simulado . . . . . . . . . . . . . . . . . . . . . . . . . 81 5.4. Router PRV3399B-B-LTentorno simulado . . . . . . . . . . . . . . . . . . . 81 5.5. SwitchTL-SF1005P ................................ 82 5.6. Definici´on de las reglas de acceso desde la interfaz LAN . . . . . . . . . . . . 85 5.7. Definicion de las reglas de acceso desde la interfaz DMZ . . . . . . . . . . . . 86 5.8. Definici´on de las reglas de acceso desde la interfaz WAN . . . . . . . . . . . . 86 5.9. Definici´on de las reglas de redirecci´on . . . . . . . . . . . . . . . . . . . . . . 87 5.10.ServidorVPNt´uneles ............................... 88 5.11. Ancho de banda para los nodos de la LAN en la red de la Figura5.1 . . . . . 89 5.12. servicios denegados por usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.13. Modo de despliegue Snort en la red . . . . . . . . . . . . . . . . . . . . . . . . 90 XXI 2.2. PLAN DIRECTOR DE SEGURIDAD El Plan Director de Seguridad consta de 6 fases que se repetir´an ciclicamente hasta disponer de una versi´on final satisfactoria del plan. Las fases son: 1. An´alisis de la situaci´on actual de la empresa: Se ha de conocer cu´al es la situaci´on actual de la empresa. En esta fase se define el alcance del plan, por ejemplo en el caso de este proyecto ser´ıa el departamento TIC, concretamente el sistema de seguridad perimetral para la intranet. Tras fijar el alcance se hace un an´alisis en el que se evaluar´an aspectos normativos con respecto al marco legal, regulatorios con respecto a est´andares de ciberseguridad, una inspecci´on de instalaciones y un an´alisis de riesgos. 2. An´alisis de la estrategia de la organizaci´on: Se han de conocer los planes de desarrollo de la empresa para poder alinear la estrategia de seguridad tanto con la estrategia TIC como con la general de negocio. 3. Definici´on de proyectos e iniciativas: Una vez obtenido un an´alisis de riesgos y alineadas las estrategias se definen y ponen en marcha iniciativas para cubrir las debilidades detectadas en la fase 1. 4. Clasificaci´on y priorizaci´on de los proyectos a realizar: Tras obtener todas las medidas y proyectos a desarrollar se deben clasificar y priorizar en funci´on del riesgo y el coste de desarrollo. 5. Aprobacion por la direcci´on: Completas las fases 1-4 ya se dispone de una versi´on preliminar del Plan Director de Seguridad que deber´a ser revisado y aprobado por la Direcci´on. 6. Implantaci´on: Una vez aprobado el plan se ponen en marcha los proyectos e iniciativas estipulados. Figura 2.1: Fases de un Plan Director de Seguridad 6 CAP´ ITULO 2. ESTADO DEL ARTE 2.3. Est´andares en ciberseguridad Los est´andares en ciberseguridad son una colecci´on de conceptos, pol´ıticas, gu´ıas y colecciones de herramientas que tienen como objeto la protecci´on de una organizaci´on y sus activos. Se usan como referencia a la hora de realizar el Plan Director de Seguridad, especialmente para el an´alisis de la Fase 1 y para el an´alisis de riesgos. En esta secci´on se definiran los est´andares m´as utilizados. 2.3.1. Familia ISO/IEC 27000 Los familia de est´andares ISO/IEC 27000 esta dedicada a la gesti´on de la seguridad de la informaci´on. Contiene las mejores pr´acticas recomendadas sobre c´omo desarrollar, impementar y mantener las especificaciones para los sistemas de gesti´on de la seguridad de la infomarci´on. Son los est´andares de referencia internacional y la base de otros est´andares como del ENS o NIST. Cada est´andar de esta familia est´a dise˜nado para poner el foco en un punto determinado. Dentro de los est´anderes m´as reconocidos estan: ISO/IEC 27001: Define las bases de la seguridad de la informaci´on dentro de la empresa. Proporciona un modelo y orientaci´on detallada para la implmentaci´on de un sistema que permita la reducci´on de la exposici´on de la informaci´on a riesgos.[6] ISO/IEC 27002: Define en detalle los controles del ISO 27001 para llevar a cabo su correcta implementaci´on. ISO/IEC 27005: Es un c´odigo de mejores pr´acticas para desarrollar una metodolog´ıa de gesti´on de riesgos. En el se definen y categorizan los riesgos para su posterior evaluaci´on y tratamiento. 2.4. Marco legal A la hora de establecer un plan de seguridad dentro de la empresa se han de conocer y acatar las leyes actualmente vigentes tanto para pa´ıs en el que esta establecida la empresa como para el que ofrece servicios y productos. Espa˜na cuenta con un c´odigo de Derecho de Ciberseguridad[7] que facilita esta tarea. Se trata de una recompilaci´on actualizada de toda legislaci´on espa˜nola relacionada con la seguridad de la informaci´on y la ciberseguridad en general. En esta secci´on hablaremos de algunas de las leyes m´as importantes a tener en cuenta a la hora de implantar soluciones de ciberseguridad en una peque˜na empresa del sector privado. En la Figura 2.2 podemos observar la evoluci´on de las leyes con respecto a la materia en ciberseguridad para pymes. En funci´on del sector de negocio al que pertenezca la empresa a 7 2.4. MARCO LEGAL tratar se han de cumplir ciertos aspectos regulatorios, pero toda empresa espa˜nola ha cumplir con la LOPDGDD y la LPI. Figura 2.2: Desarrollo legal de ciberseguridad en pymes. Espa˜na.[8] LOPDGDD que adapta al contexto espa˜nol el RGPD de la UE que entr´o en vigor el 25/05/2018. Son las normas que regulan el tratamiento de los datos sensibles pertenecientes a personas f´ısicas. Toda empresa con ´ambito de actuaci´on en la UE ha de acatar el RPGD. Es importante tenerlo en cuenta para la seguridad perimetral de la empresa, puesto que este reglamento dictamina que la empresa ha de proteger proact´ıvamente la confidencialidad de los datos de los usuarios. Los principios en los que se basa este reglamento son: 1. Licitud, lealtad y trasparencia: Los datos personales han de ser adquiridos de forma l´ıcita. El interesado debe ser informado de los datos que cede, para qu´e se van a usar y cu´anto tiempo se ver´an recogidos dentro del organismo de forma que se pueda identificar. 2. Limitaci´on de la finalidad: La finalidad para la que se recogen los datos personales ha de ser desarrollada e informada de forma clara y concisa al interesado. Tambi´en implica la prohibici´on de que estos datos sean tratados posteriormente de forma incompatible a estos fines. 3. Minimizaci´on de datos: Los datos recogidos deben ser adecuados y limitados a lo necesario en relaci´on al fin con el que se recogen. 8 CAP´ ITULO 2. ESTADO DEL ARTE 4. Exactitud de datos: Los datos han de ser correctos, completos y actualizados. El interesado tiene derecho a reactificar el tratamiento de sus datos. 5. Limitaci´on del plazo de conservaci´on de datos: Se limita el tiempo de conservaci´on de los datos al logro del fin que persigue su tratamiento. 6. Integridad y confidencialidad: Se impone a la entidad que trata los datos a actuar proactivamente en cuanto a la protecci´on de los datos que tratan ante cualquier riesgo que pueda violar la confidencialidad e integridad de estos. En caso de la violaci´on de este principio el tratador tendra 72 horas para informar a las autoridades. LPI (Ley de Protecci´on Intelectual): Con el objeto de proteger la propiedad intelectual se establece un marco por el cual se puede registrar obras por parte de empresas o personas f´ısicas. Una vez registradas se perseguir´a y castigar´a su uso il´ıcito. Esta ley tambi´en es importante para la realizaci´on de este TFG, puesto que se deber´an tomar medidas para evitar su incumplimento en la intranet empresarial, como puede ser la monitorizaci´on del tr´afico y restricci´on de acceso a webs de descargas. Ley 34/2002: Regula los aspectos jur´ıdicos de las actividades como el comercio electr´onico, la contrataci´on en l´ınea, la inforaci´on y los servicios de intermediaci´on. Se aplica para empresas que realizan comunicaciones comerciales a trav´es de la red y refleja los datos a mostrar obligaoriamente en la web de la empresa que realiza esas actividades comerciales. Ley 8/2011[9]: Dentro del marco normativo asoaciado la la ciberseguridad en empresas tiene especial importancia la Ley de Protecci´on de Intraestructuras Cr´ıticas que es complementado por el Real Decreto 704/2011[10]. Esta ley la han de acatar todos los organismos considerados cr´ıticos para el pa´ıs que se definen en ella misma y se basa en el plan cl´asico de auditar, reducir las ciberamenazas y crear planes de contingencia que toda empresa deber´ıa seguir para su correcto funcionamiento. Los objetivos de esta norma se pueden resumir en: Catalogar el conjunto de infraestructuras que presentan servicios esenciales, como pueden ser salud, TIC, transporte o alimentaci´on entre otras. Dise˜nar un planteamento de medidas de prevenci´on y protecci´on contra las posibles amenazas a las que se enfrentan estas infraestructuras. Este planteamento se dividide en dos: •PSO: define una pol´ıtica general del operado. Aqu´ı se define la metodolog´ıa de analisis de riesgo y los criterios de aplicaci´on de medidas de ciberseguridad entre otros. •PPE: define los Planes de Protecci´on Espec´ıficos, es decir, las medidas concretas a aplicar para garantizar la seguridad l´ogica y f´ısica. 2.5. Riesgos Para saber a que riesgos se exponen los activos de una empresa se deben conocer las amenazas a las que esta expuesta. Las amenazas se basan en las vulnerabilidades de la 9 2.5. RIESGOS infraestructura para atentar contra el sistema. Si existe una vulnerabilidad en el sistema, siempre existir´a alguien que intentar´a explotarla, y por lo tanto un riesgo de que esta sea explotada. Para conocer m´as sobre vulnerabilidades vaya a la secci´on 4.6.4. Figura 2.3: Relaci´on entre amenaza, vulnerabilidad y riesgo dentro de un sistema[11] Dentro del contexto de la ciberseguridad se define como activo la informaci´on contenida en el entorno empresarial. Las propiedades principales a proteger son: Confidencialidad: La informaci´on solo debe ser accesible ´unicamente a las personas autorizadas. Integridad: La informaci´on solo debe modificarse tras su autorizaci´on. Disponibilidad: La informaci´on debe ser siempre accesible para las personas autorizadas a ella. Hay muchos tipos de amenzas pero generalmennte se clasifican del siguiente modo[12]: Dependiendo del lugar donde est´a situado el agente atacante: •Interna: Procede del interior del sistema atacado. Por ejemplo un empleado que utiliza su puesto de trabajo para llevar realizar el ataque. •Externa: Procede del exterior del sistema atacado. Por ejemplo una inundaci´on. Dependiendo de la v´ıa de ataque: •F´ısica o ambiental: Afectan al hardware o a las instalacionesen donde se ubica este. Por ejemplo un fuego o un robo. •L´ogica: Afectan al software del sistema. 2.5.1. Ataques al sistema El mecanismo por el cual un agente de amenazas explota las vulnerabilidades del sistema es el ataque. En esta secci´on se van a clasificar los ataques l´ogicos deliberados. Un ataque inform´atico a un sistema normalmente se compone de varios pasos ordenados[12]: 10 CAP´ ITULO 2. ESTADO DEL ARTE 1. Descubrimiento de los sistemas que componen la red en la que se haya el objetivo. 2. Exploraci´on de las vulnerabilidades de los sistemas de la red. 3. Explotaci´on de las vulnerabilidades detectadas. 4. Compromiso del sistema. 5. Ocultamiento o eliminaci´on de los rastros que prueban el ataque. Cuando el atacante lleva a cabo estos pasos usa varias t´ecnicas de ataque. Los m´as conocidas y comunes en la actualidad seg´un INCIBE[13] son: Ataques a las contrase˜nas: Ataque a las credeciales de acceso al sistema mediante t´ecnicas como fuerza bruta o diccionario. Ataques por ingenier´ıa social: El atacante usa t´ecnicas psicol´ogicas de manipulaci´on dirigidas al usuario con el objetivo de que este realice una acci´on que beneficie al propio atacante. Los ataques m´as comunes de este tipo son los tipo phising, usando como medio aplicaciones de mensajer´ıa, pero puede usar otros medios como llamadas telef´onicas o sms. Ataques a conexiones: El atacante intercepta transici´on de informaci´on entre dos partes, generalmente usuario y servidor, con el objetivo de monitorizar y extraer datos sensibles del usuario. Entre los ataques a conexiones destacan: •Redes trampa: Suele darse en sitios con redes wifi p´ublicas. El atacante crea una red wifi con las mismas o similares caracter´ısticas externas de la red p´ublica. Tiene como objetivo el robo de informaci´on sensible de los usuarios. •Spoofing: El atacante suplanta la identidad de entidades o personas en la red. Dentro de este tipo de ataques los m´as comunes son suplantaci´on de IP, falsificaci´on web, suplantaci´on de email y suplantaci´on de DNS. •Ataque a las cookies: El atacante captura peticiones HTTP con la intenci´on de robar y/o modificar el contenido de las cookies ya que este puede traer informaci´on sensible de la v´ıctima, como credenciales. •DDos: El atacante realiza una cantidad de peticiones masiva al servidor desde varios dispotivos pudiendo llegar a dejarlo inoperativo. •Inyecci´on SQL: ataque a una aplicaci´on web que compromete su base de datos mediante sentencias SQL maliciosas. •Escaneo de puertos: se analizan los puertos de una maquina para ver qu´e puertos estan abiertos, cerrados, protocolos de seguridad aplicados. Todo ello para encontrar vulnerabilidades a explotar en el sistema. •Man in The Middle: El atacante intercepta la comunicaci´on entre dos partes que, insert´andose en el medio, bien capturando la informaci´on del intercambio o impersonando una de las partes. Tiene como objetivo el robo de informaci´on sensible. 11 2.5. RIESGOS •Sniffing: El atacante interfiere el tr´afico de la red atrav´es de programas de captura de paquetes. Tiene como objetivo el robo de informaci´on sensible. Ataques por malware: Introducci´on en el sistema de software que est´a dise˜nado espec´ıficamente para interrumpir, da˜nar u obtener acceso no autorizado a un sistema inform´atico. Existen muchos tipos de malware como el Ram •Virus: software malicioso que usa como modo de transmisi´on otro archivo o programa y una vez en el host, si es ejecutado por el usuario se atureplicar´a y causar´a da˜nos dentro del equipo. •Adware: malware que muestra anuncios a la v´ıctima con el objetivo de generar ingresos al atacante. Normalmente se instala camuflado junto a programas descargados de repositorios no oficiales. •Troyano: Se camuflan como sotfware legitimo para infectar el software de la victima con diversos objetivos como crear puertas traseras, robar informaci´on sensible o monitorizar los movimientos del equipo infectado. •Gusano: Variante de virus que se autoreplica e infecta a otros equipos con capacidad de realizar cambios en la configuraci´on del sistema. •Criptojacking: El atacante usa los recursos del dispositivo de la v´ıctima para minar criptomonedas. 2.5.2. Ciberamenazas dentro del entorno empresarial En la secci´on anterior se han listado los ciberataques m´as comunes, pero como el entorno del estudio es una PYME es importante clasificar las amenazas y ataques de los son presa las PYMEs con m´as frecuencia. A continuaci´on se listan las ciberamenazas m´as comunes dentro de un entorno empresarial, y por lo tanto las que debe conocer en mayor profundidad seg´un el INCIBE[14]: Fugas de informaci´on: Se produce cuando infomaci´on relativa a la empresa es puesta en poder de una persona no autorizada rompiendo as´ı la confidencialidad de dicha informaci´on. Las formas m´as comunes de perdida de la confidencialidad dentro de una organizaci´on son: •Extracci´on de dispositivos f´ısicos con informaci´on sensible en su interior, bien por robo o por extrav´ıo. •Uso del correo electr´onico. Ya sea de forma involuntar´ıa o a ra´ız de ataques basados en ingenir´ıa social. •Uso de redes inal´ambricas no confiables o con medidas de seguridad insuficientes. •Uso de inadecuado de redes sociales, como la publicaci´on de datos sensibles relativos a la empresa en ellas. •Uso inadecuado de las herramientas empresariales, como dar acceso a un sistema externo a la nube de la empresa. 12 CAP´ ITULO 2. ESTADO DEL ARTE •Malware como troyanos, adware o spyware. •Uso de credenciales inseguras, poco robustas o de defecto. Ataques tipo phishing:Usa la ingenier´ıa social para manipular psicol´ogicamente al propio usuario del sistema con el objetivo de que este realice una acci´on que beneficie al atacante. Su principal mendio de propagaci´on es el correo electr´onico. Fraude del CEO: Con el objetivo de robar fondos de la empresa, el atacante se hace pasar por un alto directivo de la empresa. Tras recompilar informaci´on de la persona a suplantar la identidad, el atacante trata de, usualmente mediante intercambio de emails, convencer a un empleado con capacidad de realizar transferencias financieras de que le haga urgentemente una trasferencia de dinero de los fondos de la empresa a otra cuenta bajo el control del atacante. Fraude de RR.HH.: Parecido al fruade del CEO. Se suplanta la identidad de un empleado cualquiera y se trata de convencer a un empleado de RR.HH., usualmente por intercambio de emails, de que la n´omina del empleado se ingrese a una nueva cuenta que estar´a bajo control del atacante. Suplantaci´on de proveedores: Parecido al fruade del CEO. Se suplanta la identidad de un proveedor y se trata de convencer a un empleado, usualmente realizando eail spoofing, de que realice una transferencia bancaria a una cuenta que estar´a bajo control del atacante. Sextorsi´on: La victima recibe un email en el que se le extorsiona para realizar un pago amenazandola con revelar contenido visual comprometido de esta a sus conocidos y por las redes sociales bajo la premisa de haber hackeado sus dispositivos. Ataques contra la p´agina web corporativa. Estos ataques en general est´an basados en el aprovechamiento de vulnerabilidades del sistema como software no parcheado, malas configuraciones o errores de dise˜no en la web. Este tipo de ataques se puede clasificar en: •Fuga de informaci´on: El atacante extrae informaci´on confidencial de la empresa. •DoS y DDoS: El atacante realiza una cantidad de peticiones masiva al servidor de tal manera que lo deja inoperativo. •Defacement: El atacante cambia la apariencia de la web corporativa, pudiendo usarla como trampol´ın para tralizar otro tipo de fraudes como phishing o distribuci´on de malware. Ransomware: Por medio de malware se restringe el acceso a la informaci´on de los dispositivos afectados, generalmente cifr´andola. El atacante generalmente pide un rescate econ´omico a cambio de la recuperaci´on de su acceso. Fraude de falso soporte de Microsoft: La victima se comunica telefonicamente con el estafador, que se hace pasar por tecnico de Microsoft y, pretendiendo solucionar varios problemas, roba informaci´on a la victima, instala software de acceso remoto o solicita dinero a cambio de solucionar problemas inexistentes. 13 2.6. MEDIDAS DE DEFENSA Campa˜nas de emails con malware: Envio de email que instan a la victima a descargar y ejecutar programas que comprometer´an su sistema camuflandolos como otro tipo de archivos adjuntos con los que la v´ıctima est´a familiarizada, por ejemplo un excel, o como un enlace de descarga de dicho archivo. 2.5.3. An´alisis de riesgos En el an´alisis de riesgos se detecta y calcula la probabilidad y coste de que se materialicen ciertas amenazas. En funci´on a estos par´ametros y del marco legal, se decide si el riesgo se debe evitar, mitigar, trasferir su gesti´on a terceros o coexistir con ´el. Las pautas a seguir para realizar el an´alisis se reflejan en la Figura 2.4 Figura 2.4: Fases del an´alisis de riesgos[11] 2.6. Medidas de Defensa En esta secci´on se va a hablar de las medidas que se pueden aportar para la mitigaci´on de los riesgos posibles encontrandros tras en an´alisis del entorno empresarial. Se profundizar´a en la seguridad perimetral y los sistemas UTM ya que el objetivo de este proyecto es la implantaci´on de uno de estos sistemas. Para una defensa completa se debe aplicar defensa en profundidad. La defensa en profundidad consiste en la introducci´on de m´ultiples capas de seguridad que reducen la probabilidad de compromiso introduciendo medidas varias de seguridad a todos los niveles (seguridad perimetral, seguridad interna y factor humano)[12]. En la Figura 2.5 se observan las posibles capas de seguridad. 14 CAP´ ITULO 2. ESTADO DEL ARTE Figura 2.5: Niveles de defensa en profundidad[11] La medidas para aplicar seguridad en la red interna se pueden resumir en: cortafuegos personales, actualizaciones del sistema y aplicaciones, antivirus y gesti´on de la configuraci´on del sistema. Las medidas para acotar los riesgos humanos se basan en pol´ıticas de seguridad corporativas, gesti´on de incidencias y concienciaci´on de los usuarios. Las medidas a tomar para aplicar seguridad perimetral son: filtrado de tr´afico mediante cortafuegos, sistema de detecci´on de intrusos que monitorice el tr´afico de la red, controles de acceso a la red, defensa contra malware y cifrado de datos. 2.6.1. Seguridad perimetral En una red se describe el perimetro como el conjunto de sistemas que ofrecen servicios a una red externa. El hecho de estar abiertos hacia el exterior aumenta la probabilidad de exposici´on de vulnerabilidades que podr´ıan ser explotadas. Las funciones que debe cumplir una red perimetral son: Rechazar las conexiones de clientes externos a servicios que s´olo deban ser accedido desde la red interna. Distinguir y establecer pol´ıticas de tratamiento para los diferentes tipos de tr´afico en funci´on a su red de procedencia. Seleccionar el tr´afico procedente o dirigido hacia determinados nodos de la red con el objeto de impedir el tr´afico que no provenga de donde deber´ıa provenir. 15 2.7. FIREWALL UTM Stare: Como peek, pero pudiendo hacer bump despu´es en lugar de Splice. Splice: Permite conectar 2 clientes, el cliente y el servidor de forma m´as directa, como si no hubiera proxy. Peek Splice (Splice all): Combinaci´on de los modos peek con splice, tambi´en llamado Splice all. S´olo puede ver el hostname, pero en la mayor´ıa de los casos ser´a suficiente para determinar si un sitio deber´a o no ser bloqueado por SquidGuard. Normalmente es la opci´on m´as viable porque no se rompe la cadena de confianza. Se puede configurar tanto para el modo transparente como para el directo. Figura 2.10: Alcance de los modos de Squid [16] SquidGuard Squidguard es un plug-in de Squid que se usa para el control de acceso basado en el dominio, la URL completa, o palabras contenidas en esta, solicitado por el cliente, pero no por contenido del cuerpo de la p´agina web. Sus funciones principales son: Permitir o denegar el acceso en funci´on al cliente y/o destino. Redirigir a una p´agina de error las solicitudes a accesos a p´aginas bloqueadas. Listas personalizadas de sitios o listas negras preestablecidas de otras fuentes divididas por categor´ıas establecidas en funci´on al tipo de sitios (ej: apuestas, juegos...). LightSquid Plug-in de Squid que se usa para crear reportes del historial de accesos web a partir de los logs de Squid. Los reportes pueden incluir qu´e clientes se conectan a qu´e web, cuando ancho de banda consumieron. Puede crear reportes mensuales, diarios, etc. 2.7.6. AntiMalware Tambi´en existen plugins que permiten bloquear rangos de direcciones IP de Spammers, botnets, malware, spyware y/o bloques de direcciones IP en funci´on del pa´ıs. Est´an gestiona22 CAP´ ITULO 2. ESTADO DEL ARTE dos con mediantes listas ditables por el usuarios o preexistentes que se actulizan cada cierto tiempo. En ejemplo es pfBlockerNG de pfSense. B´asicamente hace dos cosas: Bloqueo de IPs basado en reglas de firewall DNS sinkhole. Bloqueo de URL maliciosa mediante su redireccionamiento a una falsa IP. 2.7.7. VPN Las VPNs se usa para establecer conexiones seguras sobre redes de transporte inseguras. Por ejemplo para que un empleado se conecte desde su casa por escritorio remoto a un ordenador conectado a la intranet empresarial. Para ello se establece un tunel VPN. La t´ecnica de tunelizaci´on consiste en encapsular un protocolo de red sobre otro, creando un tunel entre dos puntos de una red por el cual se puede transmitir de forma segura cualquier tipo de datos. De esta forma los valores del protocolo encapsulado ser´an desapercibidos por los elementos intermedios de la conexi´on. Dentro del contexto de las UTM, estas hacen de servidor VPN para gestionar conexiones VPN, aumentando as´ı la confidencialidad e integridad de los datos. A cambio necesitan una mayor potencia de c´alculo para realizar las operaciones de cifrado y descifrado y no generar cuellos de botella. Existen 2 arquitecturas b´asicas de configuraci´on para el acceso remoto De acceso remoto o roadWarrior: Con el objeto de que un usuario se conecte a una red local remota se establece un tunel entre dicho usuario y el servidor VPN remoto que le dar´a acceso a la red local. Para la creaci´on del tunel el usuario debe autenticase frente al servidor de acceso remoto, y el servidor, ante el cliente. Una vez autenticados ambos se establece el tunel y el usuario podr´a relacionarse con los nodos de la red como si fuera un usuario local. VPN punto a punto o site-to-site: En este caso el tunel se establece entre dos redes locales en lugar de un cliente y un servidor VPN. Cada red local tendr´a su propio servidor VPN. Cualquiera de los clientes de una red local podr´a establecer conexi´on clientes de la otra red como si estuvieran en la misma y viceversa. Tecnologias utilizadas con VPN: PPTP (Point-to-Point Tunneling Protocol): protocolo de Microsoft dise˜nado espec´ıficamente para implementar VPN. PPTP corre sobre el protocolo de enlace de datos PPP (Poin-to-Point-Protocol). PPTP utiliza t´uneles GRE para implementar el t´unel de una VPN, encapsulando tramas PPP y cifrado RC4. Permite una conexi´on por t´unel. La autentificaci´on de usuarios se realiza a trav´es de los protocolos PAP (Password Authentication Protocol) y MSCHAP (versi´on de Microsoft de CHAP). Se debe tratar de evitar su uso ya que se han encontrado diversas vulnerabilidades referentes a su uso. 23 2.7. FIREWALL UTM L2TP (Layer 2 Tunneling Protocol): utiliza el protocolo PPP para proporcionar una envoltura inicial de los datos y luego incluir los encabezados adicionales. L2TP se debe usar siempre junto con IPSec debido a que L2TP solo realiza la autenticaci´on entre los puntos finales del t´unel a la hora de establecer la conexi´on, pero no para cada uno de los paquetes que viajan a trav´es de el. IPSEC: Protocolo a nivel del red. Permite definir un t´unel entre dos pasarelas. Una pasarela IPSec normalmente consiste en un router de acceso o firewall en el que est´e implementado el protocolo IPSec. Las pasarelas IPSec est´an situadas entre la red privada del usuario y la red compartida del operador. SSL/TLS: Protocolo a nivel de transporte. Permite la autenticaci´on tanto de cliente como servidor, usando claves p´ublicas y certificados digitales. Proporciona comunicaci´on segura mediante el cifrado de la informaci´on entre emisor y receptor. 2.7.8. Accesos al sistema HTTPS Para el acceso al configurador web del sistema se usa el protocolo HTTPS. Al protocolo de aplicaci´on HTTP se a˜nade el protocolo SSL en la capa intermedia entre este y TCP. SSL es el encargado de cifrar la comunicaci´on. Figura 2.11: Arquitectura HTTPS[53] SSL logra establecer una conexion segura mediente la creaci´on de la clave de sesi´on. La clave de sesi´on es sim´etrica. Sin embargo el protocolo SSL dicta que para establecer la conexi´on de cifrado sim´etrico se ha de enviar del cliente al servidor mediante el uso de cifrado asim´etrico. El uso de este cifrado asim´etrico se apoya en la infraestructura PKI (Infraestructura de Clave P´ublica) que define conjunto de elementos necesarios para crear el sistema de certificaci´on usado. Las fases de SSL para establecer una comunicaci´on cifrada vienen dadas por la Figura 2.12. 24 CAP´ ITULO 2. ESTADO DEL ARTE Figura 2.12: Flujo de operaciones SSL SSH y SSH-Agent Con el t´unel ssh, al igual que con SSL, se cifra la sesi´on. En una conexi´on ssh una vez encriptada de forma sim´etrica para la creaci´on del tunel, el usuario debe autenticarse. Para ello tradicionalmente este debe introduce sus credenciales, usuario y contrase˜na. Para reforzar la seguridad de las conexiones ssh, se puede a˜nadir una capa extra de seguridad, gestionada mediante alg´un ssh-agent, autenticando la conexi´on adem´as de con las credenciales de usuario y la contrase˜na, mediante un par de claves asim´etricas. En la Figura 2.13 se muestra c´omo se autentifican el cliente y servidor mediante el paso extra de par de clave. Figura 2.13: Flujo operaciones SSH con autenticaci´on de usuario por clave 2.8. Estudio Comparativo En esta secci´on se realizar´a una comparativa entre los UTMs tipo software m´as populares. Estos han de ser de software libre pues el cliente quiere reducir costes. Elegir un firewall UTM open source no reduce los niveles de seguridad si se compara con uno comercial por lo que analizamos las siguientes opciones. 25 2.8. ESTUDIO COMPARATIVO En la Tabla 2.1 se observa una peque˜na comparativa de las caracteristicas de algunos de los firewalls UTM m´as populares [39] que se est´an considerando para implantar como soluci´on. Todos tienen las funciones requeridas por el cliente, por lo que habr´a que comparar un poco m´as alla de las funcionalidades para elegir el firewall a instalar. A lo largo de las siguientes subsecciones se analizaran las diferentes caracteristicas que puede tener el firewall UTM. Carater´ıstica\UTM PfSense OPNSense IPFire ZeroShell Licencia Apache 2.0 Simplified BSD GPL GPL SO FreeBSD FreeBSD Linux Linux Firewall core Packet Filter Packet Filter NetFilter NetFilter IDS Snort/Suricata Snort/Suricata Suricata Snort Acceso SSH, Web (HTTP/HTTPS), RS232 SSH, Web (HTTP/HTTPS), RS232 SSH, Web (HTTPS), RS232 SSH, Web (HTTPS), RS232 QoS Si Si Si Si DMZ Si Si Si Si Configuraci´on texto\GUI texto\GUI texto\GUI GUI NAT Si Si Si Si VPN OpenVPN, IPsec, L2TP, IKEv2, Tinc, PPTP OpenVPN, IPsec, L2TP, IKEv2, Tinc, PPTP OpenVPN, IPsec, IKEv2 OpenVPN, IPsec, IKEv2 M´odulos de terceros Si No Si No Filtrado Web y cach´e Squid Squid Squid Squid Antivirus Clamav con Squid Clamav con Squid Clamav con Squid Clamav con Squid Actualizaciones Frecuentes Frecuentes Frecuentes Frecuentes Comunidad Muy activa Activa Poco activa Poco activa Documentaci´on Muy alta Alta Media Media Hardware recomendado CPU >1 Ghz RAM >1 GB CPU >1 Ghz RAM >2 GB CPU >1 Ghz RAM >1 GB CPU >233 Mhz RAM >96 MB Tabla 2.1: Comparativa de UTMs libres [38, 40, 41, 42] 2.8.1. SO: Linux vs FreeBSD FreeBSD es m´as seguro y robusto. Prueba de ello es que el n´umero de vulnerabilidades encontrado es significativamente menor, tal y como se observa en las gr´aficas de la Figura 2.14 Figura 2.14: Vulnerabilidades por a˜no FreeBSD[43], Linux[44] seg´un el CVE 2.8.2. Filtrado de conexiones: Packet Filter vs Netfiler(Iptables) Ambos permiten realizar operaciones de operaciones de manipulaci´on de paquetes. Representan la parte central y m´as importante del firewall. Sus caracter´ısticas principales son: 26 CAP´ ITULO 2. ESTADO DEL ARTE Filtrado de paquetes con control de estado. Filtrado de paquetes sin control de estado. Traducci´on de direcciones y puertos NAT/PAT. Extensi´on del framework por terceros. En el caso de los UTM es muy importante porque parte de los m´odulos que se estudiar´an a continuaci´on basan su funcionalidad en estos mecanismos: •Control de tr´afico. Es la base en los mecanismo de QoS. •Control de n´umero de veces que se activa una regla. Importate para los sistemas de monitorizaci´on de tr´afico. •Implementaci´on de proxies transparentes a partir del subsistema NAT/PAT. Packet filter y Netfiler extienden la misma funcionalidad, en sus diferencias cabe destacar: Packet filter esta implementado en sistemas FreeBSD y Netfiler en sistemas Linux. S´ıntaxis: Packet Filtering usa una sintaxis m´as sencilla que iptables. 2.8.3. IDS: Snort vs Suricata Como Sistema de Detecci´on y Prevenci´on de Intrusos se ha de elegir entre Snort y Suricata. Ambos son herramientas NIDS basadas en un motor que funciona con una base de datos de reglas o firmas. Son las alternativa de bajo coste a NIDS comerciales en entidades peque˜nas y medianas. Snort tiene una ligera mayor popularidad que Suricata. Tienen tres modos de acci´on: Modo sniffer: se monitoriza por pantalla toca actividad de las redes configuradas en Snort. Modo NIDS: Se generan alarmas en funci´on a una comparaci´on del flujo de datos y la base de firmas instaladas y activas en el NIDS. Estas firmas son reglas que se actualizan periodicamente en funci´on al a base de datos de donde se descarguen. Tambi´en el usuario puede crear sus propias reglas para limitar el uso de determinadas aplicaciones. Modo packet logger: se almacenan logs de toda la actividad de la red para realizar un an´alisis de posterior de esta. A continuaci´on se muestra una peque˜na comparativa entre Snort y Suricata para ayudar a distinguir el NIDS a instalar idealmente. La Tabla 2.2 muestra m´as favorable el uso de Snort frente a Suricata debido que la documentaci´on disponible y la actividad de la comunidad es 27 2.8. ESTUDIO COMPARATIVO mayor. La Figura 2.15 muestra la justificaci´on de esta decisi´on. El n´umero de vulnerabilidades registradas en el CVE es menor para Snort. Caracter´ıstica\IDS Snort Suricata Licencia GNU GPL v2 GNU GPL v2 Modo detecci´on Reglas Reglas Detecci´on autom´atica de protocolos Si Si Multihilo Si Si Personalizaci´on CPU Si (a partir de la versi´on 3.0) Si Calidad Documentaci´on Alta Media Comunidad Muy activa Activa Tabla 2.2: Comparativa de caracter´ısticas principales Figura 2.15: Vulnerabilidades por a˜no Snort[45], Suricata[46] seg´un CVE 2.8.4. Filtrado web, cach´e y antivirus Para todos los firewall estudiados se usa servidor proxy Squid, por lo que no se realizar´a comparativa de este punto. Vaya a la secci´on 2.7.5 para m´as informaci´on sobre el funcionamiento y funcionalidades de Squid. 2.8.5. Protocolos VPN Para seleccionar el protocolo VPN se ha creado una peque˜na tabla comparativa con las caracter´ısticas principales de las opciones disponibles m´as atractivas, Tabla 2.3. 28 CAP´ ITULO 2. ESTADO DEL ARTE OpenVPN IKEv2/IPSec L2TP/IPSec PPTP Introducci´on Muy popular. No estandarizado bajo RFC. Usa SSL/TLS para el intercambio de llaves. Estandarizado en RFC 7296. Est´andar de defecto en internet. Estandarizado en RFC 3193. Basado en tuneliazar PPP de capa 2 Encriptaci´on Usa la libreria OpenSSL que implementa algoritmos 3DEs, AES, RC5... Con IKEv2 m´aximo de 256 bit keys Implementa algoritmos 3DEs, AES, Blowfish, Camellia. Con IKEv2 m´aximo de 256 bit keys Encapsulaci´on doble via procolo est´andar IPSec Microsoft Point-to-Point que implementa algoritmos RSA y RC4. M´aximo de 128 bit keys Vulnerabilidad No conocido para el uso de algoritmo + certificado de autentificaci´on No conocido para el uso de algoritmo + certificado de autentificaci´on. Conocidas si se usa IKE. No conocido para el uso de algoritmo + certificado de autentificaci´on Sistema de autentificaci´on es vulnerable a ataques por diccionario. RC4 es vulnerable a ataques como bit-flipping. Velocidad Similar a IKEv2 Similar a OpenVPN Similar a OpenVPN M´as r´apido que OpenVPN, IPSec Puertos Cualquiera con UDP o TCP Fijos: UDP 500, 50 y 4500 Fijos: UDP 500, 1701 y 4500 Fijos: TCP 1723, 47 Plataformas compatibles Windows, macOS, Linux, Apple iOS, Android, DD-WRT Windows, macOS, Linux, Apple iOS, Android Windows, macOS, Linux, Apple iOS, Android Windows, macOS, Linux, Apple iOS, Android, DD-WRT Rendimiento Estable y r´apido sobre todo tipo de conexiones Estable y r´apido sobre todo tipo de conexiones. Configuraci´on puede ser m´as compleja que OpenVPN. Estable sobre todo tipo de conexiones. El m´as lento de la comparativa. Configuraci´on puede ser m´as compleja que OpenVPN. Existen problemas de compatibilidad con protocolo GRE y algunos routers. No es confiable en conexiones inestables. Tabla 2.3: Comparativa de caracter´ısticas principales de protocolos VPN[47] Observando la tabla comparativa resulta como mejor opci´on el uso de OpenVPN ya que no cuenta con vulnerabilidades notables, su configuraci´on es sencilla frente al resto de protocolos sin vulnerabilidades y el hecho de que pueda usar cualquier puerto facilita la configuraci´on del firewall. 29 2.8. ESTUDIO COMPARATIVO 30 CAP´ ITULO 3. PLAN DE PROYECTO Cap´ıtulo 3 Plan de proyecto 3.1. Resumen del proyecto En este cap´ıtulo se definir´a la planificaci´on del proyecto en detalle. Se documentar´an las fases del proyecto y por cada fase se definir´an sus tareas junto con la calendarizaci´on de las mismas. Tambi´en se har´a una exploraci´on de los posibles riesgos adem´as de un seguimiento de los mismos. 3.1.1. Prop´osito, Alcance y Objetivos El objetivo de este proyecto es la integraci´on de un sistema firewall UTM de bajo coste que permita cubrir las necesidades actuales de seguridad en la infraestructura de red de una peque˜na empresa. Para una mayor detalle de los objetivos lea el cap´ıtulo 1. Los requisitos de la integraci´on est´an definidos en el cap´ıtulo 4 3.1.2. Definiciones y Acr´onimos En la Tabla 3.1, se presentan los acr´onimos y definiciones que aparecen a lo largo de este documento. 31 3.3. GESTI ´ ON DEL PROCESO Identificador R06 - Enfermedad del trabajador Descripci´on El trabajador enferma y no puede cumplir con los plazos establecidos. Impacto Cr´ıtico Probabilidad 80 % Exposici´on Alto Plan de mitigaci´on Cuidar la salud del trabajador y dedicar los d´ıas no laborables a la realizaci´on del proyecto. Plan de contingencia Priorizar el desarrollo de las tareas por criticidad, replanificar la calendarizaci´on de las tareas y reevaluar los riesgos. Tabla 3.8: R06 - enfermedad del trabajador Identificador R07 - P´erdida de comunicaci´on con cliente Descripci´on No se consigue la comunicaci´on entre el cliente y el trabajador influyendo en la continuidad del proyecto. Impacto Cr´ıtico Probabilidad 60 % Exposici´on Alto Plan de mitigaci´on Fijar fechas de reuniones con antelaci´on. Plan de contingencia Replanificar la planificaci´on de las tareas y reevaluar los riesgos. Tabla 3.9: R07 - P´erdida de comunicaci´on con cliente Identificador R08 - Cambio de requisitos Descripci´on Durante la realizaci´on del proyecto se encuentran requisitos que no se tuvieron en cuenta durante las primeras fases. Impacto Cr´ıtico Probabilidad 80 % Exposici´on Alta Plan de mitigaci´on Analizar los objetivos del proyecto adecuadamente para fijar correctamente los requisitos. Plan de contingencia Priorizar el desarrollo de las tareas por criticidad, replanificar la calendarizaci´on de las tareas y reevaluar los riesgos. Tabla 3.10: R08 - Cambio de requisitos 38 CAP´ ITULO 3. PLAN DE PROYECTO 3.3.3. Estimaci´on de costes En esta secci´on se describen los recursos necesarios para el desarrollo del proyecto. Los recursos se dividir´an en 4 categor´ıas: personal, equipos y herramientas, material de oficina y espacio. Para cada uno de ellos se adjunta una descripci´on, la disponibilidad y las fechas de necesidad. Personal El proyecto consta de una ´unica persona para gestionarlo y llevarlo a cabo. Esta persona realizar´a funciones de auditor IT. Siendo el ´unico recurso en personal de proyecto, se necesitar´a durante la duraci´on completa del proyecto. Figura 3.3: Remuneraciones medias en ciberseguridad, Espa˜na 2021[19] Para establecer el coste de este recurso, tendremos en cuenta la Figura 3.3. En esta Figura podemos observar que los salario de auditor IT con menos de 2 a˜nos de experiencia oscilan entre los 20-40 K en Espa˜na. Valladolid no es una ciudad con salarios a la alta por lo que se establecer´a un salario de 25.000e/a˜no, lo que equivale a unos 13.5e/hora. Equipos y herramientas Durante este proyecto se ha usado software gratuito para la disminuci´on de los costes del mismo. Para el desarrollo del proyecto se necesitar´an las siguientes herramientas: Ordenador port´atil: se usar´a para la realizaci´on completa del proyecto. Tabla 3.11 Servidor (2): Un servidor de pruebas, para el entorno de pruebas, Tabla 3.12, y otro para el entorno real, Tabla 3.13. Google Drive: Para guardar las copias de seguridad del trabajo. 39 3.3. GESTI ´ ON DEL PROCESO Teams Microsoft: Como m´etodo de comunicaci´on con los tutores. OpenVAS: Para el an´alisis de vulnerabilidades. PfSense: UTM software que se configura e implanta. PuTTy: Para el acceso a la UTM mediante SSH. PuTTyGen: Para fortalecer la confidencialidad del acceso a la UTM. Draw.io: Para la realizaci´on de diagramas. Escritorio remoto: Para el acceso al entorno real. Navegador Chrome: Para la configuraci´on de la UTM. WakeOnLanGui: Para encender los PC del entorno real mediante Wake On LAN. OpenVPN Client: Para el acceso al entorno real. TightVNC: Para el acceso a escritorio remoto. Latex: Para la realizaci´on de la memoria. Durante la realizaci´on de los test es posible que se usen otros equipos como ordenadores o routers cedidos temporalmente por la empresa. Ordenador port´atil Descripci´on: Ordenador port´atil MSI, a˜no 2015. Componentes Procesador: Core i7-4712HQ CPU @ 2.3GHz 3.3GHz. Memoria RAM: 8 GB DDR3. Tarjeta gr´afica: NVIDIA GeForce R 920M. Disco Duro: SATA 1 TB. Resoluci´on de la pantalla: 1920x1080 ppp. Precio de compra: 700e Precio amortizaci´on proyecto: 0*e(Ya amortizado) Tabla 3.11: Ordenador port´atil: caracter´ısticas. Servidor pruebas Descripci´on: Servidor del a˜no 2011 Componentes Procesador: i7-2700K CPU @ 3.50GHz. Disco Duro: SATA 500 GB. Memoria RAM: 4 GB DDR3. Precio de compra: 1200e Precio amortizaci´on proyecto: 0*e(Ya amortizado) Tabla 3.12: Servidor para el entorno de test:caracter´ısticas 40 CAP´ ITULO 3. PLAN DE PROYECTO Servidor Descripci´on: Servidor para entorno real Componentes Procesador: Xenon 2.2GHz—10MB—4C—80W Memoria RAM: 16 GB DDR3. Tarjeta gr´afica: NVIDIA GeForce R 920M. Disco Duro: SATA 2x500 GB. Puertos NIC: 4. Precio de compra: 211.77e Tabla 3.13: Servidor entorno real: caracter´ısticas. Espacio: Hogar del trabajador: La mayor parte del proyecto se desarrollar´a desde la casa del propio desarrollador del proyecto. Conexi´on a internet: Ser´a necesario en todas las fases del proyecto. Se contabilizar´a como gastos al proyecto al realizarse en su mayor´ıa el proyecto desde el hogar del trabajador. Electricidad: Ser´a necesario en todas las fases del proyecto. Se contabilizar´a como gastos al proyecto al realizarse en su mayor´ıa el proyecto desde el hogar del trabajador. CPD: Ser´a necesario acudir al entorno en el que se implatar´a el UTM como m´ınimo en la fase de implantaci´on. En base a todos los recursos necesarios mencionados anteriormente se calcula el coste de los activos y pasivos usados para el desarrollo del proyecto. Se ve reflejado en la Tabla 3.14 : Recurso Precio dentro del proyecto Cantidad Subtotal 1. Ordenador port´atil 0e1 0e 2. Servidor pruebas 0e1 0e 3. Servidor 211.77e1 211.77e 4. Coste trabajador 13.5e/hora 336 horas 4536.00e 5. Internet 30.00e/mes 336 horas 14.00e 6. Electricidad 0.15e/kwh 336 horas 50.4e Total: 4812.17e Tabla 3.14: Presupuesto 41 3.3. GESTI ´ ON DEL PROCESO 42 CAP´ ITULO 4. AN ´ ALISIS DE LA INFRAESTRUCTURA Y FIJACI ´ ON DE OBJETIVOS Cap´ıtulo 4 An´alisis de la infraestructura y fijaci´on de objetivos En este cap´ıtulo se realiza el an´alisis de infraestructura. Incluye una primera elicitaci´on de requisitos en funci´on a las necesidades del cliente, definici´on de roles, diagramas f´ısico-l´ogicos de la infraestructura y estimaci´on de debilidades de esta. Tanto para determinar si las metas impuestas por el cliente son asequibles, como para comunicar los requisitos de este proyecto adecuadamente, se debe caracterizar la red de la empresa. A lo largo de este cap´ıtulo, con la intenci´on de dar una visi´on m´as completa de la infraestructura de la empresa, de cara a poder definir sus necesidades con certeza, se realizar´an varios mapas de red con diferente nivel de detalle, para realizar estos diagramas se seguir´an las indicaciones impartidas por el m´etodo descendente[20] en la medida de lo posible, tambi´en se tendr´an en cuenta las preferencias del cliente a la hora de definir las necesidades de la infraestructura. 4.1. Caracterizaci´on de la arquitectura l´ogica La red de la empresa que vamos a estudiar cuenta con un edificio de 4 plantas, donde se encuentran varias salas a las que se deber´a proveer de servicios de red. En la Figura 4.1 se caracteriza la arquitectura l´ogica de la red en dicho edificio, con el prop´osito de dar una percepci´on general de la estructura de la red antes de entrar en detalles f´ısico-l´ogicos. Como se puede observar en la Figura 4.1, la red troncal tiene un claro dise˜no de collapsed backbone[21], donde todos los elementos se conectan al switch central, formando as´ı una topolog´ıa de estrella. Tambi´en se observa que se dispone en una jerarqu´ıa de dos capas[22], la de n´ucleo contra´ıdo y la de acceso. La capa de n´ucleo contra´ıdo esta formado por el switch central, (switch gestionable de capa 2), junto con el UTM firewall y el router, mientras que la capa de acceso la conforman el resto equipos conectados al switch central. 43 4.1. CARACTERIZACI ´ ON DE LA ARQUITECTURA L ´ OGICA Este tipo de dise˜no es cl´asico en infraestructura peque˜nas como la que se va a estudiar, pues es f´acilmente configurable y escalable, pero hay gran riesgo si alguno de los equipos troncales falla. Al no haber redundancia de estos, si un equipo troncal falla no habr´a conexi´on de red. Figura 4.1: arquitectura l´ogica En la Figura 4.1 tambi´en se puede observar las subredes desde el punto de vista del firewall. El firewall cuenta con 3 interfaces de red activas, que conectan con 3 subredes que son: WAN: Conecta al puerto 0 del firewall cuya direcci´on es 192.168.1.3. Est´a conectado al router que da acceso a internet. En esta subred el firewall obtiene una direcci´on IP est´atica a partir del router que est´a conectado a internet. Todo el tr´afico del router est´a redireccionado al firewall. El firewall est´a configurado para que act´ue como servidor DHCP de esta subred. LAN: usa el puerto 1 del firewall cuya direcci´on es 172.25.1.1. Est´a conectado al switch central que gestionar´a todas las conexiones entre los equipos de la LAN. El firewall est´a configurado para que act´ue como servidor DHCP de esta subred. DMZ: usa el puerto 2 del firewall con la direcci´on de red 10.10.10.1/8. Est´a directamente conectado al servidor de correo electr´onico, puesto que ´unico servidor que requiere ser accedido por usuarios no pertenecientes a la empresa. El firewall est´a configurado para que act´ue como servidor DHCP de esta subred. 44 CAP´ ITULO 4. AN ´ ALISIS DE LA INFRAESTRUCTURA Y FIJACI ´ ON DE OBJETIVOS Subred Direcci´on IP/M´ascara Router por Defecto Servidor DHCP Rango de Asignaciones WAN 192.168.3.0/24 192.168.1.1 192.168.3.1 192.168.3.2-254 LAN 172.25.0.0/16 172.25.1.1 172.25.1.1 172.25.1.2-254 DMZ 10.0.0.0/8 10.10.10.1 10.10.10.1 10.10.10.2-254 Tabla 4.1: Direccionamiento 4.2. Caracterizaci´on de nombres Para permitir la identificaci´on de todos los elementos de la red se ha usado un esquema de nombres con las siguientes partes: Elemento: identifica el tipo de elemento. Numero identificativo del tipo de elemento: identifica el n´umero dentro del tipo de elemento. Puerto: identifica al n´umero puerto dentro del elemento principal de conexi´on (switch gestionable de capa 2). Si el elemento no est´a conectado a alg´un puerto se usar´a 00 en la identificaci´on del puerto. Lugar: identifica la ubicaci´on del elemento. Funci´on: protocolo de transmisi´on. Si el elemento se trata de un equipo: “elemento” “Numero identificativo del tipo de elemento”- “puerto”“lugar” Si es un elemento de conexi´on de red: “elemento” “identificaci´on num´erica del elemento”“funci´on”- “puerto”“lugar ” 45 4.3. CARACTERIZACI ´ ON DEL CABLEADO DEL EDIFICIO Y DISPOSICI ´ ON DE LOS ELEMENTOS Las referencias de cada uno de los tipos definidos anteriormente pueden ser las siguientes: ELEMENTO ETIQUETA Servidor SV Switch SW Router RT Firewall FW Telefono TL Ordenador PC Rack RK NAS NS LUGAR ETIQUETA Oficinas OFI Comercial COM Desarrollo DES Centro Datos CPD Com´un CMN Piso 2 P2 Piso 1 P1 Piso 0 P0 Piso -1 PS FUNCI´ ON ETIQUETA Transmisi´on voz V Transmisi´on datos D Transmisi´on mixta (voz y datos) M Tabla 4.2: Referencias Como ejemplo de caracterizaci´on de nombre tenemos “S17V-03COM” que define al switch 17 que transmite voz, conectado a la boca 3 del switch central, y que se sit´ua en el departamento comercial. 4.3. Caracterizaci´on del cableado del edificio y disposici´on de los elementos Para caracterizar el cableado debemos localizar los elementos principales de conexi´on estos est´an definidos en Figura 4.2 y Figura 4.3: RK02M-00P2: Armario rack situado en Piso 2 dispone del switch central y bocas patch con alcance de toda su planta RK01M-00CPD: Armario rack situado en Piso -1, en la sala CPD, contiene todos los equipos del CPD. 46 CAP´ ITULO 4. AN ´ ALISIS DE LA INFRAESTRUCTURA Y FIJACI ´ ON DE OBJETIVOS RK03M-00CPD: Armario rack situado en Piso -1, en la sala CPD, contiene el patch con alcance a los pisos -1, 0 y 1 y un switch de la capa de acceso Una vez localizados los elementos principales, estudiamos el cableado entre plantas y salas. Viene dispuesto como el esquema de Figura 4.2 y Figura 4.3. Todas las conexiones, tanto para el cableado vertical, como el horizontal, como el de ´area de trabajo, se realizan mediante cable Ethernet de categor´ıa 5e, que soporta Gigabit Ethernet, 1000 Mbps, y hasta 100 metros de distancia del cableado entre repetidores, sin que resulte en una ca´ıda significativa de la velocidad de transmisi´on de datos. 4.3.1. Cableado vertical El cableado vertical lo conforman los cables troncales del edificio, en este caso ser´an los que conectan los 3 armarios rack entre s´ı. RK02M-00P2 se conecta con RK03M-00CPD mediante cables de longitud inferior a 40 metros que van del switch central, S00M-00P2, a un switch localizado en el segundo armario, S16T-03CPD, tambi´en a las bocas patch de dicho armario. RK02M-00P2 se conecta con RK01M-00CPD a trav´es de cables de longitud inferior a 40 metros que parten de diferentes bocas del switch central a una serie de elementos agrupados en este armario, tal como el firewall, y diversos servidores. 4.3.2. Cableado horizontal El cableado horizontal est´a formado por los cables que conectan el ´area de trabajo, a la red troncal. En este caso est´a conformado por los cables que, por el interior de las paredes, van desde los paneles patch de los armarios rack a las rosetas de las salas del edificio. RK02M-00P2 contiene el patch que conectar´a al switch central los equipos que se conecten a cualquier habitaci´on perteneciente a la planta 2. RK03M-00CPD contiene el patch que conectar´a al switch central los equipos que se conecten a cualquier habitaci´on perteneciente a la plantas -1, 0 y 1. 4.3.3. Cableado de ´area de trabajo El cableado de ´area de trabajo est´a formado por el cableado, o tecnolog´ıa de conexi´on inal´ambrica, que conecta los equipos de trabajo de cada sala al cableado horizontal. En este caso por todas las conexiones de cada equipo desde las tomas de datos a los terminales. 47 4.6. CONFIGURACI ´ ON DE LOS ELEMENTOS PRINCIPALES DE LA RED 4.6. Configuraci´on de los elementos principales de la red 4.6.1. Servicios activos del switch central S00M-00P2 es el elemento central de distribuci´on del trafico dentro de la LAN. Este elemento no solo distribuye el tr´afico, sino que aporta una capa de seguridad extra con las siguientes configuraciones: VLANs del tipo IEEE 802.Q Permite o deniega el paso del tr´afico asignando y desasignando etiquetas VLAN ID. Se dispone de las VLANs de Tabla 4.12: VLAN 1: Es la de defecto. Est´a afiliada a todos los puertos, todos ellos configurados como Untagged para esta VLAN, es decir, configurados para ser desprovistos de etiqueta VLAN al abandonar el switch. Se usa como control de tr´afico. VLAN 2: Est´an afiliados todos los puertos cuya transmisi´on sea de VOIP (Tel´efonos VoIP y PBX). Todos de tipo Untagged. VLAN 10-40: Cada VLAN est´a afiliada exclusivamente a los puertos que conectan con la sala de su departamento y sus servidores asociados. Todos est´an afiliados al puerto de conexi´on con el firewall UTM, NET, as´ı como al ERP. Todos los puertos son Untagged. VLAN 50-100: VLANs de servicios internos. Los puertos afiliados ser´an exclusivamente sus clientes. Todos los puertos son Untagged. VLAN 120: Conecta al firewall UTM, ofrece conexi´on con el servidor de correo e internet. 54 CAP´ ITULO 4. AN ´ ALISIS DE LA INFRAESTRUCTURA Y FIJACI ´ ON DE OBJETIVOS Puertos (Untagged todos) VLAN ID VLAN NOMBRE Etiqueta interna Afiliados 1Default 35-48 Todos 2VOZ 1-9 1-9, 110 10 OFI 10-15 10-15, 27, 28, 34 20 COM 16, 17 16, 17, 27, 29, 34 30 DES 18-20 18-20, 27, 30, 34 40 CMN 21-26 21-27, 31, 32, 34 50 ERP 27 10-27 60 NS1 28 10-15, 28 70 NS2 29 16, 17, 28 80 NS3 30 18-20, 30 90 NS4 31 21-27, 31 100 NS5 32 21-27, 32 110 SV1 33 1-9, 33, 34 120 NET 34 10-34 Tabla 4.12: Vlans en switch central Figura 4.4: Conexiones al switch central 55 4.6. CONFIGURACI ´ ON DE LOS ELEMENTOS PRINCIPALES DE LA RED Rate Limits Configuraci´on de l´ımites de ancho de banda seg´un el puerto, tanto para el tr´afico saliente como para el entrante. Trusted MAC address Tabla con de direcciones MAC. S´olo redirigir´a el tr´afico de aquellos equipos cuya MAC est´e inscrita en la tabla. Si no hay elementos en la lista redirigir´a el trafico de forma independiente a cu´al sea la MAC de origen. IP Access List Contiene la lista de direcciones IP que pueden acceder a la parte de configuraci´on del switch. Si no hay elementos en la lista permitir´a acceder a todas las direcciones IP 4.6.2. Servicios en DMZ En la DMZ ´unicamente de dispone de un servidor de correo puesto que ser´a el ´unico servicio que requiere ser accedido por usuarios externos. Los protocolos por los que tendr´ıa que ofrecer servicio son: POP3, SMTP, IMAP. 4.6.3. Firewall El firewall instalado es un I.M.T versi´on 2.6.18[32]. Es un cortafuegos UTM bajo el SO Linux 2.6.18, que combina e integra m´ultiples servicios orientados a la seguridad. Todos los servicios integrados son configurables a trav´es de una interfaz web. A continuaci´on, dividimos los servicios que otorga el sistema firewall en 3 bloques: Servicios que usa el cliente actualmente. Servicios en los que se ha detectado un problema con su funcionamiento. Servicios disponibles en desuso. Servicios usados Actualmente los ´unicos servicios que est´an siendo usados activamente por el cliente son: IPTables: Reglas de filtrado y redirecci´on de tr´afico en la capa 3. Es el firewall perimetral. Se usan las siguientes tablas dentro de esta: •NAT: El firewall esta desplegado en Modo Pasarela, es decir, realiza funci´on de IP Forwarding. Se conecta recibiendo todas las peticiones de los equipos de la red, las procesa y las env´ıa por la interfaz interna, externa o DMZ. 56 CAP´ ITULO 4. AN ´ ALISIS DE LA INFRAESTRUCTURA Y FIJACI ´ ON DE OBJETIVOS •Filtrado: Lista de control de acceso a la red por IP, puerto y protocolo. La lista esta configurada en modo secuencial, es de decir, la prioridad de las reglas esta regulado por su orden de aparici´on en sentido descendiente. Figura 4.5: Filtrado mediante ACL Servidor DHCP: asigna direcciones IP, as´ı como la puerta de enlace y los servidores DNS autom´aticamente a las m´aquinas en la red local. Servidor DNS: proporciona la posibilidad de definir dominios internos con sus correspondientes subdominios seg´un las necesidades de la red. Dominio de email definido. Protocolo de enrutamiento RIP. El equipo adem´as de los servicios de firewall mencionados en la seccion anterior consta de los siguientes servicios modulares que fueron contratados por la empresa: Servicio Funcionalidad Funcional Chivato web Recopilar y mostrar informaci´on de los sitios web accedidos por usuarios de la red interna NO ntop Recopilar y mostrar informaci´on referente al uso de la red interna SI IDS Detecci´on de intrusos NO Gestor PKI Generar certificados SI Cacti RRDTool Generar gr´aficos referentes al tr´afico de red NO Control Web Controlar el acceso web de los usuarios NO WOL Encender equipo en remoto NO Auditor Seguridad Escaneo de vulnerabilidades de seguridad NO 4.6.4. Vulnerabilidades en el sistema Para analizar que riesgos ocasiona el sistema UTM firewall actualmente instalado, se realiza un escaneo de vulnerabilidades desde la red interna contra este, con el objeto de conocer a que fallos de seguridad est´a expuesta la red. La herramienta utilizada para realizar este escaneo es OpenVAS. A partir de una configuraci´on dada devolver´a como resultado un informe con las vulnerabilidades, c´omo se detectaron, su severidad, etc. Las m´etricas a utilizar en este an´alisis son: Severidad: Valor entre 0.0 y 10.0 que viene dado por el CVSS Base Score Calculator[36]. Siendo 10.0 la m´axima severidad, este valor viene definido por: 57 4.6. CONFIGURACI ´ ON DE LOS ELEMENTOS PRINCIPALES DE LA RED •Vector de Acceso (AV): C´omo es explotada la vulnerabilidad. A m´as remoto pueda estar un atacante del host, mayor ser´a la puntuaci´on de la vulnerabilidad para este aspecto. Puede ser: ◦Local (L): Requiere acceso f´ısico al sistema o desde una cuenta local por parte del atacante. ◦Adyacente a la red (A): Requiere acceso a la red local. ◦Red externa(N): Se puede realizar desde una red externa. •Complejidad de Acceso (AC): complejidad del ataque para explotar la vulnerabilidad una vez que el atacante ha ganada acceso al sistema. A menor complejidad mayor ser´a la puntuaci´on. Se clasifican en: ◦Alto (H): Existencia de condiciones muy espec´ıficas. ◦Medio (M): Existencia de condiciones comunes pero especificas. ◦Bajo (L): No se necesitan condiciones especificas para llevar a cabo el ataque, por ejemplo en sistema con configuraci´on por defecto. •Autenticaci´on (Au): Veces que el atacante debe autenticarse para explotar la vulnerabilidad. A menores veces mayor ser´a la puntuaci´on. Se clasifican en: ◦M´ultiple (M): Requiere 2 o mas autenticaciones ◦´ Unica (S): Requiere 1 autenticaci´on. ◦No Requerida (N): No requiere autenticaci´on. •Impacto en la Confidencialidad (C): Cantidad de informaci´on no autorizada a la que tiene acceso el atacante tras explotar la vulnerabilidad. A mayor acceso mayor ser´a la puntuaci´on. Se clasifica en: ◦Ninguna (N): No tiene acceso a informaci´on. ◦Parcial (P): Tiene acceso a informaci´on parcial. ◦Completa (C): Tiene acceso a toda la informaci´on del sistema. •Integridad (I): Cantidad de informaci´on que puede ser modificada por el atacante. A mayor cantidad mayor ser´a la puntuaci´on. Se clasifica en: ◦Ninguna (N): No afecta a la integridad de la informaci´on. ◦Parcial (P): Parte del sistema es susceptible a modificaci´on de informaci´on. ◦Completa (C): Toda la informaci´on del sistema est´a comprometida. •Disponibilidad (A): Impacto en la disponibilidad del sistema si la vulnerabilidad es explotada. A menor disponibilidad mayor ser´a la puntuaci´on. Se clasifica en: ◦Ninguna (N): No impacta a la disponibilidad del sistema. ◦Parcial (P): Puede haber interrupciones en la disponibilidad de los recursos del sistema. ◦Completa (C): Puede hacer que el sistema no este disponible por completo. QoD (Calidad de Detecci´on): valor entre 0 % y 100 % que indica la fiabilidad de la detecci´on de la vulnerabilidad. Siendo 100 % detectada v´ıa exploit y por lo tanto completamente verificada.[37] Para los esc´aneres realizados se recoger´an vulnerabilidades del rango est´andar de QoD, entre 100 %-70 %. Se han realizado 2 tipos de esc´aneo con OpenVas: 58 CAP´ ITULO 4. AN ´ ALISIS DE LA INFRAESTRUCTURA Y FIJACI ´ ON DE OBJETIVOS CVE[35]: permite pronosticar posibles riesgos de seguridad basados en informaci´on publicada por proveedores e investigadores de seguridad en la base de datos de CVE. Este tipo de esc´aner no debe usarse para evaluar si existe o no una vulnerabilidad real, sino que debe usarse para brindar al usuario final una idea de las vulnerabilidades potenciales debido a que los resultados corresponden a las vulnerabilidades individuales del sistema. No toma el conjunto del sistema en consideraci´on, simplemente devuelve todas las coincidencias con la base de datos CVE. Por ello se devolver´an muchos falsos positivos. OpenVAS Default: Hace un escaneo del sistema en su conjunto para obtener las vulnerabilidades del sistema. Para extraer las vulnerabilidades aplica test de NVT. En los resultados se mostrar´a el test NVT aplicado, el QoD, y la severidad de cada vulnerabilidad. Resultados escaneo CVE Para las vulnerabilidades unitarias, se puede observar que se han detectado 303 vulnerabilidades en el sistema, siendo un 27 % de ellos vulneralidades con una severidad alta, que ponen el sistema gran riesgo. Las puntuaciones las vulnerabilidades vienen dadas por: Figura 4.6: Vulnerabilidades CVE - infodesain En la clasificaci´on por tipo observada en la Figura 4.7 se puede ver que de las 5 aplicaciones detectadas por OpenVAS 4 tienen posibles puntos de explotaci´on de vulnerabilidades con severidad 10.0, que indica la posibilidad de completa toma de control del sistema por parte de un atacante. 59 4.6. CONFIGURACI ´ ON DE LOS ELEMENTOS PRINCIPALES DE LA RED Figura 4.7: Vulnerabilidades CVE por tipo - infodesain Resultados escaneo OpenVAS Default El n´umero de vulnerabilidades detectadas en funci´on al sistema completo es significativamente menor que el de las unitarias. Se ha reducido considerablemente las vulnerabilidades que aportan un gran riesgo. 2 frente a 83, tal y como se puede observar en las figuras 4.8 y 4.6 respectivamente. Figura 4.8: Vulnerabilidades test OpenVas Default - infodesain 60 CAP´ ITULO 4. AN ´ ALISIS DE LA INFRAESTRUCTURA Y FIJACI ´ ON DE OBJETIVOS La Tabla 4.13 compone un resumen de las diferentes vulnerabilidades detectadas durante el an´alisis: Vulnerabilidad Severidad QoD Localizaci´on Apache httpd Web Server Range Header Denial of Service Vulnerability 7.8 100 % 8000/tcp 443/tcp SSL/TLS: OpenSSL CCS Man in the Middle Security Bypass Vulnerability 6.8 70 % 443/tcp HTTP Debugging Methods (TRACE/TRACK) Enabled 5.8 99 % 8000/tcp 443/tcp 3128/tcp Tildeslash Monit <5.25.3 Multiple Vulnerabilities 5.5 80 % 2812/tcp SSL/TLS: Report Vulnerable Cipher Suites for HTTPS 5.0 98 % 443/tcp SSL/TLS: Certificate Expired 5.0 99 % 443/tcp 1241/tcp Cleartext Transmission of Sensitive Information via HTTP 4.8 80 % 2812/tcp FTP Unencrypted Cleartext Login 4.8 70 % 21/tcp SSL/TLS: Deprecated SSLv2 and SSLv3 Protocol Detection 4.3 98 % 443/tcp SSL/TLS: Report Weak Cipher Suites 4.3 98 % 1241/tcp 443/tcp SSL/TLS: RSA Temporary Key Handling ’RSA EXPORT’ Downgrade Issue (FREAK) 4.3 80 % 443/tcp SSL/TLS: SSLv3 Protocol CBC Cipher Suites Information Disclosure Vulnerability (POODLE) 4.3 80 % 443/tcp Apache Web Server ETag Header Information Disclosure Weakness 4.3 80 % 443/tcp 8000/tcp SSH Weak Encryption Algorithms Supported 4.3 95 % 22/tcp Mod Perl Path Info Remote Denial Of Service Vulnerability 4.3 80 % 443/tcp 8000/tcp SSL/TLS: ’DHE EXPORT’ Man in the Middle Security Bypass Vulnerability (LogJam) 4.3 80 % 443/tcp Apache HTTP Server ’httpOnly’ Cookie Information Disclosure Vulnerability 4.3 99 % 443/tcp 8000/tcp SSL/TLS: Diffie-Hellman Key Exchange Insufficient DH Group Strength Vulnerability 4.3 80 % 443/tcp SSL/TLS: Certificate Signed Using A Weak Signature Algorithm 4.0 80 % 1241/tcp 443/tcp TCP timestamps 2.6 80 % general/tcp Apache mod perl ’Apache::Status’ and ’Apache2::Status’ Cross Site Scripting Vulnerability 2.6 80 % 443/tcp 8000/tcp SSL/TLS: TLS/SPDY Protocol Information Disclosure Vulnerability (CRIME) 2.6 98 % 443/tcp SSH Weak MAC Algorithms Supported 2.6 90 % 22/tcp Tabla 4.13: Lista de vulnerabilidades encontradas Observando la Tabla 4.13 destacan las 2 vulnerabilidades de severidad alta se corresponden con vulnerabilidad de denegaci´on de servicio para los puertos 443 y 8000. El riesgo de que se explote esta vulnerabilidad es alto debido que tiene un QoD de 100 %. Adem´as como tiene una puntuaci´on de severidad alta es f´acil de explotar. Como se puede observar en la Figura 4.9, tiene una severidad de 7.8. Esta nota vienen dada por las condiciones para su explotaci´on. Se indica que la vulnerabilidad se puede explotar desde una red externa, tiene una complejidad de acceso baja, no requiere autenticaci´on, no impacta a la confidencialidad ni a la integridad de la informaci´on pero si a la disponibilidad ya que puede hacer que el sistema no est´e disponible por completo. La causa de estas vulnerabilidades viene dada por el hecho de usar una versi´on de Apache obsoleta. 61 4.6. CONFIGURACI ´ ON DE LOS ELEMENTOS PRINCIPALES DE LA RED Figura 4.9: Vulnerabilidades en puerto 443 y 8000 - infodesain En cuanto a las vulnerabilidades de severidad media, que se corresponden, en la Tabla 4.13, a las vulnerabilidades con severidad dentro del rango 6.8-4.0, se observa que la gran mayor´ıa corresponde a encriptaciones d´ebiles y servicios obsoletos. Estas vulnerabilidades tambi´en vienen dadas por el uso de servicios y hardware obsoleto. En el caso de las vulnerabilidades de severidad baja ocurre exactamente lo mismo que para las de severidad alto y medio, existen por el hecho de usar hardware y servicios obsoletos. Los informes obtenidos dejan claro que este equipo es muy vulnerable y se ha de reemplazar de inmediato. Confidencialidad Antes de realizar ning´un an´alisis, se hizo un escaneo de puertos, donde se detect´o que el puerto 3000, un puerto que no se est´a usando por parte de los empleados de la empresa, esta abierto. Accediendo desde el exterior se observa que a lo que se accede es a la interfaz web del programa ntop. Todos los datos de la red de la empresa se encuentran disponibles desde ese puerto. Se ha podido acceder a esos datos desde una red externa, y sin ning´un tipo de autenticaci´on, simplemente escribiendo en el navegador la direcci´on de acceso. Se considera que esta configuraci´on causa una gran brecha en la confidencialidad de la red de la empresa. 62 CAP´ ITULO 4. AN ´ ALISIS DE LA INFRAESTRUCTURA Y FIJACI ´ ON DE OBJETIVOS 4.7. Caracter´ısticas de la red actual A continuaci´on, se resume la funcionalidad que cumple la red con la configuraci´on actual: NoDescripci´on 1 La red permite conexi´on entre usuarios afiliados a una misma VLAN. 2 Se permite todo tipo de conexiones de la red interna a la externa. 3 La red dispone de DMZ con un servidor email. 4 La red permite conexi´on de usuarios internos al servidor de email disponible en la DMZ. 5 La red permite conexi´on de usuarios externos al servidor de email disponible en la DMZ. 6 La red permite escalabilidad de equipos. 7 El MTBF de disponibilidad de la red es de 3000 horas aproximadamente, es decir, cada 4 meses se produce un fallo en la infraestructura de red que no permite realizar las funciones habituales a alguno de los equipos. 8 El ancho de banda esta limitado a 100 MBPS para la totalidad de la red. Tabla 4.14: funciones actuales de la red 4.7.1. Grupos de usuarios actuales Se distinguen 3 tipos de usuarios en el uso de la red: Usuario externo: usuario con acceso restringido al servidor de email ubicado en la DMZ. Se conectan a la red mediante IP p´ublica. Usuario interno limitado: usuario de la red interna con acceso a todos los servicios de su departamento. Usuario Administrador: Usuario interno con acceso a toda la red, puede monitorizar la red y cambiar las configuraciones de esta. 4.8. Evaluaci´on del an´alisis de la red En esta secci´on se va a resumir las conclusiones a las que se ha llegado a partir de los resultados obtenidos por el estudio de la red. Para ajustarse a los requerimientos de seguridad actuales se debe cambiar el sistema firewall instalado actualmente por uno que funcione adecuadamente, aumente la seguridad actual de la infraestructura, cumpla los est´andares de seguridad, y ofrezca los servicios que el cliente quiere explotar. 63 4.11. CASOS DE USO UC9 Restablecer valores configuraci´on a versiones anteriores Req Asociado 12 Actores usuario administrador Descripci´on El usuario restablece la configuraci´on a una versi´on anterior Precondici´on El usuario ha realizado el CU loguearse en consola Secuencia 1El usuario selecciona la opci´on de restablecer configuraci´on anterior. 2El sistema muestras las configuraciones anteriores 3El usuario selecciona la versi´on a restablecer 4El sistema comprueba, guarda y aplica los cambios realizados. Postcondici´on El usuario ha cambiado la configuraci´on del sistema. Excepciones 3aEl usuario cancela la operaci´on, el caso de uso queda sin efecto. Tabla 4.24: Descripci´on del caso de uso: Restablecer valores configuraci´on a versiones anteriores UC10 Acceso al configurador web mediante HTTPs Req Asociado 12 Actores usuario administrador Descripci´on El usuario accede al sistema por interfaz gr´afica. Precondici´on Se ha realizado el CU crear usuarios y acceso a red Secuencia 1El usuario solicita conexi´on HTTPs 2El sistema autentifica al usuario, cifra la conexion y solicita credenciales 3El usuario introduce las credenciales. 4El sistema muestra la p´agina principal del configurador. Postcondici´on El usuario se ha logueado en el configurador web del sistema. Excepciones 1aEl usuario no reconoce al sistema, el caso de uso queda sin efecto. 2aEl sistema no reconoce al usuario y deniega la petici´on, el caso de uso queda sin efecto. 3aEl usuario cancela, el caso de queda sin efecto. 3bEl usuario ha introducido las credenciales incorrectas demasiadas veces, el sistema bloquea el intento de conexiones para el usuario durante un tiempo que aumenta exponencialmente en funci´on del n´umero de intentos. El caso de uso queda sin efecto. Tabla 4.25: Descripci´on del caso de uso: Acceso al configurador web mediante HTTPs UC11 Gesti´on/monitorizaci´on de las ´areas Req Asociado 12 Actores usuario administrador Descripci´on El usuario gestiona/monitoriza el sistema. Precondici´on Se ha realizado el CU acceso al configurador web mediante HTTPs y acceso a red Secuencia 1El usuario accede a una de las ´areas de configuraci´on. (Extensi´on 12-24) 2El sistema muestra el ´area 3El usuario gestiona/monitoriza el sistema. 4El sistema lleva a cabo la acci´on realizada. Postcondici´on El usuario obtiene postcondici´on de alguno de los casos extensi´on 12-24 Excepciones 3aEl usuario cancela la operaci´on, el caso de uso queda sin efecto. 4aEl sistema reconoce la acci´on como incorrecta. Contin´ua en paso 3. Tabla 4.26: Descripci´on del caso de uso: Gesti´on/monitorizaci´on de las ´areas 70 CAP´ ITULO 4. AN ´ ALISIS DE LA INFRAESTRUCTURA Y FIJACI ´ ON DE OBJETIVOS UC12 Crear backup de configuraci´on Req Asociado 12 Actores usuario administrador Descripci´on El usuario obtiene el archivo de la configuraci´on actual Precondici´on Se ha realizado el CU acceso al configurador web mediante HTTPs y acceso de red Secuencia 1El usuario accede al ´area de backup. 2El sistema muestra el ´area. 3El usuario solicita la descarga del archivo de configuraci´on del sistema. 4El sistema genera el archivo de configuraci´on. Postcondici´on El usuario dispone del archivo de configuraci´on del sistema. Excepciones 3aEl usuario cancela la operaci´on, el caso de uso queda sin efecto. Tabla 4.27: Descripci´on del caso de uso: Crear backup de configuraci´on UC13 Gestionar permisos de conexi´on entre interfaces Req Asociado 12 Actores usuario administrador Descripci´on El usuario modifica los permisos de acceso entre usuarios de las interfaces. Precondici´on Se ha realizado el CU acceso al configurador web mediante HTTPs y acceso de red Secuencia 1El usuario accede al ´area de firewall. 2El sistema muestra el ´area. 3El usuario modifica las reglas de firewall para la interfaz. 4El sistema comprueba, guarda y aplica los cambios realizados Postcondici´on Los permisos de acceso entre interfaces han cambiado. Excepciones 3aEl usuario cancela la operaci´on, el caso de uso queda sin efecto. 4aEl sistema reconoce los cambios como incorrectos, vuelve a pedir un nuevo valor de configuraci´on. Contin´ua en paso 3. Tabla 4.28: Descripci´on del caso de uso: Gestionar permisos de conexi´on entre interfaces UC14 Wake on Lan Req Asociado 12 Actores usuario administrador Descripci´on El usuario enciende uno de los equipos conectados a la LAN. Precondici´on Se ha realizado el CU acceso al configurador web mediante HTTPs, Registrar conexiones de equipos y acceso de red. Secuencia 1El usuario accede al ´area de WOL. 2El sistema muestra el ´area. 3El usuario selecciona el equipo a despertar. 4El sistema enciende el equipo. Postcondici´on El equipo ha sido encendido. Excepciones 3aEl usuario cancela la operaci´on, el caso de uso queda sin efecto. 4aEl sistema reconoce los cambios como incorrectos, vuelve a pedir un nuevo valor de configuraci´on. Contin´ua en paso 3. Tabla 4.29: Descripci´on del caso de uso: Wake on Lan 71 4.11. CASOS DE USO UC15 Registrar conexiones de equipo Req Asociado 12 Actores usuario administrador Descripci´on El usuario configura DHCP est´atico para un equipo. Precondici´on Se ha realizado el CU acceso al configurador web mediante HTTPs, Registrar conexiones de equipos y acceso de red. Secuencia 1El usuario accede al ´area de DHCP de la interfaz 2El sistema muestra el ´area. 3El usuario rellena los datos de direccion IP, mac, host... 4El sistema registra el mapeo est´atico DHCP. Postcondici´on El equipo recibe la direcci´on IP configurada. Excepciones 3aEl usuario cancela la operaci´on, el caso de uso queda sin efecto. 4aEl sistema reconoce los cambios como incorrectos, vuelve a pedir un nuevo valor de configuraci´on. Contin´ua en paso 3. Tabla 4.30: Descripci´on del caso de uso: Registrar conexiones de equipo UC16 Registrar conexiones VPN Req Asociado 12 Actores usuario administrador Descripci´on El usuario configura un nuevo cliente VPN Precondici´on Se ha realizado el CU acceso al configurador web mediante HTTPs, Registrar conexiones de equipos, acceso de red y crear usuarios Secuencia 1El usuario accede al ´area de configuraci´on VPN 2El sistema muestra el ´area. 3El usuario rellena los datos de conexi´on del cliente. 4El sistema registra al nuevo acceso VPN Postcondici´on Hay un nuevo cliente VPN con privilegios de acceso a la red mediante VPN Excepciones 3aEl usuario cancela la operaci´on, el caso de uso queda sin efecto. 4aEl sistema reconoce los cambios como incorrectos, vuelve a pedir un nuevo valor de configuraci´on. Contin´ua en paso 3. Tabla 4.31: Descripci´on del caso de uso: Registrar conexiones VPN UC17 Monitorizar el tr´afico de red Req Asociado 12 Actores usuario administrador Descripci´on El usuario monitoriza el tr´afico de red Precondici´on Se ha realizado el CU acceso al configurador web mediante HTTPs, el acceso de red Secuencia 1El usuario accede al area del log de tr´afico de red 2El sistema muestra el ´area. 3El usuario visualiza los logs de tr´afico de red Postcondici´on El usuario visualiza los datos Excepciones 3aEl usuario cancela la operaci´on, el caso de uso queda sin efecto. Tabla 4.32: Descripci´on del caso de uso: Crear usuarios 72 CAP´ ITULO 4. AN ´ ALISIS DE LA INFRAESTRUCTURA Y FIJACI ´ ON DE OBJETIVOS UC18 Crear usuarios Req Asociado 12 Actores usuario administrador Descripci´on El usuario monitoriza el tr´afico de red Precondici´on Se ha realizado el CU acceso al configurador web mediante HTTPs, y acceso de red Secuencia 1El usuario accede al ´area de gesti´on de usuarios. 2El sistema muestra el ´area. 3El usuario crea un nuevo usuario, asignandole los permisos correspondientes. 4El sistema guarda los cambios de usuario. Postcondici´on El usuario visualiza los datos Excepciones 3aEl usuario cancela la operaci´on, el caso de uso queda sin efecto. 4aEl sistema reconoce los cambios como incorrectos, vuelve a pedir un nuevo valor de configuraci´on. Contin´ua en paso 3. Alternativas Si el usuario ya existe en el sistema: 1El usuario accede al area de gesti´on de usuarios. 2El sistema muestra el ´area. 3El usuario selecciona el usuario del sistema a modificar. 4El sistema muestras las opciones a editar. 5El usuario edita la configuraci´on del usuario de sistema. 6El sistema guarda los cambios de usuario. Excepciones 3b, 5bEl usuario cancela la operaci´on, el caso de uso queda sin efecto. 6bEl sistema reconoce los cambios como incorrectos, vuelve a pedir un nuevo valor de configuraci´on. Contin´ua en paso 4. Tabla 4.33: Descripci´on del caso de uso: Crear usuarios UC19 Gestionar permisos de los usuarios de la intranet a recursos web Req Asociado 12 Actores usuario administrador Descripci´on El usuario cambia los permisos de acceso a determinados recursos web de la red externa Precondici´on Se ha realizado el CU acceso al configurador web mediante HTTPs, acceso de red, y crear usuarios Secuencia 1El usuario accede al ´area de gesti´on del proxy web 2El sistema muestra el ´area. 3El usuario modifica las listas de acceso para el usuario. 4El sistema guarda las nuevas normas de acceso para el usuario. Postcondici´on Los permisos de acceso cambiaron para el usuario configurado. Excepciones 3aEl usuario cancela la operaci´on, el caso de uso queda sin efecto. 4aEl sistema reconoce los cambios como incorrectos, vuelve a pedir un nuevo valor de configuraci´on. Contin´ua en paso 3. Tabla 4.34: Descripci´on del caso de uso: Gestionar permisos de los usuarios de la intranet a recursos web 73 4.11. CASOS DE USO UC20 Cambiar el ancho de banda percibido por usuario Req Asociado 12 Actores usuario administrador Descripci´on El usuario cambia el ancho de banda percibido por un usuario del sistema Precondici´on Se ha realizado el CU acceso al configurador web mediante HTTPs, acceso de red, y crear usuario Secuencia 1El usuario accede al ´area de gesti´on de gesti´on de ancho de banda 2El sistema muestra el ´area. 3El usuario modifica el ancho de banda percibido por el usuario del sistema 4El sistema guarda la nueva configuraci´on de repartici´on de ancho de banda. Postcondici´on El ancho de banda cambi´o para el usuario configurado. Excepciones 3aEl usuario cancela la operaci´on, el caso de uso queda sin efecto. 4aEl sistema reconoce los cambios como incorrectos, vuelve a pedir un nuevo valor de configuraci´on. Contin´ua en paso 3. Tabla 4.35: Descripci´on del caso de uso: Cambiar el ancho de banda percibido por usuario UC21 Bloquear tr´afico en funci´on listas IP, pais Req Asociado 12 Actores usuario administrador Descripci´on El usuario cambia los permisos de comunicaci´on con sistemas externos. Precondici´on Se ha realizado el CU acceso al configurador web mediante HTTPs, y acceso de red Secuencia 1El usuario accede al ´area de gesti´on de listas de bloqueo. 2El sistema muestra el ´area. 3El usuario activa las listas negras que desea aplicar 4El sistema guarda los cambios de configuraci´on Postcondici´on Los permisos de acceso a recursos de terceros o desde terceros han cambiado Excepciones 3aEl usuario cancela la operaci´on, el caso de uso queda sin efecto. 4aEl sistema reconoce los cambios como incorrectos, vuelve a pedir un nuevo valor de configuraci´on. Contin´ua en paso 3. Tabla 4.36: Descripci´on del caso de uso: Bloquear tr´afico en funci´on listas IP, pa´ıs UC22 Cambiar elementos a almacenar en cach´e por el sistema Req Asociado 12 Actores usuario administrador Descripci´on El usuario cambia la configuraci´on de los elementos que guarda en disco el sistema para su posterior acceso por parte de los usuarios. Precondici´on Se ha realizado el CU acceso al configurador web mediante HTTPs, y acceso de red Secuencia 1El usuario accede al ´area de gesti´on del proxy web 2El sistema muestra el ´area. 3El usuario cambia las reglas de almacenamiento de elementos. 4El sistema guarda los cambios de configuraci´on Postcondici´on Los usuarios descargar´an recursos nuevos desde el sistema o desde un sistema externo en funci´on a la nueva configuraci´on. Excepciones 3aEl usuario cancela la operaci´on, el caso de uso queda sin efecto. 4aEl sistema reconoce los cambios como incorrectos, vuelve a pedir un nuevo valor de configuraci´on. Contin´ua en paso 3. Tabla 4.37: Descripci´on del caso de uso: Cambiar elementos a almacenar en cach´e por el sistema 74 CAP´ ITULO 4. AN ´ ALISIS DE LA INFRAESTRUCTURA Y FIJACI ´ ON DE OBJETIVOS UC23 Monitorizaci´on por capa de aplicaci´on Req Asociado 12 Actores usuario administrador Descripci´on El usuario monitoriza el tr´afico de capa de aplicaci´on y realiza cambios pertinentes en funci´on a este. Precondici´on Se ha realizado el CU acceso al configurador web mediante HTTPs, y acceso de red Secuencia 1El usuario accede al ´area de gesti´on del IDS 2El sistema muestra el ´area. 3El usuario monitoriza la actividad de los usuarios. Postcondici´on El usuario visualiza los datos de actividad de los usuarios. Excepciones 3aEl usuario cancela la operaci´on, el caso de uso queda sin efecto. Tabla 4.38: Descripci´on del caso de uso: Monitorizaci´on por capa de aplicaci´on UC24 Actualizar ´areas del sistema Req Asociado 12 Actores usuario administrador Descripci´on El usuario actualiza las ´areas de configuraci´on del sistema. Precondici´on Se ha realizado el CU acceso al configurador web mediante HTTPs, y acceso de red Secuencia 1El usuario accede al ´area de gesti´on de paquetes del sistema. 2El sistema muestra el ´area. 3El usuario seleciona las areas que desea actualizar. 4El sistema actualiza las ´areas. Postcondici´on El sistema se ha actualizado Excepciones 3aEl usuario cancela la operaci´on, el caso de uso queda sin efecto. 4aEl sistema no puede actulizar correctamente el ´area, el caso de uso queda sim efecto. Tabla 4.39: Descripci´on del caso de uso: Actualizar ´areas del sistema 75 4.11. CASOS DE USO 76 CAP´ ITULO 5. DISE ˜ NO DE LA SOLUCI ´ ON Cap´ıtulo 5 Dise˜no de la Soluci´on 5.1. Introducci´on En este cap´ıtulo se va a dise˜nar la soluci´on que permita cumplir con los requisitos del proyecto. El dise˜no de la soluci´on a dise˜nar depende fuertemente del sistema a instalar y configurar, por ello, tras haber realizado el an´alisis es imperativo elegir el sistema a instalar. Una vez dotados del sistema a configurar que permita el acoplamiento de todas los requisitos que conformen la red segura se dise˜na la soluci´on por cara requerimiento. 5.2. Elecci´on de la UTM En la secci´on 2.8 se realiz´o una comparativa entre los diferentes candidatos a implantar como sistema soluci´on. Se ha elegido pfSense. Los motivos de la decisi´on son los siguientes: Actualizaciones frecuentes: Tiene actualizaciones frecuentes del sistema y sus componentes. Semanales o mensuales. ´ Unicamente OPNsense esta a la par con pfSense en este sentido. El resto de firewalls estudiados no hay tenido actualizaciones en meses. Este punto es crucial para el mantenimiento del sistema. Soporta software de terceros por lo que el abanico de opciones se amplia extensamente. Comunidad: De los sistemas estudiados el que consta de una comunidad mayor y m´as activa puesto que pfSense lleva a˜nos afianzado en el sector y su popularidad no decae debido a sus estabilidad, frecuentes actualizaciones y soporte de software de terceros. Documentaci´on: pfSense dispone de documentaci´on oficial muy cuidada, extensa y actualizada adem´as de la ya proporcionada por su comunidad. 77 5.3. ELECCI ´ ON DEL HARDWARE SO FreeBSD: Se considera la instalaci´on de un sistema basado en FreeBSD una mejor opci´on frente a uno basado en Linux. FreeBSD es m´as seguro y robusto. Filtrado mediante Packet Filter:Debido a su dependencia con SO FreeBSD. Se puede usar como IDS tanto Snort como Suricata. OpenVPN: adem´as de ser la mejor opci´on del mercado actualmente, pfSense cuenta con un wizard de configuraci´on de OpenVPN. Su interfaz de configuraci´on y gesti´on es friendly. Integra todos los componentes necesarios y preferibles para la configuraci´on del equipo en el entorno del cliente. 5.3. Elecci´on del Hardware Para la implantaci´on de un pfSense que cumpla todos los requisitos del cliente en el entorno empresarial el hardware ha de cumplir las siguientes caracter´ısticas[48]: Para el IDS Snort se necesitar´an +2 GB de RAM. Para Squid se ha de tener en cuenta que consume 14 MB de RAM por cada GB de cach´e en disco, m´as los requerimientos del propio Squid. Para la NIC (network interface card) : Se recomienda Intel PRO/1000 1Gb o PRO/10GbE 10Gb NICs porque tienen un soporte s´olido de controladores en FreeBSD y tienen gran rendimiento con el sistema. CPU que incluya AES-NI para usar el equipo como servidor VPN. Un disco mayor de 4 GB. Con todos los componentes a instalar y servicios de cache se ha optado por un disco de 500 GB. Se ha de comprobar la compatibilidad de los elementos con FreeBSD en las gu´ıas de freeBSD. [49] Tras tener en cuenta los requisitos m´ınimos requeridos por el software pfSense se ha decidido comprar un un DL360e de segunda mano. Las caracter´ısticas se pueden observar en la Tabla 5.1. Se ha decidido comprar un hardware que sobrepase ampliamente los requisitos m´ınimos pensando en su uso a largo plazo. Tambi´en se podr´a ampliar sus capacidades en un futuro si fuera necesario. 78 CAP´ ITULO 5. DISE ˜ NO DE LA SOLUCI ´ ON Componente f´ısico x 1 Producto: HP Proliant DL360e Gen8 1U 8x2.5”[50] Fabricante: HP Modelo: ProLiant DL360e Gen8 CPU: Quad-Core Intel Xeon E5-2407V1 2.20Ghz(10MB Cache, 6.40Gts, 80W) RAM: 16 GB CACHE: 10 MB HDD: 2x500 GB NoPuertos Gigabit Ethernet: 4 Tabla 5.1: Servidor DL360e 5.4. Arquitectura Para el router se asociar´a la MAC del equipo que contiene el pfSense instalado como direcci´on la direcci´on IP est´atica 193.168.1.3. Este equipo se asigna como DMZ en el router para que todo el tr´afico que inicie conexi´on desde la red externa sea redirigido al pfSense. Una vez instalado pfSense se deben configurar las diferentes interfaces de red. La configuraci´on de las interfaces seguir´a el esquema de la Figura 5.1. El firewall cuenta con 3 interfaces de red activas. Cada una corresponde a una subred: WAN: Conecta al puerto em0 del firewall cuya direcci´on es 192.168.1.3. Est´a conectado al router que da acceso a internet. No se configura DHCP para esta interfaz. No debe crear conexiones desde esta interfaz. LAN: usa el puerto em1 del firewall cuya direcci´on es 172.25.1.1. Los usuarios de la red interna se conectan desde esta interfaz. El firewall est´a configurado para que act´ue como servidor DHCP de esta subred. DMZ: usa el puerto r10 del firewall con la direcci´on de red 10.10.10.1. Hay un equipo que simular´a el servidor de correo de la red original. No se configura servidor DHCP para esta interfaz. La direcci´on IP de equipo se configura como est´atica. VPN: usa una direcci´on de red dentro de RFC1918 pero fuera de cualquiera otra red interna del sistema. 79 5.10. REGLAS DE REDIRECCI ´ ON NAT Reglas de la interfaz DMZ 1. Regla para permitir al servidor de email el acceso a todo en general. El alias svemail contiene la direcci´on IP del servidor de email. 2. Regla para rechazar a elementos conectados a la DMZ el acceso a redes privadas. Si otro equipo distinto del servidor de email se conectase a la DMZ solo podr´ıa comunicarse con la red externa. Reglas DMZ 1pass in quick on rl0 inet from <SV EMAIL>to any flags S/SA keep state 2block return in log quick on rl0 inet from 10.10.10.0/24 to <RFC1918> Tabla 5.7: Definicion de las reglas de acceso desde la interfaz DMZ Reglas de la interfaz WAN 1. Regla para bloquear las conexiones desde cualquier IP privada. 2. Regla para bloquear las conexiones desde IPs no registradas por IANA. 3. Reglas para permitir la conexi´on desde cualquier direcci´on al servidor de email de la DMZ mediante los protocolos: IMAPS, SMTP, IMAP, SMTP/S y SMTP/TLS. 4. Reglas para la creaci´on de t´uneles VPN que permitan a usuarios conectarse de forma remota a su departamento en la LAN. De estas reglas se hablara en apartado VPN. Reglas WAN 1block drop in log quick on em0 reply-to (em0 192.168.1.1) inet from <pfB PRI1 v4>to any label ¨ USER RULE: pfB PRI1 v4 auto rule” 2block drop in log quick on em0 from <bogons>to any label ”block bogon IPv4 networks from WAN” 2block drop in log quick on em0 from <bogonsv6>to any label ”block bogon IPv6 networks from WAN” 3pass in quick on em0 reply-to (em0 192.168.1.1) inet proto tcp from any to <SV EMAIL>port = imap flags S/SA keep state 3pass in quick on em0 reply-to (em0 192.168.1.1) inet proto udp from any to <SV EMAIL>port = imap keep state 3pass in quick on em0 reply-to (em0 192.168.1.1) inet proto tcp from any to <SV EMAIL>port = imaps flags S/SA keep state 3pass in quick on em0 reply-to (em0 192.168.1.1) inet proto udp from any to <SV EMAIL>port = imaps keep state 3pass in quick on em0 reply-to (em0 192.168.1.1) inet proto tcp from any to <SV EMAIL>port = smtp flags S/SA keep state 3pass in quick on em0 reply-to (em0 192.168.1.1) inet proto udp from any to <SV EMAIL>port = smtp keep state label 3pass in quick on em0 reply-to (em0 192.168.1.1) inet proto tcp from any to <SV EMAIL>port = submission flags S/SA keep state 3pass in quick on em0 reply-to (em0 192.168.1.1) inet proto udp from any to <SV EMAIL>port = submission keep state 3pass in quick on em0 reply-to (em0 192.168.1.1) inet proto tcp from any to <SV EMAIL>port = smtps flags S/SA keep state 3pass in quick on em0 reply-to (em0 192.168.1.1) inet proto udp from any to <SV EMAIL>port = smtps keep state 4pass in quick on em0 reply-to (em0 192.168.1.1) inet proto udp from any to any port = openvpn keep state Tabla 5.8: Definici´on de las reglas de acceso desde la interfaz WAN 5.10. Reglas de redirecci´on NAT Para que los usuarios externos puedan conectarse con el servidor de email que se encuentra en la DMZ hay que configurar las redirecciones de tr´afico hacia la DMZ. 86 CAP´ ITULO 5. DISE ˜ NO DE LA SOLUCI ´ ON Para ello se ha usado Port Forward, que permite el acceso a un dispositivo de red interna a trav´es de un puerto espec´ıfico. Las reglas de Port Forward para el acceso al servidor email en la DMZ son: 1. Regla que redirige el tr´afico procedente de la WAN a trav´es del puerto 143 al servidor de email. 2. Regla que redirige el tr´afico procedente de la WAN a trav´es del puerto 993 al servidor de email. 3. Regla que redirige el tr´afico procedente de la WAN a trav´es del puerto 25 al servidor de email. 4. Regla que redirige el tr´afico procedente de la WAN a trav´es del puerto 456 al servidor de email. 5. Regla que redirige el tr´afico procedente de la WAN a trav´es del puerto 587 al servidor de email. PortFoward 1rdr on em0 inet proto tcp from any to 192.168.1.3 port = imap -><SV EMAIL>round-robin 1rdr on em0 inet proto udp from any to 192.168.1.3 port = imap -><SV EMAIL>round-robin 2rdr on em0 inet proto tcp from any to 192.168.1.3 port = imaps -><SV EMAIL>round-robin 2rdr on em0 inet proto udp from any to 192.168.1.3 port = imaps -><SV EMAIL>round-robin 3rdr on em0 inet proto tcp from any to 192.168.1.3 port = smtp -><SV EMAIL>round-robin 3rdr on em0 inet proto udp from any to 192.168.1.3 port = smtp -><SV EMAIL>round-robin 4rdr on em0 inet proto tcp from any to 192.168.1.3 port = smtps -><SV EMAIL>round-robin 4rdr on em0 inet proto udp from any to 192.168.1.3 port = smtps -><SV EMAIL>round-robin 5rdr on em0 inet proto tcp from any to 192.168.1.3 port = submission -><SV EMAIL>round-robin 5rdr on em0 inet proto udp from any to 192.168.1.3 port = submission -><SV EMAIL>round-robin Tabla 5.9: Definici´on de las reglas de redirecci´on 5.11. Acceso a la red por parte de los usuarios: Asignaci´on de direcciones Para que un usuario se le permita el acceso a la red LAN pfSense debe asignarle una direcci´on IP. Los usuarios no invitados dispondr´an de una direcci´on IP fija. Los usuarios invitados tendr´an una direcci´on IP asignada por el servidor DHCP de pfSense. El rango de direccionamiento viene descrito en la Tabla 5.2 87 5.12. LIMITADORES DE ANCHO DE BANDA 5.11.1. Conexi´on remota: OpenVPN Para que los empleados puedan conectar en remoto a la red interna de la empresa se crean t´uneles VPN. Cada empleado tendr´a un t´unel VPN exclusivo que le permita conectarse desde su casa a un determinado equipo perteneciente a la red LAN. Figura 5.4: conexi´on VPN empleado con escritorio remoto Para la creaci´on de los t´uneles VPN se ha usado OpenVPN por los motivos dados en la secci´on 2.8.5. Para ello se deber´a: 1. Crear la infraestructura de certificados (PKI): La estructura de certificados para la VPN cuenta con una entidad certificadora, un certificado de servidor y certificados de usuario. 2. Configurar OpenVPN: En OpenVPN se configuran las caracter´ısticas del servidor VPN, junto con las reglas que concedan el paso a la conexi´on del cliente OpenVPN. 3. Configurar el acceso del cliente. En la Tabla 5.10 se muestran las caracter´ısticas de los tuneles VPN a crear por el servidor. OpenVPN Server Interfaz Protocolo/Puerto T´unel Crypto Descripcion WAN UDP4/1194 172.16.0.0/16 AES-128-CBC/SHA256 4096 bits T´unel Admin WAN UDP4/1198 172.17.7.0/24 AES-128-CBC/SHA256 4096 bits T´unel Comercial Tabla 5.10: Servidor VPN t´uneles 5.12. Limitadores de ancho de banda Para garantizar la calidad de servicio se han configurados l´ımites de descarga y de subida para los usuarios de la red interna. 5 Para los usuarios de la red LAN en la Figura 5.1 se 88 CAP´ ITULO 5. DISE ˜ NO DE LA SOLUCI ´ ON asigna un ancho de banda de 5 MBs de subida y de bajada mediante la herramienta Traffic Shaper, que esta ya integrada en pfSense. Grupo 1 IP address Subida M´aximo Bajada M´aximo 172.25.1.22 5 MB 5 MB 172.25.1.102 5 MB 5 MB Tabla 5.11: Ancho de banda para los nodos de la LAN en la red de la Figura5.1 Figura 5.5: Repartici´on del ancho de banda para usuarios de la red 5.1 5.13. Control de tr´afico web: Squid, SquidGuard El cliente quiere poder observar a qu´e sitios web se conectan sus empleados y, a su vez, restringir el acceso a determinadas p´aginas web. Para ello se ha decido usar como control de tr´afico Squid debido a que encaja a la perfecci´on los requisitos del cliente. Esta herramienta se usar´a tanto para el filtrado y control web de las peticiones de los clientes dentro de la red privada, como para el guardado en la cach´e y disco de nuestra UTM de actualizaciones de Windows y otros elementos a los que los clientes de la red vayan a acceder con frecuencia, para as´ı acelerar el acceso a los recursos en l´ınea y reducir el ancho de banda utilizado. Para conocer m´as sobre el funcionamiento de Squid y sus plugins vaya a la secci´on 2.7.5 Se ha decido guardar reservar un espacio en disco de 50 GB para guardar con la cach´e de Squid las actualizaciones de Windows. Se ha decidido configurar Squid en modo Transparente en modo peeksplice. Esta configuraci´on evita tener que realizar configuraciones en cliente y su vez permite tomar decisiones de acceso o no al servicio web en funci´on de su hostname. La configuraci´on de lista negra de accesos viene dada por la Tabla 5.12 89 5.13. CONTROL DE TR ´ AFICO WEB: SQUID, SQUIDGUARD Lista Negra Tipolog´ıa/Hostname Usuarios Apuestas 172.25.1.102 Agresivo 172.25.1.102 www.meneame.net 172.25.1.102 Tabla 5.12: servicios denegados por usuario 5.13.1. Control del tr´afico por capa de aplicaci´on: IDS Con el objeto de monitorizar el tr´afico a nivel de aplicaci´on y poder detectar posibles ataques se ha decidido instalar Snort frente a Suricata por los motivos dados en la comparativa de la secci´on 2.8.3 Se han tomado las siguientes decisiones con respecto a su configuraci´on: Snort Despliegue Acci´on Firmas/Patr´on Sensores WAN IDS Pasivo H´ıbrido Centralizado (pfSense) LAN IDS Pasivo H´ıbrido Centralizado (pfSense) Tabla 5.13: Modo de despliegue Snort en la red 5.13.2. Bloqueador de malware: pfBloquerNG Se ha decidido integrar pfBloquerNG para: Bloquear tr´afico proveniente de direcciones negras DNSBL[55] para bloquear p´aginas de malware. Se ha decidido filtrar por las 3 listas aportadas. Bloquear tr´afico por pais. Se ha decidido bloquear tr´afico proveniente de Singapur, el pa´ıs del que provienen m´as ciberataques del mundo en la actualidad.[56] Las conexiones a bloquear ser´an peticiones desde la interfaz LAN que coincidan con alg´un elemento de la lista negra y tr´afico proveniente de la WAN que cumpla el mismo criterio. Como DNS SinkHole se usa una direcci´on que no vaya a estar en uno por ning´un otro servicio. pfBlockerNG Rastreo DNS SinkHole DNSBL EASY DNSBL ADDS DNSBL Malicious Pa´ıs Entrantes:WAN y Hacia: LAN 172.20.10.1 SI SI SI Singapur Tabla 5.14: Dise˜no configuraci´on pfBloquerNG 90 CAP´ ITULO 6. IMPLANTACI ´ ON EN EL ENTORNO DE PRUEBAS Cap´ıtulo 6 Implantaci´on en el Entorno de Pruebas Es este cap´ıtulo se explican las configuraciones realizadas para la implantaci´on de un UTM pfSense que cubra todos los requisitos de cliente. Los detalles de la red y las directrices establecidas se encuentran en el cap´ıtulo de 5. Los detalles paso a paso de cada una de las configuraciones se encuentran el documento adjunto Manual de configuraci´on y uso. 6.1. Preparaci´on del entorno de pruebas El software a instalar en el equipo, pfSense 2.4.5, se descarga desde la p´agina oficial de pfSense[51]. Se instalar´a en el equipo de la Tabla 5.4. Las opciones a aplicar de descarga son: Arquitectura: AMD64 Instalador: Memstick installer Consola: VGA La instalaci´on de pfSense en el equipo se realiza desde una memoria USB donde se ha grabado la imagen. Se seleccionar´a particionamiento ZFS por los motivos dados en la secci´on 5.6 91 6.2. CONFIGURACI ´ ON DE LAS INTERFACES 6.2. Configuraci´on de las interfaces Para crear las interfaces del mostradas en la Figura 5.1 y la Tabla 5.2. Primero se ha de configurar el router frontera para que redirija el tr´afico a pfSense. Para ello: En el router frontera se asociar´a la MAC del equipo que contiene el pfSense instalado como direcci´on la direcci´on IP est´atica 193.168.1.3. Este equipo se asigna como DMZ en el router para que todo el tr´afico que inicie conexi´on desde la red externa sea redirigido al pfSense. En el firewall se configuran las 3 interfaces de red activas mencionadas en la Tabla 5.2 . Cada una corresponde a una subred: WAN: Conecta al puerto em0 del firewall cuya direcci´on es 192.168.1.3. Est´a conectado al router que da acceso a internet. No se configura DHCP para esta interfaz. No debe crear conexiones desde esta interfaz. LAN: usa el puerto em1 del firewall cuya direcci´on es 172.25.1.1. Los usuarios de la red interna se conectan desde esta interfaz. El firewall est´a configurado para que act´ue como servidor DHCP de esta subred. DMZ: usa el puerto r10 del firewall con la direcci´on de red 10.10.10.1. Hay un equipo que simular´a el servidor de correo de la red original. No se configura servidor DHCP para esta interfaz. La direcci´on IP de equipo se configura como est´atica. La interfaz WAN y LAN se deber´an configurar mediante consola por acceso f´ısico a pfSense. Figura 6.1: Configuraci´on de interfaces mediante consola 92 CAP´ ITULO 6. IMPLANTACI ´ ON EN EL ENTORNO DE PRUEBAS Mediante la opci´on 1 de la Figura 6.1 se asigna la correspondencia entre interfaz y mediante la opci´on 2 los rangos en caso de haber servidor DHCP y direccionamientos. La configuraci´on espec´ıfica viene dada por la Tabla 6.1 Configuraci´on Option 1 Option 2 Option 2 Option 2 Option 2 Interfaz Asignaci´on f´ısica DHCP IPv4 M´ascara Gateway WAN em0 no 192.168.1.3 255.255.255.0 192.168.1.1 LAN em1 start range:172.25.1.2 end range: 172.25.1.100 172.25.1.1/16 255.255.0.0 – DMZ rl0 no 10.10.10.1/24 255.255.255.0 Tabla 6.1: configuraci´on interfaces 6.2.1. Acceso seguro al configurador web de pfSense El actor administrador accede al configurador web de pfSense a trav´es de la direcci´on 172.25.1.1 mediante el protocolo http. Por defecto las credenciales de pfSense son usuario: admin, password: pfsense. Tal y como se ha comentado en la secci´on 5.7.1, para que el usuario administrador pueda acceder al configurador web de forma segura se ha de: 1. Configurar los par´ametros de pfSense tal como hostname, DNS server, nueva contrase˜na... 2. A˜nadir una contrase˜na segura que dificulte los ataques por fuerza bruta o diccionario. Se seguir´an los est´andares indicados en la secci´on 5.7.1 3. Habilitar el acceso mediante el protocolo https. Para la primera conexi´on a trav´es del configurador web se mostrar´a un wizard de configuraci´on donde se configurar´a la informaci´on general del equipo. Las configuraciones aplicadas son las de la Tabla 6.2 Wizard Domain miempresa.es Hostname firewall Primary DNS Server 172.25.1.1 Secondary DNS Server 8.8.8.8 NTP Server hora.roa.es Password Exma9pel?0Fpsas* Tabla 6.2: configuraci´on aplicada en wizard 93 6.2. CONFIGURACI ´ ON DE LAS INTERFACES Figura 6.2: wizard configuraci´on Habilitar el acceso mediante el protocolo HTTPS Para habilitar HTTPS como protocolo de acceso al configurador web: 1. Se crea la autoridad certificadora ra´ız. Sus caracter´ısticas vienen dados por la Figura 6.3. 2. Se crea el autoridad certificadora intermedio. Sus caracter´ısticas vienen dados por la Figura 6.4. 3. Se crea el certificado de servidor. Sus caracter´ısticas vienen dados por la Figura 6.5. 4. Se habilita HTTPS en pfSense 5. Se instalan las entidades certificadoras en el PC del administrador Desde System>Certificate Manager se crean los certificados. 94 CAP´ ITULO 6. IMPLANTACI ´ ON EN EL ENTORNO DE PRUEBAS Figura 6.3: Configuraci´on CA ra´ız para HTTPS 95 6.6. ASIGNACI ´ ON DE DIRECCIONES A USUARIOS Y WOL Figura 6.12: Reglas de firewall para poder realizar port forward 6.6. Asignaci´on de direcciones a usuarios y WoL Para que a un usuario invitado se le permita el acceso a la red LAN pfSense debe asignarle una direcci´on IP. Para ello se ha activado el servidor DHCP en LAN que asignar´a direcciones din´amicamente a los usuarios que le pidan conexi´on. El rango de direccionamiento din´amico viene dado en la Tabla 6.1 Los equipos con direcci´on est´atica reciben la misma direcci´on que les sera asignada por el equipo firewall anterior. Para estos usuarios hay que configurar previamente su direcci´on haciendo un mapeo en la interfaz LAN desde Services>DHCP Server>LAN>DHCP Static Mapping MAC Address: d8:cb:8a:84:eefc IP Address: 172.25.1.22 Hostname: patri Description: mapeo est´atico para patri-pc Para configurar el WoL simplemente hay que hacer click a la opci´on desde la tabla de DHCP Leases. 6.6.1. Conexi´on remota: OpenVPN Para que los empleados puedan conectar en remoto a la red interna de la empresa se han creado t´uneles VPN. Cada empleado tendr´a un t´unel VPN exclusivo que le permita conectarse desde su casa a un determinado equipo perteneciente a la red LAN. Para la creaci´on de los t´uneles VPN se ha usado OpenVPN por los motivos dados en la secci´on 2.8.5. Para ello se han seguido los siguientes pasos: 1. Crear la infraestructura de certificados (PKI): La estructura de certificados para la VPN cuenta con una entidad certificadora, un certificado de servidor y certificados de usuario. La creaci´on y el uso de estos certificados est´a explicado en la secci´on 6.2.1. 102 CAP´ ITULO 6. IMPLANTACI ´ ON EN EL ENTORNO DE PRUEBAS 2. Configurar OpenVPN: En OpenVPN se configuran las caracter´ısticas del servidor VPN, junto con las reglas que concedan el paso a la conexi´on del cliente OpenVPN. Esta configuraci´on se realiza mediante un wizard que ayuda a no saltarse ning´un paso a la hora de realizar la configuraci´on. Una vez elegidas todas las propiedades del t´unel de conexi´on se crear´a autom´aticamente una regla de firewall en la interfaz WAN que permita la entrada de conexiones al servidor VPN y otra regla de OpenVPN que permita al tr´afico de un nodo OpenVPN remoto conectarse a los recursos de la red interna. 3. Configurar el acceso del cliente: Se crea una entidad cliente cuyas propiedades de Configuraci´on de autenticaci´on de usuario,Configuraci´on de t´unel yConfiguraci´on criptogr´afica coinciden con las del servidor. Es decir con las de la Figura 6.13. 4. Autenticar al usuario: Para autenticar al usuario este debe disponer de un certificado de usuario firmado por la entidad autenticadora de de VPNs creada anteriormente. Para ello se crea un usuario por cliente que vaya a usar la VPN. Las certificados de usuario se crean desde el propio usuario. Una vez creado el certificado, se exporta con OpenVPN Client Export. El usuario debe instalar el archivo descargado en el cliente de OpenVPN de su casa para poder conectarse a la direcci´on IP se˜nalada en el certificado de servidor. En la Figura 6.13 se observan las caracter´ısticas elegidas para OpenVPN junto con una peque˜na explicaci´on. Figura 6.13: configuraci´on de OpenVPN. 103 6.7. LIMITADORES DE ANCHO DE BANDA En la Figura 6.14 se observa la asignaci´on del certificado para un usuario administrador. Figura 6.14: asignaci´on de certificado a usuario. 6.7. Limitadores de ancho de banda Para el grupo de usuarios Grupo 1 se ha definido un ancho de banda a repartir de 5 MB y 5 MB de bajada. Grupo 1 IP address Subida M´aximo Bajada M´aximo 172.25.1.22 5 MB 5 MB 172.25.1.102 5 MB 5 MB Tabla 6.3: Ancho de banda para los nodos de la LAN en la red de la Figura 5.1 Para ello: 1. Se ha definido el l´ımite de subida y el de bajada con la herramienta Traffic Shaper. Con las siguientes caracter´ısticas: Enable: marcada la opci´on para habilitar el limitador. Name: Bajada o Subida, en funci´on del limitador 104 CAP´ ITULO 6. IMPLANTACI ´ ON EN EL ENTORNO DE PRUEBAS Mask: Destination address Bandwidth: 5 Mbps 2. Se ha definido un alias con el grupo de direcciones IP de usuario al que se va a asignar la restricci´on de ancho de banda. 3. Se ha creado una regla de firewall que asigna los limites de ancho de banda al grupo de usuarios.Se puede observar en la Figura 6.15. Las caracter´ısticas de la regla son: Action:Pass. Interface: LAN. Source: Single host o valor del alias creado, en nuestro caso Grupo 1. Destination: any. Destination Port Range: WEB PORTS (alias para los puertos 80 y 443). In /Out pipe: Para In (tr´afico que entra a pfSense por el puerto de la interfaz LAN): Subida y para Out (tr´afico que sale de pfSense por el puerto de la interfaz LAN): Bajada. Figura 6.15: Alias para las direcciones del limiter 6.8. Control de tr´afico web: Squid, SquidGuard 6.8.1. Configuraci´on de Squid cache Services>Squid Proxy Server>Cach´e Para guardar cach´e se realiza la siguiente configuraci´on: Hard Disk Cach´e size: 5000. Es lo recomendado por los expertos en pfSense. Para guardar en disco las actualizaciones de Windows. 105 6.8. CONTROL DE TR ´ AFICO WEB: SQUID, SQUIDGUARD aufs. Para evitar bloquear las operaciones I/O de otros procesos de Squid. Maximum object Size: 512. (MB). Se ha tomado en consideraci´on que se quieren cachear en disco las actualizaciones de Windows. Se puede elevar en caso de observar paquetes de actualizaci´on mayores que el tama˜no seleccionado. Memory Cach´e Size: 2000. Se recomienda usar siempre menos del 50 % de la RAM f´ısica. Se tiene que tener en cuenta que Squid usa 14 MBytes de RAM por GB de cach´e. Se marca la opci´on de Cach´e dynamic content para guardar contenido din´amico de las p´aginas web cuando sea posible. Custom refresh patterns: se a˜nade el patr´on para guardar en cach´e las actualizaciones de Windows. Ver Figura 6.16 Habilitar Transparent HTTP Proxy y dejar el resto de opciones con los datos por defecto. Habilitar Bypass Proxy for Private Address Destination para no interferir con las conexiones VPN. Figura 6.16: Patr´on para cachear actualizaciones de Windows 6.8.2. Configuraci´on del modo transparente en Squid La configuraci´on general de Squid ser´a: Habilitar Squid habilitando: enable squid proxy. Se mantiene habilitado: keep setting para mantener entre versiones la configuraci´on y todos los datos referentes a Squid. En proxy interface se selecciona: LAN y loopback. Son las interfaces de las que el tr´afico ser´a interferido por Squid. Loopback es necesario seleccionarlo para usar LightSquid. Se habilita Allow Users on Interface Para permitir usar el proxy a todos los usuarios de la interfaz seleccionada. 106 CAP´ ITULO 6. IMPLANTACI ´ ON EN EL ENTORNO DE PRUEBAS Se habilita Resolve DNS IPv4 First. Para agilizar consultas, es posible que el proveedor no trabaje con IPv6 a´un. Figura 6.17: Configuraci´on General de Squid 1 En la secci´on del modo de intercepci´on se selecciona: Habilitar HTTPS/SSL Interception. Marcar el modo de intrusi´on SSL/MITM Mode como Splice all. A˜nadir como Certificado de autoridad CA una nueva entidad certificadora creada desde pfSense para Squid. Figura 6.18: Configuraci´on General de Squid 2 Por ´ultimo se a˜nade una regla de firewall que obligue a los usuarios de la LAN a usar el servidor DNS de pfSense para as´ı tener que pasar por el proxy Squid. 107 6.8. CONTROL DE TR ´ AFICO WEB: SQUID, SQUIDGUARD Figura 6.19: Regla para forzar el paso por DNS de pfSense 6.8.3. Configuraci´on de SquidGuard Se configura SquidGuard para permitir o denegar el acceso a p´aginas web en funci´on del cliente que realiza la petici´on y la URL de ´esta, bien sea el dominio, la URL completa o palabras contenidas en dicha URL. Para realizar su configuraci´on realizaremos los siguientes pasos: 1. A˜nadir una lista negra a SquidGuard: Services>Squid Proxy Server>General settings, en apartado Blacklist options.Se habilita el uso de listas negras. La lista a instalar y usar es shallalist. 2. Se configura el grupo de usuarios al que se deshabilitara. ´ Unicamente contiene al usuario de la direcci´on IP 172.25.1.102. 3. Se configura el grupo de ACLs al que se deshabilitara los servicios de categor´ıas de apuestas, agresivo y la p´agina web meneame.net. Ver imagen 6.20. En el caso de la p´agina web se a˜nade una nueva categor´ıa al grupo que se ha descargado de la shallalist. Se crea desde pfSense. Figura 6.20: Grupo restringido 6.8.4. Configuraci´on de LightSquid Para crear reportes del historial de accesos web a partir de los logs de Squid configuramos LightSquid. Se configura desde Status>Squid Proxy Reports. Opciones seleccionadas de configuraci´on: 108 CAP´ ITULO 6. IMPLANTACI ´ ON EN EL ENTORNO DE PRUEBAS Lightsquid Web Port: 7445. Puerto a trav´es del cual se accede a la interfaz web de LightSquid para ver los reportes. LightSquid Web SLL: chequeado. Para ver el reporte a trav´es de https. User y Password: Los mismos que para pfsense. Credenciales de acceso a los reportes generados por LightSquid. Report Template Settings: opciones de configuraci´on de la vista. IP Resolve Method: DNS. LSkip URL(s): Aqu´ı se introducen los dominios y direcciones IP que no queremos que se muestren el reporte. Deber´an separarse mediante —. Refresh Scheduler: 2 horas. Periodo de tiempo que tardar´a en actualizar los reportes de forma autom´atica. Ponemos un valor alto para evitar el consumo de CPU, dado que se puede refrescar manualmente. 6.9. Control del tr´afico por capa de aplicaci´on: IDS Como IDS pasivo se usa Snort. Como reglas para generar alertas se usar´an las reglas de la comunidad de Snort. Para ello hay que registrarte en Snort y conseguir un Oinkcode. Tambi´en se hace uso de OpenAppID para detectar la aplicaci´on a la que pertenece el tr´afico rastreado. La configuraci´on general de Snort ser´a la siguiente: Enable Snort VRT: Se chequea para activar las reglas de Snort VRT o Vulnerability Research Team Snort Oinkmaster Code: Se pega el Oinkcode para poder realizar la descarga de las reglas. Enable Snort GPLv2: Se chequea para activar las reglas de la comunidad de Snort Enable ET Open: Se chequea para activar las reglas de Snort de Amenazas emergentes. Enable OpenAppID: Se chequea para descargar los detectores de OpenAppID. Enable RULES OpenAppID: Se chequea para descargar las reglas de OpenAppID. Update Interval: 1 DAY Hide Deprecated Rules Categories: chequeado para eliminar reglas obsoletas. Se activa Snort en la WAN y en la LAN con la pol´ıtica menos restrictiva: Uso de pol´ıtica IPS, Modo conectividad y alerta. 109 6.10. BLOQUEADOR DE MALWARE: PFBLOCKERNG Figura 6.21: WAN configuraci´on Snort 6.10. Bloqueador de malware: pfBlockerNG La configuraci´on del ´area pfBlockerNG para el bloqueo en funci´on de listas DNS e IPs es el siguiente: Inbound en WAN yOutbound en LAN. SinkHole en 172.20.10.1. Descarga de las listas: DNSBL EasyList, DNSBL ADs, DNSBL Malicious y pfB PRI1 v4 Bajo Firewall>pfBlockerNG>General se cambia la configuraci´on de CRON para que actualice las listas una vez al d´ıa, a las 00 horas, para minizar impacto. Bajo Firewall>pfBlockerNG>IP Enable kill states: para matar estados de los que se han encontrado conexiones para IPs a˜nadidas a las listas de bloqueo. Para pfB PRI1 v4 se cambia las actualizaciones a 1 vez al d´ıa y se configura para que deniegue el tr´afico a esas IPs tanto de entrada como de salida. Para realizar el bloqueo por pa´ıs hay que configurar Firewall>pfBlockerNG>GeoIP: Se introduce la licencia MaxMind GeoIP configuration: 110 CAP´ ITULO 6. IMPLANTACI ´ ON EN EL ENTORNO DE PRUEBAS Figura 6.22: Licencia GeoIP Para configurar el bloqueo por pa´ıses se crea una regla usa Deny Inbound, para el listado de Direcciones IP en la lista del pa´ıs seleccionado. Deny Inbound es la mejor opci´on ya que los servicios en la DMZ est´an expuestos, pero un usuario podr´ıa querer acceder a alg´un servicio dentro del rango de IPs del pa´ıs al que se ha decidido bloquear el tr´afico entrante. Figura 6.23: Selecci´on de pa´ıses a bloquear con GeoIP 111 7.3. EVALUACI ´ ON COMPARATIVA TEST 18 Descripci´on El usuario monitoriza el tr´afico mediante los logs de Snort Resultado esperado El usuario observa en la lista de logs las apps que generan tr´afico Resultado obtenido El usuario observa en la lista de logs las apps que generan tr´afico Validaci´on OK Tabla 7.18: TEST 18 TEST 19 Descripci´on El usuario externo envia un email a un empleado de la empresa Resultado esperado El empleado recibe el email al buz´on de su correo de empresa Resultado obtenido El empleado recibe el email al buz´on de su correo de empresa Validaci´on OK Tabla 7.19: TEST 19 TEST 20 Descripci´on Hard shutdown del equipo Resultado esperado El equipo se reinicia sin errores Resultado obtenido El equipo se reinicia sin errores Validaci´on OK Tabla 7.20: TEST 20 7.3. Evaluaci´on comparativa Se realiza un escaneo de vulnerabilidades desde la red interna contra pfSense para conocer si se debe cubrir alguna vulnerabilidad del sistema y la mejora frente al antiguo sistema instalado en la red empresarial. La herramienta utilizada para realizar este escaneo es OpenVAS. A partir de una configuraci´on dada devolver´a como resultado un informe con las vulnerabilidades, c´omo se detectaron, su severidad, etc. Vulnerabilidad Severidad QoD Localizaci´on TCP timestamps 2.6 70 % general/tcp Tabla 7.21: Lista de vulnerabilidades encontradas pfSense La ´unica vulnerabilidad encontrada ha sido la de la tabla 7.21. Esta vulnerabilidad permitir´ıa, potencialmente, a un atacante conocer el tiempo de funcionamiento o uptime del equipo. Se ha decidido no mitigar esta debilidad por los siguientes motivos: 118 CAP´ ITULO 7. INTEGRACI ´ ON, PRUEBAS Y EVALUACI ´ ON TCP timestamps es necesario para el sistema: Desactivar TCP timestamps reducir´a el tama˜no de las ventanas TCP, afectando al rendimiento del equipo del equipo, especialmente para las conexiones VPN. [57] La vulnerabilidad tiene un riesgo muy bajo. Adem´as de esto se ha realizado un escaneo de puertos desde la red externa, en el que se ha comprobado que ´unicamente los puertos que se deseaban estaban abiertos hacia el exterior. Si se comparan las vulnerabilidades del sistema pfSense integrado frente a las mencionadas del antiguo sistema que se dispon´ıa en la red empresarial (ver secci´on 4.6.4), se puede observar que se ha producido una mejora significativa en cuanto a la seguridad de la red. 119 7.3. EVALUACI ´ ON COMPARATIVA 120 CAP´ ITULO 8. CONCLUSIONES Y TRABAJO FUTURO Cap´ıtulo 8 Conclusiones y Trabajo Futuro En este proyecto se ha mejorado la infraestructura de red de una peque˜na empresa, ajust´andola a los requerimientos de seguridad actuales. A su vez se ha aportado la funcionalidad necesaria para que los empleados desempe˜nen su trabajo adecuadamente. Para realizar esta mejora se ha desarrollado un an´alisis de la red empresarial con el objeto de encontrar las debilidades y puntos de mejora. En este an´alisis se lleg´o a la conclusi´on de que se deb´ıa sustituir el equipo firewall de la red por otro que mitigase las vulnerabilidades de red encontradas y que a su vez cubriese las nuevas necesidades funcionales de la empresa que han ido surgiendo a lo largo de los a˜nos. Con la realizaci´on de este proyecto se ha implantado una soluci´on que ha mitigado una serie de riesgos desencadenados por la mala configuraci´on y antig¨uedad del equipo de la red sustituido: Vulneraci´on de la confidencialidad: •Problema: El equipo firewall UTM daba servicios de monitorizaci´on de la red interna a usuarios de la red externa sin necesidad de verificaci´on de usuario empleado de la empresa. •Soluci´on: Con la configuraci´on que se ha realizado en este proyecto s´olo los usuarios que se autentifiquen como administrador del sistema tienen autorizaci´on para acceder a estos servicios. La comunicaci´on de estos servicios siempre se realiza mediante canales de comunicaci´on seguros. Cuellos de botella: •Problema: El equipo sustituido ocasionaba cuellos de botella en la red no solo por su localizaci´on sino tambi´en debido a que las tarjetas de red no soportan m´as de 100 MBps, impidiendo aprovechar todo el ancho de banda proporcionado por el ISP. 121 •Soluci´on: El equipo instalado consta de tarjetas de red que soportan hasta 1000 MBps, permitiendo aprovechar el ancho de banda contratado y mejorando las conexiones de red. Vulnerabilidades por software obsoleto: •Problema: Se detectaron m´ultiples vulnerabilidades como consecuencia del uso de software descontinuado. •Soluci´on: El equipo instalado est´a en constante desarrollo y permite la f´acil actualizaci´on del sistema y sus ´areas de gesti´on. Adem´as de estudiar las vulnerabilidades del antiguo sistema se han realizado los mismo test para el nuevo sistema implantando dando resultados positivos. Tal y como se menciona en la secci´on 7.3, al contrario que con el antiguo sistema, no se han encontrado vulnerabilidades para la configuraci´on realizada en pfSense que se deban mitigar. Como ya se ha mencionado previamente tambi´en se han cubierto necesidades del cliente, siempre orientadas a la mejora en la seguridad como son: la configuraci´on de OpenVPN para la conexi´on mediante t´uneles VPN de usuarios en la red externa que desean acceder a alg´un servicio en la LAN, adem´as de otras herramientas como son pfBlockerNG o Squid que permiten monitorizar y gestionar el tr´afico de la red de forma controlada. En conclusi´on, el sistema implantado en este proyecto es robusto, y cubre las necesidades requeridas por el cliente, sin embargo, hay pie a mejoras: Como mejoras de cara al futuro se propone cambiar la estructura de la red a una que duplique los elementos troncales de la misma para crear redundancia y eliminar as´ı los puntos ´unicos de falla. Una soluci´on ser´ıa crear una arquitectura maestro-esclavo en la que participen 2 equipos pfSense. En caso de quedar fuera de servicio uno de ellos, tomar´ıa el control de la red el otro. 122 AP´ ENDICE A. ADJUNTOS Ap´endice A Adjuntos Los elementos que se han adjuntado junto con este documento son: Manual administrador.pdf: Manual del admistrador. configuracion firewall.xml: Configuraci´on de pfSense. CVE infodesain Report.pdf: Reporte de vulnerabilidades infodesain CVE. infodesain rapido.pdf: Reporte de vulnerabilidades infodesain Openvas Default. pfsense-report.pdf: Reporte de vulnerabilidades de pfSense. 123 124 BIBLIOGRAF´ IA Bibliograf´ıa [1] Anton Cabian Mu˜ noz,se registraron m´as de 120.000 incidentes, seg´un los datos recogidos por el Instituto Nacional de Ciberseguridad (INCIBE), siendo siete de cada diez ciberataques registrados en Espa˜na son contra PYMES, [En linea]. Disponible en: https://fundacioninade.org/sites/inade.org/files/tribuna_ rh_acm_01-12-2018.pdf. [Accedido: 10-mayo-2020] [2] IMT technology version 2.3 http://mirror1.infodesain.com/en/imt.php [Accedido: 10-mayo-2020] [3] Empresa IMTCloud https://www.imtcloud.com [Accedido: 10-mayo-2020] [4] Dec´alogo ciberseguridad empresas. Una gu´ıa de aproximacion para el empresario. https://www.incibe.es/sites/default/files/contenidos/guias/ doc/guia_decalogo_ciberseguridad_metad.pdf [Accedido: 12-marzo-2020] [5] Plan Director de Seguridad. INCIBE. https://www.incibe.es/sites/default/ files/contenidos/dosieres/metad_plan-director-seguridad.pdf [Accedido: 12-marzo-2020] [6] Frameworks for IT management https://www.academia.edu/3905111/ISO_ 27001_Information_Security_Management_Systems [Accedido: 12-marzo2020] [7] C´odigo de Derecho de la Ciberseguridad. BOE. https://www.boe.es/biblioteca_ juridica/codigos/codigo.php?id=173 [Accedido: 12-marzo-2021] [8] Cumplimiento Legal - Colecci´on Protege tu emplesa. INCIBE https: //www.incibe.es/sites/default/files/contenidos/dosieres/metad_ cumplimientolegal.pdf [Accedido: 12-marzo-2020] [9] Ley 8/2011, de 28 de abril, por la que se establecen medidas para la protecci´on de las infraestructuras cr´ıticas https://www.boe.es/eli/es/l/2011/04/28/8/con [Accedido: 12-marzo-2020] [10] Real Decreto 704/2011, de 20 de mayo, por el que se aprueba el Reglamento de protecci´on de las infraestructuras cr´ıticas https://www.boe.es/eli/es/rd/2011/05/ 20/704/con [Accedido: 12-marzo-2020] 125 BIBLIOGRAF´ IA [11] Dec´alogo ciberseguridad empresas. Amenaza vs vulnerabilidad. https://www.incibe.es/protege-tu-empresa/blog/ amenaza-vs-vulnerabilidad-sabes-se-diferencian [Accedido: 20-enero2020] [12] Seguridad y Alta Disponibilidad. 1aEdicion. Alfredo Abad Domingo [Accedido: 20enero-2020] [13] Gu´ıa de ciberataques https://www.osi.es/sites/default/files/docs/ guia-ciberataques/osi-guia-ciberataques.pdf [Accedido: 20-enero-2020] [14] Ciberamenazas contra entornos empresariales. INCIBE. https://www.incibe.es/ sites/default/files/contenidos/guias/doc/ciberamenazas_contra_ entornos_empresariales.pdf [Accedido: 11-febrero-2020] [15] Understanding Intrusion Detection https://iratoon.medium.com/ intrusion-detection-part-2-f20052c0b3f0 [Accedido: 20-abril-2020] [16] Squid, SquidGuard and Lightsquid on pfSense https://www.slideshare.net/ NetgateUSA/squid-squidguard-and-lightsquid-on-pfsense-23-24-pfsense-hangout-january-2017 [Accedido: 15-febrero-2020] [17] Unified Process http://www.bawiki.com/wiki/Unified-Process.html [Accedido: 17-febrero-2020] [18] Eclipse Process Composer, OpenUP. https://www.eclipse.org/epf/general/ OpenUP.pdf [Accedido: 17-febrero-2020] [19] Estudio de remuneraci´on en el sector tecnol´ogico https://www.michaelpage. es/sites/michaelpage.es/files/estudio_remuneracion_tecnologia_ 2021.pdf [Accedido: 17-febrero-2020] [20] Priscilla Oppenheime,Top-Down Networking Design Third Edition. Characterizing Large Internetwork [pag. 60] [21] Backbone in Networking https://networkencyclopedia.com/ backbone-in-networking/ [Accedido: 3-marzo-2020] [22] Gary A. Donahue,Network Warrior, O’Reilly. Collapsed core [pag. 474] [23] GS748Tv5 https://www.downloads.netgear.com/files/GDC/datasheet/ en/GS716Tv3-GS724Tv4-GS748Tv5.pdf [Accedido: 3-marzo-2020] [24] GS748T https://www.downloads.netgear.com/files/GS748T_UM_ 30Oct07.pdf [Accedido: 10-may-2020] [25] TL-SG105-108 https://static.tp-link.com/res/down/doc/ TL-SG105-108.pdf [Accedido: 3-marzo-2020] [26] 77 http://www.yuanley.com/index.php?route=product/product&path= 306&product_id=110 [Accedido: 20-abril-2020] 126 BIBLIOGRAF´ IA [27] YuanLey switch PoE http://www.yuanley.com/support/YuanLey%20PoE% 20Switch%20User%20Manual.pdf [Accedido: 20-abril-2020] [28] TPLINK tlsf1005p https://www.useip.co.uk/datasheets/6877/tplink_ tlsf1005p_5_port_desktop_switch_with_4port_poe.pdf [Accedido: 20abril-2020] [29] Router orange https://ayuda.orange.es/particulares/adsl-y-fibra/ configuracion-e-instalacion/2148-todo-lo-que-debes-saber-sobre-tu-router-livebox-fibra [Accedido: 22-abril-2020] [30] HP ProLiant DL140 https://h20195.www2.hpe.com/v2/getdocument.aspx? docname=c04282505 [Accedido: 22-abril-2020] [31] RTL8139 https://en.wikipedia.org/wiki/RTL8139 [Accedido: 22-abril-2020] [32] IMT manual de usuario, infodesain https://documentos.tech/document/ manual-imt-v21.html [Accedido: 25-abril-2020] [33] infodesain web http://mirror1.infodesain.com/es/imt.php [Accedido: 10mayo-2020] [34] CVE Linux https://www.cvedetails.com/vulnerability-list/ vendor_id-33/product_id-47/version_id-37054/opec-1/ Linux-Linux-Kernel-2.6.18.html [Accedido: 10-may-2020] [35] CVE https://cve.mitre.org/about/index.html [Accedido: 10-mayo-2020] [36] CVSS m´etricas https://www.first.org/cvss/v2/guide [Accedido: 13-mayo2020] [37] OpenVas terminolog´ıa https://securityorb.com/general-security/ openvas-term-to-know/ [Accedido: 13-mayo-2020] [38] Comparativa de firewalls https://en.wikipedia.org/wiki/Comparison_of_ firewalls [Accedido: 13-mayo-2020] [39] Top 10 firewalls https://cybersecuritynews.com/ best-open-source-firewall/ [Accedido: 16-junio-2020] [40] Comparativa t´ecnica de pfSense contra OPNsense https://www. firewallhardware.it/en/ipfire[Accedido: 20-may-2020] [41] Zeroshell https://en.wikipedia.org/wiki/Zeroshell [Accedido: 21-may2020] [42] Comparativa t´ecnica de pfSense contra OPNsense https://www. firewallhardware.it/en/pfsense-vs-opnsense-technical-comparison/ [Accedido: 21-may-2020] [43] CVE-FReeBSD Vulnerabilidades https://www.cvedetails.com/vendor/6/ Freebsd.html [Accedido: 1-junio-2020] 127