Network Attack Surface Checklist: Clear Privacy Guide

By Katia Belokon

Quick Answer

A network attack surface checklist helps you identify and verify which parts of your network infrastructure are visible to the outside world. The checklist should separate what can be observed publicly—your IP address, open ports, DNS resolver, and routing path—from what remains hidden behind encryption, authentication, and application-layer controls. The practical approach is to run baseline checks, document what each tool reveals, make one change at a time, then verify which signals actually shifted. This method keeps the checklist grounded in observable evidence rather than assumptions about total privacy or security.

Most people start with a public IP check to see their visible network endpoint, but a complete network attack surface checklist goes further. It includes DNS behavior, browser fingerprint signals, account login state, open service ports, and whether traffic routes through expected infrastructure. No single test proves complete protection, so the checklist works best when each signal is verified independently and interpreted in context.

What Belongs in a Network Attack Surface Checklist

The term “attack surface” refers to all the points where an unauthorized party could interact with your system. For network diagnostics and privacy decisions, the checklist should cover the signals that change when you adjust network settings, the signals that stay constant despite those changes, and the gaps between what a tool reports and what a service actually knows.

Public IP Address and Network Identity

The public IP address is the most visible part of your network attack surface. It identifies the network endpoint that websites, apps, and services see when you connect. Check this first using a reliable IP lookup tool, then note the associated ISP name, autonomous system number (ASN), and approximate geographic region.

When you change networks—switching from home broadband to mobile data, or enabling a VPN—the public IP should change. If it doesn’t, either the change didn’t take effect or traffic is still routing through the original path. According to Cloudflare’s explanation of IP addresses, this identifier is assigned by your Internet Service Provider and can reveal your general location and network operator, though not your precise physical address.

Record the IP address, network name, and location before making any changes. Then run the same check afterward and compare the results line by line. A network attack surface checklist is only useful when you can measure what actually changed.

DNS Resolver and Leak Behavior

DNS queries translate domain names into IP addresses. Even when your public IP address changes, your browser or operating system might still send DNS requests to your ISP’s resolver, creating a mismatch that can reveal your original network.

Include a DNS leak test in your network attack surface checklist. This test shows which DNS servers are answering your queries. If you’re using a VPN or privacy DNS service, the resolver should match that service, not your ISP. A mismatch doesn’t always mean a critical failure—some browsers use DNS-over-HTTPS by default, and some operating systems have their own secure DNS settings—but it does mean you need to investigate further.

For a detailed explanation of how DNS leaks work and how to test for them, see our guide on what is a DNS leak.

Open Ports and Listening Services

Open ports represent services that accept incoming connections. A port scan from an external perspective shows which services are reachable from the public internet. Common examples include port 80 for HTTP, port 443 for HTTPS, port 22 for SSH, and port 3389 for Remote Desktop Protocol.

Your network attack surface checklist should include a port scan to identify which services are exposed. Unnecessary open ports increase risk because each one is a potential entry point. If you’re running a web server, ports 80 and 443 are expected. If you’re not, those ports should be closed or filtered by a firewall.

Run the port scan from outside your network to see what an attacker would see. Internal scans can show services that are blocked by your router or firewall, giving a false sense of exposure.

WebRTC and Browser-Level Leaks

WebRTC enables real-time communication in browsers, but it can also expose your local IP address even when you’re using a VPN. This happens because WebRTC uses STUN servers to discover your network configuration, and those requests can bypass the VPN tunnel.

Add a WebRTC leak test to your checklist. If your local IP address appears in the test results alongside your VPN’s public IP, that’s a leak. The local IP alone isn’t always a privacy risk—it’s typically a private address like 192.168.x.x or 10.x.x.x—but it can be used for fingerprinting and tracking across sessions.

Most browsers allow you to disable WebRTC or limit its behavior. Test before and after making that change to confirm the leak is closed.

Account and Cookie Signals

Changing your network path does not change your account identity. If you sign into the same Google, Facebook, or email account after switching networks, those services can still link your sessions together. Cookies, local storage, and browser sync all persist across network changes.

A complete network attack surface checklist acknowledges this limitation. Network-level privacy tools protect the routing path, but they don’t reset application-level identity. If your goal is to separate activities, use different browser profiles, avoid signing into personal accounts, and clear cookies between sessions.

How to Build and Use the Checklist

Step 1: Establish a Baseline

Before making any changes, document your current network attack surface. Run each test and record the results:

• Public IP address and associated ISP
• DNS resolver addresses
• Open ports visible from the internet
• WebRTC leak status
• Browser fingerprint characteristics
• Account login state

This baseline gives you a reference point. Without it, you can’t tell whether a change had the intended effect.

Step 2: Make One Change at a Time

Change one variable and retest. If you enable a VPN, change DNS settings, and switch browsers all at once, you won’t know which change caused which result. Isolate each variable to understand its effect on your network attack surface checklist.

For example, enable a VPN and retest your public IP and DNS resolver. If the IP changes but the DNS resolver stays the same, you’ve identified a DNS leak. Fix that before moving to the next item.

