Top source IPs: how to identify who is hammering your server in real time?

Identifying the top source IPs attacking your server is the cornerstone of modern DDoS mitigation and network security. Whether you're running game servers, APIs, or web services, understanding which remote addresses generate malicious traffic—volumetric floods, reconnaissance scans, or brute-force attempts—enables you to prioritize defenses, tune firewall rules, and feed IP blacklists with actionable intelligence. In this guide, we'll walk through the kernel-level tools, aggregation techniques, and centralized dashboards that reveal your attackers in real time, so you can respond with precision instead of guesswork.

Why Tracking Top Source IPs Matters for DDoS Defense

Every packet arriving at your server carries a source IP address. Under normal load, traffic originates from a diverse set of addresses distributed across autonomous systems and geographies. During an attack, this distribution skews dramatically: a handful of sources—or entire BGP prefixes—suddenly dominate your ingress bandwidth and connection table.

By continuously ranking source IPs by packet count or connection attempts, you gain three critical advantages:

• Early detection: A single /24 subnet sending millions of packets per second signals a reflection attack or botnet swarm before your service degrades.
• Surgical mitigation: Instead of applying blanket rate-limits that penalize legitimate users, you can drop or throttle only the top offenders at the XDP or nftables layer.
• Post-incident analysis: Audit logs enriched with GeoIP and ASN data help you identify patterns—botnets cycling through specific hosting providers, state-sponsored reconnaissance from known APT ranges, or misconfigured clients generating retry storms.

Modern kernel defenses like XDP and eBPF operate at line rate, processing packets before the network stack allocates socket buffers. Because they maintain per-flow or per-IP counters in BPF maps, you can extract top-talker statistics with negligible CPU overhead—often sub-microsecond per packet—making real-time visibility feasible even under multi-gigabit floods.

Extracting Top Source IPs with Kernel-Level Tools

The Linux kernel offers multiple collection points. Your choice depends on whether you need raw packet counts (XDP/eBPF), connection state (nftables conntrack meters), or post-stack flow records (netfilter logs).

XDP and eBPF maps

An XDP program attached to your NIC can hash each packet's source IP into a BPF hash-map, incrementing a counter atomically. A single eBPF program per interface—such as the PAKKT Engine—supports up to 256 simultaneous rules driven by separate maps, including a dedicated map for per-IP packet counters. To inspect the current state:

bpftool map dump name pakkt_ip_stats

The output lists IPv4 or IPv6 addresses alongside packet and byte counts (if your program tracks bytes separately). Because XDP runs before sk_buff allocation, this data reflects all ingress traffic, including malformed packets that would otherwise be silently dropped by the stack. For analysis, pipe the dump through sort -k2 -rn | head -20 to reveal the twenty heaviest sources.

nftables named meters and quotas

In the stateful firewall layer, nftables meters aggregate flows by arbitrary tuple keys—source IP, destination port, or a combination. A meter with a size limit automatically evicts least-recently-used entries, providing a sliding window of top talkers:

nft add rule inet pakkt input \
  meter top_ips { ip saddr limit rate over 1000/second } \
  counter log prefix "High-rate source: " drop

Query the meter state:

nft list meter inet pakkt top_ips

Each entry shows the key (source IP), rate, and expiry timestamp. Meters are particularly effective for TCP SYN floods because they leverage conntrack state; an IP sending thousands of SYN packets without completing handshakes will trigger the rate-limit while legitimate clients remain unaffected.

Conntrack table inspection

The conntrack utility exposes the kernel's connection tracking table. During an attack, you'll often see thousands of entries in SYN_SENT or TIME_WAIT from a small number of sources:

conntrack -L | awk '{print $5}' | sort | uniq -c | sort -rn | head -10

This one-liner counts connections per source IP and sorts by volume. It's useful for post-mortem analysis but imposes higher CPU cost than BPF maps when the table holds millions of entries.

Comparison table: collection methods

Method	Layer	State	CPU cost	Best use-case
XDP/eBPF map	L2 (NIC driver)	Stateless	Sub-µs/pkt	Volumetric floods, raw packet counts
nftables meter	L3/L4 (netfilter)	Stateful (optional conntrack)	Low (~1 µs/pkt)	SYN floods, per-connection rate-limit
conntrack -L	L4 (conntrack table)	Stateful	Medium (linear scan)	Post-incident forensics
tcpdump + awk	Any	Stateless	High (userspace copy)	Ad-hoc sampling, debugging

