DDoS Attacks after “Operation Eastwood”: what we experienced and how you can mitigate cost‑effectively (incl. example)

on

Background. Following the VRT NWS article of 6 August 2025 about the pro‑Russian DDoS group NoName057(16) and Europol’s “Operation Eastwood,” we are sharing how we recently faced similar attacks and which pragmatic, low‑risk and free measures we implemented internally. In that same period (14–17 July 2025), parts of NoName057(16)’s infrastructure were disrupted internationally: over 100 servers offline, arrests and searches; according to VRT (citing Europol), the network has thousands of followers.

Key message: you don’t need an expensive DDoS appliance to curb most low‑effort DDoS and crawler noise. With smart edge logic (firewall/WAF), targeted subnet/geo‑filtering and simple automation, you can go surprisingly far.

1) Context: what is actually happening?

NoName057(16) is a hacktivist DDoS movement that mobilizes volunteers via social channels. Attacks often target (semi‑)public sites in countries supporting Ukraine. Such crowdsourced DDoS waves are relatively easy to resume after takedowns: little advanced expertise is required, and new servers or networks can be spun up quickly.

Reality for organizations: traffic is often bursty (short spikes), originates from recognizable ASNs/countries, and primarily aims at availability disruption (not data theft). That creates opportunities for lightweight, reversible measures that prevent a lot of pain.

2) What we did (and what you can do tomorrow)

We opted for a step‑by‑step approach that is free, low‑risk, and easy to roll back.

  1. Log, measure, set thresholds. Collect access logs (Nginx/Apache) and network stats (conntrack, netstat). Define thresholds (e.g., >X requests/min per IP or Y open TCP connections per source/subnet).
  2. Rate‑limiting & challenges. Enable basic rate limiting on the web server (HTTP 429) to absorb spikes. Enable SYN cookies at OS level and use per‑source connection limits where possible.
  3. Subnet/geo‑filtering tailored to your audience. For markets you are not serving, temporary geo‑ or subnet filtering is often effective. Keep it temporary and risk‑based (e.g., 24–72 hours) to limit false positives.
  4. Involve upstream and ISP. Ask your hosting provider/ISP for scrubbing or uplink rate caps when volumetric traffic saturates your line. Use abuse reports towards source ASNs to shorten the lifetime of abusive infrastructure (see §6).
  5. Automate & roll back. Automate blocks with TTLs (temporary), maintain whitelists (e.g., search bots), and log every change. Prepare a runbook: when to block, what to block, for how long, who approves, how to monitor, and when to lift.

3) Open‑source: DropIPsByCountry (example script)

Because we observed excessive automated traffic across multiple sites, we published a simple open‑source script: DropIPsByCountry. Repository: github.com/OnlineSolutionsGroupBV/DropIPsByCountry.

The script is lightweight and designed to:

  • extract IPs from web server logs;
  • enrich IPs with country/ASN information (via an IP geo/ASN provider or your own data source);
  • automatically update software firewalls (UFW/iptables) with temporary rules (TTL) at IP or subnet level.

It emits machine‑readable (JSON) output and is easy to schedule via cron or integrate in CI/CD. See the README in the repo for current installation and usage instructions.

4) Alternative without UFW: ipset/nftables with temporary rules

For large rule sets, ipset (or nft sets) is more efficient than many individual iptables rules. The minimal example below shows the concept:

# 1) Create a set for subnets with a TTL of 1 hour
sudo ipset create ddos_nets hash:net timeout 3600

# 2) Drop traffic from anything in the set
sudo iptables -I INPUT -m set --match-set ddos_nets src -j DROP

# 3) Temporarily add a subnet
sudo ipset add ddos_nets 203.0.113.0/24 timeout 3600

# Rollback
sudo ipset flush ddos_nets
sudo iptables -D INPUT -m set --match-set ddos_nets src -j DROP
sudo ipset destroy ddos_nets

Why temporary? DDoS sources shift quickly. Temporary blocks reduce the risk of prolonged collateral damage.

5) Layered security architecture (vendor‑neutral)

  1. Edge (L7): HTTP rate limiting (per IP/ASN/URL), token bucket/burst; return 429 based on behavior, not country. Cache where possible; use graceful degradation under load (e.g., static fallback pages).
  2. Host/OS (L3/L4): SYN cookies, conntrack tuning, increase nf_conntrack_max. Use ipset/nft sets for performant block lists.
  3. Upstream/ISP: Traffic scrubbing or blackholing for volumetric floods that choke your uplink.
  4. Process & people: Runbook, rotations, monitoring (status codes, latency, open conns), post‑mortem.

6) Automated abuse reports (optional)

  • Find abuse contacts of source IP/ASN via RDAP/WHOIS and send a standardized report: timestamps, target host, log excerpts, impact, point of contact.
  • Automate modestly (hourly batches), avoid false positives, and include a clear unsubscribe option.
  • Goal: encourage source networks to act faster against repeated abuse.

Note: report, but never retaliate. “Hacking back” is unlawful and escalatory.

7) Wording and framing

Media often use “hacker” as a catch‑all. Technically, hacktivist DDoS operator or simply DDoS attacker is more precise. This avoids unintentionally glorifying relatively simple disruption techniques and keeps the discussion factual.

8) Risks and pitfalls (and how we mitigate them)

  • Over‑blocking due to geo filters. Use clear criteria (no customers in region X), set a TTL, and monitor error rates from that region.
  • Legitimacy & privacy. IP addresses can be personal data under GDPR; limit retention, document a legitimate interest, and offer a way to object.
  • Uplink saturation. Local firewalling won’t help if your line is full: enable upstream scrubbing.
  • False positives from shared egress. Large cloud providers reuse IPs; whitelist per use case (e.g., known bots, payment providers).
  • Single point of failure. Limit changes to the edge and keep a one‑command rollback (remove set/rules).

9) Conclusion

“Operation Eastwood” dealt a meaningful blow to NoName057(16), yet the cat‑and‑mouse game with DDoS attacks continues quickly. Fortunately, with cost‑free, reversible measures you can neutralize a large share of the nuisance:

  • Rate limiting at application and network layers,
  • temporary subnet/geo filtering where it makes business sense,
  • automation with a lightweight script such as DropIPsByCountry,
  • and abuse reports to offending networks.

We tested this approach across multiple sites and observed clear improvements in availability and cost control. Want to try our open‑source approach or integrate it into your own software firewall? Start here: DropIPsByCountry.

Comments

Post a Comment