Server DNS ricorsivi rivolti al pubblico - regole di iptables

Eseguiamo server DNS ricorsivi rivolti al pubblico su macchine Linux. Siamo stati usati per attacchi di amplificazione DNS. Ci sono delle iptablesregole consigliate che potrebbero aiutare a mitigare questi attacchi?

La soluzione ovvia è solo quella di limitare i pacchetti DNS in uscita a un determinato livello di traffico. Ma speravo di trovare qualcosa di un po 'più intelligente in modo che un attacco blocchi il traffico verso l'indirizzo IP della vittima.

Ho cercato consigli e suggerimenti, ma sembrano tutti "non eseguire server dei nomi ricorsivi rivolti al pubblico". Sfortunatamente, siamo tornati in una situazione in cui le cose che non sono facili da cambiare si romperanno se non lo facciamo, e questo è dovuto alle decisioni prese più di un decennio fa prima che questi attacchi fossero un problema.

L'intero tipo di puzza di uno scenario "non è un mio problema" che non è davvero colpa tua e dovrebbe / potrebbe essere risolto al 100% prendendo l'azione appropriata, indipendentemente da quanto sia "difficile" o "difficile", e che sta terminando il tuo aprire il server ricorsivo .

Eliminalo gradualmente: comunica ai clienti che questo server sta per essere rimosso a partire dalla data X. Dopo quel tempo, devono installare una patch (supponendo che tu ne abbia una) per impedirle di usare il tuo server DNS. Questo è fatto tutto il tempo. Amministratori di sistema, amministratori di rete, ragazzi dell'helpdesk, programmatori? Lo capiamo ; questa cosa di fine vita accade continuamente, perché la sua procedura operativa standard per un fornitore / fornitore di servizi / partner ci dice di smettere di usare qualcosa dopo X date. Non sempre ci piace, ma è un dato di fatto nella vita dell'IT.

Dici di non avere questo problema sui dispositivi attuali, quindi suppongo di aver risolto questo problema con un aggiornamento o una patch del firmware. So che hai detto che non puoi toccare il dispositivo, ma sicuramente possono? Voglio dire, se stanno permettendo a queste caselle di telefonarti a casa, non possono davvero essere così anali su chi sta facendo cosa ai loro dispositivi; potresti avere una configurazione proxy inversa per quello che sanno, quindi perché non farli installare una patch che risolva questo problema o dire loro di usare i propri server DNS . Sicuramente il tuo dispositivo supporta DHCP; Non riesco a pensare a un dispositivo di rete (non importa quanto vecchio / fragile / dispari) che non lo fa .

Se non riesci a farlo, la prossima cosa da fare è controllare chi può accedere al tuo server ricorsivo : dici che è "difficile dire" chi lo sta usando e come, ma è tempo di scoprire con certezza e iniziare a eliminare il traffico che è non legittimo.

Queste sono organizzazioni "quasi militari / governative", giusto? Bene, probabilmente fanno parte di un netblock legittimo di loro proprietà; questi dispositivi non sono router domestici dietro IP dinamici. Scoprire. Contattali, spiega il problema e come stai risparmiando un sacco di soldi non forzando un firmware o una sostituzione del prodotto se solo loro possono confermare il netblock / indirizzo IP che il dispositivo utilizzerà per accedere al tuo server DNS.

Ciò avviene sempre: ho diversi clienti che limitano l'accesso extranet o gli ascoltatori HL7 ai partner sanitari in questo modo; è non è così difficileper convincerli a compilare un modulo e fornire l'IP e / o il netblock da cui dovrei aspettarmi il traffico: se vogliono accedere alla extranet, devono fornirmi un IP o una sottorete. E questo è raramente un obiettivo mobile, quindi non è che ti inonderai di centinaia di richieste di modifica IP ogni giorno: le grandi reti ospedaliere del campus che possiedono i propri blocchi di rete con centinaia di sottoreti e migliaia e migliaia di IP host mi danno regolarmente una manciata di indirizzi IP o una sottorete che dovrei aspettarmi; di nuovo, questi non sono utenti di laptop che vagano sempre in tutto il campus, quindi perché dovrei aspettarmi di vedere i pacchetti sorgente UDP da un indirizzo IP in continua evoluzione? Chiaramente sto facendo un presupposto qui, ma scommetto che non è tanto quanto pensi per <100s di dispositivi. Sì, sarà un lungo ACL, e sì,

