Disclaimer: The statements below reflect my personal experience and opinions.
I’m sharing logs and context so readers can evaluate the claims independently.
Nothing here is legal advice or an instruction to attack, exploit, or harass anyone.
Do not misuse security information.

TL;DR

After raising payout concerns with FiveSurveys, my account activity appeared to be suppressed and payouts were refused.
In the same period, my server began receiving waves of low-skill TCP SYN flood traffic from rented hosts.
I implemented standard iptables mitigations and the traffic became background noise.

• Payouts disputed: I show $1,674 owed/earned in the period in question (evidence below).
• Traffic pattern: Short-lived SYN bursts from cheap VPS ranges; identical signatures across /24s.
• Mitigation: Basic iptables rate limiting & drops; zero downtime.
• Cost asymmetry: Attackers burn cash on throwaway hosts while my mitigation is effectively free.

What I Observed

The traffic was classic “script-kiddie” DDoS: repetitive SYN floods, shallow bursts, predictable TTLs, and unvaried TCP options.
Think copy-paste tooling, not bespoke implants. This isn’t stealthy red-teaming; it’s noisy and easy to fingerprint.

Indicators (Redacted/Generalized)

• Sources: Consecutive IPs within the same /24s from budget VPS providers.
• Behavior: Spikes of SYN packets, minimal follow-through to full handshake, no L7 sophistication.
• Timing: Recurring bursts that correlate with my disputes over payouts.

Why this matters: It shows intent to disrupt rather than resolve. And it’s amateur hour.

“Proof” — Evidence You Can Audit

I’m including the kinds of artifacts any technically literate reader can check.
Sensitive details (IPs, ticket numbers, internal URLs, personal data) are redacted, but the structure is intact.

1) Payout Records (Screenshots/CSV)

• Screenshot: Dashboard showing $1,674 earned in the disputed window.

  

<!-- Attachments you can host in your media library:
- /media/2025/09/fivesurveys-dashboard-earnings.png
- /media/2025/09/fivesurveys-payout-requests.csv
-->

2) Server Logs (Redacted)

Sample of SYN burst pattern from a single 15-minute window (timestamps and IPs partially redacted):

[2025-08-28T14:03:12Z] kernel: IN=eth0 OUT= MAC=... SRC=131.100.72.34 DST=... LEN=60 TOS=0x00 PREC=0x00 TTL=52 ID=... DF PROTO=TCP SPT=40762 DPT=443 WINDOW=64240 RES=0x00 SYN URGP=0
[2025-08-28T14:03:12Z] kernel: IN=eth0 OUT= MAC=... SRC=131.100.72.51 DST=... LEN=60 ... PROTO=TCP SPT=40774 DPT=443 ... SYN ...
[2025-08-28T14:03:13Z] kernel: IN=eth0 OUT= MAC=... SRC=131.100.72.87 DST=... LEN=60 ... PROTO=TCP SPT=40810 DPT=443 ... SYN ...
[... repeated entries across 131.100.72.0/22 and adjacent blocks ...]

3) Mitigation Rules Applied

These are standard, defensive iptables rules that rate-limit SYN and drop excess. They’re commonplace and non-controversial:

# Accept a small burst of new TCP handshakes, then rate limit:
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
# Drop everything else that's just spamming SYN:
iptables -A INPUT -p tcp --syn -j DROP

With this in place, the attack surface effectively turns into a sink.
No magic, no expensive appliances; just basic hygiene.

4) Cost Asymmetry

If an attacker rents a low-end VPS at about $11.12 per month (or per cycle) and rotates across multiple /24s,
they’re eating costs while my mitigation is a one-time copy/paste.
That’s not “winning a war”; that’s lighting money on fire.

Why SYN Floods Don’t Win

• They’re loud: Easy to detect with basic Netfilter logging.
• They’re crude: No application-layer pressure, so upstream/CDN/ACLs shrug them off.
• They’re traceable: Providers get abuse reports; hosts get null-routed; costs keep accruing.
• They’re easy to rate-limit: See the rules above. Even a small VPS can absorb it once tuned.

In short, it’s performative noise. If you’re still doing this in 2025, you’re signaling inexperience.