¿Cuál es su lista de verificación / rutina al configurar un servidor web Linux?
¿Qué recomiendas para lograr la máxima seguridad?
¿Hay alguna forma preferida de realizar mantenimiento repetido?
En primer lugar, tenga en cuenta que cualquier capacidad de secuencias de comandos en Apache (php, cgi, ruby, ...) es el equivalente potencial de una cuenta de shell con privilegios del usuario que ejecuta la secuencia de comandos.
Si el servidor se comparte con varios usuarios, es posible que desee pensar en usar suexec (- o ITK MPM - Sugerido por David Schmitt ) para que no todas las secuencias de comandos se ejecuten como el mismo usuario de Apache.
Virtualice o chroot apache, de modo que cualquier compromiso esté al menos contenido en una capa adicional de seguridad. Tenga en cuenta que cuando procesa apache, el mantenimiento puede ser más difícil, ya que termina moviendo bibliotecas a la cárcel, etc. desde los puertos, y ejecute portaudit desde dentro, sin tener que preocuparse por las dependencias de la biblioteca y mover archivos manualmente, lo que siempre se convierte en un desastre feo. Con las cárceles BSD, simplemente puede seguir usando el sistema de administración de paquetes (puertos). (En GNU / Linux también puede usar VServer para la virtualización. - Sugerido por David Schmitt )
(obviamente) Manténgase al día con las actualizaciones y parches, no solo para Apache, sino también PHP, ruby, perl, etc. No confíe en su sistema operativo para darle todas las actualizaciones tampoco. Algunas distribuciones son extremadamente lentas con sus parches. Limite el tiempo de exposición a vulnerabilidades de 0 días tanto como sea posible. Pegue el feed milw0rm en su lector RSS, suscríbase a las listas de correo de insecure.org , etc. No solo lo ayudará a conocer las vulnerabilidades antes de que su sistema operativo libere un parche, también aprenderá sobre vulnerabilidades en ciertos php aplicaciones cms, por ejemplo, que su sistema operativo ni siquiera puede administrar o parchear.
Use algo como tripwire / aide, audit o mtree (en BSD) para realizar un seguimiento de los cambios en su sistema de archivos. Este es realmente importante. Si se le envían cambios periódicamente, revíselos manualmente, todos los días. Si algún archivo cambia y no debería cambiar, investigue por qué. Si algún javascript malicioso se inserta de alguna manera en sus páginas a través de cualquier método, lo atrapará de esta manera. Esto no solo salva a su servidor, sino también a sus usuarios, ya que se puede abusar de sus propias páginas web para infectar a sus visitantes. (Esta es una táctica muy común, los atacantes a menudo ni siquiera se preocupan por su servidor, solo quieren infectar a la mayor cantidad posible de sus visitantes hasta que los descubran. Estos atacantes tampoco se molestan en ocultar sus huellas por lo general. Es muy importante atrapar un compromiso como este lo más rápido posible).
Usar cosas como suhosin para proteger php ayuda. Pero también aprenda a comprenderlo, modifique su configuración según los parámetros esperados de su aplicación.
El uso de un parche de kernel como PaX puede ayudarlo a protegerse de muchas vulnerabilidades de desbordamiento de búfer. Incluso si su software es vulnerable. (Esto no te hace invulnerable, es solo otra capa menor).
No confíes demasiado cuando uses alguna herramienta de seguridad. Comprenda las herramientas que usa y use el sentido común. Lee, aprende, mantente al día tanto como puedas.
Considere usar un control de acceso obligatorio (por ejemplo: SELinux ). Le permite especificar, para cada aplicación, lo que está permitido hacer, con gran detalle. A qué archivos se le permite acceder. Lo que el núcleo llama puede hacer, etc. Este es un proceso muy complicado y requiere mucha comprensión. Algunas distribuciones proporcionan políticas SELinux prefabricadas para sus paquetes (por ejemplo: Gentoo ). Esta sugerencia es una especie de contradicción con la siguiente, pero sigue siendo válida, sin embargo.
Mantén las cosas simples. Una estrategia de seguridad compleja puede funcionar en su contra.
En Apache, configure unas reglas predeterminadas muy restrictivas (Opciones Ninguna, Denegar de todas, etc.) y anule según sea necesario para VirtualHosts específicos.
Denegar el acceso a todos los archivos de puntos (que también cubren inmediatamente los archivos .htaccess)
Siempre use https en cualquier lugar donde haya algún tipo de autenticación de contraseña.
El firewall debe ser una política de denegación por defecto. Cree algunas reglas específicas en su firewall para registrar el tráfico específico.
Configure scripts de análisis de registros para escanear sus registros en busca de anomalías. (el conjunto de IDS de preludio puede hacer esto, pero honestamente, le recomiendo que cree sus propios scripts con el tiempo, ya que lo ayudará a comprender mejor sus propias herramientas y reglas).
Haga que el servidor le envíe informes diarios sobre los últimos usuarios registrados, conexiones activas, ancho de banda utilizado, etc.
Haga un escaneo cron para buscar binarios suid, archivos de escritura mundial y cosas así, y que se los envíen por correo.
Para cualquier cosa que configure que se le envíe por correo, debe crear una lista de excepciones a lo largo del tiempo. (carpetas para ignorar los cambios en el sistema de archivos, 777 archivos para permitir, suid binarios para permitir). Es importante que solo reciba notificaciones de cosas que no deberían suceder. Si recibe un correo todos los días con cosas triviales, comenzará a ignorarlas y se volverán inútiles.
Tenga una buena estrategia de respaldo redundante en capas sólidas. Y no asuma que hacer una imagen o copia de todo funciona. Por ejemplo, si MySQL está escribiendo una tabla durante la copia de seguridad, los archivos binarios de MySQL pueden dañarse al restaurar la copia de seguridad. Por lo tanto, necesitará un cron que mysqldump esté en sus bases de datos sobre imágenes regulares o tarballs nocturnos o control de versiones o cualquier otra cosa que haya configurado. Piensa en tu estrategia de respaldo. Quiero decir, REALMENTE lo pienso.
No confíes en listas como esta por seguridad :) ¡En serio! Encontrará muchos de estos en Internet, vaya a leerlos todos, investigue cada sugerencia y use el sentido común y la experiencia para tomar una decisión. Al final, la experiencia y el sentido común son las únicas cosas que te salvarán. Ni listas ni herramientas. Lea, pero no solo copie sin comprender.
Recomiendo la Lista de verificación de seguridad de Linux , de SAN. Lo uso, además de otros procedimientos internos. La lista de verificación puede estar un poco desactualizada, pero muchos de los puntos clave son ciertos.
fuente
fuente
edite su ~ / .ssh / config
Esto hace
no responde pero
funcionará si desea iniciar sesión como root.
fuente
Siempre habrá innumerables permisos para verificar, innumerables listas de verificación, interminables descubrimientos de nuevos errores / vulnerabilidades. La seguridad no creo que sea algo que enciende o apaga, es algo que hace constantemente.
Dada la "falla inevitable" del software, SELinux ayuda a eliminar algunas preocupaciones (una vez más, ninguna bala de plata para la seguridad). suponiendo que una aplicación de espacio de usuario está comprometida, la política correcta de SELinux evitará que actúe según sus privilegios habituales (es decir, si SELinux estaba deshabilitado o era permisivo). Por supuesto, esto requerirá que monitoree sus registros de auditoría y analice la política instalada y la modifique cuando sea necesario para permitir que las aplicaciones funcionen.
No digo que la política predeterminada no ayudaría, pero personalmente me gusta saber qué permite.
fuente