Bombing dns = DoS

[ZeroUno]

Sto ricevendo un attacco di bombing sul dns. Centinaia di query al secondo, forse anche migliaia che mi hanno causato un DoS.
Inizialmente ho droppato quei 3 ip, poi hanno cominciato a farmi bombing da altri ip.
Ora ho bloccato tutto, quindi sono senza dns esposto (fortunatamente il mio dns è mirrorato da telecom, quindi per un po' posso andare avanti senza, ma non troppo).

Quale è il modo migliore di proteggermi?
Stavo pensando a sfruttare la tabella mangle di iptables, che però non ho mai usato e me la devo studiare, per limitare il numero di richieste al secondo. O è meglio qualcos'altro?

Resta di fatto che pur bloccando tutto mi ritrovo sempre con migliaia di SYN a che:
1) rubano banda (quanta?); ho una banda di 512k/s in upload
2) rubano risorse al kernel per comunque processarle (e la macchina - slackware 12.2 - non è poi una bomba in quanto a processore)
3) ho dovuto disabilitare i log perchè mi saturava il filesystem
4) tcpdump è illegibile
A questo mi sa che non c'è rimedio. O si?

[notsafe]

in dipendenza delle query (lecite o in DENY?) puoi provare ad usare fail2ban ben ristretto.
Comunque, se è un DDoS minimamente strutturato (con una botnet abbastanza ampia), con quelle caratteristiche difficilmente potrai fare qualcosa al tuo livello.Più facilmente lo può gestire il fornitore di connettività.

PS: la risoluzione DNS lavora su UDP.Quindi non esiste "SYN".Ma immagino che tu intendevi dire la richiesta di query.

[masalapianta]

usa i moduli "recent" e "connlimit" di netfilter (prima che tu lo chieda: no, il modulo connlimit non matcha solo le connessioni a valle del 3 way handshake; matcha anche le connessioni in half-open, quindi va bene per fermare anche un syn-flood; quel che non matcha sono le connessioni in time_wait e in close)

[masalapianta]

PS: la risoluzione DNS lavora su UDP.Quindi non esiste "SYN".Ma immagino che tu intendevi dire la richiesta di query.

no, dns lavora sia in udp che in tcp; inoltre, per query la cui risposta supera i 512byte, obbliga il client al fallback su tcp.

[notsafe]

Lavora anche su TCP.
Il default (e il normale uso della risoluzione)è UDP.E verosimilmente il suo caso è quello (come praticamente la totalità dei flood DNS)
Se fosse su TCP,visto il relativo uso,può bloccare tranquillamente la 53/TCP e stare più o meno tranquillo che quasi nessuno avrà poi problemi (a meno che non ci sia qualche server autorizzato al transfer zone,non fattibile tramite UDP)

[masalapianta]

Lavora anche su TCP.

e io che ho detto?

Il default (e il normale uso della risoluzione)è UDP.E verosimilmente il suo caso è quello (come praticamente la totalità dei flood DNS)
Se fosse su TCP,visto il relativo uso,può bloccare tranquillamente la 53/TCP e stare più o meno tranquillo che quasi nessuno avrà poi problemi (a meno che non ci sia qualche server autorizzato al transfer zone,non fattibile tramite UDP)

non necessariamente, a parte i trasferimenti di zona, può capitare (soprattutto se parliamo di piccoli server su cui girano una moltitudine di servizi tra web, mail, ecc.., zone con campi TXT corposi) che una risposta ad una query possa superare i 512byte; inoltre se è un dos/ddos non ha molto senso chiudere il servizio su tcp, in quanto, se l'attaccante riesce a saturare la banda del bersaglio, l'unica cosa da fare (come hai detto tu in un precedente post) è filtrare il traffico a monte sui router del tuo isp (ma in tal caso non credo che ZeroUno avrebbe chiesto aiuto qui, perchè ogni discussione diventerebbe inutile); viceversa se l'attaccante non arriva a saturarti la banda ma punta ad esaurire le risorse del sistema (ad esempio lasciando una moltitudine di connessioni in half-open), si risolve piuttosto bene filtrando il traffico come ho consigliato in un post precedente.

[ZeroUno]

