diff options
| -rw-r--r-- | docs/appendix/examples/zone-policy.rst | 152 |
1 files changed, 90 insertions, 62 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: |