Connection to ports 2000 and 5060 successful despite filtering

Question

I run my own (Ubuntu based) router and have iptables configured to drop all incoming packets by default. To my surprise, running an nmap scan (from the WAN side) shows two open ports related to VOIP:

nmap -Pn -v --reason XXX.net

Starting Nmap 7.60 ( https://nmap.org ) at 2018-03-28 09:52 CEST
Initiating Parallel DNS resolution of 1 host. at 09:52
Completed Parallel DNS resolution of 1 host. at 09:52, 0.09s elapsed
Initiating Connect Scan at 09:52
Scanning XXX.net (XXX.XXX.XXX.XXX) [1000 ports]
Discovered open port 21/tcp on XXX.XXX.XXX.XXX
Discovered open port 22/tcp on XXX.XXX.XXX.XXX
Discovered open port 5060/tcp on XXX.XXX.XXX.XXX
Discovered open port 2000/tcp on XXX.XXX.XXX.XXX
Completed Connect Scan at 09:52, 5.17s elapsed (1000 total ports)
Nmap scan report for XXX.net (XXX.XXX.XXX.XXX)
Host is up, received user-set (0.035s latency).
Not shown: 995 filtered ports
Reason: 995 no-responses
PORT     STATE  SERVICE    REASON
21/tcp   open   ftp        syn-ack ttl 52
22/tcp   open   ssh        syn-ack ttl 54
113/tcp  closed ident      reset ttl 254
2000/tcp open   cisco-sccp syn-ack ttl 61
5060/tcp open   sip        syn-ack ttl 61

Read data files from: /usr/local/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 5.33 seconds

ftp and ssh are correct, as these two services are configured on the router. But cisco-sccp and sip being open is news to me.

Indeed, a telnet connection to both ports is successful:

telnet XXX.net 2000
Trying XXX.XXX.XXX.XXX...
Connected to XXX.net.
Escape character is '^]'.

telnet XXX.net 5060
Trying XXX.XXX.XXX.XXX...
Connected to XXX.net.
Escape character is '^]'.

But running netstat -talpn on the router while the telnet session is active shows no established connection for either port. And the log shows that iptables drops the packets:

Mar 27 20:52:16 router DROP INPUT  IN=ppp0 OUT= MAC=MM:MM:MM:M SRC=YYY.YYY.YYY.YYY DST=XXX.XXX.XXX.XXX LEN=60 TOS=00 PREC=0x00 TTL=51 ID=39215 DF PROTO=TCP SPT=52200 DPT=2000 SEQ=106277563 ACK=0 WINDOW=42340 SYN URGP=0 MARK=0

where YYY.YYY.YYY.YYY is the IP that telnet connects from.

Is my diagnosis correct?

If yes, how can telnet establish a connection, even though the packets are dropped at the router? Who is listening on ports 2000 and 5060?

Answer 1

There is something between the scanner and the target that is responding on behalf of the target, spoofing its source address so as to appear to be the target itself. When you ran the Nmap scan as root with --reason -v, it showed the IP Time-to-Live (TTL) values of the response packets for each port:

PORT     STATE  SERVICE    REASON
21/tcp   open   ftp        syn-ack ttl 52
22/tcp   open   ssh        syn-ack ttl 54
113/tcp  closed ident      reset ttl 254
2000/tcp open   cisco-sccp syn-ack ttl 61
5060/tcp open   sip        syn-ack ttl 61

The TTL field starts at some number (usually 128 or 64) and is decremented by each intervening IP router or hop. If any received TTL fields are unexpectedly high, it can mean that the packet originated closer to the scanner than expected, i.e. from one of the hops.

You said that 21 and 22 were expected to be open. They have differing TTL values, which could mean that one of them (FTP) is port-forwarded to a system inside your network, or it could mean that there is some asymmetric routing going on resulting in a different path each time. But the real question is over 2000 and 5060, which are 7 hops closer than the nearest expected distance. These are almost certainly being intercepted.

You should be able to determine which hop is intercepting the traffic by conducting a traceroute. Nmap can be used to do this, if you limit its traffic to the one port in question:

nmap --traceroute -Pn -p 2000 example.com

This will show a series of hops culminating in the one "from" your target. It's actually most likely to be the hop beyond the last hop in this list. Compare it to the traceroute for a port that is acting as expected. For example, if your scan looks like this:

# nmap --traceroute -Pn -p 2000 example.com
TRACEROUTE (using port 2000/tcp)
1   2.04 ms  gateway (192.168.1.1)
2   14.37 ms 10.100.96.1
3   15.60 ms example.com (192.0.2.5)

# nmap --traceroute -Pn -p 22 example.com
TRACEROUTE (using port 22/tcp)
1   2.04 ms  gateway (192.168.1.1)
2   14.37 ms 10.100.96.1
3   15.60 ms 182.23.16.88
4   10.11 ms 182.23.16.82
5   44.73 ms example.com (192.0.2.5)

The last common hop is 10.100.96.1. The next hop in the sequence is 182.23.16.88, which is most likely the one that is spoofing the response.

As to why these ports may be being spoofed, I note that SCCP (port 2000) and SIP (port 5060) are both VoIP services. Maybe your ISP doesn't want you running a VoIP server, client, or relay, and is using this method to prevent it?