Translate an iptables rule to firewall-cmd

Issues related to configuring your network
taylorkh
Posts: 526
Joined: 2010/11/24 15:08:33
Location: North Carolina, USA

Translate an iptables rule to firewall-cmd

Post by taylorkh » 2019/12/25 16:09:23

I have a computer with two NICs. One is connected to my DSL modem and the second to my LAN. Using the NetworkManager applet I set the second NIC to "Shared to other computers" on the IPV4 tab. Presto a simple but effective gateway/router etc.

The Internet connection is in the DROP zone and the LAN connection is in the INTERNAL zone. I have pared down the INTERNAL zone to only allow ssh which I use to administer the machine. So far, so good.

I have a printer which seems to have the capability/tendency to "phone home." That I do not wish to allow. The printer has a static IP address set so it SHOULD be simple to block it at the firewall from accessing the Internet. I can add a rule with the iptables command which accomplishes this task and still allows the printer to be accessed on the LAN.

Code: Select all

 iptables -I FORWARD -s 10.42.0.13 -j DROP
This works as desired and I have also tested it with a computer. The blocked computer cannot access the Internet yet it still can connect to other computes on the LAN with ssh and it can be connected TO with ssh.

The question is... how do I accomplish this using firewall-cmd? I added a rich rule

Code: Select all

firewall-cmd --add-rich-rule='rule family="ipv4" source address="10.42.0.13" drop'
which would seem to do the same thing (at worst it would drop ALL traffic from the offending address) but it does not do anything that I can tell. What am I missing?

TIA,

Ken

User avatar
jlehtone
Posts: 2478
Joined: 2007/12/11 08:17:33
Location: Finland

Re: Translate an iptables rule to firewall-cmd

Post by jlehtone » 2019/12/25 21:16:09

Add that source to zone 'block'.

taylorkh
Posts: 526
Joined: 2010/11/24 15:08:33
Location: North Carolina, USA

Re: Translate an iptables rule to firewall-cmd

Post by taylorkh » 2019/12/25 21:31:42

Thanks jlehtone,

Let me reset my test machine and I will give it a try. However, I am only using the drop and internal zones (as far as I know.) And I have drop as my default zone. I will try specifying block and see what happens. If that does not do the trick I will try the other zones I am using and perhaps move the Internet NIC to block etc.

I will post back once I have some results.

Thanks again,

Ken

taylorkh
Posts: 526
Joined: 2010/11/24 15:08:33
Location: North Carolina, USA

Re: Translate an iptables rule to firewall-cmd

Post by taylorkh » 2019/12/25 23:42:50

I added the rich rule to --zone=block and found no effect. I also added it to ---zone=drop. Nothing. I finally added it to --zone=internal. The computer at 10.42.0.13 could still access the Internet. However, it could NOT ssh to the firewall computer at 10.42.0.1.

The iptables rule deals with the FORWARD chain which I suspect has to do with passing packets between the interfaces. Somehow that is the thing the rich rule needs to deal with I think. How? I have no idea.

Ken

User avatar
jlehtone
Posts: 2478
Joined: 2007/12/11 08:17:33
Location: Finland

Re: Translate an iptables rule to firewall-cmd

Post by jlehtone » 2019/12/26 09:12:32

No. No rich rules. Just:

Code: Select all

firewall-cmd [--permanent] --zone=block --add-source=10.42.0.13
That should add:

Code: Select all

# iptables -S | grep block
-N FWDI_block
-N FWDI_block_allow
-N FWDI_block_deny
-N FWDI_block_log
-N FWDO_block
-N FWDO_block_allow
-N FWDO_block_deny
-N FWDO_block_log
-N IN_block
-N IN_block_allow
-N IN_block_deny
-N IN_block_log
-A FORWARD_IN_ZONES_SOURCE -s 10.42.0.13/32 -j FWDI_block
-A FORWARD_OUT_ZONES_SOURCE -d 10.42.0.13/32 -j FWDO_block
-A FWDI_block -j FWDI_block_log
-A FWDI_block -j FWDI_block_deny
-A FWDI_block -j FWDI_block_allow
-A FWDI_block -j REJECT --reject-with icmp-host-prohibited
-A FWDO_block -j FWDO_block_log
-A FWDO_block -j FWDO_block_deny
-A FWDO_block -j FWDO_block_allow
-A FWDO_block -j REJECT --reject-with icmp-host-prohibited
-A INPUT_ZONES_SOURCE -s 10.42.0.13/32 -j IN_block
-A IN_block -j IN_block_log
-A IN_block -j IN_block_deny
-A IN_block -j IN_block_allow
-A IN_block -j REJECT --reject-with icmp-host-prohibited

