Otros consejos de seguridad

Para finalizar este tema se van a recopilar una serie de consejos de seguridad que no encajan exactamente en ninguna de las secciones anteriores, pero que son igualmente muy importantes.

Actualizaciones:

—Apache, al igual que IIS, es un servidor que ha tenido un historial no exento de problemas graves de seguridad, por lo que es importante mantenerlo actualizado. Por este motivo, es recomendable suscribirse a la Apache HTTP Server Announcements List (http://httpd.apache.org/lists.html#http-announce) para estar informado de estos problemas y sus soluciones, o bien usar un servicio alternativo con la misma funcionalidad. También debemos tener en cuenta que muchas veces el problema no reside en el servidor, sino en los módulos instalados, los scripts CGI o el propio SO, por lo que es recomendable estar al día de las incidencias de todos esos elementos para mantener un nivel de seguridad adecuado en todo momento. Las actualizaciones en sí de Apache se pueden conseguir de forma automática en Ubuntu mediante apt-get update, como ya hemos dicho.


Acceso a ficheros del sistema y Logs:

Se debe tener especial cuidado con los permisos asignados a directorios y ficheros del sistema (comandos, programas, etc.) y también logs. Si un usuario cualquiera puede escribir sobre el ejecutable de un comando, entonces puede crear una versión alterada maliciosamente de forma que cuando root la ejecute, con el máximo privilegio, pueda hacer mucho daño en el servidor. —

Si, en cambio, permitimos que los logs o su localización física puedan ser escritos por usuarios no root, alguien podría colocar un enlace simbólico a otro archivo como fichero de log, escribiendo (y destruyendo) dicho fichero. Otra consecuencia de este fallo de seguridad es que escribir en un log puede enmascarar ataques o introducir datos falsos, anulando su utilidad.

Por este motivo tenemos que tener especial cuidado con los permisos a nivel de todo el sistema operativo. En el caso concreto de los logs, debemos comprobar propietarios, permisos y contenidos del directorio /var/log/apache2;— el propietario debe ser root (y el grupo adm, que es el de usuarios con privilegios de administrador) y los permisos nunca deben darse para "todos". Por suerte, una instalación por defecto de Apache ya está configurada de esta manera.


Server Side Includes:

—El uso de esta tecnología puede suponer riesgos de seguridad potenciales:

  • Incrementan la carga de trabajo del servidor.
  • Poseen los mismos riesgos asociados con scripts CGI en general. Usando "exec cmd" (http://www.w3.org/Jigsaw/Doc/User/SSI.html#exec) los archivos habilitados para SSI podrían ejecutar cualquier programa CGI con los permisos del usuario sobre el que se ejecuta Apache. Algunos consejos para evitarlo son:
    • —Para aislar el potencial daño que un archivo SSI malicioso puede causar, un administrador puede habilitar suEXEC (visto a continuación)
    • Es recomendable reservar una extensión concreta para ficheros que tengan habilitado SSI (como .shtml)
    • —Se puede deshabilitar la posibilidad de ejecutar scripts y programas desde páginas con SSI reemplazando Includes con IncludesNOEXEC en la directiva Options dentro de cualquier tag <Directory> que nos interese según las páginas que queramos limitar.


Programas CGI en general:

—Debemos tener plena confianza en los autores de programas CGI que usemos, así como tener habilidad para detectar (o averiguar si se han detectado) agujeros de seguridad potenciales en los mismos, usando los mecanismos ya descritos para encontrar por Internet vulnerabilidades documentadas de estos programas.

—Todos los scripts CGI se ejecutaran bajo el mismo usuario. Se pueden ejecutar scripts bajo distintos usuarios mediante suEXEC o CGIWrap:

  • suEXEC es una característica de Apache que permite a los usuarios ejecutar programas CGI o SSI con IDs de usuario distintas a la que usa el servidor. Más información: http://httpd.apache.org/docs/2.2/suexec.html
  • CGIWrap es un programa que permite a los usuarios usar programas CGI y forms HTML sin comprometer la seguridad del servidor:
    • —Los scripts se ejecutan con los permisos del usuario propietario de los mismos.
    • A cada script se le pasan unos chequeos de seguridad.
    • Si estos no se pasan el script no se ejecuta, porque se determina que es potencialmente perjudicial.
    • —Más información: http://cgiwrap.sourceforge.net/

—Finalmente, no se debe permitir a los usuarios ejecutar scripts CGI en cualquier directorio. Como ya hemos mencionado, se debe limitar la ejecución a directorios especiales concretos, dando al administrador control completo para administrar lo que se coloca en los mismos (script aliased cgi).


Otras fuentes de contenido dinámico:

Módulos como mod_php, mod_perl, mod_tcl, y mod_python, se ejecutan con los permisos del usuario bajo el que se ejecuta Apache (el cual se especifica en la directiva User de apache2.conf).— Por tanto, sus scripts pueden acceder a lo mismo que el propio servidor.— Debemos pues tener cuidado con el usuario asignado al mismo y sobre los permisos que le damos en partes del sistema de ficheros que no estén relacionadas con el servidor directamente.


Directiva UserDir (mod_userdir):

—Aunque ya hemos visto cómo se instala y para qué sirve, hay un detalle adicional que conviene tener en cuenta a la hora de trabajar con este mod: root no debería tener ningún dato propio accesible para nadie de esta forma, es decir, root no debería tener una web personal para no correr el riesgo de revelar información personal que pueda derivar en un ataque debido al análisis de la misma, ingeniería social u otras técnicas que se puedan aprovechar de la existencia de estas webs. — Para ello, se recomienda incluir: UserDir disabled root (o una lista de usuarios sin derecho a usar el mod, separada con espacios) en la configuración del mod. Las versiones modernas de mod_userdir ya lo hacen por defecto con el root.


Uso de Location y Directory

Debemos evitar conflictos entre las directivas Location y Directory, es decir, evitar que ambas asignen a las mismas localizaciones parámetros contradictorios. Una sección <Location> aplica las directivas que contiene según la porción de la URL que designe, es decir, que el nombre de la sección Location realmente indica una parte de una URL del servidor. Esta directiva por tanto actúa siempre fuera del sistema de ficheros, siendo esta la diferencia principal con la directiva Directory, que siempre designa una localización física en el disco duro del servidor. En este sentido es similar a la directiva <Directory>, y también tiene que terminar con una directiva de cierre acorde (</Location>).

Por tanto, el funcionamiento de una sección Location es similar (aunque no idéntico) al de una sección Directory. Por ejemplo, si incluimos esto en el fichero de configuración de Apache:

<Location /private>
Order Allow,Deny
Deny from all
</Location>

Denegaremos el acceso vía web a URLs como:

Es decir, se aplica a todas las URL que tengan una sección que comience por private, aunque luego haya más caracteres.

Las secciones <Location> se procesan en el orden en que aparecen en el fichero de configuración que las contiene, después de leer las secciones <Directory> y los ficheros .htaccess, y también después de las secciones <Files>. Una vez dada toda esta información, podemos también enunciar una serie de normas a la hora de manejarla:

  • Esta directiva no debe usarse para controlar el acceso a ubicaciones del sistema de ficheros, ya que actúa al margen del mismo. Para el contenido al que se le asigne una configuración concreta en función del lugar en el que esté en el sistema de ficheros, se debe usar <Directory> y <Files>, que es el propósito específico de estas directivas.
  • Como diferentes URLs (destinos designados mediante Location) pueden corresponderse con una misma ubicación de un sistema de ficheros, los controles de acceso a los mismos podrían saltarse si varias directivas Location tienen configuraciones contradictorias entre si.
  • Una excepción a lo dicho es el uso de <Location />, que aplica una configuración a un servidor entero.
  • El uso de <Location> es especialmente útil combinado con la directiva SetHandler. Así pueden establecerse puntos concretos dentro del mapa del sitio donde su acceso origine la ejecución de un handler con un fin concreto.

—Más información: http://httpd.apache.org/docs/2.2/sections.html

Last modified: Saturday, 31 July 2010, 11:39 AM