syn flood attacks from NL-based netblocks

Mike mike-nanog at tiedyenetworks.com
Sun Aug 18 03:01:30 UTC 2019


On 8/16/19 3:04 PM, Jim Shankland wrote:
> Greetings,
>
> I'm seeing slow-motion (a few per second, per IP/port pair) syn flood
> attacks ostensibly originating from 3 NL-based IP blocks:
> 88.208.0.0/18 , 5.11.80.0/21, and 78.140.128.0/18 ("ostensibly"
> because ... syn flood, and BCP 38 not yet fully adopted).
>
> Why is this syn flood different from all other syn floods? Well ...
>
> 1. Rate seems too slow to do any actual damage (is anybody really
> bothered by a few bad SYN packets per second per service, at this
> point?); but
>
> 2. IPs/port combinations with actual open services are being targeted
> (I'm seeing ports 22, 443, and 53, just at a glance, to specific IPs
> with those services running), implying somebody checked for open
> services first;
>
> 3. I'm seeing this in at least 2 locations, to addresses in different,
> completely unrelated ASes, implying it may be pretty widespread.
>
> Is anybody else seeing the same thing? Any thoughts on what's going
> on? Or should I just be ignoring this and getting on with the weekend?
>
> Jim
>
>
>
>

I am seeing this against my recursive revolvers - one syn in, and many
syn-ack's back with no connection obviously. Low rate to be sure, but
what was surprising to me was that my revolvers (PowerDNS) definitely
have an allowed-networks ACL which specifies my permitted client
addresses, and I thought this would effectively filter any inbound
queries. But it looks like this ACL is applied only AFTER connection
setup. Maybe I have been blind this entire time thinking I wouldn't
respond to any packets sent to my resolver from non-allowed-networks
addresses. But anyways just a good data-point for anyone else to check
your revolvers too and consider the TCP case may behave as mine do. I
fixed it by implementing a revised iptables firewall which definitely
corrects the issue and drops outright all packets to
non-allowed-networks addresses, thank you ipset...

Mike-




More information about the NANOG mailing list