Port Scan False Positives — AWS Global Accelerator SYN Proxy

Summary

External penetration tests and vulnerability scans frequently report that many TCP ports are publicly open on your ThoughtFarmer-hosted site. These are false positives. The reported ports are not open, not accepting connections, and not exposing any services to the internet.

This behaviour is caused by a deliberate DDoS-protection feature built into AWS Global Accelerator called TCP SYN Proxy (also known as SYN Cookies). This article explains the technical details, provides commands you can run to verify it yourself, and links to official documentation from AWS and other infrastructure providers that confirm this is a well-known industry-wide behaviour.

What You Are Seeing

Your penetration testing or vulnerability scanning tool (e.g., Qualys, Nessus, Rapid7, or nmap with default settings) reports results similar to:

• Multiple TCP ports flagged as "open" (e.g., 21, 23, 179, 636, 873, 1099, 1521, 3306, 3389, 5432, 5985)
• The target IP resolves to an AWS Global Accelerator address (e.g., *.awsglobalaccelerator.com)
• The ports are reported as open intermittently or across different scan dates
• No actual service banners are returned for the flagged ports

This is expected behaviour from the AWS infrastructure protecting your site and is not a security vulnerability.

Technical Explanation

How a Normal TCP Connection Works

A standard TCP connection uses a three-way handshake:

1. Client → Server: SYN (request to connect)
2. Server → Client: SYN-ACK (acknowledgement)
3. Client → Server: ACK (handshake complete, connection established)

Most port scanners only perform the first two steps. They send a SYN packet, and if they receive a SYN-ACK in return, they declare the port open. They never send the final ACK, so they never actually establish a connection.

How AWS Global Accelerator's SYN Proxy Changes This

AWS Global Accelerator uses a stateless SYN Proxy at its edge network. This is a security mechanism designed to protect against SYN flood DDoS attacks — one of the most common and destructive types of denial-of-service attacks on the internet.

Here is how it works:

1. A client sends a SYN packet to any TCP port on the Global Accelerator IP.
2. The SYN Proxy responds with a specially crafted SYN-ACK containing an encoded challenge (a SYN cookie) — regardless of whether the port has an actual service behind it.
3. If the client responds with a valid ACK containing the correct cookie data:
   • If the port has a listener (real service): The connection is forwarded to the backend.
   • If the port has no listener: The connection is immediately dropped.

Because the SYN Proxy is stateless, it does not allocate any resources or create any connection state when sending the SYN-ACK. This allows it to absorb massive SYN flood attacks (millions of packets per second) without exhausting memory or CPU.

Why Port Scanners Get It Wrong

The fundamental issue is that most scanners use a SYN scan (nmap -sS or -sT). Their logic is simple:

• Send SYN → Receive SYN-ACK → Port is open
• Send SYN → Receive RST → Port is closed
• Send SYN → No response → Port is filtered

Since the SYN Proxy responds with a SYN-ACK to every SYN on every port, the scanner's logic incorrectly concludes that all ports are open. The scanner never completes the handshake, so it never discovers that Global Accelerator would have dropped the connection on a non-listener port.

This is a well-known limitation of SYN scanning when a SYN Proxy or SYN Cookie mechanism is in place. It is not specific to AWS — it affects any infrastructure that uses this DDoS protection technique.

Verify It Yourself

You can confirm that these ports are not actually open by attempting to complete a full TCP connection. Below are several methods you can use.

Method 1: Full TCP Connect with nmap

Run a full connect scan (-sT) with service version detection (-sV) instead of a SYN scan:

# Replace <your-site-ip> with your Global Accelerator IP
# Replace <port> with any port your scanner flagged as open

nmap -sT -sV -p <port> <your-site-ip>

A SYN scan will say the port is "open":

# SYN scan (incomplete handshake) — gives a FALSE POSITIVE
nmap -sS -p 3389 <your-site-ip>
# Result: 3389/tcp open  ms-wbt-server   <-- MISLEADING

A full connect scan with version detection will show no service is actually responding:

# Full connect scan with version detection — gives the REAL answer
nmap -sT -sV -p 3389 <your-site-ip>
# Result: 3389/tcp open  ms-wbt-server?  <-- no banner, no service response

Method 2: Attempt a Direct Connection with nc (Netcat)

# Attempt to connect and send data. The connection will be refused or hang.
echo "test" | nc -w 5 <your-site-ip> 3389

# You will receive no response — the connection is dropped after the handshake.

Method 3: Use curl or telnet to Test

# Try to establish an HTTP connection on a supposedly "open" port
curl -v --connect-timeout 5 http://<your-site-ip>:1521/

# Try telnet — the connection will time out or be refused
telnet <your-site-ip> 3389

In every case, you will find that no service responds, no data is exchanged, and the connection is dropped. The port is not open in any meaningful sense.

Method 4: Wireshark / tcpdump Packet Capture

