Community discussions

MikroTik App
 
User avatar
broderick
Member Candidate
Member Candidate
Topic Author
Posts: 242
Joined: Mon Nov 30, 2020 7:44 pm

Allowed Remote Requests: Drop input !LAN VS Filter Rules

Fri Apr 23, 2021 1:23 pm

Hi everyone,

I ckecked the "Allowed Remote Requests" box in DNS setting to enable DNS cache in my Mikrotik.
I know that there can be some security issues with that, so I was wondering which setting will prevent dns queries from outside world, especially from attackers

Will this rule, at the end of the rule list, be enough to keep me save from that:
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN log=yes

or I'd better use something like these for example:

add chain=input in-interface=ether1 protocol=udp dst-port=53 action=drop
add chain=input in-interface=ether1 protocol=tcp dst-port=53 action=drop
..and why?
Thanks
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 12001
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: Allowed Remote Requests: Drop input !LAN VS Filter Rules

Fri Apr 23, 2021 2:19 pm

Hi everyone,

I ckecked the "Allowed Remote Requests" box in DNS setting to enable DNS cache in my Mikrotik.
I know that there can be some security issues with that, so I was wondering which setting will prevent dns queries from outside world, especially from attackers

Will this rule, at the end of the rule list, be enough to keep me save from that:
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN log=yes

or I'd better use something like these for example:

add chain=input in-interface=ether1 protocol=udp dst-port=53 action=drop
add chain=input in-interface=ether1 protocol=tcp dst-port=53 action=drop
..and why?
Thanks

First rule block all non LAN connection attempt only to router: DNS, HTTP, WINBOX, etc.,

other (two) only block DNS service coming from "ether1" only for router
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19318
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Allowed Remote Requests: Drop input !LAN VS Filter Rules

Fri Apr 23, 2021 3:51 pm

The first rule you noted is the default firewall rule which is perfectly safe and allows only LAN traffic to hit the router.
If you start messing with the default rules ensure you know what you are doing.


Most folks modify eventually the input and forward chains to more targeted approach. By that I mean the default rules allow ALL user/devices FULL access to the router.
Not a concern necessarily but not a best security practice. I don't want kids friends or devices or compromised computers to have that type of access, even though I have username and password etc..... Best to eliminate threat vectors.

Here is what I do
Here is my minimalist but safe setup.
(1) The idea being, as stated move from default setup (which is safe but not targeted) and has a concept of allow all and block what you don't want.
TO what The previous poster and most who prefer to change the setup to BLOCK ALL by default and then state what is allowed.

(2) Correct in that the goal is to only allow the admin to have access to the router, but users/devices may need some services typically DNS.

(3) For VLAN to VLAN protection and any traffic to and from the LANs, the firewall rules in the forward chain come into play.
The same concept as above applies, modify the default rules, into a concept of block all except what you wish to allow.
All the rules above the +++++ line are default ones that we want to keep and the ones below are the ones the admin adds.
NOTE: In the input chain, do not put in the LAST RULE the DROP rule until the allow admin access rule is in place - otherwise one is locked out!
...
...
/ip firewall filter
{input chain}
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="Allow ADMIN to Router" =\
    in-interface-list=MGMT src-address-list=adminaccess
add action=accept chain=input comment="Allow LAN DNS queries - TCP" \
    connection-state=new dst-port=53 in-interface-list=LAN protocol=tcp
add action=accept chain=input comment="Allow LAN DNS queries-UDP" \
    connection-state=new dst-port=53 in-interface-list=LAN protocol=udp
add action=drop chain=input comment="Drop All Else"
....
{forward chain}
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=accept chain=forward comment="allow LAN  to WAN traffic"
    in-interface-list=LAN  out-interface-list=WAN 
add action=accept chain=forward comment="Allow Port Forwarding" \   {disable when not needed}
connection-nat-state=dstnat  connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="drop all else"

