I dont know what your network looks like behind the mikrotik and I dont know how your WAN setup looks like (how many ISPs, how many WANIPs etc).
I dont know if port forwarding is needed etc etc… Lacking context just a bunch of rules.
I will say I am very confused by a very messy rule set especially with DNS.
I will say that I would REMOVE all external access you are permitting to the router AND ONLY USE vpn for remote connection.
Then use winbox through the VPN.
Also anything that has a source address list, that does not impact IPs on your network I would put in /ip raw add chain=prerouting, action=drop, source-address-list=XXXXXXX
(For example the bogon list but be sure to NOT include the bogon that contains your private IP network such as 192.168.0.0/16 or whatever it is).
The context is my home router. One ISP, one wan ip, a lan bridge with few ethernet ports, a dhcp server running on it and a masquerade of the lan network. That’s all.
What’s wrong with the DNS? The rules drop the external dns requests
Input chain specifically allows to access pretty much everything running on router from everywhere, except DNS from WAN. There is drop rule at the end, to block connections from other sources than LAN bridge, but it’s not very useful when it’s after rules that allow (almost) everything. The order or rules matters! And do you really need some of those things (e.g. ftp and telnet) at all? If not, do not waste time with anti-bruteforcing and disable services instead.
Forward chain is wide open for anything in any direction. It’s not the best idea, even though you’re probably safe from internet, but anyone connected to same subnet as your WAN can freely access anything in your LAN.
I will post a variation of my rule set but trying to keep your functionality.
HOWEVER I will let others describe a VPN way to access your router remotely, I am not qualified yet to give that advice LOL.
First lets make the router secure for everyday use!!
Where I differ is my DNS.
I force users to use the LAN gateway IP as their DNS server, so they cannot use anything else.
Then you can decide what all will use! For example., to use the peer DNS servers underc dhcp client setting and thus have dynamic servers provided by your ISP, or you can turn this off here at DCHP client,and in the IP DNS setting put in the ones you want such as google 8.8.4.4 or OPENDNS… etc.
/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="Allow ADMIN Access" in-interface=\
HomeBridge in-interface=LAN src-address-list=support {you identify who is allowed access to the router typically the PCs the admin may use}
add action=accept chain=input comment="Allow LAN DNS queries - TCP" dst-port=\
53 in-interface=LAN protocol=tcp
add action=accept chain=input comment="Allow LAN DNS queries-UDP" dst-port=53 \
in-interface=LAN protocol=udp
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp (if you dont want to allow ICMP ping simply remove this rule)
add action=drop chain=input comment="Drop ALL Else" log=yes log-prefix=\
"INPUT - DROP ALL"
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 HOMELAN to WAN" \
in-interface=HomeBridge out-interface=WAN
add action=accept chain=forward comment=\
"Allow Port Forwarding - DSTNAT" connection-nat-state=dstnat
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=log chain=forward comment="Show ALL Else Dropped" log=yes \
log-prefix="FORWARD DROP-All Else"
add action=drop chain=forward comment="DROP ALL Else"
add action=drop chain=output comment="Drop Access to WebUI" protocol=tcp \
src-port=80
/ip firewall nat
add action=masquerade chain=srcnat comment="SCR_NAT for LAN Users" \
ipsec-policy=out,none out-interface=WAN
add action=dst-nat chain=dstnat comment="SIMOGERE_Server" in-interface=WAN \
protocol=tcp dst-port=5150 to-addresses={your server LANIP}
add action=redirect chain=dstnat comment=\
"Force Users to Router for DNS - TCP" dst-port=53 protocol=tcp
add action=redirect chain=dstnat comment=\
"Force Users to Router for DNS - UDP" dst-port=53 protocol=udp
/ip firewall raw
add action=drop chain=prerouting comment="Drop Badguys" \
in-interface=WAN src-address-list=blacklist
add action=drop chain=prerouting comment="Drop Bogons" \
in-interface=WAN src-address-list=bogons {if your blacklist already includes bogons, many do, then this rule is not required}
add action=drop chain=prerouting comment="Drop Scanners"
in-interface=WAN src-address-list=Scanners
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh address=LANIP or LAN subnet (typically matches your input allow rule for admin above) PORT=zzzzz (change default to one of your choosing)
set api disabled=yes
set winbox address=LANIP or LAN subnet (typically matches your input allow rule for admin above)
set api-ssl disabled=yes
/ip ssh
set strong-crypto=yes
I am still thinking about the port scanner issue…
My INPUT filter rules (would be in order the FIRST input rules) would look like:
add chain=input action=add-src-to-address-list address-list=“Scanners”
address-list-timeout=2d in-interface=wan protocol=tcp dest-ports=23,53,123,445, 8291
add chain=input action=add-src-to-address-list address-list=“Scanners”
address-list-timeout=2d in-interface=wan protocol=UDP dest-ports=23,53,123,445, 8291
The associated IP RAW rule I would place AFTER the blacklist and bogon list rules as that should block most of the nonsense (rule shown above).
Last note" Be careful with Bogon list entries and be sure not to include the one that describes your private network typically its the 192.168.0.0/16 one! Remove it!!
It’s just a little hard to believe that you need to access all those port from anywhere (whole internet). SSTP, PPTP, sure, if you use router as VPN server. Even WinBox or http for WebFig can make sense (just make sure that you don’t have outdated RouterOS version, there are some very ugly vulnerabilities in older ones!). But things like ftp, telnet, snmp, both encrypted and plaintext api, really?
Problem with forward chain is that default action is accept. Yours drops only invalid packets, but if someone would try to connect to 192.168.x.y (or whatever you have in LAN), that’s not invalid and router will be happy to let it pass. Good news is that not just anyone on internet can do it, but it still doesn’t make it right. Default firewall has a rule like this at the end:
and it’s blocking anything coming from WAN, unless it’s a forwarded port (packets coming from WAN as replies to connections originated from LAN are accepted by “accept established,related,untracked” rule).
My basic rules for both input and forward are:
accept established, related and untracked
drop invalid
accept everything from LAN
other accept rules for stuff I want to specifically allow from internet
drop everything else
But you can keep what you have, but only add rules for services you really need to have available from internet (the less, the better) and put them between “Drop invalid” and “Drop all not coming from LAN” rules. What you don’t allow and will come from internet (or better “not from LAN Bridge”) will be dropped, e.g. you don’t need to specifically block DNS from WAN.
Rules are checked from top to bottom and when a rule matches the packet, processing stops there.
So all those accept rules you have, with only protocol and port, allow connecting to given ports from everywhere. As I wrote before, you’re allowing access to almost every service that runs on router. So with the last drop rule in input chain, you’re mostly “protecting” only closed ports. And when they are closed, they don’t do anything anyway.
Even if you need to have all those ports open to whole world, you should move the rules after the two for establieshed/related/untracked/invalid. Because as it is now, every single packet is checked if it’s for port 53 from WAN, port 53 from anywhere else, then ports 443, 5678, … when instead it could be accepted right away as established (if it’s the case), if you had that rule as first.