Step 3: Cross-Check with Multiple Tools

No single tool is authoritative. Use at least two independent sources for each signal. If one tool shows a DNS leak and another doesn’t, investigate the difference. It might be a timing issue, a browser setting, or a difference in how the tools perform the test.

Cross checking reduces false positives and helps you understand the nuances of each test. A network attack surface checklist is more reliable when it’s based on consistent results across multiple tools.

Step 4: Interpret Results in Context

A surprising result isn’t always a failure. IP geolocation can be inaccurate, especially for mobile networks, data centers, and shared infrastructure. A city-level mismatch might just mean the geolocation database is stale or the network uses a regional gateway.

Focus on whether the result matches your expectations for the connection type. If you’re using a VPN based in the Netherlands, the IP should resolve to a Dutch network. If it resolves to your home ISP, the VPN isn’t working. If it resolves to a different country, check whether the VPN is using a shared exit node or a CDN.

Common Gaps and Misinterpretations

Assuming IP Change Equals Full Privacy

Changing your public IP address is one layer of privacy, not a complete solution. Websites can still track you through cookies, browser fingerprints, account logins, and behavioral patterns. A network attack surface checklist should make this distinction clear.

If you visit the same websites, sign into the same accounts, and use the same browser configuration, those services can still recognize you even when your IP address changes. Network-level tools protect the routing path, but they don’t erase application-level identity.

Overreacting to Location Mismatches

IP-based geolocation is approximate. It can point to a city, region, or ISP service area, but it’s not a precise street address. Geolocation databases are maintained by third parties and can be outdated or incorrect.

If your network attack surface checklist shows a location that’s off by 50 miles, that’s usually normal. If it shows a different country when you’re not using a VPN, that’s worth investigating. Context matters more than precision.

Ignoring Split Tunneling and Selective Routing

Some VPNs and privacy tools route only certain traffic through the protected path. Split tunneling allows you to send some apps through the VPN and others through your regular connection. This can create confusing results where your browser shows one IP address and your operating system shows another.

Check whether split tunneling is enabled and which apps are included. If your network attack surface checklist shows mixed results, split tunneling is a likely cause. Disable it temporarily and retest to confirm.

Trusting a Single Test

One clean test result doesn’t prove your entire network attack surface is secure. Different tools test different signals, and each signal can behave independently. A DNS leak test checks DNS behavior, not WebRTC. A port scan checks open services, not browser fingerprints.

Use a comprehensive checklist that covers all the relevant signals. Test each one independently and interpret the results together. A network attack surface checklist is only as good as the breadth and accuracy of the tests it includes.

Network Attack Surface Checklist Table

Signal	What It Reveals	How to Test	Expected Behavior
Public IP Address	Visible network endpoint, ISP, approximate location	IP lookup tool	Should match the network or VPN you’re using
DNS Resolver	Which servers translate domain names	DNS leak test	Should match your VPN or privacy DNS service
Open Ports	Services accepting incoming connections	External port scan	Only necessary services should be open
WebRTC Leaks	Local IP address exposed by browser	WebRTC leak test	Should show only VPN IP, not local IP
Browser Fingerprint	Configuration details that identify your browser	Fingerprint test	Should be generic or match your privacy settings
Account Login State	Whether you’re signed into identifiable accounts	Manual check	Sign out or use separate profiles for privacy

When to Rerun the Checklist

Your network attack surface changes over time. Rerun the checklist whenever you make significant changes to your network setup, install new software, or notice unexpected behavior.

After Changing Privacy Tools

If you switch VPN providers, change DNS settings, or enable new browser privacy features, rerun the full checklist. Each tool has different behaviors and potential leaks. What worked with one provider might not work with another.

After Software Updates

Operating system updates, browser updates, and VPN client updates can change network behavior. A new browser version might enable DNS-over-HTTPS by default, or a VPN update might change how it handles IPv6 traffic. Test after updates to catch unexpected changes.

After Noticing Anomalies

If a website shows an unexpected location, a service blocks your connection, or your network feels slower than usual, run the checklist to diagnose the issue. Anomalies can indicate misconfigurations, leaks, or changes in how your ISP or VPN routes traffic.

Periodically for High-Risk Situations

If you handle sensitive information, work in a high-risk environment, or travel frequently, run the checklist on a regular schedule. Monthly or quarterly checks help you catch gradual changes and maintain a consistent security posture.

Advanced Checklist Items

IPv6 Leak Detection

Many networks now support IPv6 alongside IPv4. If your VPN only protects IPv4 traffic, your IPv6 address can leak and reveal your real location. Include an IPv6 leak test in your network attack surface checklist to verify that both protocols are protected.

If you don’t need IPv6, consider disabling it at the operating system level. This eliminates the risk of IPv6 leaks and simplifies your network configuration.

Traceroute and Routing Path Analysis

A traceroute shows the path your traffic takes from your device to a destination server. This can reveal whether your traffic is routing through expected infrastructure or taking unexpected detours.

Run a traceroute to a known server before and after enabling a VPN. The path should change to reflect the VPN’s routing. If the path stays the same, the VPN might not be active or might be misconfigured.

