Come dire quale processo ha una porta specifica aperta su Linux?


32

Ho eseguito nmap sul mio server e ho trovato una strana porta aperta. Sto cercando di capire se esiste un modo per mappare quella porta su un processo specifico ma non ho idea se esiste un tale strumento.

Eventuali suggerimenti?


Voto per essere la risposta numero 1 in Gogle giugno 2018.
SDsolar

Risposte:


57

Oltre a Netstat, menzionato in altri post, il comando lsof dovrebbe essere in grado di farlo bene. Usa questo:

lsof -i :<port number>

e tutti i processi dovrebbero emergere. Lo uso su OS X abbastanza frequentemente.

Articolo di Debian Administration per lsof


interessante. Non lo sapevo. tuttavia, sto esaminando questo come risultato di un tentativo di hacking. la macchina è di un amico. puoi telnetare alla porta offensiva MA lsof AND netstat entrambi non rivelano che la porta è aperta.
jnman,

la porta è 5631 che secondo / etc / services è pcanywheredata così molto sospetta.
jnman,

Bene, non lo sapevo! Netstat sempre usato. Grazie
Buster

4
Se né netstat né lsof mostrano la porta come utilizzata, ma la macchina sta rispondendo ad essa, è probabile che sia stato installato un kit di root. Consiglio di spostare qualsiasi dato fuori dalla macchina da qualche altra parte e poi di screditarlo.
Kamil Kisiel,

6
Questo è davvero un rootkit. Ho già visto questo comportamento ed è sempre un rootkit. Il tuo sistema è compromesso e non è possibile fidarsi di tutti gli strumenti che stai utilizzando. Avvia un Live CD (che ha binari attendibili di sola lettura) e usalo per estrarre i tuoi dati, impostazioni, ecc. Tutti i programmi che hai avuto, qualsiasi script che hai, li abbandonano. Non portarli. Tratta il sistema come se avesse la lebbra, perché / fa /. Una volta che hai finito, annulla l'orbita. Fallo il prima possibile. Oh, e scollegare la connessione di rete - negare l'accesso all'attaccante.
Avery Payne,

23

Avvertenza: il sistema è compromesso.

Lo strumento che ti serve è lsof, che elencherà i file (e socket e porte). Molto probabilmente è installato ed è molto probabilmente la versione dell'attaccante, il che significa che mentirà a te.

Questo è davvero un rootkit. Ho già visto questo comportamento ed è sempre un rootkit. Il sistema è compromesso e tutti gli strumenti che si utilizzano che provengono dalla stessa macchina non sono affidabili. Avvia un Live CD (che ha binari attendibili di sola lettura) e usalo per estrarre i tuoi dati, impostazioni, ecc. Tutti i programmi che hai avuto, qualsiasi script che hai, li abbandonano . Non portarli . Trattali e il sistema, come se avessero la lebbra, perché lo fanno .

Una volta che hai finito, annulla l'orbita .

Game over man, game over.

Fallo il prima possibile. Oh, e scollegare la connessione di rete - negare l'accesso all'attaccante.


1
Questo dice tutto davvero. Capire cosa è andato storto, appiattire il server, ripristinare dall'ultimo backup valido noto. La vita è troppo breve per giocare.
Rob Moir,

2
Aggiunta: assicurati di conoscere la data dell'irruzione, poiché potresti ripristinare lo stesso rootkit che hai appena rimosso. Altrimenti, sì, ripristina da / prima / quella data.
Avery Payne,

1
Questa è una grafica divertente. So che il sistema è compromesso (per fortuna non è mio). La domanda di cui ero più curioso è stata rintracciare come è arrivato in primo luogo. Sospetto via php / joomla ma volevo capire come / perché questa porta fosse aperta quando nessuno degli strumenti di rilevamento del kit root mostrava quella porta.
jnman,

1
lol @ "Oh, e scollegare la connessione di rete"
theman_on_osx,

