Firewalld understanding, accept just one IP

kropex · 04-20-2020, 05:07 AM

Quote:

Originally Posted by ferrari

Correct.

I'm not sure if I understand you here. If you add source IP like this

Code:

firewall-cmd --zone=public --add-source=xxx.xxx.xxx.xxx

then packets coming from that address are handled by rules in the designated zone.

Refer
https://access.redhat.com/documentat...ding_on_source

I don't touch the public zone. I have my own zone "test" which is default,active, has the target DROP and my interface:eth0
So my example was for this zone not public, I added my ip to this zone as source. Why this zone let other IPs to go to ssh if other IPs are not in source? Where is the mistake, I already tested and does not work as I understood zone concept.

ferrari · 04-20-2020, 06:23 PM

Again, I encourage you to show us the working config as reported via iptables (for an agonstic view of the firewall state)...

Code:

iptables -S

kropex · 04-21-2020, 02:07 AM

Here below is my zone:

Code:

pcfslx (active)
  target: DROP
  icmp-block-inversion: no
  interfaces: eth0
  sources: 192.168.0.10
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

here below is the iptables:

Code:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N FORWARD_IN_ZONES
-N FORWARD_IN_ZONES_SOURCE
-N FORWARD_OUT_ZONES
-N FORWARD_OUT_ZONES_SOURCE
-N FORWARD_direct
-N FWDI_pcfslx
-N FWDI_pcfslx_allow
-N FWDI_pcfslx_deny
-N FWDI_pcfslx_log
-N FWDO_pcfslx
-N FWDO_pcfslx_allow
-N FWDO_pcfslx_deny
-N FWDO_pcfslx_log
-N INPUT_ZONES
-N INPUT_ZONES_SOURCE
-N INPUT_direct
-N IN_pcfslx
-N IN_pcfslx_allow
-N IN_pcfslx_deny
-N IN_pcfslx_log
-N OUTPUT_direct
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j INPUT_direct
-A INPUT -j INPUT_ZONES_SOURCE
-A INPUT -j INPUT_ZONES
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
-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
-A OUTPUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -j OUTPUT_direct
-A FORWARD_IN_ZONES -i eth0 -j FWDI_pcfslx
-A FORWARD_IN_ZONES -j FWDI_pcfslx
-A FORWARD_IN_ZONES_SOURCE -s 192.168.0.10/32 -j FWDI_pcfslx
-A FORWARD_OUT_ZONES -o eth0 -j FWDO_pcfslx
-A FORWARD_OUT_ZONES -j FWDO_pcfslx
-A FORWARD_OUT_ZONES_SOURCE -d 192.168.0.10/32 -j FWDO_pcfslx
-A FWDI_pcfslx -j FWDI_pcfslx_log
-A FWDI_pcfslx -j FWDI_pcfslx_deny
-A FWDI_pcfslx -j FWDI_pcfslx_allow
-A FWDI_pcfslx -j DROP
-A FWDO_pcfslx -j FWDO_pcfslx_log
-A FWDO_pcfslx -j FWDO_pcfslx_deny
-A FWDO_pcfslx -j FWDO_pcfslx_allow
-A FWDO_pcfslx -j DROP
-A INPUT_ZONES -i eth0 -j IN_pcfslx
-A INPUT_ZONES -j IN_pcfslx
-A INPUT_ZONES_SOURCE -s 192.168.0.10/32 -j IN_pcfslx
-A IN_pcfslx -j IN_pcfslx_log
-A IN_pcfslx -j IN_pcfslx_deny
-A IN_pcfslx -j IN_pcfslx_allow
-A IN_pcfslx -j DROP
-A IN_pcfslx_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW,UNTRACKED -j ACCEPT

I have no idea how much iptable will help to investigate this. My question was, if it's normal to have this behavior, I'm just trying to understand the deep concept of firewalld.

ferrari · 04-21-2020, 03:41 AM

Quote:

Why this zone let other IPs to go to ssh if other IPs are not in source? Where is the mistake, I already tested and does not work as I understood zone concept.

It is because the interface (eth0) is also part the zone you're using. I'm not a firewalld power user, and I don't generally tweak it beyond allowing particular services, so I haven't investigated its many fine-grained features. Suffice to say you can do a lot with firewalld. I assume that you're already digging in to the https://firewalld.org/documentation/

Note that they have mailing lists, that would probably give you the advanced support that you likely desire.

kropex · 04-21-2020, 10:04 AM

Quote:

Originally Posted by ferrari

It is because the interface (eth0) is also part the zone you're using.

it's hard to believe that the interface present into my default active zone is affecting the source, but I can't say that it's not true until I do the test. Until than I'm using rich-rule with success, but I remain curious how to use source too.