Hello everyone,
I have been practicing and experimenting with some firewall rules lately and I come across some of these rules that baffles me. This firewall rules were copied from Mikrotik website. for example, when the RAW rules below is applied, something strange happens. In this testing, I have only one computer connected to the router. The router has 192.168.88.1 and the PC connected to it has an IP: 192.168.88.2. I noticed that only the JUMP "jump-target=bad_tcp" [shown in BOLD] counter continues increasing at a high rate but the actual rule "bad_tcp" [in GREEN] did not increase. I have attached the logs and RAW pic to this post.
My question is: Why is the JUMP counter increasing instead of the actual rules that the traffic was suppose to match against? I thought the JUMP is just instructing the firewall process to JUMP into the "bad_tcp" chain, then match the packet against the "bad_tcp" rules, then return. I'm confused.
/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"
/ip firewall raw
add action=drop chain=bad_tcp comment="defconf: TCP flag filter" protocol=tcp tcp-flags=!fin,!syn,!rst,!ack
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=fin,syn
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=fin,rst
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=fin,!ack
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=fin,urg
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=syn,rst
add action=drop chain=bad_tcp comment=defconf protocol=tcp tcp-flags=rst,urg
add action=drop chain=bad_tcp comment="defconf: TCP port 0 drop" port=0 protocol=tcp
Firewall "JUMP" rules
You do not have the required permissions to view the files attached to this post.
Re: Firewall "JUMP" rules
One of uses for custom chains is to reduce number of rules which packets have to be matched against.
In your particular case: the chain=prerouting protocol=tcp matches all TCP packets and executes chain=bad_tcp. Rules in chain=bad_tcp then don't have to match against protocol type (because only TCP packets will enter that chain) which saves a CPU cycle or two ... and only check against other properties (in particular: invalid mix of TCP flags). Vast majority of TCP packets will not match against any of those rules, hence none of rules will get executed (and counters remain zero or low).
You could move all the rules from chain=bad_tcp to main chain=prerouting, you'd just have to add the "basic" matcher (protocol=tcp) to all of those rules. However, if firewall is working on an UDP packet, it would have to be matched against all of rules ... with your current setup, UDP packets only get matched against a single rule (the highlited one).
Don't get alarmed by "connection state: invalid" ... you're looking at logs from raw firewall rules, which get executed before connection state machinery has opportunity to classify packets into connection table ... hence their state is actually unknown but wrongly reported as invalid.
In your particular case: the chain=prerouting protocol=tcp matches all TCP packets and executes chain=bad_tcp. Rules in chain=bad_tcp then don't have to match against protocol type (because only TCP packets will enter that chain) which saves a CPU cycle or two ... and only check against other properties (in particular: invalid mix of TCP flags). Vast majority of TCP packets will not match against any of those rules, hence none of rules will get executed (and counters remain zero or low).
You could move all the rules from chain=bad_tcp to main chain=prerouting, you'd just have to add the "basic" matcher (protocol=tcp) to all of those rules. However, if firewall is working on an UDP packet, it would have to be matched against all of rules ... with your current setup, UDP packets only get matched against a single rule (the highlited one).
Don't get alarmed by "connection state: invalid" ... you're looking at logs from raw firewall rules, which get executed before connection state machinery has opportunity to classify packets into connection table ... hence their state is actually unknown but wrongly reported as invalid.
Re: Firewall "JUMP" rules
One of uses for custom chains is to reduce number of rules which packets have to be matched against.
In your particular case: the chain=prerouting protocol=tcp matches all TCP packets and executes chain=bad_tcp. Rules in chain=bad_tcp then don't have to match against protocol type (because only TCP packets will enter that chain) which saves a CPU cycle or two ... and only check against other properties (in particular: invalid mix of TCP flags). Vast majority of TCP packets will not match against any of those rules, hence none of rules will get executed (and counters remain zero or low).
You could move all the rules from chain=bad_tcp to main chain=prerouting, you'd just have to add the "basic" matcher (protocol=tcp) to all of those rules. However, if firewall is working on an UDP packet, it would have to be matched against all of rules ... with your current setup, UDP packets only get matched against a single rule (the highlited one).
Right on spot. Thanks for this explanation. I also thought of moving the chain=bad_tcp to main chain=prerouting, which I eventually tested and the counter stayed zero as expected. Since packets get processed in RAW before it hits the INPUT or FORWARD chain, is it advisable to use RAW mainly for dropping traffics before it CLOGS the INPUT or FORWARD chain?
Why would anyone use a RAW to accept traffic instead of using INPUT or FORWARD? If I use RAW to accept connection, it won't be tracked in the connection tracking table. so under what circumstances does this make sense?
In my previous case where the JUMPER counter kept increasing, won't this continuous increase have impact on the router, assuming I have 100 clients connected, that means all packets from these clients will be evaluated on the JUMP chain.
Re: Firewall "JUMP" rules
IMO most of rules you posted are pretty useless ... because connection tracking machinery will assign connection state "invalid" to those. So the default rule "drop invalid" will adequately get rid of them.
Adding rules in raw means that some packets will get dropped before they hit connection tracking machinery ... and this machinery is the most CPU-expensive part of packet processing. However, rules in raw are not without any cost either and (depending on particular configuration) many if not all raw rules will get evaluated for most (if not all) passing packets, accumulating considerable CPU load.
IMO the only benefit of using raw rules is when your network is under some (D)DoS attack and raw rules can (quite easily) drop packets, associated to attack ... but appropriate rule(s) can only be set up after the attack is analysed.
Keep in mind also that fikter rules and raw rules are not evaluated "raw or filter", they are both evaluated ... jzst raw rules are evaluated earlier. So if raw rules explicitly accept a packet, then filter rules will still be evaluated (at each firewall chain, prerouting or forward, there's implicit accept rule at the end if the chain, explicit accept is no different than packet reaching the end of (visible) rule list for some chain).
Adding rules in raw means that some packets will get dropped before they hit connection tracking machinery ... and this machinery is the most CPU-expensive part of packet processing. However, rules in raw are not without any cost either and (depending on particular configuration) many if not all raw rules will get evaluated for most (if not all) passing packets, accumulating considerable CPU load.
IMO the only benefit of using raw rules is when your network is under some (D)DoS attack and raw rules can (quite easily) drop packets, associated to attack ... but appropriate rule(s) can only be set up after the attack is analysed.
Keep in mind also that fikter rules and raw rules are not evaluated "raw or filter", they are both evaluated ... jzst raw rules are evaluated earlier. So if raw rules explicitly accept a packet, then filter rules will still be evaluated (at each firewall chain, prerouting or forward, there's implicit accept rule at the end if the chain, explicit accept is no different than packet reaching the end of (visible) rule list for some chain).
Re: Firewall "JUMP" rules
Well said. Clear and well understood. I appreciate your effort in explaning this. CheersIMO most of rules you posted are pretty useless ... because connection tracking machinery will assign connection state "invalid" to those. So the default rule "drop invalid" will adequately get rid of them.
Adding rules in raw means that some packets will get dropped before they hit connection tracking machinery ... and this machinery is the most CPU-expensive part of packet processing. However, rules in raw are not without any cost either and (depending on particular configuration) many if not all raw rules will get evaluated for most (if not all) passing packets, accumulating considerable CPU load.
IMO the only benefit of using raw rules is when your network is under some (D)DoS attack and raw rules can (quite easily) drop packets, associated to attack ... but appropriate rule(s) can only be set up after the attack is analysed.
Keep in mind also that fikter rules and raw rules are not evaluated "raw or filter", they are both evaluated ... jzst raw rules are evaluated earlier. So if raw rules explicitly accept a packet, then filter rules will still be evaluated (at each firewall chain, prerouting or forward, there's implicit accept rule at the end if the chain, explicit accept is no different than packet reaching the end of (visible) rule list for some chain).
Re: Firewall "JUMP" rules
Another quick question @mkx
So does all traffic that passed through RAW also gets checked by INPUT and FORWARD chain, or
if there is a match in RAW it stops processing or
If there is a match in RAW for accept or drop, it proceed to INPUT or FORWARD chain for matching?
In other words, if a packet passes through the RAW table, will it still be inspected by the INPUT or FORWARD chain later, or wil the packet bypass the INPUT and OUTPUT chain after passing thru the RAW table? Thanks
So does all traffic that passed through RAW also gets checked by INPUT and FORWARD chain, or
if there is a match in RAW it stops processing or
If there is a match in RAW for accept or drop, it proceed to INPUT or FORWARD chain for matching?
In other words, if a packet passes through the RAW table, will it still be inspected by the INPUT or FORWARD chain later, or wil the packet bypass the INPUT and OUTPUT chain after passing thru the RAW table? Thanks
Re: Firewall "JUMP" rules
If a packet is not dropped by any raw rule (with action=drop), it will proceed and will be processed by the other tables (mangle, nat, filter). You can read all about it here:
https://help.mikrotik.com/docs/spaces/R ... n+RouterOS
Here are some relevant pictures:
Starting with the prerouting chain. If there is a raw prerouting rule that drops the packet, the packet processing stops there. In other cases, it proceeds to the next block. If action=no-track, the next block is the mangle prerouting block, otherwise it's the connection tracking block. It then continues with dst-nat rules.
Then in case of packets being forwarded https://help.mikrotik.com/docs/spaces/R ... OS-Forward, you have this diagram:
Where after a routing decision is made, the packet goes through the forward chain, where the rules from the mange and filter tables (chain forward) will also be checked. Aftert that it goes through post routing, with the mangle (chain=postrouting) and src-nat rules.
If routing decision chooses the Input chain instead of forward, you have https://help.mikrotik.com/docs/spaces/R ... erOS-Input:
And the rules from the mangle and filter tables (chain=input) will still be checked.
In general, you only need RAW rules when you absolutely want to drop packets immediately. Let's say you have a list of IP addresses currently DDoS-ing you, then you can add a drop rule in the RAW table chain=prerouting, that way those dropped packets won't go through connection tracking (consume resources) and the rest of the diagram.
If most of your traffics are benign (total number of "good" packets far outweighs "evil" packets), it's inefficient to have RAW rules when the evil packets will be dropped by filter rules anyway. Because if you have raw rules, all packets have to go through them. If you don't have raw rules, but only use normal filter drop rules instead, most of the time the filter drop rules only have to process the initial packets of a connection. The bulk of the packets only have to hit the accept or fasttrack rule with connection-state=established,related that should be conveniently placed at the top of the chains.
https://help.mikrotik.com/docs/spaces/R ... n+RouterOS
Here are some relevant pictures:
Starting with the prerouting chain. If there is a raw prerouting rule that drops the packet, the packet processing stops there. In other cases, it proceeds to the next block. If action=no-track, the next block is the mangle prerouting block, otherwise it's the connection tracking block. It then continues with dst-nat rules.
Then in case of packets being forwarded https://help.mikrotik.com/docs/spaces/R ... OS-Forward, you have this diagram:
Where after a routing decision is made, the packet goes through the forward chain, where the rules from the mange and filter tables (chain forward) will also be checked. Aftert that it goes through post routing, with the mangle (chain=postrouting) and src-nat rules.
If routing decision chooses the Input chain instead of forward, you have https://help.mikrotik.com/docs/spaces/R ... erOS-Input:
And the rules from the mangle and filter tables (chain=input) will still be checked.
In general, you only need RAW rules when you absolutely want to drop packets immediately. Let's say you have a list of IP addresses currently DDoS-ing you, then you can add a drop rule in the RAW table chain=prerouting, that way those dropped packets won't go through connection tracking (consume resources) and the rest of the diagram.
If most of your traffics are benign (total number of "good" packets far outweighs "evil" packets), it's inefficient to have RAW rules when the evil packets will be dropped by filter rules anyway. Because if you have raw rules, all packets have to go through them. If you don't have raw rules, but only use normal filter drop rules instead, most of the time the filter drop rules only have to process the initial packets of a connection. The bulk of the packets only have to hit the accept or fasttrack rule with connection-state=established,related that should be conveniently placed at the top of the chains.