Why this happens
When your domain is connected to Encited, it resolves to our global anycast edge network. The edge accepts the initial TCP handshake on every port by design, then immediately resets the connection unless the port is one we actually serve. This handshake-first behavior is what lets the edge route, load-balance, and absorb abusive traffic before it ever reaches a server.
Most security scanners only test whether the TCP handshake completes — they never check whether a real service answers. Against our edge, that kind of scan reports every port as "open": 3389 (RDP), 22 (SSH), 5900 (VNC), and thousands of others. None of these services exist. Only the ports that serve your site over the web route anywhere at all — traffic to everything else is dropped at the edge and never reaches a server. There is no remote-desktop, shell, or admin service to reach; the "open" ports lead nowhere.
How to verify it yourself
A connect-only scan (nc -zv, or a scanner's default TCP scan) will always say "open" — that's the false positive. To see what's really there, run a service-detection scan, which sends real protocol probes and waits for a response:
nmap -sV -Pn -p 3389 <your-domain>
The result:
PORT STATE SERVICE VERSION3389/tcp open tcpwrapped
tcpwrapped is nmap's verdict for "the handshake completed, but nothing behind the port ever responded to any protocol probe — including RDP's own mandatory handshake." A real RDP server must answer its opening negotiation; here, nothing does.
Two things to know when running this:
- It takes about two minutes. Because nothing responds, nmap has to exhaust its entire probe library before concluding
tcpwrapped. A port with a real service behind it answers in seconds — the long wait is itself evidence that nothing is there. - Any other port behaves identically. Scan 3390, 5900, or a random high port and you'll get the same result — which confirms this is edge behavior, not a hidden service.
For your security team: the finding is a false positive inherent to
anycast edge networks (CDNs and edge proxies broadly behave this way).
Re-scanning with service detection (nmap -sV) instead of a connect-only scan
shows no service responds on the flagged ports. The pass criterion to use is
"no service responds," not "handshake completes."
How to fix it
There is nothing to fix — no service is exposed, and this is not a vulnerability. If your scanner supports it, configure it to use service detection or to treat tcpwrapped results as closed, or add an exception for the flagged ports on this host.
