3 ms·

Interesting--I'd like to know more. Would you please provide example command(s) of blocking both ANY queries and NOERROR responses that you've had relative suc

Interesting--I'd like to know more. Would you please provide example command(s) of blocking both ANY queries and NOERROR responses that you've had relative success with? Thanks!

LinuxBender 9y ago
Certainly! -A OUTPUT -p udp -m udp --sport 53 -m string --hex-string "|8500|" --algo kmp --from 30 --to 31 -j ACCEPT -A OUTPUT -p udp -m udp --sport 53 -m string --hex-string "|8400|" --algo kmp --from 30 --to 31 -j ACCEPT -A OUTPUT -p udp -m udp --sport 53 -j DROP The above used in the filter table drops anything that does not match NOERROR recursive and NOERROR non-recursive responses. -A PREROUTING -i eth0 -p udp -m udp --dport 53 -m string --hex-string "|0000ff0001|" --algo bm --from 40 --to 65535 -j DROP The above used in the raw table drops "ANY". It could probably be optimized to search through less of the packet. -A INPUT -i eth0 -p udp -m state --state NEW -m length --length 24:120 -m udp --dport 53 -j ACCEPT Above is the inbound rule that blocks some overflow attempts.
- heybrendan 9y ago
  Thanks a bunch. I'll take a crack at implementing something similar, much appreciated!
  - LinuxBender 9y ago
    No problem. If you run into issues, it could be that your particular DNS server may put the result code in a different part of the packet. If that is so, simply use tcpdump -p -i interface -NNnn -s0 -c100 -SeX port 53 and look for the 8400 and 8500 hex codes and what the number in the far left column is. Then adjust iptables accordingly to look in that part of the packet. Another way to do this is to modify the source code of the DNS server, but I found that to be too time consuming. Disclaimer: I should also add that the above method of using iptables to drop anything we do not know about does violate some RFC's and instead follows the thing our Mom's taught us, "If you don't have anything nice to say...". That said, you would have to decide if bending some RFC's is ok. In a Corporate environment it can lead to confusion and time lost troubleshooting.

Interesting--I'd like to know more. Would you please provide example command(s) of blocking both ANY queries and NOERROR responses that you've had relative success with? Thanks!

LinuxBender 9y ago

Certainly! -A OUTPUT -p udp -m udp --sport 53 -m string --hex-string "|8500|" --algo kmp --from 30 --to 31 -j ACCEPT -A OUTPUT -p udp -m udp --sport 53 -m string --hex-string "|8400|" --algo kmp --from 30 --to 31 -j ACCEPT -A OUTPUT -p udp -m udp --sport 53 -j DROP The above used in the filter table drops anything that does not match NOERROR recursive and NOERROR non-recursive responses. -A PREROUTING -i eth0 -p udp -m udp --dport 53 -m string --hex-string "|0000ff0001|" --algo bm --from 40 --to 65535 -j DROP The above used in the raw table drops "ANY". It could probably be optimized to search through less of the packet. -A INPUT -i eth0 -p udp -m state --state NEW -m length --length 24:120 -m udp --dport 53 -j ACCEPT Above is the inbound rule that blocks some overflow attempts.

heybrendan 9y ago
Thanks a bunch. I'll take a crack at implementing something similar, much appreciated!
- LinuxBender 9y ago
  No problem. If you run into issues, it could be that your particular DNS server may put the result code in a different part of the packet. If that is so, simply use tcpdump -p -i interface -NNnn -s0 -c100 -SeX port 53 and look for the 8400 and 8500 hex codes and what the number in the far left column is. Then adjust iptables accordingly to look in that part of the packet. Another way to do this is to modify the source code of the DNS server, but I found that to be too time consuming. Disclaimer: I should also add that the above method of using iptables to drop anything we do not know about does violate some RFC's and instead follows the thing our Mom's taught us, "If you don't have anything nice to say...". That said, you would have to decide if bending some RFC's is ok. In a Corporate environment it can lead to confusion and time lost troubleshooting.