On 12/23/23 01:29, Tim Woodall wrote:
The fact that the OP is not sending a SYN+ACK (according to the
tcpdumps that I saw) means that this is already blackholed.[2]
There are three options at this point:
1. Ignore it - my "EVILSYN[1]" blacklist is right at the top of my iptables
rules and drops without logging before anything else.
2. Talk to their ISP and get it blocked there - that's the only surefire
way to stop it eating their quota if that's the problem.
3. Try and make them give up - that's why I suggested sending a RST.
[1] I have a set of rules that blacklist IPs that send too many SYN
packets that are not responded to with SYN+ACK.
[2] This did look weird. I'm not sure how only some connections get a
SYN+ACK back - I wonder if their webserver is rate-limited and these are
"genuine" connection attempts that are failing - although the SPT=80
DPT=80 looks suspiciously like something crafted to get through naive
stateless firewall rules that rely on outgoing (allowed) connections to
have DPT=80 to the internet and SPT=80 from the internet.
Thank you for your comments and explanations.
Your [1] and [2] make me think of fail2ban(1). Any similarities?
STFW I found some informative articles:
https://www.cisco.com/c/en/us/support/docs/ip/ip-multicast/14760-4.html
https://heimdalsecurity.com/blog/syn-flood/
Sending a RST to a falsified IP address would make the sending host into
an attacker by proxy. Why do you suggest it?
Does Debian and/or Linux support SYN cookies?
I believe Debian includes packages for various intrusion detection
systems. Does anyone have any comments or recommendations?
Analyzing and correlating iptables and httpd logs should provide a
better understanding of legitimate traffic versus attacker traffic. We
would need matching excerpts from the OP to try it.
David