Alojamiento compartido. Es la opción barata, ¿no? Y para una gran parte de la población, es todo lo que necesitarán para alojar su sitio web o aplicación web. Y cuando se hace bien, el alojamiento compartido es escalable, rápido y seguro.
¿Pero qué sucede cuando no se hace bien?
Bueno, ahí es cuando comienzan a aparecer problemas de seguridad peligrosos. Es cuando su sitio corre el riesgo de ser borrado, o de que se filtren los datos privados que posee. Pero no te preocupes. La gran mayoría de los servidores web tienen medidas de seguridad decentes. Son solo los anfitriones de gangas y sótanos de ganga que debes desconfiar.
Vamos a explorar los problemas de seguridad que rodean el alojamiento compartido. Pero primero, hablemos sobre lo que hace que una plataforma de alojamiento compartido sea segura.
Lo que hace que un host web seguro
Hay algunas consideraciones de seguridad destacadas que deben hacerse con respecto al alojamiento compartido.
- Cada usuario en el servidor debe estar aislado de otros usuarios, y no debe poder acceder o modificar los archivos de otros usuarios.
- Una vulnerabilidad de seguridad en la lógica de un sitio web alojado en el servidor no debería afectar a otros usuarios.
- El servidor se revisa, actualiza y supervisa regularmente para solucionar los problemas de seguridad arquitectónicos.
- Cada usuario debe tener su propio acceso a la base de datos y no se le debe permitir realizar cambios en los registros almacenados o en los permisos de tabla de otros usuarios.
Una vez más, la mayoría de los servidores web cumplen estos requisitos para sus ofertas compartidas. Pero si está buscando alojar múltiples sitios web en un servidor, o tiene curiosidad por ver cómo se acumula su empresa de hosting, o incluso pensando en lanzar su propia empresa de hosting y está ansioso por encontrar la forma de proteger a sus usuarios, entonces lea en.
Pero primero, una exención de responsabilidad
Antes de entrar en la carne de mirar los ataques comunes dirigidos al alojamiento compartido, solo quiero decir que esta publicación no será (y no debe leerse como) una lista exhaustiva de posibles problemas de seguridad.
La seguridad es, en una palabra, grande. Hay muchas maneras de comprometer un sitio. Esto se duplica para el alojamiento compartido. Cubrirlos en un solo artículo nunca estuvo en las cartas.
Si está paranoico con respecto a su seguridad, obtenga un VPS o servidor dedicado. Estos son entornos en los que tiene (en su mayor parte) control absoluto sobre lo que sucede. Si no está seguro sobre los diferentes tipos de alojamiento web, consulte esta publicación. Explicación de las diversas formas de alojamiento de sitios web [Explicación de la tecnología] Explicación de las diversas formas de alojamiento de sitios web [Tecnología explicada] Lea más de mi colega, James Bruce.
También debo hacer hincapié en que esta publicación no debe interpretarse como un ataque al alojamiento compartido. Más bien, es una mirada puramente académica a los problemas de seguridad que rodean esta categoría de alojamiento web.
Recorrido del directorio
Comencemos con el recorrido de directorio (a menudo conocido como 'recorrido de ruta'). Este tipo de ataque le permite acceder a archivos y directorios que están almacenados fuera de la raíz web.
¿En inglés simple? Bueno, imaginemos que Alice y Bob usan el mismo servidor para alojar sus sitios web. Los archivos de Alice se almacenan en / var / www / alice, mientras que los documentos de Bob se pueden encontrar en / var / www / bob. Además, imaginemos que hay otra carpeta en el servidor (/ usr / crappyhosting / myfolder) que contiene un archivo de texto sin cifrar (lo llamaremos pwd.txt) que contiene las contraseñas y los nombres de usuario del sistema.
Conmigo hasta ahora? Bueno. Ahora, imaginemos que el sitio web de Bob sirve archivos PDF que se generan localmente, y el archivo local se referencia en la URL. Algo como:
http://example.com/file?=report.pdf
¿Qué pasaría si reemplazara el 'informe.pdf' con los parámetros de UNIX que cambian el directorio?
http://example.com/file?=../alice/
Si el servidor está configurado incorrectamente, esto le permitirá ver la raíz del documento de Alice. Interesante, pero estamos mucho más interesados en ese jugoso pasaporte. Contraseñas Accio !
http://example.com/file?=../../../usr/crappyhosting/myfolder/pwd.txt
Realmente es tan fácil como eso. Pero, ¿cómo lo enfrentamos? Eso es fácil.
¿Has oído hablar alguna vez de una utilidad Linux poco conocida llamada chroot ? Probablemente ya hayas adivinado lo que hace. Establece la raíz de Linux / UNIX en una carpeta arbitraria, por lo que es imposible que los usuarios salgan de ella. Efectivamente, detiene los ataques de cruce de directorios en sus pistas.
Es difícil saber si su anfitrión tiene esto en su lugar sin infringir la ley. Después de todo, para probarlo, estaría accediendo a sistemas y archivos a los que no tiene permiso de acceso. Con esto en mente, quizás sería sensato hablar con su proveedor de alojamiento web y preguntarle cómo aislar a sus usuarios el uno del otro.
¿Está operando su propio servidor de alojamiento compartido y no está utilizando chroot para proteger a sus usuarios? Es cierto que el enganche de tus entornos puede ser difícil. Afortunadamente, hay una gran cantidad de complementos que hacen que esto sea más fácil. Echa un vistazo a mod_chroot, en particular.
Inyección de comando
Volvamos a Alice y Bob. Entonces, sabemos que la aplicación web de Bob tiene algunos ... Ejem ... Problemas de seguridad. Una de ellas es la vulnerabilidad de inyección de comandos, que le permite ejecutar comandos de sistema arbitrarios. Una guía rápida para comenzar con la línea de comandos de Linux Una guía rápida para comenzar con la línea de comandos de Linux Puede hacer muchas cosas increíbles con comandos en Linux y realmente no es difícil de aprender. Lee mas .
El sitio web de Bob le permite ejecutar una consulta Whois en otro sitio web que luego se muestra en el navegador. Hay un cuadro de entrada HTML estándar que acepta un nombre de dominio y luego ejecuta el comando whois system. Este comando se ejecuta llamando al sistema () comando PHP.
¿Qué pasaría si alguien ingresa el siguiente valor?
example.com && cd ../alice/ && rm index.html
Bueno, vamos a descomponerlo. Algo de esto puede serle familiar si ha leído nuestra Guía de introducción a Linux Guía de introducción a Linux Guía de introducción a Linux ¡Una guía de introducción para principiantes de Linux! Probablemente hayas escuchado acerca de Linux, el sistema operativo de fuente abierta que ha estado presionando a Microsoft. Lea más e-book, que publicamos anteriormente en 2010, o ha echado un vistazo a nuestra hoja de comandos de línea de comandos de Linux.
En primer lugar, ejecutará una consulta whois en example.com. Luego cambiaría el directorio de trabajo actual a la raíz del documento de Alice. Luego eliminaría el archivo llamado 'index.html', que es la página de índice de su sitio web. Eso no es bueno. No señor.
Entonces, como administradores de sistemas, ¿cómo podemos mitigar esto? Bueno, volviendo al ejemplo anterior, siempre podemos poner a cada usuario en su propio entorno aislado, desinfectado y en chroot.
También podemos abordar esto desde un nivel de lenguaje. Es posible (aunque, esto puede romper cosas) eliminar globalmente las declaraciones de funciones de los idiomas. Es decir, es posible eliminar la funcionalidad de los idiomas a los que tienen acceso los usuarios.
Si mira PHP en particular, puede eliminar la funcionalidad con Runkit, el juego de herramientas oficial de PHP para modificar la funcionalidad del idioma. Hay una gran cantidad de documentación por ahí. Lea en ello.
También puede modificar el archivo de configuración de PHP (php.ini) para deshabilitar las funciones que los piratas informáticos suelen abusar. Para hacerlo, abra un terminal en su servidor y abra su archivo php.ini en un editor de texto. Disfruto usando VIM, pero NANO también es aceptable.
Encuentre la línea que comienza con disable_functions y agregue las definiciones de funciones que desea prohibir. En este caso, sería exec, shell_exec y el sistema, aunque vale la pena señalar que hay otras funciones incorporadas que son explotables por los hackers.
disable_functions = exec, shell_exec, sistema
Ataques basados en el lenguaje y el intérprete
Entonces, veamos PHP. Este es el lenguaje que impulsa una sorprendente cantidad de sitios web. También viene con una serie de idiosincrasias y comportamientos extraños. Me gusta esto.
PHP se usa generalmente junto con el servidor web Apache. En su mayor parte, es imposible cargar múltiples versiones del idioma con esta configuración.
¿Por qué es esto un problema? Bueno, imaginemos que la aplicación web de Bob se construyó originalmente en 2002. Eso fue hace mucho tiempo. Eso fue cuando Michelle Branch todavía estaba encabezando las listas, Michael Jordan seguía jugando para los Washington Wizards y PHP era un idioma muy diferente.
¡Pero el sitio web de Bob todavía funciona! Utiliza un montón de funciones de PHP descontinuadas y obsoletas, ¡pero funciona! El uso de una versión moderna de PHP rompería efectivamente el sitio web de Bob, y ¿por qué Bob debería reescribir su sitio web para satisfacer los caprichos de su proveedor de alojamiento web?
Esto debería darte una idea del dilema que enfrentan algunos servidores web. Deben mantener un equilibrio entre mantener un servicio arquitectónicamente sólido y seguro, y mantenerlo en armonía con garantizar que los clientes que pagan sean felices.
Como resultado, no es raro ver que los hosts más pequeños e independientes usan versiones anteriores del intérprete de PHP (o de cualquier idioma, para el caso).
No es raro ver que los hosts más pequeños e independientes usan versiones anteriores de PHP, lo que puede exponer a los usuarios a riesgos de seguridad.
¿Por qué es esto algo malo? Bueno, en primer lugar, expondría a los usuarios a una serie de riesgos de seguridad. Al igual que la mayoría de los principales paquetes de software, PHP se actualiza constantemente para hacer frente a la gran cantidad de vulnerabilidades de seguridad que constantemente se están descubriendo (y divulgando).
Además, significa que los usuarios no pueden usar las últimas (y mejores) funciones de lenguaje. También significa que las funciones que han quedado obsoletas por algún motivo permanecen. En el caso del lenguaje de programación PHP, esto incluye las funciones mysql_ ridículamente terribles (y recientemente obsoletas) que se utilizan para interactuar con el sistema de base de datos relacional MySQL, y dl (), que permite a los usuarios importar sus propias extensiones de idioma.
Como usuario, debería poder ver qué versión de un intérprete se está ejecutando en su servicio. Si está desactualizado o contiene varias vulnerabilidades de seguridad, comuníquese con su host.
¿Qué hay de los administradores de sistemas? Aquí tienes algunas opciones. El primero (y el más prometedor) es utilizar Docker para cada uno de sus usuarios. Docker le permite ejecutar múltiples entornos aislados al mismo tiempo, al igual que lo hace una máquina virtual, aunque sin tener que ejecutar otro sistema operativo. Como resultado, esto es rápido. Realmente, muy rápido.
¿En inglés simple? Puede ejecutar el intérprete de última generación más avanzado para la mayoría de sus usuarios, mientras que los clientes que utilizan aplicaciones antiguas que usan intérpretes antiguos y obsoletos lo hacen sin comprometer a otros usuarios.
Esto también tiene la ventaja de ser independiente del idioma. PHP, Python, Ruby. Lo que sea. Todo es lo mismo.
No tengas pesadillas.
Esta publicación tenía la intención de hacer un par de cosas. En primer lugar, fue para llamar su atención la cantidad de problemas de seguridad que las empresas de alojamiento web deben enfrentar para garantizar la seguridad de sus clientes y sus datos.
También se intentó mostrar cómo los sitios alojados en el mismo servidor pueden afectarse entre sí. ¿Quieres hacer mella en esto? Comience a obedecer estándares de codificación buenos y seguros. En particular, comience a desinfectar sus entradas tanto en el front-end como en el back-end.
Un buen comienzo es con la nueva funcionalidad de validación de formularios HTML5. Ya hemos hablado de esto en nuestra guía HTML5. Colectivamente, podemos hacer que los sitios web sean más seguros siendo mejores y más concienzudos programadores.
Como siempre, estoy dispuesto a escuchar tus pensamientos. Déjame un comentario a continuación.
Crédito de la foto: Todo el mundo necesita un pirata informático (Alexandre Dulaunoy), Pegatina en la ventana de taxi (Cory Doctorow), Sala de servidores (Torkild Retvedt), Libros y revistas de Linux (library_mistress), Elefante PHP (Markus Tacker)