Il blocco di un IP con IP Tables ti protegge da un attacco DOS (non DDOS)?

My question is, if all you are doing is rejecting their requests, then they still have access to try to send information on that port. Can they not still overload your server with requests?

Sì, un sottoinsieme di attaccanti può. Se la loro larghezza di banda è maggiore della tua, o se trovano un modo per utilizzare la larghezza di banda più veloce della loro per compensare la differenza, sei affamato di larghezza di banda e il traffico legittimo non riesce a passare.

Questo è vero in ogni momento attacker_effective_bandwidth + legittimate_bandwidth > server_bandwidth, quindi non dipende esclusivamente dalle risorse dell'attaccante, ma anche dal grado di sovra-provisioning.

Si noti inoltre che fail2ban è focalizzato sui tentativi di accesso e gli exploit che si registrano o monitorano. Alcuni attacchi Denial of Service si basano su comunicazioni che potrebbero non essere registrate (ad esempio richieste echo ICMP) e potrebbero non attivare fail2ban.

if you block their IP and aren't doing any processing on the information then they are really throwing pebbles at a brick wall there. Is this correct?

È corretto solo se la risorsa che si sta preservando è CPU, e se fail2ban osserverà / innescerà in base a tutto il traffico che causa l'utilizzo della CPU. Eliminare i pacchetti richiede una quantità misurabile di CPU, ma è molto più piccolo di cercare di fare qualcos'altro con loro.

What other reasons would this you be protected from DOS with this method?

Non capisco questa domanda, ma penso che fail2ban sia uno strumento che potresti usare e ragionevole. Tuttavia, dovresti prendere in considerazione l'aggiunta di altri strumenti se il costo del tuo sito è inferiore al costo di acquisizione e manutenzione degli strumenti necessari per prevenirlo.

Per rispondere alla tua domanda, si bloccare l'IP di un utente malintenzionato L'esecuzione del server è una soluzione efficace. Questo è per due motivi fondamentali:

Motivo # 1: Ipoteticamente, se l'attaccante sta andando con un attacco base basato sull'inondazione con l'intenzione di sopraffare il server con larghezza di banda (ad esempio caricamento di file?) bloccando il loro IP si ridurrà significativamente il larghezza di banda del loro attacco al punto che non dovrebbe avere alcun impatto sul tuo server (purché il tuo server non sia un criceto in esecuzione su una ruota che alimenta un Raspberry Pi).

Dovrebbe essere notato, # 1 è una rara strategia di attacco per un attacco DoS dal momento che realisticamente, un singolo nodo attaccante non avrà le capacità di larghezza di banda per mandare in crash un server inondandolo di richieste. Il caso più comune è

Motivo n. 2: Livello di applicazione Gli attacchi DoS sono molto più efficaci. Ad esempio, diciamo che il tuo sito web ha una pagina di accesso che esegue l'hashing crittografico lato server della password fornita. Un utente malintenzionato può tentare di arrestare il server concentrando il proprio attacco DoS su quella richiesta di accesso, facendo in modo che il server calcoli centinaia o migliaia di accessi simultanei quando il carico tipico è molto più leggero. In questo caso, il framework Fail2Ban che hai descritto dovrebbe funzionare perfettamente in quanto filtrerebbe le richieste di login false degli attaccanti.

L'intera tattica di mitigazione può essere aggirata ruotando frequentemente un indirizzo IP falsificato alla nota dell'attaccante, ma diventa uno strano ibrido DDoS / DoS e tu hai chiesto espressamente in merito alla vecchia moda DoS. Pertanto, la risposta è valida. Basta bloccare l'IP di attacco dovrebbe essere una difesa adeguata.

Ciò che probabilmente è più importante qui è che, per quanto riguarda la mitigazione, è quasi inutile distinguere gli attacchi DoS e DDoS in questi giorni. Nessun attacco denial-of-service del mondo reale avviene più da una singola sorgente IP fissa.

