===== Rules ===== .. image:: ./rule/image1.png :scale: 100% This section provides an introduction and overview of the **Firewall Rules** screen. First, browse to FirewallRules. This will bring up the WAN rule set. .. image:: ./rule/image10.png which by default has no entries other than those for Block private networks and Block bogon networks if you enabled. If you click **edit** the to the right of the Block private networks or Block bogon networks rules, it will take you to the WAN interface configuration page, where these options can be enabled or disabled. (See Block Private Networks and Block Bogon Networks for more details about blocking private and bogon networks.) Click on the **LAN** tab to view the LAN rules. .. image:: ./rule/image2.png :scale: 100% By default,the only entries are the Default allow LAN to any rules for IPv4 and IPv6. and the Anti-Lockout Rule if you have it enabled. The anti-lockout rule is designed to prevent you from accidentally locking yourself out of the GUI. Click **edit** next to the anti-lockout rule and you will be taken to the page where you can disable the rule. For more information on how it works and how to disable it, see Anti-lockout. Rules for other interfaces may be viewed by clicking their respective tabs. OPT interfaces will appear with their descriptive names, so if you named your OPT1 interface DMZ, then the tab for its rules will also say DMZ. To the left of each rule is an indicator icon showing the action of the rule pass, block, or reject. If logging is enabled for the rule, is shown there as well. The same icons are used for disabled rules, except the iconlike the rule, will be a lighter shade of their original color, or a shade of gray. **Adding a firewall rule** Click either of the **pluse** buttons on the Firewall: Rules screen to add a new rule. The top and bottom buttons, as shown LAN Rule Options, will add a new rule. The **upper arow** top adds a rule to the top of the ruleset, while the bottom **down arrow** adds the rule at the bottom. **Editing Firewall Rules** To edit a firewall rule, click the **edit** to the right of the rule, or double click anywhere on the line. You will then be taken to the edit screen for that rule, where you can make any needed adjustments. See Configuring firewall rules for more information on the options available when editing a rule. **Deleting Firewall Rules** To delete a single rule, click the **delet butten** to the right of the rule. You will be prompted to confirm the deletion, and if this is what you wanted to do, click OK to actually delete the rule. To delete multiple rules, check the box at the start ofthe rows that should be removed, then click the **delet** ai the bottom of the list. Rules may also be selected by single clicking any where on their line. -------------------------- Configuring firewall rules -------------------------- This section covers each individual option available onthe Firewall Rules Edit screen when configuring firewall rules. .. image:: ./rule/image3.png :scale: 100% **Action** This is where you specify whether the rule will pass , block , or reject traffic. Each of these is covered earlier in this chapter. **Disabled** If you wish to disable a rule without removing it from the rule list, check this box. It will still show in your firewall rules screen, but will be grayed out to indicate its disabled state. .. image:: ./rule/image3.1.png :scale: 100% **Interface** The Interface drop down specifies the interface on which the rule will be applied. Remember that on interface and group tab rules, traffic is only filtered on the interface where the traffic is initiated. Traffic initiated from your LAN destined to the Internet or any other interface on your firewall is filtered by the LAN ruleset. **TCP/IP Version** Here is where you choose if this rule will apply to IPv4 , IPv6 , or both IPv4+IPv6 . The rules will only match and act upon packets matching the correct protocol. You can use aliases that contain both types of IP addresses and the rule will match only the addresses from the correct protocol. .. Note:: IPv4+IPv6 type rules can only work with ICMP, TCP, UDP, and TCP/UDP. Other protocols require separate rules for each type of traffic. **Protocol** This is where you specify the protocol this rule will match. Most of these options are self-explanatory. TCP/UDP will match both TCP and UDP traffic. Specifying ICMPwill make another drop down box appear where you can select the ICMP type. Several other common protocols are also available. .. Note:: This field defaults to TCP for a new rule because it’s a common default and it will display the expected fields for that protocol. If you wish the rule to apply to any protocol, you will need to change this field to any . One of the most common mistakes in creatingnew rules is accidentally creating a TCP rule and then not being able to use ping, DNS, etc. **Source** .. image:: ./rule/image4.png :scale: 100% This is where you specify the source IP address, subnet, or alias that will match this rule. You may also check the not box to negate the match. For the Type you may specify: Any, which will match anyaddress; Single host or alias, which will match a single IP address/hostname or alias name; or Network, which will take both an IP address and subnet mask to match arange of addresses. Lastly, there are several available presets that can be quite useful instead of entering these addresses by hand: WAN address, LAN address, LAN subnet, and PPPoE users. For rules using TCP and/or UDP, you can also specify the source port here by clicking the Advanced button. The source port is hidden behind the Advanced button because you will normally want to leave the source port set to “any”, as TCP and UDP connections are sourced from a random port in the ephemeral port range (between 1024 through 65535, the exact range used varying depending on the OS and OS version that is initiating the connection). The source port is almost never the same as the destination port, and you should never configure it as such unless you know the application you are using employs this a typical behavior. It is also safe to define your source port as a range from 1024 to 65535. **Destination** .. image:: ./rule/image5.png :scale: 100% This is where you specify the destination IP address, subnet, or alias that will match this rule. See the description of the Source option in Source for more details. As with the Source address setting, you may check notto negate the match. For rules specifying TCP and/or UDP, the destination port, port range, or alias is also specified here. **Extra Option** .. image:: ./rule/image6.png :scale: 100% **Log** This box determines whether packets that match this rule will be logged to the firewall log. Logging is discussed in more detail in Logging Practices. **Description** Enter a description here for your reference. This is optional, and does not affect functionality of the rule. You should enter something here describing the purpose of the rule. The maximum length is 52 characters. **Advanced Features** .. image:: ./rule/image7.png :scale: 100% Some options that are less likely to be needed or that have functionality that could be confusing to new usershave been related into this section of the page. Each set of options inside this section is hidden behind an Advanced button to keep the page from being too cluttered with potentially confusing information. If an option in this section of the page has been set, then it will appear when the rule is loaded in the future without needing to click Advanced. **Source OS** One of the more unique features of pf and hence DefenseBolt is the ability to filter by the operating system initiating the connection. For TCP rules, pf enables passive operating system finger printing that allows you to create rules based on the operating system initiating the TCP connection. The p0f feature of pf determines the OS in use by comparing characteristics of the TCP SYN packet that initiates TCP connections with a finger prints file. Note that it is possible to change the fingerprint of your operating system to look like another OS, especially with open source operating systems such as the BSDs and Linux. This isn’t easy, but if you have technically proficient users with administrator or root level access to systems, it is possible. **Diffserv Code Point** Differentiated Services Code Point, shortened to Diffserv Code Point or abbreviated as DSCP and sometimes referred to as the TOS field, is a way for applications to indicate inside the packets how they would prefer the routers to treat their traffic as it gets forwarded along its path. The most common use of this is for quality of service or traffic shaping purposes. The program or device generating the packets, for example Asterisk via its tos_sip and tos_audio configuration parameters, will set the flag in the packets and then it’s up to the firewall to match and queue or act on them as needed.If you want to match these parameters in the firewall using the Diffserv Code Point drop-down entry that matches the value set by the originating device The downside of DSCP is that it assumes that routers support or act on the field, which may or may not be the case,and different routers may treat the same DSCP value in unintended or mismatched ways. .. Note:: This option only reads and matches the DSCP value. It does not set it. **Advanced Options** This section lets you configure several of pf’s powerful advanced options. This includes abilities to limit firewall states on a per- rule basis. By default, there are no limits or values set for any of these parameters. **IP Options** Checking this box will allow packets with defined IP options to pass. By default, pf blocks all packets that have IP options set in order to deter OS fingerprinting, among other reasons. IF you have IGMP or other multicast traffic with IP options that must be passed, then check this box. **Disable Reply-To** By default, on WAN type interfaces we add reply-to in order to ensure that traffic that enters a WAN will alsoleave via that same WAN. In certain cases this behavioris undesirable, such as when some traffic is routed viaa separate firewall/router on the WAN interface. In these cases you can check this option to disable reply-to only for traffic matching this rule, rather than disabling reply-to globally. **Marking and Matching** These are mostly useful in concert with floating rules,so you can mark a packet with a specific string on the way in with an interface rule, and then act differentlyon a matched packet on the way out with a floating rule. See Marking and Matching for more on this topic. .. image:: ./rule/image7.1.png :scale: 100% **Maximum state entries this rule can create** This option limits the maximum number of connections, total, that can be allowed by this rule. If more connections match this rule while it is at its connection limit, this rule will be skipped in the rule evaluation. If a later rule matches, the traffic has the action of that rule applied, otherwise it hits the default deny rule. Once the number of connections permitted by this rule drops below this connection limit, traffic can once again match this rule. **Maximum number of unique source hosts** This option specifies how many total source IPs may simultaneously connect for this rule. Each source IP is allowed an unlimited number of connections, but the total number of source IPs allowed is restricted to this value. **Maximum number of established connections per host** If you prefer to limit based on connections per host, this setting is what you want. Using this setting, you may limit a rule to 10 connections per source host, instead of 10 connections total. This option controls how many fully established (completed handshake) connections are allowed per host that match the rule. **Maximum state entries per host** This setting works similarly to the established count above, but works regardless of whether or not a successful connection was made. .. image:: ./rule/image8.png :scale: 100% **Maximum new connections / per second** This method of rate limiting can help to ensure that a high connection rate will not overload a server or yourstate table. For example, limits can be placed on incoming connections to a mail server to reduce the burden of being overloaded by spambots. It can also be used on outbound traffic rules to set limits that would preventany single machine from loading up your state table or making too many rapid connections, behaviors which are common with viruses. You can set both a connection amount and a number of seconds for the time period. Any IP address exceeding that number of connections within thegiven time frame will be blocked for one hour. Behind the scenes, this is handled by the virusprot table, named for its typical purpose of virus protection. **State timeout in seconds** Here you can define a state timeout for traffic matching this rule, overriding the system’s default state timeout. Any inactive connections will be closed when the connection has been idle for this amount of time. The default state timeout depends on the firewall optimization algorithm in use. The optimization choices are covered in Firewall Optimization Options .. Note:: Because this only controls the traffic in the inbound direction, it is not very useful on its own. The outbound traffic will still have the default state timeout. To use this setting properly, you will also need a matching floating rule in the outbound path taken by the traffic with a similar state timeout setting. **TCP Flags** .. image:: ./rule/image8.1.png :scale: 100% By default, new pass rules for TCP only check for the TCP SYN flag to be set, out of a possible set of SYN and ACK. If you need to account for more complex scenarios, such as working around asymmetric routing or some other non-traditional combination of traffic flow, you can alter how the flags are checked here. The first row controls which flags must be set to match the rule. The second row defines the list of flags that will be consulted on the packet to look for a match. The meanings of the most commonly used flags are: **SYN** Synchronize sequence numbers. Indicates a new connection attempt. ACK Indicates ACKnowledgment of data. As discussed earlier, these are replies to let the sender know data was received OK. **FIN** Indicates there is no more data from the sender, closing a connection. **RST** Connection reset. This flag is set when replying to a request to open a connection on a port which has no listening daemon. Can also be set by firewall software to turn away undesirable connections. **PSH** Indicates that data should be pushed or flushed, including data in this packet, by passing the data up to the application. **URG** Indicates that the urgent field is significant, and this packet should be sent before data that is not urgent. To allow TCP with any flags set, check **Any Flags.** **State Type** There are three options for state tracking in DefenseBolt that can be specified on a per-rule basis. - keep state This is the default, and what you should almost always use. - sloppy state Sloppy is a less strict means of keeping state that’s intended for scenarios where there is asymmetric routing. When the firewall can only see half the traffic of a connection, the validity checks of the default state keeping will fail and traffic will be blocked. Some of pf’s mechanisms that prevent certain kinds of attacks will not kick in during a sloppy state check. - synproxy state This option causes DefensBolt to proxy incoming TCP connections. TCP connections start with a three way handshake. The first packet of a TCP connection is a SYN from source, which elicits a SYN ACK response from the destination, then an ACK in return from the source to complete the handshake. Normally the host behind the firewall will handle this on its own, but synproxy state has the firewall complete this handshake instead. This helps protect against one type of Denial of Service attack, SYN floods. This is typically only used with rules on WAN interfaces. This type of attack is best handled at the target OS level today, as every modern operating system includes capabilities of handling this on its own. Because the firewall can’t know what TCP extensions the back-end host supports, when using synproxy state, it announces no supported TCP extensions. This means connections created using synproxy state will not use window scaling, SACK, nor timestamps which will lead to significantly reduced performance in most all cases. It can be useful when opening TCP ports to hosts that do not handle network abuse well, where top performance isn’t a concern. **none** This option will not keep state on this rule. This is only necessary in some highly specialized advanced scenarios, none of which are covered in this book because they are exceedingly rare. You should never have a need for using this option. .. Note:: Because this only affects traffic in the inbound direction, it is not very useful, since a state will still be created in the outbound direction. It must be paired with a floating rule in the outbound direction which also has the same option chosen. .. image:: ./rule/image9.png :scale: 100% **No XML-RPC Sync** Checking this box prevents this rule from synchronizingto other CARP members. This is covered in High Availability. This does not prevent a rule on a slave node from being overwritten by the master. **802.1p** 802.1p, also known as IEEE P802.1p or Priority Code Point, is a way to match and tag packets with a specific quality of service priority. Unlike DSCP, 802.1p operates at layer 2 with VLANs. However, like DSCP, the upstream router must also support 802.1p for it to be useful. There are two options in this section. The first will match an 802.1p field so you can choose how to act on it. The second will inject an 802.1p tag into a packet as it passes through this firewall. Some ISPs may require this in certain areas, such as France, in order to properly handle voice/video/data on segregated VLANs at the correct priority to ensure quality. There are eight levels of priority for 802.1p, and eachhas a two letter code in the GUI. In order from lowest priority to highest, they are: - BK Background - BE Best Effort - EE Excellent Effort - CA Critical Applications - VI Video - VO Voice - IC Internetwork Control - NC Network Control **Schedule** Here you can select a schedule specifying the days and times this rule will be in effect. Selecting “none” means the rule will always be enabled. For more information, see Time Based Rules later in this chapter. **Gateway** Gateway allows you to specify a Gateway or Gateway Group for traffic matching this rule to use. This is covered in Policy routing. .. image:: ./rule/image9.1.png :scale: 100% **In/Out (Limiters)** These selections let you pick from your defined Limiters to apply a bandwidth limit to the traffic entering this interface (In) and leaving this interface (Out). More detail on limiters can be found in Limiters. **Ackqueue/Queue** These options define which traffic shaper queues are applied to traffic entering and exiting this interface. For more information on traffic shaping, see Traffic Shaper. **Layer 7** Selecting an entry for Layer 7 will redirect traffic into a Layer 7 inspection instance. See Layer 7 Inspection for more information on Layer 7 filtering and classification. .. Note:: It is counter-intuitive, but rules for Layer 7 should always use the pass action. The decision to block or queue is made by the Layer 7 inspection instance, the firewall rule merely passes the traffic into the inspection daemon so it can be acted upon later. .. Note:: Layer 7 cannot be used to direct traffic to a specific WAN with Multi-WAN. The classification of traffic must happen after the flow has already started, which is too late to make a routing decision.