Looking for Trouble: ICMP and IP Statistics to Watch

Opening and Interpreting EtherPeek’s Summary Statistics Window

When you launch EtherPeek, the first thing that jumps out on the main toolbar is the Summary Statistics icon. Click it and the window opens, presenting a clean layout of network traffic data that is usually captured in a single sweep. You don’t need to dive into raw packets to spot anomalies - everything you need is already summarized for quick consumption.

The window is split into distinct sections. At the top, the ICMP Analysis panel gives you a bird’s‑eye view of ping traffic, echo replies, and more exotic ICMP messages. Beneath it sits the IP Analysis panel, which aggregates ARP requests, TCP SYNs, FINs, RSTs, and reverse‑ARP activity. Each metric is a numeric counter, allowing you to spot spikes or gaps that warrant a deeper look.

To use this tool effectively, first understand the baseline for your network. A small office environment with 25 hosts will generate far fewer ARP requests than a large campus. Likewise, an industrial control system might routinely send ICMP Router Solicitations as part of its configuration process. By noting the normal range for each counter over a typical week, you establish a yardstick against which future traffic is measured.

Once you have a baseline, look for deviations. A sudden uptick in ping requests, for instance, may signal a user playing with the command line, while a surge in ICMP Destination Unreachable packets can indicate misconfigured services or an ongoing UDP scan. The Summary Statistics window turns raw traffic into actionable intelligence in seconds, saving you the time of sifting through thousands of packets.

Because EtherPeek updates the counters in real time, you can monitor trends live. Watch the “Ping Requests” counter rise, and if the “Ping Unanswered” counter stays low, you’re probably seeing legitimate traffic. If “Ping Unanswered” climbs alongside the requests, it’s a sign that someone is probing the network for alive hosts. In that scenario, the next step is to identify the source IPs and determine whether the scans are coming from internal tools or from the wider Internet.

Overall, the Summary Statistics window is your first line of defense. By keeping a close eye on its panels, you can spot problems before they grow, whether that means a rogue host, a misconfigured gateway, or a hacker probing for weaknesses.

ICMP Analysis: Spotting Reconnaissance, Misconfigurations, and Network Redirects

ICMP sits at the core of the TCP/IP stack, offering both essential diagnostic functions and a stealthy reconnaissance tool for attackers. The ICMP Analysis section in EtherPeek’s Summary Statistics window is therefore a critical lens through which you can see the health of your network.

The simplest indicator is the ping trio: Ping Requests, Ping Responses, and Ping Unanswered. Calculating the difference between requests and responses gives you a quick gauge of network reachability. A healthy network will have ping requests matched by responses, leaving Ping Unanswered near zero. When the counter for Ping Unanswered rises above 10% of the total requests, suspect a ping sweep. Network management tools sometimes perform scans, but if the source is an external IP, block inbound echo requests to keep the probe at bay.

Beyond pings, ICMP provides a set of other message types that attackers exploit for OS fingerprinting. Classic tools - Xprobe, Nmap, LANguard Network Scanner - send crafted ICMP packets, watching how the target replies. The most common types are Echo requests (type 8) and replies (type 0), Host Parameter Problem (type 12), Timestamp requests (type 13) and replies (type 14), Information request (type 15) and replies (type 16), Address mask request (type 17) and replies (type 18), and Router Solicitation (type 10) with replies (type 9).

Because legitimate traffic rarely uses types 12, 13, 15, 17, or 10, their presence in the Summary Statistics panel is a red flag. A spike in Router Solicitation messages, for instance, may mean a device is probing for better routes. If the router returns a reply, the host updates its routing table and may start using an unexpected gateway. Monitoring these exchanges helps you spot misconfigured default gateways or, worse, malicious redirects that hijack traffic through an attacker’s machine.

Redirects themselves are straightforward: a router sends an ICMP Redirect to a host to tell it that another router offers a more direct path. If a host starts receiving Redirects for routes that don’t belong to it, the gateway may be misconfigured, or an adversary could be attempting to steer traffic through a compromised system. In either case, capture a few minutes of traffic and filter for the redirect type to identify the source IP and the suggested gateway. Cross‑reference that with your network topology to confirm legitimacy.

ICMP Destination Unreachable messages also carry valuable insight. The four subtypes - Network unreachable, Host unreachable, Protocol unreachable, and Port unreachable - are each triggered by different failure conditions. A bulk of “Port unreachable” packets often means a UDP scan is underway: a scanner sends packets to a range of ports, and hosts that lack services on those ports reply with “Port unreachable.” In contrast, a sudden burst of “Host unreachable” may indicate a misconfigured or failed host that can’t resolve a gateway.

By watching these ICMP metrics in real time, you can differentiate between routine diagnostics, internal scans, and potential attacks. If the numbers don’t match your established baseline, investigate the offending traffic immediately, capturing packets for deeper inspection or configuring a more granular filter to focus on the suspicious types.

IP Analysis: Uncovering ARP Anomalies, TCP Reset Storms, and RARP Activity

The IP Analysis panel aggregates counters that reveal how devices communicate at the Ethernet layer. High numbers of ARP requests and responses can signal normal network growth, but a sudden spike in unanswered ARPs often points to a deeper issue.

When a host sends an ARP request and no reply arrives, the sender believes the target is on the local subnet but the target either doesn’t exist, isn’t powered on, or is mis‑configured. A large volume of unanswered ARPs suggests one of two things: either the sending host’s network mask is wrong, or an ARP scan is in progress. In a scan, an attacker broadcasts ARP requests to discover every active MAC address on the network. While network management tools may use this technique, it remains a sign of potential reconnaissance if the origin is unverified.

Beyond ARP, the panel tallies TCP SYN packets, which initiate connections, and RST packets, which abruptly terminate them. An unusual pattern - many SYNs followed by a high percentage of RSTs - typically indicates a TCP port scan. A scanner sends SYN packets to a range of ports; if a port is closed, the target sends a RST. While a few RSTs are normal during legitimate traffic, if they exceed 30% of the SYNs, investigate further. Capture traffic around the suspected source IP, apply a filter for “tcp.flags.reset” and review the destination ports being targeted.

FIN packets appear at the end of a graceful shutdown, while RST packets abruptly abort the session. A network filled with FINs but a sparse number of RSTs suggests a stable environment. If RSTs dominate, look for scanners or misbehaving applications that close connections prematurely. Similarly, monitor for excessive RSTs sent to a single host, as this can indicate a denial‑of‑service attack where the attacker floods the target with connection attempts and then rejects them.

Reverse ARP (RARP) activity is rarer but still useful to track. RARP is used by legacy systems to map IP addresses to MAC addresses. An uptick in RARP requests could signal devices attempting to discover their network identity, but if the traffic is uncharacteristic for your environment, confirm whether it comes from an old node or an intruder.

Overall, the IP Analysis panel transforms raw traffic into a set of numbers that tell the story of your network’s behavior. By cross‑checking ARP, TCP, and RARP counters against your baseline, you can spot anomalies that may signify configuration errors, scanning, or malicious activity, often before the attacker’s payload reaches the target.