Shulou(Shulou.com)06/02 Report--

Firewalls

Firewall Foundation

Inlet filtration

Outlet filtration

Brief introduction to firewall rules

Alias

Firewall rule configuration example

Rule method

Configure firewall rules

Floating rule

The method of using other public network IP addresses

Virtual IP address

Time-based rules

View firewall log

How to block access to a website?

Troubleshooting Firewall Rul

One of the main functions performed by pfSense is to filter traffic. This chapter includes firewall fundamentals, best practices, and the necessary information to configure firewall rules.

Basic knowledge of firewall

This section mainly introduces the concept of firewall, which lays the foundation for understanding and using pfSense to configure firewall rules.

Basic terminology

Rules and rule sets are two terms used throughout this chapter:

Rules: refers to a single entry on a firewall > rule policy. Rules guide how firewalls match or handle network traffic. Rule set: collectively referred to as a set of rules. It is either the entire firewall rule or a set of rules in a specific context, such as the rules on the interface tab. The complete firewall rule set is the sum of all user configuration and auto-add rules, which are discussed further in this chapter.

The rule set on the Interface tab is executed by pfSense priority matching. This means that the rule set of the interface is executed from top to bottom, and the first rule to match will be the rule used by the firewall. It stops after the match, and then the firewall takes the action specified by the rule. Always keep this in mind when creating new rules, especially when making rules that limit traffic. The loosest rules should be placed at the bottom of the list so that restrictions or exceptions can be made above.

Be careful

The floating tab is the only exception to this rule processing logic. It will be described later in this chapter.

State filtering

PfSense is a stateful firewall, which means that it remembers information about the connection that flows through the firewall so that it can answer traffic automatically. This data is retained in the status table. The connection information in the state table, including source, destination, protocol, port, and so on, is sufficient to uniquely identify a specific connection.

With this mechanism, you only need to allow communication on the interface that enters the firewall. When the connection meets the delivery rules, the firewall creates an entry in the state table. Traffic is automatically answered to the connection through the firewall by matching it to the state table rather than checking the rules in both directions. This includes any related traffic using different protocols, such as ICMP control messages that may be provided in response to TCP,UDP or other connections.

Referenc

For more information about state options and types, see Firewall Advanced Settings and State types.

Status table size

The firewall state table must be limited in size to prevent memory exhaustion. Each state requires approximately 1 KB of RAM. The default state table size in pfSense is calculated by taking up 10% of the RAM available in the firewall by default. On 1GB RAM's firewall, the default state table size can hold approximately 100000 entries.

Referenc

For more information about state table size and RAM usage, see Firewall maximum State Table.

Each user connection usually consists of two states: one is created when entering the firewall and the other is created when leaving the firewall. Therefore, with a state table size of 1000000, the firewall can handle about 500000 user sessions that are traversing the firewall, after which any additional connections will be discarded. As long as you do not exceed the number of RAM available in the firewall, you can increase this limit as needed.

Increase the status table size:

Navigate to the system > Advanced options, Firewall, and NAT tab

Enter the desired number in the maximum status bar of the firewall, or leave the default calculated value. The following figure increases the size of the state table to 2000000

Click Save.

Modify the maximum firewall state to 2000000

Historical state table usage is tracked by the firewall. To view a chart:

Navigate to system status > Monitoring

Click

Extended Chart option

Set the category of the left axis to the system

Set the drawing of the left axis to the state

Click to update the chart

Stop and reject

There are two ways to disable traffic that uses firewall rules on the pfSense: block and deny.

A rule set to block will quietly drop traffic, and blocked clients will not receive any response, so they will wait for the connection attempt to time out. This is the default behavior of rejecting a rule in pfSense.

The rule is set to deny traffic that responds to clients denying TCP and UDP, letting the sender know that the connection is denied. Rejected TCP traffic receives a TCP RST (reset) in response, and rejected UDP traffic receives an ICMP unreachable message in response. Although rejection is a valid choice for any firewall rule, IP protocols other than TCP and UDP cannot be rejected; these rules silently abandon other IP protocols because there is no standard for rejecting other protocols.

Block or reject?

Over the years, security professionals have debated the value of deterrence and rejection. Some people think that it makes more sense to use blocking, claiming that it "slows down" those who scan the Internet. When a rule is set to reject, an immediate response port is closed, preventing traffic from being dropped quietly, causing the port scanner to wait for a response. This is not true because every good port scanner can scan hundreds or thousands of hosts at the same time, and the scanner does not stagnate, waiting for a response from a closed port. The difference between resource consumption and scanning speed is small, but so slight that it should not be taken into account.

