Understanding Firewall Rules: A Beginner's Guide

Think of a firewall as a security guard at the entrance of your network. Every piece of data trying to get in or out has to go through the firewall first. The firewall checks each packet of data against a set of rules you've configured, and based on those rules, it either lets the traffic through or blocks it.

Firewalls sit between your network and the outside world (like the internet), monitoring all incoming and outgoing traffic. They're your first line of defense against hackers, malware, and unauthorized access.

There are different types of firewalls:

• Hardware Firewalls – Physical devices (like your router) that protect your entire network.
• Software Firewalls – Programs installed on individual computers (like Windows Firewall or UFW on Linux).
• Network Firewalls – Enterprise-grade solutions that protect entire organizations.

Most home users rely on their router's built-in firewall plus a software firewall on each device. For servers and IT professionals, you're probably dealing with command-line firewalls like iptables, ufw, or netsh advfirewall.

Firewall rules are instructions that tell the firewall what to do with specific types of traffic. Each rule typically includes:

• Action – Allow, Deny, or Drop the traffic
• Direction – Inbound (coming in) or Outbound (going out)
• Protocol – TCP, UDP, ICMP, etc.
• Source – Where the traffic is coming from (IP address or range)
• Destination – Where the traffic is going (IP address or range)
• Port – Which port number is being used (like 80 for HTTP, 443 for HTTPS, 22 for SSH)

The Three Main Actions

When traffic hits your firewall, the rule can do one of three things:

• Allow – Let the traffic through. The connection is established.
• Deny – Block the traffic and send a rejection notice back to the sender. The sender knows they were blocked.
• Drop – Silently block the traffic without sending any response. The sender gets no feedback, making it harder for attackers to probe your network.

Most security experts recommend using Drop for blocking unwanted traffic because it doesn't reveal any information to potential attackers.

Rule Evaluation Order Matters

Here's something that trips up beginners: firewalls process rules in order from top to bottom. Once a rule matches, the firewall stops checking and applies that rule's action.

Example: If your first rule is "allow all traffic from anywhere," then every other rule below it becomes useless because all traffic will match that first rule and get allowed.

Default Policies: Allow vs Deny

Every firewall has a default policy that kicks in if traffic doesn't match any rule. There are two approaches:

• Default Allow – Allow everything unless explicitly blocked. Less secure, easier to manage.
• Default Deny – Block everything unless explicitly allowed. More secure, requires more setup.

For security-focused environments (servers, enterprise networks), Default Deny is the best practice. You only open the ports you need and block everything else.

When creating firewall rules, you'll often need to specify ports. Here are the most common ones:

When setting up a web server, you'd typically allow ports 80 and 443. For an SSH server, you'd allow port 22 (though many admins change this to a non-standard port to avoid automated attacks).

Let's look at some practical examples across different firewall systems.

Example 1: Allow SSH from Specific IP (Linux - UFW)

This rule allows SSH connections (port 22) only from IP address 192.168.1.100. Anyone else trying to SSH in will be blocked.

Example 2: Block All Traffic from an IP (Linux - iptables)

This rule drops (silently blocks) all incoming traffic from IP 203.0.113.50. Useful for blocking known attackers or malicious IPs.

Example 3: Allow HTTPS Traffic (Windows)

This Windows firewall rule allows incoming HTTPS traffic on port 443. Essential for web servers.

Example 4: Block Outbound Traffic to Specific Port (Linux - UFW)

This blocks outbound traffic on port 25 (SMTP email). Useful if you want to prevent a compromised server from sending spam emails.

Example 5: Allow Ping (ICMP) Traffic

This allows ping requests to reach your server. Some admins block ICMP to make their servers "invisible" to ping sweeps, but it can make troubleshooting harder.

1. Use Default Deny Policy

Start with a "block everything" approach and only open the ports you need. This minimizes your attack surface.

2. Limit SSH to Specific IPs

Don't expose SSH (port 22) to the entire internet. Restrict it to your office IP or VPN. This prevents brute-force attacks.

3. Use Non-Standard Ports When Possible

Attackers scan for services on well-known ports. Moving SSH from port 22 to something like 2222 won't stop a determined attacker, but it will filter out most automated scans.

4. Log Denied Connections

Enable logging for blocked traffic so you can see who's trying to access your system and from where. This helps you spot attack patterns.

5. Regularly Review Your Rules

Firewall rules tend to accumulate over time. Old rules for services you no longer use create unnecessary complexity. Audit your rules every few months.

6. Use Stateful Firewalls When Possible

Stateful firewalls track active connections and only allow return traffic for established sessions. This is more secure than stateless packet filtering.

7. Block by Default, Allow by Exception

This is the golden rule of firewall configuration. If you're unsure whether to allow something, block it. You can always open it later if needed.

8. Test Before Deploying

Always test firewall changes in a safe environment first. One misconfigured rule can take down your entire network or lock you out of critical systems.

1. Allowing All Traffic from "Trusted" Networks

Just because traffic is coming from your internal network doesn't mean it's safe. Compromised devices on your LAN can still attack other systems.

2. Forgetting About Outbound Rules

Most people focus on inbound traffic and ignore outbound. But outbound rules can prevent malware from communicating with command-and-control servers.

3. Using "Any" Too Often

Rules that use "any" for source, destination, or port are too broad. Be specific. The more granular your rules, the better your security.

4. Not Documenting Rules

Six months from now, you won't remember why you created that weird rule allowing port 8473 from a specific IP. Document your rules with comments explaining their purpose.

5. Disabling the Firewall to "Fix" a Problem

If something isn't working, don't just turn off the firewall. Figure out which rule is blocking it and adjust that specific rule. Disabling your firewall completely defeats the purpose.

Want to actually practice these concepts? Check out our interactive command simulators:

Firewalls are your first line of defense, but they're only as good as the rules you configure. A poorly configured firewall can be worse than no firewall at all because it gives you a false sense of security.

Start simple: block everything by default, allow only what you need, and document your decisions. As you get more comfortable, you can create more complex rules for specific scenarios.

And remember: security is about layers. A firewall is essential, but it should be part of a broader security strategy that includes strong passwords, regular updates, monitoring, and proper access controls.

Now go forth and lock down those networks.