This is my first Mikrotik device, and my first try at a default deny firewall. It is on a home network. Let me know what you think. Everything seems to work, I just want to make sure there are no obvious mistakes, holes, ect. Thank you.
Requirements:
DHCP Server for LAN
DHCP Client from ISP on WAN
DNS Server for LAN
DNS Client from WAN
NTP Server for LAN
NTP Client from WAN
L2TP/IPsec VPN server for Android client. Remote access to LAN and router admin.
Router admin access from the LAN DHCP pool (3 cellphones and a laptop on the wifi).
add action=accept chain=input comment=“Allow Remote Admin, L2TP VPN” dst-port=8291,443 protocol=tcp
src-address-list=“VPN Local IP Range”
(1) The first one appears to be for the purpose of allowing the admin to access the router which is a good idea. However I dont know why you delineate ports?
Not required and why 443 anyway?? We don’t https into the router?
All you need is the following
add chain=input action=accept in-interface-list=MNGMT source-address-list=adminaccess
Where:
a. MGMT identifies every interface that the admin may use to access the router
b. firewall address list called “adminaccess” is where you delineate the static LANIPs of your devices (admin desktop, laptop, ipad, smartphone etc)
This could be a subset of DHCP
(2) The second rule is also confusing, as it appears you think its a good idea to allow direct access to the router from external websites. The quick answer is NO.
If you want to access the router, then use a VPN connection (seems like you have that intent), if so, then guess what you can scrap this rule because you already have a rule that I suggested above to allow access tot he router (just add the VPN local Ip users to adminaccess list!!!
3. You have changed modifed added rules but kept default rules that are no longer relevant.
For example what is covered or what is the purpose of this rule. “add action=drop chain=input comment=“defconf: drop all else not coming from LAN” in-interface-list=!LAN”
When you answer that question, then review your config to see if its needed!
See how it may affect other rules that follow!! is a hint.
(1) and (2) Might be a little off topic, but why don’t we use https? I have only winbox and https services enabled on the router with certificates for https that my browser seems to like. I don’t need any other services, but don’t want to rely only on winbox.
Per your suggestion, I replaced the 2 admin rules with:
I kept the default drop all else not from LAN rule to prevent DNS and NTP requests from WAN. My allow DNS and NTP rules are below this, allowing requests from LAN, and my accept established, related rule is above this to allow replies to requests sent out by the router. Is this correct? Or would it be better if the DNS and NTP rules specify in-interfaces?
Also, with the new management rule I changed drop all else not from LAN to drop all else from WAN.
The reason why you no longer need the rule.
add action=drop chain=input comment=“defconf: drop all else not coming from LAN” in-interface-list=!LAN
Is because it ALLOWS ANY RULE COMING NOT FROM THE WAN ( lan to router, router to lan, router to WAN) and therefore any rule allowing anything from the LAN after this rule is redundant the traffic is already accepted and will not hit any other rules.
So all the DNS NTP and allow management rules etc. would never be used.
The rule basically opens the router TO ALL on the LAN, which is fine for the default rule.
We remove that rule because we added the better rule add chain=input action=drop comment=“drop all else”
This drops all traffic wan to router, router to wan, lan to router, router to lan.
Thus all we need to do above this is basically state what is allowed.
such as admin access
The only other things required are lan user access to router services DNS, NTP etc.
Oh I forgot the vpn rules at the top are required.
Okay regarding https access, interesting I have never used that for access, Id much rather use winbox and my own port of choosing.
Personal choice I guess…
Everything is based on the default firewall rules. Complete them with the rolls you need.
Leaving dns port 53 open is not a “good practice”! It is better to close it. http://forum.mikrotik.com/t/deny-outside-dns-on-port-53-permit-inside-dns/84285/1 The order of the firewall rules is also important because the rules are executed in a top-down order.
I’ll copy it for you as an example.
/ip firewall address-list
add address=192.168.X.X/24 list=Allowed-IP
/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="Allow DNS to local" dst-port=53 \
in-interface-list=!WAN protocol=udp src-address-list=Allowed-IP
add action=accept chain=input comment=L2TP connection-state=new dst-port=\
500,1701,4500 protocol=udp
add action=accept chain=input comment="IKE IPSec" protocol=ipsec-esp
add action=accept chain=input comment=\
"Allow access to router from known network" in-interface-list=!WAN \
src-address-list=Allowed-IP
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
Sorry Johnson, your muddying the waters and leaving some default rules in place the OP no longer needs.
The allow services rule is just fine as it is because one delineates all those on the LAN interface have access.
NO further granularity is desired by the OP for allowing or disallowing DNS from a subset of lan users.
ok if you need to allow dns 53 from everywhere, you can leave input chain = Allow dns.
Only after a while the author will have a question - why my router is so busy and there are problems with speed
I agree 100%, I should have added the rules to explain my line of thinking!
the rules should be
add action=accept chain=input comment=“Allow DNS, UDP” dst-port=53 protocol=udp in-interface-list=LAN
add action=accept chain=input comment=“Allow DNS, TCP” dst-port=53 protocol=tcp in-interface-list=LAN
add action=accept chain=input comment=“Allow NTP” dst-port=123 protocol=udp in-interface-list=LAN
Only the admin needs full access to the router and lan users only need required services!
I want to clarify this. In the unmodified default configuration, this is true. However, in the firewall in my original post this rule passes all LAN traffic to be tested by the remaining input chain rules. I reset all the counters and my DNS and NTP accept rules did show hits.
I intend to follow your advice and get rid of this rule, but I need to make the accept rules after this rule more specific. I do want to continue to avoid an open dns resolver, as johnson seems to be getting at.
Someone please explain me where is the point on default configuration that permit DNS from WAN,
or why on default configuration is needed to drop incoming DNS request from WAN on input chain…
/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"
add chain=input action=accept protocol=icmp comment="defconf: accept ICMP"
add chain=input action=accept dst-address=127.0.0.1 comment="defconf: accept to local loopback (for CAPsMAN)"
add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
[...]
On the OP “export”:
/ip firewall filter
[...]
add action=drop chain=input comment="defconf: drop all else not coming from LAN" in-interface-list=!LAN
add action=accept chain=input comment="Allow DNS, UDP" dst-port=53 protocol=udp
add action=accept chain=input comment="Allow DNS, TCP" dst-port=53 protocol=tcp
add action=accept chain=input comment="Allow NTP" dst-port=123 protocol=udp
[...]
The rules “opened to the entire world” are putted after “drop all from the outside world”
and really (ON THAT POSITION) are perfectly secure because the traffic coming from WAN is already blocked.
As @anav suggest, is better specify “coming from LAN” because if are accidentally moved on wrong place… BANG!
yes I agree. The default config does not specify permit dns from Wan, but the author had set it in his configuration. He asked if the configuration will be correct without errors ect ..
Maybe he needs it? Maybe he typed it in by mistake?
I personally blocked dns port 53 in the Raw chain section
Thanks for the information.
I also suggest @Greenfun2 to put the default rules on the same initial place, for example, if is invalid, can’t be “established,related,untracked”
Moving invalid drop before “established,related,untracked” you only slow traffic, no one type of advantage (except if 51% of your traffic is invalid…)
And about “invalid” the system do not check the integrity of the packet, but other things, but is not this topic to explain all again.
Let me explain with some examples (ignoring selection error on menu),
you add a WAN interface, but you forget to set on group WAN… perfect, not problem is !LAN
you remove one ethernet from bridge and use for another scope… not problem, the bridge is on LAN, the ethernet not, the ethernet is !LAN…
you add a VPN, but you forget to put it on right group, probably must be set on WAN, but still no problem, the VLAN is !LAN
you delete LAN grup for errors: not problem, the rule stop working because there is not a corrispondence on group
etc…
Obvously this can not prevent disaster if you delete all interface on LAN group…
And this also prevent you to accidentally remove the access to the router,
if you delete or move accidentally the rule that permit to access the ruter when is present “drop all input unconditionally” at the end…
Or if accidentally you put “drop all input unconditionally” on top…
and you have bad habit to disable MAC telnet…
hope if the device have serial port…
Anav,
This configuration has been for me for many years no problem. You explained very much and well, but would you please not say what is wrong with my case?
I need some grammar corrector on browser...