Lista de verificación de seguridad para alojar un sitio web en un servidor dedicado - Linux [cerrado]

Red Hat proporciona una guía de seguridad para RHEL 6, que también es aplicable a CentOS. Esto está disponible aquí . CIS también proporciona una lista de verificación bastante decente ubicada aquí .

Sin embargo, si este servidor es importante para algo remoto, le recomiendo que contrate a un experto para que realice una auditoría exhaustiva de su sistema.

Mantenga su software actualizado, especialmente el software que acepta entradas de fuentes no confiables (es decir, usuarios, Internet, cualquiera que no sea usted).

Solo permite lo que sea necesario. Ejemplo: no permita SSH de entrada global, solo permita conexiones desde el rango de IP de sus oficinas.

Evite configuraciones donde los usuarios puedan ponerse en riesgo. Ejemplo: requiere claves SSH y no permitir contraseñas. Es fácil para un usuario elegir una contraseña incorrecta, es mucho más difícil para ellos elegir una clave privada incorrecta.

Asegúrese de que sus consultas de base de datos sean resistentes a la inyección de SQL

Asegúrese de que la raíz de su documento esté bien definida y de que no presente más archivos de los que desea.

Minimice los privilegios que tienen sus cuentas de base de datos (es probable que no necesiten la eliminación y creación de tablas, por ejemplo)

Evite los lugares en el código en los que toma la entrada del usuario y la ejecuta o evalúa

Identifique sus puntos débiles e instale mitigaciones de protección. Ejemplo: memcached no tiene excelentes funciones de control de acceso, así que vincúlelo a localhost o bloquee las conexiones entrantes no deseadas con IPTables.

Borre los datos que pertenecen a sus usuarios que ya no tienen valor para usted. No puedes perder lo que no tienes.

En un entorno de alojamiento, comprenda que su host también tiene acceso y control sobre ese entorno, por lo que habrá algunos riesgos que no podrá evitar. Si se portan mal o cometen errores, sus datos y sistemas estarán en riesgo. Probablemente no esté bien para los secretos de estado, tal vez un nivel aceptable de riesgo para su sitio. Esa es una decisión de juicio que tendrá que hacer por su cuenta.

El consejo de @Terry es bastante sólido. Permítame ofrecerle una visión más conceptual.

Su servidor estará seguro si todo lo que se ejecuta en él se contabiliza y mantiene adecuadamente. Si bien esto suena como una tautología (es), apunta a algunos principios generales:

• Siempre aplique actualizaciones de seguridad del proveedor de software. Las distribuciones de Linux tienen herramientas para eso; déjalos correr.
• Si es posible, no instale software que no provenga del proveedor de distribución de Linux, ya que un software adicional significa trabajo adicional para aplicar los parches de seguridad.
• No ejecute nada que no necesite. Una nueva instalación de sistema operativo en blanco tiende a generar una gran cantidad de servicios que no son estrictamente necesarios para sus operaciones. En particular, use netstat -a para ver qué servicios de acceso remoto están en su máquina, y lsof para encontrar el proceso correspondiente.
• Asegúrese de que, en cualquier momento, haya una cadena de responsabilidad definida correctamente. Si sucede algo malo, las personas deben saber con quién comunicarse y cómo. Un servidor sin un administrador del sistema claramente definido es un servidor que pronto formará parte de una red de bots, o ya lo es. Asegúrese de que cuando vaya de vacaciones, haya alguien más disponible para completar las tareas de administración del sistema.
• Hacer copias de seguridad. Mantenga varias copias de seguridad sucesivas en lugar de conservar solo la última. Esto ayuda mucho para la recuperación después de un ataque, aunque solo sea para análisis postmortem. Recuerde que su servidor está destinado a ejecutar un servicio : disponibilidad es un objetivo principal. Las copias de seguridad frecuentes y completas pueden ayudarlo a poner el servicio en línea más rápido.