31 votos

Linux hardening - servidores web

¿Cuál es su lista de comprobación/rutina a la hora de configurar un servidor web Linux?

¿Qué recomienda para lograr la máxima seguridad?

¿Hay alguna forma preferible de realizar el mantenimiento repetido?

27voto

jns Puntos 449
  • En primer lugar, ten en cuenta que cualquier capacidad de scripting en Apache (php, cgi, ruby,...) es el equivalente potencial de una cuenta Shell con privilegios del usuario que ejecuta el Shell.

  • Si el servidor se comparte con varios usuarios, es posible que desee pensar en utilizar suexec (- o MPM ITK - Sugerido por David Schmitt ) para que no todos los script se ejecuten con el mismo usuario apache.

  • Virtualizar o chroot apache, de modo que cualquier compromiso es al menos algo contenido en una capa adicional de seguridad. Tenga en cuenta que cuando hace chroot a apache, el mantenimiento puede volverse más difícil, ya que termina moviendo bibliotecas a la jaula, etc. Si está en FreeBSD puede usar una jaula en su lugar, que es mucho más fácil de mantener, ya que puede simplemente instalar apache desde los ports, y ejecutar portaudit desde dentro, sin tener que preocuparse de ninguna dependencia de librerías y mover ficheros manualmente, lo que siempre se convierte en un feo lío. Con las jaulas BSD puedes simplemente seguir usando el sistema de gestión de paquetes (ports). (En GNU/Linux también puedes usar VServer para la virtualización. - Sugerido por David Schmitt )

  • (obviamente) Mantente al día con las actualizaciones y parches, no sólo para Apache, sino también para PHP, ruby, perl, etc... tampoco confíes sólo en que tu sistema operativo te proporcione todas las actualizaciones. Algunas distribuciones son extremadamente lentas con sus parches. Limita el tiempo de exposición a vulnerabilidades de día 0 tanto como sea posible. Pega los milw0rm en su lector RSS, suscríbase a insecure.org listas de correo, etc. No sólo le ayudará a conocer las vulnerabilidades antes de que su sistema operativo publique un parche, sino que también conocerá las vulnerabilidades de ciertas aplicaciones php cms, por ejemplo, que puede que ni siquiera estén gestionadas o parcheadas por su sistema operativo.

  • Use algo como tripwire/aide, audit, o mtree(en BSD) para realizar un seguimiento de los cambios en su sistema de archivos. Esta es realmente importante. Haz que te envíen los cambios por correo regularmente, revísalos manualmente, todos los días. Si cambia algún archivo que no debería cambiar, investiga por qué. Si algún javascript malicioso de alguna manera se inserta en sus páginas a través de cualquier método, usted lo atrapará de esta manera. Esto no sólo salva a su servidor, sino también a sus usuarios, ya que sus propias páginas web pueden ser abusadas para infectar a sus visitantes. (Esta es una táctica muy muy común, los atacantes a menudo ni siquiera se preocupan por su servidor, sólo quieren infectar a tantos de sus visitantes como sea posible hasta ser descubiertos. Estos atacantes ni siquiera se molestan en ocultar sus huellas. Atrapar un compromiso como este lo más rápido posible es muy importante).

  • Usando cosas como suhosin para proteger php ayuda. Pero también aprender a entenderlo, ajustar su configuración a los parámetros esperados de su aplicación.

  • Utilizando un parche del kernel como PaX puede ayudarle a protegerse de muchas vulnerabilidades de desbordamiento del búfer. Incluso si su software es vulnerable. (Esto no te hace invulnerable, es sólo otra capa, menor).

  • No te confíes cuando utilices alguna herramienta de seguridad. Comprende las herramientas que utilizas y usa el sentido común. Lee, aprende, mantente al día todo lo que puedas.

  • Considere la posibilidad de utilizar un control de acceso obligatorio (p. ej: SELinux ). Permite especificar, para cada aplicación, lo que se le permite hacer, con todo lujo de detalles. A qué ficheros puede acceder. Qué llamadas al kernel se le permite hacer, etc. Este es un proceso muy complicado y requiere mucha comprensión. Algunas distro's proveen politicas SELinux pre-hechas para sus paquetes (eg: Gentoo ). Esta sugerencia es una especie de contradicción con la siguiente, pero sigue siendo válida.

  • Las cosas sencillas. Una estrategia de seguridad compleja puede jugar en su contra.

  • En Apache, establezca unas reglas por defecto muy restrictivas (Opciones Ninguna, Denegar a todos, etc...) y anúlelas según sea necesario para VirtualHosts específicos.

  • Denegar el acceso a todos los dotfiles (que también cubre inmediatamente los archivos .htaccess)

  • Utilice siempre https en cualquier lugar donde haya algún tipo de autenticación de contraseña.

  • El cortafuegos debe ser una política de denegación por defecto. Construya algunas reglas específicas en su cortafuegos para registrar tráfico específico.

  • Configure scripts para analizar sus registros en busca de anomalías. (los preludio IDS suite puede hacer esto, pero honestamente, te recomiendo que construyas tus propios scripts con el tiempo, ya que te ayudará a entender mejor tus propias herramientas y reglas).

  • Haz que el servidor te envíe informes diarios sobre los últimos usuarios conectados, las conexiones activas, el ancho de banda utilizado, etc.

  • Haz que un cron escanee en busca de binarios suid, archivos escribibles en el mundo y cosas así, y que te los envíe por correo.

  • Para cualquier cosa que configures y que te envíen por correo, deberías crear una lista de excepciones con el tiempo. (carpetas para ignorar cambios en el sistema de archivos, archivos 777 para permitir, binarios suid para permitir). Es importante que sólo recibas notificaciones de cosas que no deberían ocurrir. Si recibes un correo todos los días con cosas triviales, empezarás a ignorarlas y dejarán de tener sentido.

  • Disponga de una buena estrategia de copias de seguridad redundantes en capas sólidas. Y no te conformes con hacer una imagen o copia de todo lo que funciona. Por ejemplo, si MySQL está en medio de la escritura de una tabla durante su copia de seguridad, sus archivos binarios MySQL pueden estar dañados cuando restaure su copia de seguridad. Así que necesitarás un cron que haga mysqldump de tus bases de datos además de imágenes regulares o tarballs nocturnos o control de versiones o cualquier otra cosa que hayas configurado. Piensa en tu estrategia de copia de seguridad. Quiero decir, piensa REALMENTE en ello.

  • No confíe en listas como ésta para su seguridad :) En serio. Encontrarás montones de ellas por todo Internet, léelas todas, investiga cada sugerencia y utiliza el sentido común y la experiencia para decidirte. Al final, la experiencia y el sentido común son lo único que te salvará. No las listas ni las herramientas. Lee, pero no te limites a copiar sin entender.

