ManualDe Seguridad DelSistema
1
Índice Introducción... 4 Seguridad Perimetral... 5 Seguridad del Servidor Web... 6 Mantenerse actualizado... 6 Permisos en los directorios ServerRoot... 6 Server Side Includes (SSI)... 8 CGI en general... 9 Sin Script con alias CGI... 9 Script con alias de CGI... 10 Otras fuentes de contenido dinámico... 10 Protegiendo la Configuración del Sistema... 11 Proteja los archivos del servidor por defecto... 11 Revisión de los Logs... 12 Seguridad en el servidor de contenido... 13 Seguridad en la plataforma LMS... 14 Recomendaciones básicas... 14 Utilice sistemas de actualización automática... 15 Tenga copias de seguridad disponibles... 16 Otras consideraciones... 16 2
En este documento veremos las recomendaciones de seguridad para los sistemas instalados. NOTA: Por motivos de seguridad en este manual no se incluye ninguna cuenta ni password de administración. Estos datos serán enviados por correo electrónico al responsable del proyecto. 3
Introducción Este manual pretende ser una guía de buenas prácticas para la correcta configuración en el campo de la seguridad del Campus Virtual. Tenemos que tener en cuenta que la solución instalada es un sistema complejo en el que intervienen, además del sistema operativo, varios motores, servidores web, gestores de contenido y LMS. Por este motivo en este manual se comentan las distintas recomendaciones de seguridad por las distintas capas. 4
Seguridad Perimetral El sistema está dotado de un sistema de firewalls perimetrales los cuales solo aceptan el trafico web de unos puertos determinados. En concreto el trafico HTML a través del puerto 80 Por motivos de seguridad para el tráfico de conexiones remotas a través de SSH el firewall no permite este tipo de conexiones desde cualquier dirección IP. Por lo que es necesario crear una regla específica para permitir el acceso a través de SSH desde las instalaciones del MSyD. Teniendo que ser esta una única dirección IP fija. Por este motivo al comienzo del proyecto deberán de comunicar mediante correo electrónico la dirección IP desde la que se van a conectar a los servidores. La dirección de correo a la que tienen que remitir esta información es: soporte@neo-com.net y nacho.paniagua@cestas.org 5
Seguridad del Servidor Web El servidor web instalado en un Apache en su versión 2.0 La plataforma se entrega correctamente configurada, no siendo necesario realizar estas configuraciones. No obstante se enuncian en este documento el listado de buenas prácticas para que lo tengan en cuenta en caso de que necesiten realizar cualquier cambio en la configuración, una vez que la plataforma haya sido migrada. Las recomendaciones de seguridad son las siguientes: Mantenerse actualizado El Servidor Apache HTTP tiene un buen historial de seguridad y una comunidad de desarrolladores muy preocupado por los problemas de seguridad. Pero es inevitable que algunos problemas - grandes o pequeños - se descubrirán en el software después de haberlo publicado. Por esta razón, es crucial para mantener al tanto de las actualizaciones del software. Es importante suscribese a la lista de anuncios de servidor Apache HTTP http://httpd.apache.org/lists.html#http-announce Aquí podrá mantenerse informado de las nuevas versiones y actualizaciones de seguridad. Permisos en los directorios ServerRoot En funcionamiento normal, Apache se ha iniciado por el usuario root, y cambia al usuario definido por la directiva de usuario para servir hits. Como es el caso con cualquier comando que ejecuta root, debe tener cuidado de que ésta se protege frente a posibles modificaciones por los usuarios que no sean root. 6
No sólo deben los propios archivos de tener permisos de escritura por root, es necesario que los directorios y los padres de todos los directorios lo tengan. Por ejemplo, si se decide colocar en ServerRoot / / local / apache usr entonces se sugiere que se cree ese directorio como root, con comandos como los siguientes: mkdir /usr/local/apache cd /usr/local/apache mkdir bin conf logs chown 0. bin conf logs chgrp 0. bin conf logs chmod 755. bin conf logs Se supone que /, / usr y / usr / local son sólo modificable por el root. Al instalar el ejecutable httpd, debe asegurarse de que está protegido de manera similar: cp httpd /usr/local/apache/bin chown 0 /usr/local/apache/bin/httpd chgrp 0 /usr/local/apache/bin/httpd chmod 511 /usr/local/apache/bin/httpd Se puede crear un subdirectorio htdocs que esan modificable por otros usuarios. Desde la raíz no se ejecuta nunca ningún archivo fuera de allí, y no debe crear archivos allí. 7
Server Side Includes (SSI) Server Side Includes (SSI ) presentan un administrador del servidor con varios riesgos de seguridad potenciales. El primer riesgo es el aumento de la carga del servidor. Todos los archivos habilitados para SSI tienen que ser analizados por Apache, o no existen directivas SSI comprendidos dentro de los archivos. Aunque este aumento de la carga es menor, en un entorno de servidor compartido puede llegar a ser significativa. Archivos de SSI también plantean los mismos riesgos que están asociados con los scripts CGI en general. Utilizando el elemento exec cmd, archivos habilitados para SSI pueden ejecutar cualquier script CGI o programa bajo los permisos del usuario y el grupo de Apache se ejecuta como, según la configuración en httpd.conf. Hay maneras de mejorar la seguridad de los archivos de SSI sin dejar de tener beneficios que proporcionan. Para aislar el daño que un archivo SSI díscolo puede causar, un administrador del servidor puede habilitar suexec. Para ello puede consultar el manual online de Apache : http://httpd.apache.org/docs/2.0/es/misc/security_tips.html#cgi Habilitación de SSI para archivos con extensiones.html o.htm puede ser peligroso. Esto es especialmente cierto en un alto tráfico o en entornos de servidor compartido. Los archivos compatibles con SSI deben tener una extensión por separado, tales como.shtml convencional.. Esto ayuda a mantener la carga del servidor en un mínimo y permite una gestión más sencilla de los riesgos. Otra solución consiste en deshabilitar la capacidad de ejecutar scripts y programas de las páginas SSI Para ello sustituir Incluye con: <--#include virtual="..." - -> Para ejecutar scripts CGI si estos scripts se encuentran en los directorios designados por una directiva ScriptAlias. 8
CGI en general En primer lugar, siempre hay que recordar que hay que confiar en los escritores de los CGI scripts / programas o de su capacidad para detectar los agujeros de seguridad potenciales en CGI, si eran deliberadas o accidentales. Scripts CGI ejecutan esencialmente comandos arbitrarios en el sistema con los permisos del usuario del servidor web y por lo tanto pueden ser extremadamente peligrosos si no se controlan cuidadosamente. Todos los scripts CGI se ejecutan como el mismo usuario, por lo que tienen potencial de conflicto (accidental o deliberadamente) con otras secuencias de comandos. Sin Script con alias CGI Permitir a los usuarios ejecutar scripts CGI en cualquier directorio sólo si: Se confía en que los usuarios no escribir guiones que deliberada o accidentalmente exponer su sistema a un ataque. Se tiene en cuenta la seguridad en su sitio y esta quieren que sea tan débil en otras áreas, como para que un agujero potencial sea irrelevante. No tiene los usuarios, y nadie visita su servidor. 9
Script con alias de CGI Limitar el CGI en directorios especiales da el control de administración sobre lo que sucede en esos directorios. Esto es más seguro que sin Script con alias de CGI, pero sólo si los usuarios con acceso de escritura a los directorios son de confianza o el administrador está dispuesto a probar cada nuevo script / programa CGI para agujeros de seguridad potenciales. La mayoría de los sitios eligen esta opción Otras fuentes de contenido dinámico Habilitar opciones de scripting que se ejecutan como parte del propio servidor, como mod_php, mod_perl, mod_tcl y mod_python, provoca que se ejecuten bajo la identidad del propio servidor, y por lo tanto los scripts ejecutados por estos motores pueden potencialmente acceder a cualquier cosa del servidor. Algunos motores de scripting pueden proporcionar restricciones, pero es mejor no realizar esta configuración si no se está completamente seguro. 10
Protegiendo la Configuración del Sistema Para evitar que los usuarios pueden anular las funciones de seguridad que ha configurado. Puede realizar lo siguiente. En el archivo de configuración del servidor <Directory /> AllowOverride None </ Directory> Esto evita el uso de.htaccess en todos los directorios aparte de los habilitados específicamente. Proteja los archivos del servidor por defecto Un aspecto de Apache, que de vez en cuando es mal entendido es la característica de acceso predeterminado. Es decir, a menos que tome medidas para cambiarla, si el servidor puede encontrar su camino a través de un archivo de reglas normales de mapeo de URL, que puede servir a los clientes. Por ejemplo, consideremos el siguiente ejemplo: # cd /; ln -s / public_html Accessing http://localhost/~root/ 11
Esto permitiría a los usuarios acceder a través de todo el sistema de ficheros. Para solucionar este problema se agrega el siguiente bloque de configuración de su servidor: <Directory /usr/users/*/public_html> Order Deny,Allow Allow from all </Directory> <Directory /usr/local/httpd> Order Deny,Allow Allow from all </Directory> Es necesario prestar especial atención a las interacciones de Ubicación y Directorio de directivas, por ejemplo, even ifi<directory /> deniega el acceso, una directiva <Location /> podría derribarla. También tenga cuidado de jugar con la directiva UserDir;. Ajustarlo a algo como./ tendría el mismo efecto, para root, como el primer ejemplo de arriba. Revisión de los Logs Para mantenerse al día con lo que está sucediendo realmente en contra de su servidor en el que tiene que comprobar los archivos de registro. A pesar de que los archivos de registro sólo informa de lo que ya ha sucedido, que le dará una comprensión de lo que se lanza ataques contra el servidor y permite comprobar si el nivel necesario de seguridad está presente. 12
Seguridad en el servidor de contenido El servidor de contenido CMS implantado es un Drupal en su versión Core 7.22 La plataforma se entrega correctamente configurada, no siendo necesario realizar estas configuraciones. No obstante se enuncian en este documento el listado de buenas prácticas para que lo tengan en cuenta en caso de que necesiten realizar cualquier cambio en la configuración, una vez que la plataforma haya sido migrada. Las recomendaciones de seguridad son las siguientes: Quitar todos los archivos CHANGELOG.txt y demás archivos.txt de los modulos que instalados Quitar el archivo install.php Cambiar la ruta de login, esto es que cuando entre a /user me niegue el acceso esto lo podemos hacer con el hook_menu_alter via @jedihe Poner un límite de intentos en el login por ejemplo con este módulo http://drupal.org/project/flood_control si pueden tener un certificado ssl sería muy bueno. El pilón: Si usan git o svn para mantener su sitio con los ultimos cambios en el de producción revisen los permisos de las carpetas site.com/.svn site.com/.git o archivos en concreto site.com/.gitignore site.com/.svn/entries, más información. Suscribese a la lista de seguridad de drupal http://lists.drupal.org/mailman/listinfo/security-news 13
Seguridad en la plataforma LMS El motor LMS instalado es un Moodle en su versión 2.4 La plataforma se entrega correctamente configurada, no siendo necesario realizar estas configuraciones. No obstante se enuncian en este documento el listado de buenas prácticas para que lo tengan en cuenta en caso de que necesiten realizar cualquier cambio en la configuración, una vez que la plataforma haya sido migrada. Las recomendaciones de seguridad son las siguientes: Recomendaciones básicas Actualice Moodle regularmente en cada lanzamiento. Los agujeros de seguridad publicados atraen la atención de los crakers después del lanzamiento. Cuanto más antigua sea la versión, tanto más probable es que sea vulnerable. Desactive Registros globales. Esto ayudará a prevenir contra posibles problemas XSS en scripts de terceras partes. Use contraseñas complejas para el administrador y los profesores. Elegir contraseñas "difíciles" es una práctica de seguridad básica para proteger contra el cracking por "fuerza bruta" de las cuentas. 14
Abra cuentas de profesor únicamente a usuarios dignos de confianza. Evite crear cajas de arena (sandboxes) públicas con cuentas gratuitas de profesor en servidores de producción. Las cuentas de profesor tienen permisos mucho más libres y es más fácil crear situaciones donde es posible abusar de los datos o robarlos. Separe sus sistemas todo lo que le sea posible Otra técnica básica de seguridad es usar diferentes contraseñas en diferentes sistemas, usar diversas máquinas para diversos servicios, etc. Esto impedirá que el daño se extienda incluso si una cuenta o un servidor son atacados. Ejecute actualizaciones regulares Utilice sistemas de actualización automática Linux: up2date, yum, apt-get Considere automatizar las actualizaciones mediante un scritp programado vía cron Manténgase al día en php, apache y moodle Utilice listas de correo para mantenerse actualizado Cortafuegos 15
Tenga copias de seguridad disponibles Practique con antelación procedimientos de recuperación Utilice regularmente un detector rootkit Linux/MacOSX - http://www.chkrootkit.org/ Otras consideraciones He aquí algunas otras otras consideraciones que favorecen su seguridad general: Desactive opentogoogle, especialmente en sitios K12 Utilice SSL, httpslogins=yes Desactive el acceso de invitados Incluya claves de matriculación en todos los cursos Utilice buenas contraseñas Utilice el ajuste de formularios seguros Ajuste la contraseña de usuario root en mysql Desactive el acceso de red mysql Permisos de archivo más seguros/paranoides 16
Fin del documento 17