Esta es una pregunta canónica sobre cómo asegurar una pila LAMP

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

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

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

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

• Puntos de referencia del Centro de seguridad de Internet : distribución específica para los principales sabores
• CentOS Hardening HowTo : sigue de cerca la guía CIS RHEL5, pero es una lectura mucho más fácil
• NIST SP800-123 - Guía de seguridad general del servidor
• Hojas de datos de endurecimiento de la NSA : no se actualizó tan recientemente como CIS, pero aún es aplicable en su mayoría
• Tiger : software de auditoría de seguridad del sistema en vivo

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

• Apache Server Hardening : esta pregunta en el sitio hermano de IT Security tiene mucha buena información.
• Benchmarks del Centro de Seguridad de Internet - Nuevamente, benchmarks de Apache.
• Consejos de seguridad de Apache : directamente desde el proyecto Apache, parece que cubre los conceptos básicos
• Lista de verificación de endurecimiento de DISA - Lista de verificación de los chicos del Departamento de Información

Ellos

• Center for Internet Security Benchmarks - Nuevamente, pero para los puntos de referencia MySQL
• OWASP MySQL Hardening
• Pautas generales de seguridad : lista de verificación básica de los desarrolladores del proyecto

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

• Endurecimiento de PHP : algunas discusiones menores, también en el sitio de IT Security SE.
• Proyecto PHP Endurecido - Proyecto principal que produce Suhosin , un intento de parchear la aplicación PHP para proyectar contra ciertos tipos de ataques.
• Endurecimiento de PHP con Suhosin : un breve tutorial específicamente para Suhosin
• Endurecimiento de PHP desde php.ini : discusión breve, pero no mala, sobre algunas de las opciones de tiempo de ejecución relacionadas con la seguridad

Has 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 el sistema operativo, todos los servicios y ESPECIALMENTE todas las aplicaciones web que está ejecutando.
2. Deshabilite los servicios innecesarios, limite los que son necesarios a la exposición mínima (si no se está conectando remotamente a MySQL, entonces no lo escuche en TCP) y ejecute un firewall basado en host. (Si es estrictamente LAMP, debería ser bueno con 80 y 443, pero quizás también con SSH para la administración).
3. Usa contraseñas seguras. Mejor aún, si usa SSH, use solo autenticación basada en clave.
4. Asegúrese de no iniciar sesión como root. Inicie sesión como usuarios y use su & 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 sucede en su servidor.

Espero que te ayude a comenzar.

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

Cortafuegos

• Un buen enfoque es no permitir que comience ningún tráfico, luego solo abra lo que necesite , según lo necesite. Esto resulta en la apertura de los puertos / ips mínimos para que las cosas funcionen y eso minimiza su exposición.
• Para un servidor LAMP, es posible que solo necesite abrir puertos para http / https al mundo y ssh para sysadmins.
• Asegúrese de que cosas como el tráfico ipv6 esté bloqueado si no lo está usando
• AWS proporciona grupos de seguridad, Linux tiene iptables y muchos paquetes para elegir.

SSH y usuarios

• Sin contraseña para acceso ssh (use clave privada)
• No permita que root haga ssh (los usuarios apropiados deben ingresar, luego su o sudo)
• Use sudo para usuarios para que los comandos se registren
• 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 tenga poca fruta y mantenga alejado gran parte del tráfico molesto, pero no hará mucho por la seguridad, especialmente por sí mismo)
• bloquee ssh solo al rango de ip que necesite (un rango grande es mejor que ningún rango)

Base de datos

• Desinfecte los datos del 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 llegar a su pila web y viceversa.
• Como cualquier software, mantenerse actualizado es importante.
• Un usuario para cada propósito . Al crear usuarios, comience sin privilegios y agregue solo los que necesita para realizar su rol. Tener usuarios separados para diferentes aplicaciones (o, a veces, distintas partes de las aplicaciones) ayudará a reducir el beneficio que tiene un atacante si compromete 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 le preocupa la cantidad de esfuerzo requerida, recuerde que menos frecuente es mejor que nunca.
• Comprender el cifrado de contraseña. Contraseñas de sal . ¡No uses md5!

Software

• Mantenga el software actualizado (sistema operativo, servidor web, lenguaje de script, CMS). Mucha gente buscará vulnerabilidades conocidas en versiones antiguas (sin parches)
• Elimine cualquier software que no necesite (idealmente no mantenga el paquete requerido para compilar software en servidores de producción, es mejor precompilar el software y ponerlo a disposición de sus máquinas de producción como un paquete)
• Asegúrese de que los permisos de archivo estén bloqueados (especialmente para cosas como cargas de usuarios y archivos de configuración)
• Área de administración de protección con contraseña para CMS en el nivel del servidor web (la autenticación http puede ubicarse frente a un CMS vulnerable y ayudar a bloquear el acceso, que es una buena manera de prevenir ataques)
• Use SSL para el área de administración y otros datos confidenciales
• Automatice la administración de sus servidores e infraestructura (algo como Puppet, Chef o SaltStack. Si usa AWS CloudFormation también). Esto lo 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
• Siempre que sea posible, no regale la versión particular de su CMS, PHP o WebServer. Si bien ocultar esta información no es seguridad, hay muchas personas que buscan versiones particulares de diferentes programas y, mientras menos información entregue libremente, más tiene que trabajar un atacante. Esta es una buena manera de asegurarte de que no eres una de las frutas bajas. Por supuesto, esto no hará nada a alguien que quiera gastar un poco más de esfuerzo para entrar
• Limite las personas que tienen acceso al servidor

Además de lo que sugiere David, 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 es su pila LAMP: un ejemplo de esto es tener un usuario de Apache para archivos / carpetas Apache con 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 con 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 PHP. Además, asegúrese de que el nombre de usuario 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 la (s) carpeta (s) a las que apache tiene acceso (en el caso del usuario de apache) y fuera de la tabla ( s) / base de datos (en el caso del usuario para la base de datos MySQL).

Si de alguna manera el usuario de MySQL se viera comprometido, no podría, por ejemplo, acceder a la base de datos y eliminar todas las bases de datos de MySQL y arruinar todos sus datos. PODRÍAN, en algunas circunstancias, poder soltar 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 para eliminar tablas o actualizar privilegios, luego no se los dé a ese usuario.

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

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

supongamos que tiene usuarios en su sistema (la raíz debe estar deshabilitada por seguridad mediante 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 cifrada). Bigbird solo tiene privilegios selectos y privilegios de actualización, pero no se descarta ni crea, 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 al usuario raíz de la base de datos MySQL para que no se pueda comprimir. Garfield ha sido otorgado . privilegios en todo MySQL (efectivamente, esto es solo renombrar root).

ahora, crea un grupo apache o un usuario y lo llamaremos apweb2. Appweb2 no es miembro de otros grupos, y todos los archivos / carpetas para 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 del documento 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 ponerlos 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 llevar más allá es hacer que los usuarios de ssh no puedan sudo, podría crear usuarios especiales que puedan usar sudo que no puedan usar ssh, por lo que una vez que ingrese, debe iniciar sesión en otro usuario para tener Acceso al sudo.

Entonces, al modularizar cada segmento, si uno se ve comprometido, la pila completa no se verá comprometida y puede solucionar el problema 1 en lugar de tener que comenzar de nuevo desde cero.

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

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 están construidos (espacios de nombres, cgroups). El uso de la virtualización de contenedores le permite aislar procesos, por ejemplo, si uno de los servicios se ve comprometido, un atacante no obtendrá 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.