Post cover image

November 3, 2026

Network Security Testing Explained: What to Look For and How to Test It End to End

A complete methodology for assessing a network: how to map it, discover hosts and services, find weak configurations, test segmentation…

By Vigneshkumaroffsec

8 min read

A complete methodology for assessing a network: how to map it, discover hosts and services, find weak configurations, test segmentation, and check whether anyone would notice an attack.

By Vignesh Kumar | Security Researcher

In May 2021, Colonial Pipeline shut down the largest fuel pipeline in the United States after a ransomware attack.

The attackers got in through a VPN account that was no longer in use but had never been disabled. It was protected only by a password, with no multi-factor authentication. That password was later found in a batch of leaked credentials.

One forgotten account on one network entry point led to fuel shortages across the East Coast.

Network security is full of stories like this. The firewall was configured. The servers were patched. But one old service, one flat network segment, or one unmonitored entry point was enough.

This article explains how to test a network end to end: what to look for at each stage, which tools to use, and how to turn findings into fixes.

Before anything: scope and authorization

Network testing sends real traffic to real systems. It must be authorized in writing.

Before you start, agree on:

  • The targets: IP ranges, hostnames and cloud networks in scope, and anything explicitly excluded.
  • The type of test: external (from the internet), internal (from inside the network), or both.
  • The timing: some scans can slow down fragile systems, so agree on test windows.
  • Rules of engagement: which techniques are allowed, and who to call if something breaks.
  • Your source IP addresses, so the security team can tell your traffic from a real attack.

Industrial control systems, medical devices and old printers can crash from aggressive scanning. Ask about them early.

How networks fail

Most network findings fall into a few categories:

  • Exposure: services reachable from places they shouldn't be, like RDP or databases on the internet.
  • Weak services: outdated software, default credentials, and insecure protocols.
  • Weak encryption: old TLS versions, weak ciphers, or no encryption at all.
  • Flat networks: no segmentation, so one compromised laptop can reach every server.
  • Uncontrolled egress: internal systems allowed to connect anywhere on the internet.
  • Blind spots: no logging or detection, so an attacker can move around unnoticed.

Each stage of testing looks for one or more of these.

Stage 1: Understand the Network

Don't start with a scanner. Start with understanding.

Read the architecture

If you are testing your own network or working with a client, ask for:

  • Network diagrams, including VLANs and subnets.
  • Firewall rule sets.
  • A list of internet-facing services.
  • Remote access methods: VPN, jump hosts, remote desktop gateways.
  • Cloud networks and how they connect to on-premises.

Diagrams are often out of date. That is useful in itself, because the differences between the diagram and reality are often where the findings are.

Passive reconnaissance for external tests

For an external test, collect information without touching the target:

  • DNS records: subdomains, mail servers, and name servers.
  • Certificate Transparency logs: hostnames from TLS certificates, through crt.sh.
  • IP ownership: the organization's IP ranges and autonomous system numbers.
  • Internet scan databases: Shodan and Censys show which ports and services they have already seen on those IPs.

Check whether the DNS servers allow zone transfers. A misconfigured server can hand over its whole list of records:

dig axfr example.com @ns1.example.com

A properly configured server refuses the request.

Stage 2: Discover Hosts and Ports

Now find out what is actually alive and listening.

Host discovery

nmap is the standard tool. A ping sweep shows which hosts respond:

nmap -sn 10.10.0.0/24 -oA discovery

Some hosts block ping. For important ranges, also scan without host discovery using -Pn. It takes longer, but it finds hosts that hide.

Port scanning

Scan all 65,535 TCP ports on important hosts. Services often run on unexpected ports:

sudo nmap -sS -p- --min-rate 1000 -oA full-tcp 10.10.0.15

For large ranges, masscan or RustScan find open ports much faster. Then use nmap for detailed checks on what they find. Keep the rate low enough not to overload the network.

Don't forget UDP. It is slow to scan, but services like DNS, SNMP and NTP run there:

sudo nmap -sU --top-ports 50 -oA udp 10.10.0.15

What to notice

  • Services that shouldn't be exposed to that network at all.
  • Management interfaces: SSH, RDP, WinRM, iLO, iDRAC, IPMI, and admin web panels.
  • Databases: 3306 (MySQL), 5432 (PostgreSQL), 1433 (SQL Server), 6379 (Redis), 27017 (MongoDB), 9200 (Elasticsearch).
  • File sharing: 445 (SMB), 2049 (NFS), 21 (FTP).
  • Cleartext protocols: 23 (Telnet), 21 (FTP), 80 (HTTP), 161 (SNMP).
  • Unusual high ports that nobody can explain.

