Creazione di join multicast per acquisizioni tcpdump


11

Voglio scrivere uno script di shell Linux che catturerà il traffico multicast specifico. Specifico come in, voglio creare un file pcap che abbia tutto il traffico per un gruppo / porta multicast specifico.

Ecco la riga di comando che sto usando per visualizzare il traffico:

tcpdump -nnXs 0 -i eth1 udp port 22001 and dst 233.54.12.234

Funziona bene finché ho già sottoscritto un abbonamento multicast a quel gruppo. Ad esempio, se eseguo questo in un'altra console:

mdump 233.54.12.234 22001 10.13.252.51

tcpdumpvedrà i pacchetti. Se mdumpnon è in esecuzione, tcpdumpnon vede nulla.

Esiste un modo linux-y standard per stabilire questi join multicast prima di iniziare le acquisizioni? Potrei usare mdumpper stabilire questi join, ma questo sembra dispendioso poiché mdumpelaborerà tutti quei dati sul gruppo, ma ho intenzione di buttarli via.

Si noti che a causa del mio ambiente specifico, sono stato scoraggiato dal mettere l'interfaccia in modalità promiscua. In effetti, potrebbe essere proibito.


1
A meno che non si sta eseguendo una versione non standard di tcpdump, si sta mettendo l'interfaccia in modalità promiscua - la -pbandiera, nelle versioni standard di tcpdump, si trasforma modalità promiscua fuori , come è il default. In modalità promiscua, dovrebbe visualizzare tutto il traffico, incluso il traffico multicast, indipendentemente dal fatto che l'abbonamento sia stato stabilito, a meno che non ci si trovi su una rete commutata ed è necessario disporre dell'abbonamento stabilito per consentire lo switch forwarding del traffico.

1
@GuyHarris: grazie per il chiarimento. Sono su una rete commutata. Senza l'abbonamento già stabilito (ovvero con l' mdumpesecuzione in un'altra console), tcpdumpnon vede nulla.
John Dibling,

E se non vogliono che tu funzioni in modalità promiscua, probabilmente non ti vogliono (o non ti lasceranno nemmeno ) impostare una "porta speculare" sullo switch (supponendo che lo switch lo supporti anche) per ottenere copie di tutto il traffico attraverso lo switch (o tutto il traffico attraverso determinate porte, se possibile).

Quindi cosa c'è di sbagliato nel farlo con una sceneggiatura? Ciò che conta è se fa il lavoro, non se qualcuno lo considera "nel solito modo" - cosa c'è di "insolito" nella sceneggiatura?

La modalità promiscua è disabilitata perché l'abilitazione, a quanto pare, avrebbe un impatto sulle altre macchine virtuali sull'host. Questo è indesiderato. Io posso impostare una porta a specchio con l'interruttore - questi sono 40GB aristas - ma io non sono sicuro di vedere il tuo punto.
John Dibling,

Risposte:


5

TL; DR - Scegli uno:

sudo ip addr add 233.54.12.234/32 dev eth1 autojoin

socat STDIO UDP4-RECV:22001,ip-add-membership=233.54.12.234:eth1 > /dev/null


All'inizio stavo per dire "basta usare ip maddress added essere fatto con esso". Il problema ip maddressriguarda solo gli indirizzi multicast a livello di link e non gli indirizzi multicast di protocollo ( man 8 ip-maddress).

Detto questo, usare la autojoinbandiera con il verbo dell'indirizzo fa proprio il trucco.

Ciò solleva tuttavia alcune domande successive. Presumo dato che sarai in esecuzione tcpdumpo tsharkche hai il permesso di root. Nel caso in cui 22001 non sia una porta con numero elevato e anche altre utility come socatfaranno le cose.

Non credermi sulla parola però. Solo per provarlo possiamo generare pacchetti UDP multicast con socato ncat(generalmente impacchettati tramite nmap/ nmap-ncat).

Su alcuni host eseguire una delle due seguenti combinazioni:

Opzione 1:

sudo ip addr add 233.54.12.234/32 dev eth1 autojoin

Opzione 2:

socat -u UDP4-RECV:22001,ip-add-membership=233.54.12.234:eth1 /dev/null &

La prima opzione richiederà root o almeno la funzionalità CAP_NET_ADMIN . La seconda opzione non richiede root, ma si aspetta anche di essere eseguita in primo piano e quindi potrebbe essere meno favorevole allo scripting (anche se tracciare l'ID del processo figlio e ripulirlo con un trapin BASH potrebbe essere proprio quello che stai cercando.

Una volta fatto (ma prima di andare fuori di testa testando il nostro tcpdump/ tsharkcomando) assicurati che il kernel riconosca l'interfaccia che ha aderito al gruppo IGMP corretto. Se ti senti super fantasioso puoi impazzire analizzando l'esagono /proc/net/igmp, ma suggerirei solo di correre netstat -gn.

Una volta verificato che vedi l'interfaccia sottoscritta al gruppo corretto, avvia il tuo comando tcpdump:

tcpdump -nnXs 0 -i eth1 udp port 22001 and dst 233.54.12.234

In alternativa, se non vuoi seguire completamente la rotta di tcpdump (o inciampare su questa risposta e sei solo curioso di vedere il multicast in azione) puoi usare il socatcomando sopra per unirti e fare eco al contenuto STDOUTsostituendolo /dev/nullcon STDOUT:

socat -u UDP4-RECV:22001,ip-add-membership=233.54.12.234:eth1

Quindi, da un'altra macchina utilizzare una delle due seguenti opzioni per inviare alcuni semplici dati di test:

Opzione 1:

socat STDIO UDP-DATAGRAM:233.54.12.234:22001

Opzione 2:

ncat  -u 233.54.12.234 22001

Quando si esegue uno di questi comandi, attenderà in modo interattivo l'input. Digita solo alcune cose, premi invio per inviare, quindi CTRL+Dquando hai finito di inviare un EOFmessaggio.

A questo punto avresti dovuto vedere un test end-to-end e con pochi comandi creato il sistema di chat peggiore e più insicuro al mondo.


1
Caspita, ci sono voluti 4 anni per ottenere una risposta! Non lo faccio nemmeno più, e davvero non ho modo di testarlo, ma accetterò comunque.
John Dibling,

1
È utile proprio ora! : D Grazie Brian :)
quaylar
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.