nmap sul mio server web mostra le porte TCP 554 e 7070 aperte

Ho un server web che ospita vari siti Web per me. I due servizi accessibili all'esterno sono SSH e Apache2. Questi sono in esecuzione su una porta non standard e standard, rispettivamente. Tutte le altre porte vengono chiuse esplicitamente tramite arno-iptables-firewall. L'host sta eseguendo Debian Testing.

Ho notato che una scansione dell'host che utilizza nmap ha prodotto risultati diversi da diversi PC. Dal mio laptop sulla mia rete domestica (dietro un BT Homehub), ottengo quanto segue:

Not shown: 996 filtered ports
PORT     STATE SERVICE
80/tcp   open  http
554/tcp  open  rtsp
7070/tcp open  realserver
9000/tcp open  cslistener

mentre la scansione da un server con sede negli Stati Uniti con nmap 5.00 e un box Linux in Norvegia con nmap 5.21 ottengo quanto segue:

Not shown: 998 filtered ports
PORT     STATE SERVICE
80/tcp   open  http
9000/tcp open  cslistener

quindi spero che sia la mia rete interna o ISP a giocare, ma non posso esserne sicuro.

L'esecuzione di un netstat -l | grep 7070non produce nulla. Allo stesso modo per la porta 554.

Qualcuno può spiegare le peculiarità che sto vedendo?

Questo è molto probabilmente qualcosa in linea, quelle 2 porte (554/7070) sono per RealServer Realplayer.

http://service.real.com/firewall/adminfw.html

Sarei propenso a incolpare il tuo ISP o qualcosa tra te e il tuo server per questo. Se vuoi solo rassicurarti sul fatto che quelle porte sono davvero chiuse, potresti provare ad ascoltare su quelle porte e se ci riesce allora è lecito ritenere che non sia già in ascolto. Ecco cosa sto facendo sulla mia macchina (che ha Apache sulla porta 80 e niente sulla porta 81):

$ sudo netcat -p 80 -l --wait 1    # Apache on port 80
Error: Couldn't setup listening socket (err=-3)
$ sudo netcat -p 81 -l --wait 1    # Nothing on port 81
(Ctrl-C)

EDIT: E per essere sicuro che questo abbia davvero funzionato, telnetad esso da un'altra casella e controlla che netcatsta ricevendo ciò che invii (probabilmente vorrai aumentare il --waittimeout).

Il tuo router è probabilmente la colpa. Mi stavo solo chiedendo se questo fosse un problema con l'essere su un host OpenVZ e ho trovato questo articolo: le porte 21, 554 e 7070 sono aperte o chiuse? La risposta è si.

Questo ha senso per me, poiché attualmente sono su un pessimo router Fitec Actiontec. Qualsiasi combinazione di test nmap e netcat sul contenitore e sul nodo host conferma che tali porte non sono realmente aperte.

Vari router diversi (Verizon FiOS, BT Home Hub, Apple Airport Extreme, ...) mostrano le porte 554e sono 7070aperti per tutti gli IP per qualche motivo.

Hackerific »Porte TCP false positive!

Sono d'accordo con Nickgrim. Inoltre, potresti provare le scansioni nmap locali dalla casella stessa

Confronta l'output di questi:

nmap 127.0.0.1

nmap 1.2.3.4

Dove 1.2.3.4 è il tuo IP pubblico

Potrebbe trattarsi di un RTSP ALG (Application Layer Gateway) sull'hub di casa che intercetta il traffico e fornisce una risposta.

Stai usando una VM su ESXi Guest? Ho iniziato a ottenere risultati falsi 554/7070 quando ho spostato la mia VM Kali Linux da Workstation a ESXi. Puoi verificare la latenza:

nmap yourip --reason -p 7070 --traceroute

Controlla il diverso numero di hop delle porte 554 e 7070 con porte normali ...