Se per qualche motivo i canali di comunicazione non sono aperti (o qualcuno ha troppa paura o non può essere disturbato a contattare questi proprietari di dispositivi legacy e farlo correttamente), è necessario stabilire una base di utilizzo / attività normale in modo da poter formulare qualche altra strategia che aiuterà (ma non impedisce) la tua partecipazione agli attacchi di amplificazione DNS.

A lungo termine tcpdumpdovrebbe funzionare il filtro su UDP 53 in arrivo e la registrazione dettagliata sull'applicazione server DNS. Vorrei anche iniziare a raccogliere indirizzi IP di origine / netblock / informazioni geoIP (sono tutti i tuoi clienti negli Stati Uniti? Bloccare tutto il resto) perché, come dici tu, non stai aggiungendo nuovi dispositivi, stai semplicemente fornendo un lascito servizio agli impianti esistenti.

Questo ti aiuterà anche a capire quali tipi di record vengono richiesti e per quali domini, da chi e con quale frequenza : affinché l'amplificazione DNS funzioni come previsto, l'utente malintenzionato deve essere in grado di richiedere un tipo di record di grandi dimensioni (1) a un dominio funzionante (2).

1. "tipo di record di grandi dimensioni": i tuoi dispositivi hanno persino bisogno di record TXT o SOA per poter essere risolti dal tuo server DNS ricorsivo? Potresti essere in grado di specificare quali tipi di record sono validi sul tuo server DNS; Credo che sia possibile con BIND e forse Windows DNS, ma dovresti scavare. Se il tuo server DNS risponde SERVFAILa qualsiasi record TXT o SOA, e almeno quella risposta è un ordine di grandezza (o due) più piccolo del carico utile previsto. Ovviamente sei ancora "parte del problema" perché la vittima falsificata continuerebbe a ricevere quelle SERVFAILrisposte dal tuo server, ma almeno non le stai martellando e forse il tuo server DNS viene "cancellato" dall'elenco (i) raccolto (i) i robot usano nel tempo per non "cooperare".

2. "dominio funzionante": potresti essere in grado di autorizzare solo i domini validi. Faccio questo sulle mie configurazioni di data center rinforzate in cui i server hanno bisogno solo di Windows Update, Symantec, ecc. Per funzionare. Tuttavia, stai solo mitigando il danno che stai causando a questo punto: la vittima verrebbe comunque bombardata NXDOMAINo con le SERVFAILrisposte dal tuo server perché il tuo server continuerebbe a rispondere all'IP di origine contraffatto. Ancora una volta, lo script Bot potrebbe anche aggiornare automaticamente l'elenco dei server aperti in base ai risultati, in modo da rimuovere il server.

Vorrei anche usare una qualche forma di limitazione della velocità, come altri hanno suggerito, sia a livello di applicazione (ad esempio dimensioni del messaggio, limitazioni per richieste client) sia a livello di firewall (vedere le altre risposte), ma ancora una volta devi fare alcune analisi per assicurarti di non uccidere il traffico legittimo.

Un sistema di rilevamento delle intrusioni che è stato sintonizzato e / o addestrato (di nuovo, ha bisogno di una base di riferimento qui) dovrebbe essere in grado di rilevare nel tempo anche il traffico anormale per fonte o volume, ma probabilmente prenderebbe regolarmente baby sitter / tuning / monitoraggio per prevenire falsi positivi e / o vedi se sta effettivamente impedendo gli attacchi.

Alla fine della giornata, devi chiederti se ne valga la pena o se dovresti semplicemente insistere sul fatto che sia fatta la cosa giusta e che in primo luogo elimini il problema.

Dipende dal tipo di limitazione della frequenza che si desidera fare.

La limitazione della frequenza con iptablesè davvero più intesa per limitare i pacchetti in entrata, poiché i pacchetti fino al limite corrisponderanno al filtro e avranno applicato l'obiettivo specificato (ad es ACCEPT.). Presumibilmente avresti un obiettivo successivo per i DROPpacchetti non corrispondenti al filtro. E sebbene iptablesabbia un QUEUEobiettivo, passa semplicemente il pacchetto allo spazio utente in cui è necessario fornire la propria applicazione di accodamento. Puoi anche valutare il limite dei pacchetti in uscita, ma poche persone vogliono davvero iniziare a eliminare il traffico in uscita.

