0

I have been trying to convert a iptables settings to firewalld on a new server. The existing rule blocks ICMP except from a subset of IPs. Only people from our IT subnet (192.168.10.0/24) and our monitoring server (10.10.10.10) should be able to ping the server. In some cases additional servers would have additional IPs enabled to get a ping response.

iptables -I INPUT -p ICMP -j DROP
iptables -I INPUT -p ICMP -s 192.168.10.0/24 -j ACCEPT
iptables -I INPUT -p ICMP -s 10.10.10.10 -j ACCEPT
iptables -I INPUT -p ICMP -s N.N.N.N -j ACCEPT

Then when I try to apply similar rules, using firewalld rich rules, I am able to create a rule to allow either the IT subnet or the monitoring server, but not both. I appear to have the same problem as described in this question. I've seen several other pages with proposed solutions, but all have failed in one way or another. I've since reverted my test box back to defaults.

After I update this ICMP rule I will need to write a more restrictive SSH access lists, which allows a smaller subset of the IT range to access these machines. At this point adding the SSH rules in this process would have unexpected results.

rich rules:
    rule family="ipv4" source address="192.168.10.0/24" accept
    rule family="ipv4" source address="10.10.10.10" accept
    rule family="ipv4" source NOT address="192.168.10.0/24" drop

The results of these rules result with:

  1. Blocking all traffic, not just ICMP
  2. Without the "NOT address drop" line I can ping the server on devices I shouldn't be able to
  3. With the "NOT address drop" line I can not ping from my monitoring server at 10.10.10.10
  4. Adding the rules to iptables, using the commands above, does work but are deleted on a reboot

UPDATE 1 I've revisiting multi-Zone approach as recommended. The issue appears that my "ssh" people are being caught up with my ITsubnet zone. This is preventing them from SSH access.

# firewall-cmd --zone=ITsubnet --list-all
ITsubnet (active)
  target: default
  icmp-block-inversion: no
  interfaces:
  sources: 192.168.10.0/24
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

# firewall-cmd --zone=MonitoringSRV --list-all
MonitoringSRV (active)
  target: default
  icmp-block-inversion: no
  interfaces:
  sources: 10.10.10.10
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

# firewall-cmd --zone=SSH_Access --list-all
SSH_Access (active)
  target: default
  icmp-block-inversion: no
  interfaces:
  sources: 192.168.10.10
  services: ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

# firewall-cmd --zone=public --list-all
public (active)
  target: DROP
  icmp-block-inversion: no
  interfaces: eno16777984
  sources:
  services:
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

PS found this explainer which helped.

RunThor
  • 197
  • 2
  • 11
  • Stop using rich rules, create zones instead. – Michael Hampton Feb 14 '18 at 21:44
  • I tried using a few zone approaches, but in those cases there was still things which weren't working correctly. If you have a specific guide or example I would be interested in trying again as I read several times that rich-rules should be avoided. – RunThor Feb 14 '18 at 22:09
  • A zone is just a group of firewall rules applied to either a network interface, or a set of source addresses (which is what you want here). So, group together all the source addresses that will have the _same_ firewall rules, and make a zone with them. Repeat as necessary. – Michael Hampton Feb 14 '18 at 22:13
  • His iptables rules can't be correct. The `DROP` should be at the end. In that configuration, ALL the icmp packets are dropped at the first line without reaching next lines. – Alexis Nov 29 '19 at 01:40

1 Answers1

0

Commands used to make changes in UPDATE 1

firewall-cmd --permanent --new-zone=ITsubnet
firewall-cmd --permanent --new-zone=MonitoringSRV
firewall-cmd --permanent --new-zone=SSH_access
firewall-cmd --reload
firewall-cmd --permanent --zone=ITsubnet --add-source=192.168.10.0/24
firewall-cmd --permanent --zone=MonitoringSRV --add-source=10.10.10.10
firewall-cmd --permanent --zone=SSH_access --add-source=192.168.10.10
firewall-cmd --permanent --zone=public --remove-service=ssh
firewall-cmd --permanent --zone=SSH_access --add-service=ssh
firewall-cmd --permanent --zone=public --set-target=DROP
firewall-cmd --reload

Blocks all ssh access even from 192.168.10.10.

Commands used to make changes in UPDATE 2

Zone name appears to influence order so ITsubnet is processed before SSH_access. This is confirmed with:

iptables -S

or

iptables -vnL

So changing the zone name to get the more specific rule to process first fixes this issue.

firewall-cmd --permanent --delete-zone=SSH_Access
firewall-cmd --permanent --new-zone=A1_First010
firewall-cmd --permanent --zone=A1_First010 --add-source=192.168.10.10
firewall-cmd --permanent --zone=A1_First010 --add-service=ssh
RunThor
  • 197
  • 2
  • 11
  • 2
    You should not use `--permanent` in firewalld commands and then follow them up with `--reload`. This may cause it to be impossible to access your system if you make a mistake. You should instead leave off `--permanent` and use `--runtime-to-permanent` when the firewall rules are complete and correct. – Michael Hampton Feb 15 '18 at 18:24