Tcpdump ignora iptables?


48

Ho erroneamente configurato un server DNS open resolver, che è stato presto utilizzato per un sacco di attacchi DDoS originari da qualche parte dalla / alla Russia. Per questo motivo ho bloccato completamente la porta 53 su entrambi i server DNS per tutti tranne che per gli IP affidabili. Funziona, non sono più in grado di connettermi a loro, ma ciò che mi sembra strano è che quando eseguo tcpdump su eth1 (che è l'interfaccia sul server con internet pubblico) vedo molti pacchetti in arrivo dall'attaccante alla porta 53.

È normale che tcpdump visualizzi questi pacchetti anche se iptables li rilascia? O ho configurato iptables in modo errato?

D'altra parte non vedo alcun pacchetto in uscita dal mio server, cosa che ho fatto prima, quindi suppongo che il firewall funzioni in qualche modo. Mi sorprende solo che il kernel non rilasci completamente i pacchetti? O è tcpdumpagganciato al kernel in modo tale da vedere i pacchetti anche prima che arrivino su iptables?

Risposte:


61

Questa è una bella domanda

È un dato di fatto, tcpdump è il primo software trovato dopo il filo (e la scheda di rete, se vuoi) sulla via IN , e l'ultimo sulla via OUT .

Wire -> NIC -> tcpdump -> netfilter/iptables

iptables -> tcpdump -> NIC -> Wire

In questo modo vede tutti i pacchetti che raggiungono la tua interfaccia e tutti i pacchetti che escono dalla tua interfaccia. Poiché i pacchetti alla porta 53 non ottengono una risposta, come visto da tcpdump, hai verificato con successo che le tue regole iptables sono state configurate correttamente.

MODIFICARE

Forse dovrei aggiungere alcuni dettagli. tcpdump si basa su libpcap , una libreria che crea un socket di pacchetto . Quando viene ricevuto un pacchetto regolare nello stack di rete, il kernel controlla innanzitutto se esiste un socket di pacchetto interessato al pacchetto appena arrivato e, se ce n'è uno, inoltra il pacchetto a quel socket di pacchetto. Se viene scelta l'opzione ETH_P_ALL , tutti i protocolli passano attraverso il socket del pacchetto.

libpcap implementa uno di questi socket di pacchetto con l'opzione attivata, ne conserva una copia per uso proprio e duplica il pacchetto nello stack di rete, dove viene elaborato dal kernel nel solito modo, incluso il passaggio prima a netfilter , il kernel -parte dello spazio di iptables . Stessa cosa, in ordine inverso ( cioè prima netfilter quindi ultimo passaggio attraverso il socket del pacchetto), in uscita.

È incline all'hacking? Ma certo. Esistono certamente rootkit a prova di concetto che usano libpcap per intercettare le comunicazioni destinate al rootkit prima che il firewall possa mettergli la mano. Ma anche questo impallidisce rispetto al fatto che una semplice query di Google scopre codice funzionante che nasconde il traffico anche da libpcap . Tuttavia, la maggior parte dei professionisti ritiene che i vantaggi superino ampiamente gli svantaggi, nel debug dei filtri di pacchetti di rete.


C'è un modo per visualizzarlo in modo che io possa vedere quali pacchetti sono stati consentiti e quali sono stati eliminati?
Petr

2
@Petr puoi registrare i pacchetti che iptables ha lasciato cadere, thegeekstuff.com/2012/08/iptables-log-packets
MariusMatutiae
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.