L'unica ovvia eccezione è quando un utente malintenzionato genera un pacchetto appositamente predisposto per sfruttare una vulnerabilità con potenziale DoS (ad esempio un null pointer dereference da qualche parte in un codice di gestione pacchetti; ecco un esempio di tale vulnerabilità ). Ma bloccare un indirizzo IP sorgente che esegue un exploit non è davvero un buon modo per mitigarlo; l'applicazione di patch su un sistema vulnerabile è.

In teoria, sarebbe più semplice gestire un semplice attacco DoS rispetto a uno distribuito. Tuttavia, poiché sono troppo facili da mitigare, al giorno d'oggi sono per lo più estinti e lo strumento che stai chiedendo (Fail2Ban) non è lì per aiutare contro gli attacchi estinti, è scritto con l'applicazione del mondo reale in mente.

Considerando questo, bloccare un indirizzo IP (con Fail2Ban o manualmente) ha senso solo se vengono soddisfatte due condizioni contemporaneamente:

1. L'attacco DDoS che è in corso riguarda solo le prestazioni del server stesso (o qualcosa dietro, come un server database dietro un'applicazione Web), ma non il trasporto di rete di fronte ad esso ;
2. Può essere verificato in qualche modo che tutti gli indirizzi IP di origine coinvolti nell'attacco non siano falsificati. Per esempio. un attacco DDoS ha come target un handshake basato sul servizio di rete (dove puoi negoziare un segreto verso un cliente e verificare che il client abbia effettivamente ricevuto il segreto) e passa con successo l'handshake di base. Posso fare un altro esempio, ma la descrizione sopra riassume lo scenario più frequente.

Per quanto riguarda un tipico server HTTPS, è possibile utilizzare il blocco dell'intervallo IP contro, ad esempio, allacciamento TCP, handshake SSL / TLS flood, flood POST, Slowloris e così via (è piuttosto difficile classificare gli attacchi di livello 7 oltre le semplici inondazioni), che nella maggior parte dei casi soddisfano entrambi i requisiti.

Si noti, tuttavia, che un'inondazione POST sufficientemente grande potrebbe in effetti influire sul trasporto di rete di fronte al proprio server, ma il blocco IP può comunque aiutare in questo modo, poiché impedisce la creazione di connessioni TCP sottostanti e un bot dannoso non sarà in grado di inviare successivamente un grosso corpo POST al tuo server. Ciò limita efficacemente il traffico malintenzionato in entrata a un flood SYN a basso tasso, che nella maggior parte dei casi è facile da gestire.

Inoltre, l'effetto principale che un'inondazione basata su HTTP causerà sul trasporto di rete è dovuto al traffico in uscita generato dal server in risposta (che nell'odierno HTTP potrebbe essere circa 11-12 volte superiore a quello in entrata), e il blocco delle fonti IP di un flusso HTTP elimina anche questo a causa dei motivi sopra delineati.

Allo stesso tempo il blocco IP è per lo più inutile contro attacchi come flood ICMP, flood SYN, flood UDP e altri che non soddisfano almeno il requisito # 2; e contro attacchi di amplificazione che, nella maggior parte delle condizioni, sono così potenti in termini di traffico in entrata da non soddisfare il requisito # 1.

Si noti che il fatto che un indirizzo IP sorgente in un flood SYN, ad esempio, non possa essere verificato non significa necessariamente che sia stato falsificato. Tuttavia, il blocco di un intervallo di indirizzi IP potenzialmente falsificato può rendere il servizio non raggiungibile per gli utenti legittimi. Infatti, potrebbe essere l'intenzione di un utente malintenzionato di indurti a iniziare automaticamente (ad esempio tramite il suddetto strumento Fail2Ban) a bloccare gli indirizzi IP di origine di un'alluvione basata su pacchetti mentre ci sono solo poche sorgenti presenti nel traffico e quindi a spoofare importanti Intervalli di indirizzi IP, come gli intervalli IP degli ISP più grandi nel tuo paese, o persino l'intero intervallo di indirizzi IPv4 globale di ~ 4 miliardi di indirizzi che, con una frequenza di inondazione arbitraria di 100 Mbit al secondo, potrebbero essere elencati in circa un'ora - L'ho visto davvero nella mia vita un paio di volte.