Supponiamo di avere un sito Web e voglio assicurarmi che un hacker non stia facendo cadere il mio server utilizzando un attacco DDOS sul mio sito web. Ho pensato di ottenere l'indirizzo IP e revocare l'accesso, ma mi sembra complicato da implementare.
Dovrei essere preoccupato per questo? O dovrei lasciarlo senza alcuna protezione contro di esso.
Se sei interessato a capire i metodi di protezione a un livello più tecnico, ci sono molti articoli che descrivono strategie più approfondite per proteggersi da un attacco DDOS, come questo da Cisco: link
Detto questo, potresti aver notato che anche alcuni dei più grandi servizi al mondo sono ancora affetti da attacchi DDOS su vasta scala ( Telegram quest'anno , Reddit più volte negli ultimi anni ). Non c'è davvero un punto d'argento per questo tipo di cose, anche se alcune strategie possono includere:
Rilevamento di intervalli di indirizzi IP bloccanti mentre l'attacco è in corso, come sottolineato da schroeder
Esegui un'acquisizione / acquisizione di pacchetti sul traffico che ritieni provenga da alcuni degli host in conflitto e prova a trovare alcuni attributi univoci che puoi utilizzare per bloccare la richiesta (ad esempio, agenti utente simili, dati dell'intestazione HTTP)
Utilizza un servizio come Cloudflare o Akamai come CDN - spesso questi servizi hanno un certo grado di protezione DDOS integrato anche nei loro piani gratuiti.
Se ti interessa il blocco degli attacchi DDOS tramite l'indirizzo IP probabilmente non ti sarà di grande aiuto, perché DDOS significa Distributed Denial of Service e quindi è tipicamente causato da un numero elevato di host, solitamente alcune botnet. In questo caso non ci sono solo molte fonti per l'attacco, ma cambiano spesso anche nel tempo, quindi il semplice blocco tramite l'indirizzo IP sorgente non aiuta molto e probabilmente ha anche effetti collaterali indesiderati come tenere fuori gli utenti non malintenzionati.
Esistono diversi tipi di attacchi DOS e DDOS, a seconda del livello in cui lavorano: gli attacchi classici funzionano solo a livello di trasporto e consumano molta larghezza di banda, rendendo così il tuo sito difficile da raggiungere. Spesso questi possono essere filtrati all'interno di un firewall upstream basandosi solo su modelli di traffico tipici, come la dimensione della richiesta o persino l'indirizzo IP di origine. Anche CDN come Cloudflare può essere d'aiuto in questo caso perché hanno semplicemente una maggiore larghezza di banda disponibile e un team più agile per rilevare e dissuadere gli attacchi. Altri attacchi funzionano contro il server o specificamente contro l'applicazione e causano un sovraccarico del server con a volte solo poche richieste. Questi tipi di attacchi sono più difficili da difendere. A volte un firewall per applicazioni Web (WAF) è in grado di filtrare tali richieste HTTP dannose ma non sempre.
C'è molta diversità negli attacchi che rende impossibile avere un'unica soluzione da proteggere contro tutti questi. Alcuni esempi:
E questi sono solo alcuni esempi e nessuno di questi attacchi richiede più di un metodo GET (magari su misura) e talvolta nemmeno questo. Dovrebbero mostrarti che non esistono soluzioni di protezione singole. Usare CDN o provider specializzati nella protezione di DOS sarà sicuramente d'aiuto, ma non saranno in grado di combattere tutti gli attacchi. Quindi, se stai cercando di costruire un'attività basata sul tuo sito web, dovresti essere consapevole del rischio e pianificare di conseguenza.
Come è stato già detto, il blocco degli IP non funzionerà. Gli attacchi DDoS sono molto difficili e talvolta impossibili da proteggere.
Raccomando di utilizzare un servizio come CloudFlare. Gli stessi DDoSer lo usano per proteggersi dai loro compagni DDoSer. Ha un livello gratuito e un livello pagato. Se quello che stai proteggendo è di bassa scala (cioè, più piccolo di una grande azienda), il livello gratuito dovrebbe essere sufficiente.
CloudFlare is designed to accelerate and secure any website. Our system works somewhat like a Content Delivery Network (CDN), but is designed to be much easier to setup and configure.
To explain how the system works, imagine you have a website (allen.com) and it's running a web server with the IP address of 1.1.1.1. Before CloudFlare, if someone typed your website's domain (allen.com) into their browser, the first thing that visitor's computer would do is send a query to the DNS system and get back your web server's IP address (1.1.1.1).
In order to make CloudFlare easy to set up, we take advantage of how this basic function of the Internet works. Rather than having you add hardware, install software, or change your code, we have you designate two CloudFlare nameservers as the authoritative nameservers for your domain (e.g., bob.ns.cloudflare.com and sara.ns.cloudflare.com). You make this change with the registrar from which you bought your domain (e.g., GoDaddy, Network Solutions, Register.com, etc.).
Designating CloudFlare as your authoritative nameservers doesn't change anything about your website. Your registrar remains your registrar, your hosting provider remains your hosting provider, and so on. However, because we are your authoritative nameserver, we can begin cleaning and accelerating your web traffic.
To make this happen we use a network routing technology called Anycast (and some other fancy tricks) to route initial DNS lookups for your domain to a CloudFlare data center closest to the visitor. We have data centers around the world and we’re growing every month. The data center that receives the request returns an answer in the form of an IP address (e.g., 99.99.99.99), which directs all the visitor's subsequent requests to the best data center for them.
After a visitor's browser has done the initial DNS lookup, it begins making requests to retrieve the actual content of a website. These requests are directed to the IP address that was returned from the DNS lookup. Before CloudFlare, that would have been 1.1.1.1, with CloudFlare as the authoritative nameserver that would be 99.99.99.99 (or some other address depending on what CloudFlare data center is closest to the user). CloudFlare's edge servers running on that IP address receive the request and perform analysis on it. We scan to see if the visitor appears to be a threat based a number of characteristics including the visitor's IP address, what resource they are requesting, what payload they are posting, how frequently they're making requests, etc.
To speed up the response time for a request that goes to a one of our frontline servers, CloudFlare caches parts of websites that are static in these servers. For example, we cache things like images, CSS, and JavaScript. We are very conservative with our caching because we never want to mess up dynamic content. So, for example, as a general rule we do not cache HTML. We also refresh the cache relatively frequently, so files are never more than a few hours old. Even being conservative, however, typically 50% of the resources on any given web page are cacheable.
Assuming the visitor is not a threat, the frontline checks the request against the Cached resources on our front line servers to see if the resource being requested is in CloudFlare’s local cache. If we have a local copy of the file being requested, then we can deliver it directly to the visitor from a local data center greatly increasing request response time.
If the request is for a type of resource we don't cache, or if we don't have a current copy in our cache, then we make a request from our data center (99.99.99.99) back to your origin server (1.1.1.1). Because of our scale, we can get premium routes from our data centers back to most places on the Internet. As a result, while it may seem counter-intuitive, it is sometimes the case that the number of "hops" a visitor’s request makes going through the CloudFlare network is less than the number of "hops" that they would have made going to the origin web server directly, even when we aren't able to return a result from our cache.
The combination of these systems means that we can protect sites from malicious visitors by stopping them before they even get to the origin web server, save over 60% of the bandwidth that a site would otherwise have to pay for, save over 65% of the requests that would otherwise have to be handled by a site, and cut in half average page load times. In order to make performance even better, we also do web content optimization.
Leggi altre domande sui tag webserver brute-force