Community discussions

MikroTik App
 
Spartacus
Member Candidate
Member Candidate
Topic Author
Posts: 132
Joined: Thu Apr 19, 2018 6:38 pm

Firewall Rule Concept

Tue May 29, 2018 5:19 pm

Hi,
I would like to build up a firewall rule-set which is flexible enough for future implementations and changes on a RB3011 (e.g. VPN, Port Forwarding, etc.)
I have learned that it is smart to use "address-lists" and "customized chains" for specific exceptions (e.g. protocol related, deny DNS Requests from WAN, or ssh) I also red the manual https://wiki.mikrotik.com/wiki/Manual: ... all/Filter but I am a little bit confused about the correct order of the rules. I learned that the order runs from "permissive" to more and more "restrictive" rules with a "drop" at the end.

But what I do nor understand is, if this can be managed in "blocks" for "input", "Forward", "Output" and "Custom"- Chains, or if the rule-order has to be managed by restrictions..
If it can be managed in "Chain-Blocks" how is the best way to implement?
e.g.
  • Input - rules
  • Forward-rules
  • Output rules
  • Custom-rules
Christian
 
anav
Forum Guru
Forum Guru
Posts: 4596
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Firewall Rule Concept

Tue May 29, 2018 5:34 pm

Typically one has input rules, then forward rules, and there is no such thing as custom rules.
They all fit into Input or Forward (output is used rarely or so it seems).
The use of JUMP and Mangle areimportant skill set to have if doing more complex setups, which I have not acquired.
Similarly the use of VLANs can be intimidating.........
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
User avatar
AlainCasault
Trainer
Trainer
Posts: 631
Joined: Fri Apr 30, 2010 3:25 pm
Location: Laval, QC, Canada
Contact:

Re: Firewall Rule Concept

Tue May 29, 2018 5:56 pm

The use of custom chains (not rules as mentioned) is VERY useful to separate traffic by function (ex. Web server farm, input traffic, VoIP, etc.). It makes management visually easier and helps with cpu and memory offloading by sending traffic to the right custom chain to be processed right away and not having to go through many rules for no reason. The use of a flat structure is not suggested unless you have a very simple firewall.

Order will depend on your traffic. Put rules that are "hit" often early on in the blocks. Also put basic management traffic early also (echo replies, DNS replies and so on).

A firewall structure should not be viewed as static, meaning that order may change as traffic changes.

Personally, I like to process extrrnal input traffic rapidly to drop attacks asap and to permit management traffic just as fast.

Also, when using the JUMP action, be as specific as possible (or as needed) with your matchers and don't repeat those matchers once in your custom chain as they are implied. You may want to add different matchers depending on your goals though.

Best regards,


Sent from Tapatalk

___________________________
Alain Casault, Eng.
If I helped you, let me know!
 
Sob
Forum Guru
Forum Guru
Posts: 5590
Joined: Mon Apr 20, 2009 9:11 pm

Re: Firewall Rule Concept

Tue May 29, 2018 6:24 pm

And one quick jump back to something more basic, input, forward and output have different purpose, each packet will go only in one of the three:

- input = packet coming to router itself, i.e. destination address is one of router's own ones
- forward = packet going through router
- output = packet sent by router, i.e. by process running on router, so not when it's going from one interface to another (that's forward)

So whether you have input before forward, other way around, or even if you mix rules from these different chains, it doesn't matter, do whatever you like best.

What does matter is order of rules within the same chain, because those are processed from first to last.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
Spartacus
Member Candidate
Member Candidate
Topic Author
Posts: 132
Joined: Thu Apr 19, 2018 6:38 pm

Re: Firewall Rule Concept

Tue May 29, 2018 7:05 pm

Hello,
many thanks for the reply. But there is a question left.
If I use the "jump" in a rule how is it processed. Is it like a subroutine and returns the process back to the point, where the "jump" was initiated

e.g.
1. add chain=input dst-address=195.x.x.x protocol=tcp dst-port=443 in-interface=ether1 action=accept
2. add chain=input dst-address=195.x.x.x protocol=tcp dst-port=22 in-interface=ether1 action=jump jump-target=ssh-in
3. add chain=input action=drop
...
4. add chain=ssh-in src-address-list=ssh-clients action=accept
5. add chain=ssh-in src-address-list=shadowserver-scan action=drop
6. add chain=ssh-in action=add-src-to-address-list address-list=ssh-attacks address-list-timeout=none-static
7. add chain=ssh-in action=drop
The "jump" is initiated in line2, line 4 - line 7 will be processed, but what happens then, will the process automatically jump back to line 3?)

