¿Cuál es la forma más segura de configurar los permisos de usuario del servidor web? [cerrado]

Personalmente, me gusta activar HTTPs, activar SElinux y hacer algo como esto en el archivo vhost:

## Deny access based on HTTP method
if ($bad_method = 1) {
        return 444;
}

location = /robots.txt  { access_log off; log_not_found off; }
location = /favicon.ico { access_log off; log_not_found off; }
## Disable access to hidden files
location ~ /\.          { access_log off; log_not_found off; deny all; }
location ~ ~$           { access_log off; log_not_found off; deny all; }

También intentando controlar los ataques de desbordamiento de búfer desde el nginx.conf

 ## Start: Size Limits & Buffer Overflows ##
  client_body_buffer_size  1K;
  client_header_buffer_size 1k;
  client_max_body_size 1k;
  large_client_header_buffers 2 1k;
 ## END: Size Limits & Buffer Overflows ##

Y luego:

1. El módulo NginxHttpLimitZone debe estar activado.
2. Restringir conexiones Nginx salientes
3. Restricciones de directorio (configure su CMS para que solo pueda leer los archivos que necesita; o lo que necesite)

La lista es larga, y esto es solo una precaución.

  

¿Cuál es la forma más segura de configurar los permisos de usuario para una aplicación web?

bueno, esto depende de su servidor web y (la tecnología de) su aplicación. si tienes algo como php y apache / mod_php entonces sería idealmente así:

• tener un devel-usuario
• deje que el usuario de desarrollo adquiera su docroot
• permita que su usuario de servidor web sea su caché / tmp-directorios (o use una aplicación web moderna como contao que ni siquiera necesita esa llamada "piratería de modo seguro")

¿Por qué? Bueno, si el servidor web no es el propietario de los archivos, no se puede engañar para que sobrescriba o altere los archivos, por lo que no es posible realizar muchos ataques.

otro punto en asegurar esp. php está utilizando disable_funtions en php.ini, pero eso no es tema.

si usas apache / suphp, entonces esta separación no funcionará; No estoy seguro acerca de fastcgi.

si utiliza su servidor web como un servidor de inversión inversa y un servidor / contenedor de aplicaciones (como django, rails, tomcat, etc.), necesitará otro concepto porque no hay nada como un docroot.

por cierto, nginx no ejecuta archivos de aplicaciones web o ejecuta php.

  

Y como beneficio adicional (sin dejar el tema del servidor en sí), ¿qué otros consejos de configuración relacionados puede proporcionar para asegurar un servidor web más allá de lo que podría obtener de los repositorios?

use su google-foo para "asegurar el manual de Debian", mi padawan muy joven :) esta pregunta ha sido respondida mucho en esta plataforma.

En caso de que esté hablando de sitios web de PHP, tengo una solución que funciona.

Si tiene varios usuarios que tienen varios sitios web (todos ejecutándose con PHP) y desea aislarlos, puede intentar usar php-fpm junto con Nginx. A continuación, crea para cada sitio web un grupo de fpm propio donde ese usuario específico se utiliza para la ejecución de ese grupo de fpm específico, ya que los usuarios no pueden interferir con los sitios web de otros usuarios, ya que en un nivel de permiso no pueden ejecutar código En otros directorios o incluso acceder a ellos. Al pasar las variables php como 'basedir' al grupo fpm, puede configurar, por ejemplo, el directorio de trabajo para ese intérprete de PHP en particular.

Básicamente, está creando un contexto de ejecución para cada usuario individual y, por lo tanto, los está aislando.

Lamentablemente, Internet carece de un buen tutorial que le muestre cómo configurar todo, pero puede trabajar con este tutorial para configurar dicho entorno: enlace

Le daría la propiedad de un directorio de sitio web particular a un usuario, que también está en el grupo www-data, para que Nginx aún pueda llamar a los archivos estáticos (html, css, js).

Seamos más abstractos. La solución anterior básicamente le dice que debe separar la ejecución de ese programa que ejecuta sus archivos de aplicación. Solo necesita esta seguridad si necesita servir archivos no estáticos (es decir, una llamada a un script php).