If the firewall blocks all traffic from the Internet, there is a significant difference between blocking and denying: no one knows that the firewall is online. Even if a single port is open, the value of this capability is minimal, because the user can easily determine that the host is online and know what port is open, regardless of whether the blocked connection is denied by the firewall. Although there is no significant value in blocking rejections we still recommend using blocking on WAN rules. There is some value in not actively passing information to potential people, and it is not good to automatically respond to external requests unnecessarily.

For internal interface rules, we recommend that you use reject in most cases. When a host tries to access resources that are not allowed by firewall rules, the application that accesses it may hang until the connection times out or the client program stops trying to access the service. The rejected connection is rejected immediately, and the customer avoids these hangs. This is usually just an annoyance, but we usually recommend using rejections to avoid potential application problems caused by quietly dropping traffic in the network.

Inlet filtration

Ingress filtering is the concept of firewall traffic entering the network from an external source, such as Internet. In a deployment that uses multiple WAN, firewalls have multiple entry points. The default ingress policy on pfSense is to block all traffic because there are no allowed rules on WAN in the default rule set. Traffic replies initiated from within the local network are automatically allowed to be returned by the state table through the firewall.

Outlet filtration

Egress filtering refers to the concept of firewall traffic initiated within a local network, destined for a remote network, such as the Internet. Like almost all similar commercial and open source solutions, pfSense comes with LAN rules that allow all communications from LAN to Internet. However, this is not the best way to operate. But it has become the de facto default setting in most firewall solutions that most people expect. The common misconception is that "everything on the intranet is' trustworthy', so why filter it?

Why use exit filtering?

Based on our experience with numerous firewalls working with many suppliers from many different vendors, most small companies and home networks do not use egress filtering. Because each new application or service may need to open additional ports or protocols in the firewall, this increases the administrative burden. In some environments, this is difficult because administrators don't know exactly what's going on on the network, and they don't want to destroy things. In other circumstances, the cause of workplace politics is inevitable. It is a best practice for the administrator to configure the firewall to allow only the minimum required traffic to leave the network where possible. Strict exit filtering is important for the following reasons:

Limit the impact of the damaged system

Export filtering limits the impact of the damaged system. Malware usually uses ports and protocols that are not needed in most business networks. Some rovers rely on IRC connections to call home and receive instructions. Some use more universal ports, such as TCP port 80 (usually HTTP), to evade egress filtering, but many ports do not. If the firewall does not allow access to TCP port 6667 of the usual IRC port 6667, then robots that rely on IRC may be filtered for corruption.

Another example is where we are involved, where the internal interface of the pfSense installation sees 50-60 Mbps of traffic, while the throughput of WAN is less than 1 Mbps. There are no other interfaces on the firewall. Some investigations show that the reason is that the victim system on the local area network running zombie programs participated in the distributed denial of service (DDoS) against China. * use UDP port 80, which is not allowed by the egress rule set in this network, so all DDoS is doing is to emphasize the internal interface of the firewall and discarded traffic. In this case, the firewall advanced by leaps and bounds without any performance degradation, and the network administrator did not know what was going on until he accidentally discovered it.

The * * described in the above paragraph may use UDP port 80 for two main reasons:

UDP allows the client to send large packets without completing the TCP handshake. Because stateful firewalls are normal, large TCP packets will not pass until the handshake is completed successfully, which limits the effectiveness of DDoS.

Users who use export filtering technology are usually too tolerant, allowing only TCP and UDP that need TCP, just like HTTP.

These types of * * are usually initiated from an infected Web server. If there is a broad open egress rule set, traffic will flow to the Internet and may overflow the state table on the firewall, resulting in a loss of bandwidth usage and / or reducing all performance of Internet connections.

Outbound SMTP is another example. Only SMTP (TCP port 25) is allowed to leave any network of the mail server. Or, if the mail server is externally hosted, only internal systems are allowed to communicate with specific external systems on TCP port 25. This prevents every other system in the local network from being used as a spam robot because their SMTP traffic will be discarded. Many mail providers have switched to authentication submissions for clients that only use TCP port 587, so clients do not need to access port 25. This is a good way to limit spam, and it also prevents adding the network to the entire Internet, which will prevent the site from sending legitimate e-mail messages to more mail servers. This may also prevent the site's ISP from shutting down its Internet connection due to abuse.

The ideal solution is to prevent these types of things from happening in the first place, but exit filtering provides another way, and if other measures fail, export filtering can help impose restrictions.

Prevent compromise

