Pregunta Consejos para asegurar un servidor LAMP


Esto es un Pregunta canónica sobre cómo asegurar una pila LAMP

¿Cuáles son las pautas absolutas para asegurar un servidor LAMP?


91
2017-12-14 01:52


origen




Respuestas:


La respuesta de David es una buena base de los principios generales del fortalecimiento del servidor. Como indicó David, esta es una gran pregunta. Las técnicas específicas que adopte podrían depender mucho de su entorno y de cómo se utilizará su servidor. Advertencia, esto puede requerir mucho trabajo en un entorno de prueba para desarrollarlo y hacerlo bien. Seguido de una gran cantidad de trabajo para integrarse en su entorno de producción y, lo que es más importante, del proceso empresarial.

Primero, sin embargo, verifique si su organización tiene políticas de fortalecimiento, ya que podrían ser las más directamente relevantes. Si no, dependiendo de tu rol, este podría ser un buen momento para desarrollarlos. También recomendaría abordar cada componente por separado de abajo hacia arriba.

El l
Hay muchas buenas guías disponibles para ayudarte. Esta lista puede o no puede ayudarlo dependiendo de su distribución.

La A
Apache puede ser divertido de asegurar. Me resulta más fácil fortalecer el sistema operativo y mantener la facilidad de uso que con Apache o PHP.

Ellos

La p
Esto encaja de lleno con la idea de las Prácticas de Programación Seguras, que es toda una disciplina propia. SANS y OWASP tienen una cantidad ridícula de información sobre el tema, así que no intentaré replicarlo aquí. Me centraré en la configuración del tiempo de ejecución y dejaré que los desarrolladores se preocupen por el resto. A veces, la 'P' en LAMP se refiere a Perl, pero generalmente PHP. Estoy asumiendo lo último.


105
2017-12-14 14:50



Quiero subir esta respuesta al menos 10 veces. - user58859
La N silenciosa: ya sea con IPTables o un firewall externo, bloquea las conexiones de red solo para lo que es necesario para que el público acceda. - Matt
Esto debería ser una wiki de la comunidad. - Brian Adkins
Es tan fácil olvidar el firewall. Me enteré de alguien que construyó un servidor web para un sitio web e incluso llegó a piratear la pila TCP / IP para eliminar el tráfico que no era el puerto 80. Otra cosa que se pasa por alto son los servicios innecesarios, si no es necesario para ser encendido, apágalo - Aaron Mason
@AaronMason: ¡Felicitaciones! Tienes una anécdota exitosa. Recordemos que su situación específica funcionó bien, pero esperemos que los futuros lectores comprendan su entorno inusual. En el caso general este consejo es bastante peligroso. - Scott Pack


Usted ha hecho una pregunta que es, francamente, digna de algunos libros sobre el tema. Pero hay algunas pautas básicas generales que funcionan bien:

  1. Mantener actualizado. Esto significa que el sistema operativo, todos los servicios y, sobre todo, todas las aplicaciones web que esté ejecutando.
  2. Deshabilite los servicios innecesarios, limite los que sean necesarios a la exposición mínima (si no se está conectando de forma remota a MySQL, entonces no la escuche en TCP) y ejecute un firewall basado en host. (Si es estrictamente LAMP, deberías ser bueno con 80 y 443, pero quizás con SSH también para la administración).
  3. Utilice contraseñas seguras. Mejor aún, si usa SSH, use solo autenticación basada en clave.
  4. Asegúrese de que no está iniciando sesión como root. Inicie sesión como usuarios y use su y sudo.
  5. Si bien no hace que las cosas sean más seguras, debe ejecutar herramientas como logwatch para estar al tanto de lo que está sucediendo en su servidor.

Espero que te ayude a empezar.


13
2017-12-14 02:23



Le sugeriré que lea la "Guía para la configuración segura de Red Hat Enterprise Linux 5" escrita por NSA - ALex_hha
Llegué tarde a la fiesta, pero recientemente leí que "no iniciar sesión como root" ya no es tan importante, especialmente si estás usando autenticación SSH basada en claves públicas / privadas. - the0ther


Aquí hay una buena lista de verificación con la que me gustaría comenzar.

