Firewalls: Rules? A Guide with Examples

Rules are meant to be broken… as long as it’s not my rules

Introduction

Previously, we’ve talked about what firewalls are and what types of firewalls exist. This time, I want to dig into what kinds of rules these firewalls have that make them work as the last post in my Firewall miniseries.

Basic Firewall Rules and Configurations

For some of these rules examples, I’m going to include one way to declare each rule using iptables, which is available as a very simple host-based firewall on Linux system. (The Wikipedia summary is that iptables is a user-space utility program that allows a system administrator to configure the IP packet filter rules of the Linux kernel firewall, implemented as different Netfilter modules). I chose to use examples this way because it is indicative of the general thought process that is used to create these kinds of rules, even if the syntax can vary. This isn’t an iptables tutorial and a total and proper implementation for each example might contain other commands, as well.

Other examples are more complicated and aren’t really suited for iptables and I give some simplified examples for other products in the marketplace that meet the challenge.

IP Address-Based Rules

• Example Rule: Deny all traffic from external IP 142.250.189.174 to any IP within the network.
• Use Case: This rule is useful when you want to block specific external threats known by their IP addresses.
• Simple Implementation: sudo iptables -A INPUT -s 142.250.189.174 -j DROP
• Implementation Explanation: sudo executes the command as a super user (Administrative permissions). iptables is the Linux command utility program. -A INPUT explains that this is a rule for inbound packets. -s 142.250.189.174 means that this rule applies to packets coming from the source (the -s) of 142.250.189.174. -j DROP means that the result will jump (-j) to the DROP action, meaning the packet will not be passed along to the rest of the system.

Port-Based Rules

• Example Rule: Allow TCP traffic only on port 443 (HTTPS).
• Use Case: Ideal for web servers that should only communicate via web traffic ports.
• Simple Implementation: sudo iptables -A INPUT -p tcp –dport 443 -j ACCEPT && sudo iptables -A OUTPUT -p tcp –dport 443 -j ACCEPT
• Implementation Explanation: We covered sudo iptables -A INPUT and -j ACCEPT above. The -p tcp means that this rule applies to the protocol (-p) of TCP and destination port (–dport) of 443. && just allows us to put two Linux commands in one line. Then the only difference in the second command is that we’re making a rule to allow outbound traffic as well as inbound traffic (-A OUTPUT).

Protocol-Specific Rules

• Example Rule: Allow ICMP (Internet Control Message Protocol) for internal network devices only.
• Use Case: Useful for allowing internal network testing and diagnostics while blocking potential external pings or other ICMP-based attacks.
• Simple Implementation: sudo iptables -A INPUT -s 192.168.1.0/24 -p icmp -j ACCEPT && iptables -A INPUT -p icmp -j DROP
• Implementation Explanation: In this case, our source (-s) is given as a subnet. You’d put whatever subnet represents your internal network (this is a shorthand way to represent every possible IP address that can exist on a network). The protocol (-p) is icmp and we will jump (-j) to ACCEPT. Again, we && to put two commands together and then create another rule that drops all other ICMP packets. It is important that these rules are included in this order or else the broad DROP will execute first before the limited ACCEPT rule is considered.

Stateful Inspection Rules

• Example Rule: Allow outgoing traffic on any port but restrict incoming traffic to responses to established connections only.
• Use Case: This is common for businesses that want to ensure outbound traffic is unobstructed while maintaining tight control over incoming requests.
• Simple Implementation: access-list YOUR_ACL_NAME extended permit tcp any any established
• Implementation Explanation: This rule is using a Cisco ASA, which has stateful firewall capabilities. In this case, this rule assumes you already have an access list (here represented by YOUR_ACL_NAME) and you address the access-list named YOUR_ACL_NAME and extended (rather than standard) will filter traffic on multiple criteria. In this case, we are allowing (permit) tcp traffic from any address to any address as long as it was already established.

Time-Based Rules

• Example Rule: Blocking all inbound traffic during non-business hours.
• Use Case: For organizations that want to limit access during off-hours for security purposes.
• Simple Implementation: It’s complicated 😉
• Implementation Explanation: There are a few ways to do this. One way is to run cron jobs (scheduled jobs) on your Linux server that add and remove iptables rules at the appropriate times. Other firewalls, like pfSense Plus and OPNsense make it easy through an interface. Here are the steps to do this in OPNsense:
  1. Define a Schedule: First, go to “Firewall” then “Schedules” in OPNsense. Create a new schedule and define the time periods (8 am to 5 pm) and the days of the week (Monday to Friday).
  2. Create Firewall Rule: Next, create a firewall rule under “Firewall” > “Rules” and select the interface where the rule should apply. Configure the rule to match your desired traffic (e.g., set the action to “Pass” for allowing traffic).
  3. Apply the Schedule to the Rule: In the rule settings, you will find an option to apply the schedule. Select the schedule you created in the first step.
  4. Activate and Test the Rule: After saving the rule, it will become active according to the schedule. It’s important to test the rule to ensure it behaves as expected during the specified times.

Configuring Your Firewall

Applying rules in a firewall is often very easy. You can see that the commands aren’t very long and UIs can make even complex rules creatable in a minute. However, defining and configuring your firewall rules correctly is very complicated. It is important that the rules are applied in the right order (“deny all traffic” needs to be the last rule applied, after the few approvals that you add for traffic you want, for instance). It is also important that your rules fit your business and your needs. Certain companies might need to allow traffic over port 22 (ssh). Some of those companies might allow free connections to the port, while others might “IP Whitelist” and only allow certain locations to connect. Other companies might allow the default RDP port of 3389, while other companies that have no Windows Servers would never need that port opened. The team defining these setups must understand the entire organization’s needs in order to lock the network down correctly. It is a razor’s edge: too strict and the company could not function effectively, too permissive and the company could be vulnerable to intrusion by threat actors. But here are the 30,000ft view of the steps that the team would undertake to configure a firewall.

1. Identifying Network Requirements: Understanding what services and traffic are necessary for your network.
2. Defining Clear Security Policies: Knowing what your organization’s security policies are in terms of what should be allowed or blocked.
3. Implementing and Testing Rules: Gradually implementing rules and testing them to ensure they don’t disrupt legitimate traffic.
4. Regular Updates and Monitoring: Keeping the firewall rules updated according to the evolving network needs and security landscape.

Whew, that’s a lot. If you’re new to this entire idea and reading this from a beginner’s point of view, I hope that I didn’t make this super confusing. I am hoping that by seeing these scenarios and beginning to “think in firewall logic” that you’ll begin to understand more fully the roles that firewalls play and how someone would begin to think about setting them up. It definitely has more in common with “who can come into my clubhouse?” than stupid scenes in movies where say ridiculous statements like “our firewall is at 19%”.