Exit filtering can prevent compromises in some cases. Some vulnerabilities and worms require outbound access to succeed. An older but good example is the code red worm that began in 2001. This vulnerability enables the affected system to execute an executable file and then execute it via TFTP (Trivial File Transfer Protocol, normal File transfer Protocol). Web servers almost certainly do not need to use the TFTP protocol, and blocking TFTP through egress filtering can prevent code red infection even on unpatched servers. To a large extent, this is only useful for stopping fully automated * and worms, because real human beings will find any loopholes in exit filtering and use it for their targets. Similarly, the right solution to prevent this problem is to fix network vulnerabilities used as media, but egress filtering can also help.

Restrict unauthorized application use

Many applications (such as × × clients, peer-to-peer software, instant messaging software, etc.) rely on atypical ports or protocols to run. Although more and more peer-to-peer and instant messaging applications jump ports until they find a port that is allowed to leave the local network, many ports are blocked by a restrictive set of egress rules, which is also an effective means of restricting more types of xxx connections.

Prevent IP spoofing

This is a common reason for using egress filtering, but pfSense automatically blocks fraudulent traffic through pf's anti-spoofing feature, so it doesn't apply here. Preventing IP spoofing means that malicious clients cannot send traffic with apparently forged source addresses.

Prevent the disclosure of information

Certain protocols are never allowed to leave the local network. Specific examples of such protocols vary from environment to environment, but some common examples are:

Microsoft RPC on TCP port 135 (remote procedure call)

NetBIOS on TCP and UDP ports 137to139

SMB / CIFS on TCP and UDP port 445 (server message block / generic Internet file system).

Stopping these protocols prevents information about the internal network from leaking to the Internet and prevents the local system from initiating authentication attempts with the Internet host. Because many worms rely on these protocols to run, these protocols also belong to the impact of limiting compromised systems discussed earlier. Other protocols that may be relevant are syslog,SNMP and SNMP traps. Restricting this traffic will prevent misconfigured network devices from sending logging and other potentially sensitive information to Internet. Instead of worrying about which protocols may leak information outside the local network and need to be blocked, the best practice is to allow only the required traffic.

The method of realizing exit filtering

On networks that have not historically used egress filtering, it is difficult to know what traffic is absolutely necessary. This section describes some methods for identifying traffic and implementing egress filtering.

Allow what you know, stop the rest, and work through the consequences

One way is to add firewall rules to the known required traffic that is allowed. Start by listing what you know you need, such as the egress traffic requirements in the following table.

Requires egress traffic description source destination port HTTP and HTTPS from all hostsLAN NetworkAnyTCP 80 and 443SMTP from mail serverMail ServerAnyTCP 25DNS queries from internal DNS serversDNS ServersAnyTCP and UDP 53

After making the list, configure the firewall rule to pass only that traffic and let all others hit the default deny rule.

Record traffic and analysis log

Another way is to enable logging for all delivery rules and send the logs to the Syslog server. The Syslog server can analyze the logs to see which traffic is leaving the network. PfSense uses a custom log format, so you usually need to parse the log through a custom script, unless the server has some knowledge of the pfSense filter log format. The analysis of the logs will help you build the required rule set to better understand the traffic needed on the local network.

Brief introduction of Firewall rules

This section provides an introduction and overview of the firewall rules page in Firewall > Rule policies. This page lists the initiated WAN rule sets, and by default, if these options are activated on the WAN interface, there are no other entries to block private and Block bogon networks by default, as shown in the following figure.

Prompt

Click Block Private Network or Block bogon Network rules to the right to go to the WAN interface configuration page where these options are enabled or disabled.

Default WAN rule

Click the LAN tab to view the LAN rules. By default, the only entries are any rules that allow LAN to be IPv4 and IPv6 by default, as shown in the following figure, and anti-locking rules if active. The anti-locking rule is designed to prevent administrators from accidentally locking themselves out of the GUI. Click next to the anti-lock rule to access the page where the rule is disabled.

Referenc

For more information about how anti-locking rules work and how to disable rules, see Anti-locking rules and Anti-locking.

Default LAN rule

To display rules for other interfaces, click their respective tabs. The OPT interface will appear under its descriptive name, so if the OPT1 interface is renamed to DMZ, its regular tab will also represent DMZ.

To the left of each rule is an indicator icon that shows the action of the rule: pass (), block (), or reject (). If logging is enabled for the rule, it is displayed in the same area. If the rule has any advanced options enabled, the icon is also displayed. Hover over any of these icons and text explaining their meaning will be displayed. For disabled rules, the same icon is displayed, but the icons and rules are lighter in color.

Add Firewall Rul

"to add a rule to the top of the list, click add."

To add a rule to the bottom of the list, click add.

To make a new rule similar to the existing rule, click to the right of the existing rule. The edit page displays pre-filled existing rule settings that can be adjusted at any time. When you copy an existing rule, the new rule is added directly below the original rule.

Edit Firewall Rule

To edit a firewall rule, click to the right of the rule, or double-click anywhere on the line.

