If echo request comes from the internet, it will go to the INPUT-chain and the router either responds to it or not. No LAN device can see the request.
If echo request comes from the LAN, the reply from the internet will get state ESTABLISHED and therefore it will be accepted by the following default rule:
Raw “prerouting” rules happen before filter “input”, so the drop icmp at end of the chain happens before the accept in /ip/firewall/filter. See the packet flow diagram in the manual, specifically this one:
ICMP has protections in the OS kernel (e.g. limits on echo reply), so I’d say “recommends” may be strong… I view the manual is more providing a concrete example of how to use the raw (connection-less) filters to do limits and avoid connection tracking…than “must have” rules for security.
Certainly you finely tune the limits in the raw rules, but the value may be minimal. And…adding more rules does slow down packet processing — although the action=jump to the icmp4 chain helps to avoid the performance hit from add’l rules, which is part of the example.
Instead stick to the defaults…
The defaults are safe for a single user and a single WAN and LAN subnet with no complexities.
Once you go beyond that, its 99.999 percent of the time needed to start mucking about in the rules.
The default concept, is block a bunch of stuff and implicitly allow everything else.
Most here prefer to reverse that and state BLOCK everything except traffic we know we need. EXPLICIT allow.
Recommend the following… /ip firewall filter
{Input Chain}
(default rules to keep) 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
( admin rules ) add action=accept chain=input src-address-list=Authorized comment=“Config Access”
add action=accept chain=input comment=“Allow LAN DNS queries-UDP”
dst-port=53 in-interface-list=LAN protocol=udp
add action=accept chain=input comment=“Allow LAN DNS queries - TCP”
dst-port=53 in-interface-list=LAN protocol=tcp
add action=drop chain=input comment=“drop all else” { add this rule last so you don’t lock yourself out }
{forward chain}
(default rules to keep) 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
(user rules) add action=accept chain=forward comment=“allow internet traffic” in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment=“port forwarding” connection-nat-state=dstnat disabled=yes { enable if required }
add action=drop chain=forward comment=“drop all else”
Where the input chain entry of Authorized is a firewall address list ( mostly from static dhcp leases ) /ip firewall address-list
add address=adminIP1 list=Authorized comment=“local address - desktop-wired”
add address=adminIP2 list=Authorized comment=“local address - laptop-wired or wifi”
add address=adminIP3 list=Authorized comment=“local address -smartphone/ipad - wifi”
add address=adminIP3 list=Authorized comment=“remote vpn address”
As noted, the kernel has some controls on ICMP, outside of the firewall, via “/ip/settings/set icmp-rate-limit=” in CLI & enabled by default. So there is some protection again ping attacks without any additional rules.
The help talks about these rules in the “Building Advanced Firewall” section: showing it possible to tweak things like ICMP rates further. I can see an ISP wanting fine-grain control, but not sure enterprise/home customer require anything beyond linux’s built-in protections. Just my opinion.
@anav pretty spot on, the default firewall is excellent starting place. Using the “interface-list” like WAN and LAN is the right way, IMO, to create a firewall.
Since most user don’t read the manual… Mikrotik docs are more reference and examples, than prescriptive of what to do…e.g. you need to know what you want to do before looking at the help
Basically Mikrotik also like dense examples,
Like the “basic firewall” subtle shows using IP address-list, instead of the interface-list used in default — since that’s that’s “more pure” way to view the firewall filters operate at the IP layer (layer-3 in ISO) & not actually on interfaces (although it has helpers to lookup get IP from interface). But operationally using an interface-list is WAY better approach, so why the defaults do it that way. Manual skips the “why”.
And the “advanced firewall” shows “how to” to RAW rules at the same time as showing examples of using a “jump” (since there are no example of action=jump elsewhere) — it does not say “you must do this”…
The default ruleset is elegant and simple and I’d really like to stick to it. However, I need to use port forwarding for http-server so I will probably benefit from more comprehensive ruleset that handles ICMP forwarding, IP spoofings, basic DoS attacks etc.
For extra protection. I can’t guarantee that the server and the software are safe (has no security flaws) so it’s better to block at least part of the malicious traffic before it even passes the router.
If your server does not have secure login (encrypted) then you shouldnt be using those servers.
Assuming they are secure logins, consider
a. src-address-list on your dst-nat rules ( everyone is comming from a public IP address, static or dynamic either directly or from their upstream ISP modem/router and there are many free domain names/urls out there for dynamic IPs.
b. give your users wireguard access to the LAN and specifically only to your servers.
c. host your servers on cloud server, where they are equipped to deal with such issues.
d. consider using zerotrust cloudflare tunnel for hosting.
It’s more than the firewall to secure the router. For example, you’ll likely want to disable unused things in /ip/services. Or, using QoS to manage traffic so DoS attack etc to web server don’t overwhelm the link (or have a limit-at on ICMP to ensure some pings get out when congested). Or, if you’re not using IPv6, disable it (and if you are…it needs to be considered as well)
My thought is more complex rules, also create more complex config to evaluate if complete…and if done wrong someplace, you could be worse off and/or more troubleshooting. But I don’t see any issue with using some of the examples the “Advanced Firewall”, in addition to, the default one if you want a “belt-and-suspenders” approach.
As @anav highlights, you can certain add more rules to drop based on your IPs (in addition to interface list like LAN/WAN). I just think the “invalid” rule covers a lot of case in default (and kernel does rp-filter=loose and icmp throttling via /ip/settings already).