Cortafuegos

  • Un buen enfoque es no permitir que empiece el tráfico, entonces solamente abre lo que necesites, como lo necesites. Esto resulta en la apertura de la Puertos / ips mínimos para hacer que las cosas funcionen y que minimice su exposición.
  • Para un servidor LAMP es posible que solo necesite abrir puertos para http / https para el mundo y ssh para administradores de sistemas.
  • Asegúrese de que cosas como el tráfico de ipv6 estén bloqueadas si no lo están utilizando
  • AWS proporciona grupos de seguridad, Linux tiene iptables y muchos paquetes para elegir desde.

SSH y Usuarios

  • Sin contraseña para acceso ssh (usar clave privada)
  • No permitas root a ssh (los usuarios apropiados deben ssh en, luego su o sudo)
  • Usa sudo para usuarios para que los comandos sean registrados.
  • Registre intentos de inicio de sesión no autorizados (y considere el software para bloquear / prohibir a los usuarios que intentan acceder a su servidor demasiadas veces, como fail2ban)
  • ssh en un puerto no estándar (esto puede ser útil para asegurarse de que no está fruncido, y mantener alejado gran parte del tráfico molesto, pero no hará mucho por la seguridad, especialmente por sí mismo)
  • bloquee ssh solo en el rango de ip que requiera (un rango grande es mejor que ningún rango)

Base de datos

  • Sanear datos de usuario
  • Parametrizar consultas
  • Considere abstraer el DB a su propia máquina. Esta separación puede hacer que sea más difícil para un atacante acceder a su pila web y viceversa.
  • Como cualquier software mantenerse al día es importante.
  • Un usuario para cada finalidad.. Al crear usuarios, comience sin privilegios y agregue solo los que necesitan para realizar su función. Tener usuarios separados para diferentes aplicaciones (o, a veces, partes distintas de las aplicaciones) ayudará a reducir el beneficio que tiene un atacante en caso de que comprometan cualquier cuenta. También tenga cuidado con privilegios especiales como GRANT que no deben asignarse a la ligera.
  • Tener una política para cambiar las contraseñas periódicamente es una buena idea. Si está preocupado por la cantidad de esfuerzo requerido, recuerde que menos frecuente es mejor que nunca.
  • Entender el cifrado de contraseñas. Contraseñas de sal. ¡No uses md5!