The edit page for the rule is loaded and can be edited.

Mobile firewall rules

Rules can be reordered in two different ways: drag and drop and use Select and Click.

Move the rule using the drag-and-drop method:

Move the mouse over the firewall rule, the cursor will change and the prompt can be moved

Click and hold the mouse button

Drag the mouse to the desired location

Release the mouse button

Click Save to store the new rule order

Warning

Trying to leave the page after moving the rule, but before saving the rule, causes an error in the browser to confirm whether to exit the page. If the browser leaves the page without saving, the rule will remain in its original location.

To move rules in the list by group, select them first, using the check-and-click method:

Check the box next to the left side of the rule you want to move, or click the rule. When you select a rule, it changes the color.

Click where you want the rule to move.

Prompt

Hold down the shift key and click on the mouse to move the rule below the selected rule instead of above.

When you move a rule using the Select and Click method, the new rule is automatically stored.

Delete firewall rules

To delete a single rule, click to the right of the rule. The firewall displays a confirmation prompt before deleting the rule.

To delete multiple rules, check the box at the beginning of the line that should be deleted, and then click the delete button at the bottom of the list. Rules can also be selected by clicking anywhere on their line.

Disable or enable firewall rules

Disable the rule and click to the right of the rule. The appearance of the icon changes to a lighter shadow to indicate that it is disabled and the icon becomes.

To enable a previously disabled rule, click to the right of the rule. The appearance of the rule will return to normal, and the enable / disable icon will return to its original state.

You can also disable or enable a rule by editing the rule and switching the disable check box.

Rule delimiter

A firewall rule delimiter is a colored bar in a rule set that contains a small piece of text, and it does nothing to do anything about network traffic. They are useful for visually separating or adding comments to special parts of a rule set. The following figure shows an example of a firewall rule separator that shows how to use these rules to group and record rule sets.

Example of firewall rule delimiter

Create a new firewall rule delimiter:

Open the firewall rule tab where the rule delimiter is located

Click to add a delimiter

Enter the description text for the rule delimiter

Select the color of the rule separator by clicking the desired color icon

Click and drag the rule delimiter to its new location

Click to save the rule delimiter content

Click Save at the bottom of the rule list

To move the rule delimiter:

Open the firewall rules tab that contains the rule delimiter

Click and drag the rule delimiter to its new location

Click Save at the bottom of the rule list

To delete a rule delimiter:

Open the firewall rules tab that contains the rule delimiter

Click inside the rule delimiter on the right

Click Save at the bottom of the rule list

The firewall rule delimiter cannot be edited. If you need to change the text or color, create a new firewall rule delimiter and delete the existing entry.

Tracking firewall rule application

When you create or update a rule, the firewall records the user's login, IP address, and timestamp on the rule to track who added and / or last changed the rule. If the firewall automatically creates the rule, it will also be logged. This is done for firewall rules and port forwarding and outbound NAT rules. As shown in the following figure, in the firewall rule timestamp, you can see it when you edit the firewall rule at the bottom of the rules page.

Firewall rule timestamp

Alias

An alias defines a group port, host, or network. Aliases can be referenced by firewall rules, port forwarding, outbound NAT rules, and other locations in the firewall GUI. Using aliases helps reduce administrative effort and create a more manageable rule set.

Be careful

Do not confuse firewall aliases with interface IP aliases, which are a means of adding additional IP addresses to network interfaces.

Basic knowledge of aliases

Aliases are located in Firewall > Alias Management. The page is divided into different types of alias tags: IP, Port, URL, and all tabs. When you create an alias, add it to any tab and classify it to the correct location according to the selected type.

You can create the following types of aliases:

Host: alias network containing a single IP address or hostname: network with CIDR mask, hostname, IP address range, or alias port for a single IP address: these aliases contain a list of TCP or UDP port numbers or port ranges URL: built from files in the specified URL, but read only once, and then become normal network or port type aliases URL table: built from files at the specified URL But update by periodically getting a list from URL

We will describe each alias type in more detail in this section.

Nested alias

Most aliases can be nested within other aliases, as long as they are of the same type. For example, an alias can nest an alias that contains a Web server, an alias that contains a mail server, and a server alias that contains Web and mail server aliases, all of which are concentrated in a larger Servers alias. Note here that URL table aliases cannot be nested.

Use hostname in alias

The host name can also be used as an alias. Any hostname can be entered into a host or network alias and will be resolved and updated periodically by the firewall. If the host name returns more than one IP address, all returned IP addresses are added to the alias. This is useful for tracking dynamic DNS entries to allow specific users to translate from dynamic IP addresses to services.

Be careful