iptables caduta del limite di velocità:

iptables -A INPUT -p udp --port 53 -m hashlimit --hashlimit 1/minute --hashlimit-burst 5 -j ACCEPT
iptables -A INPUT -p udp --port 53 -j DROP

L'uso hashlimitpiuttosto che limitun limite di velocità per IP di destinazione. Vale a dire, cinque pacchetti a 8.8.8.8 che superano il limite impediranno l'invio di pacchetti a 8.8.4.4 mentre con hashlimitse 8.8.8.8 è al massimo puoi comunque raggiungere 8.8.4.4, che suona più come quello che desideri.

Se non vuoi che i pacchetti oltre il limite vengano eliminati, ciò che vuoi veramente è tc. tcregolerà il flusso per ottenere un flusso costante piuttosto che un traffico intenso. Sul lato in entrata i pacchetti vengono consegnati all'applicazione più lentamente ma arriveranno tutti in ordine. Sui pacchetti in uscita lascerà la tua applicazione il più velocemente possibile ma posizionata sul filo in un flusso coerente.

Non ho usato tcmolto, ma ecco un esempio di ICMP che limita la velocità che probabilmente puoi adattare facilmente per il DNS.

Ecco una cosa che puoi fare per mitigare potenzialmente le risposte alle query contraffatte, ma ci vuole un po 'di lavoro:

Innanzitutto, dai un'occhiata al tuo registro del canale di sicurezza e trova un indirizzo IP che viene falsificato.

Quindi eseguire un tcpdump utilizzando tale IP di origine (10.11.12.13) in questo modo:

tcpdump -n src 10.11.12.13 and udp dst port 53 -v -X -S

Otterrai qualcosa del genere:

18: 37: 25.969485 IP (fino a 0x0, ttl 52, id 46403, offset 0, flag [nessuno], proto: UDP (17), lunghezza: 45) 10.11.12.13.51169> 01.02.03.04.dominio: 4215+ ANY ? . (17)
        0x0000: 4500 002d b543 0000 3411 b9d9 0A0B 0C0D E ..-. C..4 .......
        0x0010: 0102 0304 c7e1 0035 0019 0e89 1077 0100 ....... 5 ..... w ..
        0x0020: 0001 0000 0000 0000 0000 ff00 0100 ..............

Ora la parte divertente! Apri rfc1035 su http://tools.ietf.org/html/rfc1035 e vai alla sezione 4.1.1.

È tempo di tradurre i risultati di tcpdump e capire un modello che possiamo usare per creare un filtro a livello di pacchetto.

L'ID dell'intestazione inizia a 0x1C, quindi abbiamo alcuni flag a 0x1E, il QDCOUNT a 0x20, l'ANCOUNT a 0x22, il NSCOUNT a 0x24 e l'ARCOUNT a 0x26.

Ciò lascia la domanda effettiva a 0x28, che in questo caso è null (ROOT) per NAME, 0xFF per QTYPE = ANY e 0x01 per QCLASS = IN.

Per farla breve, ho scoperto che l'aggiunta delle seguenti regole iptables blocca oltre il 95% delle query contraffatte che richiedono QUALSIASI record IN ROOT:

iptables -A INPUT -p udp --dport domain -m u32 --u32 "0x28=0x0000ff00" -j DROP

Il tuo chilometraggio può variare ... spero che questo aiuti.

Utilizzo tce accodamento di discipline in linux per la porta 53 in uscita UDP:

IFACE=eth0    
tc qdisc  add dev ${IFACE} root handle 1: htb default 0
tc class  add dev ${IFACE} parent 1: classid 1:1 htb rate   10mbit burst 20m
tc qdisc  add dev ${IFACE} parent 1:1 handle 10: sfq perturb 1
tc filter add dev ${IFACE} protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:1

Ti imposterà con un disclimite di 10 mbit per qualsiasi pacchetto con contrassegno firewall '1'. I contrassegni del firewall sono solo interni al firewall e non modificano il pacchetto. Solo la gestione del pacchetto da parte della disciplina di accodamento. Ecco come utilizzare iptablesper creare i contrassegni del firewall:

