13

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?

Christian David
  • 233
  • 1
  • 2
  • 5
  • my two cents https://forum.fortinet.com/tm.aspx?m=154963 – JOW Mar 27 '18 at 22:06
  • Add `--reason -v` to your Nmap scan to see TTL differences in the SYN ACK response packets received. It is possible that something else is responding/intercepting on these ports. – bonsaiviking Mar 28 '18 at 02:06
  • netstat -talpn add u bit to get udp. `netstat -talpnu` - run it with `root` – again Mar 28 '18 at 05:53
  • @bonsaiviking Thank you for the suggestion. As expected from the `telnet` sessions, the reasons are successful TCP handshakes. I also looked at the XML output, and get reason_ttl="0" for all open ports (which I don't understand). Furthermore, doing two nmap scans, one for 22/tcp and one for 2000/tcp, the round trip times are similar. – Christian David Mar 28 '18 at 08:21
  • @again These are TCP ports, why should I include UDP? In any case, no service is listening on the corresponding UDP ports either. – Christian David Mar 28 '18 at 08:24
  • @bonsaiviking I forgot to run `nmap` as `root`. Now the ttls are included in the output, and are indeed different for ports 2000 and 5060, compared to 21 and 22. – Christian David Mar 28 '18 at 08:34

1 Answers1

10

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?

bonsaiviking
  • 11,316
  • 1
  • 27
  • 50
  • Excellent answer. Running the traces revealed that my mobile ISP is the culprit (I was tethered while doing the scans). – Christian David Mar 29 '18 at 15:42
  • Glad to hear it worked! I just added [a tweak to Nmap](https://github.com/nmap/nmap/commit/6680f5648da2e3218f379827e2f03085894207bb) to prefer other ports besides some commonly-blocked ones when sending timing/ranging probes. Thanks for the inspiration! – bonsaiviking Mar 29 '18 at 18:44