Description of problem: Seem not to be able to find documentation for very basic functional setup. Not all need are out facing internet DMZ type set ups. With iptables we were able to run firewalls on all systems and not block service between internal systems. Version-Release number of selected component (if applicable): firewalld-0.2.12-2.fc18.noarch.rpm How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: - How to define your internal network to accept connections between peer nodes? - How to add a new service, rsync? - How to make the above pernmanent - The configuration files are now XML where are the XSD files for validation? If you open an ssh port for roaming connection support you must protect as it will become target within seconds of opening the port to be hammered. If you want to dynamic add block rules it appears that you can do it with direct rules. But what if you would like them to persist across restart. We are looking to re-write an sshdfilter type function using firewalld when we have the knowledge of how to do this. Migration for this does not seem easily accomplished as iptables now no longer functions as before! Questions seem pretty basic how could we miss better documentation? Searching the internet has produced no hits for users defining how they are implementing even rudimentary functionality. The above basic needs are blocking us from moving to Fedora 18.
OK, adding an rsync service was easy, listed files in the firewalld RPM, copied one to /etc/firewalld/services/rsync.xml and changed it to the following, could have used the firewall GUI for this: <?xml version="1.0" encoding="utf-8"?> <service> <short>rsync</short> <description> Define service and port for rsync daemon service.</description> <port protocol="tcp" port="873"/> </service> After doing: firewall-cmd --direct --passthrough ipv4 -t filter --line-numbers --list Was surprised to see all the chains, including the ones for the zones not being used. It seems very wrong to have all the extra, I'm hoping unused, rules but we are doing the forensics to see if we can grasp the intent of this change. We are used to using a very simple set of rules which seemed to provide all the safety needed after the NAT router which does the port forward for a very small set of services. Below is our rule set. Note the SSHD chain which is used for dynamic drop rules added by the Perl script sshdfilter on root login attempts, ping ssh port, too many attempts, unknown user attempts. The internal network is 10.2.2.0 with a netmask of 255.255.255.0. We are not experts in this so we are looking for constructive help. # Generated by iptables-save v1.3.5 on Sat Nov 11 12:48:03 2006 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [569:82408] :RH-Firewall-1-DST - [0:0] :RH-Firewall-1-INPUT - [0:0] :SSHD - [0:0] -A INPUT -j RH-Firewall-1-INPUT -A INPUT -p tcp -m tcp --dport 22 -j SSHD -A FORWARD -j RH-Firewall-1-INPUT -A RH-Firewall-1-DST -d 224.0.0.0/240.0.0.0 -j DROP -A RH-Firewall-1-INPUT -i lo -j ACCEPT -A RH-Firewall-1-INPUT -s 172.16.0.0/255.240.0.0 -j DROP -A RH-Firewall-1-INPUT -s 192.168.0.0/255.255.0.0 -j DROP -A RH-Firewall-1-INPUT -s 224.0.0.0/240.0.0.0 -j DROP -A RH-Firewall-1-INPUT -s 240.0.0.0/248.0.0.0 -j DROP -A RH-Firewall-1-INPUT -s 0.0.0.0/255.0.0.0 -j DROP -A RH-Firewall-1-INPUT -d 255.255.255.255 -j DROP -A RH-Firewall-1-INPUT -s 169.254.0.0/255.255.0.0 -j DROP -A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT -A RH-Firewall-1-INPUT -s xxx.76.32.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -s xxx.76.64.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -s 10.2.2.0/255.255.255.0 -p tcp -m tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -p tcp -m tcp --dport 22 -j SSHD -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -s 10.2.2.0/255.255.255.0 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited COMMIT # Completed on Sat Nov 11 12:48:03 2006
(In reply to comment #0) > - How to define your internal network to accept connections between peer > nodes? Specifying source address/port is not yet supported. (bug #903222) > - The configuration files are now XML where are the XSD files for validation? We don't have any yet. > direct rules. But what if you would like them to persist across restart. That's not possible at the moment. (bug #815489) > Migration for this does not seem easily accomplished as iptables now no > longer functions as before! iptables (the tool as well as the service) should still work, you just need to disable firewalld service and enable iptables service. # systemctl stop firewalld.service # systemctl disable firewalld.service # systemctl start iptables.service # systemctl enable iptables.service # systemctl start ip6tables.service # systemctl enable ip6tables.service > Questions seem pretty basic how could we miss better documentation? All the documentation we have is https://fedoraproject.org/wiki/FirewallD and man pages: firewall-cmd(1), firewalld(1), firewalld.conf(5), firewalld.zones(5) firewalld.icmptype(5), firewalld.service(5), firewalld.zone(5) (In reply to comment #1) > Was surprised to see all the chains, including the ones for the zones not > being used. bug #907375 > Below is our rule set. Would you mind if I close this bug as duplicate of bug #903222 ? Because the impossibility of specifying source address seems to be the blocker here.
After reviewing the referenced bug reports please close this one as a duplicate. I did do a search before, but did not recognize the other reports by the summary titles.
Tried stopping, disabling firewalld.service and then starting and enabling iptables. Will not run. Just in case, we reverted the /etc/sysconfig/iptables file to the default, it still will not run. Even went through a reboot just incase something was fouled up, still no joy.
Fixed the issue, was not getting run as the start of the ypbind service was failing due to a misconfigured dhcp server. Talk about Murphy striking.
*** This bug has been marked as a duplicate of bug 903222 ***