¿Una solución de alojamiento resistente a los piratas para organizaciones sin fines de lucro?

47

(Mientras que las respuestas y los comentarios se encuentran en Cómo trato ¿son útiles un servidor comprometido? , mi pregunta es más sobre la prevención de piratería cuando no tengo control total (o mucho) sobre el servidor. Tengo acceso a SSH pero no privilegios de root. No puedo ver ni cambiar nada más allá de mi propia cuenta de usuario.)

Soy voluntario para una organización sin fines de lucro, manteniendo su sitio web para ellos. Hemos estado en una plataforma de alojamiento compartido de bajo presupuesto (Bluehost) durante varios años. El sitio se creó en Wordpress e hice todo lo posible para mantener el núcleo WP y todos los complementos actualizados.

Pero nos hackearon varias veces. A veces era malicioso (desfiguraba la página de inicio) mientras que otras veces era sigiloso (descubrí archivos ocultos que parecían permitir que alguien entrara y husmeara).

Me deshice totalmente de WP, reconstruyendo el sitio en Bootstrap. Eliminé todos los archivos todos del servidor, realicé varias exploraciones de virus en la versión local del nuevo sitio, revisé cualquier cosa sospechosa y luego subí los archivos al servidor. Estaba casi 100% seguro de que este nuevo código estaba "limpio".

Pero dentro de unos días, descubrí (comparando el servidor con mi versión local) un index.php pirateado (se insertó algo de código 'preg-replace' antes de la primera línea) y encontré un "logo-small.png "archivo en un subdirectorio que no era realmente un archivo de imagen. Era un gran trozo de PHP ofuscado que parecía estar preparado para cosas desagradables (me quité la imagen y vi el código).

Sabía que los hosts compartidos, a menudo con cientos de sitios, podrían ser vulnerables. En este punto, desconfío totalmente del servidor en el que estamos. Pero cuando le pregunté a Bluehost si estaríamos más seguros en un VPS o en un servidor dedicado (pensando que nuestra "caja de arena" sería más difícil), dijeron que realmente no haría una diferencia.

Así que estoy en un dilema. La organización sin fines de lucro que ayudo tiene un presupuesto limitado. Pero tampoco quiero seguir gastando de diez a cientos de horas monitoreando y arreglando el sitio. No sé si los hackers están ingresando a través del sistema de archivos o un puerto abierto que no debería estar abierto.

¿Existe una solución rentable que ofrezca un "endurecimiento" mucho mejor?

    
pregunta user249493 09.03.2016 - 03:49
fuente

9 respuestas

61

Si lo único que expone a Internet son las páginas web no interactivas y no necesita ejecutar componentes del lado del servidor, entonces puede reducir sustancialmente sus riesgos utilizando un sitio web estático .

Luego te quedas con el motor web en sí y, en cierta medida, se extiende el sistema operativo subyacente. Apache o nginx no son fáciles de endurecer, por lo que podría echar un vistazo a Cherokee o publicfile .