taylorkh
Posts: 526
Joined: 2010/11/24 15:08:33
Location: North Carolina, USA

Re: Translate an iptables rule to firewall-cmd

Post by taylorkh » 2019/12/26 13:13:54

Thanks again jlehtone,

I removed the rich rules which I had been playing with and executed the command you provided. I see the same 3 entries related to the specified IP address

Code: Select all

root@t25-magic:~# iptables -S | grep "10.42.0.13"
-A FORWARD_IN_ZONES_SOURCE -s 10.42.0.13/32 -j FWDI_block
-A FORWARD_OUT_ZONES_SOURCE -d 10.42.0.13/32 -j FWDO_block
-A INPUT_ZONES_SOURCE -s 10.42.0.13/32 -j IN_block
However, all I seem to have done is to block the computer at that address from accessing the firewall computer with ssh for example. The computer at 10.42.0.13 can still ping an Internet address and connect with a web browser.

Ken

User avatar
jlehtone
Posts: 2478
Joined: 2007/12/11 08:17:33
Location: Finland

Re: Translate an iptables rule to firewall-cmd

Post by jlehtone » 2019/12/26 16:44:09

Netfilter has counters.

Code: Select all

iptables -vnL
shows the packet and byte counts for every rule.

If you store output, generate some traffic in 10.42.0.13 and store output again, then at least some of the increased counts are due to that traffic. Comparison of outputs should show, which rules have seen those packets.

taylorkh
Posts: 526
Joined: 2010/11/24 15:08:33
Location: North Carolina, USA

Re: Translate an iptables rule to firewall-cmd

Post by taylorkh » 2019/12/26 16:48:33

Great idea! Let me give that a try.

taylorkh
Posts: 526
Joined: 2010/11/24 15:08:33
Location: North Carolina, USA

Re: Translate an iptables rule to firewall-cmd

Post by taylorkh » 2019/12/26 21:26:45

Starting with a "clean" firewall - no rules or anything applied - I examined the initial traffic, browsed a couple of pages from the subject computer and then ssh from the subject computer to the firewall computer. It appears that the INPUT, FORWARD AND OUTPUT chains were all touched.

Code: Select all

Initial:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67
    4   326 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
 5053 5724K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

After 10.42.0.13 browsed Internet:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67
  212 16588 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
13205   14M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

After 10.42.0.13 ssh to firewall server:

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67
  212 16588 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
14879   15M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
   17  1238 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    6   640 INPUT_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    6   640 INPUT_ZONES_SOURCE  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    6   640 INPUT_ZONES  all  --  *      *       0.0.0.0/0            0.0.0.0/0           


Initial:
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot

After 10.42.0.13 browsed Internet:

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 7561 8208K ACCEPT     all  --  *      eth0    0.0.0.0/0            10.42.0.0/24         state RELATED,ESTABLISHED
 5338  495K ACCEPT     all  --  eth0   *       10.42.0.0/24         0.0.0.0/0           

After 10.42.0.13 ssh to firewall server:

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 7561 8208K ACCEPT     all  --  *      eth0    0.0.0.0/0            10.42.0.0/24         state RELATED,ESTABLISHED
 5339  495K ACCEPT     all  --  eth0   *       10.42.0.0/24         0.0.0.0/0           


Initial:

