dump connessioni tcp senza tcpdump

In un centos box, mi piace scaricare le connessioni tcp - vorrei vedere se un server tenta di inviare richieste a un determinato IP. Di solito tcpdump farebbe il trucco, ma tcpdump non è installato e l'installazione del software non è un'opzione (a causa dei criteri aziendali). Temo che netstat non mi mostri una singola richiesta.

Quindi mi chiedevo quali altre opzioni ho. Ho accesso root sul server.

Sicuramente hai python?

from socket import * 
from struct import unpack 
import sys 

INTERFACE = "eth0"
TARGET = "8.8.8.8" 

if __name__ == "__main__": 
  sock = socket(AF_PACKET, SOCK_DGRAM, 0x0800) 
  sock.bind((INTERFACE, 0x0800)) 
  while True: 
    data = sock.recvfrom(1500, 0)[0] 
    ip = inet_ntop(AF_INET, data[12:16]) 
    if ip == TARGET: 
      print "GOT TARGET" 
      sys.exit(1)

Questo uscirà con "GOT TARGET" fornendo l'indirizzo IP che ritorna alle partite. Dal momento che TCP deve inviare qualcosa durante una stretta di mano, questo dovrebbe catturare qualsiasi cosa da un indirizzo target specifico. Tuttavia, non importa se il protocollo è TCP o UDP (né controllo).

Non dimenticare di cambiare TARGET e INTERFACE.

Proverei davvero a ottenere tcpdump. Detto questo, alcune alternative per vedere se esiste una determinata connessione per un IP sono:

strace:

[kbrandt@ny-kbrandt01: ~] strace -e trace=network nc 1.2.3.4 1234
...
socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(1234), sin_addr=inet_addr("1.2.3.4")}, 16) = -1 EINPROGRESS (Operation now in progress)

lsof:

[kbrandt@ny-kbrandt01: ~] nc 1.2.3.4 1234 &
[1] 11434
[kbrandt@ny-kbrandt01: ~] lsof -p 11434
....
nc      11434 kbrandt    3u  IPv4 4543149      0t0     TCP 10.7.0.78:58886->1.2.3.4:search-agent (SYN_SENT)

netstat:

[kbrandt@ny-kbrandt01: ~] nc 1.2.3.4 1234 &
[1] 11486
[kbrandt@ny-kbrandt01: ~] sudo netstat -a -p | grep 11486
tcp        0      1 10.7.0.78:58891             1.2.3.4:search-agent        SYN_SENT    11486/nc

Iptables ha una funzionalità di debug e può essere utilizzata anche per l'analisi del traffico.

La soluzione è descritta nell'URL seguente.

Regole di debug in Iptables

Vale anche la pena leggere il seguente URL per impostare la registrazione dell'output di traccia in un file a scelta.

http://backreference.org/2010/06/11/iptables-debugging/

Non considererei questa soluzione uguale a tcpdump, ma può essere fatta usando un'installazione minima di Centos. Devi fare attenzione a non riempire il disco con i registri, perché tcpdump è molto più efficiente nell'uso del disco. Disattiva la registrazione quando non è necessaria.

È possibile utilizzare quanto segue come modello di base nello script.

# Logging
log(){
SOURCE=a.b.c.d (IP address)
$IPT -A INPUT   -s $SOURCE -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "In: "
$IPT -A OUTPUT  -s $SOURCE -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "Out: "
$IPT -A FORWARD -s $SOURCE -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "Fw: "
$IPT -t nat -A POSTROUTING -m limit --limit 50/minute -j LOG --log-level 7 --log-prefix "Nat: "
}
#log  (remove comment to enable)

trace(){
iptables -t raw -A PREROUTING -p tcp  -j TRACE
iptables -t raw -A OUTPUT     -p tcp  -j TRACE
}
#trace (remove comment to enable)

Se hai bisogno di un software specifico per svolgere il tuo lavoro e non ti è permesso, o non stai facendo un buon caso aziendale o vendendo le tue idee alle persone giuste ... o non hai il controllo di questo sistema .. .

Se avessi il compito di fare qualcosa e avessi bisogno del tipo di informazioni di debug / risoluzione dei problemi richieste in questo caso, utilizzerei lo strumento giusto. È probabile tcpdumpo tshark. Sì, quelli sono pezzi di software, ma li considero utilità più essenziali . In realtà, sono utility che potrebbero essere installate o caricate temporaneamente sul sistema e rimosse senza incidenti (è possibile utilizzare supporti rimovibili? ... suggerimento )

Ma il punto è che una soluzione alternativa alla politica aziendale richiede probabilmente più sforzo che ottenere l'approvazione per questo caso d'uso.

Kyle ha offerto alcune ottime opzioni. Un altro sarebbe usare iptables:

[james@server ~]$ sudo iptables -I OUTPUT -d 1.2.3.4/32
...
[james@server ~]$ sudo iptables -L OUTPUT -n -v
Chain OUTPUT (policy ACCEPT 105 packets, 35602 bytes)
 pkts bytes target  prot opt in  out  source      destination
   87 33484 LOG     all  --  *   *    0.0.0.0/0   1.2.3.4     LOG flags 0 level 4

Questa è essenzialmente una regola contabile. Non consente esplicitamente o nega il traffico, quindi viene utilizzata la politica predefinita per la catena OUTPUT (che per impostazione predefinita è ACCETTA). Tuttavia, qualsiasi pacchetto corrispondente aumenterà i contatori per la regola.

Se lo desideri, puoi anche registrare i dettagli sul pacchetto con l' -j LOGopzione:

[james@server ~]$ sudo iptables -I OUTPUT -d 1.2.3.4/32 -j LOG
...
[james@server ~]@ dmesg | grep 1.2.3.4 | tail -1
IN= OUT=eth0 SRC=192.168.1.1 DST=1.2.3.4 LEN=100 TOS=0x10 PREC=0x00 TTL=64 ...

I log andranno alla funzione di logging del kernel, quindi dovrebbe apparire in / var / log / messages sui derivati ​​Red Hat e /var/log/kern.log sui derivati ​​Debian. Sarebbe anche visibile nell'output di dmesg, come mostrato. A differenza tcpdump, tuttavia, non registrerà il contenuto completo del pacchetto, ma solo il contenuto dell'intestazione del pacchetto.

Dal momento che il tuo server si sta connettendo a un determinato IP, presumo che sarà a una porta di cui sei a conoscenza?

In ogni caso, netstato sssono progettati per fare quello che vuoi. Puoi fare lo stesso con entrambi i comandi:

netstat -n -t | awk '{print $5}' | grep A.B.C.D:n
ss      -n -t | awk '{print $5}' | grep A.B.C.D:n

dove A.B.C.Drappresenta un indirizzo IPv4 e n rappresenta un numero di porta a cui il server si sta connettendo sul lato remoto. Per esempio:

ss      -n -t | awk '{print $5}' | grep 10.137.54.22:3389

Oppure, se vuoi solo sapere che la connessione è stata stabilita:

ss      -n -t | awk '{print $5}' | grep -q 10.137.54.22:3389 && echo "CONNECTION MADE"

Se non si conosce il numero di porta a cui si sta tentando di connettersi, il lavoro sarebbe più difficile poiché TCP aprirà una porta su entrambi i lati della conversazione per i dati e i pacchetti ACK. In tal caso, è possibile richiedere semplicemente l'indirizzo IP per mostrare che è stata stabilita una connessione, che sia da o verso.

Infine, puoi eseguire questo ciclo in base al contenuto del tuo cuore da utilizzare come strumento di monitoraggio:

while true; do
    ss -n -t | awk '{print $5}' | grep -q A.B.C.D:n && \
        echo "CONNECTION MADE" && \
        exit 0
    sleep 1
done