Page 1 of 1

Firewall rules disputable question

Posted: Wed Mar 04, 2015 9:37 pm
by koshak83
Hi! =)
The question may seem disputable but still I ask him.

How all the same right must start chain firewall rules:
1- drop invalid->allow established->allow related
2- allow established->allow related->drop invalid?

Met a lot of variations of firewall rule sets, sometimes the same but with a different order of these rules.
Ask for advice. Since the basic firewall router default the second option, but for example here in the first option.

Re: Firewall rules disputable question

Posted: Wed Mar 04, 2015 10:13 pm
by DLNoah
In this specific case, the order doesn't really matter, because all three rules match different packets (no packet will match more than one).

If your drop rule could potentially match packets that should be accepted (allowed), it must come last -- once packet is accepted (allowed) or dropped, no further firewall rules are checked. So, if your rules were something like:

1) Drop new
2) Accept new from specific "known good" IPs
3) Accept established
4) Accept related

The only packets that would be getting accepted are those that match "established" or "related" (rules 3 & 4). All packets that would potentially match rule #2 would be dropped by rule #1 before they ever had a chance to check rule 2. In this case, you would need to change the order so that rule #1 occurs after rule #2 (though the positioning of rule #3 and #4 still will not matter).

Also, it's important to know that there's an implicit "accept all" at the last position of your firewall chains -- MikroTik will accept any packet that is not otherwise handled by your firewall rules

Re: Firewall rules disputable question

Posted: Wed Mar 04, 2015 11:37 pm
by andriys
From the performance point of view, established and related must always be the very first rules in a chain. And this approach should not make your rules less secure, since established or related state means the packet has already passed some internal validation and was considered a legitimate part of an already authenticated connection.

Following the established/related rules I usually do the following:
1. Drop packets with weird combinations of TCP flags.
2. Allow what should be allowed.
3. Drop everything else.

I said "usually", because there are exceptions to any rule, and YMMV.

Re: Firewall rules disputable question

Posted: Thu Mar 05, 2015 9:03 pm
by koshak83
Thank you all for your answers!
As I understand it, in general, it all depends on what policies firewall work is selected.
In principle, the chains input and output, is essentially responsible for the protection of the router, should be adhered the policy type rules- allow only what should be expressly permitted, and deny everything else. Essentially allow only that provides a minimum for the correct operation of the router, and limited access to its management of a trusted environment. And in politics rules the chain forward responsible for the protection of the customer, contrary- clearly deny unwanted and add more as needed, and allow all rest. Thus, to protect the customer the possibility of unwanted, but not to limit or interfere with its operation in a broad sense.
In fact, obtained scales with bowls, where: all that concerns the router (input/output)- reasonably maximally protected, and what the customer (forward)- has to spit seek a "middle ground" between security and convenience (or usability if you like).
Do I understand correctly?

Re: Firewall rules disputable question

Posted: Thu Mar 05, 2015 9:53 pm
by ZeroByte
Do I understand correctly?
It sounds like you do understand correctly.

I would like to point to one thing I sometimes put before the allow established / related rules:
input / forward: drop src-list = BANLIST
output / forward: drop dst-list = BANLIST

The address list is a data structure that operates very fast even with huge number of entries, so it's not a lot of performance impact to check this even before related/established. If you see a security incident taking place, you can add the offending IP address to BANLIST (or IP network e.g. and packets will immediately get dropped, even from established sessions. It is also nice because putting the address in the list one time affects all rules and chains that look at it, and it can be used to match on the source or the destination as needed.