I replaced 3 monitoring tools
with a 5MB binary

Back to Blog

The Old Stack

For years, my go-to investigation workflow when a server was acting up looked like this:

First, nload to see if bandwidth was the problem. It shows inbound and outbound throughput with a nice ASCII graph. Good for a quick "is the pipe full?" check, but that's all it does. No protocol breakdown, no source IPs, no port information. Just bytes per second, in and out.

Second, iftop to see connections. It shows which IPs are talking to which IPs and how much data is flowing between them. Better than nload for understanding who's responsible for the traffic, but it thinks in terms of connections, not packets. During a UDP flood there are no connections. iftop shows a mess of individual source/destination pairs with no useful aggregation.

Third, a custom tcpdump one-liner piped through awk to get protocol breakdown and packet counts. Something like:

sudo tcpdump -i eth0 -c 10000 -nn -q 2>/dev/null | \
  awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -rn | head -20

This kind of worked, but it was slow (had to capture packets first, then process), the output was ugly, and every time I needed a slightly different breakdown I had to rewrite the awk chain. I had a folder of these scripts. None of them were good.

The three tools together gave me a decent picture. But running three things in three terminal panes, mentally correlating the output from each one while a server was actively having a bad time, was not great. Especially over SSH on a server that was already struggling under load.

What I Wanted

I wanted one screen that showed me:

• Current bandwidth and packet rate (what nload gave me)
• Top source IPs (what iftop gave me, but aggregated)
• Protocol breakdown: TCP vs UDP vs ICMP (what my tcpdump scripts gave me)
• Top destination ports (what none of them gave me easily)
• Whether the current traffic pattern looked like a DDoS attack (what none of them gave me at all)

All in a single TUI, updating in real time, without having to set up config files or install a database or run a web server.

NetHawk Does This

NetHawk is a single Go binary that does all of the above. Install it, run sudo nethawk, and you get a real-time dashboard with bandwidth, PPS, protocol percentages, top source IPs, top destination ports, a 60-second sparkline, and automatic attack detection and classification.

Here's the comparison with what I was doing before:

Bandwidth monitoring (replaces nload)

NetHawk shows current and peak bandwidth in Gbps/Mbps, plus packets per second. The 60-second sparkline gives you the same "is it going up or down?" visual that nload provided, but in the context of all the other data on screen. You don't need a separate tool just to answer "how much bandwidth am I using?"

Source IP ranking (replaces iftop)

The top source IPs section ranks the IPs sending you the most traffic by packet count. During normal operation, this is mildly interesting. During an attack, it's critical. You can immediately see if traffic is concentrated from a few sources (single-source flood) or distributed across thousands (botnet or amplification).

Unlike iftop, NetHawk aggregates by source IP rather than by connection. This matters for UDP attacks where there are no connections to track. iftop shows noise during a UDP flood. NetHawk shows you the top senders regardless of protocol.

Protocol breakdown (replaces custom tcpdump scripts)

TCP, UDP, and ICMP percentages update every second with visual bars. No more piping tcpdump through awk and waiting for a sample to finish. The answer is right there, continuously updated. A server that was 94% TCP suddenly showing 85% UDP is an instant signal, and you see it the moment it happens rather than after a 10-second capture completes.

Destination ports (new, nothing did this well before)

This was the thing I couldn't easily get from any of my old tools. Which ports are receiving the most traffic? Is it port 443 (normal HTTPS)? Port 53 (DNS amplification)? Port 123 (NTP amplification)? Port 11211 (Memcached)? NetHawk breaks it down by percentage and updates in real time.

This alone is worth the switch. During an attack, the destination port breakdown is the fastest way to identify the vector.

Attack classification (new, nothing did this at all)

NetHawk doesn't just show raw numbers. When PPS exceeds your threshold, it analyzes the protocol and port distribution and tells you the attack type: DNS Amplification, SYN Flood, NTP Amplification, UDP Flood, and so on. It also assigns a severity level (Normal, Medium, High, Critical) based on how far above the threshold you are.

With my old tools, I had to mentally cross-reference nload (bandwidth high), iftop (lots of random sources), and my tcpdump output (mostly UDP, port 53) to conclude "DNS amplification." NetHawk just says it.

Why It's 5MB and Why That Matters

NetHawk compiles to a single static binary. No Python runtime, no npm install, no dependency tree. You download one file, make it executable, and run it. Or use the one-liner installer:

curl -sSfL https://raw.githubusercontent.com/Flowtriq/nethawk/main/install.sh | sudo sh

This matters in practice because the servers where you most need traffic analysis are often the ones where installing software is painful. Production servers with locked-down package managers. Minimal container images. Servers belonging to a client where you have SSH access but not root access to their package repo. A static binary sidesteps all of that. Download it to /tmp, run it, and delete it when you're done.

The size matters too. 5MB downloads in seconds even on congested links. I've deployed it to servers that were actively under DDoS attack with degraded connectivity. It still only takes a few seconds to transfer.

JSON Mode Replaced My Last Script

The one custom script that survived the longest was a tcpdump-based thing that logged traffic stats to a file every 30 seconds so I could look at them later. NetHawk's JSON mode replaces that completely:

sudo nethawk -json | tee /var/log/traffic-stats.json

Every second, you get a structured JSON object with all the metrics. Pipe it to jq, feed it to a log aggregator, or write a wrapper that sends alerts. The data is the same as the TUI, just machine-readable.

sudo nethawk -json | jq 'select(.severity != "NORMAL") | {severity, attack_type, pps, bps}'

That one-liner watches for traffic anomalies and prints only the ones that cross the threshold. Better than anything I built with tcpdump and awk, and it took 10 seconds to write.

What It Doesn't Do (And What Does)

I'd be lying if I said NetHawk replaced everything in my monitoring stack. It didn't. Here's what it's not designed for, and I want to be honest about this because the boundaries matter:

• It doesn't mitigate attacks. It shows you the attack. It doesn't stop it. If you need automated firewall rules, FlowSpec injection, or upstream scrubbing triggered by detection, that's a different tool.
• It doesn't do multi-server monitoring. It runs on one server and shows you that server's traffic. If you have 50 servers, you need to SSH into each one. There's no central dashboard, no fleet view, no cross-node correlation.
• It doesn't build baselines. The attack detection uses a fixed PPS threshold that you set. It doesn't learn what "normal" looks like for your server over time. A gaming server at 300K PPS and a blog at 2K PPS need different thresholds, and you set those manually.
• It doesn't alert anyone. There's no built-in Slack integration, no PagerDuty, no email. You can build alerting around the JSON output, but that's DIY work.
• It doesn't capture PCAPs. It reads packets for real-time analysis but doesn't save them to disk for forensics.

All of those things are exactly what Flowtriq does. Flowtriq runs an agent on every server that monitors continuously, learns per-node baselines, deploys automated mitigation, captures PCAPs during incidents, and sends alerts to wherever your team watches. One dashboard for all your nodes.

The way I think about it: NetHawk is the tool I reach for when I need to investigate a single server right now. SSH in, run it, see the problem, make a decision. Flowtriq is the tool that's already running on every server so that most problems get detected and mitigated before I need to investigate anything.

They actually work well together. NetHawk gives you raw, immediate visibility on any machine. Flowtriq gives you continuous, automated protection across your fleet. Different tools for different jobs.

Back to Blog

Related Articles