Hola, acabo de empezar mi prueba gratuita de 14 días y me gusta lo que veo. Tengo una pregunta sobre seguridad:
Solía usar un foro de “Simple Machines”, vinculado a mi sitio web, pero demostró ser un riesgo de seguridad masivo, ya que los spammers usaban el foro como una puerta trasera para acceder a mi sitio y luego colapsarlo.
Planeo usar una cuenta estándar de Discourse, alojada por Discourse (¿entiendo bien?).
¿Qué tipo de firewall existe entre el foro de Discourse y mi sitio web vinculado?
Discourse es utilizado por muchas grandes empresas tecnológicas
Es un sistema robusto. No puedes alojar un sitio de Discourse en Squarespace, será alojado por Discourse en sus servidores, eso es por lo que estás pagando y será una entidad separada.
Nuestro servidor físico fue hackeado hace unos años (99 % debido a un sitio antiguo de Confluence). Casi todo fue destruido excepto Discourse. Hemos tenido como 4 spammers en los últimos 10 años. Pero no somos famosos. He visto alrededor de 2 spammers en el propio Discourse Meta en los últimos 3 meses que llegaron a publicar algo en el foro. Considero que está construido a prueba de spam desde cero. Creo que es incluso la idea básica con la que empezaron.
Si las pesadillas provienen de la integración al incrustar un foro como sistema de comentarios en otro sitio, como WordPress [1], no puedo darte explicaciones técnicas, pero yo uso Discourse de esa manera, y muchos otros también lo hacen, sin problemas.
Si (y cuándo?) usas Discourse de forma independiente, como la mayoría, tu sitio principal es solo otro enlace dentro de Discourse. Entonces, la seguridad de ese sitio/servidor proviene de lo que sucede allí, por supuesto. Y la seguridad de Discourse alojado es un dolor de cabeza de CDCK, no tuyo.
Pero apuesto a que hay más instancias autoalojadas que las de CDCK, y de nuevo, otros pueden darte información más sólida, pero nunca he oído hablar de instancias de Discourse rotas o hackeadas.
No sé si los foros alojados tienen esa capacidad ↩︎
Squarespace es un creador de sitios alojado, no un lugar que alojaría un sitio de WordPress, pero tiene disposiciones para incrustar fuentes externas a través de bloques de código y bloques de incrustación.
No está claro a qué se refiere SamM específicamente con “los spammers usarían el foro como una puerta trasera para acceder a mi sitio y luego colapsarlo”. Los spammers no quieren colapsar el sitio, solo quieren inundarlo con anuncios basura y clickbait. Si eso es lo que sucedió, entonces tal vez Simple Machines carecía de las herramientas de Discourse para controlar el spam.
Pero la pregunta “¿Qué tipo de firewall existe entre el foro de Discourse y mi sitio web enlazado?” parece algo que se le debe preguntar a Squarespace. Advierten que la inyección de código puede causar problemas de visualización fuera de su control, pero no me imagino que una publicación de foro incrustada cause más daño que eso.
Esto está un poco fuera de tema, pero fue un problema real con WordPress hace algunos años. Los primeros ataques de spam funcionaron, pero debido a una debilidad bien conocida, cientos de otros siguieron, y ese servidor se bloqueó. O la misma debilidad fue explotada por script kiddies que intentaban secuestrar todo el sistema, y como en su mayoría eran simples copiones y pegadores, su código deficiente y falta de habilidades rompieron todo.
Una realidad es que solo una minoría de spammers trabajan como parásitos, mientras que la mayoría actúa más como bacterias o virus.
Esa no es la situación con Discourse. Pero supongo que tales situaciones están detrás de esa preocupación.
De hecho, hay muchas incógnitas. ¿El software del foro que usaron no tenía funciones reales de detección/contención de spam? Y, por supuesto, si se usa un creador de sitios, ¿qué funciones proporciona Squarespace?
Una respuesta completa a esta pregunta llenaría literalmente un libro sobre seguridad.
Pero te daré una respuesta mayormente completa aquí después de aclarar algunos puntos sobre lo que te sucedió:
Esto suena a que atacantes (no “spammers” - los spammers solo publicarían spam) pudieron explotar el foro Simple Machines y obtener acceso remoto a tu servidor en el que estaba alojado. Bloquear tu sitio solo impediría el acceso a él, en lugar de permitirles el acceso.
Presumiblemente, este servidor también alojaba otras cosas o contenía otros datos.
La mejor manera de pensar en esto es en términos de “radio de explosión”. En caso de que alguien obtuviera acceso de administrador indebido a tu foro, tendría acceso a todos los datos del foro.
En particular, información personal identificable (PII), pero también configuración u otros secretos de API. Por ejemplo, si otro servicio en tu dominio dependiera de este sitio para la autenticación, eso podría permitir a los atacantes pivotar a ese otro servicio.
En el peor de los casos, si un atacante obtuviera acceso a los servidores del backend (generalmente conocido como ejecución remota de código), el radio de explosión también incluiría todo lo accesible por la cuenta de usuario bajo la cual se ejecuta el servicio real. Varias protecciones para limitar ese radio de explosión, como la contenerización y la ejecución de servidores con credenciales no de administrador, también ayudan a limitar esa exposición.
En resumen, alojarse en un servicio administrado es lo más seguro para tu sitio, ya que somos responsables de la seguridad del sistema.