Puede ir un paso más allá al alojar sus archivos estáticos en un entorno existente que los acepta ( Github Pages , por ejemplo) o muévase a un sitio que cree con bloques como Google Sites (que son gratis para organizaciones sin ánimo de lucro

    
respondido por el WoJ 09.03.2016 - 08:33
fuente
21

El problema con el alojamiento compartido es que:

  1. Dependes de que todos los sitios web mantengan su código actualizado. Podría ser posible que se comprometa otra cuenta que le permita a un atacante acceder a su parte del servidor web. Hay varias formas de lograr esto, especialmente si se instala un panel de control como Direct Admin.

  2. Cuando, como hacker, compro espacio web en el mismo servidor en el que está, simplemente podría (en su caso) cargar un shell web PHP y (posiblemente) acceder a todos los sitios web ubicados en ese servidor. Esto es posible incluso si los permisos de los archivos se configuran correctamente.

La solución no es utilizar alojamiento web compartido.

Le sugiero que compre un VPS. Se puede comprar un buen VPS (6 GB de RAM - discos SSD) por $ 7 al mes. Podría darle el enlace si lo desea, pero no quiero anunciarlo aquí. De esa manera, tendrás más control de lo que está sucediendo.

    
respondido por el Jeroen - IT Nerdbox 09.03.2016 - 06:04
fuente
9

Mover a un sistema de páginas estáticas. Yo también solía tener WordPress, pero después de ser hackeado 2 veces por el "Ejército Sirio Libre" (en un esfuerzo por promover su situación ...) me harté de Wordpress y usé Nikola .

Sencillo y fácil: páginas web estáticas ... sin cuentas / puertos / vulnerabilidades de SQL, etc.

Hay otros (bifurcaciones de la misma) - busca también a Pelican.

    
respondido por el Tim Seed 09.03.2016 - 16:38
fuente
8

Digital Ocean ofrece máquinas virtuales dedicadas por tan solo $ 5 / mes. Esto sería comparable a un servidor dedicado en términos de comparación de la solución con VPS.

Sin embargo, el problema suele ser que su solución de software se use en la entrega real de contenido. El endurecimiento de los archivos de configuración de la suite elegida no es trivial a menos que tenga experiencia con ese tipo de cosas.

El endurecimiento del servidor como un tema general es enorme, pero si ha cubierto un conjunto particular de programas que desea utilizar, es muy probable que Google y ServerFault.SE tengan muchos consejos sobre cómo bloquearlos.

O como sugiere WoJ, puedes usar una solución de alojamiento más preconstruida.

    
respondido por el Vegard 09.03.2016 - 11:29
fuente
5

Como regla general, no es el host el que se piratea, es su sitio. Si tienes un sitio seguro, entonces un simple VPS puede mantenerte seguro.

Suponiendo que no necesita que su contenido responda de manera diferente a diferentes visitantes, entonces un generador de sitio estático funcionará para usted. Por lo general, son un poco como wordpress, ya que escribes tu propio contenido personalizado y se convierte en un sitio temático, pero es diferente en que el generador vive en tu computadora (no en el servidor web) y lo único en el servidor es HTML estático.

Así que no hay nada que hackear. No esta vivo El servidor no puede hacer nada. Es solo contenido.

Si desea poner eso en su propio VPS, puede obtener uno en Linode o Digital Ocean, o si se siente valiente, AWS o Google Compute. El servidor de nivel más bajo en todos estos lugares es de alrededor de $ 5 / mes, lo cual es suficiente para sus necesidades.

Incluso puedes alojar un sitio de este tipo en Github Pages sin costo alguno.

    
respondido por el tylerl 11.03.2016 - 03:14
fuente
4

Si ya tiene experiencia con Wordpress, entonces, ¿por qué no usar simplemente la nube de wordpress.com? Con suerte, ellos se encargarán de la administración del sistema, incluida la seguridad. Solo necesita mantener la contraseña segura y exportar / respaldar sus publicaciones regularmente. Por supuesto, estás a merced de la empresa, una vez se bloqueó mi blog, pero logré convencerlos de que lo abrieran de nuevo. Además, posiblemente no todos los complementos que necesitas puedan estar allí. También podría haber problemas de privacidad, el problema del nombre de dominio de su organización sin fines de lucro y los anuncios que wordpress.com podría colocar en su página de inicio.

    
respondido por el Finn Årup Nielsen 10.03.2016 - 11:35
fuente
2

Hay un montón de buenos consejos en las respuestas. Sin embargo, posiblemente el consejo más importante es utilizar solo una empresa de hosting con buena reputación. No base su decisión en el costo y vaya a un sitio de presupuesto basado únicamente en ese criterio.

La realidad es que la gestión de una empresa de alojamiento conlleva gastos generales de mantenimiento considerables. Para lograr ganancias suficientes, los recortes deben hacerse en algún lugar. Desafortunadamente, estos recortes a menudo se aplican a los procesos de administración de riesgos porque no hay una relación obvia de 1 a 1 entre el gasto y los ingresos. El resultado es que la seguridad a menudo sufre.

Las organizaciones más grandes en las que se considera que la reutilización es un aspecto importante de su rentabilidad probablemente gastarán más en estas áreas. También tienen el beneficio de poder aprovechar las economías de escala. Si no está en la posición de administrar los riesgos de seguridad usted mismo, debe confiar en su empresa de alojamiento.

Varias respuestas sugirieron usar un sitio estático en lugar de wordpress. Un sitio estático puede ayudar, pero, por supuesto, si el servidor está comprometido, hay poca diferencia. Sin embargo, los marcos dinámicos mal mantenidos que no se actualizan serán siempre más riesgosos que un sitio estático dada la misma seguridad de alojamiento.

Wordpress es una solución de alto riesgo. Está enfocado activamente y hay una serie de debilidades en el sistema de complementos. Incluso si mantiene los complementos actualizados, no hay garantía. Solo esta semana hubo un informe de un popular complemento que tiene importantes agujeros de seguridad que han sido agregados deliberadamente por el nuevo mantenedor del complemento (este es un problema común con las arquitecturas de complementos: los complementos de Chrome tienen el mismo problema. Busca algunos funcionalidad. Es consciente de la seguridad, por lo que comprueba las referencias, la reputación y los informes de usuario de un complemento. Todo se ve bien y el desarrollador tiene una buena reputación, por lo que lo instala. Más tarde, el desarrollador sigue adelante, ya sea vendiendo el complemento o entregando Puede ser que no sea tan ético. No existe un mecanismo para avisarle de este cambio. El nuevo propietario emite una actualización que tiene un código malicioso. Usted aplica la actualización (o quizás la actualización se aplica automáticamente). ).

Si simplemente no puede usar un sitio estático, quizás considere usar otra cosa que no sea wordpress, que no está orientada activamente. Esto no será conveniente ya que probablemente significará aprender un nuevo marco, pero puede proporcionar alguna protección adicional.

La otra cosa a considerar seriamente, especialmente si simplemente no hay suficiente presupuesto es volver a vender su reputación web sin fines de lucro. Hay un costo asociado con tener una presencia en la web. Si la organización sin fines de lucro no puede pagar el costo de un sitio lo suficientemente seguro, debe aceptar el riesgo de ser pirateado o debe reducir su presencia en la web a algo que estén dispuestos a financiar. En general, hay pocas soluciones de seguridad 'baratas': usted obtiene lo que paga (puede pagar de más - especialmente con algunos de los comerciantes de aceite de serpiente que se sienten atraídos por el espacio de seguridad lucrativo, pero si investiga, busque buenas referencias) / árbitros, recuerde que no existe tal cosa como un almuerzo gratis y si suena demasiado bueno para ser verdad, probablemente no lo sea, bla bla bla, generalmente estará bien).

    
respondido por el Tim X 11.03.2016 - 02:26
fuente
2