4. The input chain rule requiring the admin access firewall address list ensures only the LANIPs identified have access to the router (via winbox for example). Typically one sets ones IPs through the routers dhcp leases as static, fixed Ips.
/ip firewall address-list
add address=ip_admin-desktop list=adminaccess
add address=ip_admin- laptop list=adminaccess
add address=ip_admin-smartphone list=adminaccess

(5) The other part of this rule as you may have noted is an interface-list=MGMT
Typically this is the scenario.

/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
add name=MGMT (optional)
add name=VlansWith-Internet (optional but if you dont allow all vlans to access internet this provides an easy way to config)

/interface list member
add comment=defconf interface=Ether1 list=WAN
add interface=bridge list=LAN
add interface=vlan10 list-MGMT (this identifies the management lan typically the home lan the admin user is on)
+++++++++++++++++++++++++++++++++++++
add interface=ether5 list=LAN (if you have an emergency access port on the router to reach it for config purposes if bridge or main LAN gets funky)
add interface=ether5 list=MGMT (so as to be able to reach router from emerg access for config purposes)

(6) Can you guess where else we use MGMT.
Correct Look at TOOLS MACSERVER.
Set WINBOX- MAC sever interface=MGMT.

(7) Go To IP Services and turn all services off except for WINBOX and possibly SSH as a backup
a. change default port to something else but write it down!
b. in the Available from, put in the subnets above that are applicable (vlan10 subnet and ether5 subnet)

(8) Go to SYSTEM USers and for the logins allowed to access winbox put in the same subnets as in b.

Thus you have in summary limited access to the router (for config purposes)
by login rules (username and password and subnets)
by winbox access (port number and subnets)
by firewall rules that limit access to winbox mac server
by firewall rules that limit access by subnets and IP addresses.
 
User avatar
broderick
Member Candidate
Member Candidate
Topic Author
Posts: 242
Joined: Mon Nov 30, 2020 7:44 pm

Re: Allowed Remote Requests: Drop input !LAN VS Filter Rules

Fri Apr 23, 2021 5:39 pm

Hi everyone,

I ckecked the "Allowed Remote Requests" box in DNS setting to enable DNS cache in my Mikrotik.
I know that there can be some security issues with that, so I was wondering which setting will prevent dns queries from outside world, especially from attackers

Will this rule, at the end of the rule list, be enough to keep me save from that:
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN log=yes

or I'd better use something like these for example:

add chain=input in-interface=ether1 protocol=udp dst-port=53 action=drop
add chain=input in-interface=ether1 protocol=tcp dst-port=53 action=drop
..and why?
Thanks

First rule block all non LAN connection attempt only to router: DNS, HTTP, WINBOX, etc.,

other (two) only block DNS service coming from "ether1" only for router
ok.
so the first one, although it is a default rule, can block also some useful services and I may come across a few unexpected behaviors, meaning that something wouldn't work as I expected if I forgot that this rule exists.
The second one just aims at blocking dns requests from outside.

Correct?
Thanks
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19318
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Allowed Remote Requests: Drop input !LAN VS Filter Rules

Fri Apr 23, 2021 6:43 pm

Not quite.

1. The LAN rule is not blocking anything from the LAN side.
2. There is no danger of blocking useful services with the default rule.
3. Keep this rule! Unitl you know what you are doing LOL

4. The second rule is useless in context because its already covered by the first rule.
5. When you start playing with input chain rules (to and from the router itself) as noted the most likely and smart change is to add a drop all rule at the end.
This blocks ALL traffic from and to the router.
Therefore what does one have to do as a minimum
a. ensure admin has access to the router
b. ensure users/device have access to services on the router (typically only DNS, sometimes NTP).

Therefore the drop all rule drops every thing, even from the LAN, which ALLOWS you as the admin to then state the two allow rules and basically TO REFINE the security.

Summary: Keep default rules until you understand them better.

Who is online

Users browsing this forum: dj23, GoogleOther [Bot] and 69 guests