Stage 3: Enumerate the Services

An open port is only the start. Now find out exactly what is running and how it is configured.

Version and default script scan

nmap -sV -sC -p 22,80,443,445,3389 -oA services 10.10.0.15

-sV identifies service versions. -sC runs nmap's default scripts, which collect details like page titles, SSH host keys and SMB settings.

For a quick vulnerability check, nmap can run only scripts that are both vulnerability checks and considered safe:

nmap -sV --script "vuln and safe" -oA vulns 10.10.0.15

Vulnerability scanners

For broad coverage, use a dedicated vulnerability scanner:

  • Greenbone OpenVAS: open source, with a large library of network vulnerability tests.
  • Nessus: a widely used commercial scanner, with a free Essentials edition for small networks.
  • Nuclei: fast and template-based, strong on web services and known CVEs.

Scanners match versions and known issues. They report many findings that are not exploitable in your context, so verify the important ones by hand.

Service-by-service checks

Each common service has its own weak points.

SMB (file sharing on Windows networks)

Check whether SMB signing is required. Without it, attackers on the network can relay authentication to other machines:

nmap --script smb2-security-mode -p 445 10.10.0.0/24
netexec smb 10.10.0.0/24

Also check for SMBv1, anonymous access to shares, and shares readable by every user that contain sensitive files.

SSH

ssh-audit checks the algorithms, key types and version:

ssh-audit 10.10.0.15

Look for password authentication on internet-facing hosts, root login allowed, weak algorithms, and outdated versions.

TLS on web and other services

testssl.sh checks protocols, ciphers, certificates and known TLS vulnerabilities:

./testssl.sh https://app.example.com

Look for TLS 1.0 and 1.1, weak ciphers, expired or self-signed certificates, and missing HSTS on websites.

SNMP

SNMP often uses default community strings like public, which can reveal a device's configuration, interfaces and running processes:

snmpwalk -v2c -c public 10.10.0.20 system

If that returns data, the device is using a default string. Use SNMPv3 with authentication instead.

Databases and caches

Check whether Redis, MongoDB, Elasticsearch or similar services accept connections without authentication. These have been the source of many large data leaks.

Remote access

VPN gateways, firewalls and remote desktop gateways are some of the most targeted devices on the internet. Check their versions against current advisories, and confirm that MFA is enforced for every account.

Name resolution on Windows networks

On internal networks, LLMNR and NBT-NS are legacy name resolution protocols that attackers can abuse to capture password hashes. If they are not needed, disable them through Group Policy.

Default credentials

Network devices, printers, cameras and management interfaces often ship with default passwords. Check each management interface against the vendor's documented defaults, within the limits of your rules of engagement, and avoid repeated attempts that could lock accounts.

Stage 4: Test Segmentation and Firewall Rules

Segmentation decides how far an attacker can go after the first compromise. This is where many internal tests find their most serious issues.

Test from each zone

Put a test machine in each network zone, such as user, guest, server and management, and try to reach the others:

# From the guest Wi-Fi: none of these should be reachable
nmap -Pn -p 22,445,3389,5432 10.20.0.0/24

Every port should show as filtered. If any shows as open, the segmentation has a gap.

Look for:

  • Guest or user networks that can reach servers directly.
  • Workstations that can reach other workstations. Most of them don't need to talk to each other.
  • Management interfaces reachable from user networks.
  • Production reachable from development or test.
  • Payment card systems not isolated from the rest of the network, if PCI DSS applies.

Review the firewall rules

Read the rules, not just the results. Common problems include:

  • any to any rules, often added "temporarily".
  • Rules for systems that no longer exist.
  • Broad rules placed above specific ones, so the specific ones never apply.
  • No logging on deny rules.
  • No documented owner or reason for each rule.

Test egress

Outbound traffic is often forgotten. Malware needs to reach its command server, and stolen data needs a way out.

From a server, test which outbound ports and destinations are allowed. Servers should only reach the specific services they need, such as update servers and APIs, not the whole internet.

Also check DNS: can internal hosts query any DNS server on the internet, or only your own resolvers?

Stage 5: Check Detection