Centralized Dashboards and GeoIP Enrichment

Parsing BPF maps and meter dumps on each server individually does not scale beyond a handful of nodes. A centralized control plane collects per-IP statistics via agent heartbeats, normalizes timestamps into a time-series database (TimescaleDB or Prometheus), and enriches each address with GeoIP and ASN metadata.

PAKKT.io exemplifies this architecture: the lightweight Go agent (mTLS, 30-second heartbeat, SHA256 self-update) reports per-rule and per-port metrics to a central panel. The dashboard renders:

• A world map heatmap of attack origins, color-coded by packet volume.
• A top source IPs table with packet count, country flag, ASN name, and last-seen timestamp.
• A top countries chart aggregating all sources within each ISO code.
• Per-port breakdowns showing which services (SSH on 22, game protocols on 25565, 27015, etc.) are under heaviest probe.

Because the agent runs in userspace and queries BPF maps via bpf(2) syscalls, the XDP program itself remains stateless and can process several million packets per second without stalling. The 30-second polling interval strikes a balance between real-time visibility and minimal CPU overhead (typically <1% on a modern x86_64 core).

Automated blacklist synchronization

Once you've identified the top offenders, manual nft add element commands quickly become tedious. A dual-layer IP blacklist—one BPF map in XDP for earliest possible drop, one nft set in the stateful firewall for policy enforcement—keeps both layers synchronized. When you add an IP to the web panel, the agent pushes it to both the XDP map and the nftables set within the next heartbeat cycle:

# XDP layer (BPF map update via agent)
# nftables layer
nft add element inet pakkt blacklist_v4 { 203.0.113.42 }

Packets from blacklisted sources are dropped at line rate in XDP, never reaching conntrack or the application. The stateful layer provides a second enforcement point for any edge cases (fragmented packets, VLAN tags) that bypass XDP on certain NIC drivers.

Integration with Pterodactyl and public API

Game server panels like Pterodactyl v1.x can display attack statistics and toggle blacklist entries directly within the server management UI. PAKKT Integrations provide webhooks and REST endpoints (API key authentication) so that panel plugins can:

• Fetch the current top-10 source IPs for a given server node.
• Trigger an emergency blacklist of an entire /24 subnet during an active DDoS.
• Export CSV or JSON logs for compliance or incident-response workflows.

The public API also powers a community-shared template marketplace, where users publish pre-configured XDP and nftables rulesets for common attack patterns (Minecraft query floods, Source Engine A2S_INFO reflection, etc.).

Interpreting Top-Talker Data: Signal vs. Noise

Not every high-volume source IP is malicious. Legitimate traffic spikes—a popular streamer joining your game server, a CDN origin pull, a monitoring probe—can temporarily dominate the top-talker list. Distinguishing attack traffic from normal bursts requires context:

• Packet size distribution: Reflection amplification attacks (DNS, NTP, Memcached) produce uniform small packets (~60–100 bytes). Legitimate game traffic shows a mix of small keepalives and larger data frames.
• Protocol and port: Thousands of ICMP echo requests from a single /28 are almost certainly a ping flood. TCP SYN to a closed port suggests a scan or spoofed reflection.
• GeoIP anomalies: A Minecraft server with a European player base suddenly receiving gigabits from a single Chinese ASN is a red flag. Conversely, a US-based API seeing spikes from AWS us-east-1 may simply be autoscaling clients.
• Time-of-day patterns: Botnets often exhibit flat 24-hour activity. Human users cluster around regional peak hours.

A stateless XDP program cannot distinguish these nuances alone; it only counts packets. The stateful nftables layer adds conntrack state (NEW, ESTABLISHED, INVALID) and TCP flag inspection, enabling rules like:

nft add rule inet pakkt input \
  tcp flags syn tcp dport 25565 \
  ct state new limit rate 100/second burst 200 packets accept

This rule allows up to 200 new SYN packets per second to port 25565, then throttles further attempts. Legitimate clients complete the handshake and transition to ESTABLISHED, bypassing the rate-limit. Spoofed SYN floods remain in NEW and are dropped, preventing conntrack table exhaustion.

