Community discussions

MikroTik App
draid
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 91
Joined: Wed Aug 22, 2018 5:42 pm

DNS Cache Setup - Allow-remote-requests

Mon Nov 09, 2020 9:37 pm

Hello guys,

Currently I'm using couple of Mikrotik devices in my internal network. The main router has two ISP connections (PPoE and Static coming from DSL model as backup). I've also set up the router with Allow-remote-requests=yes. As for now I don't have any specific rules to drop port 53 inputs but I have a rule to drop all not coming from LAN. I was wondering if I have to set up rules to allow port 53 UDP/TCP on the input chain for LAN and then specifically drop or my firewall configuration is good enough. I would appriciate any help to improve the security of my home network, here is the firewall export:
Code:Select all
/ip firewall filter add action=accept chain=input comment=\ "defconf: accept established,related,untracked" connection-state=\ established,related,untracked add action=drop chain=input comment="defconf: drop invalid" connection-state=\ invalid add action=accept chain=input comment="defconf: accept ICMP" \ in-interface-list=!WAN protocol=icmp add action=drop chain=input comment="defconf: drop all not coming from LAN" \ in-interface-list=!LAN add action=accept chain=forward comment="defconf: accept in ipsec policy" \ ipsec-policy=in,ipsec add action=accept chain=forward comment="defconf: accept out ipsec policy" \ ipsec-policy=out,ipsec add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \ connection-state=established,related add action=accept chain=forward comment=\ "defconf: accept established,related, untracked" connection-state=\ established,related,untracked add action=drop chain=forward comment="defconf: drop invalid" \ connection-state=invalid add action=drop chain=forward comment=\ "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \ connection-state=new in-interface-list=WAN /ip firewall nat add action=src-nat chain=srcnat comment="SRC-NAT MainLink" out-interface=\ pppoe-out1 to-addresses= ISP1 add action=src-nat chain=srcnat comment="SRC-NAT BackUp" out-interface=\ ether2-WAN2 to-addresses= ISP2
Top
User avatar
anav
Forum Guru
Forum Guru
Posts: 17447
Joined: 太阳2月18日,2018年十一28便士m
Location:Nova Scotia, Canada
Contact:

Re: DNS Cache Setup - Allow-remote-requests

Mon Nov 09, 2020 10:10 pm

Confusing terminology for me.
Internal doesnt mean touching public IP.
So does the MT get a public IP?? , or are you using double NAT so to speak.
Top
tippenring
Member
Member
Posts: 304
Joined: Thu Oct 02, 2014 8:54 pm
Location:St Louis MO
Contact:

Re: DNS Cache Setup - Allow-remote-requests

Mon Nov 09, 2020 10:24 pm

您的规则“添加action =删除链=输入评论= "德fconf: drop all not coming from LAN" in-interface-list=!LAN" requires your interface list "LAN" to be configured correctly, and the rule must be appropriately positioned in the input chain rule order. If the conditions are correct, it will drop all traffic destined to the router via ingress interfaces not listed in the interface list named "LAN", including DNS.

Do you need an explicit rule to drop DNS from the internet? The rule is in an appropriate position in the input rule chain. So the answer depends on your interface list configuration.
Top
User avatar
mkx
Forum Guru
Forum Guru
Posts: 10287
Joined: Thu Mar 03, 2016 10:23 pm

Re: DNS Cache Setup - Allow-remote-requests

Mon Nov 09, 2020 10:27 pm

The single most important fact about ROS firewall: at the end of each chain there's an implicitacceptrule. Keep that in mind when analyzing firewall rules.

So this rule
Code:Select all
add action=accept chain=input comment="defconf: accept ICMP" \ in-interface-list=!WAN protocol=icmp
doesn't have any effect since there's no rule dropping any!WANafter the quoted rule.

And this applies to your question about DNS (port 53): unless you drop those connections this way or another they are alowed. Nothing in your firewall configuration is blocking DNS requests from LAN to router.
Top
draid
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 91
Joined: Wed Aug 22, 2018 5:42 pm

Re: DNS Cache Setup - Allow-remote-requests

Mon Nov 09, 2020 10:45 pm

Confusing terminology for me.
Internal doesnt mean touching public IP.
So does the MT get a public IP?? , or are you using double NAT so to speak.
Yeah my bad, now when I'm reading it again it seems to not be really clear. I have a hEX in the following setup with recursive failover:
Eth1: ISP1 main link via PPoE with static public IP
Eth2: ISP2 backup link via static adress from ADSL device with static public IP
All devices behind it in the LAN are using this router as DNS server.
您的规则“添加action =删除链=输入评论= "德fconf: drop all not coming from LAN" in-interface-list=!LAN" requires your interface list "LAN" to be configured correctly, and the rule must be appropriately positioned in the input chain rule order. If the conditions are correct, it will drop all traffic destined to the router via ingress interfaces not listed in the interface list named "LAN", including DNS.

