Internet-Facing Exposure: Find What Attackers Can See

Published October 23, 2026 · Last reviewed October 23, 2026

What counts as internet-facing

Anything with a public address that answers: the office firewall or router, a VPN gateway, a remote-access or remote-desktop service, a web or mail server, a camera or recorder, a network storage box, a printer with a web page, and cloud servers you started and forgot. Cloud logins such as Microsoft 365 or Google Workspace are internet-facing by design; the question for those is how well the sign-in is protected, which the MFA guide covers.

Build the list

1. Ask your internet provider, or read the firewall, for the public IP addresses your business uses. Include any static addresses at branch sites.
2. Ask your domain registrar or DNS host for the full list of DNS records on your domains. Each A, AAAA and CNAME record points to something that is, or once was, reachable.
3. Ask your cloud accounts (Microsoft Azure, Amazon Web Services, Google Cloud) for the list of running servers with public addresses.
4. Add what staff report: “the camera we can watch from home”, “the old file server we reach from the road”.

Test from outside, then decide

Action

Scan your own public addresses from a network that is not yours (a phone hotspot or a home connection). A free port scanner such as nmap can show which ports answer: nmap -Pn -p 1-1024,3389,8080,8443 203.0.113.10 (the address is a documentation example; use only addresses you own or are authorised to test).

Why it helps

What the firewall configuration says and what the internet sees can differ. The outside view is the one attackers have.

Verification

Compare the open ports with the list of services you intend to expose. Anything unexpected is a finding.

Fallback if delayed

If you cannot run a scan, ask your MSP or internet provider for the firewall’s inbound rule list and compare it with your intentions.

Action

Remove direct exposure of remote desktop (port 3389), file sharing (port 445) and device management pages. Put remote access behind a VPN or a zero-trust remote-access service with MFA, and limit management pages to the office network or a named management address.

Why it helps

These services are scanned constantly. A single weak password or unpatched flaw on a directly exposed service can be a complete compromise.

Verification

Repeat the outside scan and confirm the ports no longer answer. Then test that staff can still work remotely through the approved route.

Fallback if delayed

If a service must stay open for now, restrict it by source address, enforce MFA and log every sign-in, and set a date to remove it.

Action

Check each exposed appliance against its vendor’s support status and the KEV catalogue. Note the model, the version and the vendor’s end-of-support date. Replace devices that no longer receive security fixes.

Why it helps

Edge devices without fixes cannot be made safe by configuration. Many exploited flaws in the KEV catalogue are in this class of device.

Verification

For each device the sheet shows a current version, a support end date in the future, and a named person responsible for updates.

Fallback if delayed

Isolate an unsupported device in its own network segment, limit it to the minimum, and budget its replacement.

Action

Set one account as the owner of the list and review it monthly. Add a line to onboarding for any new public service: who approved it, why it must be public, and who patches it.

Why it helps

Exposure grows by accident, one convenient exception at a time. A named owner and a monthly review keep it from drifting.

Verification

At the monthly review the outside scan matches the list. Differences are explained or removed.

Fallback if delayed

Calendar a quarterly scan if monthly is not practical.

Free help exists in some cases: CISA offers Cyber Hygiene vulnerability scanning to eligible organisations, so check whether your business qualifies. Do not scan addresses you do not control.

Common failure mode

Scanning only the office address and forgetting the things that were never on the office network: a cloud server started for a project, a vendor-installed camera system, a branch router. The second failure is removing a port from the firewall while the service still answers through another route, such as a second internet line.

How it works

Attackers and researchers continually scan the internet for services with known weaknesses. A new service on a public address can be found within a short time of going online. They look for particular products, versions and open ports, then try the flaws and the default or weak logins for each. They do not need to know who you are.

That is why exposure is a more useful measure than the number of flaws on your machines. A flaw on a device that cannot be reached from the internet needs a foothold first; the same flaw on a device that is reachable needs nothing. Reducing the list of reachable services cuts both the chance of a first-time attack and the urgency of each patch. The KEV playbook shows how to prioritise patches for what remains.

Worked example

Suppose, as a hypothetical, an owner asks the internet provider for the list of public addresses and finds two. A phone-hotspot scan of the first shows only the firewall’s VPN port. The second address is a surprise: it answers on a web page, port 3389 and port 445. It belongs to a server an outsourced developer set up years ago for a project that ended.

The owner confirms with the developer that the project is finished, takes a backup, blocks the ports at the firewall, and schedules the server for decommissioning. A week later a repeat scan shows only the VPN port. The addresses and services are invented for illustration; the pattern of a forgotten system with several open services is common.