diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/appendix/examples/zone-policy.rst | 152 | ||||
| -rw-r--r-- | docs/firewall.rst | 107 | ||||
| -rw-r--r-- | docs/routing/pbr.rst | 39 |
3 files changed, 176 insertions, 122 deletions
diff --git a/docs/appendix/examples/zone-policy.rst b/docs/appendix/examples/zone-policy.rst index 90ece39a..bfe77c2e 100644 --- a/docs/appendix/examples/zone-policy.rst +++ b/docs/appendix/examples/zone-policy.rst @@ -15,16 +15,31 @@ We have three networks. DMZ - 192.168.200.0/24, 2001:0DB8:0:BBBB::0/64 -This specific example is for a router on a stick, but is very easily adapted -for however many NICs you have. +**This specific example is for a router on a stick, but is very easily +adapted for however many NICs you have**: + + +* Internet - 192.168.200.100 - TCP/80 +* Internet - 192.168.200.100 - TCP/443 +* Internet - 192.168.200.100 - TCP/25 +* Internet - 192.168.200.100 - TCP/53 +* VyOS actis as DHCP, DNS forwarder, NAT, router and firewall. +* 192.168.200.200/2001:0DB8:0:BBBB::200 is an internal/external DNS, web + and mail (SMTP/IMAP) server. +* 192.168.100.10/2001:0DB8:0:AAAA::10 is the administrator's console. It + can SSH to VyOS. +* LAN and DMZ hosts have basic outbound access: Web, FTP, SSH. +* LAN can access DMZ resources. +* DMZ cannot access LAN resources. +* Inbound WAN connect to DMZ host. .. image:: /_static/images/zone-policy-diagram.png :width: 80% :align: center :alt: Network Topology Diagram -The VyOS interface is assigned the .1/:1 address of their respective networks. -WAN is on VLAN 10, LAN on VLAN 20, and DMZ on VLAN 30. +The VyOS interface is assigned the .1/:1 address of their respective +networks. WAN is on VLAN 10, LAN on VLAN 20, and DMZ on VLAN 30. It will look something like this: @@ -57,31 +72,33 @@ It will look something like this: Zones Basics ^^^^^^^^^^^^ -Each interface is assigned to a zone. The interface can be physical or virtual -such as tunnels (VPN, pptp, gre, etc) and are treated exactly the same. +Each interface is assigned to a zone. The interface can be physical or +virtual such as tunnels (VPN, PPTP, GRE, etc) and are treated exactly +the same. Traffic flows from zone A to zone B. That flow is what I refer to as a zone-pair-direction. eg. A->B and B->A are two zone-pair-destinations. Ruleset are created per zone-pair-direction. -I name rule sets to indicate which zone-pair-direction they represent. eg. -ZoneA-ZoneB or ZoneB-ZoneA. LAN-DMZ, DMZ-LAN. +I name rule sets to indicate which zone-pair-direction they represent. +eg. ZoneA-ZoneB or ZoneB-ZoneA. LAN-DMZ, DMZ-LAN. -In VyOS, you have to have unique Ruleset names. In the event of overlap, I -add a "-6" to the end of v6 rulesets. eg. LAN-DMZ, LAN-DMZ-6. This allows for -each auto-completion and uniqueness. +In VyOS, you have to have unique Ruleset names. In the event of overlap, +I add a "-6" to the end of v6 rulesets. eg. LAN-DMZ, LAN-DMZ-6. This +allows for each auto-completion and uniqueness. -In this example we have 4 zones. LAN, WAN, DMZ, Local. The local zone is the -firewall itself. +In this example we have 4 zones. LAN, WAN, DMZ, Local. The local zone is +the firewall itself. -If your computer is on the LAN and you need to SSH into your VyOS box, you -would need a rule to allow it in the LAN-Local ruleset. If you want to access -a webpage from your VyOS box, you need a rule to allow it in the Local-LAN -ruleset. +If your computer is on the LAN and you need to SSH into your VyOS box, +you would need a rule to allow it in the LAN-Local ruleset. If you want +to access a webpage from your VyOS box, you need a rule to allow it in +the Local-LAN ruleset. -In rules, it is good to keep them named consistently. As the number of rules -you have grows, the more consistency you have, the easier your life will be. +In rules, it is good to keep them named consistently. As the number of +rules you have grows, the more consistency you have, the easier your +life will be. .. code-block:: none @@ -97,14 +114,16 @@ you have grows, the more consistency you have, the easier your life will be. Rule 800 - SSH Rule 900 - IMAPS -The first two rules are to deal with the idiosyncrasies of VyOS and iptables. +The first two rules are to deal with the idiosyncrasies of VyOS and +iptables. Zones and Rulesets both have a default action statement. When using -Zone-Policies, the default action is set by the zone-policy statement and is -represented by rule 10000. +Zone-Policies, the default action is set by the zone-policy statement +and is represented by rule 10000. -It is good practice to log both accepted and denied traffic. It can save you -significant headaches when trying to troubleshoot a connectivity issue. +It is good practice to log both accepted and denied traffic. It can save +you significant headaches when trying to troubleshoot a connectivity +issue. To add logging to the default rule, do: @@ -113,38 +132,40 @@ To add logging to the default rule, do: set firewall name <ruleSet> enable-default-log -By default, iptables does not allow traffic for established session to return, -so you must explicitly allow this. I do this by adding two rules to every -ruleset. 1 allows established and related state packets through and rule 2 -drops and logs invalid state packets. We place the established/related rule at -the top because the vast majority of traffic on a network is established and -the invalid rule to prevent invalid state packets from mistakenly being matched -against other rules. Having the most matched rule listed first reduces CPU load -in high volume environments. Note: I have filed a bug to have this added as a -default action as well. +By default, iptables does not allow traffic for established session to +return, so you must explicitly allow this. I do this by adding two rules +to every ruleset. 1 allows established and related state packets through +and rule 2 drops and logs invalid state packets. We place the +established/related rule at the top because the vast majority of traffic +on a network is established and the invalid rule to prevent invalid +state packets from mistakenly being matched against other rules. Having +the most matched rule listed first reduces CPU load in high volume +environments. Note: I have filed a bug to have this added as a default +action as well. ''It is important to note, that you do not want to add logging to the -established state rule as you will be logging both the inbound and outbound -packets for each session instead of just the initiation of the session. -Your logs will be massive in a very short period of time.'' +established state rule as you will be logging both the inbound and +outbound packets for each session instead of just the initiation of the +session. Your logs will be massive in a very short period of time.'' -In VyOS you must have the interfaces created before you can apply it to the -zone and the rulesets must be created prior to applying it to a zone-policy. +In VyOS you must have the interfaces created before you can apply it to +the zone and the rulesets must be created prior to applying it to a +zone-policy. I create/configure the interfaces first. Build out the rulesets for each -zone-pair-direction which includes at least the three state rules. Then I setup -the zone-policies. +zone-pair-direction which includes at least the three state rules. Then +I setup the zone-policies. -Zones do not allow for a default action of accept; either drop or reject. -It is important to remember this because if you apply an interface to a zone -and commit, any active connections will be dropped. Specifically, if you are -SSH’d into VyOS and add local or the interface you are connecting through to a -zone and do not have rulesets in place to allow SSH and established sessions, -you will not be able to connect. +Zones do not allow for a default action of accept; either drop or +reject. It is important to remember this because if you apply an +interface to a zone and commit, any active connections will be dropped. +Specifically, if you are SSH’d into VyOS and add local or the interface +you are connecting through to a zone and do not have rulesets in place +to allow SSH and established sessions, you will not be able to connect. -The following are the rules that were created for this example -(may not be complete), both in IPv4 and IPv6. If there is no IP specified, -then the source/destination address is not explicit. +The following are the rules that were created for this example (may not +be complete), both in IPv4 and IPv6. If there is no IP specified, then +the source/destination address is not explicit. .. code-block:: none @@ -213,10 +234,10 @@ Since we have 4 zones, we need to setup the following rulesets. Dmz-wan Dmz-local -Even if the two zones will never communicate, it is a good idea to create the -zone-pair-direction rulesets and set enable-default-log. This will allow you to -log attempts to access the networks. Without it, you will never see the -connection attempts. +Even if the two zones will never communicate, it is a good idea to +create the zone-pair-direction rulesets and set enable-default-log. This +will allow you to log attempts to access the networks. Without it, you +will never see the connection attempts. This is an example of the three base rules. @@ -325,26 +346,32 @@ Start by setting the interface and default action for each zone. set zone-policy zone dmz default-action drop set zone-policy zone dmz interface eth0.30 -In this case, we are setting the v6 ruleset that represents traffic sourced -from the LAN, destined for the DMZ. -Because the zone-policy firewall syntax is a little awkward, I keep it straight -by thinking of it backwards. +In this case, we are setting the v6 ruleset that represents traffic +sourced from the LAN, destined for the DMZ. Because the zone-policy +firewall syntax is a little awkward, I keep it straight by thinking of +it backwards. .. code-block:: none set zone-policy zone dmz from lan firewall ipv6-name lan-dmz-6 -dmz-lan policy is lan-dmz. You can get a rhythm to it when you build out a bunch at one time. +DMZ-LAN policy is LAN-DMZ. You can get a rhythm to it when you build out +a bunch at one time. -In the end, you will end up with something like this config. I took out everything but the Firewall, Interfaces, and zone-policy sections. It is long enough as is. +In the end, you will end up with something like this config. I took out +everything but the Firewall, Interfaces, and zone-policy sections. It is +long enough as is. IPv6 Tunnel ^^^^^^^^^^^ -If you are using a IPv6 tunnel from HE.net or someone else, the basis is the same except you have two WAN interface. One for v4 and one for v6. +If you are using a IPv6 tunnel from HE.net or someone else, the basis is +the same except you have two WAN interface. One for v4 and one for v6. -You would have 5 zones instead of just 4 and you would configure your v6 ruleset between your tunnel interface and your LAN/DMZ zones instead of to the WAN. +You would have 5 zones instead of just 4 and you would configure your v6 +ruleset between your tunnel interface and your LAN/DMZ zones instead of +to the WAN. LAN, WAN, DMZ, local and TUN (tunnel) @@ -367,7 +394,8 @@ v6 pairs would be: Notice, none go to WAN since WAN wouldn't have a v6 address on it. -You would have to add a couple of rules on your wan-local ruleset to allow protocol 41 in. +You would have to add a couple of rules on your wan-local ruleset to +allow protocol 41 in. Something like: diff --git a/docs/firewall.rst b/docs/firewall.rst index 9426b87d..12eae726 100644 --- a/docs/firewall.rst +++ b/docs/firewall.rst @@ -3,53 +3,63 @@ Firewall ======== -VyOS makes use of Linux `netfilter <https://netfilter.org/>`_ for packet filtering. - -The firewall supports the creation of groups for ports, addresses, and networks -(implemented using netfilter ipset) and the option of interface or zone based -firewall policy. - -**Important note on usage of terms:** The firewall makes use of the terms -`in`, `out`, and `local` for firewall policy. Users experienced with netfilter -often confuse `in` to be a reference to the `INPUT` chain, and `out` the -`OUTPUT` chain from netfilter. This is not the case. These instead indicate the -use of the `FORWARD` chain and either the input or output interface. The -`INPUT` chain, which is used for local traffic to the OS, is a reference to -as `local` with respect to its input interface. +VyOS makes use of Linux `netfilter <https://netfilter.org/>`_ for packet +filtering. + +The firewall supports the creation of groups for ports, addresses, and +networks (implemented using netfilter ipset) and the option of interface +or zone based firewall policy. + +.. note:: **Important note on usage of terms:** + The firewall makes use of the terms `in`, `out`, and `local` + for firewall policy. Users experienced with netfilter often confuse + `in` to be a reference to the `INPUT` chain, and `out` the `OUTPUT` + chain from netfilter. This is not the case. These instead indicate + the use of the `FORWARD` chain and either the input or output + interface. The `INPUT` chain, which is used for local traffic to the + OS, is a reference to as `local` with respect to its input interface. Zone-based Firewall Policy -------------------------- -As an alternative to applying policy to an interface directly, a zone-based -firewall can be created to simplify configuration when multiple interfaces -belong to the same security zone. Instead of applying to rulesets to interfaces -they are applied to source zone-destination zone pairs. +As an alternative to applying policy to an interface directly, a +zone-based firewall can be created to simplify configuration when +multiple interfaces belong to the same security zone. Instead of +applying to rulesets to interfaces they are applied to source +zone-destination zone pairs. -An example to zone-based firewalls can be found here: :ref:`examples-zone-policy`. +An introduction to zone-based firewalls can be found `here +<https://support.vyos.io/en/kb/articles/a-primer-to-zone-based-firewall>`_, +and an example at :ref:`examples-zone-policy`. Groups ------ -Firewall groups represent collections of IP addresses, networks, or ports. Once -created, a group can be referenced by firewall rules as either a source or -destination. Members can be added or removed from a group without changes to -or the need to reload individual firewall rules. +Firewall groups represent collections of IP addresses, networks, or +ports. Once created, a group can be referenced by firewall rules as +either a source or destination. Members can be added or removed from a +group without changes to or the need to reload individual firewall +rules. .. note:: Groups can also be referenced by NAT configuration. -While **network groups** accept IP networks in CIDR notation, specific IP addresses -can be added as a 32-bit prefix. If you foresee the need to add a mix of -addresses and networks, the network group is recommended. +While **network groups** accept IP networks in CIDR notation, specific +IP addresses can be added as a 32-bit prefix. If you foresee the need +to add a mix of addresses and networks, the network group is +recommended. -Here is an example of a network group for the IP networks that make up the -internal network: +Here is an example of a network group for the IP networks that make up +the internal network: .. code-block:: none set firewall group network-group NET-INSIDE network 192.168.0.0/24 set firewall group network-group NET-INSIDE network 192.168.1.0/24 -Groups need to have unique names. Even though some contain IPv4 addresses and others contain IPv6 addresses, they still need to have unique names, so you may want to append "-v4" or "-v6" to your group names. +Groups need to have unique names. Even though some contain IPv4 +addresses and others contain IPv6 addresses, they still need to have +unique names, so you may want to append "-v4" or "-v6" to your group +names. .. code-block:: none @@ -57,10 +67,11 @@ Groups need to have unique names. Even though some contain IPv4 addresses and ot set firewall group ipv6-network-group NET-INSIDE-v6 network 2001:db8::/64 -A **port group** represents only port numbers, not the protocol. Port groups can -be referenced for either TCP or UDP. It is recommended that TCP and UDP groups -are created separately to avoid accidentally filtering unnecessary ports. -Ranges of ports can be specified by using `-`. +A **port group** represents only port numbers, not the protocol. Port +groups can be referenced for either TCP or UDP. It is recommended that +TCP and UDP groups are created separately to avoid accidentally +filtering unnecessary ports. Ranges of ports can be specified by using +`-`. Here is an example of a port group a server: @@ -73,9 +84,10 @@ Here is an example of a port group a server: Rule-Sets --------- -A rule-set is a named collection of firewall rules that can be applied to an -interface or zone. Each rule is numbered, has an action to apply if the rule -is matched, and the ability to specify the criteria to match. +A rule-set is a named collection of firewall rules that can be applied +to an interface or zone. Each rule is numbered, has an action to apply +if the rule is matched, and the ability to specify the criteria to +match. Example of a rule-set to filter traffic to the internal network: @@ -93,8 +105,8 @@ Applying a Rule-Set to an Interface Once a rule-set is created, it can be applied to an interface. -.. note:: Only one rule-set can be applied to each interface for `in`, `out`, - or `local` traffic for each protocol (IPv4 and IPv6). +.. note:: Only one rule-set can be applied to each interface for `in`, + `out`, or `local` traffic for each protocol (IPv4 and IPv6). .. code-block:: none @@ -113,23 +125,34 @@ first be created): How VyOS replies when being pinged ---------------------------------- -By default, when VyOS receives an ICMP echo request packet destined for itself, it will answer with an ICMP echo reply, unless you avoid it through its firewall. +By default, when VyOS receives an ICMP echo request packet destined for +itself, it will answer with an ICMP echo reply, unless you avoid it +through its firewall. -With the firewall you can set rules to accept, drop or reject ICMP in, out or local traffic. You can also use the general **firewall all-ping** command. This command affects only to LOCAL (packets destined for your VyOS system), not to IN or OUT traffic. +With the firewall you can set rules to accept, drop or reject ICMP in, +out or local traffic. You can also use the general **firewall all-ping** +command. This command affects only to LOCAL (packets destined for your +VyOS system), not to IN or OUT traffic. -.. note:: **firewall all-ping** affects only to LOCAL and it always behaves in the most restrictive way +.. note:: **firewall all-ping** affects only to LOCAL and it always + behaves in the most restrictive way .. code-block:: none set firewall all-ping enable -When the command above is set, VyOS will answer every ICMP echo request addressed to itself, but that will only happen if no other rule is applied dropping or rejecting local echo requests. In case of conflict, VyOS will not answer ICMP echo requests. +When the command above is set, VyOS will answer every ICMP echo request +addressed to itself, but that will only happen if no other rule is +applied dropping or rejecting local echo requests. In case of conflict, +VyOS will not answer ICMP echo requests. .. code-block:: none set firewall all-ping disable -When the command above is set, VyOS will answer no ICMP echo request addressed to itself at all, no matter where it comes from or whether more specific rules are being applied to accept them. +When the command above is set, VyOS will answer no ICMP echo request +addressed to itself at all, no matter where it comes from or whether +more specific rules are being applied to accept them. Example Partial Config ---------------------- diff --git a/docs/routing/pbr.rst b/docs/routing/pbr.rst index 5d2678ff..797f79e3 100644 --- a/docs/routing/pbr.rst +++ b/docs/routing/pbr.rst @@ -5,15 +5,16 @@ PBR --- -:abbr:`PBR (Policy-Based Routing)` allowing traffic to be assigned to different -routing tables. Traffic can be matched using standard 5-tuple matching (source -address, destination address, protocol, source port, destination port). +:abbr:`PBR (Policy-Based Routing)` allowing traffic to be assigned to +different routing tables. Traffic can be matched using standard 5-tuple +matching (source address, destination address, protocol, source port, +destination port). Transparent Proxy ^^^^^^^^^^^^^^^^^ -The following example will show how VyOS can be used to redirect web traffic to -an external transparent proxy: +The following example will show how VyOS can be used to redirect web +traffic to an external transparent proxy: .. code-block:: none @@ -21,9 +22,9 @@ an external transparent proxy: set policy route FILTER-WEB rule 1000 protocol tcp set policy route FILTER-WEB rule 1000 set table 100 -This creates a route policy called FILTER-WEB with one rule to set the routing -table for matching traffic (TCP port 80) to table ID 100 instead of the -default routing table. +This creates a route policy called FILTER-WEB with one rule to set the +routing table for matching traffic (TCP port 80) to table ID 100 +instead of the default routing table. To create routing table 100 and add a new default gateway to be used by traffic matching our route policy: @@ -32,10 +33,11 @@ traffic matching our route policy: set protocols static table 100 route 0.0.0.0/0 next-hop 10.255.0.2 -This can be confirmed using the show ip route table 100 operational command. +This can be confirmed using the ``show ip route table 100`` operational +command. -Finally, to apply the policy route to ingress traffic on our LAN interface, -we use: +Finally, to apply the policy route to ingress traffic on our LAN +interface, we use: .. code-block:: none @@ -45,15 +47,15 @@ we use: Multiple Uplinks ^^^^^^^^^^^^^^^^ -VyOS Policy-Based Routing (PBR) works by matching source IP address ranges and -forwarding the traffic using different routing tables. +VyOS Policy-Based Routing (PBR) works by matching source IP address +ranges and forwarding the traffic using different routing tables. Routing tables that will be used in this example are: * ``table 10`` Routing table used for VLAN 10 (192.168.188.0/24) * ``table 11`` Routing table used for VLAN 11 (192.168.189.0/24) -* ``main`` Routing table used by VyOS and other interfaces not participating in - PBR +* ``main`` Routing table used by VyOS and other interfaces not + participating in PBR .. figure:: ../_static/images/pbr_example_1.png :scale: 80 % @@ -89,7 +91,8 @@ Apply routing policy to **inbound** direction of out VLAN interfaces set interfaces ethernet eth0 vif 11 policy route 'PBR' -**OPTIONAL:** Exclude Inter-VLAN traffic (between VLAN10 and VLAN11) from PBR +**OPTIONAL:** Exclude Inter-VLAN traffic (between VLAN10 and VLAN11) +from PBR .. code-block:: none @@ -98,5 +101,5 @@ Apply routing policy to **inbound** direction of out VLAN interfaces set policy route PBR rule 10 destination address '192.168.189.0/24' set policy route PBR rule 10 set table 'main' -.. note:: Allows the VLAN10 and VLAN20 hosts to communicate with each other - using the main routing table. +These commands allow the VLAN10 and VLAN20 hosts to communicate with +each other using the main routing table. |