This feature is of no use in allowing or forbidding users to access large public websites. Large and busy sites tend to have constant rotation or random responses to DNS queries, so the contents of aliases do not necessarily match the responses that users receive when they try to resolve the same site name. It can be applied to small sites with only a small number of servers and does not include an incomplete set of addresses in its DNS response.

Mix IPv4 and IPv6 addresses in aliases

IPv4 and IPv6 addresses can be mixed within aliases. When aliases are referenced in a particular rule, the firewall uses the appropriate type of address.

Alias size problem

The total size of all tables must be roughly half of the firewall's largest table entry, with a default value of 200000. If the maximum number of table items is not sufficient to contain all entries, the rule may not load. For information about changing this value, see Firewall maximum Table entry. Because of the way aliases are loaded and reloaded, aliases must be placed twice in the total area; the new list is loaded with the old list, and then the old list is deleted.

If the firewall contains enough RAM to save the entry, you can increase this value as needed. The usage of RAM is similar to but smaller than the state table, but it is assumed that the 1K footprint of each entry is conservative and safe.

Configure alias

Add an alias:

Navigate to Firewall > alias Management

Click add

Enter the name of the alias, which may contain only the characters AmurzMagi 0-9 and _.

Enter a description of the alias

Select the type of alias.

Enter type-specific information as needed. Each type has a data field and a description field for each entry. To add a new member to the alias, click add at the bottom of the list of entries. To remove a member from an alias, click Delete at the end of the row.

When the alias is complete, click Save to store the alias contents.

Each manually entered alias is limited to 5000 members, but some browsers can only display 3000 entries. For a large number of entries, use URL table type aliases that can handle large lists.

Host alias

The host type alias contains the IP address group. The following figure example host alias shows a host type alias used to contain a list of public Web servers.

Example of a host alias

Other host type aliases can be nested within this entry. As mentioned earlier, the hostname can also be used as an entry.

Network alias

The network type alias contains a netgroup or IP address range. A single host can also be included in a network alias by selecting a / 32 netmask for the IPv4 address or a / 128 prefix length for the IPv6 address. The following figure shows an example of a network alias used later in this chapter.

Example of a network alias

Other hosts or network aliases can be nested within this entry. As mentioned earlier, the hostname can also be used as an entry.

When an alias entry contains an IPv4 scope, the firewall automatically converts it to an equivalent collection of IPv4 CIDR networks, which will fully contain the specified scope. As shown in the following figure, when you save the alias, the specified range automatically expands and the resulting list of IPv4 CIDR networks exactly matches the requested range.

Example IP Range Before

Example of IP range

Port alias

Port type aliases contain ports and port range groups. The protocol is not specified in the alias; the firewall rule using the alias defines the protocol as TCP,UDP or both. The following figure shows an example of a port type alias.

Port alias exampl

Enter an alias for another port type in the Port field to nest other port type aliases within this alias.

URL alias

Using the URL type alias, set the URL to the text file that contains the list of items. You can enter multiple URL. When you click Save, up to 3000 entries from each URL are read from the file and imported into the network type alias.

If you select URL (IP), the URL must contain IP addresses or CIDR-masked network entries, and the firewall creates a network type alias from the content.

If you select URL (port), the URL must contain only the port number or range, and the firewall creates a port type alias from the content.

URL alias

The behavior of URL table aliases is significantly different from that of URL aliases. For beginners, it does not import the contents of the file into normal aliases. It downloads the contents of the file to a specific location on the firewall and uses the contents of so-called persistence tables (also known as file-based aliases). The full contents of the alias cannot be edited directly in GUI, but can be viewed in the table viewer.

For URL table aliases, after the update cycle is set, the alias content is updated overnight by the script that retrieves the data.

URL table aliases can be quite large and contain thousands of entries. Some customers use them to keep lists of all IP blocks in a particular country or region, which can easily have more than 40, 000 entries. The pfBlocker plug-in uses this alias when dealing with country lists and other similar behaviors.

Note: URL table aliases cannot be nested.

If you select the URL table (IP), the URL must contain a network entry for the IP address or CIDR mask, and the firewall creates a network type alias based on the content.

If you select the URL table (port), the URL must contain only the port number or range, and the firewall creates a port type alias from the content.

Bulk import network aliases

Another way to import multiple entries into aliases is to use the bulk import feature.

Use the import feature:

Navigate to Firewall > alias Management

Click Import

Fill in the alias and description

Enter the alias content into the alias to import the text area, one entry per line.

Click Save

Examples of common uses of this page include IP addresses, networks, and blacklist lists. The list may contain IP addresses, CIDR blocked networks, IP ranges, or port numbers. The firewall will attempt to automatically determine the destination alias type.

The firewall imports the project into a normal alias that can be edited later.