False positives and whitelisting

If a top source IP belongs to a known partner—your monitoring service, a backup gateway, or a high-traffic legitimate user—add it to the XDP and nftables whitelists before applying aggressive rate-limits. The dual-layer whitelist operates identically to the blacklist but with inverted logic: packets from whitelisted IPs bypass all further XDP rules and nftables meters, proceeding directly to the application.

nft add element inet pakkt whitelist_v4 { 198.51.100.10 }
nft insert rule inet pakkt input ip saddr @whitelist_v4 accept

Place the whitelist rule at the top of the input chain to minimize CPU cycles spent on every packet from trusted sources.

Operational Workflow: From Detection to Mitigation

Here is a pragmatic step-by-step process for leveraging top source IP data during an active incident:

1. Alert trigger: Your monitoring system (Prometheus, Grafana, or the PAKKT dashboard) detects ingress traffic exceeding the baseline by 10×—e.g., 500k pps instead of 50k.
2. Identify top talkers: Query the XDP BPF map or nftables meter to list the top 20 source IPs. Cross-reference with GeoIP: are they concentrated in a single ASN or geographically dispersed?
3. Assess attack vector: Check packet size (min/max), protocol distribution (TCP/UDP/ICMP), and destination ports. A UDP flood to port 19132 (Bedrock) differs tactically from a TCP SYN flood to port 22 (SSH).
4. Apply surgical blocks: If five IPs account for 80% of malicious packets, add them to the XDP blacklist. If an entire /24 is involved, blacklist the subnet. Monitor the traffic drop within seconds.
5. Enable rate-limiting: For distributed attacks (hundreds of sources, each below your per-IP threshold), configure a global or per-port PPS limit in the XDP engine (e.g., max_port_pps = 100k) and a complementary nftables meter for stateful throttling.
6. Document and iterate: Export the top-talker logs, ASN details, and applied rules to your incident-response playbook. Update your XDP/nft templates in the community marketplace so other users benefit from your findings.

This loop—detect, identify, mitigate, document—becomes faster with centralized tooling. A manual SSH session running bpftool and nft list on each server is acceptable for one or two nodes; beyond that, a unified dashboard with one-click blacklist updates is essential.

Conclusion

Tracking the top source IPs attacking your infrastructure transforms reactive firefighting into proactive defense. By combining XDP's line-rate packet counting, nftables' stateful flow metering, and centralized GeoIP dashboards, you gain sub-second visibility into attack origins and can apply surgical mitigations—blacklists, rate-limits, or whitelists—without collateral damage to legitimate users. Whether you parse BPF maps manually or leverage an agent-based control plane, the kernel's built-in observability ensures that even multi-gigabit floods leave a clear forensic trail, empowering you to harden rules, share intelligence, and reduce mean-time-to-mitigation with every incident.

FAQ

How often should I refresh the top source IPs list during an active DDoS?

During an attack, poll your XDP BPF maps or nftables meters every 5–10 seconds to catch new botnet nodes cycling into the swarm. A 30-second agent heartbeat is adequate for steady-state monitoring but may lag during rapid escalation. For manual triage, a simple shell loop with bpftool map dump piped to watch provides near-real-time updates without overwhelming your terminal.

Can I track top source IPs for IPv6 traffic separately?

Yes. Maintain distinct BPF maps (one for AF_INET, one for AF_INET6) and separate nftables sets (type ipv6_addr). IPv6 sources often appear as /64 or /48 prefixes rather than individual addresses, so aggregate by prefix length in your analysis scripts. GeoIP databases like MaxMind GeoLite2 include IPv6 ranges, enabling the same country and ASN enrichment as IPv4.

What should I do if my top source IP belongs to a major cloud provider like AWS or GCP?

Verify the traffic legitimacy first: check logs for valid API requests, SSH key exchanges, or application handshakes. If the traffic is a flood with no corresponding application-layer activity, the instance is likely compromised or spoofed. Contact the cloud provider's abuse desk with timestamps, source IPs, and packet captures. Meanwhile, apply a temporary rate-limit (e.g., 1000 pps) rather than an outright block, allowing legitimate bursts while capping malicious volume. Review your whitelists to ensure authorized cloud services (monitoring agents, CI/CD runners) are excluded from aggressive throttling.