I85PREP
⌘ K
CEH study materials
CEH study resources

Every Port Filtered, One Host Answers

CEH · Put your knowledge to work in context.

All case studies

Every Port Filtered, One Host Answers

An external assessment covers three public IPs. nmap -sS -p- against the first returns every port as filtered, no RSTs, and ICMP echo replies arrive with TTL 63. Browsing port 443 shows a wildcard TLS certificate with twelve SANs, none of which match the client's naming convention. Traceroute terminates at a large content-delivery network. The client then gives you a jump host inside the DMZ. From there, the same server 10.20.5.14 shows 22, 80, 443, and 3389 open in under a minute. The second public IP answers every port with a TCP RST and TTL 255. The third returns nothing at all, ever.

1. Explain the external-versus-internal discrepancy and what it tells you about the perimeter, without assuming the firewall is misconfigured.

Read the worked answer

Three different behaviours, three different explanations - treat them as evidence, not as errors.

  • IP 1 (all filtered, ICMP TTL 63): filtered means no response was received, which is what a default-deny stateful policy looks like when it drops rather than rejects. The TTL of 63 suggests the replies you do get are generated one hop away, i.e. by a filtering device, not by the server. The internal scan proving 22/80/443/3389 open is not a contradiction: from inside the DMZ you are on the trusted side of that policy, so the rule that blocks you externally simply does not apply. The correct conclusion is "the perimeter enforces default-deny and the internal segment has a much flatter policy" - which is itself a finding about internal segmentation.
  • The wildcard certificate with non-matching SANs says the 443 listener is likely a shared front end (CDN or reverse proxy) terminating TLS on the client's behalf, not the origin server. Scanning it tells you about the provider's edge.
  • IP 2 (RST on every port, TTL 255): a device that rejects everything is deliberately advertising its presence - typically a firewall in reject mode, an IPS in block mode, or a load balancer. Uniform RST on all 65,535 ports is not a real host's port map. TTL 255 hints at a network device rather than a general-purpose OS.
  • IP 3 (silence): either a blackhole route, a decommissioned address, or a drop-all policy with no ICMP. Silence is not evidence of safety; confirm ownership before drawing conclusions.

2. You have four hours and a change window that forbids load testing. Which techniques do you use next, and in what order?

Read the worked answer

Order by information gained per packet sent, not by tool familiarity.

  1. Confirm what you are actually talking to. Resolve the twelve SANs, check their certificates and issuance dates, and see which ones point back into the client's own ranges. Certificate transparency logs and DNS history often reveal the origin address behind a CDN - that is the asset the client owns and the one worth testing.
  2. Map the rule set rather than the ports. An ACK scan against IP 1 distinguishes filtered from unfiltered and shows which ports the firewall passes, without completing handshakes. Pair it with --reason so every result carries its justification.
  3. Test only ports the policy permits. You already know 443 is allowed. Put your enumeration effort there - virtual host discovery, TLS configuration, HTTP methods, and application fingerprinting - because that is the only surface reachable from the internet.
  4. Use the internal jump host for depth. Since the DMZ host answers normally from inside, do service/version detection and authenticated enumeration from there; it is faster, quieter on the perimeter, and matches how an attacker who lands a DMZ foothold would actually move.
  5. Do not chase IP 3. Confirm with the client whether the address is still allocated. Spending window time on a black hole is the classic way to finish a test with three findings and no coverage.

On evasion: any timing or fragmentation trick needs to be in the rules of engagement. If it is not, ask - do not improvise against a production IPS.

3. The jump host reveals 3389 open on 10.20.5.14 but externally that port is filtered. What do you report, and how do you avoid overstating it?

Read the worked answer

Report it as an exposure-conditional finding, not as a critical vulnerability found on the internet.

The honest statement is: RDP is reachable from the DMZ segment and is blocked at the perimeter. Impact therefore depends entirely on how an attacker reaches the DMZ - a phished workstation, a compromised VPN account, a misconfigured partner link. Severity should reflect that conditional path, not the raw port number.

To avoid overstating:

  • State the two vantage points explicitly and that the perimeter rule is currently effective.
  • Check whether the RDP service itself is hardened (NLA required, patched, restricted accounts) - if you can determine this from the internal side without valid credentials, do it; if not, say so.
  • Do not claim "RDP exposed to the internet." That sentence would be wrong and the client's firewall team will disprove it in the first review meeting, costing you credibility on the findings that are real.

Recommendation: keep the perimeter rule, add a DMZ-to-server-segment rule that does not pass 3389, and add monitoring for internal RDP sweeps. Frame it as defence-in-depth, because the perimeter control is already doing its job.