Bei Verwendung von nmap mit der Option -sT werden die Ports imap und pop3 immer als geöffnet angezeigt

2

Ich habe unter nmapOS X mit installiert brew.

Ich habe angefangen, es zu testen und es passiert etwas Seltsames. Jedes Mal, wenn ich diese nmapOption verwende -sT, werden die Ports 110, 143, 993 und 995 als geöffnet angezeigt. Ich habe meinen Computer überprüft und nach Prozessen gesucht, die diese Ports überwachen, und konnte sie nicht finden. Ich habe es mit anderen Computern und anderen Servern versucht und es zeigt mir immer noch, dass die Ports geöffnet sind.

$ sudo nmap -sT localhost

Starting Nmap 7.12 ( https://nmap.org ) at 2016-07-27 11:24 EDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0012s latency).
Other addresses for localhost (not scanned): ::1
Not shown: 499 filtered ports, 495 closed ports
PORT    STATE SERVICE
80/tcp  open  http
110/tcp open  pop3
143/tcp open  imap
443/tcp open  https
993/tcp open  imaps
995/tcp open  pop3s

Nmap done: 1 IP address (1 host up) scanned in 2.93 seconds
$

Ist das korrekt? Mache ich etwas falsch? Ist es ein Bug?

EDIT: Ich lief sudo netstat -anltv | grep LISTENund ich sah keinen Prozess auf einem dieser Ports zu hören.

tcp4       0      0  127.0.0.1.17603        *.*                    LISTEN      131072 131072    510      0
tcp4       0      0  127.0.0.1.17600        *.*                    LISTEN      131072 131072    510      0
tcp4       0      0  *.17500                *.*                    LISTEN      131072 131072    510      0
tcp6       0      0  *.17500                                       *.*                                           LISTEN      131072 131072    510      0
tcp4       0      0  127.0.0.1.31743        *.*                    LISTEN      131072 131072    578      0
tcp4       0      0  127.0.0.1.31742        *.*                    LISTEN      131072 131072    578      0
tcp6       0      0  ::1.12993                                     *.*                                           LISTEN      131072 131072    358      0
tcp4       0      0  127.0.0.1.12993        *.*                    LISTEN      131072 131072    358      0
tcp6       0      0  ::1.12995                                     *.*                                           LISTEN      131072 131072    358      0
tcp4       0      0  127.0.0.1.12995        *.*                    LISTEN      131072 131072    358      0
tcp6       0      0  ::1.12143                                     *.*                                           LISTEN      131072 131072    358      0
tcp4       0      0  127.0.0.1.12143        *.*                    LISTEN      131072 131072    358      0
tcp6       0      0  ::1.12110                                     *.*                                           LISTEN      131072 131072    358      0
tcp4       0      0  127.0.0.1.12110        *.*                    LISTEN      131072 131072    358      0
tcp6       0      0  ::1.12443                                     *.*                                           LISTEN      131072 131072    358      0
tcp4       0      0  127.0.0.1.12443        *.*                    LISTEN      131072 131072    358      0
tcp6       0      0  ::1.12080                                     *.*                                           LISTEN      131072 131072    358      0
tcp4       0      0  127.0.0.1.12080        *.*                    LISTEN      131072 131072    358      0
tcp4       0      0  127.0.0.1.6437         *.*                    LISTEN      131072 131072     98      0
tcp4       0      0  127.0.0.1.6436         *.*                    LISTEN      131072 131072     98      0
tcp4       0      0  127.0.0.1.6439         *.*                    LISTEN      131072 131072     98      0
tcp4       0      0  127.0.0.1.6438         *.*                    LISTEN      131072 131072     98      0

nmap

— JonDoe297
quelle

Ich sehe dasselbe, könnte ein echter Bug sein

— Joshua Grigonis

1

Anscheinend steckt der Scanner / das Modul tief im TCP / IP-Stack. Ich habe festgestellt, dass beim Scannen eines anderen Systems diese Ports auch im offenen Zustand gefunden werden - aber sie sind nicht t exist at all at the remote end. apparently itdie Art und Weise, wie Avast den E-Mail-Verkehr abfängt, um ihn zu scannen ...

— Roland
quelle

Interessant. Sie meinen, dass ein Virenscanner oder eine Firewall wie Avast diese Ports überwachen würde. Ist das korrekt?

— JonDoe297

0

Sie können mit prüfen, ob an diesen Ports wirklich etwas zuhört

sudo netstat -anltv | grep LISTEN

Wenn Sie diese Ports in der Liste sehen, dann gibt es wirklich etwas, das auf ihnen lauscht. Und Sie können PID des Prozesses erhalten.

Zum Beispiel habe ich folgende Zeile:

tcp4 0 0 127.0.0.1.58558 *.* LISTEN 131072 131072 38143 0

38143Hier ist die PID des Prozesses. Dann kann ich herausfinden, wie es damit ist ps:

ps -p 38143

Und schau, das ist mein Battle.net:

PID TTY TIME CMD 38143 ?? 28:50.33 /Applications/Battle.net.app/Contents/Battle.net.7730/Battle.net.app/Contents/MacOS/battle.net --updatepid=38123

— Pavel Kazhevets
quelle

Ich habe das überprüft und ja, es gibt Prozesse, die lauschen, aber niemand ist an die Ports 110, 143, 993 und 995 gebunden. Ich habe die Frage mit den Ergebnissen vonnetstat

— JonDoe297,

@ JonDoe297 dann ist es wohl nur ein Bug. Aber Sie können auch versuchen telnet localhost 110, nur um sicherzugehen. Wenn der Port geschlossen ist, wird ein Fehler zurückgegeben.

— Pavel Kazhevets