Mi sa che le connessioni non erano in halfopen ma la query dns completa , ma non ne sono sicuro; l'ho bloccati prima di indagare
tcpdump riporta
13:24:01.963069 IP (tos 0x0, ttl 117, id 11935, offset 0, flags [DF], proto UDP (17), length 66)
72.8.167.141.53 > server.53: [no cksum] 952+ [1au] ANY? ripe.net. ar: . OPT UDPsize=4096 OK (38)


Per sicurezza ho bloccato anche le query tcp, ma mi sa che le riapro, almeno mi assicuro il transfer zone (magari ci metto un log oppure filtro per ip del dns slave).

Il firewall mi dice che ci sono pochi tentativi su tcp:

456K 30M DROP udp -- eth1 * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
59 2740 DROP tcp -- eth1 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
(circa in un paio di ore)

Si, ho detto SYN per intendere nuova connessione. Non conosco bene l'udp e non uso più i flag syn/ack dai tempi di ipchains visto che iptables ha il metodo degli stati che è decisamente migliore.

Bloccandolo con il firewall sembra che si naviga decentemente, visto che il firewall dall'output che ho dato blocca 30M in due ore e la cpu ha un idle del 100% (fondamentalmente la macchina è un firewall; fa qualche servizio ma molto minoritario.

Come si usano "recent" e "connlimit" ? (ovvio, intanto me li studio con google, ma se hai qualche consiglio nel frattempo ... )

[ZeroUno]

Vediamo se ho capito bene recent e connlimit.

Con il primo gli dico tipo "x secondi tra una connessione e l'altra"
Con il secondo gli dico tipo "y connessioni simultanee al massimo"

A quanto setto x e y?

Dai log ho visto che in fondo ho pochi accessi, vuoi perchè il sito è piccolo (praticamente lo usano solo una 50ina di persone, per lo più smtp, pop e webmail), vuoi per la cache dns dei provider, mi ritrovo con poche richieste nei log.

[masalapianta]

Vediamo se ho capito bene recent e connlimit.

Con il primo gli dico tipo "x secondi tra una connessione e l'altra"
Con il secondo gli dico tipo "y connessioni simultanee al massimo"

prima ti crei una catena pippo, poi con recent schiaffi in pippo i pacchetti con srcip che stanno gia nella recent list e(ne aggiorni il timestamp con --update) e che non sono scaduti (con --seconds), poi con una seconda regola usi connlimit per infilare in pippo i pacchetti che eccedono il limite impostato con connlimit e recent per infilare il srcip nella recent list; poi ovviamente dei pacchetti che finiscono in pippo fai quel che vuoi (reject, drop, mark e traffic shaping, ecc..)

A quanto setto x e y?

impossibile dirlo a priori, dipende da mille cose (la tua banda, il massimo troughput del flood e la sua stabilità o meno, quanta banda usi per i tuoi servizi e come la usi, quante connessioni aperte può reggere il tuo sistma, ecc..); fai delle prove e aggiusta il tiro.

[ZeroUno]

Ok, grazie.

A quanto setto x e y?

impossibile dirlo a priori, dipende da mille cose

Al momento voglio limitare solo il dns.
Prima voglio essere sicuro che il sistema di filtraggio funzioni bene, visto che non l'ho mai fatto e dai test che ho fatto finora mi sfuggono alcune cose ancora; per esempio mi funziona se metto solo connlimit o solo recent, ma quando li metto insieme si incastrano sembra.


Ma quello che intendevo è, per un dns, considerando che principalmente si lavora con la cache dei dns di provider o locali, in _teoria_ basterebbe anche 1 connessione simultanea, e 1 al minuto sarebbe quasi pure troppo.
E conviene (per recent) fare limitazioni del tipo, per esempio, massimo 1 ogni 5 secondi o qualcosa tipo 10 ogni 50 secondi? Il risultato è lo stesso.. in 50 secondi non mi fai più di 10 richieste, ma nel primo caso significa che mi posso fare appunto una ogni 5 secondi, quindi se l'utente che naviga mi chiede www.miodomino.it e poi www2.miodominio.it deve aspettare 5 sec. se invece chiede due volte www la seconda se lo prende dalla cache sua o del provider; nel secondo caso invece l'utente si può fare le sue belle 10 richieste tutte insieme (nel rispetto di connlimit comunque) e poi aspettare 49 secondi se gli serve www11.miodominio.it oppure prendersi comunque un sito ogni 5 secondi.