Software

  • Mantener el software actualizado (OS, servidor web, lenguaje de scripting, CMS). Mucha gente explorará en busca de vulnerabilidades conocidas en versiones antiguas (no parcheadas)
  • Elimine cualquier software que no necesite (idealmente, no mantenga el paquete necesario para compilar software en servidores de producción, es mejor compilarlo previamente y ponerlo a disposición de sus máquinas de producción)
  • Asegurate de archivo los permisos están bloqueados (especialmente para cosas como subidas de usuarios y archivos de configuración)
  • La contraseña protege el área de administración de CMS a nivel de servidor web (autenticación http Puede sentarse frente a un CMS vulnerable y ayudar a bloquear el acceso, lo cual es una buena manera de prevenir ataques.
  • Utilizar SSL para el área de administración y otros datos sensibles
  • Automatice la administración de sus servidores e infraestructura (algo como Puppet, Chef o SaltStack. Si también utiliza AWS CloudFormation). Esto le ayudará a parchear cosas en muchos servidores y reducir escenarios como arreglar permisos en el Servidor A, pero olvidarse de hacerlo en el Servidor B
  • Donde sea posible, no regale la versión particular de su CMS, PHP o WebServer. Si bien no es seguro ocultar esta información, hay muchas personas explorando en busca de versiones particulares de software diferente y cuanta menos información proporcione libremente, más tendrá que trabajar un atacante. Esta es una buena manera de asegurarte de que no eres una de las frutas de bajo rendimiento. Por supuesto, esto no le hará nada a alguien que quiera dedicar un poco más de esfuerzo a entrar
  • Limitar las personas que tienen acceso al servidor.

7
2017-08-10 08:08





Además de lo que David sugiere, cuanto más modular sea su instalación, me refiero a restringir el acceso a ciertos usuarios / grupos creados específicamente para una tarea y limitar su alcance, más segura será su pila LAMP: un ejemplo de esto es tener un usuario de Apache para los archivos / carpetas de Apache con los permisos establecidos en consecuencia y no en ningún grupo que pueda acceder a archivos / carpetas críticos del sistema. Un usuario que puede acceder a las tablas MySql que están asociadas a sus sitios web que va a servir y solo a esas tablas. Además, puede restringir su acceso para dar la cantidad mínima de acceso desde una llamada de PHP. Además, asegúrese de que el nombre de usuario de MySQL utilizado / expuesto a través del archivo PHP no sea el mismo nombre de usuario o contraseña utilizado para otro usuario.

Lo que esto significa: si el usuario de apache o el usuario de MySql están comprometidos, no pueden hacer ningún daño fuera del alcance de las carpetas a las que apache tiene acceso (en el caso del usuario de apache) y fuera de la tabla ( s) / database (s) (en el caso del usuario para la base de datos MySQL).

Si de alguna manera se comprometiera al usuario de MySQL, no podrían, por ejemplo, acceder a la base de datos y eliminar todas las bases de datos de MySQL y arruinar todos sus datos. PODRÍAN, bajo ciertas circunstancias, eliminar tablas o insertar información en algunas tablas en una base de datos aislada, por lo que es importante otorgar solo acceso a la tabla donde sea absolutamente necesario y solo otorgar los permisos necesarios ... si no lo hace. No es necesario tener privilegios de eliminación de tablas ni privilegios de actualización, entonces no se los dé a ese usuario.

Además, si por alguna razón se encuentra su nombre de usuario y contraseña de la cuenta administrativa para MySQL, si usa un nombre de usuario diferente al de cualquier nombre de usuario en su sistema, primero debe romper la seguridad de su sistema antes de ingresar a su base de datos para hacer daño. Lo mismo ocurre con el usuario de apache y el acceso a los archivos.

Ejemplo de tiempo! Voy a dar un ejemplo de sistema para simplificar la idea.

digamos que tiene usuarios en su sistema (la raíz debe estar deshabilitada por seguridad a través de algo como umod -l o passwd -l, etc.): john, barney, terence, y lisa.

puede crear un usuario en MySQL con el nombre de bigbird (asegúrese de usar una contraseña con hash). Bigbird solo tiene privilegios de selección y privilegios de actualización, pero no permite eliminar o crear, y ciertamente no . Además, crea otro usuario administrativo de MySQL con el nombre garfield para trabajar en la base de datos MySQL y elimina el usuario root de la base de datos MySQL para que no pueda comprimirse. Garfield ha sido concedido . privilegios en todo MySQL (efectivamente, esto solo es cambiar el nombre de la raíz).

ahora, crea un grupo de apache o un usuario y lo llamaremos apweb2. Appweb2 no es miembro de otros grupos, y todos los archivos / carpetas de apache se almacenan en / home / apweb2 /. Cada host virtual tendría su propia subcarpeta y cada uno de estos hosts tendría la raíz de documentos establecida en esa subcarpeta. Los enlaces simbólicos se deshabilitarían para no proporcionar accidentalmente acceso al resto del sistema.

Además, puede restringir el acceso ssh solo a ciertos usuarios (o ciertos grupos, me gusta colocarlos en el grupo ssh y hacer que sea lo único que pueda usar ssh).

Además, puede elegir qué usuarios tienen privilegios de sudo para restringir aún más las cosas. Otro paso que puede seguir es hacer que cualquier usuario ssh no pueda sudo, puede crear usuarios especiales que puedan usar sudo y que no puedan usar ssh, de modo que una vez que ssh, tenga que iniciar sesión en otro usuario para poder Acceso al sudo.

Por lo tanto, al modularizar cada segmento, si uno está comprometido, no se comprometerá a toda la pila y puede solucionar el problema 1 en lugar de tener que comenzar de nuevo desde cero.


4
2017-07-30 04:49





Encontré este documento de SANS.org realmente útil http://www.sans.org/score/checklists/linuxchecklist.pdf


2
2017-08-10 11:50



Bienvenido a Server Fault! En general, nos gustan las respuestas en el sitio para poder pararse solas. Los enlaces son geniales, pero si ese enlace se rompe, la respuesta debería tener suficiente información para seguir siendo útil. Por favor considere editar su respuesta para incluir más detalles. Ver el Preguntas más frecuentes para más información. - slm


En la actualidad, no descuide la virtualización de contenedores, a saber, Docker, systemd-nspawn y los mecanismos de virtualización de contenedores en los que se construyen (espacios de nombres, cgroups). El uso de la virtualización de contenedores le permite aislar procesos, por ejemplo, si uno de los servicios está comprometido, un atacante no tendrá acceso a otros servicios.

En el caso de LAMP, es posible utilizar, por ejemplo, cuatro contenedores Docker con servidor SSH, Apache, MySQL, PHP-FPM / Python / Perl / etc.


0
2017-07-27 20:00