Devo limitare i pacchetti con iptables?


8

Sto usando iptables su Ubuntu Server. È un server Web su un VPS.
Vorrei sapere se dovrei limitare i pacchetti. In tal caso, cosa devo limitare? E dovrei farlo a livello globale o per indirizzo IP?

Riferimento
Ho visto persone che suggerivano questo:

# Limit packet traffic on a TCP or UDP port:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -m limit --limit $lim/s --limit-burst $lb -j ACCEPT

# Limit established/related packet traffic:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -m limit --limit $lim/s --limit-burst $lb -j ACCEPT

Quanto sopra, un limite di tasso globale non sembra molto utile, almeno per i casi che posso immaginare. Esiste un caso in cui dovrei limitare il tasso a livello globale?
Credo che un limite di velocità per IP sia generalmente migliore:

# Add the IP to the list:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -m recent --set --name RATELIMITED
# Drop if exceeded limit:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -m recent --update --seconds $sec --hitcount $hc --rttl --name RATELIMITED -j DROP
# Accept if inside limit:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -j ACCEPT

Domanda aggiuntiva: gli IP remoti potrebbero essere falsificati. Come limitarli correttamente?
Aggiunta un'altra domanda per questo:
/server/340258/how-to-rate-limit-spoofed-ips-with-iptables

L'obiettivo
che sto cercando di mitigare il rischio di alcuni attacchi D / DoS e abusi generali.

Correlato
Come posso limitare le connessioni SSH con iptables?

PS : Ho appena aperto una domanda correlata solo per ICMP e include la limitazione della velocità per questo protocollo: iptables | Tipi di ICMP: quali sono (potenzialmente) dannosi?

Risposte:


6

Un limite di velocità non è una prevenzione, ma piuttosto un invito a DoS, in particolare nel sapore presentato sopra in cui i pacchetti verranno eliminati se viene superato un determinato tasso di pacchetti non autenticati senza informazioni sullo stato. Poiché tutti possono creare pacchetti (compresi gli indirizzi IP di origine) in questo stato di connessione senza ulteriori sforzi, sorgerà un nuovo vettore di attacco DoS che sfrutta la propria struttura di limite di velocità.

Un limite di tasso generalmente avrà senso solo se lo hai

  1. un limite prevedibile di connessione hard o soft nella configurazione
  2. impostare il limite di velocità per il traffico generale al di sotto di questo limite per poter impostare connessioni per traffico prioritario o amministrativo indipendentemente dal carico

Mentre 1. spesso è abbastanza difficile determinare persino di disturbare, 2. funzionerà ovviamente solo se si è in grado di differenziare in modo affidabile il traffico "prioritario o amministrativo" dal resto al momento della configurazione della connessione, ad esempio se proviene da un'altra interfaccia di rete.

In altri casi, preferirebbe ridurre la resilienza del sistema piuttosto che aggiungerlo.


Ciao syneticon-dj. Capisco e accetto che un firewall non configurato correttamente è un altro strumento per un attacco DoS. Grazie per il testa a testa!
ML--

Anche la limitazione della velocità per ip o per porta ip sembra avere senso quando si difende dal traffico legittimo che è troppo massiccio per il proprio server ma il cui creatore non è in grado di sfruttare il problema menzionato, diciamo, comportamento abusivo dal Bingbot o Bot di Facebook.
Ján Lalinský,

3

Il problema con -m limit è la limitazione di tutti i pacchetti TCP indipendentemente dagli indirizzi IP di origine. Quindi, se hai un limite basso per pacchetti syn simili

-A INPUT -p tcp  --syn -m limit --limit 30/s --limit-burst 30 -j ACCEPT
-A INPUT -p tcp --syn -j DROP

solo un client con la riga di comando hping può arrestare il server inviando tanti pacchetti tcp con flag SYN perché la regola del limite corrisponderà e eliminerà molti pacchetti indipendentemente dagli indirizzi IP di origine. Il limite non fa differenza tra traffico buono e traffico cattivo. Abbatterà anche il buon traffico in entrata.

hping potrebbe essere qualcosa del tipo:

hping thetargetedhostip -p 80 -S -c 1000 -i u20000

È meglio usare hashlimit per limitare le connessioni tcp in entrata per indirizzo IP . La seguente regola corrisponderà solo se verranno ricevuti 30 pacchetti al secondo, riducendo il numero di pacchetti autorizzati per IP a 15 pacchetti al secondo.

-A INPUT -p tcp --syn -m hashlimit --hashlimit 15/s --hashlimit-burst 30 --hashlimit-mode srcip --hashlimit-srcmask 32 --hashlimit-name synattack -j ACCEPT 
-A INPUT -p tcp --syn -j DROP

In effetti, sono CONVINTO che molti server che vengono smantellati oggi non vengono eliminati esaurendo le risorse durante un attacco ma a causa del modulo limite che rilascia tutto il traffico in entrata.


1

In genere limito le regole di limitazione della velocità ai server che mi aspetto di avere:

  • basse quantità di traffico previsto
  • servizi di autenticazione

Ad esempio, la pagina di accesso di un pannello di controllo di hosting, POP3, IMAP, SSH, ecc. Di solito lascio i servizi HTTP spalancati e blocco solo in caso di problemi.

Non si desidera eliminare un buon traffico Web. Un link su slashdot potrebbe inviarti tonnellate di traffico e con le regole globali, potresti non realizzare un problema.

Per quanto riguarda gli IP falsificati, non possono essere bloccati utilizzando questo metodo e in genere non destano preoccupazione poiché queste regole si concentrano principalmente sulla limitazione delle connessioni TCP stabilite. Con un IP spoof la connessione TCP non può mai essere stabilita.


Ciao jeffatrackaid, grazie per la tua risposta! Sono anche propenso a limitare (a livello globale) questi tipi di servizi (SSH ecc.). Per quanto riguarda il traffico HTTP, ecco perché non intendo applicare un limite globale. In questa domanda mi aspetto di vedere se ci sono casi in cui un limite per IP può essere interessante. Per quanto riguarda gli IP contraffatti (ho aperto una domanda separata su questo) anche se non è possibile stabilire connessioni, esiste la possibilità di un DoS utilizzando un flood SYN. Rimango interessato a sapere come mitigarlo.
ML--
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.