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?
Debian has SNORT and Suricata. I use Suricata. It works well and does not require paying the subscription for the SNORT oink account.
sudo apt install suricata suricata-update
You can configure Suricata via /etc/suricata/suricata.yaml. All that really needs configured for a basic IDS/IPS is to change the interfaces from Eth0 to the actual interface. After that you can enable and start Suricata via SystemD.
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