Use aliases

When a letter is entered into an input box that supports aliases, a list of matching aliases is displayed. Select the desired alias from the list, or type its name completely.

Be careful

Alias autocompletion is case-insensitive, but is limited by type. For example, a network or host type alias is listed in the autocomplete of the network field, but the port alias is not; the port alias can be used in the port field, but the network alias is not in the list.

As shown in the following figure, use the WebServers alias in the destination field when adding or editing firewall rules.

Edit Firewall Rule

Select a single host or alias

Then type the first letter of the desired alias: enter W and display the alias as shown.

Automatically complete host alias

As shown in the following figure, the configured port alias is automatically completed. If more than one alias matches the letter entered, all aliases of the corresponding type are listed. Click the desired alias to select it.

Autocomplete port alias

As shown in the following figure, the rules created using Web Servers and WebPorts aliases are shown. This rule is located on WAN and allows any source to access the IP address defined in the WebPorts alias when using the port defined in the Web Servers alias.

Sample rules for using aliases

Hover the mouse cursor over an alias on the Firewall > Rule Policy page, and a prompt displays the contents of the alias and the description contained in the alias. As shown in the following figure, one hover displays the contents of the host and one hovers the contents of the port alias.

Hover to display host content

Hover to display port content

Firewall rule configuration example

This section provides a general example of firewall rule configuration.

Reject by default

There are two basic principles of computer security related to access control: default allow and default deny. The default deny policy for firewall rules is a best practice. Firewall administrators should configure rules to allow only the minimum required traffic to meet the needs of the network and cause the remaining traffic to decline with the default deny rules built into pfSense. As you can imagine, the number of rejected rules in the rule set will be the minimum.

In the default dual-interface LAN and WAN configuration, pfSense uses the default deny on WAN and the default permission on LAN. Everything inbound from the Internet is rejected, and everything from LAN to Internet is allowed. All family-level routers use this approach, as do all similar open source projects and most similar commercial products. This is what most people expect, so it is the default configuration. Although this is a convenient way to start, it is not the recommended long-term operation.

PfSense users often ask, "what bad thing should I stop?" But this is the wrong problem because it applies to methods that are allowed by default. The security professional Marcus Ranum noticed included a default license in his "six stupidest ideas for computer security" file, which is recommended by any security professional. Allow only what the network needs, and avoid leaving all rules on the LAN by default, and add blocking rules to prevent "bad things" on top of the allowed rules.

Keep it short.

The shorter the rule set, the easier it is to manage. Lengthy rule sets are difficult to manage, increase the chances of human error, are often too tolerant, and review is clearly more difficult. Use aliases to keep the rule set as short as possible.

View firewall rules

We recommend that you manually check the firewall rules and NAT configuration on a regular basis to ensure that they still meet the minimum requirements of the current network environment. The frequency of this inspection varies from environment to environment. In networks that are not frequently changed, only a small number of firewall administrators are usually sufficient on a quarterly or semi-annual basis. Check the configuration at least once a month for people in a rapidly changing environment or with poor change control, as well as multiple firewall visitors.

Usually when we review the rules with our customers, we ask for specific rules, and they say, "We deleted the server six months ago." If something else takes over the same internal IP address as the previous server, traffic will be allowed to access the new server, but this may not be intentional.

Document configuration

In all networks except the smallest, it may be difficult to recall where the configuration is and why. We always recommend using the description fields in the firewall and NAT rules to record the purpose of the rules. In larger or more complex deployments, create and maintain more detailed configuration documents that describe the entire pfSense configuration. When looking at the firewall configuration in the future, this will help determine which rules are necessary and why they are there. This also applies to any other area that is configured.

It is important to keep this document up to date. When performing periodic configuration reviews, also review this document to ensure that it is up-to-date with the current configuration. Be sure to update this document when you change the configuration.

Reduce log noise

By default, pfSense logs packets that are blocked by the default deny rule. This means that all noise blocked from the Internet will be recorded. Sometimes there is not much noise in the log, but in many environments, it is inevitable that something keeps sending spam messages.

On networks that use large broadcast domains-a common practice for wired ISP-this is usually NetBIOS broadcasting from people who lack clues, who connect the Windows machine directly to the broadband connection. In addition, these machines will continue to send broadcast requests for web browsing. ISP routing protocol packets may also be visible, or router redundancy protocols such as VRRP or HSRP. In a co-location environment such as a data center, there may be a combination of all these things.

Since the firewall has blocked 14 million NetBIOS broadcasts in the past day is of no value, and the noise may have masked important logs, it is a good idea to add blocking rules to the WAN interface to block noise traffic. By adding a blocking rule on the WAN interface that does not enable logging, the traffic will still be blocked, but the log will no longer be populated.

