Tengo un sitio que se ejecuta en un VPS. Configuré la pila LAMP y algunos otros programas personalmente. Esta es la segunda vez que configuro un VPS y estoy un poco preocupado por la seguridad. ¿Hay algunas cosas que debería tener en cuenta (con respecto a mi instalación de Linux y la pila LAMP) que las personas podrían usar para obtener acceso a mi VPS y robar / alterar mi sitio o apagarlo?
Cualquier servicio externo es un riesgo de seguridad. Usted indicó que está ejecutando una pila LAMP, por lo que asumo que tiene al menos los siguientes servicios en ejecución:
1. SSHd
2. Apache/Nginx
3. PHP
4. MySQL
MySQL por defecto no está orientado externamente, y no debería hacerlo a menos que esté involucrado en un entorno de agrupación o replicación (en cuyo caso hay alternativas a ponerlo en la web amplia, como una VPN).
Apache / Nginx + PHP no se puede hacer internamente si pretende proporcionar contenido a las personas en la web, por lo que estos serán sus principales puntos de ingreso.
SSHd en sí mismo tiene que ser público (no siempre, pero en aras de la simplicidad en este caso). El uso de un par de claves para la autenticación y la desactivación total de la autenticación de contraseña es su mejor opción para evitar que las personas obtengan acceso a través de este servicio.
Hablemos de servicios web. Apache, Nginx y PHP. Estos son los servicios que las personas intentarán explotar para obtener acceso a su máquina, así que hablemos de cómo protegerlos.
Primero, vas a querer aislar los servicios. Si los instaló usted mismo, eso significa asegurarse de que Apache y Nginx se ejecuten como usuarios no root.
En segundo lugar, querrá echar un vistazo a php-fpm o suphp, que permite a PHP operar como un usuario que está separado de su servidor web incluso a nivel de host virtual o de directorio.
Esto logra dos cosas, al quitar los permisos de root de Apache / Nginx, si alguien obtiene el control de ese servicio, no puede afectar nada más que la operación de ese servicio específico.
Cambiar el usuario de php (especialmente en función de cada sitio) aísla al módulo PHP de la interacción con otros sitios en la máquina y con el servidor web, por lo que si tiene un cliente o sitio web con un código explotable, Su servicio completo, otros sitios y su máquina no están en riesgo.
Su código de solicitud.
Cualquier código de aplicación del lado del servidor, ya sea PHP / Perl / Python (sea lo que sea la P en LAMP) es tu mayor riesgo. Ya sea que lo haya escrito usted mismo, o sea un paquete de código abierto (o comercial), cualquier falla de codificación podría provocar vulnerabilidades de seguridad como la inyección de SQL.
Si usted mismo ha escrito un código, debe seguir el Top 10 de OWASP como mínimo. También debe verificar su código, tal vez escaneando con Zap o Rips (que son gratuitos), u otras herramientas, o la contratación de una empresa de pruebas de lápiz.
Si está utilizando software de código abierto o comercial, debe verificar su historial de vulnerabilidades. Si no hay ninguna preocupación, es probable que el código nunca haya sido auditado. Si hay un número pequeño, es una buena señal. Si hay muchos es posible que desee evitar el proyecto. Los complementos pueden causar riesgos, así como las aplicaciones principales (un gran problema con los CMS como Drupal).
Otras personas han mencionado ajustes de infraestructura, pero en general los valores predeterminados son bastante buenos en estos días. Yo restringiría SSH al inicio de sesión basado en clave (en lugar de contraseñas) y me aseguraría de que la aplicación se conecte a la base de datos utilizando un usuario con pocos privilegios.
Lo que está tratando de lograr se conoce como hardening , es decir, hacer que los sistemas y servicios sean más seguros. Obviamente hay mucho de qué hablar y pensar. Probablemente también desee tener una perspectiva mucho más amplia, ya que probablemente desee reforzar su servidor completo, no solo los pocos servicios que mencionó anteriormente.
Personalmente creo que la NSA hizo un gran trabajo aquí. Eche un vistazo a sus recomendaciones para varios sistemas operativos. Aunque específicamente hablan de RHEL5 en el caso de Linux, la mayoría de los consejos se pueden aplicar a cualquier distribución de Linux.
Aunque está un poco anticuado, la lista de verificación SANS es un buen punto de partida (estoy a punto de ir a buscar la lista de la NSA mencionada por Karol).
Pero las grandes ganancias provienen de las cosas simples: