Scopri che software Linux sta cercando di chiamare a casa

Question

Scopri che software Linux sta cercando di chiamare a casa

#1 da (2 voti)
#2 da (0 voti)
#3 da (0 voti)
#4 da (-1 voti)

4

Ho visto alcune comunicazioni sospette in uscita bloccate sul mio VPS, che ospita un piccolo sito Web sperimentale, e voglio scoprire quale applicazione sta facendo il tentativo. Il server sta eseguendo CentOS e sto usando iptables per il firewall. Ecco un estratto dal mio set di regole iptables:

# create a new chain for rejecting certain ip addresses  
-N input_tcp_deny  
-A input_tcp_deny -m limit --limit 5/min -j LOG --log-prefix "tcp/ip input denied " --log-level 6  
-A input_tcp_deny -j REJECT  

# create a new chain for rejecting certain ip addresses  
-N output_tcp_deny  
-A output_tcp_deny -m limit --limit 5/min -j LOG --log-prefix "tcp/ip output denied " --log-level 4  
-A output_tcp_deny -j REJECT  

-A INPUT -p tcp -s 171/8 -j input_tcp_deny  
-A OUTPUT -p tcp -d 171/8 -j output_tcp_deny  
-A INPUT -p tcp -s 141/8 -j input_tcp_deny  
-A OUTPUT -p tcp -s 141/8 -j output_tcp_deny  
-A INPUT -p tcp -s 103/8 -j input_tcp_deny  
-A OUTPUT -p tcp -d 103/8 -j output_tcp_deny

% output diiptbles -nvL mostra:

Chain output_tcp_deny (91 references)  
 pkts bytes target     prot opt in     out     source               destination  
    6   120 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/min burst 5 LOG flags 0 level 4 prefix 'tcp/ip output denied '  
    6   120 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable

L'aspetto del file di registro iptables mostra:

Apr  9 00:19:25 servername kernel: tcp/ip output denied IN= OUT=eth0 SRC=serverip4addr DST=171.64.65.117 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=15407 DF PROTO=TCP SPT=46898 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0  
Apr  9 00:19:25 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.214.186.162 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=TCP SPT=80 DPT=54582 WINDOW=14480 RES=0x00   ACK SYN URGP=0  
Apr  9 00:19:25 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.219.155.233 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=0 DF PROTO=TCP SPT=80 DPT=54760 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr  9 00:19:26 servername kernel: tcp/ip output denied IN= OUT=eth0 SRC=serverip4addr DST=171.64.65.117 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=15408 DF PROTO=TCP SPT=46898 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0  
Apr  9 00:19:26 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.214.186.162 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=TCP SPT=80 DPT=54582 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr  9 00:19:26 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.219.155.233 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=0 DF PROTO=TCP SPT=80 DPT=54760 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr  9 00:19:26 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.214.186.162 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=TCP SPT=80 DPT=54582 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr 12 11:48:55 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.214.186.162 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=TCP SPT=80 DPT=54742 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr 12 11:48:55 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.216.10.182 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=49 ID=0 DF PROTO=TCP SPT=80 DPT=53542 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr 12 11:48:56 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.214.186.162 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=TCP SPT=80 DPT=54742 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr 12 11:48:56 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.214.186.162 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=TCP SPT=80 DPT=54742 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr 12 11:48:58 servername kernel: tcp/ip output denied IN= OUT=eth0 SRC=serverip4addr DST=103.25.63.44 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=43399 DF PROTO=TCP SPT=45638 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0  
Apr 12 11:48:58 servername kernel: tcp/ip input denied IN=eth0 OUT= MAC=macnotshared SRC=141.214.186.162 DST=serverip4addr LEN=60 TOS=0x00 PREC=0x00 TTL=48 ID=0 DF PROTO=TCP SPT=80 DPT=54742 WINDOW=14480 RES=0x00 ACK SYN URGP=0  
Apr 12 11:48:59 servername kernel: tcp/ip output denied IN= OUT=eth0 SRC=serverip4addr DST=103.25.63.44 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=43400 DF PROTO=TCP SPT=45638 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0  
Apr 12 11:49:01 servername kernel: tcp/ip output denied IN= OUT=eth0 SRC=serverip4addr DST=163.178.174.25 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=59335 DF PROTO=TCP SPT=37733 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0  
Apr 12 11:49:02 servername kernel: tcp/ip output denied IN= OUT=eth0 SRC=serverip4addr DST=163.178.174.25 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=59336 DF PROTO=TCP SPT=37733 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0

Ricerca degli indirizzi IP per le comunicazioni in uscita bloccate:
- 171.64.65.117 stanford.edu
- 103.25.63.44 Centro dati all'ingrosso di Hong Kong LLC

Le comunicazioni bloccate in entrata si sono verificate molto vicino nel tempo, quindi ho cercato anche quelle:
- 141.214.186.162 Università del Michigan
- 141.219.155.233 mtu.edu (Università del Michigan)
- 141.216.10.182 umflint.edu (Università del Michigan)

Per chi è curioso, ho anche IPV6 completamente bloccato (ma nessun log) e ho visto questo da ip6tables -nvL :

Chain OUTPUT (policy DROP 8 packets, 536 bytes)

Quindi ho date, orari e indirizzi IP. Ma ora vorrei scoprire quale software open source sta facendo questo.

linux firewalls forensics iptables

posta John L 16.04.2014 - 05:58

fonte

