Home/Blog/Network Diagnostics for Security Teams: ping, hping3, and traceroute
Cyber Security
Network Diagnostics for Security Teams: ping, hping3, and traceroute
AJAjish StephenAugust 12, 20269 min read
⚠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.