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

Alojamiento compartido. Es la opción barata, ¿no? Y para una gran franja 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 que pasa cuando no se hace bien.?

Bueno, ahí es cuando comienzan a surgir problemas de seguridad peligrosos. Ahí es cuando su sitio corre el riesgo de sufrir daños o se filtran los datos privados que posee. Pero no se preocupe. La gran mayoría de los servidores web tienen medidas de seguridad decentes. Solo tienes que ser cauteloso con los anfitriones del sótano de ganga por la noche..

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 de 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 es parcheado, actualizado y monitoreado regularmente para abordar problemas de seguridad de arquitectura.
• Cada usuario debe tener su propio acceso a la base de datos aislado, y no se le debe permitir hacer cambios a los registros almacenados o permisos de mesa de otros usuarios.

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

Pero primero, un descargo de responsabilidad

Antes de que comencemos a analizar los ataques comunes dirigidos a un alojamiento compartido, solo quiero decir que esta publicación no será (y no debe leerse) una lista exhaustiva de posibles problemas de seguridad..

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

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) control absoluto sobre lo que sucede. Si no está seguro acerca de 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 [Explicación de la tecnología] Lea más sobre mi colega, James Bruce.

También debo recalcar que esta publicación no debe interpretarse como un ataque al alojamiento compartido. Más bien, es un aspecto puramente académico de los problemas de seguridad que rodean a esta categoría de alojamiento web.

Directorio transversal

Comencemos con los ataques de cruce de directorios (a menudo conocidos como "recorrido de ruta"). Este tipo de ataque le permite acceder a archivos y directorios que se almacenan 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 encuentran en / var / www / bob. Además, supongamos que hay otra carpeta en el servidor (/ usr / crappyhosting / myfolder) que contiene un archivo de texto simple sin cifrar (lo llamaremos pwd.txt) que contiene nombres de usuario y contraseñas del sistema.

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

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

¿Qué pasaría si reemplazara el 'report.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ía ver la raíz del documento de Alice. Interesante, pero estamos mucho más interesados ​​en ese jugoso archivo de pasaportes.. Contraseñas de 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.

¿Has oído hablar de una utilidad de Linux poco conocida llamada chroot? Probablemente ya has adivinado lo que hace. Establece la raíz de Linux / UNIX en una carpeta arbitraria, lo que hace imposible que los usuarios salgan de ella. Efectivamente, detiene los ataques transversales 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 para acceder. Teniendo esto en cuenta, quizás sería sensato hablar con su proveedor de alojamiento web y preguntar cómo aislan a sus usuarios entre sí..

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

Inyeccion de Comando

Volvamos con Alice y Bob. Por lo tanto, 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 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 de 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 PHP del sistema ().

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

example.com && cd… / alice / && rm index.html

Bueno, vamos a descomponerlo. Algo de esto puede resultarle 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 a Linux de Newbie! Probablemente hayas oído hablar de Linux, el sistema operativo de código abierto y gratuito que ha estado luchando contra Microsoft. Lea más e-book, que publicamos anteriormente en 2010, o echó un vistazo a nuestra hoja de trucos de Linux Command Line.

En primer lugar, ejecutará una consulta de 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 mitigamos esto? Bueno, volviendo al ejemplo anterior, siempre podemos poner a cada usuario en su propio entorno aislado, desinfectado y enjaulado..

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..

Mirando a PHP en particular, puede eliminar la funcionalidad con Runkit, el kit de herramientas oficial de PHP para modificar la funcionalidad del idioma. Hay una gran cantidad de documentación por ahí. Leerlo.

También puede modificar el archivo de configuración de PHP (php.ini) para deshabilitar las funciones que los hackers abusan a menudo. Para hacerlo, abra un terminal en su servidor y abra su archivo php.ini en un editor de texto. Me gusta usar 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 sistema, aunque vale la pena señalar que existen otras funciones integradas que pueden ser explotadas por piratas informáticos..

disable_functions = exec, shell_exec, sistema

Ataques basados ​​en intérpretes y lenguaje

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

PHP se usa generalmente en conjunto 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 construyó originalmente en 2002. Eso fue hace mucho tiempo. Eso fue cuando Michelle Branch todavía estaba en la cima de las listas, Michael Jordan seguía jugando para los Washington Wizards y PHP era un lenguaje muy diferente.

¡Pero el sitio web de Bob todavía funciona! Utiliza un montón de funciones de PHP descontinuadas y en desuso, ¡pero funciona! Usar una versión moderna de PHP efectivamente rompería el sitio web de Bob, y ¿por qué Bob debería volver a escribir su sitio web para satisfacer los caprichos de su proveedor de alojamiento web?

Esto debería darle una idea del dilema que enfrentan algunos anfitriones web. Deben mantener un servicio seguro y arquitectónicamente equilibrado, al mismo tiempo que se mantienen en armonía con la garantía de que los clientes que pagan están contentos..

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

No es raro que los hosts más pequeños e independientes usen versiones anteriores de PHP, lo que potencialmente expone 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 paquetes de software, PHP se actualiza constantemente para abordar la gran cantidad de vulnerabilidades de seguridad que se descubren (y revelan) constantemente.

Además, significa que los usuarios no pueden usar las funciones de lenguaje más recientes (y las mejores). También significa que las funciones que han sido desaprobadas por una razón permanecen. En el caso del lenguaje de programación PHP, esto incluye las funciones mysql_ ridículamente terribles (y recientemente desaprobadas) que se utilizan para interactuar con el Sistema de base de datos relacional de 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 está ejecutando en su servicio. Si está desactualizado o contiene varias 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 utilizar Docker para cada uno de sus usuarios. Docker le permite ejecutar múltiples entornos aislados al mismo tiempo, como lo hace una máquina virtual, aunque sin tener que ejecutar otro sistema operativo. Como resultado, esto es rápido. Realmente rapido.

¿En inglés simple? Puede ejecutar el último y mejor intérprete para la mayoría de sus usuarios, mientras que los clientes que utilizan aplicaciones antiguas que utilizan intérpretes antiguos y en desuso lo hacen sin comprometer a otros usuarios..

Esto también tiene la ventaja de ser un lenguaje agnóstico. PHP, Python, Ruby. Lo que sea. Todo es lo mismo.

No tengas pesadillas.

Este post estaba destinado a hacer un par de cosas. En primer lugar, fue para llamar la atención sobre la cantidad de problemas de seguridad que deben enfrentar las empresas de alojamiento web para garantizar la seguridad de sus clientes y sus datos..

También fue pensado para mostrarle cómo los sitios alojados en el mismo servidor pueden afectarse entre sí. ¿Quieres hacer un hueco en esto? Comience a obedecer las normas de codificación buenas y seguras. En particular, comience a limpiar sus entradas tanto en la parte delantera como en la parte posterior.

Un buen comienzo es con la nueva funcionalidad de validación de formularios HTML5. Hemos hablado de esto antes en nuestra guía de HTML5. En conjunto, podemos hacer que los sitios web sean más seguros siendo programadores mejores y más conscientes..

Como siempre, estoy dispuesto a escuchar tus pensamientos. Déjame un comentario abajo.

Crédito de la foto: Todos necesitan un pirata informático (Alexandre Dulaunoy), pegatina en la ventana del taxi (Cory Doctorow), sala de servidores (Torkild Retvedt), libros y revistas de Linux (library_mistress), PHP Elephant (Markus Tacker)

Explorar más sobre: ​​seguridad en línea, alojamiento web.