Seguridad de la computadora personal

Según el formulario de comentarios AL , la vulnerabilidad puede no tener nada que ver con su sitio web o el alojamiento, pero más que ver con el robo de contraseñas de una computadora de administradores de sitios web comprometidos o similar o tal vez el atacante tiene control sobre una cuenta administrativa que no se ha restablecido desde la limpieza inicial.

Deshazte de WordPress contra la actualización a un mejor host

Alejarse de WordPress puede ayudar, pero encontrar un host con mejores prácticas de seguridad puede ser una solución más efectiva.

Cuido de unos 50 sitios web creados con un CMS similar a WordPress y soy muy consciente de la aplicación regular de actualizaciones. Los sitios en hosts de buena calidad (por ejemplo, SiteGround) rara vez son hackeados. SiteGround actualiza regularmente el firewall de su aplicación web para bloquear las vulnerabilidades más comunes de WordPress, Joomla y otras, aunque aún debe actualizar rápidamente su CMS y cualquier complemento de terceros a medida que se publiquen las actualizaciones.

Alojamiento compartido vs VPS

Pasar a un VPS puede reducir el riesgo de contaminación de otras cuentas en el mismo servidor, pero la seguridad de un VPS se basa en las habilidades de la persona que lo mantiene, al igual que en el alojamiento compartido.

Es menos probable que una cuenta de alojamiento compartido en un servidor bien mantenido sea hackeada que un VPS mal mantenido.

Precauciones de seguridad de Common Sense

Hagas lo que hagas, nada en la web es 100% seguro. Puede minimizar el riesgo de pérdida de datos ejecutando copias de seguridad regulares, copiando las copias de seguridad fuera del sitio y probando las copias de seguridad periódicamente.

Obtenga información sobre otras precauciones de seguridad de sentido común, como:

  • aplicando actualizaciones regularmente
  • manteniendo la versión de PHP actualizada,
  • elegir software solo de desarrolladores establecidos y confiables
  • minimizar el número de complementos cuando sea posible
  • minimizar el número de cuentas administrativas
  • implementar un servidor de seguridad de aplicación web para proteger el sitio web y / o habilitar una red de entrega de contenido (CDN) que incluya un servidor de seguridad de aplicación web

En conclusión

Yo diría que la solución más rentable en su caso, donde tiene un cliente preocupado por su presupuesto, es una solución de alojamiento compartido con un proveedor de alojamiento de buena calidad.

    
respondido por el Neil Robertson 11.03.2016 - 12:30
fuente
2

En primer lugar, debo señalar que no estoy de acuerdo con la premisa sobre ser vulnerable solo por estar en un host compartido. Si su cuenta de alojamiento compartido está comprometida por otro usuario, es porque:

  • La empresa de alojamiento no aisló correctamente a los usuarios
  • El usuario hizo algo tonto (como tener 777 archivos)

Con un VPS, el aislamiento lo proporciona una capa diferente, que es más difícil de superar. Y aún más con un servidor dedicado. Por lo tanto, no estoy de acuerdo con la respuesta que te dio Bluehost.

Sin embargo , si el compromiso se originó en su cuenta (por ejemplo, un complemento vulnerable de wordpress), entonces no importará la opción de alojamiento que use.

Ciertamente, su archivo logo-small.png parece como si se hubiera cargado a través de su aplicación.

En cuanto a la detección de compromisos, recomiendo mantener el archivo en el control de versiones. Es fácil hacer un script que rsync su sitio web y se comprometa, por ejemplo, a. un repositorio git.

Esto sirve como copia de seguridad y también resalta muy claramente las diferencias cuando se modifican los archivos.

Varias respuestas promueven el uso de archivos estáticos. Si los archivos no cambian de forma remota, y asumiendo que usted es el único que cambia las páginas web (o que se cambian en la misma computadora "maestra") un simple rsync -avz --delete website/ the-server: regresaría a la versión "limpia", si surgiera tal compromiso. Incluso se puede sincronizar automáticamente de esa manera "por si acaso", aunque si el sitio web es de alguna manera vulnerable, la restauración automática de la copia de seguridad, aunque sea efectiva en el tiempo, no es una solución real.

    
respondido por el Ángel 03.07.2016 - 01:21
fuente

Lea otras preguntas en las etiquetas