-1

I am trying to filter the dns requests from my local network. Only authorize requests to specific dns and deny the rest, but it has not worked for me. This is my rule (with dns google example):

internal=enp2s1
external=enp2s0

iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

echo 1 > /proc/sys/net/ipv4/ip_forward # default 0
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6 # default 0
echo 1 > /proc/sys/net/ipv6/conf/default/disable_ipv6 # default 0
echo 1 > /proc/sys/net/ipv6/conf/lo/disable_ipv6 # default 0

iptables -A INPUT -p all -i lo -j ACCEPT
iptables -A INPUT -s 192.168.0.10 -j ACCEPT
iptables -A OUTPUT -p all -o lo -j ACCEPT
iptables -A OUTPUT -p all -s 127.0.0.1 -j ACCEPT
iptables -t mangle -A PREROUTING -p all -i lo -j ACCEPT
iptables -t mangle -A PREROUTING -p all -s 127.0.0.1 -j ACCEPT
iptables -t nat -A PREROUTING -p all -i lo -j ACCEPT
iptables -t mangle -A PREROUTING -i lo -s 127.0.0.0/8 -j ACCEPT
iptables -t mangle -A PREROUTING -i lo -d 127.0.0.0/8 -j ACCEPT

iptables -t mangle -A PREROUTING -i $internal -s 255.255.255.0/32 -j ACCEPT
iptables -t mangle -A PREROUTING -i $internal -d 255.255.255.0/32 -j ACCEPT

iptables -t mangle -A PREROUTING -i $internal -s 192.168.0.0/24 -j ACCEPT
iptables -t mangle -A PREROUTING -i $internal -d 192.168.0.0/24 -j ACCEPT

iptables -t mangle -A PREROUTING -p udp --dport 853 -j DROP
iptables -t mangle -A PREROUTING -p tcp --dport 853 -j DROP

dns="8.8.8.8 8.8.4.4"
for ip in $dns; do
   iptables -A INPUT -s $ip -p udp --sport 53 -m state --state RELATED,ESTABLISHED -j ACCEPT
   iptables -A OUTPUT -d $ip -p udp --dport 53 -m state --state RELATED,ESTABLISHED -j ACCEPT
   iptables -A FORWARD -d $ip -p udp --dport 53 -m state --state RELATED,ESTABLISHED -j ACCEPT
done
iptables -A FORWARD -p udp --dport 53 -j REJECT

For example, if I put manually cloudflare dns on a PC on my local network (1.1.1.1 1.0.0.1) the PC has internet access

PD:

  1. The rule "-m state --state RELATED,ESTABLISHED" is in this question selected as correct
  2. The blocking rule is in this question selected as correct
  3. I have tried the same blocking rule on all chains (INPUT, Mangle, OUTPUT, FORWARD) and change REJECT with DROP and it does not block
  4. I added additional blocking rules for src and it also does not block. Example:
iptables -A FORWARD -s $ip -p udp --sport 53 -m state --state RELATED,ESTABLISHED -j ACCEPT
# and block
iptables -A FORWARD -p udp --sport 53 -j DROP

Note: These rules are also for TCP (but not to repeat them I do not put them)

Update:

I changed dns rule to:

dns="8.8.8.8 8.8.4.4"
for ip in $dns; do
   iptables -A INPUT -s $ip -p udp --sport 53 -j ACCEPT
   iptables -A OUTPUT -d $ip -p udp --dport 53 -j ACCEPT
   iptables -A FORWARD -d $ip -p udp --dport 53 -j ACCEPT
done
iptables -A INPUT -p udp --sport 53 -j DROP
iptables -A OUTPUT -p udp --dport 53 -j DROP
iptables -A FORWARD -p udp --dport 53 -j DROP

But it doesn't do the blocking correctly either

Note: INPUT rule with or without "-m state --state RELATED,ESTABLISHED -j ACCEPT" it is irrelevant because what interests me is to block the connection and it is what does not happen

thanks

7
  • A couple of things: 1: you should post your entire iptables config. 2: I don't know what you mean by 'selected as correct'. The RELATED and ESTABLISHED matches are for matching exactly that: traffic that has already been accepted by other rules. In your case, they make your rules not match. 3: you can see how many hits rules have with iptables -L -n -v. 4: note the existence of 'DNS over http'. What your trying may be pointless.
    – Halfgaar
    Jun 15, 2020 at 19:33
  • 'selected as correct' means that the information was obtained from an answer to a similar question, which was selected as correct (check the link)
    – acgbox
    Jun 15, 2020 at 19:42
  • Also note that clients can set IPv6 DNS addresses.
    – Halfgaar
    Jun 15, 2020 at 19:49
  • Your "selected as correct" misses the point from original question in your quoted answer. Jun 15, 2020 at 19:52
  • 1
    "I am trying to filter the dns requests from my local network." Are you aware that browsers for example now use more and more DNS over HTTPS and hence blocking port 53 will not block them whatsoever to do DNS queries? Jun 20, 2020 at 5:27

1 Answer 1

0

Short summary

iptables -A OUTPUT -d $ip -p udp --dport 53 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -d $ip -p udp --dport 53 -m state --state RELATED,ESTABLISHED -j ACCEPT

rules should be:

iptables -A OUTPUT -d $ip -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -d $ip -p udp --dport 53 -j ACCEPT

Explanation

I'll use client IP 192.168.100.100 and port 12345 as example.

When a client (192.168.100.100) in your network sends a DNS request, it sends a UDP packet from port 12345 to DNS server's port 53.

When the packet goes via your Linux router box, the router creates a connection tracking entry for the DNS query. This connection tracking entry has multiple states, one of them ESTABLISHED.

Now, in your original rules, you require ESTABLISHED state for the first outgoing DNS query packets. In the example case, client 192.168.100.100 sending UDP packet from port 12345 to 8.8.8.8 port 53, there is no ESTABLISHED entry for that quintuple. Therefore the firewall drops the packet.

When the match state is removed from outgoing rules, then all outgoing packets to DNS server port 53 are approved, and connection tracking entry is created properly.

Then you can match the return direction using the -m state --state ESTABLISHED, because the connection tracking entry exists.

3
  • @ajcg The INPUT rule was correct as-is, so doesn't need any changes. Jun 15, 2020 at 20:33
  • DNS uses UDP AND TCP. Jun 20, 2020 at 5:26
  • @PatrickMevzek please read Note: These rules are also for TCP (but not to repeat them I do not put them)
    – acgbox
    Jun 21, 2020 at 17:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.