Prevention eventually fails. The last question is whether anyone would notice.

Look at the traffic

Capture traffic on a test segment with Wireshark or tcpdump, and look for credentials and data sent in cleartext:

tshark -r capture.pcap -Y "http.request || ftp || telnet || pop || imap"

Zeek turns raw traffic into structured logs for connections, DNS, HTTP, TLS and files. It is excellent for spotting unusual behavior over time:

zeek -r capture.pcap

Validate your detection tools

If the network has an IDS like Suricata or Snort, or a SIEM, check whether your testing appeared in it:

  • Did the port scans trigger an alert?
  • Was anyone notified, and how quickly?
  • Were the scans from an internal host treated differently from external ones?

Agree on this with the security team before the test. A test that nobody detects is one of the most important findings you can report.

Check the logs exist

Confirm that firewalls, VPN gateways, DNS servers and domain controllers send their logs to a central place, and that they are kept long enough for an investigation.

Stage 6: Report and Fix

A finding is only useful if someone can act on it.

For each finding, include:

  • What: the affected host, port and service.
  • Evidence: the command output or screenshot that proves it.
  • Risk: what an attacker could actually do, in plain words.
  • Fix: a specific action, such as "require SMB signing through Group Policy".
  • Priority: based on exposure and impact, not just a scanner's score.

Prioritize what is exposed to the internet, what gives access to credentials, and what lets an attacker move between segments.

After the fixes, retest. A fix that wasn't verified is only a promise.

Making It Continuous

Networks change every week. A test once a year finds what was wrong on that day.

  • Schedule external port scans of your own IP ranges, and alert on any new open port.
  • Run authenticated vulnerability scans internally every month.
  • Re-run segmentation tests after every major network change.
  • Track your internet-facing assets with an attack surface monitoring tool or regular Shodan checks.

A simple version is a weekly nmap scan of your public ranges, compared with last week's results using ndiff:

nmap -Pn -p- --open -oX scan-new.xml 203.0.113.0/28
ndiff scan-old.xml scan-new.xml

Any new open port is something to explain.

The Tools at a Glance

  • Mapping: crt.sh, Shodan, Censys, dig.
  • Discovery: nmap, masscan, RustScan.
  • Enumeration: nmap scripts, NetExec, enum4linux-ng, ssh-audit, testssl.sh, snmpwalk.
  • Vulnerability scanning: Greenbone OpenVAS, Nessus, Nuclei.
  • Traffic analysis: Wireshark, tcpdump, Zeek.
  • Detection: Suricata, Snort, your SIEM.
  • Comparison: ndiff, for changes between scans.

Common Mistakes to Avoid

  • Testing without written authorization.
  • Scanning only the top 1,000 ports.
  • Skipping UDP.
  • Trusting scanner output without verifying it.
  • Testing from only one network zone.
  • Ignoring outbound traffic.
  • Forgetting cloud networks and VPN connections.
  • Not telling the security team, or not checking whether they noticed.
  • Reporting findings without a clear fix.

A Quick Network Security Checklist

  • Every internet-facing service is known, needed and patched.
  • No RDP, SMB, databases or management interfaces exposed to the internet.
  • VPN and remote access require MFA, and unused accounts are disabled.
  • SMB signing required, SMBv1 disabled.
  • SSH uses keys, with no root login and modern algorithms.
  • TLS 1.2 or newer everywhere, with valid certificates.
  • No default credentials or default SNMP communities.
  • LLMNR and NBT-NS disabled where not needed.
  • Segmentation tested between every zone.
  • Egress restricted on servers.
  • Firewall rules reviewed, with owners and reasons.
  • Logs centralized, and scans detected and alerted.
  • External scans scheduled and compared over time.

Final Thoughts

Network security testing is not about running nmap and handing over the output.

It is about understanding how a network is supposed to work, finding where reality is different, and showing what an attacker could do with that difference.

The most serious findings are rarely exotic. They are an old VPN account, a flat network, a forgotten server, or an alert nobody received. Colonial Pipeline is a reminder that one of those can be enough.

If you only do one thing this week, scan your own public IP ranges for every open port, and make sure someone can explain each one.

About me

I'm Vignesh Kumar, a security researcher working across application security, DevSecOps, cloud security, and vulnerability research.

I share practical findings from security assessments and responsible disclosures to help improve the security of real-world systems.

The techniques in this article are intended for networks you own or are explicitly authorized to test.