The rules shown in the following figure are configured on the test system on the internal LAN where "WAN" is behind the edge firewall. To eliminate log noise to view things of interest, we added this rule to prevent-but not record-anything about the destination of the broadcast address of the subnet.

Firewall rules that prevent recording broadcasts

We recommend adding similar rules to match the details of any log noise observed in the network environment. Under the system status > system Log, Firewall tab, check the firewall log, view the types of traffic blocked by the firewall, and see how often the log appears. If any particular traffic is recorded more than 5 times per minute and the traffic is not malicious or noteworthy, add blocking rules to it to reduce recording noise.

Log analysis

PfSense does not record any passing traffic, only all discarded traffic. This is the typical default behavior of almost all open source and commercial firewalls. This is most practical because recording all passing traffic is rarely needed, which only increases the load and the number of logging records. However, from a security point of view, this approach is somewhat retrogressive. Blocked traffic does not damage the network, so its log value is limited, and data through the interface may contain very important log information if the system is threatened. After eliminating any useless recording noise described in the previous section, the rest is valuable for trend analysis purposes. If it is observed that the number of logs is significantly more or less than the regular number of logs, the nature of the survey recording traffic may be better. OSSEC is an open source host-based detection system (IDS) that collects logs from pfSense through system logs and issues alerts based on logging anomalies.

Rule methodology

In pfSense, the rules on the interface tab are applied on each interface, always in the inbound direction of that interface. This means that traffic originating from LAN will be filtered using LAN interface rules. Filter traffic originating from Internet through WAN interface rules. Because all rules in pfSense are stateful by default, a state table entry is created when traffic matches the allowed rules. All reply traffic is automatically allowed by this status table entry.

Floating rules (floating rules) are an exception, and floating rules can act on any interface using inbound, outbound, or both directions. Outbound rules are never needed because filtering is applied in the inbound direction of each interface. In some limited cases, such as firewalls with many internal interfaces, setting floating rules can greatly reduce the number of firewall rules required. In this case, the egress rule of Internet traffic is applied as the outbound rule of the WAN to avoid copying the egress rule on each internal interface. The use of inbound and outbound filtering makes the configuration more complex and more prone to user errors, but may be required in specific applications.

Interface group

An interface group is a way to place rules on multiple interfaces at the same time. This can simplify some rule configuration if similar rules need to be done in the same way on many interfaces. Interface group rules, such as interface rules, are processed only in the inbound direction. Open × ×, L2TP and PPPoE server × × tabs are special interface groups that are automatically created behind the scenes.

For example, a group can be used for an interface collection that includes all LAN or DMZ type interfaces or a set of VLAN.

Be careful

The interface group is not valid in multiple WAN because the group rule does not handle the reply correctly. Because of this flaw, traffic that matches a group rule on a WAN that does not have a default gateway will exit from the WAN through the default gateway rather than through the interface it enters.

Rule processing order

So far, we have talked about how to handle rules on the interface tab, but there are three main types of rules: general interface rules, floating rules, and interface group rules (including × × tab rules). These types are processed in different order, and they are sorted as follows:

Floating rule

Interface group rules

Interface rules

Rules are sorted in this way in the actual rule set, and keep this in mind when making rules. For example, if an interface group contains a rule that blocks traffic, the rule cannot be overridden with an interface tab rule because the traffic has been processed by the first matching interface group rule in the rule set.

Processing firewall rules does not stop until a match is found, but if a packet does not match in the group rule, it can still be matched through the interface rule.

Another important place is to assign the Open × × interface. If there is a "allow all" rule on the Open × × tab, it will match the interface group rule. This means that the rules on the interface tab will not apply. This may be a problem. If the Open × × rule requires an answer, make sure that the traffic is exited through × ×.

Automatically add firewall rules

PfSense automatically adds internal firewall rules for a variety of reasons. This section describes the rules that are automatically added and their uses.

Anti-locking rule

To prevent administrators from being locked out of the Web interface, pfSense enables anti-lock rules by default. This can be configured on the system > Advanced Settings page. This automatically added rule allows traffic from any source in the network that contains the rule to listen on any firewall management protocol for LAN IP addresses. For example, it allows access to WebGUI's TCP port 443 TCP port 80 for GUI redirection and SSH-enabled port 22. If the WebGUI port has changed, the configured port is the port allowed by the anti-lock rule.

In a security-aware environment, it is a best practice to disable this rule and configure LAN rules so that only aliases of trusted hosts can access the management interface of the firewall. A better approach is not to allow access from the local area network, but only from isolated management networks.

Restrict access to the management interface from the local area network