TLS and Certificate Validation

Some networks intercept HTTPS traffic by installing custom certificates on your device. This is common in corporate environments and some public Wi-Fi networks. Check your browser’s certificate details when visiting HTTPS sites to ensure the certificate is issued by a trusted authority, not a local proxy.

If you see unexpected certificates, your traffic might be intercepted. This isn’t always malicious—corporate networks do this for security monitoring—but it’s important to know when it’s happening.

Practical Example: Running the Checklist

Imagine you’re evaluating a new VPN service. Here’s how to use a network attack surface checklist to verify it’s working correctly:

1. Before connecting, check your public IP address, DNS resolver, and open ports. Record the results.
2. Connect to the VPN and recheck your public IP. It should change to an IP address owned by the VPN provider.
3. Run a DNS leak test. The DNS resolver should match the VPN provider, not your ISP.
4. Run a WebRTC leak test. Your local IP address should not appear in the results.
5. Run a port scan. The open ports should match the VPN’s configuration, not your home network.
6. Check your IPv6 address. If the VPN doesn’t support IPv6, your IPv6 address should not be visible.
7. Visit a few websites and check the browser’s certificate details. The certificates should be standard, not intercepted.

If all tests pass, the VPN is working as expected. If any test fails, investigate the specific issue before trusting the VPN for sensitive activities.

Limitations of Network Attack Surface Checklists

A network attack surface checklist is a diagnostic tool, not a guarantee of privacy or security. It shows you what’s visible from the outside, but it can’t prove what every website, app, or service knows about you.

Application-Layer Tracking

Network-level tools don’t protect against application-layer tracking. If you sign into a Google account, Google knows who you are regardless of your IP address. If you use a mobile app, the app can send device identifiers and behavioral data that bypass network privacy tools.

Treat network checks as one layer of a broader privacy strategy. Combine them with account separation, browser isolation, and careful app permissions.

Timing and Behavioral Analysis

Even when your IP address and DNS resolver are protected, sophisticated tracking can correlate your activity based on timing, browsing patterns, and behavioral fingerprints. A network attack surface checklist can’t detect or prevent this type of tracking.

For high-risk scenarios, consider additional measures like using Tor, avoiding persistent accounts, and varying your browsing patterns.

False Negatives and Tool Limitations

Some leaks are difficult to detect with standard tools. For example, a DNS leak might only occur for certain domains, or a WebRTC leak might only appear in specific browser configurations. A clean test result doesn’t prove there are no leaks, only that the tool didn’t find any.

Use multiple tools, test in different scenarios, and stay skeptical of any single result.

FAQ

What is a network attack surface checklist used for?

A network attack surface checklist is used to identify and verify which parts of your network infrastructure are visible to external observers. It helps you understand what information your IP address, DNS queries, open ports, and browser reveal to websites, apps, and potential attackers. The checklist is most useful when you’re evaluating privacy tools, diagnosing network issues, or preparing for high-risk activities where network visibility matters.

How often should I run a network attack surface checklist?

Run the checklist whenever you make significant changes to your network setup, such as switching VPN providers, changing DNS settings, or updating your operating system. For routine use, monthly or quarterly checks are sufficient unless you work in a high-risk environment or notice unexpected behavior. After any software update that affects networking—browser updates, VPN client updates, or OS updates—rerun the checklist to catch unintended changes.

Can a network attack surface checklist detect all privacy leaks?

No. A network attack surface checklist detects network-level signals like IP address, DNS resolver, open ports, and WebRTC leaks, but it cannot detect application-layer tracking, account-based identification, browser fingerprinting, or behavioral analysis. It’s one diagnostic layer in a broader privacy strategy. Combine network checks with account separation, browser isolation, and careful review of app permissions for more comprehensive protection.

What should I do if my network attack surface checklist shows unexpected results?

First, verify the result by running the same test again and cross checking with a different tool. If the unexpected result persists, isolate the issue by changing one variable at a time. For example, if your DNS resolver doesn’t match your VPN, check whether your browser is using DNS-over-HTTPS, whether your operating system has custom DNS settings, or whether split tunneling is enabled. Document each change and retest until you identify the cause.

Does changing my IP address hide my identity from websites?

Changing your IP address hides your network endpoint, but it does not hide your identity if you sign into accounts, use the same browser configuration, or allow cookies to persist across sessions. Websites can still track you through account logins, browser fingerprints, payment information, and behavioral patterns. A network attack surface checklist should clarify this distinction: network-level privacy tools protect the routing path, but they don’t erase application-level identity.

What is the difference between a DNS leak and a WebRTC leak?

A DNS leak occurs when your DNS queries are sent to your ISP’s resolver instead of your VPN’s resolver, revealing which domains you’re visiting even when your IP address is protected. A WebRTC leak occurs when your browser exposes your local IP address through WebRTC’s network discovery mechanism, potentially revealing your real network even when using a VPN. Both are network-level leaks, but they involve different protocols and require different tests to detect. Include both in your network attack surface checklist for complete coverage.