Home / Blog / Network Diagnostics for Security Teams: ping, hping3, and traceroute
Cyber Security

Network Diagnostics for Security Teams: ping, hping3, and traceroute

AJAjish Stephen August 12, 2026 9 min read
Network Diagnostics for Security Teams: ping, hping3, and traceroute
Authorized use only. Everything below applies to systems you own, or infrastructure you have explicit written permission to test. Sending crafted packets at networks you don't control is indistinguishable from an attack to the receiving side and can carry real legal consequences.

Before you can secure a network, you need to see what's actually happening on it — which hosts respond, which ports are open, and how firewall rules behave under real traffic. ping and hping3 are two of the oldest tools for this, and still two of the most useful — one for basic reachability, the other for crafting the exact packet you need to answer a specific question.

Basic reachability with ping

Standard ping sends ICMP echo requests and measures round-trip time. It's the fastest first check for "is this host up," though many cloud firewalls and security groups block ICMP by default — a failed ping doesn't always mean a dead host.

# Basic connectivity check
ping-c 410.0.0.15

# Flood interval for stress-testing YOUR OWN test host
ping-i 0.2 -c 5010.0.0.15

# Check with a specific packet size (test MTU / fragmentation)
ping-M do -s 147210.0.0.15

Testing firewall rules with hping3

Where ping only speaks ICMP, hping3 can craft TCP and UDP packets with specific flags and ports — exactly what you need to verify a firewall rule actually does what it claims.

# TCP SYN probe against a single port — did the firewall let it through?
hping3-S -p 443 -c 310.0.0.15

# Scan a small range of ports (simple, sequential — not a full port scan)
hping3-S -p ++20 -c 2010.0.0.15

# ACK scan — useful for mapping stateful vs stateless firewall behavior
hping3-A -p 80 -c 310.0.0.15

# UDP probe for a specific service port
hping3-2 -p 53 -c 310.0.0.15
Reading the response
A SYN/ACK reply means the port is open and reachable
An RST reply means the port is closed but the host is reachable — the firewall isn't silently dropping traffic
No response at all usually means the packet was dropped by a firewall rule — this is what you want to see for ports that should be blocked

Tracing the path with traceroute

When a host is unreachable, traceroute shows exactly which hop the traffic is dying at — useful for telling a routing problem apart from a firewall drop.

# Standard ICMP traceroute
traceroute10.0.0.15

# TCP traceroute on a specific port — bypasses ICMP-only blocks
traceroute-T -p 44310.0.0.15

# hping3 equivalent, one TTL at a time
hping3-S -p 443 -t 1 -c 110.0.0.15

Detecting this activity on your own infrastructure

The same techniques that verify your defenses are what an attacker's early reconnaissance looks like. Watching for this pattern is part of the job, not just running the probes.

Rate-limit ICMP at the edge firewall so bulk ping sweeps get throttled instead of answered instantly
Watch for sequential SYN probes across a range of ports from a single source in a short window — classic port-scan signature
Use fail2ban or an IDS like Suricata to auto-block sources that trip scan-detection thresholds
Log dropped packets, not just accepted ones — the drops are what tell you someone is probing, not just passing through

Need help hardening a network's edge, or want an authorized penetration test against your own infrastructure before an attacker finds the gaps first? This is exactly the kind of work I do as part of Cybersecurity services engagements.

Common questions

Is it legal to use hping3 to test a network?
Only against systems you own or have explicit written authorization to test. Sending crafted packets at infrastructure you don't control can violate computer misuse laws and looks identical to an attack from the receiving side.
What's the difference between ping and hping3?
Standard ping sends ICMP echo requests to check basic reachability and latency. hping3 crafts custom TCP, UDP, and ICMP packets with specific flags and ports, useful for testing firewall rules that plain ping can't probe.
Why would ping fail even though a server is online?
Many firewalls and cloud security groups block ICMP echo requests by default even while TCP services like HTTP or SSH remain fully reachable. A failed ping often just means ICMP is filtered.
How can I detect this kind of reconnaissance against my own servers?
Monitor for unusual ICMP volumes, SYN packets to closed or unexpected ports, and repeated probes from the same source in a short window. IDS tools like Suricata or fail2ban can flag or rate-limit this automatically.
Want your network tested before someone else does it for you?
I run authorized penetration tests and firewall audits that find gaps before attackers do.
Explore Cybersecurity Services →
© Copyright 2024 Ajish Stephen