Hello All
Good day from this side. please, I have a question about the advanced firewall rules posted on MikroTik page. I'm still learning about firewall in general, why would the last 3 rules below say "accept all coming in from WAN and LAN", then drop the rest. Isn't this contradicting? Why are they accepting all from LAN and WAN? Wouldn't this be considered dangerous? Can someone please help explain. Thanks in advance.

/ip firewall raw
add action=accept chain=prerouting comment="defconf: enable for transparent firewall" disabled=yes
add action=accept chain=prerouting comment="defconf: accept DHCP discover" dst-address=255.255.255.255 dst-port=67 in-interface-list=LAN protocol=udp src-address=0.0.0.0 src-port=68
add action=drop chain=prerouting comment="defconf: drop bogon IP's" src-address-list=bad_ipv4
add action=drop chain=prerouting comment="defconf: drop bogon IP's" dst-address-list=bad_ipv4
add action=drop chain=prerouting comment="defconf: drop bogon IP's" src-address-list=bad_src_ipv4
add action=drop chain=prerouting comment="defconf: drop bogon IP's" dst-address-list=bad_dst_ipv4
add action=drop chain=prerouting comment="defconf: drop non global from WAN" src-address-list=not_global_ipv4 in-interface-list=WAN
add action=drop chain=prerouting comment="defconf: drop forward to local lan from WAN" in-interface-list=WAN dst-address=192.168.88.0/24
add action=drop chain=prerouting comment="defconf: drop local if not from default IP range" in-interface-list=LAN src-address=!192.168.88.0/24
add action=drop chain=prerouting comment="defconf: drop bad UDP" port=0 protocol=udp
add action=jump chain=prerouting comment="defconf: jump to ICMP chain" jump-target=icmp4 protocol=icmp
add action=jump chain=prerouting comment="defconf: jump to TCP chain" jump-target=bad_tcp protocol=tcp
add action=accept chain=prerouting comment="defconf: accept everything else from LAN" in-interface-list=LAN
add action=accept chain=prerouting comment="defconf: accept everything else from WAN" in-interface-list=WAN
add action=drop chain=prerouting comment="defconf: drop the rest"

It's about interface list membership. Both LAN and WAN list membership has to be (manually) maintained ... and as long as certain interface is not made member of either of interface lists, traffic ingressing via that interface gets dropped (second and third rule from the end don't get triggered, so the last one acts) unless one of previous (more specific) rules accept it.

And my personal opinion: these rules are not needed. Default firewall filter rules adequately deal with most problems and hence these rules in raw only add to processing efforts. Keep in mind that these rules get evaluated for all allowed traffic even if there's "accept established,related" rule in filter list (which then skips evaluation of the rest of filter rules). Rules in raw are only good when your router is getting hit by lots of malicious traffic and rules in raw can drop that traffic before packets enter connection tracking machinery (which has to determine for each packet to which of existing connections it belongs ... which is a pretty costly operation).

It's about interface list membership. Both LAN and WAN list membership has to be (manually) maintained ... and as long as certain interface is not made member of either of interface lists, traffic ingressing via that interface gets dropped (second and third rule from the end don't get triggered, so the last one acts) unless one of previous (more specific) rules accept it.

And my personal opinion: these rules are not needed. Default firewall filter rules adequately deal with most problems and hence these rules in raw only add to processing efforts. Keep in mind that these rules get evaluated for all allowed traffic even if there's "accept established,related" rule in filter list (which then skips evaluation of the rest of filter rules). Rules in raw are only good when your router is getting hit by lots of malicious traffic and rules in raw can drop that traffic before packets enter connection tracking machinery (which has to determine for each packet to which of existing connections it belongs ... which is a pretty costly operation).

Thank you for your quick response. I was just wondering why one would accept all traffic from a WAN and LAN interface-list. For LAN-list, I would expect one to put on the LAN network range and what would warrant someone to use a WAN list. It just doesn't sit well with me. Thanks for the explanation. I'm not implementing this, it just caught my eyes and thought I should ask the expertise in the house. Thanks again

So, if I get this right, the three rules are a way to write something logically *like* (pseudo-pseudo code):
IF (NOT LAN AND NOT WAN) THEN DROP
or "accept only from LAN and WAN"
Correct?
Good to know.

Its all logic........... Some like it in pretzel format, I dont.
The easiest logic is at the end of both chains

add action=drop chain=forward comment="drop all else"
add action=drop chain=forward comment="drop all else"

What needs to be allowed is above these rules (keeping some of the needed default rules of course).

Here I have any question. Below is the default configuration. As you can see, it started with "connection established, related....". I know anav and others have said in the past that golden rules is to start will default

1. add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
2. add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"
3. ++++++++++++++++++++++++++++add you accept rules
4. drop every thing else.

does it make sense to put explicit drop rules first before the "established connection" and so on. Just thinking out loud and experimenting. For example: I have seen many videos where rules got moved to the top of the chain. Am I confusing myself?

drop brute force ssh
drop traffic to specific ports
drop........
drop........
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)"
drop everything else

In my opinion if you unambiguously want something dropped then put that before any of the permit rules. That means that no unintended effect of the permit rules, or future change, can ever permit that traffic. It's already been dropped before permissions are even considered.

For example if you always want to drop Netbios then put that first. If you want to drop netbios unless it's part of an established connection, the the drop goes after "permit established" rule.

Much cleaner than conditional permissions, or exceptions within the permit rules.

I would say that your wasting your time overthinking it.
The place to drop traffic if its a valid concern, is in RAW and then there is no additional load on the router.
The other suggestions prior to the default rules is pure hogwash.

does it make sense to put explicit drop rules first before the "established connection" and so on.

In principle: if you follow the "allow permitted, drop everything else" principle, then there's no need to place any of "drop" rules above the allow rules. In most cases there's no need for any additional drop rules. Unless there's an "accept" rule for packets with certain (quite wide) characteristics and then there's a subset of those to be dropped ... in this case the very specific drop rule has to be above the (slightly) less specific accept rule.

But there a few gotchas:

1. always keep in mid that rules are evaluated from top to bottom and first one matching executes
2. keep in mind that connection tracking machinery assigns a connection-state status to packets (unless raw rule marks packets with no-track) ... similarly NAT machinery assigns connection-nat-state status to packets which are eligible for NAT-ing
3. keep in mind that evaluation of every rule costs CPU cycles

So when considering the correct place for certain rule, always think about a packet, which should trigger that rule, and (mentally) evaluate every rule from top towards bottom. If any of rules match the packet and the action is not desirable (e.g. you'd want packet to be dropped, but there's some rule which allows it), you should place the rule above the "infringing" rule.

Also when considering the correct place for certain rule, consider the volume of packets that will trigger its action. Rules, triggered by more packets, should be higher on the list.
This is the reason for "accept established,related,untracked" rule to be on top (or very close) of rules, in normal operating conditions it'll take care of around 99% of packets. Next rule is "drop invalid". So the only packets still remaining to be taken care of are "new".

Isnt that what I just said..........."hogwash ;-P ( nice explanation though)