4 risposte

Leggi altre domande sui tag linux firewalls forensics iptables

Kerberos attacca le domande Quanto è sicuro OAuth 2.0 basato su JavaScript

score 2 · Answer 1

Se hai installato auditd, puoi usarlo per registrare le connessioni:

auditctl -a exit,always -F arch=b64 -S connect -k NETWORK

Se hai un sistema operativo a 32 bit, usa b32 piuttosto che b64.

Ora dovresti essere in grado di cercare nei file dei registri auditd in / var / log / per trovare i processi che stabiliscono le connessioni in uscita.

Sfortunatamente, il file audit.log è un po 'criptico. Ecco un esempio dei miei registri dopo l'esecuzione di "nc 8.8.8.8 53":

type=SYSCALL msg=audit(1401890039.928:1080289): arch=c000003e syscall=42 success=no exit=-115 a0=3 a1=df3310 a2=10 a3=7fffd8db6910 items=0 ppid=7310 pid=7725 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=pts5 comm="nc" exe="/bin/nc.openbsd" key="NETWORK"
type=SOCKADDR msg=audit(1401890039.928:1080289): saddr=02000035080808080000000000000000

Nella riga type = SYSCALL, puoi vedere l'id del processo, il cmd "/bin/nc.openbsd" e le informazioni sull'uid che esegue il processo. Nella riga type = SOCKADDR, hai il campo saddr contenente informazioni sulla connessione ip / tcp:

02000035080808080000000000000000

02 = IP
35 = Port 53
08080808 = 8.8.8.8

Se si desidera cercare l'indirizzo IP 163.178.174.25, si potrebbe fare quanto segue in python per ottenere la rappresentazione esadecimale di questo IP.

$ python
Python 2.7.4 (default, Sep 26 2013, 03:20:26) 
[GCC 4.7.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct, socket
>>> "%x" % struct.unpack("<L", socket.inet_aton("163.178.174.25"))[0]
'19aeb2a3'

Quindi, puoi eseguire il comando di auditing.log per le occorrenze di questa stringa esadecimale per trovare l'applicazione incriminata.

E infine, una volta terminato il debug, ricorda di disattivare la regola di auditd, poiché può produrre una discreta quantità di log.

auditctl -d exit,always -F arch=b64 -S connect -k NETWORK

Happy hacking!

Credito a risposte su serverfault:

link

score 0 · Answer 2

Potresti usare un ciclo per chiamare continuamente lsof per vedere tutte le connessioni di rete aperte, collegarlo a un file e quindi passarci attraverso per la porta 80. Questo mostrerebbe il processo che apre il socket e l'utente in cui è in esecuzione.

Potrebbe essere qualcosa di simile a:

#!/bin/bash
# monitor.sh
while true; do
    date
    lsof -i -P
    sleep 1
done

Per usarlo:

$ chmod +x monitor.sh
$ sudo ./monitor.sh > connections.log

Per controllarlo:

$ grep ":80 (" connections.log

Includendo "(" nel modello di grep in modo che corrisponda all'output di lsof, grep deve corrispondere solo alle connessioni in uscita alla porta 80.

Vorrei grep il registro ogni paio di ore e vorrei anche testarlo prima per assicurarsi che il file di registro non diventasse troppo grande e manchi tutto il mio spazio su disco.

score 0 · Answer 3

Oltre alle altre buone risposte (in particolare, auditd), la tua situazione potrebbe richiedere quanto segue:

Rimuovi il parametro --ulimit da iptables, per assicurarti che non manchi alcuna connessione
Reindirizzare i registri su un file di registro diverso o anche su una diversa funzione di registro
Configura syslog per rilevare tale funzionalità e reindirizzare a una pipe (vedi questo link per un esempio)
Scrivi uno script di shell che legge il contenuto della pipe e dopo aver ricevuto un evento:
1. esegue lsof o netstat -nalp per acquisire PID e binari offensivi
2. avvia una sessione tcpdump per acquisire il traffico
3. invia e-mail in modo che tu possa agire rapidamente:)

La mia scommessa è su qualche pezzo innocuo di software come un contest di popolarità , un daemon NTP o un aggiornamento software. Comunque sono curioso quindi tienici aggiornato per favore!

score -1 · Answer 4

Dopo aver valutato il rischio di disattivare i miei iptables per alcuni minuti, questi sarebbero stati i miei primi passi:

interrompi il processo iptables per consentire all'app open-source di avviare una connessione home (di nuovo, solo se ritieni sicuro di farlo)
Esegui netstat -lntp | less . Questo elenco dovrebbe indicare gli IP di destinazione a cui si connette la casella. Se trovi quelli che hai elencato sopra, prova a cercare l'ID processo (PID) per quella connessione.
Esegui ps aux | less . Prova a individuare lo stesso PID che hai trovato nel passaggio 2 sopra. Potrebbe essere necessario fare un po 'di scavo e giocare con le opzioni di questo comando. Questa pagina potrebbe essere utile.
restart iptables
riavvia il server (potrebbe non essere necessario, ma a volte questo è quello che serve all'open-source per chiamare di nuovo a casa, a meno che tu non sappia già che il call-home è costante)
controlla di nuovo il iptables . I prossimi passi dipenderanno dai tuoi risultati qui.

Poiché ti è stato chiesto solo come identificare , piuttosto che bloccare questo traffico, mi fermerò qui; spero che questo ti possa aiutare un po '.