iptables -A PREROUTING -o eth0 -p udp --sport 53 -t mangle -j MARK --set-mark 1
iptables -A PREROUTING -o eth0 -p udp --dport 53 -t mangle -j MARK --set-mark 1

Modifica a tuo piacimento per escludere subnet e / o destinazioni attendibili. La -o eth0limita la sagomatura solo ai pacchetti in uscita. Spero che sia di aiuto.

Proverei a comporre un elenco di tutti i client che si affidano ai resolver ricorsivi rivolti verso l'esterno. Inizia con circa un giorno di tracce di pacchetti nelle caselle DNS. Da lì, inizia a creare regole iptables per consentire quel traffico che riconosci e autorizzi. L'impostazione predefinita sarà infine la riduzione del traffico su 53 / tcp e 53 / udp. Se ciò rompe qualcosa, perfeziona le tue regole.

a seconda della 'posizione' della rete in cui ci si trova [avendo più feed bgp o trovandosi alla 'fine' di Internet - come rete stub] puoi provare qualcosa come uRPF per prevenire lo spoofing dell'indirizzo di origine.

altra fonte di informazioni.

Questi dispositivi sono ancora oggetto di un contratto di assistenza? In tal caso, contatta i tuoi clienti. Fai sapere loro che Internet si è evoluto un po 'nell'ultimo decennio e per continuare a fornire la risoluzione dei nomi per questi dispositivi devi conoscere l'IP SRC per cui aspettarti delle domande. Imposta una data ~ 6 mesi in futuro in quel momento non sarai più in grado di servire clienti sconosciuti e attenersi ad esso. Questo è abbastanza comune nel settore. Se questi dispositivi non sono più soggetti a un contratto di assistenza ... sembra una decisione commerciale. Per quanto tempo la tua azienda intende spendere risorse per prodotti antichi che non generano più entrate?

Sembrano dispositivi specializzati, sono così specializzati che puoi ragionevolmente prevedere per quali domini aspettarti query legittime? bind supporta le viste, crea una vista pubblica che fa solo ricorsione per quei domini.

Utilizzalo come opportunità di apprendimento, se non l'hai già fatto, smetti di rilasciare prodotti in cui non hai la possibilità di correggere i bug. Ecco cos'è, un bug. Uno che sicuramente eliminerà questo dispositivo prematuramente, prima o poi.

Da qualche parte in nanog, questo:

iptables -A INPUT -p udp --dport 53 -m hashlimit \
--hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \
--hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP 

Questo non è l'ideale. Potrebbe essere meglio consentire un minor numero di pacchetti al secondo e avere un burst più elevato.

Ecco una soluzione che ho usato un paio di volte contro gli attacchi DDOS, non è perfetta ma mi ha aiutato. La soluzione consiste in uno script che viene chiamato ogni N minuti (come 1,2,3 ecc. Minuti) dal cron e blocca gli IP che stanno creando un numero di connessioni più grande di quello indicato nello script:

#!/bin/sh

PORT_TO_CHECK="53"
CONNECTION_LIMIT="20"
IPTABLES="/sbin/iptables"

netstat -an > /tmp/netstat.tmp
Buf_var1=`cat /tmp/netstat.tmp | grep -v "LISTEN"| grep ":$PORT_TO_CHECK\ " | grep -v "0.0.0.0" | awk '{print $5}' | grep -v ":$PORT_TO_CHECK$" | sed -e 's/^::ffff://g' -e 's/:.*$//g' | sort | uniq`
i=0
banned_flag=0
for conn in `for i in $Buf_var1; do echo -n "$i "; cat /tmp/netstat.tmp | grep -c $i;done | grep -v "=\ 0"`;do
[ $i = 0 ] && connip=$conn && i=1
[ $i = 2 ] && {
connum=$conn
[ $connum -ge $CONNECTION_LIMIT ] && {
[ "$var_test" = "" ] && {
$IPTABLES -I INPUT -s $connip -j DROP
banned_flag=1
}
}
}
[ $banned_flag = 1 ] && i=0
[ $i = 1 ] && i=2
done
rm -f /tmp/netstat.tmp