Hola mi estimado estudiante, esta es una muestra de una mitigación de seguridad para servidores Linux, la misma pretende mostrarte como seria en el caso de que puedas tener la oportunidad de trabajar en una gran corporación, la cuál tiene tanto departamente de seguridad infotmación y departamento de servidores Linux por separado. Recuerda esto es solo una muestra, sin embargo puede aplicar también al mundo real. CONTENIDO RESUMEN EJECUTIVO............................................................................................ II.INTRODUCCION­ III.ENFOQUE DE LA EVALUACION DE SEGURIDAD EN TECNOLOGIAS DE­ INFORMACION­ IV.CARACTERIZACION...................................................................................... ASPECTOS DETECTADOS........................................................................... VI.CONCLUSION RESUMEN EJECUTIVO Se inicia la evaluación de seguridad sobre los servidores con sistema operativo Linux Ubuntu, los cuales funcionaran como servidores de aplicación y servicio Web para el Sistema de Curso de Udemy que tiene como principal función el permitir que los estudiantes del Curso UBUNTU SERVER BASICO dictado por el Instructor Beny Blanco entiendan como realizar una mitigación de seguridad en servidores con el sistema operativo Ubuntu. Los servidores prestaron servicio en la Intranet. Los principales hallazgos y recomendaciones referentes a esta plataforma serán explicados con mayor detalle a lo largo de este curso. A continuación se mencionan las vulnerabilidades que pueden ser detectadas: Debilidades en la gestión de cuentas de usuario Debilidades en la permisología de archivos sensibles.­ Posibles puertos innecesarios El servidor es vulnerable a ataques de forma remota a través de puertos con servicios activos no necesarios. Debilidad en la administración de usuarios y grupos Debilidades en la configuración del archivo sshd_config Debilidad en acceso remoto de root a dispositivos TTY en securetty­ Debilidad en configuración de hosts.deny y hosts.allow­ El servidor web es vulnerable a un ataque de denegación de servicios­ (vía TFTP)­ Paquetes instalados en los servidores evaluados.­ Debilidad en configuración de scripts de arranque que se encuentran en /etc/init.d El protocolo UUCP alternativo a TCP/IP se encuentra habilitado­ Ausencia de información documental sobre los procedimientos de continuidad operacional del servidor web­ Debilidad en la versión instalada de PHP.­ Debilidad en el lí­mite de conexiones establecido para cada Base de Datos Es posible Clonar la Base de Datos La Base de Datos Permite Conexiones Remotas­ Debilidad en los parámetros de configuración de la Base de Datos­ Debilidad en configuración de apache server INTRODUCCIÓN Emitir un diagnostico de seguridad que permita detectar y evaluar posibles brechas de seguridad asociadas a los servidores desde el punto de vista del sistema operativo que puedan afectar su buen funcionamiento. Evaluar los servidores,a fin de detectar y mitigar posibles vulnerabilidades asociadas a los mismos. Generar las recomendaciones asociadas para minimizar las­ vulnerabilidades de la Plataforma Tecnologicas.­ Proteger los activos de información disponibles en la plataforma tecnolgica de la corporación donde estemos trabajando.­ 2.2 Alcance Se realiza una evaluación de seguridad al sistema operativo de los servidores Ubuntu,la cual se enfoca especi­ficamente a los siguientes aspectos:­ Cuentas de usuarios.­ Políticas de seguridad.­ Parches y actualizaciones de seguridad.­ Puertos y Servicios innecesarios.­ Permisología de archivos sensibles.­ 2.3 Esquema de Proceso: 2.4­ Limitaciones:­ 3.2 Técnicas de recopilación de información:­ Para realizar el levantamiento de información es necesario para la evaluación de seguridad, fueron utilizadas como técnicas de recopilación:­ Listas de chequeo.­ Herramientas de detección de vulnerabilidades.­ Implementación de scripts de evaluación.­ IV. CARACTERIZACIÓN La plataforma tecnologica evaluada esta conformada por: NOMBRE‭ ‬FUNCIÓN‭ ‬DIRECCIÓN IP‭ ‬SISTEMA OPERATIVO‭ LINUX34‭ Aplicación 129.90.60.34‭ Red Hat‭ ‬4‭ LINUX50‭ Web/BD‭ 129.90.60.50‭ Red Hat‭ ‬4‭ V. ASPECTOS DETECTADOS 1. Debilidades en la gestión de cuentas de usuario Hallazgo Se evidenció la existencia de cuentas de usuario creadas por defecto. Descripción Cuentas de Servidor Usuario halt operator gopher dbus netdump pcap operator smmsp lwuser dbus xfs gopher pcap ident nscd Wnn netdump Gdm amanda smmsp Seglog nscd Dovecot Así mismo se evidenció en el servidor se encuentran dos cuenta para la administración de SIMIP (simip y SIMIP) Es necesario acotar que no se visualizan en ninguno de los servidores cuentas personalizadas para los administradores de la plataforma. Riesgo Es posible que un intruso pueda acceder a un servidor con privilegios de administrador y ejecutar programas en el mismo de manera no autorizada. Además, hay servicios innecesarios o inseguros que tienen relacionados usuarios para su funcionalidad, los cuales son conocidos públicamente. Recomendación Se recomienda eliminar todas aquellas cuentas que se consideren innecesarias, así como analizar sus permisos para cada una de ellas, a fin de que tenga los privilegios correspondientes a sus actividades. De igual forma se recomienda que todos los administradores ingresen a los equipos con su cuenta de usuario particular y en caso que sea estrictamente necesario realizar actividades con privilegios root, utilizar el comando ‘su’, lo cual deberá quedar registrado en los logs de auditoría. 2. Debilidades en los permisos de archivos sensibles. Hallazgo Se evidenció la existencia de archivos y directorios cuya permisología les podría permitir a personas malintencionadas obtener información valiosa para el sistema e intentar ataques contra este. Dichos archivos se presentan a continuación: Ver Anexo 1 SERVIDOR ARCHIVO / DIRECTORIO PERMISOLOGIA /etc/hosts.deny 644 Linux34 Linux50 /etc/hosts.allow 644 /etc/ssh 755 /etc/rc.d/init.d 755 /var/log 755 Riesgo La existencia de permisos en archivos que pudieran permitirle a personas malintencionadas intentar acciones sobre equipos de la Plataforma Tecnológica de la Corporación, constituye un elemento a mitigar. Ya que si un usuario que no sea root posee permiso de lectura-escritura puede intentar aprovecharse de la presencia de servicios vulnerables. Recomendación Se recomienda crear un grupo conformado por los administradores de Unix/Linux, para controlar que las acciones de administración y/o mantenimiento de los equipos; al mismo tiempo que se implemente el uso del comando ‘su’ para aquellas labores que necesiten ser realizadas como ‘root’. A continuación se presenta una tabla con los permisos recomendados para estos archivos y/o directorios: ARCHIVO / DIRECTORIO PERMISOLOGIA Crontab, hosts.deny, hosts.allow, shadow 600 init.d , ssh 750 /var/log 751 4. El servidor es vulnerable a ataques de forma remota a través de puertos con servicios activos no necesarios. Hallazgo Al realizar la verificación de los servicios disponibles en: /etc/services del servidor web se determino que existen un número significativo de servicios tradicionales activos. Riesgo El servidor es vulnerable a un ataque de forma remota que se podría originar debido a que existen servicios activos que no están siendo utilizados o que pudieran ser no necesarios en el servidor. Recomendación Se requiere deshabilitar servicios innecesarios tradicionales como: Telnet y FTP que deben reemplazarse con SSH. Se recomienda comentar: ftp, tftp, systat, rexd, ypupdated, netstat, rstatd, rusersd, sprayd, walld, comsat, rquotad, name, exec, uucp, sadmind, rlogin, finger, chargen, echo, time, daytime, discard, telnet, imap, pop3, fsp, los servicios rpc (en: /etc/rpc), y todos aquellos servicios y/o programas que no sean necesarios en el servidor o que no estén siendo utilizados. 5. Debilidad en la administración de usuarios y grupos Hallazgo Al momento de realizar la verificación del archivo groups en /etc de los servidores evaluados, se determina que se requiere revisar y deshabilitar algunas cuentas de usuarios o grupos predefinidos que se encuentran activos como: disk, mem, kmem, wheel, mail, dip, utempter, entre otros. Adicionalmente, se detecto que en el archivo etc/shadow existen usuarios/procesos del sistema que no implementan contraseña. Riesgo Un atacante podría usar las cuentas que crea el administrador del sistema para ejecutar programas con el comando login para encontrar información sobre una conexión. Las cuentas estándar o usuarios de sistema, en muchas ocasiones sin una contraseña asignada, constituyen graves fallas de seguridad debido a que un usuario no autorizado podría acceder a información sensible o confidencial del sistema operativo. Recomendación En Unix se encuentran muchas cuentas preinstaladas o que se agregarán en la instalación de un nuevo software especialmente los demonios. Se recomienda deshabilitar o eliminar todas las cuentas de usuarios y grupos no necesarios que hayan sido creados de forma predefinida durante la instalación de Linux como lo son: lp, sync, shutdown, halt, news, uucp, wireless, games, gopher, etc. Por otro lado, todas las cuentas por defecto que en algún momento puedan realizar el procedimiento de autenticación representan una vulnerabilidad del sistema, por lo que no se deben permitir cuentas sin contraseña. Así mismo se debe tener en cuenta los siguientes puntos: Realizar regularmente una auditoria de las cuentas inactivas y deshabilitar aquellas que no han sido utilizadas por un período de tiempo específico, de acuerdo a las políticas de seguridad (90 días). Respaldar los directorios home de los usuarios. Implementar el archivo loginlog (var/log/loginlog) con el fin de monitorear regularmente los intentos fallidos de autenticación (cuando estos superen los 3 intentos). Verificar regularmente los mensajes de login rechazados en var/log/faillog. Colocar el valor (0) a la variable: SYSLOG/SMALL>_FAILED/SMALL>_LOGINS. Implementar el archivo sulog con la finalidad de monitorear regularmente los archivos logs para intentos exitosos o no del comando su. Verificar las cuotas de espacio asignadas a las cuentas de los usuarios. 6. Debilidades en la configuración del archivo sshd_config Hallazgo Se evidencia en el archivo sshd_config, de los servidores, vulnerabilidades en los parámetros de configuración. A continuación se indican los detalles: Los parámetros que permiten restringir las peticiones ssh a través de una interfaz se encuentran deshabilitados #ListenAddress 0.0.0.0 #ListenAddress :: Se encuentra habilitada la política que permite hacer login con el root. #PermitRootLogin no PermitRootLogin yes El parámetro LoginGraceTime que determina el tiempo que se tiene para introducir las credenciales se encuentra deshabilitado. Las siguientes opciones de seguridad se encuentran deshabilitadas. o MaxAuthTries: indica la cantidad de veces de intentos fallidos al ingresar el usuario y/o contraseña. #MaxAuthTries 6 o MaxStartups: indica la cantidad de pantallas de login, o cantidad de conexiones simultaneas de login que permitirá el sshd por ip que intente conectarse. o PasswordAuthentication: permitir a los usuarios que utilicen su login/contraseña habitual #PasswordAuthentication yes o PermitEmptyPasswords: permitir cuentas con contraseñas vací­as #PermitEmptyPasswords no Riesgo El no contar con la configuración adecuada de los parámetros de seguridad del servicio SSH, aumenta la posibilidad de que un atacante se aproveche para ganar acceso indebido. Recomendación Configurar y habilitar el parámetros que permite limitar las interfaces del sistema a través del cual se puede establecer una conexión ssh; en este caso se debe configurar que se accedan a través de la interfaz interna del equipo ListenAddress dir_ip_interna Configurar el parámetros LoginGraceTime a 30 segundos en el servidor Linux50 Configurar el parámetros de acceso del usuario root vía ssh de la siguiente manera: PermitRootLogin: no En el servidor Linux50, activar las opciones de seguridad como se indica a continuación: MaxAuthTries 2 MaxStartups 3 PasswordAuthentication yes PermitEmptyPasswords no Por último se recomienda que todos los usuarios ingresen con su usuario, y para el momento que sea necesario realizar actividades que ameriten tener privilegios de administrador, 7. Debilidad en acceso remoto de root a dispositivos TTY en securetty Hallazgo Al realizar la revisión del archivo securetty en /etc se verifica que el usuario root se puede conectar desde cualquier Terminal tty para autenticarse en los servidores. Riesgo Si no se limita el acceso del usuario root, este se podría conectar de manera remota, poniendo en peligro la seguridad de los servicios que presta el equipo. Recomendación Se debe establecer el acceso de root solo local (tty1), en este sentido es recomendable eliminar o comentar las líneas de consolas virtuales y tty en el archivo /etc/securetty que no sean requeridas. 8. Debilidad en configuración de hosts.deny y hosts.allow Hallazgo Al realizar la revisión de los archivos: hosts.deny y hosts.allow de los servidores evaluados, se detectó que estos archivos no han sido definidos. Riesgo El no tener ninguna instrucción en estos archivos, se otorgara el acceso a cualquier servicio que se solicite, poniendo en riesgo la integridad del servidor. Recomendación Se debe negar todas las máquinas colocando: "ALL: ALL@ALL, PARANOID" en el archivo host.deny y luego en el archivo hosts.allow incluir las máquinas de confianza que están permitidas en el equipo. Los permisos que conceden o niegan el acceso se pueden basar en una dirección IP concreta o nombres de hosts. El archivo hosts.allow tiene prioridad sobre el archivo hosts.deny. 9. El servidor web es vulnerable a un ataque de denegación de servicio (DoS) vía TFTP Hallazgo Al llevar a cabo la revisión del script de los servidores evaluados se determinó que se encuentra habilitado el Protocolo de Transferencia de archivos (TFTP) el cual es un servicio inseguro. Riesgo Un acceso no restringido al servicio TFTP permite a sitios remotos recuperar una copia de archivos claves del sistema, entre los que se pueden incluir archivos críticos como archivos de configuración de routers y archivos de contraseñas Recomendación Se requiere deshabilitar los scripts de arranque que no sean necesarios y de debe otorgar permiso solo de lectura a los usuarios que deban tener acceso a estos. Además los scripts no necesarios no deben tener permiso de ejecución. Y no deben comenzar con las letras K ó S. 12. El protocolo UUCP alternativo a TCP/IP se encuentra habilitado Hallazgo Al realizar la revisión de los script de evaluación se determino que se encuentra habilitado el Protocolo UUCP, el cual es un protocolo en desuso. Riesgo Se posibilita ataques a nivel de red y de denegación de servicios (DoS) debido a fallas en los servicios disponibles vía TCP/IP y en el uso de protocolos defectuosos o no seguros. Recomendación Es necesario que no esté habilitado este servicio ni su usuario. Además, se recomienda que se filtre el servicio si no es requerido su acceso. 13. Ausencia de información documental sobre los procedimientos de continuidad operacional del servidor web Hallazgo Se determino que no se encuentran disponible la documentación de los procedimientos a ejecutar en caso de una contingencia o evento que pudiera afectar la continuidad operativa de los servidores. Riesgo En caso de un evento o interrupción de los servicios no se podría garantizar la continuidad operativa de la plataforma tecnológica. Recomendación Con el objetivo de garantizar la disponibilidad del equipo y su servicio, se debe elaborar los planes de continuidad: plan operativo y plan de contingencia con los procedimientos a ejecutar en caso de que ocurra un evento que pudiera afectar la continuidad operativa del servidor. El mismo deberá ser elaborado por el personal Custodio y entregado oportunamente a la Gerencia Responsable de la Seguridad de la Plataforma Tecnológica para revisar, evaluar y efectuar pruebas planificadas de conformidad a los procedimientos establecidos para tal fin. 14. Debilidad en la versión instalada de PHP. Hallazgo Mediante el empleo de herramientas de evaluación de seguridad se determiná que la versión de Apache instalada en el servidor web es PHP 4.3.9 (cgo.) y se verifico que actualmente se encuentra disponible la versión estable 5.6.9. Riesgo Cuando no se instalan los parches de seguridad o no se actualiza la versión del servidor web se compromete información importante y no se garantiza la disponibilidad, integridad y disponibilidad de la plataforma tecnológica. Recomendación Se sugiere descargar e instalar la última versión estable de PHP 5.6.9. Esta versión incluye mejoras significativas de seguridad y es recomendada por el fabricante por encima de las versiones previas disponibles. En el siguiente sitio web se encuentran los últimos parches disponibles para la versión de Apache: http://php.net/downloads.php (*)Nota Importante: La actualización de la versión debe probarse primero en ambiente de desarrollo.