Il mio sito web utilizza Discourse. Inizialmente, non era protetto da Cloudflare e ha subito un attacco DDoS.
Successivamente, ho cambiato l’indirizzo IP e implementato Cloudflare. Tuttavia, il sito web è stato nuovamente attaccato da DDoS, apparentemente a causa di una fuga dell’IP del server di origine.
Quando si utilizza Cloudflare CDN, come possiamo impedire che l’IP del server di origine venga divulgato? Qualcuno ha dei buoni metodi? Grazie.
Non lo so, ma l’IP di ogni server online verrà trapelato nello stesso momento in cui viene creato.
È possibile evitare molte perdite facendo quanto segue
HTTPS_PROXY e HTTP_PROXY in modo che Discourse li utilizzi (impostarle nella sezione env del file app.yml)NO_PROXY='127.0.0.1, localhost, \u003cinternal-network\u003e'Vedi anche Install discourse with internet access only via proxy, Configuration outbound proxy e Discourse Link previews through a proxy server? - #14 by supermathie
Inoltre, quando ci si trova dietro CF, è possibile modificare il firewall sul proprio host Discourse per consentire solo il traffico in entrata dagli indirizzi IP di Cloudflare (e dall’host da cui si accede personalmente).
Questa è la soluzione. La sicurezza per oscurità non è sicura. Quindi non importerà se il tuo IP è di dominio pubblico.
Questo o, in alternativa, un approccio più semplice sarebbe utilizzare quello che viene chiamato un tunnel Cloudflare. Dovrebbe essere un’impostazione una tantum e poi dovresti essere in grado di chiudere quasi completamente il tuo firewall per le connessioni in entrata.
Credo di averlo fatto un po’ di tempo fa (senza la configurazione proxy che hai menzionato). Non sono sicuro se questo si applichi a tutti i firewall (o forse a qualcosa nella mia configurazione)
ma nel mio caso con ufw, vale la pena menzionare che docker bypassa ufw per impostazione predefinita, quindi devi assicurarti di applicare le regole anche ai tuoi IP docker interni.
È passato un po’ di tempo ma posso approfondire i dettagli se ne hai ancora bisogno, più tardi questa settimana.
E sì, i tunnel Cloudflare sono fantastici! @itsbhanusharma
Dovrai utilizzare il firewall fornito dal tuo provider VPS. L’utilizzo di un firewall basato sull’host sarà molto meno efficace nel combattere un attacco DDoS poiché il traffico raggiunge comunque lo stack di rete.
Penso che la maggior parte dei grandi provider offra la protezione DDOS per impostazione predefinita? Non dovrebbe essere sufficiente? Aggiungere manualmente gli IP di CloudFlare tramite l’interfaccia sembra una seccatura (il mio script bash personalizzato richiede 2 secondi e recupera automaticamente gli IP di CF, ad esempio).
Devo dire che di solito leggo il contrario, ufw/fw locale rispetto al fw del provider 
Modifica; Capisco la logica qui, dal punto di vista ddos questo è probabilmente più efficace e hai ragione. Detto questo, se l’IP principale è nascosto correttamente fin dall’inizio, il ddos non dovrebbe essere un problema, giusto?
La maggior parte dei provider ha un’API per questo al giorno d’oggi?
Corretto! Ma è un “se” piuttosto grande…
In realtà sbagliato. Solo perché l’IP non è mai nascosto. Il Ddos non è un problema se un proxy inverso o simile ha strumenti per fermarlo. E anche allora, quando c’è un vero attacco, è necessario qualcosa di più di una soluzione entry-level. E se bot o utenti schiavi stanno bussando a porte chiuse o porte limitate dall’IP, non è un grosso problema. Lo definirei un altro giovedì nel mondo di WordPress, ma Discourse è un altro mondo per molti versi.
D’altra parte, non sono un esperto in materia.
Ma sono curioso… quanto traffico è necessario perché un ddos abbia successo? Naturalmente dipende dalle risorse della configurazione, ma per favore dammi qualche numero.
Dipende dalla tua definizione di nascosto. Sì, tutti gli indirizzi IP sono pubblici. Ma allora quale dei 4 miliardi di indirizzi IP è quello corretto? Penso che, per questa discussione, l’IP possa essere considerato nascosto se non c’è modo di determinare l’indirizzo IP (o gli indirizzi IP) di un server che sta servendo un forum Discourse specifico (quindi la funzione f(h) è indeterminata, dove la funzione f ti fornisce l’indirizzo IP reale per un host)
Dato:
Ma sono d’accordo con te sul fatto che “nascosto” sia un termine confuso e scorretto. “Sconosciuto” è probabilmente meglio.
Dipende dal tipo di DDoS. Per un attacco a livello di applicazione questo potrebbe essere vero, ma anche difficile poiché richiederebbe una qualche forma di limitazione della frequenza con ispezione delle richieste. Ma per un attacco a livello di rete (semplice inondazione di traffico tramite amplificazione o attacco syn) questo potrebbe non valere. Inoltre, quello che stai fondamentalmente dicendo è “non è un problema se puoi mitigarlo”, il che è piuttosto ovvio, ma anche difficile e/o costoso.
Dipende anche dal tipo di attacco. Un attacco a livello di applicazione dovrebbe essere personalizzato per Discourse, ma potrebbe ad esempio eseguire query pesanti come ricerche per sopraffare i server delle applicazioni, mentre un attacco a livello di rete può essere più generico, richiedere più traffico e può semplicemente intasare nginx o la rete del VPS.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.