pfSense: Adding Firewall Rules to Filter Services
PfSense is an open source firewall, router and UTM (unified threat management) distribution based on FreeBSD. This is the third article in the series on pfSense, and it helps readers in designing and configuring firewall rules as per their requirements.
The first two articles in this series described the basic pfSense set-up, installation and configuration of the Squid Proxy server, SquidGuard proxy filter, and configuration of dual WAN failover. This article starts off from the point when pfSense has been configured, at the end of the second article. It then continues to configure the firewall to filter services – to allow internal computer systems to access required websites/IP addresses located in the Internet using permited services by configuring firewall rules. Please refer to the earlier articles to establish a firewall in dual WAN failover.
What is services filtering?
Many people view a firewall as a device to block access to undesirable websites, which is partially true. Emphasis must also be given to blocking requests from the internal network towards the Internet or external network, using undesirable services. This control is still not seen in many implementations.
For example, a firewall not configured to block undesirable services will not block malicious software such as viruses, worms, spyware, etc, from sending emails out using email services such as SMTP or from sending outgoing traffic using non-standard ports. This type of traffic could also lead to blacklisting of your static IP address.
It is crucial that services blocking is enabled along with website filtering to ensure correct firewall configuration.
The concept of the port
To explain it in simple terms, imagine a server connected to a single client by a crossover cable. This server is running three different services – HTTP, SSH and FTP. The client system is trying to access these services simultaneously using only one physical cable. This gives rise to two questions: 1. How does the server differentiate between the requests received from different clients? How does it determine which packet is for which service? 2. How does the client differentiate between the replies received from the server? How does it determine which packet is received as reply to which request sent earlier? The answer lies in the concept of a port – different services run on different ports. The HTTP service runs on Port 80, SSH on Port 22, FTP on Port 21, and so on. In all, there are 65,535 ports. While sending requests to the server, the client sends the IP address of the server as part of the IP header and the port number for the service as part of the TCP header. In addition, the client also sends the self IP address as the source IP address, and adds a randomly generated source port as the source port number. While replying, the server reverses the source and the destination IP addresses so that the packet reaches the client, and also reverses the source/destination port numbers for the client to understand which packet belongs to which service request. The handshake remains the same for multiple clients and servers. The source and destination IP addresses identify the client and the server, while the source and destination ports identify the service request and the reply. See Figure 1 for quick understanding. In firewall parlance, the terms ‘ports’ and ‘services’ are often used interchangeably, and mean the same thing. Please note that this explanation is only to simplify the concept of ports. You can refer to a more detailed explanation of the TCP/IP handshake on Wikipedia.
The firewall configuration scenario
Let us consider a typical requirement for a company, which would be to allow access depending on the work profile of employees. Let’s assume that there are three groups – admins, engineers and accountants with various access requirements.
The first step is to prepare a basic Access Control List (ACL), a sample of which is shown in Table 1. We will use this ACL to configure pfSense for this article.
Discussions should be held with all computer users to try and find all the services and websites being used by them, in order to create ACLs. Employees should be asked whether they use a specific website frequently or not. For instance, during such discussions, a website being used once in three months might get identified, which runs on a non-standard port 8080. In the example given in Table 1, it could belong to the Pune Municipal Corporation local body tax division.
Please discuss in detail with computer users and have the patience to create these lists. The more details you get, the fewer reconfiguration calls will be needed later.
Identify internal IP addresses, external IP addresses, external host names and services required for controlling access, etc. For example, for allowing Gmail access, we need to configure three groups: a. GmailServices Port alias group containing the following
TCP services (ports) required for Gmail access: IMAPS – 993 SMTPS – 465 POP3S – 993 Submission – 587 b. GmailServers IP alias group containing IP addresses for the following servers: smtp.gmail.com imap.gmail.com c. Group of internal systems required to access Gmail using the mail client. Think about how to group various internal/external IP addresses and services to create the minimum number of access rules. Create IP and ports alias lists from Firewall – Alias menus. Note: Planning before implementing rules is the best way – there are no shortcuts. Once the aliases are ready, go to Firewall – Rules – LAN and proceed to create the desired access rules as per the requirements already defined in Table 1.
From the Source dropdown box, select Single host or alias. Type the name of the predefined alias in the box in front – pfSense will auto display all matching aliases.
Since this firewall is configured with dual WAN, click on Display Advanced under Extra Options and select DualWAN Gateway.
Similarly, create the additional required rules to allow traffic from the source towards the destination by using Services. For example, to allow the computer from Admin group to access Gmail using a mail client, create the following rule: ct the pass rule with source as Admin group.
the destination with Gmail servers using Gmail services. the gateway and dual WAN to ensure this rule works with both the WAN interfaces. Knowledgeable readers may revisit ACL in Table 1 before reading further, to check if any rule is missing.
At the time of installation, pfSense configures a default rule, which allows all traffic from the LAN net towards any destination. Once all rules are configured, disable this default rule by clicking the √ button.
Note: A default anti lockout rule is configured to ensure admin access to the firewall from the internal network. Take care not to disable this rule, otherwise you wil be locked out of the firewall.
Diagnostics
Often, the implementer will stare at various inaccessible sites/ services after such rules are implemented. The best way to diagnose these issues is to browse Status – System Logs – Firewall.
All ‘blocked’ log entries will be seen on this page, ordered chronologically. The button can be used to filter the results based on the source IP address, destination IP address, etc.
Missing rule?
Readers may revisit the ACL in Table 1 before reading the next sentence.
Once configuration is implemented according to the ACL defined in Table 1, LAN users will not be able to ping the Internet or even the firewall itself, since ICMP packets are not allowed towards the firewall and towards the Internet. The importance of ICMP packets for troubleshooting cannot be emphasised enough. Here, two rules will be required to allow ping requests towards pfSense and towards external DNS servers, at the minimum. Note: To ensure correct documentation, update the ACL table first and then change the corresponding rule in the firewall.
An important configuration for accessing Gmail via the client
Readers will definitely notice that the imap.gmail.com and smtp.gmail.com IP addresses keep changing practically every time. Due to this, it is difficult to create a rule to allow outgoing traffic towards these domain names.
About using FQDN for the host alias, the pfSense website has the following caveat: “DNS names that use very low TTLs and change frequently, such as round robin entries, are not reasonable to use in this fashion. This means that large sites like google.com, which return a different set of IP addresses with each query, would not be viable in an alias.”
Thus, using various domain names such as smtp.gmail. com, imap.gmail.com, etc, as alias entries will not work
properly in setting firewall rules.
This can be overcome in two ways: 1. Search all Gmail IP addresses, and allow traffic on GmailServices towards all these IP addresses. This configuration will require considerable effort. 2. Configure Domain Override settings under DNS Resolver under Services to resolve smtp.gmail.com and imap.gmail. com to correct static IP addresses. Further, configure a rule to allow all traffic for GmailServices towards these IP addresses. Use the following steps: 1. Find the current IP address belonging to such FQDNs
by pinging them. 2. Configure the DNS resolver to resolve these URLs to
these IP address(es). 3. Use these IP addresses to configure groups and
firewall rules. 4. Ensure that all users use pfSense as their DNS server so that the IP address for overridden domains will resolve to the preconfigured IP address. Note that systems configured with DNS servers other than pfSense will get different IP addresses for these overridden domains and access will be blocked.
Managing firewall configuration changes
As a good change management practice, the following sequence should be observed: 1. Back up the firewall before making any changes – this will enable a rollback of settings if something goes wrong after the change. 2. Make changes in the documentation such as the ACL table
first – to ensure the documentation is up to date, always. 3. Make changes to firewall settings, ensuring comments for
created rules. Implement only documented rules. 4. Test the change to ensure it is giving only the desired
access. 5. Back up the firewall after the change is complete.
Following these steps will ensure correct and up-to-date documentation of implemented firewall rules, which will definitely help future firewall troubleshooting, reconfiguration and migration.
Interesting pfSense features related to firewall rules
pfSense provides easy addition of pass or drop rules by clicking the signs in the destination column. Once such a rule is created, do not forget to inspect this rule from Firewall – Rules – LAN, and change the default gateway as well as add a proper comment for easy identification at a later date.
Check logs of firewall rule changes from the menu Diagnostics – Backup and Restore. Here, details of changed rules can be checked by comparing the earlier rule and changed rule by selecting radio buttons corresponding to the required rules and clicking on them.
Latest available update
Please update pfSense to the latest new minor release version 2.3.1-RELEASE-p5 which was built on June 16, 2016. Details of new features and changes for this release are available at https://doc.pfsense.org/index.php/2.3.1_New_ Features_and_Changes#Update_5.