it-swarm-es.com

Endurecimiento del servidor Linux

Ya hemos tenido preguntas aquí acerca de Endurecer Apache , Endurecer PHP y Asegurar SSH .

Para continuar con esta tendencia, me interesan los pasos que las personas toman para fortalecer los servidores Linux. Como en qué pasos las personas siempre toman al configurar un nuevo servidor, que no son específicos de la aplicación. Como configurar la partición tmp para que sea noexec, desinstalar/deshabilitar ciertos servicios, e.t.c.

88
Mark Davidson

Identifique las aplicaciones y procesos requeridos y aplique una lista de verificación para evitar instalarlos o, en el peor de los casos, desinstálelos después de la compilación inicial.

¡Aquí estoy pensando en esos culpables comunes que todavía parecen pasar a demasiadas distribuciones por defecto!

  • Servicios NFS: nfsd, lockd, mountd, statd, portmapper
  • servidor telnet y servidor ftp
  • Servicios R: rlogin, rsh, rcp, rexec
  • BIND y servidor DNS a menos que sea necesario
  • servidores de correo como sendmail
  • X11 (a menos que se necesite escritorio)
  • dedo demonio, etc.

El siguiente paso es ir a través de los posibles servicios débiles y limitar el acceso a ellos.

  • use at.allow y cron.allow para restringir el acceso a crontab
  • Asegúrese de que todos los dispositivos sean ilegibles e inescrutables por usuarios comunes (excluyendo aquellos como/dev/tty y/dev/null, etc.)
  • Archivos clave: los permisos sobre estos deben ser propiedad de root:/etc/fstab,/etc/password,/etc/shadow
  • Verifique cuidadosamente hosts.equiv - una gran fuente de acceso aquí :-)
  • Del mismo modo, la configuración de NFS se bloquea si es necesario
  • Deshabilitar cuentas del sistema innecesarias.
  • Mire el sistema de archivos: bits fijos para todos los ejecutables y directorios públicos.
  • Verifique todos los requisitos de raíz (variable de entorno PATH, sin acceso remoto como raíz, membresía de grupo, requisitos de contraseña)
  • Verifique todos los requisitos del usuario (membresía en grupos privilegiados, shells válidos, umask, SUID, requisitos de SGID
  • y, por supuesto, el guía SANS es una muy buena fuente!
57
Rory Alsop

El espacio "Servidor Linux" incluye un enorme rango de distribuciones , cada uno con su propia estrategia de actualización de configuración predeterminada, cadena de herramientas de administración de paquetes y enfoque de servicios predeterminados y puertos abiertos. También hay una amplia gama de escenarios de implementación: fortalecer un servidor web es bastante diferente a fortalecer un enrutador basado en Linux. Puede obtener mejores consejos al preguntar sobre las distribuciones y los casos de uso que más le interesan.

En ese sentido, solo abordaré la seguridad de Ubuntu aquí señalando algunas fuentes relevantes, aunque gran parte de esto será útil para otras situaciones.

Una buena introducción está aquí: http://www.andrewault.net/2010/05/17/securing-an-ubuntu-server/

La comunidad ha descrito algunos valores predeterminados más estrictos y consejos de refuerzo aquí que se inclinan más hacia la seguridad incluso si la usabilidad se ve afectada: https://help.ubuntu.com/community/StricterDefaults

Aquí hay una matriz y un resumen de las características de seguridad de Ubuntu, para ayudar a la gente a buscar listas de verificación que encuentre en otros lugares: https://wiki.ubuntu.com/Security/Features

Para ver cómo puede hacer algunas de las pruebas usted mismo, consulte la transcripción en http://people.canonical.com/~kees/demo/ec2-session.log dirigida por el código de demostración en http://people.canonical.com/~kees/demo/

Un resumen de lo que se necesita para hacer lo que está en: https://wiki.ubuntu.com/Security/Privileges

El equipo de seguridad de Ubuntu tiene algunas otras cosas útiles en su wiki: https://wiki.ubuntu.com/Security/

25
nealmcb

El endurecimiento del sistema en un momento dado es una hazaña beneficiosa, pero lo que realmente define la implementación segura de un servidor es lo que se hace para ¡mantener ese estado.

Elija cualquiera de las listas de verificación de calidad (vea los enlaces a continuación) que detallan las modificaciones de configuración recomendadas para fortalecer la seguridad de sus servidores y aplique los cambios que tengan sentido para su configuración. Mejor aún, codifique las recomendaciones a través de Puppet ( http://www.puppetlabs.com/ ): esto es ganar-ganar, desplegará más seguro y usted ' Te darás la oportunidad de luchar para mantener las configuraciones endurecidas con el tiempo.

Bonificación : Modelado de ataque/modelado de amenaza ( http://taosecurity.blogspot.com/2007/06/threat-model-vs -attack-model.html ) para enfocar tus esfuerzos defensivos. Por ejemplo, hágase preguntas como:

¿Cómo podría un atacante obtener acceso a estos servidores?
¿Qué cosas puedo hacer para reducir sus posibilidades de éxito?

Traduzca su respuesta a la segunda pregunta a cambios de configuración específicos (endurecimiento) o mediante la implementación de controles adicionales. El juego, por supuesto, es minimizar la probabilidad de éxito de cualquier amenaza. Esto lleva tiempo, pero te sentirás mejor con los cambios que has hecho y por qué en lugar de hacer cambios de manera casual porque alguien dijo que era bueno hacerlo.

Obtenga excelentes resultados al iniciar sesión y revisar . La prevención siempre falla: para contrarrestar esta realidad, desea impulsar el registro para que pueda identificar y reaccionar más rápido ante incidentes y recuperarse más rápido. Mi herramienta favorita para aumentar las defensas y mejorar el inicio de sesión en Linux es OSSEC ( http://www.ossec.net/ ). Dedicar tiempo adicional a la personalización de las reglas incluidas con OSSEC para ver las cosas que más le preocupan es una actividad que vale la pena (por ejemplo, enumerar directorios y archivos adicionales para recibir alertas sobre si se modifican, agregando reglas o elevando la gravedad de las reglas existentes para alertarlo sobre anomalías de autenticación, agregando reglas para observar los cambios en la tabla de usuarios de mysql ( http://blog.rootshell.be/2011/ 01/07/auditing-mysql-db-integrity-with-ossec / ), ad infinitum). Richard Bejtlich acaba de publicar una entrada de blog oportuna titulada ¡Siete proyectos geniales de código abierto para defensores ( http://taosecurity.blogspot.com/2011/01/seven-cool-open- source-projects-for.html )

Para respaldar la verificación continua de las defensas de su servidor, puede ejecutar Nessus ( http://www.nessus.org/nessus/ ) de forma continua con el Centro para plantillas de auditoría de Linux de Internet Security (CIS). Use los resultados como referencia, esté atento a los cambios y remedie las debilidades descubiertas.

Para recapitular:

1) Aproveche las listas de verificación de seguridad respetadas existentes para ayudarlo a redactar una personalizada que funcione para su entorno (con suerte después de realizar actividades de modelado de ataques/amenazas y elegir un marco de administración de configuración)

2) Mejorar las capacidades de observación: mejorar el registro (es decir, ajustar el sistema para generar registros suficientes para las actividades que desea observar), implementar HIDS (p. Ej. OSSEC ), implementar herramientas de análisis de registro (por ejemplo, logwatch - http://sourceforge.net/projects/logwatch/ ), tal vez capturar flujos de red (por ejemplo, a través de softflowd =)

3) Hacer que sea responsabilidad de alguien ser un defensor asiduo de los sistemas

4) Continuamente audita y prueba para verificar lo que crees que se está haciendo.

recursos de referencia/lista de verificación :.

http://cisecurity.org/ El Centro para la Seguridad de Internet (CIS) es una empresa sin fines de lucro cuya División de evaluación comparativa y métrica ayuda a las organizaciones a reducir el riesgo de interrupciones comerciales y de comercio electrónico que resultan de una técnica inadecuada controles de seguridad La División proporciona a las empresas estándares consensuados de mejores prácticas para configuraciones de seguridad, así como recursos para medir el estado de seguridad de la información y para tomar decisiones racionales sobre inversiones en seguridad.

http://iase.disa.mil/stigs/checklist/ Agencia de Sistemas de Información de Defensa (DISA)

http://web.nvd.nist.gov/view/ncp/repository
http://csrc.nist.gov/fdcc/faq-common_security_configurations.html
El Programa Nacional de Lista de Verificación (NCP), definido por el NIST SP 800-70 Rev. 1), es el depósito del gobierno de los EE. UU. De listas de verificación de seguridad disponibles públicamente (o puntos de referencia) que proporcionan guía detallada de bajo nivel para establecer la configuración de seguridad de sistemas operativos y aplicaciones.

21
Tate Hansen

Podría hacer mucho peor que comenzar con Sin lista de verificación .

Mi única crítica a esto es que no pone suficiente énfasis en la administración de la seguridad de un sistema implementado, en particular para garantizar que los parches de los proveedores estén actualizados, planificar un buen modelo de permisos, administrar informes de excepciones IDS, etc.

17
symcbean

Primero, debe averiguar el propósito del servidor y el modelo de amenaza del que está tratando de defenderse. ¿Es un servidor de un solo uso? ¿Múltiples usuarios tienen acceso? Si varios usuarios tienen acceso, ¿confía en todos ellos o no?

Permítame suponer que este servidor se usa solo para servicios de red y que no tiene que lidiar con la amenaza de ataques de alguien que tiene una cuenta en su máquina. Aquí están los pasos que tomo:

  • Habilitar un firewall. Uso iptables para configurar un firewall local. Uso una política default-deny: todas las conexiones entrantes están bloqueadas por defecto, a menos que se permita explícitamente en la política del firewall. Habilito las conexiones entrantes a los servicios que están destinados a ser exportados al mundo (por ejemplo, el puerto 25 si se trata de un servidor de correo, los puertos 80/443 si se trata de un servidor web, etc.). iptables tiene un excelente soporte para el filtrado con estado, de modo que una vez que se establece una conexión, todos los paquetes asociados con esa conexión están permitidos.

  • Actualice todos los paquetes y habilite las actualizaciones automáticas. Actualizo mi distribución de Linux a la última versión de todos los paquetes (yum upgrade en Fedora, pero use lo que sea apropiado para su configuración). También configuré un script cron para capturar e instalar automáticamente las actualizaciones una vez al día (yum -y upgrade en Fedora). Me doy cuenta de que algunos administradores de sistemas con experiencia pueden recomendar no realizar actualizaciones automáticas, porque existe el riesgo de que una actualización rompa algún servicio; tendrá que sopesar ese riesgo contra el riesgo de una violación de seguridad debido a un paquete desactualizado. Personalmente, considero que la facilidad de pensar y la conveniencia de las actualizaciones automáticas valen el riesgo de servicios rotos, pero esta podría no ser la respuesta correcta en todas las configuraciones operativas.

  • Habilitar SELinux. SELinux proporciona una segunda capa de defensa contra ataques a servicios expuestos. En ocasiones puede ser un poco molesto (ocasionalmente me ha causado problemas, rompiendo un servicio de una manera difícil de depurar), pero para una configuración crítica de seguridad, creo que vale la pena.

  • Configure SSH para la administración remota. Debe configurar SSH, para que pueda administrar la máquina de forma remota. Le recomiendo que genere una clave privada DSA en el lado del cliente, que la cifre con una frase de contraseña, que instale la clave pública correspondiente en el archivo Authorized Keys en el servidor e inicie sesión con la clave privada. Es posible que desee personalizar el sshd_config archivo de configuración en el servidor, también. Considere deshabilitar la autenticación de contraseña y solicitar que las personas inicien sesión con una clave pública. La autenticación de contraseña puede ser una alternativa útil en caso de que algo salga mal con su clave privada, pero también es un riesgo mayor, porque los humanos a menudo eligen contraseñas adivinables. Si tiene otros usuarios en su sistema en los que no puede confiar para elegir contraseñas de muy alta calidad, puede deshabilitar la Autenticación de contraseña. Si solo eres tú y tienes una confianza muy alta en todas tus contraseñas, puedes dejarla habilitada. No evito que root inicie sesión a través de SSH, pero es posible que se sienta diferente.

  • Si tiene varios administradores de sistemas, configure cuentas para ellos. Otorgue acceso a cada uno de ellos Sudo, o configure una cuenta raíz separada para cada administrador de sistemas.

  • Habilitar DNSSEC. Configuro mis servidores para ejecutar un servidor DNS de almacenamiento en caché local que valida los nombres de host con DNSSEC siempre que sea posible, para reducir el riesgo de falsificación de DNS.

Luego, para cada servicio que está expuesto al mundo, tomo precauciones para asegurar ese servicio. Por ejemplo, habilito la criptografía (por ejemplo, STARTTLS para servidores de correo) y servidores chroot o sandbox siempre que sea posible. Sin embargo, los detalles variarán de un servicio a otro. Por lo tanto, sugiero enviar una pregunta por separado para cada servicio que intente ejecutar, pidiendo consejos sobre cómo bloquear ese servicio.

Si está buscando una distribución de Linux que ya tenga mucho endurecimiento aplicado, le recomiendo encarecidamente Openwall Linux .

(Comentario: si le da usuarios no confiables a su servidor, entonces se vuelve mucho más difícil reforzar la seguridad: la superficie de ataque es mucho mayor. Si eso es una preocupación para usted, sugiero hacer una pregunta por separado sobre cómo bloquear su servidor para proteger contra ataques de usuarios locales con cuentas en su servidor, ya que el conjunto de técnicas para hacerlo es bastante diferente).

13
D.W.

Y qué pasa con los parches de kernel de Grsecurity/PAX, estos incluyen características muy agradables para fortalecer el servidor a nivel de kernel.

Resumen:

  • Proteger los desbordamientos de pila y pila
  • Ocultar procesos de otros usuarios
  • Lista de control de acceso basada en roles
  • Endurecimiento de chroot
  • / proc, FIFO y restricciones dmesg
  • Capacidades de registro avanzadas
6
Jerry Jacobs

Para Red Hat , NSA tiene consejos sobre el endurecimiento. Ver Guía de configuración para Red Hat Enterprise Linux 5) - NSA/CSS .

Deberían ser útiles para CentOS y otros derivados también.

4
nealmcb
3
nealmcb

Si está intentando proteger su sistema desinstalando paquetes/servicios innecesarios, entonces ya tiene un problema mayor. Estos paquetes no deberían haberse instalado en primer lugar.

Debe instalar un sistema minimalista y solo agregar paquetes que realmente necesita. Lo mismo se aplica a su núcleo. Compile su propio núcleo con solo las características que necesita. No use su núcleo de distribución con soporte para todo (no necesitará el 95% de todos modos)

2
Martin Vegter