Using nmap with -sT option always shows imap and pop3 ports as opened

Question

I installed nmap on OS X using brew.

I started to test it and something weird is happening. Every time I use nmap with the option -sT, it always shows the ports 110, 143, 993 and 995 as opened. I checked my computer, looking for process that are listening on that ports, and I could not find them. I tried with other computers and different servers, and it is still showing me that ports as opened.

$ 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
$

Is that correct? Am I doing something wrong? Is it a bug?

EDIT: I ran sudo netstat -anltv | grep LISTEN and I didn't see a process listening on one of those ports.

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

I see the same thing, might be a real bug – Joshua Grigonis Apr 12 '17 at 21:30 — Joshua Grigonis, Apr 12 '17 at 21:30

score 2 · Answer 1 · edited Mar 07 '24 at 13:06

2

Apparently, that scanner/module plugs deep into the TCP/IP stack. I found that when I scan another systems, these ports are also found in open state - but they don't exist at all at the remote end. Apparently it's the way how Avast intercepts mail traffic to scan into that...

edited Mar 07 '24 at 13:06

Alexey Vazhnov

194

answered Oct 05 '17 at 13:31

roland

21

1

Interesting. You mean that a Virus scanner or a firewall like Avast would be listening on those ports. Is that correct? – JonDoe297 Oct 05 '17 at 14:35

score 0 · Answer 2 · answered Jul 27 '16 at 16:20

0

You can check if something is really listening on that ports with

sudo netstat -anltv | grep LISTEN

If you see that ports in the list, then there are really something listening on them. And you can get PID of process.

For example, I have following row:

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

38143 here is PID of process. Then I can figure out what it is with ps like this:

ps -p 38143

And look, thats my 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

answered Jul 27 '16 at 16:20

Pavel Kazhevets

311

I checked that, and yes, there are processes listening , but no one is binded to ports 110, 143, 993 and 995. I updated the question with the results of netstat – JonDoe297 Jul 27 '16 at 18:42
@JonDoe297 then I guess it is just a bug. But you also can try to telnet localhost 110, just to make sure. If port is closed, then it will return you error. – Pavel Kazhevets Jul 27 '16 at 21:01

Using nmap with -sT option always shows imap and pop3 ports as opened

2 Answers2