Fri Feb 19, 2021 12:22 am
Looks good!
The default rules are excellent in that a user can plug in the router and safely work right away.
However they can be refined.
You may have noticed that the default rules are setup with a design that says, EVERYTHING IS ALLOWED, unless we deny it.
So it relies on the user to know which things to deny.
It does this with really broad hammer by these two rules.
{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 log=yes log-prefix=\
"not DSTNATed"
Both use the ! symbol which means everything but not the following which is actually a tricky rule that can have unintended consequences in a config.
They are safely used here but are often more difficult to understand as its like a double negative when talking.
So I dont like these rules because they are not as straightforward as possible. In the case of the forward chain the rule is dual hatted, another thing I dont like (KISS), it stop traffic general but is also the rule that allows port forwarding.
So the subtle change is to turn the firewall rules to a different design, that is to BLOCK ALL TRAFFIC, and only have allow rules for traffic the admin wants to permit.
Since I certainly am not aware of all the things possible, this is the safest approach for me.
Easily accomplished by adding a drop all rule at the end of both chains. In the input chain one needs to do this after adding an allow rule for the admin to access the route.
SO, the default rules which you basically have now then look like this......
{input chain}
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 Router-ACCESS only for ADMIN" in-interface=Bridge
source-address-list=AdminAccess (note)
add action=accept chain=input comment="Allow access to router dns services for all users" in-interface=LAN\
dest-port=53 protocol=tcp connection-state=new
add action=accept chain=input comment="Allow access to router dns services for all users" in-interface=LAN\
dest-port=53 protocol=udp connection-state=new
add action=drop chain=input comment=Drop
We add an allow rule, on the interface that the admin uses, in your case bridge, and is narrowed down to a list of IP addresses you enter
(ip static of desktop, laptop, smartphone, ipad etc.......). No one else needs full access to the router itself.
note: this list is made up in the firewall address list.
If you dont have this rule in place first and you add a drop rule at the end you will lock yourself out of the router LOL.
We then add rules to allow users that require services from the router, these are normally only DNS, sometimes people provide NTP to devices on the LAN.
Next lets look at the changes to the forward chain.
{forward chain}
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="Internet Access" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="Allow port forwarding"\
connection-nat-state=dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward comment=Drop
Here we added an allow rule for lan to wan traffic
We added an allow port forwarding rule.
Dropped everything else.
If we had vlans for example, the drop rule would ensure that at layer 3 they would not talk to each other.
If you had a shared printer on different subnets, one would make an allow rule for subnetA, to access shared printer on subnet B.
If you wanted the admin on vlan A, to be able to access other vlans, you would make such a rule.
So basically this construct allows the admin to more clearly config as to what is permissible.
As an aside for port forwarding, if you can its best to get a defined list of external users, their public IP addresses and put this in a firewall address list.
Then add the list to the destination nat rule..........as follows......
add action=dst-nat chain=dstnat comment="mike6715b - MC" dst-port=25565 \
in-interface=pppoe-out log=yes log-prefix=mc-server protocol=tcp \
to-addresses=10.20.0.10 source-address-list=allowed_users
You have pointed out that the ports are visible on scans but appear as closed.
If you add a source address list to the dstnat rules, the ports are NOT visible on scans at all.
Also I should point out that if the dst ports are the same as to ports, you dont need to enter the to-ports at all, and that is why they are not shown above.