Firewall Rules GUI, question about content

Networking
1

In the Firework rules page, under the list of rules, there is a table with three columns of values:

What does this table mean?

GREEN Internet (Allowed) ORANGE (Allowed) BLUE (Allowed)
ORANGE Internet (Allowed) GREEN (Blocked) BLUE (Blocked)
BLUE Internet (Allowed) ORANGE (Blocked) GREEN (Blocked)

Does it mean that the BLUE zone is “blocked” from sending traffic to the Green zone, but the Green Zone is allowed to send traffic to the BLUE zone? Where is this controlled, or is it a hardcoded default associated with the definitions of those zones?

image
image996×653 64.9 KB

2

I would go with hard-coded
Can make firewall rules to change dynamic if you wish.

3

I’m find the firewall rule setup very, very hard to understand.
On the Blue network, out of the box I can’t ping a machine on the Green network.
It has hosts 192.168.39.10 & 11 which will respond to PING.

So I make a rule
Source: Blue but nothing more specific
NAT on
Destination: 192.168.39.10
and now from 192.168.40.50 (Blue network) I can ping 192.168.39.10 and I can not ping 192.168.39.11
But if I change the destination in the rule to be 192.168.39.11 then I ping 39.11 but no longer 39.10

So the “destination” address is somehow relevant to the rule. Not only is it choose which hosts responds, but it is filtering according to the request.

Because I have a rule which sends port 443 traffic from the internet (red) to a host 192.168.39.15
but on the internet, the request is to the static IP address of my ISP, not 192.168.39.15
So in one case, the destination IP address seems to be affecting how the rule works, but in the case of RED to Green, the destination address is not relevant to selecting the rule. This does not make sense to me, unless it just behaves differently when the RED network is involved. I can’t find this explained or documented. It’s as if the HTTPS rule will take anything on port 443 and send it to 192.168.39.15 server. Fine. But then, why does the first rule not take any ssh request or any ping request and send it to the destination server? I

4

yes

the second you said, however you could change some aspect of the policy to make it more restrictive.

EDIT: to understand the logic behind the firewall, you need to think in term of trust minimization.

  • The green network has the highest level of trust because it operates over network cables (or it is assumed as such) and it is located inside a space that you control. Any danger from the green network comes from an unlikely break-in or the unintended consequence from the administrator actions (viruses, exploits, malware etc.).

  • On the other end, the blue network deserves much less trust, because it can be exploited remotely and also because it is assumed to be used by third parties, separated from the administrator control.

  • The orange network is the most trust minimized of the three because it is destined to host publicly accessible servers, which WILL be exploited, given enough time. When it happens, you do not want this exploit to affect for example your NAS in the green network with your most important personal files.

1 Like
5

Tim Richardson:

I’m finding the firewall rule setup very, very hard to understand.

It is indeed a complex topic with many nuances. It’s common to find it challenging initially.

On the Blue network, out of the box, I can’t ping a machine on the Green network.

By default, the blue network is quite restricted. To initiate communication, you will first need to allow the MAC address through, or remove the layer 2 block entirely. Following this, you can access the red interface and the firewall itself, though you might want to restrict access to the firewall to maintain a higher security level.

So I make a rule

Creating a rule essentially means opening a pinhole in the green network. The goal is to permit only necessary traffic, minimizing potential vulnerabilities.

But if I change the destination in the rule to be 192.168.39.11 then I can ping 39.11 but no longer 39.10

To allow communication with the entire network, set the destination to encompass the whole green network, rather than a specific IP. Or you can group all the IPs together, name the group and use that name in your rule.

So the “destination” address is somehow relevant to the rule. Not only does it choose which hosts respond, but it is filtering according to the request.

Indeed, rules can be defined based on various packet attributes including source, destination, and protocol, allowing for precise control over the network traffic.

Because I have a rule which sends port 443 traffic from the internet (red) to a host 192.168.39.15 but on the internet, the request is to the static IP address of my ISP, not 192.168.39.15

This is achieved through a mechanisms called Source Network Address Translation (SNAT) or IP masquerading, which allow multiple services on your LAN to operate behind a single public IP.

This does not make sense to me

I think you have a mental model that does not accurately map the design of the firewall, including the flexibility and broad capabilities of IPTables, the Linux firewall subsystem. It is designed to cater to a wide range of network configurations and requirements.

Fine. But then, why does the first rule not take any SSH request or any ping request and send it to the destination server?

Here, it is vital to differentiate between different protocols and ports. For instance, ping operates differently from TCP packets, and SSH utilizes different ports compared to HTTPS. Understanding these distinctions will enable you to set up rules that accurately reflect your network’s needs minimizing the surface of attach coming from Internet to your local network.

5 Likes
6

thank you for your patient answer. I am currently reading an O’Reilly book about firewalls, NAT and how they connect to routing. It is not as complicated as I thought, once I saw that each of these functions plays a strictly limited role in the pipeline of delivering a packet. It gets overwhelming if one conflates these different tasks into one black box, which is what I was doing. I was being lazy, I hoped I could get away with not understanding much about how it works. Once I understand it, I will map it back to IPFire.

IPFire, in my opinion, adds to the complexity by having predefined zones that have specific and different defaults, catering to assumptions that don’t fit my needs. For instance, wifi is an essential and integral part of my home and home office network, and does not match the segmentation baked in to the Blue vs Green zone defaults. And the Orange network , the third “inside” zone, is restricted in different ways… the DHCP server is arbitrarily excluded from it, so I wanted to use that zone for a guest vlan where the subnet has DHCP, it’s awkward. It would be nice to revert the three inside zones to a generic and equal setting, so users can build these zones to suit. Is this possible already?

7

I see things a bit differently. I would not scold your brain here, the genes you inherited from your ancestor, came to you in an unbroken line also thanks to the ability to asses the trade off in cost//benefit. Laziness is good because is a survival tool, if kept in check. And I will keep telling this story to my self until I believe it :grinning:

On the contrary, this is done to have a complete containment of the “radioactive zone”.

Unfortunately not. IPFire 3 will have the ability to define an arbitrary number of zones, with their own characteristics. Until then, you will need to use custom rules to modify the behavior of the firewall.

8

The most mind-bending part of the firewall was for me understanding how IPTables works. You have tables, you have chains and you have rules. What is the difference between chains in different tables? What is the order of rules application? How many circumstances exists where the order of rules is changed? If I print my entire IPTables, can I understand my firewall? Can I read it? All these things required a lot of effort to understand.