A conceptual firewall question

[taylorkh]

I have a CentOS 7 box with two NICs positioned between my DSL modem and my LAN. The firewall is configured with firewalld. It is quite simple. The Internet facing NIC/interface is in the "drop" zone - all packets (are supposed to be) dropped unless asked for by a process on the "good" side of the firewall. The LAN facing NIC/interface is in the "public" zone - ssh and vnc are open from the LAN side for administration of the CentOS box.

The firewall has three main chains - INPUT, FORWARD and OUTPUT. (firewalld created a whole bunch of sub-chains but that is a question for another day.)

I had attempted to prevent one PC on my LAN from accessing the Internet by blocking it from the CentOS box with a rich rule based on the IP Address of the PC. What I accomplished was to prevent the PC from accessing the CentOS box, not the Internet. I learned that I had blocked the PC with/on the INPUT chain, not the FORWARD chain. Using the iptables command I was able to block the PC with/on the FORWARD chain and thus prevent the PC from accessing the Internet.

From this experiment I learned:

1 - A block with the INPUT chain will stop a packet addressed to the firewall computer from accessing the firewall computer.
2 - A block with the INPUT chain will NOT stop a packet addressed somewhere on the far side of the firewall (e.g. the Internet). The packet says "I am just passing through" and the firewall lets it go through (via the FORWARD chain).

Here is the concept I am trying to get my head around...

An unsolicited packet arrives from the Internet side and is addressed to a device on the LAN side of the firewall. With the Internet facing NIC/interface being in the drop zone will the packet be dropped? It is after all "just passing through" as was the Internet bound packet from the "blocked" PC described above.

Thanks for any clarification.

Ken

[jlehtone]

Here is something to study:
https://gist.github.com/nerdalert/a1687ae4da1cc44a437d
https://www.digitalocean.com/community/ ... chitecture


The FORWARD (and subchains) ought to essentially have:
1. IF a reply, THEN let it through
2. IF new and going to "inet", THEN let it through
3. Reject the rest

[taylorkh]

Thanks jlehtone,

I like pictures Perhaps I can find one that will fit in my brain.

By "inet" do you mean Internet? If so, how does the chain know that? In my case a packet destined for my LAN is going to a private address. That would be a clue that the destination was NOT the Internet. Could there be an Internet address on BOTH sides of the firewall? I am trying to figure out a scenario where that would make sense. I will have to think on that.

The second link has some great background information. However, with firewalld, maintaining a simple firewall seems to be VERY simple. Trying to do something more granular... that seems to be somewhat problematic. I am reverse engineering firewalld by making a change and examining what it does to the output of netstat -r or iptables -L. For example, allowing https through the block zone (using the gui firewalld tool as the "simple minded" approach) I found a new entry in Chain IN_drop_allow to permit https to come in. I guess the naming convention means that this chain is the INPUT chain for the drop zone which collects allowed packets. I guess I need to make a diagram of firewalld chain relationships and tie it to the other diagrams you linked to.

Thanks again,

Ken

[jlehtone]

netstat is an older tool.

Name : net-tools
Summary : Basic networking tools
Description : The net-tools package contains basic networking tools,
: including ifconfig, netstat, route, and others.
: Most of them are obsolete. For replacement check iproute package.

ip and ss are not so old. For example:

Code: Select all

ip route show
ip -4 addr show
ss -tl

nmcli is yet younger.

Code: Select all

nmcli
nmcli con show

iptables -L does show things, but how about

Code: Select all

iptables --lin -vnL
iptables -S
iptables -t nat -S
iptables -t mangle -S

Filtering does not have to look at the address.

I have more or less default FORWARD:

Code: Select all

-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -j FORWARD_direct
-A FORWARD -j FORWARD_IN_ZONES_SOURCE
-A FORWARD -j FORWARD_IN_ZONES
-A FORWARD -j FORWARD_OUT_ZONES_SOURCE
-A FORWARD -j FORWARD_OUT_ZONES
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

Note how it starts with:

1. IF a reply, THEN let it through

and ends with:

3. Reject the rest

In between are some FORWARD_IN* and FORWARD_OUT*. They include

Code: Select all

-A FORWARD_IN_ZONES  -i eth0 -g FWDI_external
-A FORWARD_OUT_ZONES -o eth0 -g FWDO_external

Pay attention to the -i and -o options. A packet that travels the FORWARD knows the interface that it came in from and the interface that it will go out from.

Code: Select all

-A FWDO_external -j FWDO_external_allow
-A FWDO_external_allow -m conntrack --ctstate NEW -j ACCEPT

but FWDO_public* chains have no ACCEPTs.

There we have the

2. IF new and going to "inet", THEN let it through

IF packet is new and going out from network card that is in zone "external", THEN let it go.
A packet that would be routed out via a network card in the zone "public" does not have similar "ACCEPT".

[taylorkh]

Thanks again jlehtone.

I did not mean to say netstat. I have looked at that but not necessarily for this purpose. Your dissecting of the iptables output is very helpful. I need to explore more options of that command. I have been focusing on the -L option. Let me chew on all this and I will post back.

Ken