Chain OUTPUT (policy ACCEPT 3859 packets, 398K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 3859  398K OUTPUT_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

After 10.42.0.13 browsed Internet:

Chain OUTPUT (policy ACCEPT 10040 packets, 1270K bytes)
 pkts bytes target     prot opt in     out     source               destination         
10040 1270K OUTPUT_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

After 10.42.0.13 ssh to firewall server:

Chain OUTPUT (policy ACCEPT 12338 packets, 6377K bytes)
 pkts bytes target     prot opt in     out     source               destination         
12338 6377K OUTPUT_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
Zones are simple and I can visualize such a setup. Tables and chains I have some understanding of. How zones, tables, chains and the kernel routing table relate I will admit I can not picture in my mind. Using iptables to plug a rule into the FORWARD chain I can see would stop the traffic as I intend. As to firewall-cmd... I am not there yet.

Ken

User avatar
jlehtone
Posts: 2478
Joined: 2007/12/11 08:17:33
Location: Finland

Re: Translate an iptables rule to firewall-cmd

Post by jlehtone » 2019/12/27 10:49:49

taylorkh wrote:
2019/12/26 21:26:45
Zones are simple and I can visualize such a setup. Tables and chains I have some understanding of. How zones, tables, chains and the kernel routing table relate I will admit I can not picture in my mind. Using iptables to plug a rule into the FORWARD chain I can see would stop the traffic as I intend.
Firewalld is a front-end, an attempt to provide simpler user interface to the netfilter/nftables.
A single firewall-cmd command can create/modify multiple related rules in the netfilter.
Zones are one abstraction used by firewalld.


iptables (aka netfilter) and routing are far older. See Figure 3b in https://ebtables.netfilter.org/br_fw_ia/br_fw_ia.html

You admit that you don't understand iptables. (To convert from something that you don't understand into something new is the challenge.)


Let say a packet enters from LAN with router as destination.
There is no port-forwarding, so prerouting does not change the packet.
A routing decision is that the packet is for the router. It is directed to the INPUT filter.

Let say a packet enters from LAN with www.centos.com (a WAN address) as destination.
There is no port-forwarding, so prerouting does not change the packet.
A routing decision is that the packet is to be send out via WAN interface. It is directed to the FORWARD filter.
The FORWARD is set to allow (new) traffic from LAN to WAN.
POSTROUTING is set to masquerade (SNAT) outgoing traffic; the source address in the packet is rewritten to be router's external address.

A reply packet enters from WAN from www.centos.com and router as destination.
Within prerouting the NAT-engine rewrites the destination to be the LAN device that did send out the initial packet.
A routing decision is that the packet is to be send out via LAN interface. It is directed to the FORWARD filter.
The FORWARD is set to allow replies from WAN to LAN.
Postrouting does nothing.


A packet enters FORWARD chain. The chain is an ordered set of rules. Each rule has a match and target.
If packet matches a rule, it will go to the target (and counters for the rule update).

If target is a terminating action: ACCEPT, REJECT, DROP, then the packet's fate is corresponding and no further rules will be checked.
If target is an another chain, the packet will enter that chain. Therein might be a terminating action, or the packet might return to this chain.

An example:

Code: Select all

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination       
    6   640 INPUT_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    6   640 INPUT_ZONES_SOURCE  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
    6   640 INPUT_ZONES  all  --  *      *       0.0.0.0/0            0.0.0.0/0
* Six packets have entered the INPUT
* INPUT_direct matches all packets, so all 6 enter chain INPUT_direct
* nothing in INPUT_direct ends the chain traversal
* INPUT_ZONES_SOURCE matches all packets, so all 6 enter chain INPUT_ZONES_SOURCE
* nothing in INPUT_ZONES_SOURCE ends the chain traversal
* INPUT_ZONES all packets, so all 6 enter chain INPUT_ZONES
* We assume that INPUT_ZONES is the last rule
* Chain INPUT has seen 0 packets after the last rule
* Therefore, some rule in chain INPUT_ZONES (or in chains, where its rules send packets to) must have matched and actioned on all those 6 packets

We would have to look at the chain INPUT_ZONES to see what. More likely look at some more chains too.


Notice how INPUT_ZONES_SOURCE is before INPUT_ZONES?
When a zone has sources, packets from those sources traversing INPUT will enter the chains of that zone from INPUT_ZONES_SOURCES.
Zone should have terminating action by default. (The 'block' has REJECT.)
Therefore, no packets with that source address will ever reach the INPUT_ZONES chain, where packets enter a zone according to their in interface.

Both INPUT_ZONES_SOURCE and INPUT_ZONES can direct packets to same zone. Some due to their source address, some due to interface.
(RHEL 5 had one custom chain "RH-firewall..." and both INPUT and FORWARD did send packets to it. Reuse is good, but that was restrictive.)


The (sub)chains created by firewalld for FORWARD are similar.

Post Reply

Return to “CentOS 7 - Networking Support”