Do you need an explicit rule to drop DNS from the internet? The rule is in an appropriate position in the input rule chain. So the answer depends on your interface list configuration.
I have set up the lists in a pretty simple way. As I'm using the eth2 as WAN I've just disabled it from the bridge and moved it to WAN interface list. Both lists are the ones coming with the def conf. Here is the export:
Code:Select all
/接口列表添加评论= defconf名称= WAN添加comment=defconf name=LAN /interface bridge port add bridge=bridge comment=defconf disabled=yes interface=ether2-WAN2 add bridge=bridge comment=defconf interface=ether3 add bridge=bridge comment=defconf interface=ether4 add bridge=bridge comment=defconf interface=ether5 add bridge=bridge comment=defconf interface=sfp1 /interface detect-internet set internet-interface-list=WAN lan-interface-list=LAN wan-interface-list=WAN /interface list member add comment=defconf interface=bridge list=LAN add comment=defconf interface=pppoe-out1 list=WAN add interface=ether2-WAN2 list=WAN

The order of the rules in the firewall are as exported. I was wondering if I need to explicitly allow DNS on port 53 for LAN and then drop it again in the input chain with the rules presented in my firewall. So something like this:
Code:Select all
add action=accept chain=input comment="LAN DNS-UDP" dst-port=53 \ in-interface-list=LAN protocol=udp add action=accept chain=input comment="LAN DNS-TCP" dst-port=53 \ in-interface-list=LAN protocol=tcp
And then drop the dst-port=53 TCP/UDP in WAN?
The single most important fact about ROS firewall: at the end of each chain there's an implicitacceptrule. Keep that in mind when analyzing firewall rules.

So this rule
Code:Select all
add action=accept chain=input comment="defconf: accept ICMP" \ in-interface-list=!WAN protocol=icmp
doesn't have any effect since there's no rule dropping any!WANafter the quoted rule.

And this applies to your question about DNS (port 53): unless you drop those connections this way or another they are alowed. Nothing in your firewall configuration is blocking DNS requests from LAN to router.
I do not want to block the DNS from the LAN as if I do, all devices which are currently using the router as DNS server will need static DNS. I want to prevent it happening from outside.

On the other remark. Does this mean I should add:
Code:Select all
add action=drop chain=input comment="Drop ICMP"\ in- interface-list=WAN protocol=icmp add action=accept chain=input comment="defconf: accept ICMP" \ in-interface-list=LAN protocol=icmp
Top
User avatar
anav
Forum Guru
Forum Guru
Posts: 17447
Joined: 太阳2月18日,2018年十一28便士m
Location:Nova Scotia, Canada
Contact:

Re: DNS Cache Setup - Allow-remote-requests

星期一2020年11月09、11

Okay this is the basic default setup and should be your starting point.
All will work right off the bat. However I highlight the following rules.
Code:Select all
/ip firewall filter add action=accept chain=input comment=\ "defconf: accept established,related,untracked" connection-state=\ established,related,untracked add action=drop chain=input comment="defconf: drop invalid" connection-state=\ invalid add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp add action=accept chain=input comment=\ "defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1 add action=drop chain=input comment="defconf: drop all not coming from LAN" \ in-interface-list=!LAN add action=accept chain=forward comment="defconf: accept in ipsec policy" \ ipsec-policy=in,ipsec add action=accept chain=forward comment="defconf: accept out ipsec policy" \ ipsec-policy=out,ipsec add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \ connection-state=established,related add action=accept chain=forward comment=\ "defconf: accept established,related, untracked" connection-state=\ established,related,untracked add action=drop chain=forward comment="defconf: drop invalid" \ connection-state=invalid add action=drop chain=forward comment=\ "defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \ connection-state=new in-interface-list=WAN /ip firewall nat add action=masquerade chain=srcnat comment="defconf: masquerade" \ ipsec-policy=out,none out-interface-list=WAN
input chain
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
forward chain
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN

What I recommend is unpack these rules and apply them differently.
The input chain rule tries to cover off blocking traffic from WAN and allow all LAN traffic to the router.
Personally, only the admin should have full access to the router and the LAN users for necessary sercvices DNS< NTP etc.

Thus recommend
add action=accept in-interface-list=LAN source-address-list=admin_access
where one adds a firewall address list
add address=ipofadmindesktop list=admin_access
add address=ipofadminlaptop list=admin_access
add address=ipofadminipad list=admin_access etc..

Then for users as you stated......
allow UDP and TCP on port 53 for lan users.

Finally you can add the last drop all rule
add chain=input action=drop comment="drop all else" (caution you need to have admin access first or you will lock yourself out of the router)
++++++++++++++++++++++++++++++++++++++

Forward chain - that rule tries to block all wan to lan traffic other than port forwardings.
I change this to allow port forwarding (if there is to be any otherwise dont need it)
and a last rule
add chain=forward action=drop comment="drop all else"
Top

Who is online

Users browsing this forum:Ahrefs [Bot],alvermanand 24 guests