Regards,
Christian
 
Sob
Forum Guru
Forum Guru
Posts: 5590
Joined: Mon Apr 20, 2009 9:11 pm

Re: Firewall Rule Concept

Tue May 29, 2018 7:13 pm

If there's matching rule in ssh-in, processing ends there. In your case, #7 will match anything, so it will never return to original chain. If you didn't have #7 and nothing matched in ssh-in, it would return back to input and would be dropped by #3.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
squeeze
Member Candidate
Member Candidate
Posts: 146
Joined: Thu Mar 22, 2018 7:53 pm

Re: Firewall Rule Concept

Tue May 29, 2018 8:38 pm

If there's matching rule in ssh-in, processing ends there. In your case, #7 will match anything, so it will never return to original chain. If you didn't have #7 and nothing matched in ssh-in, it would return back to input and would be dropped by #3.

Are you sure about that? In the wiki it says:
When processing a chain, rules are taken from the chain in the order they are listed there from top to bottom. If a packet matches the criteria of the rule, then the specified action is performed on it, and no more rules are processed in that chain (the exception is the passthrough action). If a packet has not matched any rule within the built-in chain, then it is accepted.
 
Sob
Forum Guru
Forum Guru
Posts: 5590
Joined: Mon Apr 20, 2009 9:11 pm

Re: Firewall Rule Concept

Tue May 29, 2018 9:53 pm

Yes, input is built-in chain (with implicit accept at the end), but ssh-in isn't, so if nothing matches there, it returns back to original chain and continues after the jump.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply. Not intended as incentive for masochists.
 
anav
Forum Guru
Forum Guru
Posts: 4596
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: Firewall Rule Concept

Tue May 29, 2018 10:02 pm

So if I can be permitted to Squeeze Sob ;-P,

Then you are both saying the same thing. If no rules are matched in the SSH chain it is accepted, to the next rule after the initial JUMP rule in firewall filter list.
In other words, the packet was not needed after all, in the jump chain, and should go back and be processed like the rest of the packets in the normal list.

The firewall rules are implicitly accept and thus why I like the drop everything at the end of input and forward.
I'd rather manage rats than software. Follow my advice at your own risk! (Sob & mkx forced me to write that!)
 
Spartacus
Member Candidate
Member Candidate
Topic Author
Posts: 132
Joined: Thu Apr 19, 2018 6:38 pm

Re: Firewall Rule Concept

Tue May 29, 2018 10:43 pm

Hi all,
thank you so much for support.
Let me summarize in oder to check, if I understood correctly:
  • the order of input-, forward-, output- and "jump-in"-chain doesn't matter, because a package can only pass one of the chains.
  • if there's matching rule within a chain, processing ends there and the rest of the chain will be ignored for the specific package
  • if nothing is matching in the "jump-in"-chain, rule-processing will be continued after the initial jump-command in the specific chain.
  • for completeness, there should be a "drop everything" at the end of each chain
Please correct me, if I am wrong,
Regards,
Christian
 
squeeze
Member Candidate
Member Candidate
Posts: 146
Joined: Thu Mar 22, 2018 7:53 pm

Re: Firewall Rule Concept

Wed May 30, 2018 12:02 am

So if I can be permitted to Squeeze Sob ;-P,

Then you are both saying the same thing. If no rules are matched in the SSH chain it is accepted, to the next rule after the initial JUMP rule in firewall filter list.
In other words, the packet was not needed after all, in the jump chain, and should go back and be processed like the rest of the packets in the normal list.

The firewall rules are implicitly accept and thus why I like the drop everything at the end of input and forward.

No, Sob is correct. "Accept" means something very specific. It means that a packet continues into the next stage of packet processing, outside of Filter stage and its chains.

I misread that Wiki sentence because I was not careful enough to note it specifically refers to "built-in" chain.

I may still retain an explicit Return in custom chains in my configurations where it makes sense to use it, but clearly it is not required at the end of a custom chain block ever.

Who is online

Users browsing this forum: deanz and 33 guests