From e39d7d8990dd0f107b328258ecf67e3e4a1b179e Mon Sep 17 00:00:00 2001 From: Giggum <152240782+Giggum@users.noreply.github.com> Date: Fri, 5 Jan 2024 00:29:03 -0500 Subject: [PATCH 1/3] docs: fix to improve readability and correct typos. --- docs/configuration/firewall/index.rst | 40 +++++++++++++-------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/docs/configuration/firewall/index.rst b/docs/configuration/firewall/index.rst index 3887e26a86..bdfc20693a 100644 --- a/docs/configuration/firewall/index.rst +++ b/docs/configuration/firewall/index.rst @@ -5,30 +5,30 @@ Firewall ######## With VyOS being based on top of Linux and its kernel, the Netfilter project -created the iptables and now the successor nftables for the Linux kernel to +created iptables and its successor nftables for the Linux kernel to work directly on the data flows. This now extends the concept of zone-based security to allow for manipulating the data at multiple stages once accepted by the network interface and the driver before being handed off to the -destination (e.g. a web server OR another device). +destination (e.g., a web server OR another device). -A simplified traffic flow, based on Netfilter packet flow, is shown next, in +A simplified traffic flow diagram, based on Netfilter packet flow, is shown next, in order to have a full view and understanding of how packets are processed, and -what possible paths can take. +what possible paths traffic can take. .. figure:: /_static/images/firewall-gral-packet-flow.png -Main notes regarding this packet flow and terminology used in VyOS firewall: +Main points regarding this packet flow and terminology used in VyOS firewall are below: - * **Bridge Port?**: choose appropiate path based on if interface were the + * **Bridge Port?**: choose appropriate path based on whether interface where the packet was received is part of a bridge, or not. -If interface were the packet was received isn't part of a bridge, then packet +If interface where the packet was received isn't part of a bridge, then packet is processed at the **IP Layer**: * **Prerouting**: several actions can be done in this stage, and currently - these actions are defined in different parts in vyos configuration. Order + these actions are defined in different parts in VyOS configuration. Order is important, and all these actions are performed before any actions - define under ``firewall`` section. Relevant configuration that acts in + defined under ``firewall`` section. Relevant configuration that acts in this stage are: * **Conntrack Ignore**: rules defined under ``set system conntrack ignore @@ -40,12 +40,12 @@ is processed at the **IP Layer**: * **Destination NAT**: rules defined under ``set [nat | nat66] destination...``. - * **Destination is the router?**: choose appropiate path based on - destination IP address. Transit forward continunes to **forward**, + * **Destination is the router?**: choose appropriate path based on + destination IP address. Transit forward continues to **forward**, while traffic that destination IP address is configured on the router continues to **input**. - * **Input**: stage where traffic destinated to the router itself can be + * **Input**: stage where traffic destined for the router itself can be filtered and controlled. This is where all rules for securing the router should take place. This includes ipv4 and ipv6 filtering rules, defined in: @@ -61,10 +61,10 @@ is processed at the **IP Layer**: * ``set firewall ipv6 forward filter ...``. - * **Output**: stage where traffic that is originated by the router itself - can be filtered and controlled. Bare in mind that this traffic can be a - new connection originted by a internal process running on VyOS router, - such as NTP, or can be a response to traffic received externaly through + * **Output**: stage where traffic that originates from the router itself + can be filtered and controlled. Bear in mind that this traffic can be a + new connection originated by a internal process running on VyOS router, + such as NTP, or a response to traffic received externaly through **inputt** (for example response to an ssh login attempt to the router). This includes ipv4 and ipv6 filtering rules, defined in: @@ -79,11 +79,11 @@ is processed at the **IP Layer**: * **Source NAT**: rules defined under ``set [nat | nat66] destination...``. -If interface were the packet was received is part of a bridge, then packet -is processed at the **Bridge Layer**, which contains a ver basic setup where -for bridge filtering: +If interface where the packet was received is part of a bridge, then packet +is processed at the **Bridge Layer**, which contains a basic setup for +bridge filtering: - * **Forward (Bridge)**: stage where traffic that is trasspasing through the + * **Forward (Bridge)**: stage where traffic that is trespasing through the bridge is filtered and controlled: * ``set firewall bridge forward filter ...``. From 7132481c92e169348ac3f6750be8ce45c2f2b5dd Mon Sep 17 00:00:00 2001 From: Giggum <152240782+Giggum@users.noreply.github.com> Date: Fri, 5 Jan 2024 22:40:42 -0500 Subject: [PATCH 2/3] fix to add more fixes on top of previous pull request --- docs/configuration/firewall/index.rst | 35 ++--- docs/configuration/firewall/index.rst~ | 179 +++++++++++++++++++++++++ 2 files changed, 197 insertions(+), 17 deletions(-) create mode 100644 docs/configuration/firewall/index.rst~ diff --git a/docs/configuration/firewall/index.rst b/docs/configuration/firewall/index.rst index bdfc20693a..74d5bc2086 100644 --- a/docs/configuration/firewall/index.rst +++ b/docs/configuration/firewall/index.rst @@ -4,26 +4,27 @@ Firewall ######## -With VyOS being based on top of Linux and its kernel, the Netfilter project +As VyOS is based on Linux it leverages its firewall. The Netfilter project created iptables and its successor nftables for the Linux kernel to -work directly on the data flows. This now extends the concept of zone-based -security to allow for manipulating the data at multiple stages once accepted -by the network interface and the driver before being handed off to the -destination (e.g., a web server OR another device). +work directly on packet data flows. This now extends the concept of +zone-based security to allow for manipulating the data at multiple stages once +accepted by the network interface and the driver before being handed off to +the destination (e.g., a web server OR another device). -A simplified traffic flow diagram, based on Netfilter packet flow, is shown next, in -order to have a full view and understanding of how packets are processed, and -what possible paths traffic can take. +A simplified traffic flow diagram, based on Netfilter packet flow, is shown +next, in order to have a full view and understanding of how packets are +processed, and what possible paths traffic can take. .. figure:: /_static/images/firewall-gral-packet-flow.png -Main points regarding this packet flow and terminology used in VyOS firewall are below: +The main points regarding this packet flow and terminology used in VyOS +firewall are covered below: - * **Bridge Port?**: choose appropriate path based on whether interface where the - packet was received is part of a bridge, or not. + * **Bridge Port?**: choose appropriate path based on whether interface + where the packet was received is part of a bridge, or not. -If interface where the packet was received isn't part of a bridge, then packet -is processed at the **IP Layer**: +If the interface where the packet was received isn't part of a bridge, then +packetis processed at the **IP Layer**: * **Prerouting**: several actions can be done in this stage, and currently these actions are defined in different parts in VyOS configuration. Order @@ -79,8 +80,8 @@ is processed at the **IP Layer**: * **Source NAT**: rules defined under ``set [nat | nat66] destination...``. -If interface where the packet was received is part of a bridge, then packet -is processed at the **Bridge Layer**, which contains a basic setup for +If the interface where the packet was received is part of a bridge, then +packetis processed at the **Bridge Layer**, which contains a basic setup for bridge filtering: * **Forward (Bridge)**: stage where traffic that is trespasing through the @@ -88,7 +89,7 @@ bridge filtering: * ``set firewall bridge forward filter ...``. -Main structure VyOS firewall cli is shown next: +The main structure VyOS firewall cli is shown next: .. code-block:: none @@ -134,7 +135,7 @@ Main structure VyOS firewall cli is shown next: - custom_zone_name + ... -Please, refer to appropiate section for more information about firewall +Please, refer to appropriate section for more information about firewall configuration: .. toctree:: diff --git a/docs/configuration/firewall/index.rst~ b/docs/configuration/firewall/index.rst~ new file mode 100644 index 0000000000..bdfc20693a --- /dev/null +++ b/docs/configuration/firewall/index.rst~ @@ -0,0 +1,179 @@ +:lastproofread: 2023-11-23 + +######## +Firewall +######## + +With VyOS being based on top of Linux and its kernel, the Netfilter project +created iptables and its successor nftables for the Linux kernel to +work directly on the data flows. This now extends the concept of zone-based +security to allow for manipulating the data at multiple stages once accepted +by the network interface and the driver before being handed off to the +destination (e.g., a web server OR another device). + +A simplified traffic flow diagram, based on Netfilter packet flow, is shown next, in +order to have a full view and understanding of how packets are processed, and +what possible paths traffic can take. + +.. figure:: /_static/images/firewall-gral-packet-flow.png + +Main points regarding this packet flow and terminology used in VyOS firewall are below: + + * **Bridge Port?**: choose appropriate path based on whether interface where the + packet was received is part of a bridge, or not. + +If interface where the packet was received isn't part of a bridge, then packet +is processed at the **IP Layer**: + + * **Prerouting**: several actions can be done in this stage, and currently + these actions are defined in different parts in VyOS configuration. Order + is important, and all these actions are performed before any actions + defined under ``firewall`` section. Relevant configuration that acts in + this stage are: + + * **Conntrack Ignore**: rules defined under ``set system conntrack ignore + [ipv4 | ipv6] ...``. + + * **Policy Route**: rules defined under ``set policy [route | route6] + ...``. + + * **Destination NAT**: rules defined under ``set [nat | nat66] + destination...``. + + * **Destination is the router?**: choose appropriate path based on + destination IP address. Transit forward continues to **forward**, + while traffic that destination IP address is configured on the router + continues to **input**. + + * **Input**: stage where traffic destined for the router itself can be + filtered and controlled. This is where all rules for securing the router + should take place. This includes ipv4 and ipv6 filtering rules, defined + in: + + * ``set firewall ipv4 input filter ...``. + + * ``set firewall ipv6 input filter ...``. + + * **Forward**: stage where transit traffic can be filtered and controlled. + This includes ipv4 and ipv6 filtering rules, defined in: + + * ``set firewall ipv4 forward filter ...``. + + * ``set firewall ipv6 forward filter ...``. + + * **Output**: stage where traffic that originates from the router itself + can be filtered and controlled. Bear in mind that this traffic can be a + new connection originated by a internal process running on VyOS router, + such as NTP, or a response to traffic received externaly through + **inputt** (for example response to an ssh login attempt to the router). + This includes ipv4 and ipv6 filtering rules, defined in: + + * ``set firewall ipv4 input filter ...``. + + * ``set firewall ipv6 output filter ...``. + + * **Postrouting**: as in **Prerouting**, several actions defined in + different parts of VyOS configuration are performed in this + stage. This includes: + + * **Source NAT**: rules defined under ``set [nat | nat66] + destination...``. + +If interface where the packet was received is part of a bridge, then packet +is processed at the **Bridge Layer**, which contains a basic setup for +bridge filtering: + + * **Forward (Bridge)**: stage where traffic that is trespasing through the + bridge is filtered and controlled: + + * ``set firewall bridge forward filter ...``. + +Main structure VyOS firewall cli is shown next: + +.. code-block:: none + + - set firewall + * bridge + - forward + + filter + * flowtable + - custom_flow_table + + ... + * global-options + + all-ping + + broadcast-ping + + ... + * group + - address-group + - ipv6-address-group + - network-group + - ipv6-network-group + - interface-group + - mac-group + - port-group + - domain-group + * ipv4 + - forward + + filter + - input + + filter + - output + + filter + - name + + custom_name + * ipv6 + - forward + + filter + - input + + filter + - output + + filter + - ipv6-name + + custom_name + * zone + - custom_zone_name + + ... + +Please, refer to appropiate section for more information about firewall +configuration: + +.. toctree:: + :maxdepth: 1 + :includehidden: + + global-options + groups + bridge + ipv4 + ipv6 + flowtables + +.. note:: **For more information** + of Netfilter hooks and Linux networking packet flows can be + found in `Netfilter-Hooks + `_ + + +Zone-based firewall +^^^^^^^^^^^^^^^^^^^ +.. toctree:: + :maxdepth: 1 + :includehidden: + + zone + +With zone-based firewalls a new concept was implemented, in addtion to the +standard in and out traffic flows, a local flow was added. This local was for +traffic originating and destined to the router itself. Which means additional +rules were required to secure the firewall itself from the network, in +addition to the existing inbound and outbound rules from the traditional +concept above. + +To configure VyOS with the +:doc:`zone-based firewall configuration ` + +As the example image below shows, the device now needs rules to allow/block +traffic to or from the services running on the device that have open +connections on that interface. + +.. figure:: /_static/images/firewall-zonebased.png From dfa516d63e38eadc5e57dd143b17022c6ff2c092 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Robert=20G=C3=B6hler?= Date: Mon, 8 Jan 2024 21:23:37 +0100 Subject: [PATCH 3/3] Delete docs/configuration/firewall/index.rst~ --- docs/configuration/firewall/index.rst~ | 179 ------------------------- 1 file changed, 179 deletions(-) delete mode 100644 docs/configuration/firewall/index.rst~ diff --git a/docs/configuration/firewall/index.rst~ b/docs/configuration/firewall/index.rst~ deleted file mode 100644 index bdfc20693a..0000000000 --- a/docs/configuration/firewall/index.rst~ +++ /dev/null @@ -1,179 +0,0 @@ -:lastproofread: 2023-11-23 - -######## -Firewall -######## - -With VyOS being based on top of Linux and its kernel, the Netfilter project -created iptables and its successor nftables for the Linux kernel to -work directly on the data flows. This now extends the concept of zone-based -security to allow for manipulating the data at multiple stages once accepted -by the network interface and the driver before being handed off to the -destination (e.g., a web server OR another device). - -A simplified traffic flow diagram, based on Netfilter packet flow, is shown next, in -order to have a full view and understanding of how packets are processed, and -what possible paths traffic can take. - -.. figure:: /_static/images/firewall-gral-packet-flow.png - -Main points regarding this packet flow and terminology used in VyOS firewall are below: - - * **Bridge Port?**: choose appropriate path based on whether interface where the - packet was received is part of a bridge, or not. - -If interface where the packet was received isn't part of a bridge, then packet -is processed at the **IP Layer**: - - * **Prerouting**: several actions can be done in this stage, and currently - these actions are defined in different parts in VyOS configuration. Order - is important, and all these actions are performed before any actions - defined under ``firewall`` section. Relevant configuration that acts in - this stage are: - - * **Conntrack Ignore**: rules defined under ``set system conntrack ignore - [ipv4 | ipv6] ...``. - - * **Policy Route**: rules defined under ``set policy [route | route6] - ...``. - - * **Destination NAT**: rules defined under ``set [nat | nat66] - destination...``. - - * **Destination is the router?**: choose appropriate path based on - destination IP address. Transit forward continues to **forward**, - while traffic that destination IP address is configured on the router - continues to **input**. - - * **Input**: stage where traffic destined for the router itself can be - filtered and controlled. This is where all rules for securing the router - should take place. This includes ipv4 and ipv6 filtering rules, defined - in: - - * ``set firewall ipv4 input filter ...``. - - * ``set firewall ipv6 input filter ...``. - - * **Forward**: stage where transit traffic can be filtered and controlled. - This includes ipv4 and ipv6 filtering rules, defined in: - - * ``set firewall ipv4 forward filter ...``. - - * ``set firewall ipv6 forward filter ...``. - - * **Output**: stage where traffic that originates from the router itself - can be filtered and controlled. Bear in mind that this traffic can be a - new connection originated by a internal process running on VyOS router, - such as NTP, or a response to traffic received externaly through - **inputt** (for example response to an ssh login attempt to the router). - This includes ipv4 and ipv6 filtering rules, defined in: - - * ``set firewall ipv4 input filter ...``. - - * ``set firewall ipv6 output filter ...``. - - * **Postrouting**: as in **Prerouting**, several actions defined in - different parts of VyOS configuration are performed in this - stage. This includes: - - * **Source NAT**: rules defined under ``set [nat | nat66] - destination...``. - -If interface where the packet was received is part of a bridge, then packet -is processed at the **Bridge Layer**, which contains a basic setup for -bridge filtering: - - * **Forward (Bridge)**: stage where traffic that is trespasing through the - bridge is filtered and controlled: - - * ``set firewall bridge forward filter ...``. - -Main structure VyOS firewall cli is shown next: - -.. code-block:: none - - - set firewall - * bridge - - forward - + filter - * flowtable - - custom_flow_table - + ... - * global-options - + all-ping - + broadcast-ping - + ... - * group - - address-group - - ipv6-address-group - - network-group - - ipv6-network-group - - interface-group - - mac-group - - port-group - - domain-group - * ipv4 - - forward - + filter - - input - + filter - - output - + filter - - name - + custom_name - * ipv6 - - forward - + filter - - input - + filter - - output - + filter - - ipv6-name - + custom_name - * zone - - custom_zone_name - + ... - -Please, refer to appropiate section for more information about firewall -configuration: - -.. toctree:: - :maxdepth: 1 - :includehidden: - - global-options - groups - bridge - ipv4 - ipv6 - flowtables - -.. note:: **For more information** - of Netfilter hooks and Linux networking packet flows can be - found in `Netfilter-Hooks - `_ - - -Zone-based firewall -^^^^^^^^^^^^^^^^^^^ -.. toctree:: - :maxdepth: 1 - :includehidden: - - zone - -With zone-based firewalls a new concept was implemented, in addtion to the -standard in and out traffic flows, a local flow was added. This local was for -traffic originating and destined to the router itself. Which means additional -rules were required to secure the firewall itself from the network, in -addition to the existing inbound and outbound rules from the traditional -concept above. - -To configure VyOS with the -:doc:`zone-based firewall configuration ` - -As the example image below shows, the device now needs rules to allow/block -traffic to or from the services running on the device that have open -connections on that interface. - -.. figure:: /_static/images/firewall-zonebased.png