Community discussions

MikroTik App
 
stefnab
just joined
Topic Author
Posts: 17
Joined: Mon Jan 07, 2019 9:53 am

firewall filter

Mon Jan 07, 2019 10:22 pm

Hello all,

what should be proper order of these rules and why ?
add chain=forward comment="Accept established and related packets" connection-state=established,related
add action=drop chain=forward comment="Drop new connections from internet which are not dst-natted" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="Drop invalid packets" connection-state=invalid
Why accept established&related connections should be 1st ?

If i do not choose any interface will following rule apply to every source interface?
add action=drop chain=input comment="DROP ALL IN INPUT CHAIN"
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: firewall filter

Mon Jan 07, 2019 11:05 pm

My limited experience has been that its best to process the bulk of traffic first, in other words, don't have the bulk of traffic checked against all the rules as this eats up CPU cycles.
If you can apply the bulk of traffic to the first rules, the better.
Since most traffic is established and related it makes sense for this to be at the top.
I follow this by the invalid drop rule........

As for this rule......... I dont need it or use it.
add action=drop chain=forward comment="Drop new connections from internet which are not dst-natted" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

What I do have is a forward rule that permits DST NAT Rules I have under /IP Firewall NAT to be functional.
add action=accept chain=forward comment="Allow Port Forwarding" connection-nat-state=dstnat

As for the last question. At the end of my Input Chain and Forward Chain I have drop all else rules.
In other words If I don't explicitly state something is allowed everything else is dropped.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11381
Joined: Thu Mar 03, 2016 10:23 pm

Re: firewall filter

Mon Jan 07, 2019 11:10 pm

what should be proper order of these rules and why ?

The rule order as written is fine. Reason is that rules are checked from top to bottom until some rule applies for all packets. So more speciffic rules should be higher than general ones. And rules that will be hit by more packets should be higher.

Most of times majority of packets will be the wanted packets of already established connections being forwarded vy router (i.e. connections initiated by LAN hosts towards internet), so you want this rule near the top. Middle rule might have medium hit rate ... depends on how much will intruders try to break your firewall. Most of tries will be otherwise regular connection attempts but to services you don't provide. The last one will be robably executed the least often, but should be dropped anyway.

If i do not choose any interface will following rule apply to every source interface?
add action=drop chain=input comment="DROP ALL IN INPUT CHAIN"
Yes.
 
stefnab
just joined
Topic Author
Posts: 17
Joined: Mon Jan 07, 2019 9:53 am

Re: firewall filter

Mon Jan 07, 2019 11:51 pm

Thank you guys for sharing your knowledge.
established connections being forwarded vy router (i.e. connections initiated by LAN hosts towards internet),
This sentence actually explains a lot what actually "accept related&established means" , thx man :D

At the end could you tell,if my understanding is good (it's not super technical):

All ports for routers clients are closed from outside, except the ones they open by themselves (running apps,browsers et cetra) or ports on forward chain, which router NAT'S directly to them from outside. Does my thinking make sense ? It seems like router actually conceals users from outside (what is actually very safe for computers, because users are directly intargetable)
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: firewall filter

Tue Jan 08, 2019 12:18 am

Nat is not designed as a security protocol at least to my knowledge however a byproduct of NAT, translating private to public IPs and back is that layer in between of what you speak.
The firewall filter rules allow us to ensure everything is closed down except what we want to allow. Yes anything going out is normally allowed out and the return traffic as well.
However some business shut down and only allow specific services to the WAN.
In my location I allow LAN to WAN traffic, but if I wanted to only allow specific ports for example, I would state allow LAN to WAN for those ports only and the rest would be dropped by a last drop all forward rule.
I am currently prescribing to a service that has layer 7 rules that are inspecting outgoing traffic which is a layer of knowledge beyond mine.

Back to port forwarding.......
Normally with other devices, I would have separate rules for NAT and Firewall security but on the mikrotik they are combined on the NAT rule (allow source or source list for example)

The other great vulnerability is access to the router itself, and for me the basic rule is that if there is no good reason for external access ensure you shut that down and even internally limit the access and use a strong password (heck change the ssh port number and winbox port number). The only pain in the ass is remembering so if its discoverable via MAC or you know the ip.
IP:port# has to be added.
 
stefnab
just joined
Topic Author
Posts: 17
Joined: Mon Jan 07, 2019 9:53 am

Re: firewall filter

Tue Jan 08, 2019 2:14 am

Please notice that you cant Connect with specific client in the lan network( forward chain) from outside unless router allows you (NAT forwarding). From The other hand clients are still able to establish (for example) connections with websites using port 80 and 8080 ( and data exchange is in 2 directions - website is sending the data to lan user). How is this possble if I block all not dstnated ?

That's what I actually understand by established&related. The connections made by users by themselves ( that explains why not blocked, ofc i can block mentioned ports, but usually all ports are open from "users site") If i am wrong tell me :D
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11381
Joined: Thu Mar 03, 2016 10:23 pm

Re: firewall filter

Tue Jan 08, 2019 9:05 am

Normally with other devices, I would have separate rules for NAT and Firewall security but on the mikrotik they are combined on the NAT rule (allow source or source list for example)

I guess that with ROS it could be done the same ... i.e. in /ip firewall nat just tell the router to NAT ports and in /ip firewall filter limit access to the NATed ports. However, the strength given by possibility to define access rules in NAT section is that you can actually NAT the very same port on WAN IP address to different internal hosts depending on remote address (or some other criteria):
/ip firewall nat
add action=dst-nat chain=dstnat comment="HTTP from trusted source goes to server 1" dst-port=80 in-interface-list=WAN src-address-list=WAN_trusted protocol=tcp to-addresses=<IP of server 1>
add action=dst-nat chain=dstnat comment="HTTP from rest of internet goes to server 2" dst-port=80 in-interface-list=WAN protocol=tcp to-addresses=<IP of server 2>
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: firewall filter

Tue Jan 08, 2019 6:36 pm

Nice approach MKX!!!
The only thing I would add is that the DST Nat rules can also provide the firewall protection normally done in separate rules but also allow port translation.
So people could come in on port 9999 and be translated to the server port 80 in the case of non-trusted.............. for example.....

/ip firewall nat
add action=dst-nat chain=dstnat comment="HTTP from trusted source goes to server 1" dst-port=80 in-interface-list=WAN src-address-list=WAN_trusted protocol=tcp to-addresses=<IP of server 1>
add action=dst-nat chain=dstnat comment="HTTP from rest of internet goes to server 2" dst-port=9999 in-interface-list=WAN protocol=tcp to-addresses=<IP of server 2> to-ports=80

Where this comes into play is that normally one gives an URL for access to servers such as my.homeserver.org and the only difference is now they would have to identify in the app or URL box, my.homeserver.org:9999 (or if by IP address 24.224.67.2:9999)

Who is online

Users browsing this forum: No registered users and 38 guests