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:
- Scan from multiple networks (mobile hotspot, VPN, different ISPs)
- Compare results with online port scanners
- Check router firmware for media streaming features
- 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:
- Compare traceroutes from different networks
- Test from multiple geographical locations using services like ping.eu
- Implement port knocking for sensitive services
- 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.