For a definitive technical proof, capture the full handshake:

# Capture packets on the relevant port
sudo tcpdump -i any -nn host <your-site-ip> and port 3389

# In another terminal, attempt a connection
nc -w 5 <your-site-ip> 3389

You will observe:

1. Your client sends SYN
2. Global Accelerator replies with SYN-ACK (this is the SYN Proxy challenge)
3. Your client sends ACK (completing the handshake)
4. Global Accelerator sends RST (immediately tearing down the connection because no listener exists on that port)

This packet sequence proves the port is not open — the SYN Proxy challenged the connection and then rejected it once the handshake completed with no matching listener.

This Is Not Unique to AWS

This behaviour is a well-documented characteristic of SYN flood protection across the industry. Other major infrastructure providers and firewall vendors exhibit the same behaviour:

Palo Alto Networks

Palo Alto firewalls with SYN Cookie zone protection enabled produce identical false positives. Their official knowledgebase confirms that when SYN Cookies are active, the firewall sends a SYN-ACK before checking security policy, causing scanners to report all TCP ports as open.

Palo Alto KB Article: Vulnerability scanners such as Qualys (or nmap) report all TCP ports as open

Key quote from the article: the SYN-Cookie feature sends a SYN-ACK and waits for an ACK from the client before processing the connection and checking the security policy. This causes any scanner relying on SYN-ACK to determine port status to report all TCP ports as open.

Other Affected Platforms

This is a known issue with any infrastructure using SYN flood protection, including but not limited to:

• AWS Global Accelerator / AWS Shield (SYN Proxy)
• Palo Alto Networks firewalls (SYN Cookies in Zone Protection)
• Check Point firewalls (SYN Defender / SynAttack Protection)
• Cloudflare (SYN flood mitigation at edge)
• F5 BIG-IP (SYN Cookie protection)
• Juniper SRX (SYN flood protection)

AWS Official Documentation

The following AWS documentation describes the SYN Proxy feature and the DDoS attack it mitigates:

1. AWS Shield DDoS Mitigation Features
   Describes the TCP SYN Proxy as a core mitigation feature that challenges new connections using SYN cookies before allowing them to pass to the protected service.
   https://docs.aws.amazon.com/waf/latest/developerguide/ddos-event-mitigation-features.html
2. AWS Best Practices for DDoS Resiliency — SYN Flood Attacks
   Explains SYN flood attacks and how AWS mitigates them using stateless SYN cookies at the network edge.
   https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/syn-flood-attacks.html

Recommendations for Your Security Team

1. Reconfigure your scanner to complete the full TCP handshake. Ask your penetration testing provider if their tools can be configured to send the final ACK and detect SYN Proxy / SYN Cookie behaviour. Many enterprise scanners have settings to accommodate this.
2. Use service version detection. Running nmap -sV (version detection) in addition to a port scan will reveal that no service is actually listening on the flagged ports.
3. Flag Global Accelerator IPs as SYN-Proxy-protected. If your scanning tool supports it, mark the target as behind a SYN Proxy to suppress false positives on future scans.
4. Refer to the Palo Alto KB article. If your penetration testing vendor pushes back, the Palo Alto Networks article linked above is a vendor-neutral reference that documents this exact behaviour with resolution steps. It is a well-understood industry issue, not an AWS-specific anomaly.
5. Run the verification commands above. The fastest way to confirm this for yourself is to attempt a real connection to any flagged port. You will see the connection is refused or dropped — no data is accepted.

Frequently Asked Questions

Q: Are these ports actually open and accepting traffic?
No. The SYN Proxy responds to the initial SYN packet as a challenge mechanism, but no connection is established and no data is accepted on ports that do not have an active service listener.

Q: Could an attacker exploit these ports?
No. An attacker completing the TCP handshake on a non-listener port will have their connection immediately dropped by Global Accelerator. No data is forwarded to any backend service. The SYN Proxy is specifically designed to protect against this.

Q: Why do different ports appear on different scan dates?
The SYN Proxy operates at the AWS edge network level. Variations in which ports are reported can be influenced by scanner timeouts, network conditions, and the timing of the SYN-ACK challenge responses. This does not indicate any change in your site's configuration.

Q: Is this something ThoughtFarmer configured?
No. The SYN Proxy is a built-in feature of AWS Global Accelerator and AWS Shield. It is enabled and managed by AWS at their network edge. ThoughtFarmer does not have visibility into or control over this specific AWS infrastructure behaviour.

Q: Should we be concerned about our site's security?
Your ThoughtFarmer instance is protected by AWS Global Accelerator and AWS Shield, which provide enterprise-grade DDoS protection. The SYN Proxy behaviour that triggers these false positives is itself a security feature — it is evidence that your site is more protected, not less.

Contact

If you have additional questions about this behaviour or need assistance verifying your scan results, please contact ThoughtFarmer Support. We are happy to walk through the verification steps with you.