5voto

simmosn Puntos 304
  • Configuro un cortafuegos, y solo hago agujeros para añadir cada servicio individualmente
  • Para cualquier servicio, leo los documentos de ayuda de la aplicación para su(s) archivo(s) de configuración, y me aseguro de ojear al menos cada ajuste.
  • Estoy suscrito a listas de correo de seguridad
  • Ejecuto rkhunter y lynis todas las noches en un cron job
  • Me envían por correo todos los errores que superan un determinado umbral
  • Tengo todos los cambios relacionados con el registro (reiniciar el servicio de registro, etc) por correo electrónico a mí
  • Guardo etc en subversion

5voto

Recomiendo el Lista de comprobación de seguridad de Linux de SAN. Yo uso eso, además de otros procedimientos internos. Puede que la lista esté un poco desfasada, pero muchos de los puntos clave siguen siendo válidos.

4voto

devin Puntos 569

Edita tu ~/.ssh/config

permit_root_login no

esto hace

ssh root@server

no responder pero

ssh user@server
user$ su

funcionará si quieres iniciar sesión como root.

1voto

rev Puntos 88

Siempre habrá innumerables permisos que comprobar, innumerables listas de comprobación, un descubrimiento interminable de nuevos fallos/vulnerabilidades. Yo no diría que la seguridad es algo que se activa o desactiva, sino algo que se hace constantemente.

Dado el "fallo inevitable" del software, SELinux ayuda a apagar algunas preocupaciones (de nuevo, no es una bala de plata para la seguridad). suponiendo que una aplicación de espacio de usuario se vea comprometida, la política correcta de SELinux evitará que actúe con sus privilegios habituales (es decir, si SELinux estaba deshabilitado o permisivo). Esto por supuesto requerirá que monitorees tus registros de auditoría y analices la política instalada y la modifiques donde sea necesario para permitir que las aplicaciones funcionen.

No digo que la política por defecto no ayude, pero personalmente me gusta saber lo que permite.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X