This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
meshdesk:nft-adv-block [2023/05/10 22:52] admin [Design Philosophy] |
meshdesk:nft-adv-block [2023/05/11 07:17] (current) admin [Using Available Meta Data] |
||
|---|---|---|---|
| Line 24: | Line 24: | ||
| * One or more Rules | * One or more Rules | ||
| * A Rule in turn can contain one or more Apps (If the Rule's category is selected as **App**) | * A Rule in turn can contain one or more Apps (If the Rule's category is selected as **App**) | ||
| + | * Lets create a simple Firewall Profile that will block YouTube between 7AM and 5PM during weekdays. | ||
| + | |||
| + | ==== Blocking YouTube During Week Days ==== | ||
| + | * Click on the Add Toolbar Button to create a new Firewall Profile | ||
| + | {{: | ||
| + | * We selected to make it system wide (Indicated by the Umbrella Icon in the Name banner.) | ||
| + | {{: | ||
| + | * Next we can start to add Rules. | ||
| + | * If a rule's Category is App you should select one or more predefined Firewall Apps to be part of the rule. | ||
| + | * An App has to be defined and contains a list of IP Addresses. (For the technical minded, these will be bundled into a **set** to be used by **nftables**. | ||
| + | |||
| + | ==== Creating The YouTube Firewall App ==== | ||
| + | * To manage Firewall Apps, click on the toolbar button with the wrench (Tool-tip Firewall Apps) | ||
| + | * This will open a new tab with a list of Firewall Apps. | ||
| + | {{: | ||
| + | * Two items that need more explanation. | ||
| + | * **FA Code**. | ||
| + | * Although it is cosmetic, it is also functional to identify Apps that's part of a rule. | ||
| + | * You can consult this URL for available Icons: https:// | ||
| + | * **Elements**. These are IP addresses or ranges which will be used by nftables as part of their sets. | ||
| + | * You can consult this URL to read up more on Sets and Elements inside Sets: https:// | ||
| + | * Now we can return to our Firewall Profile to complete the new rule. | ||
| + | |||
| + | ==== Rule for YouTube ==== | ||
| + | * The Add and Edit Rule form is very easy to use and also to make changes to existing rules. | ||
| + | {{: | ||
| + | * You can combine as many rules as you like in one Firewall Profile. | ||
| + | * Here we keep it simple by just blocking YouTube. | ||
| + | |||
| + | ==== Using The Firewall Profile ==== | ||
| + | |||
| + | * Next we can associate it with an Exit Point on a MESH network or an AP Profile. | ||
| + | {{: | ||
| + | * Alternatively you can associate it with a client' | ||
| + | {{: | ||
| + | |||
| + | ===== Technical Details ===== | ||
| + | |||
| + | * If you are an old hand with Linux you are probably very familiar with **iptables**. | ||
| + | * In the old days firewalls were done using **iptables** and in case you needed to do packet management on layer two you would use **ebtables**. | ||
| + | * Fast forward to today and we have the much more advanced and user friendly **nftables**. | ||
| + | * nftables allows you to do packet management on layer three and layer two. | ||
| + | * OpenWrt version 22.03 migrated to use nftables instead of iptables. | ||
| + | * This means that the feature will require OpenWrt version 22.03 or higher based firmware to work correct. | ||
| + | * We took the opportunity to take advantage of this improvement and are using this with the Firewall Profile. | ||
| + | ==== Using Available Meta Data ==== | ||
| + | * With nftables one can create filters based on //meta data//. | ||
| + | * Meta data is data that is available but which are **not part of the traffic** flowing between two hosts on the Internet. | ||
| + | * This includes detail about the hardware (e.g. the interface through which the traffic flows) | ||
| + | * It also includes detail about the time when the traffic is flowing. | ||
| + | * With these meta data filters that is available we formulated the options that you can select when adding a rule to a Firewall Profile. | ||
| + | * One aspect which makes our implementation unique is the fact that we work on layer two and not layer three. | ||
| + | * The reason for this is that MESHdesk and APdesk allows you to create bridged networks where the IP Address management (DHCP) can be done by another device on the network. | ||
| + | * By working on layer two it allows us to formulate rules without the requirement to know the IP Address of a device or Exit Point to which the Firewall Profile is associated with. | ||
| + | * You will need the compulsory **kmod-nft-bridge** nftable module. | ||
| + | * Make sure it is included with the OpenWrt based firmware. | ||
| + | * The **adv_meshdesk** bridge table is where things are happening. | ||
| + | * You can inspect the table using the following command **nft -e -a list table bridge adv_meshdesk**. | ||
| + | <code javascript> | ||
| + | nft -e -a list table bridge adv_meshdesk | ||
| + | table bridge adv_meshdesk { # handle 2 | ||
| + | set YouTube { # handle 4 | ||
| + | type ipv4_addr | ||
| + | flags interval | ||
| + | elements = { 172.217.0.0/ | ||
| + | } | ||
| + | |||
| + | set md_lan { # handle 5 | ||
| + | type ipv4_addr | ||
| + | flags interval | ||
| + | elements = { 10.0.0.0/8, 172.16.0.0/ | ||
| + | | ||
| + | } | ||
| + | |||
| + | set md_internet_not { # handle 6 | ||
| + | type ipv4_addr | ||
| + | flags interval | ||
| + | elements = { 10.0.0.0/8, 172.16.0.0/ | ||
| + | | ||
| + | } | ||
| + | |||
| + | chain forward { # handle 1 | ||
| + | type filter hook forward priority 0; policy accept; | ||
| + | meta day { " | ||
| + | } | ||
| + | |||
| + | chain input { # handle 2 | ||
| + | type filter hook input priority 0; policy accept; | ||
| + | meta day { " | ||
| + | } | ||
| + | |||
| + | chain output { # handle 3 | ||
| + | type filter hook output priority 0; policy accept; | ||
| + | } | ||
| + | } | ||
| + | </ | ||
| + | * Here you can see the rules which were generated for the Youtube Block Firewall Profile which we defined and applied on a NAT/DHCP and also a bridged exit point. | ||
| + | * The forward chain rule is for the bridged exit point. | ||
| + | * The input chain rule is for the NAT/DHCP exit point. | ||
| + | * As you can see our time of day and also the days to apply is in the meta day and meta hour parts respectively. | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||
| + | |||