Comment 38 for bug 406122

(In reply to comment #50)
> FWIW, the Debian report mentions use of the u32 iptables module to suppress
> packets based upon matching a bit-string, as in:
>
> iptables -A INPUT -p udp --dport 53 -j DROP -m u32 --u32 '30>>27&0xF=5'
>
> Unfortunately, the u32 module doesn't seem to exist in RHEL kernels ( and hence
> also CentOS ). The 32 module is mentioned in the manual, even though it doesn't
> exist in the kernel, BTW.
>
> After some experimentation, I've found that a partial workround is to use the
> string module instead searching for a single hex-byte:
>
> iptables -I INPUT -p udp --dport 53 -m string --algo kmp --from 30 --to 31
> --hex-string '|28|' -j LOG --log-prefix "warning: DROPDNS: " --log-level
> warning
>
> Note that this string search matches on 8-bits, whereas u32 matches on 4.
> RFC2136 requires 3 of the other bits to be sent as zero, but ignored if
> non-zero. Hence there's no guarantee that an attacker might not be able to use
> hex-strings 29 through 2F instead, which would need 7 more iptables rules.
> There may be a way of expressing this via a regex, but the iptables manual is
> very thin on details in this regard.
>
> I also assume that string matching on every DNS packet in the kernel is
> probably CPU hungry, but this workround may at least provide enough medicine to
> keep the patient alive until the RPM update ambulance arrives.

This is protection against UDP based queries only. TCP based queries will still knock down your named.