¿Tienes alojamiento compartido y te preocupa la seguridad? Esto es lo que necesitas saber

Anuncio

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. Ahí es cuando su sitio está en riesgo de ser desfigurado, o los datos privados que tiene se filtran. Pero no te preocupes. La gran mayoría de los servidores web tienen medidas de seguridad decentes. Solo debes tener cuidado con los anfitriones que vuelan de noche y en el sótano de gangas.

Nosotros recomendamos El alojamiento compartido de InMotion Hosting con almacenamiento SSD.

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 servidor 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 poder afectar a otros usuarios.
• El servidor se revisa, actualiza y supervisa periódicamente para abordar problemas de seguridad arquitectónica.
• Cada usuario debe tener su propio acceso a la base de datos aislada, y no se le debe permitir realizar cambios en los registros almacenados o permisos de tabla de otros usuarios.

Nuevamente, la mayoría de los servidores web cumplen con estos requisitos para sus ofertas compartidas. Pero si está buscando alojar varios sitios web en un servidor, o tiene curiosidad por ver cómo se compara su empresa de alojamiento, o incluso si está pensando en lanzar su propia empresa de hosting y está ansioso por descubrir cómo proteger a sus usuarios, entonces lea en.

Pero primero, un descargo de responsabilidad

Antes de entrar en la carne de mirar ataques comunes dirigidos a un alojamiento compartido, solo quiero declare que esta publicación no será (y no debe leerse como) una lista exhaustiva de seguridad potencial cuestiones.

La seguridad es, en una palabra, grande. Hay muchas formas de comprometer un sitio. Esto va doble para el alojamiento compartido. Cubrirlos en un solo artículo nunca estuvo en las cartas.

Si está paranoico acerca de su seguridad, obtenga un VPS o un servidor dedicado. Estos son entornos en los que tiene (en su mayor parte) un control absoluto sobre lo que sucede. Si no está seguro acerca de los diferentes tipos de alojamiento web, mira esta publicación Las diversas formas de alojamiento de sitios web explicadas [Tecnología explicada] Lee mas de mi colega, James Bruce.

