Mi sitio web utiliza Discourse. Inicialmente, no estaba protegido por Cloudflare y sufrió un ataque DDoS.
Posteriormente, cambié la dirección IP e implementé Cloudflare. Sin embargo, el sitio web fue atacado nuevamente por DDoS, aparentemente debido a una fuga de la IP del servidor de origen.
Al utilizar Cloudflare CDN, ¿cómo podemos evitar que se filtre la IP del servidor de origen? ¿Alguien tiene algún buen método? Gracias.
No lo sé, pero la IP de todos los servidores en línea se filtrará al mismo tiempo que se crea.
Puedes evitar muchas fugas haciendo lo siguiente
HTTPS_PROXY y HTTP_PROXY para que Discourse la utilice (establecerlas en la sección env de tu app.yml)NO_PROXY='127.0.0.1, localhost, <red-interna>'Ver también Install discourse with internet access only via proxy, Configuration outbound proxy y Discourse Link previews through a proxy server? - #14 by supermathie
Además, cuando estés detrás de CF, puedes modificar el firewall de tu host de Discourse para que solo permita el tráfico entrante desde tus IPs de Cloudflare (y el host desde el que accedes tú mismo).
Esta es la solución. La seguridad por ocultación no es segura. Entonces no importará si tu IP es de conocimiento común.
Esto o, alternativamente, un enfoque más simple sería usar lo que se llama un túnel de Cloudflare. Debería ser una configuración única y luego debería poder cerrar en gran medida su firewall para las conexiones entrantes.
Creo que opté por esto hace un tiempo (sin la configuración del proxy que mencionaste). No estoy seguro si esto se aplica a todos los firewalls (o tal vez a algo en mi configuración)
pero en mi caso con ufw, vale la pena mencionar que docker omite ufw por defecto, por lo que debes asegurarte de aplicar las reglas también a tus IPs internas de docker.
Ha pasado un tiempo, pero puedo investigar más a fondo si todavía lo necesitas, más adelante esta semana.
¡Y sí, los túneles de Cloudflare son increíbles! @itsbhanusharma
Querrás usar el firewall que te proporciona tu proveedor de VPS. Usar un firewall basado en host será mucho menos efectivo para combatir un DDoS ya que el tráfico llega a tu pila de red.
¿Creo que la mayoría de los proveedores grandes ofrecen protección DDOS por defecto? ¿No debería ser suficiente? Añadir IPs de CloudFlare manualmente a través de la interfaz parece un engorro (mi script bash personalizado tarda 2 segundos y obtiene automáticamente las IPs de CF, por ejemplo).
Tengo que decir que normalmente leo lo contrario, ufw/fw local sobre el fw del proveedor 
Edición; Entiendo la lógica aquí, desde la perspectiva de ddos esto es probablemente más efectivo y tienes razón. Dicho esto, si la IP principal está oculta correctamente desde el principio, ddos no debería ser un problema, ¿verdad?
La mayoría de los proveedores tienen una API para eso hoy en día.
¡Correcto! Pero eso es un “si” bastante grande…
En realidad, está mal. El hecho de que la IP no esté oculta no significa que los ataques DDoS sean un problema si un proxy inverso o similar tiene herramientas para detenerlos. E incluso entonces, cuando hay un ataque real, se necesita algo más que una solución de nivel de entrada. Y si los bots o usuarios esclavos están atacando puertos cerrados o puertos con límite de IP, eso no es un gran problema. Yo lo llamaría un jueves más en el mundo de WordPress, pero Discourse es otro mundo en muchos aspectos.
Por otro lado, no soy un experto en esto.
Pero tengo curiosidad… ¿cuánto tráfico se necesita para que un ataque DDoS tenga éxito? Por supuesto, depende de los recursos de la configuración, pero por favor, deme algunas cifras.
Depende de tu definición de oculto. Sí, todas las direcciones IP son públicas. Pero entonces, ¿cuál de los 4 mil millones de direcciones IP es la correcta? Creo que, para esta discusión, la IP puede considerarse oculta si no hay forma de determinar la(s) dirección(es) IP de un servidor que está sirviendo un foro específico de Discourse (por lo que la función f(h) no está determinada, donde la función f te da la dirección IP real de un host).
Dado:
Pero estoy de acuerdo contigo en que “oculto” es un término confuso e incorrecto. “Desconocido” es probablemente mejor.
Eso depende del tipo de DDoS. Para un ataque a nivel de aplicación, esto podría ser cierto, pero también difícil ya que necesitaría algún tipo de limitación de velocidad con inspección de solicitudes. Pero para un ataque a nivel de red (simplemente inundación de tráfico por amplificación o un ataque syn) esto podría no ser válido. Además, lo que básicamente estás diciendo es “no es un problema si puedes mitigarlo”, lo cual es bastante obvio, pero también difícil y/o costoso.
También depende del tipo de ataque. Un ataque a nivel de aplicación necesitaría ser adaptado a Discourse, pero podría, por ejemplo, ejecutar algunas consultas pesadas como búsquedas para abrumar a los servidores de aplicaciones, mientras que un ataque a nivel de red puede ser más genérico, generar más tráfico y simplemente atascar nginx o la red del VPS.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.