¿Sabotear una cuenta de alojamiento web compartido puede poner en peligro la seguridad de las cuentas de hermanos, ya que se comparten en el mismo servidor?
Ya sea a través de configuraciones de htaccess, publicación de credenciales de inicio de sesión y detalles de configuración públicamente, o similares, ¿cuáles son las principales vulnerabilidades a las que un cliente de hosting compartido puede enfrentarse desde cuentas de hermanos malintencionados? O por sus completos errores de noob.
Depende del grado de aislamiento entre cuentas. Simplificar lo que de otro modo sería un tema bastante amplio:
El servidor web se ejecuta como, por ejemplo, wwwrun:wwwdata , todos los sitios web son grabables en grupo, las cuentas son chudadas por ftp en sus propios webroots. Un script malicioso en el sitio A se ejecuta como grupo de datos www, y puede leer y escribir archivos en otros webroots. Podría decir que tales cuentas han nacido comprometidas .
Sin embargo, algunas pequeñas empresas que mantienen sitios web para clientes (subcontratación completa) pueden optar por operar de esta manera, ya que "somos los únicos que accedemos al servidor". El mantenimiento deficiente, los empleados descontentos y la instalación de marcos de terceros vulnerables, generalmente no en este orden, son los principales riesgos. Es decir. Si el cliente A no desea actualizar una versión muy personalizada de MyNiceBlog 1.0 a una versión de seguridad fija 1.5 porque portar las personalizaciones sería costoso, en realidad está poniendo en peligro a todos los otros sitios en la misma máquina.
El servidor web se ejecuta como se indica arriba, pero hay limitaciones ("modos seguros") que intenta evitando que un script salga de la cárcel web. El problema es que el proceso se está absteniendo voluntariamente de usar algunos de los derechos y poderes que todavía tiene . Por lo tanto, también debe eliminar algunas funciones y características (por ejemplo, ejecutar un script de shell), lo que podría hacer que un script malicioso pueda usar nuevamente esos poderes. El sitio solo es ligeramente más seguro y pierde varias características y resultados en la negociación.
El servidor web se ejecuta con permisos completos, luego, para cada solicitud que recibe, genera una copia de sí mismo con permisos reducidos. Cada webroot también es propiedad de un usuario específico con un grupo propio, y no hay acceso de lectura cruzada. El usuario es chrooteado en el sitio web. Si todo funciona como debería, esta configuración es razonablemente segura, por lo que debe tener cuidado con los ataques de escalada de privilegios que podrían hacer que las cosas funcionen, ya que no deberían . Dependiendo de la plataforma y el software instalado, la superficie de ataque puede ser bastante grande. Es posible que algunas funciones (por ejemplo, la carga de módulos dinámicos) aún requieran bloqueo.
Además, los procesos no están aislados a nivel de red; así, por ejemplo, cualquier solicitud del sitio A se vería desde el sitio B como proveniente del mismo host, lo que puede ser malo para (por ejemplo) servidores de bases de datos. Si el sitio A tiene un GRANT ALL PRIVILEGES ON mydb.* TO root@localhost , el sitio B puede conectarse a esa base de datos en el mismo "localhost" con acceso completo y A ninguno lo sabe.
Cada instancia de servidor web se ejecuta en lo que equivale a una máquina virtual propia, con una red independiente. Los sitios no se pueden ver y, si lo hacen, lo hacen con direcciones IP externas, por lo que el servidor de base de datos A no puede confundir una solicitud de inicio de sesión desde el sitio B con una solicitud desde dentro de sí mismo. Sin embargo, la contención de recursos puede ser un problema, y las conexiones al exterior pueden tener un NAT para que no se puedan distinguir. El sitio A podría luego enviar correos electrónicos que simulen ser el sitio B, por ejemplo, o podría intentar recuperar toda la memoria disponible, el ancho de banda o las ranuras de E / S del disco para afectar negativamente al sitio A. Algunas funciones de bajo nivel pueden compartirse entre las máquinas y pueden ser utilizado para montar ataques, por ejemplo, Lectura de reloj y fuente de aleatoriedad para anular esquemas de autenticación.
Esto se debe principalmente a la compañía que proporciona el alojamiento compartido, ya que las formas en que estas empresas han configurado el alojamiento compartido pueden ser diferentes. Una posible vía de ataque se encuentra dentro del sistema de archivos y las cuentas.
Un sistema operativo multiusuario adecuado, como Linux, se basa en un enfoque fundamentalmente seguro de los permisos de los usuarios. Archivos de un conjunto de permisos para cada archivo. Esto se logra asignando a cada archivo la propiedad del usuario y del grupo, así como un conjunto de privilegios para tres grupos de personas:
Como usuario en un servidor web de host compartido, es probable que no pueda leer, y mucho menos escribir fuera de su directorio de inicio. Ciertamente, no debería poder navegar por el directorio de inicio o la raíz de documentos de otros usuarios. Sin embargo, existe un riesgo fundamental en el uso de cuentas de aplicaciones. Tomemos, por ejemplo, la cuenta nobody para ejecutar apache, si alguien obtuviera los privilegios de nobody , tendría acceso a todas las configuraciones de apache de los servidores. Así que los sitios de todos, etc.
A menudo, sí, este es el caso.
Dependiendo del mecanismo para la separación de la cuenta en uso, los atacantes pueden burlar la protección provista por el host y atacar otros sitios. La seguridad en esta área es generalmente lo suficientemente pobre como para que la mayoría de los atacantes intenten un movimiento lateral entre sitios en el mismo servidor. A menudo funciona lo suficiente como para que formen parte de su estrategia. Éstos son algunos de los niveles de aislamiento que se usan en la actualidad y la protección que brindan. Asumiré apache, ya que eso es lo que es común. Aunque estos mismos principios se aplican con otro software de servidor.
Si no se realizan personalizaciones de seguridad, el servidor web ejecutará un solo usuario ("apache" o "nadie" o "www-data") compartido entre todos los sitios, mientras que los archivos serán propiedad de usuarios de FTP específicos. La intención es restringir qué tipo de acceso tiene el público (apache) asegurándose de que no tenga acceso de escritura a sus archivos. Desafortunadamente, esta disposición no es compatible con la mayoría de las aplicaciones web actuales que esperan que los usuarios puedan cargar archivos, incluido el código ejecutable, lo que permite que el sitio se actualice automáticamente, instale extensiones y otras tareas administrativas que se realicen a través del sitio.
En esta configuración, el código que se ejecuta en cualquier sitio tiene el mismo acceso a los archivos de otro sitio como lo haría ese sitio. Esta configuración conduce fácilmente a un compromiso para muchas aplicaciones web.
Con SuExec, las aplicaciones CGI se ejecutan bajo los permisos del propietario del sitio en lugar de usar los permisos propios de Apache. suPHP y suhosin también extienden este comportamiento a PHP (que tradicionalmente no se ejecuta como un ejecutable CGI). FastCGI, incluido fcgid, también suele proporcionar este mismo comportamiento.
Bajo este régimen, los archivos generalmente aún son legibles por la cuenta de usuario de Apache, pero solo se pueden escribir en la cuenta del propietario del sitio. Esto limita la mayoría de los tipos de movimientos laterales, pero aún permite un conjunto limitado de ataques.
Uno de esos ataques que he observado ocurre de tal manera que el atacante crea enlaces simbólicos a los archivos de configuración para otros sitios en el servidor, como por ejemplo:
/home/user1/public_html/foo.txt -> /home/user2/public_html/wp-config.php
El usuario luego busca ese archivo directamente y la configuración que contiene (incluidas las contraseñas de la base de datos) se muestra al atacante.
Un nuevo módulo experimental de Apache llamado mod_ruid2 por Kees Monshouwer ejecuta el proceso de apache bajo los permisos del usuario. Este módulo ahora está disponible en los servidores de cPanel, lo que significa que está bastante implementado en entornos de alojamiento compartido. Esto protege contra el ataque descrito anteriormente, pero no protege frente a permisos y administración inadecuados, vulnerabilidades de escalamiento de privilegios y otros problemas a nivel del sistema. Tampoco es compatible con una serie de características y extensiones comunes.
Es posible ejecutar el servidor bajo un régimen de aislamiento usando chroot y características similares (como cgroups) para ofrecer aislamiento y seguridad adicionales sin el costo de la virtualización. Sin embargo, esta opción tradicionalmente no se ha seguido muy lejos.
Sin dar a cada usuario su propio servidor, dar a cada usuario su propio servidor virtual es la mejor opción. Este es el núcleo del alojamiento "en la nube" y ofrece seguridad relativamente sólida, pero a un costo bastante alto.
Lea otras preguntas en las etiquetas webserver shared-hosting server