robbob2112
New Around Here
Hi,
Does anyone know if there are any plans to update the iptables version in asuswrt?
RT-AC66U:/tmp/etc# iptables -V
iptables v1.3.8
Version from typical current linux
> iptables -V
iptables v1.4.12
The reason for the question is there are a lot of additional features in the newer version of iptables to help with DOS and DDOS attacks.
Specifically I run an authoritative DNS server behind the AC66 and it is being use as part of a DNS amplification attack. (spoofed source request for "." zone... 26~28 bytes in length... replies go to the spoofed source and vary from 45~200bytes depending on how the server is configured)... not possible to block it at the DNS server because of the OS it is running and better practice to block things at the edge anyways.
Even with recursion off it still responds with REFUSED which is 45 bytes in length.
The easy way to kill this sort of attack is with iptables either with packet matches on the "." request or with some of the built in rate limiting settings in the 1.4.x versions of iptables. With the 1.3 tables either it isn't possible to block or I haven't been able to figure out a workable syntax.
Thanks
Robert
Does anyone know if there are any plans to update the iptables version in asuswrt?
RT-AC66U:/tmp/etc# iptables -V
iptables v1.3.8
Version from typical current linux
> iptables -V
iptables v1.4.12
The reason for the question is there are a lot of additional features in the newer version of iptables to help with DOS and DDOS attacks.
Specifically I run an authoritative DNS server behind the AC66 and it is being use as part of a DNS amplification attack. (spoofed source request for "." zone... 26~28 bytes in length... replies go to the spoofed source and vary from 45~200bytes depending on how the server is configured)... not possible to block it at the DNS server because of the OS it is running and better practice to block things at the edge anyways.
Even with recursion off it still responds with REFUSED which is 45 bytes in length.
The easy way to kill this sort of attack is with iptables either with packet matches on the "." request or with some of the built in rate limiting settings in the 1.4.x versions of iptables. With the 1.3 tables either it isn't possible to block or I haven't been able to figure out a workable syntax.
Thanks
Robert