First, configure firewall rules as needed to restrict access to the desired management interface. In the following figure, both SSH and HTTPS are used for management, so create a management port alias (management port alias) that contains these ports.

Alias for the management port

Then create an alias for the host and / or network that will have access to the management interface (see figure below).

Alias for the management host

The generated aliases are displayed in the list of drawing aliases.

Alias list

The LAN firewall rule must then be configured to allow access to previously defined hosts and deny all other access. There are many ways to do this, depending on the network environment and how egress filtering is handled. Here are two examples. The first allows DNS to query the IP address of the LAN, and this also allows the LAN host ping LAN IP address if the DNS parser or DNS transponder is enabled. Then deny all other traffic. The second example allows access to the management port from the management host, and then denies all other traffic to the management port. You can choose the most suitable management method. Remember that the source port is set to be different from the destination port.

Example restricted Management LAN rules

Backup example of restricted management LAN rules

Once the firewall rule is configured, disable the webGUI anti-lock rule on the system > Advanced Settings page. Check the box and click Save.

Be careful

If the management interface is no longer accessible after the anti-lock rule is disabled, the firewall rule is not configured properly. Re-enable the anti-lock rule by using the set Interface IP address option in the console menu, and then select reset LAN IP address. Set it to the current IP address and the rule will be automatically re-enabled.

Disable anti-locking rules

Anti-deception rule

PfSense uses the antispoof feature in pf to block fraudulent traffic. This provides the unicast reverse path forwarding (uRPF) feature defined in RFC3704. The firewall checks each packet against its routing table, and if the connection attempt comes from a source IP address on a non-resident interface on the network that is known to the firewall, it will be discarded. For example, a WAN packet with an internal network source IP address will be discarded. Any content initiated on the internal network will be discarded if the source IP address is not on the internal network.

Block private network

The Block Private Network option on the WAN interface automatically sets blocking rules for RFC 1918 subnets. Enable this option unless you are using dedicated IP space on WAN. This applies only to traffic initiated by the Wang side. It is still possible for local clients to reach hosts on the private network from inside the firewall. This option can be used for any interface, but is usually used only for WAN type interfaces. You can manually create a similar rule that blocks private networks on the interface by creating an alias that contains the RFC 1918 subnet and adding a firewall rule at the top of the interface rule to block traffic from sources that match that alias.

Block Bogon network

Bogon networks are networks that should never be seen on the Internet, including reserved and unallocated IP address space. The presence of traffic from these networks may indicate that fraudulent traffic or unused subnets are hijacked for malicious use. PfSense provides two bogons lists that are updated as needed, one for the IPv4 bogon network and one for the IPv6 bogon network. If Block bogon networking is enabled, the firewall gets the updated bogons list from files.pfsense.org on the first day of each month. The script runs at 3 a.m. local time. This list doesn't change very often, and the new IP address assignment has been removed from the mobile list a few months before it was actually used, so monthly updates are sufficient. If you must update the list more frequently, change the update frequency on the Firewall and NAT tab of system > Advanced Settings.

Be careful

The list of IPv6 is so large that if there is not enough memory in the system, or if the maximum number of table items is not sufficient to contain it, it may not be loaded.

Make sure that the firewall can resolve the DNS hostname, otherwise the update will fail. To ensure that the firewall parses the DNS, browse to system Diagnostics > DNS lookup, and then try to parse the files.pfsense.org. If possible, go to the system Diagnostics > Test port and try to connect to port 80 of files.pfsense.org, as shown in the following figure.

Test connectivity for Bogon updates

Force bogons updates

Because the bogon list changes relatively little, the monthly update of bogon is sufficient. However, manual bogon updates may occur, for example, bogon updates fail due to incorrect DNS configuration. In the system Diagnostics > table, perform the update through the firewall Web interface by selecting bogons or bogonsv6, and then clicking Update.

IPsec

When a site-to-site IPsec connection is enabled, a rule is automatically added to allow remote tunnel endpoint IP addresses to access UDP ports 500 and 4500, as well as the ESP protocol on the WAN IP address used for the connection. When IPsec for mobile clients is enabled, the same traffic is allowed, but from any source, not from a specific source address.

Because of the way policy routing works, any traffic that matches the rules of the specified gateway will be forced to Internet and bypass IPsec processing. The rules automatically add policy routes that cancel the flow of traffic to remote × × subnets, but they do not always have the desired effect. To disable the automatic negation rule, and add a firewall rule at the top of the rule on the internal interface to pass traffic to × × without a gateway set.

Referenc

Automatically added IPsec rules are discussed further in IPsec.

Default reject rule

Failure to comply with any user-defined rules or other automatically added rules will be rejected by default reject rules.

Firewall of pfSense book (2)

Translated from pfsense book!

2017-11-06

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.