nmap rileva la porta aperta ma non riesce a connettersi con telnet

Question

nmap rileva la porta aperta ma non riesce a connettersi con telnet

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

3

Ho effettuato una scansione su un singolo IP con nmap e segnala che la porta 65301 è aperta, e anche se rileva che è forse il servizio pcanywhere.

sudo nmap -p 65000-65535 -sV x.x.x.x
Starting Nmap 6.00 ( http://nmap.org ) at 2015-06-04 22:43 CEST
Nmap scan report for x.x.x.x
Host is up (0.96s latency).
Not shown: 336 closed ports
PORT      STATE SERVICE     VERSION
...
65003/tcp open  unknown
65301/tcp open  pcanywhere?
65308/tcp open  unknown
...

Ma quando provo a stabilire una connessione con quella porta con telnet, rifiuta semplicemente la connessione:

$ telnet  x.x.x.x 65301
Trying x.x.x. ...
telnet: Unable to connect to remote host: Connection refused

Quale potrebbe essere la causa della "connessione rifiutata": nmap ha restituito un falso rilevamento e la porta non è realmente aperta? O forse c'è qualche restrizione aggiuntiva che impedisce al telnet di connettersi anche se la porta è aperta?

Lo stesso accade con l'altra porta con servizio "sconosciuto", ma questo fatto che ha rilevato un possibile servizio (pcanywhere) ma telnet viene connesso mi intriga me stesso.

AGGIORNAMENTO: Allego i risultati dell'esecuzione del comando proposto da StackzOfZtuff, rileva la porta come chiusa, che penso sia il comportamento normale (inoltre il primo comando riporta ora la porta come chiusa ora):

$ sudo nmap -vv --packet-trace -p 65301 -sV x.x.x.x
...
Initiating SYN Stealth Scan at 10:24
Scanning x.x.x.x [1 port]
SENT (0.1877s) TCP y.y.y.y:53502 > x.x.x.x:65301 S ttl=53 id=3258 iplen=44  seq=3444593130 win=1024 <mss 1460>
RCVD (0.1881s) TCP x.x.x.x:36876 > y.y.y.y:41094 RA ttl=255 id=62429 iplen=40  seq=0 win=0 
RCVD (0.2064s) TCP x.x.x.x:21053 > y.y.y.y:41094 RA ttl=255 id=62430 iplen=40  seq=0 win=0 
RCVD (0.2084s) TCP x.x.x.x:42352 > y.y.y.y:41094 RA ttl=255 id=62431 iplen=40  seq=0 win=0 
RCVD (0.2110s) TCP x.x.x.x:4036 > y.y.y.y:41094 RA ttl=255 id=62432 iplen=40  seq=0 win=0 
RCVD (0.2308s) TCP x.x.x.x:30952 > y.y.y.y:41094 RA ttl=255 id=62433 iplen=40  seq=0 win=0 
RCVD (0.2352s) TCP x.x.x.x:65301 > y.y.y.y:53502 RA ttl=255 id=62434 iplen=40  seq=0 win=0 
Completed SYN Stealth Scan at 10:24, 0.05s elapsed (1 total ports)
Initiating Service scan at 10:24
NSE: Script scanning x.x.x.x.
NSE: Starting runlevel 1 (of 1) scan.
Nmap scan report for x.x.x.x
Host is up (0.0061s latency).
Scanned at 2015-06-06 10:24:17 CEST for 0s
PORT      STATE  SERVICE    VERSION
65301/tcp closed pcanywhere

unix attacks nmap network-scanners

posta Toni 05.06.2015 - 20:42

fonte

3 risposte

Leggi altre domande sui tag unix attacks nmap network-scanners

Come gestire un arresto SSL / TLS dannoso Strana linea di log di apache [duplicato]

score 2 · Answer 1

È possibile che il dispositivo stia consentendo solo connessioni da intervalli di indirizzi IP specificati (es: 192.168.1.0/24 per la sua sottorete locale). Quindi durante la scansione potrebbe mostrare la porta aperta e il telnet in esecuzione, a meno che non veda il tuo indirizzo IP in quell'intervallo, la tua connessione verrà rifiutata.

score 1 · Answer 2

1

Strano. Prova a scansionare quella porta con maggiore verbosità per vedere cosa sta succedendo.

sudo nmap -vv --packet-trace -p 65301 -sV x.x.x.x

risposta data 06.06.2015 - 09:46

fonte

score 0 · Answer 3

Dall'output del pacchetto-traccia, nmap ha inviato una richiesta SYN TCP alla porta 65301. Nmap ha quindi ricevuto una risposta da 65301 con un Reset-Acknowledge [RA] - sta confermando il pacchetto Syn, quindi ripristinando la connessione .

SENT (0.1877s) TCP y.y.y.y:53502 > x.x.x.x:65301 S ttl=53 id=3258 iplen=44  seq=3444593130 win=1024 <mss 1460>

RCVD (0.2352s) TCP x.x.x.x:65301 > y.y.y.y:53502 RA ttl=255 id=62434 iplen=40  seq=0 win=0

Stai ricevendo molte cose sulla porta 41094, quindi sembrerebbe che questa connessione richieda il funzionamento di più porte.

RCVD (0.1881s) TCP x.x.x.x:36876 > y.y.y.y:41094 RA ttl=255 id=62429 iplen=40  seq=0 win=0 
RCVD (0.2064s) TCP x.x.x.x:21053 > y.y.y.y:41094 RA ttl=255 id=62430 iplen=40  seq=0 win=0 
RCVD (0.2084s) TCP x.x.x.x:42352 > y.y.y.y:41094 RA ttl=255 id=62431 iplen=40  seq=0 win=0 
RCVD (0.2110s) TCP x.x.x.x:4036 > y.y.y.y:41094 RA ttl=255 id=62432 iplen=40  seq=0 win=0 
RCVD (0.2308s) TCP x.x.x.x:30952 > y.y.y.y:41094 RA ttl=255 id=62433 iplen=40  seq=0 win=0

Poiché tutte le rimonte delle connessioni hanno [RA], anche queste vengono resettate. È molto probabile che per stabilire correttamente la connessione, è necessario fornire alcuni dati iniziali / cookie / header, qualcosa per stabilire una comunicazione.

Questa porta è contrassegnata come Open perché ricevi un bel po 'di dati in risposta al pacchetto SYN, ma c'è un pezzo mancante per stabilire correttamente un canale di comunicazione.