También debo enfatizar 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 los ataques de recorrido de directorio (a menudo conocidos 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, supongamos que hay otra carpeta en el servidor (/ usr / crappyhosting / myfolder) que contiene un archivo de texto sin cifrar (lo llamaremos pwd.txt) que contiene los nombres de usuario del sistema y contraseñas

Conmigo hasta ahora? Bueno. Ahora, imaginemos que el sitio web de Bob sirve archivos PDF que se generan localmente, y el archivo local está referenciado en la URL. Algo como:

http://example.com/file?=report.pdf

¿Qué pasaría si reemplazara el "informe.pdf" con algunos 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 archivo de pasaportes. Contraseñas Accio!

http://example.com/file?=../../../usr/crappyhosting/myfolder/pwd.txt

Realmente es tan fácil como eso. Pero, ¿cómo lidiamos con eso? Eso es fácil.

Alguna vez has oído hablar de una utilidad de Linux poco conocida llamada chroot? Probablemente ya hayas adivinado lo que hace. Establece la raíz de Linux / UNIX en una carpeta arbitraria, lo que hace que sea imposible para los usuarios salir de ella. Efectivamente, detiene los ataques transversales de directorio en sus pistas.

Es difícil saber si su host tiene esto en su lugar sin violar la ley. Después de todo, para probarlo, estaría accediendo a sistemas y archivos a los que no tiene permiso de acceso. Con eso en mente, quizás sería sensato hablar con su proveedor de alojamiento web y preguntarle cómo aislan a sus usuarios unos de otros.

¿Está operando su propio servidor de alojamiento compartido y no está usando chroot para proteger a sus usuarios? Es cierto que modificar sus entornos puede ser difícil. Afortunadamente, hay una gran cantidad de complementos que facilitan esta tarea. Echa un vistazo a mod_chroot, en particular.

Inyección de comandos

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 arbitrarios del sistema Una guía rápida para comenzar con la línea de comandos de LinuxPuedes 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 del sistema whois. Este comando se ejecuta llamando al comando system () PHP.

¿Qué pasaría si alguien ingresara el siguiente valor?

ejemplo.com && cd ../alice/ && rm index.html

Bueno, vamos a desglosarlo. Algo de esto puede resultarle familiar si ha leído nuestro "Guía de inicio de Linux" Comenzando con Linux y UbuntuEstás interesado en cambiar a Linux... pero por donde empiezas ¿Es compatible tu PC? ¿Funcionarán tus aplicaciones favoritas? Aquí está todo lo que necesita saber para comenzar con Linux. Lee mas e-book, que publicamos anteriormente en 2010, o hemos revisado nuestro Hoja de trucos de la 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 del sistema, ¿cómo mitigamos esto? Bueno, volviendo al ejemplo anterior, siempre podemos poner a cada usuario en su propio entorno aislado, desinfectado y desorganizado.

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 los usuarios tienen acceso.

Si observa PHP en particular, puede eliminar la funcionalidad con Runkit, el kit de herramientas oficial de PHP para modificar la funcionalidad del lenguaje. Hay una gran cantidad de documentación por ahí. Léelo.

También puede modificar el archivo de configuración de PHP (php.ini) para deshabilitar funciones que los hackers a menudo abusan de ellas. Para hacer eso, abra una 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 system, aunque vale la pena señalar que hay otras funciones integradas que los hackers pueden explotar.

disable_functions = exec, shell_exec, sistema

Ataques basados ​​en lenguaje e intérpretes

Entonces, veamos PHP. Este es el lenguaje que impulsa un sorprendente número de sitios web. También viene con una serie de idiosincrasias y comportamientos extraños. Me gusta esto.

PHP generalmente se usa junto con el servidor web Apache. En su mayor parte, es imposible cargar varias versiones del idioma con esta configuración.

¿Por qué es esto un problema? Bueno, imaginemos que la aplicación web de Bob se creó originalmente en 2002. Eso fue hace mucho tiempo. Eso fue cuando Michelle Branch todavía estaba encabezando las listas, Michael Jordan todavía jugaba para los Washington Wizards y PHP era un lenguaje muy diferente.

¡Pero el sitio web de Bob sigue funcionando! Utiliza un montón de funciones PHP descontinuadas y en desuso, ¡pero funciona! El uso de una versión moderna de PHP efectivamente rompería 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 darle una idea del dilema que enfrentan algunos servidores web. Deben equilibrar el mantenimiento de un servicio arquitectónico sólido y seguro, mientras lo mantienen en armonía con garantizar que los clientes que pagan estén contentos.

Como resultado, no es raro ver que los hosts más pequeños e independientes usen versiones anteriores del intérprete PHP (o cualquier otro lenguaje).

No es raro ver hosts más pequeños e independientes que usan versiones anteriores de PHP, exponiendo potencialmente 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. Como la mayoría de los paquetes de software principales, PHP se actualiza constantemente para abordar la gran cantidad de vulnerabilidades de seguridad que se descubren (y divulgan) constantemente.

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 en desuso por alguna razón permanecen. En el caso de la Lenguaje de programación PHP Aprenda a construir con PHP: un curso intensivoPHP es el lenguaje que usan Facebook y Wikipedia para atender miles de millones de solicitudes diarias; El lenguaje de facto utilizado para enseñar a la gente la programación web. Es maravillosamente simple, pero brillantemente poderoso. Lee mas , esto incluye las ridículas funciones terribles (y recientemente desaprobadas) mysql_ que se utilizan para interactuar con el sistema de base de datos relacional MySQL y dl (), que permite a los usuarios importar su propio idioma extensiones

Como usuario, debería poder ver qué versión de un intérprete se está ejecutando en su servicio. Si está desactualizado o contiene una serie de vulnerabilidades de seguridad, comuníquese con su host.

¿Qué pasa con los administradores de sistemas? Tienes algunas opciones aquí. El primero (y el más prometedor) es usar Docker para cada uno de sus usuarios. Docker le permite ejecutar múltiples entornos aislados al mismo tiempo, al igual que una máquina virtual, aunque sin tener que ejecutar otro sistema operativo. Como resultado, esto es rápido. Muy, muy rápido.

¿En inglés simple? Puede ejecutar el mejor y más reciente intérprete de vanguardia para la mayoría de sus usuarios, mientras que los clientes que utilizan aplicaciones antiguas que utilizan intérpretes antiguos y obsoletos para hacerlo sin comprometer a otros usuarios.

Esto también tiene la ventaja de ser independiente del lenguaje. 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 sobre 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 tenía la intención de mostrarle 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 sobre esto en nuestra guía HTML5. Colectivamente, podemos hacer que los sitios web sean más seguros siendo mejores programadores y más conscientes.

Como siempre, estoy dispuesto a escuchar tus pensamientos. Déjame un comentario a continuación.

Autor de la foto: Todo el mundo necesita un hacker (Alexandre Dulaunoy), Pegatina en la ventana del taxi (Cory Doctorow), Sala de servidores (Torkild Retvedt), Libros y revistas de Linux (biblioteca_mistress), Elefante PHP (Markus Tacker)