Diagnosing False Open Ports in Nmap Scans: RTSP (554) and RealServer (7070) Port Anomalies


3 views

During routine security checks, I encountered puzzling behavior when scanning my Debian Testing webserver from different networks. While external scans only detected the expected HTTP (80) and CSlistener (9000) ports, internal scans through my BT Homehub showed two additional open ports: RTSP (554) and RealServer (7070).

First, I confirmed these ports weren't actually open on my server:

# Check listening ports
netstat -tuln | grep -E '554|7070'
# Alternative using ss
ss -tuln | grep -E '554|7070'
# Verify service binding
lsof -i :554
lsof -i :7070

The discrepancy suggests intermediate network devices might be intercepting these ports. Common culprits include:

  • ISP transparent proxies
  • Home router media streaming features
  • Carrier-grade NAT behavior

To determine if these are false positives, I ran more sophisticated Nmap scans:

# TCP SYN scan with service detection
nmap -sS -sV -p 554,7070 your.server.ip

# ACK scan to check filtering
nmap -sA -p 554,7070 your.server.ip

# Aggressive scan with OS detection
nmap -A -p- -T4 your.server.ip

My arno-iptables-firewall configuration explicitly blocks all non-essential ports. To verify:

# Check iptables rules
iptables -L -n -v
# Check for NAT rules
iptables -t nat -L -n -v
# Monitor live traffic
tcpdump -i eth0 port 554 or port 7070 -vv

To isolate the issue:

  1. Scan from multiple networks (mobile hotspot, VPN, different ISPs)
  2. Compare results with online port scanners
  3. Check router firmware for media streaming features
  4. Contact ISP about transparent proxy services

The most likely explanation is that my home router (BT Homehub) has built-in media streaming capabilities that intercept RTSP traffic on port 554 and possibly realserver traffic on 7070. This creates false positives during internal scans while external scans show the true state of the server.

To confirm router interference:

# Bypass router with direct modem connection
# Scan from same network using different scanner
nmap --script=firewall-bypass your.server.ip
# Check router admin interface for media services

During a routine security audit of my Debian Testing webserver, I encountered perplexing nmap scan discrepancies:

# From local network (BT Homehub):
Not shown: 996 filtered ports
PORT     STATE SERVICE
80/tcp   open  http
554/tcp  open  rtsp
7070/tcp open  realserver
9000/tcp open  cslistener

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

First, I confirmed no local services were actually listening on these ports:

netstat -tulnp | grep -E '554|7070'
ss -tulnp | grep -E ':554|:7070'
lsof -i :554 -i :7070

All commands returned empty results, suggesting these weren't actual open ports on my server.

The key observations point to network-level manipulation:

  • Ports only appear open from specific networks (my home ISP)
  • Standard services (RTSP on 554, RealServer on 7070) commonly intercepted by ISPs
  • Behavior consistent with transparent proxies or carrier-grade NAT

To verify if this was ISP-level behavior, I ran targeted tests:

# Check if ports respond differently to malformed requests
nmap -sV --script=banner -p554,7070 your.server.ip

# Test with non-standard protocols
echo "FAKE RTSP REQUEST" | nc -vn your.server.ip 554
echo "RANDOM DATA" | nc -vn your.server.ip 7070

If these return service banners or unexpected responses, it confirms intermediate devices.

Despite using arno-iptables-firewall, I audited rules to ensure no leaks:

iptables -L -n -v
iptables -t nat -L -n -v
iptables-save > current_rules.txt

Running tcpdump revealed the truth:

tcpdump -i eth0 'port 554 or port 7070' -w suspect_ports.pcap

Analysis showed SYN-ACK responses coming not from my server but from intermediate hops.

For definitive proof and mitigation:

  1. Compare traceroutes from different networks
  2. Test from multiple geographical locations using services like ping.eu
  3. Implement port knocking for sensitive services
  4. Consider VPN tunneling to bypass ISP inspection

The root cause became clear: My ISP was performing deep packet inspection and transparently intercepting certain media-related ports, a common practice among some providers for "value-added services" or traffic shaping.