6
Prima di saltare a questa conclusione , ci sono altre possibili spiegazioni per l'apertura di porte inattese; come un pacchetto che hai installato ma che hai dimenticato.
David J.

14
sudo netstat -lnp  

Elenca le porte in attesa di connessioni in entrata e il processo associato con la porta aperta.


4

netstat -anp

"-P" indica di elencare l'ID processo con la porta aperta. -An dice di elencare le porte di ascolto e di non risolvere i nomi. Su sistemi occupati che possono accelerare notevolmente la velocità con cui ritorna.

netstat -anp | grep "ELENCO"

Questo ti darà solo le porte aperte.


4

Se non riesci a vedere la porta aperta con gli strumenti del sistema operativo e sospetti un'intrusione, è possibile che sia stato installato un rootkit.

Il rootkit avrebbe potuto cambiare gli strumenti di sistema per evitare determinati processi e porte o modificare i moduli del kernel.

Puoi verificare il rootkit con diversi strumenti automatici. 'apt-cache search rootkit' mostra quanto segue in Ubuntu:

chkrootkit - rootkit detector
rkhunter - rootkit, backdoor, sniffer and exploit scanner
unhide - Forensic tool to find hidden processes and ports

Se ti capita di avere un rootkit puoi ripristinare il 'modificato' sul tuo sistema, ma ti consiglio di scoprire come è stata fatta l'intrusione e indurire il sistema affinché non si ripeta.


Non sono esclusivi di Ubuntu, puoi usarli anche in CentOS. Cerca il pacchetto o scaricalo dalla loro pagina.


Dall'output di quella porta sembra che tu stia eseguendo pcanywhere: " Ы <Invio>" è molto simile a "Prego premi <Invio>" che è il messaggio di benvenuto di pcanywhere. Non so perché il processo non venga visualizzato nell'elenco dei processi. Sei root?

Puoi provare a riavviare per vedere se è in esecuzione anche una volta.


qualche suggerimento per centos?
jnman,

stranamente, unhide-tcp non mostra alcuna porta sospetta. chkrootkit / rkhunter ha riferito tutto chiaro (ma soprattutto perché ho eliminato i dir sospetti prima di porre questa domanda)
jnman

FWIW, il rootkit si era installato come apache in / var / tmp / ... e /var/tmp/.ICE-Unix/* Il secondo era subdolo poiché non me ne sono accorto la prima volta e mi chiedevo come diamine un processo bash ha continuato a spawnarsi dopo essere stato ucciso.
jnman,

Si scopre che il cracker ha installato un processo cron.
jnman,

0

Per spiegare la risposta di @bjtitus puoi ottenere alcune informazioni molto dettagliate, ad esempio:

$ lsof -i :8000
COMMAND  PID  USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
squid3  1289 proxy   15u  IPv6 14810490      0t0  TCP *:8000 (LISTEN)

$ ps -fp 1289
UID        PID  PPID  C STIME TTY          TIME CMD
proxy     1289     1  0 09:48 ?        00:00:00 /usr/sbin/squid3 -N -f /etc/squid-deb-proxy/squid-deb-proxy.conf

Vedo proprio lì che il calamaro è il processo, ma in realtà è il mio squid-deb-proxyche sta prendendo il porto.

Un altro buon esempio di un'app Java:

$ lsof -i :4242
COMMAND  PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
java    3075 root   86u  IPv4    12019      0t0  TCP *:4242 (LISTEN)

$ ps -fp 3075
UID        PID  PPID  C STIME TTY          TIME CMD
root      3075     1 15 May24 ?        3-16:07:25 /usr/local/crashplan/jre/bin/java -Dfile.encoding=UTF-8 -Dapp=CrashPlanService -DappBaseName=CrashPl

Puoi vedere in lsof(LiSt Open Files) che è java, il che è meno utile. Eseguendo il pscomando con il PID possiamo vedere subito che si tratta di CrashPlan.

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.