Network Scanning and Service Discovery — DedSec Project

Network scanning answers bounded questions about hosts, ports, protocols, and exposed services. In an ethical assessment, scanning is not a stealth exercise: scope, rate, expected traffic, monitoring coordination, and evidence quality matter more than concealment.

Authorized-use boundary: Scan only addresses and services explicitly included in your scope. For learning, use localhost, a host-only VM network, containers, or an isolated lab such as 192.168.56.0/24 that you control.

Learning objectives

• explain TCP/UDP discovery and the limits of scan results;
• understand open, closed, and filtered observations;
• use Nmap safely in a small lab;
• identify service versions without over-trusting banners;
• understand why IPv4/IPv6 and firewall policy must be reviewed together;
• correlate scanner output with packet and server-side evidence.

Start with a question

A scan should answer a defined question such as “Which approved lab hosts expose TCP/22 and TCP/443?” or “Did the firewall change remove access from this test segment?” Avoid broad scans when a narrower test will answer the same question.

TCP state

TCP uses a stateful connection model. A typical connection begins with SYN, SYN/ACK, and ACK. A listening service may respond differently from a closed port, while a firewall or host policy may drop, reject, rate-limit, proxy, or otherwise alter traffic.

The terms open, closed, and filtered describe an observation from the scanner's position. They are not permanent properties of the target. Routing, source address, protocol family, network policy, load balancing, and time can change the result.

UDP state

UDP has no connection handshake. A silent UDP probe can mean many things: open service, filtered traffic, application-specific behavior, or packet loss. Strong conclusions usually require protocol-aware requests or server-side evidence.

Host discovery

ICMP echo is only one discovery signal. Hosts may block echo but still expose TCP or UDP services. Conversely, a gateway or load balancer may answer in ways that do not prove the application behind it is healthy.

In a lab, compare:

ping -c 2 192.168.56.10
nmap -sn 192.168.56.0/24

Use a small host-only subnet you control, not an arbitrary Internet range.

Nmap basics

Nmap supports many scan types. Begin with the least complex option that answers the question.

nmap -sT -p 22,80,443 192.168.56.10

A TCP connect scan uses the operating system's normal connection mechanism and is appropriate for many labs without raw-packet privileges.

Version detection can be useful when explicitly authorized:

nmap -sT -sV -p 22,80,443 192.168.56.10

Treat version output as a hypothesis. Reverse proxies, custom banners, backported patches, or service wrappers can make banner-based conclusions wrong.

Scan rate and reliability

Faster is not always better. Excessive concurrency can cause packet loss, trigger rate limits, overload fragile lab services, or create misleading results. Record timing options and retry conditions when results matter.

Firewalls and detection validation

Do not use scanning options to “get around” monitoring. If the assessment includes control validation, coordinate with the defensive team and ask whether the expected traffic was logged, correlated, and alerted on. A useful test produces evidence on both sides:

• scanner timestamp and source;
• target/service response;
• firewall or security-group decision;
• host log or application log;
• SIEM/EDR/network-detection evidence where applicable.

IPv6 parity

A service may be reachable through IPv6 even when IPv4 is restricted. Check listening sockets, DNS AAAA records, host firewall rules, cloud security policies, and monitoring coverage for both protocol families. Module 86 covers IPv6 in greater depth.

Service discovery and validation

After identifying a listening port, ask:

1. What protocol is expected?
2. Does the service require TLS?
3. What identity or authorization boundary protects it?
4. Is the service intended to be reachable from this network segment?
5. What evidence confirms the actual application and version?

Avoid assuming “port 443 = secure web server” or “port 22 = OpenSSH.” Ports are conventions, not identities.

Network diagrams

A useful scan report includes a simple diagram showing the scanner, routing boundary, firewall/security group, target, and relevant monitoring point. This makes it easier to distinguish target behavior from network filtering.

Common mistakes

• Scanning outside the approved CIDR range.
• Using broad port ranges when a small approved list is sufficient.
• Treating lack of ICMP echo as proof a host is offline.
• Treating scanner version detection as definitive.
• Ignoring IPv6.
• Trying to bypass monitoring rather than validating its coverage.
• Failing to correlate scan timestamps with defensive telemetry.

Safe lab

Create two local services on a VM or container you own, one on a known open port and one deliberately stopped. Scan only those ports, predict the expected state, capture the result, then change one firewall or service setting and repeat. Explain why the observation changed.

Knowledge check

1. Why is UDP scanning inherently ambiguous?
2. What does “filtered” describe?
3. Why can a service banner be misleading?
4. What evidence should accompany a firewall-validation scan?
5. Why must IPv6 be considered separately?

Guided study workflow

Use the shared Study Method. The mastery goal is to explain a scan result from TCP/UDP behavior and network policy, not from memorized Nmap switches.

Continue with

Recommended next modules: 04, 05, 12, 51.