FirewallD

[Evil-I]

Hi All,

Read that FirewallD is making its first appearance in F17. Just realised that my fresh install from Live CD appears to have not installed FirewallD or offered the option (unless I was being very blind..) Now I have good old iptables and system-config-firewall but other elements of F17 seem to be looking for FirewallD.

An example is that whilst trying to get my new install to see a shared printer on my home server (Running F14) it throws an error message saying that FirewallD isn't running and seems incapable of finding any network printer devices.

What are my options? can I install FirewallD and then disable/ remove iptables and system-config-firewall?

If I do, is there a GUI for managing and configuring FirewallD?

Thanks for any advice,

E-I

[stevea]

firewalld was removed from the default install of F17.

Since the gui config tool was not available in time, the only way to change the firewall config was to manualy edit the (complex, undocumented) config files. The cli interface only allowed you to make temporary changes, lost after reboot.

[ddreggors]

Yes it was removed from F17 Final. I was lucky enough to have gotten it by default in the Beta release of F17.

[EDIT]
However you can install it still via yum or the software "Add/Remove" tool.
[/EDIT]

I know many are squeamish about command line tools and hand editing config files. I am a 20 year veteran of command line tools so I am not so quick to jump in to GUI based tools. I have seen one too many GUI tools foobar my configs in the past too.

With that said, IMHO the command line tool (firewall-cmd) is very straight forward:

  firewall-cmd --add --service=ipp-client
  firewall-cmd --list=all

This should temporarily add the needed ports in FirewallD for network printer protocols. If you also want to *share* printers you will need to add service ipp

  firewall-cmd --add --service=ipp
  firewall-cmd --list=all

Again this is a temporary change and will only remain until you restart FirewallD or reboot. You will need to edit the config files to make it permanent.

As to the config files, they are just xml which is very readable and if you follow the simple structure it can be easy to get a simplistic firewall up and running.

The default configs reside in:

/usr/lib/firewalld/

there are 3 directories under that one. The directories are "icmptypes", "services", and "zones".

You can easily understand what each folder holds if you are AT ALL familiar with firewalls.
The main configs that YOU (the admin user running as root) deal with live under:

/etc/firewalld/

It has the same folders (icmptypes, services, and zones), but they are all empty. The only file found in this directory tree is "firewalld.conf" and I bet you can guess what that's for.. It tells firewalld what "zone" config to load (among other things). The reason the directories are empty is so that you can copy the default icmptype/service/zone config files from "/usr/lib/firewalld" into "/etc/firewalld" under the correct location and OVERRIDE the default.


When you first look at "/etc/firewalld/firewalld.conf" you see that it is set to use the "public" zone.

It is advisable to leave it as public until you are more comfortable with zones and you are sure the zone does not need this level of protection!

Since there is no public.xml file under "/etc/firewalld/zones" firewalld looks to "/usr/lib/firewalld/zones" and finds "public.xml" and loads that zone definition.

To change that default definition you simply copy public.xml from "/usr/lib/firewalld/zones" to "/etc/firewalld/zones".

sudo cp -v /usr/lib/firewalld/zones/public.xml /etc/firewalld/zones/"

then edit it to add the ports or more simply the services you want to open.

The original:

<?xml version="1.0" encoding="utf-8"?>
<zone name="public">
  <short>Public</short>
  <description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
  <service name="ssh"/>
  <service name="dhcpv6-client"/>
</zone>

Now becomes:

<?xml version="1.0" encoding="utf-8"?>
<zone name="public">
  <short>Public</short>
  <description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
  <service name="ssh"/>
  <service name="ipp"/>
  <service name="ipp-client"/>
</zone>

and viola! You now have opened the ports for cups (client and server), and ssh You have also closed the dhcpd over ipv6 port as well!

Like wise if you find that you need to modify the ssh service config, namely if you have told ssh to run on another port besides 22, you will need to edit the ssh.xml service config.

Again, we don't want to modify the default config, we want to copy the correct config to our firewalld config tree under "/etc".

cp -v /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/

Now edit that file as needed:

Assuming you change the original port (22) to (222) to obscure it from brute force attempts.
The original:

<?xml version="1.0" encoding="utf-8"?>
<service name="ssh">
  <short>SSH</short>
  <description>Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.</description>
  <port protocol="tcp" port="22"/>
</service>

Now becomes:

<?xml version="1.0" encoding="utf-8"?>
<service name="ssh">
  <short>SSH</short>
  <description>Secure Shell (SSH) is a protocol for logging into and executing commands on remote machines. It provides secure encrypted communications. If you plan on accessing your machine remotely via SSH over a firewalled interface, enable this option. You need the openssh-server package installed for this option to be useful.</description>
  <port protocol="tcp" port="222"/>
</service>

and again it was that simple. You can use either of the commands below to load the changes

firewall-cmd --reload

systemctl reload firewalld.service

Note there are also other commands for systemct like "restart" and for firewall-cmd like "--complete-reload", but as previously stated in this thread, the documentation is a bit sparse currently so I am not sure exactly how "offline" these commands render firewall, even if only for a fraction of a second. With that said, the point of firewalld is to be able to reload changes WITHOUT dropping existing connections or blocking new connections for any amount of time so I recommend sticking with the simple "reload" for systemctl or firewall-cmd.

BTW, if you just want to TEST changes without editing the config, run the firewall-cmd to add a port or service to the running rules. This does not change the saved configs so a reload will revert your changes.

Example:

firewall-cmd --add --service=ssh

or:

firewall-cmd --add --port=8080/tcp

Hope that helps some of you out there!

[MotherDawg]

Finally...

Mr. ddreggors... AFAIK, your post IS the only comprehensive explanation of how to use this fantastic new firewall available on the net.

Thank You Very Much.

It is appalling that it came out with basically no manual. How the hell are we supposed to RTFM when there is none?

Until the power that be conjure one up, I'm putting a page together.
May I have your authorization to quote you... pretty much cut&paste the entire thing ?
LoLz

I already have another WIP on running TigerVNC with systemD on F17.
Planning to put it all together: TigerVNC and SSH through FirewallD on SystemD... a nice case of chops busting.

Again I thank you as it is now running and working.


UN*X is sexy!
who | grep -i blonde | date; cd ~; unzip; touch; strip; finger; mount; gasp; yes; uptime; umount; sleep

[ddreggors]

Thanks MotherDawg! I appreciate the kind words.

Certainly you may quote me, just please keep in mind that there may soon be better documentation. If I understand correctly, Fedora 18 should be released in December 2012 and should have FirewallD *with* GUI firewall tool. I would imagine that it will have better docs at that point as well.

Also, if you find cases where my words need correction or a bit more description please add that here as well. The more knowledge we can share and learn the better

[jpollard]

It also shows how clumsy XML is at doing things that were previously simple.

[DBelton]

I am still debating on the new firewalld.

So far, I haven't seen anything to suggest that it doesn't do as good a job as the old iptables, but I don't trust it fully, either.

And I too agree that xml is a clumsy way of doing things, especially when you look at it's track record of security flaws.

[pete_1967]

Originally Posted by DBelton

And I too agree that xml ..., especially when you look at it's track record of security flaws.

You do know that XML is markup language and all an XML document is is a plain text file don't you?

[jpollard]

Yes, he does.

And that doesn't prevent security problems due to the complex parsing of the file required. That complexity also translates into having to have "Yet Another Configuration Editor" to get the formatting right... and hope that version mismatch between editor, file, and processing (by firewalld) doesn't cause massive screwups.

[ddreggors]

I am not sure that an xml config introduces more chances of a security breach than the old iptables configs. An inexperienced admin/user can fat finger a rule in either. The big difference is that xml is quite a bit more readable for the mere mortal.

Personally it sounds like more of an unfounded rant because you don't like change, but time will tell I guess.

As to complex parsing... iptables configs are far more complex than xml. In fact almost every language has built in xml parsers yet none that I have seen handle iptables configs as easily as xml. Even perls "IPTables::Parse" is quite a headache to use.

I am not saying that FirewallD is the best or even that it will not be problematic, I just dislike seeing people discouraging use of a new application when they haven't even tried it themselves. At least wait until it is tested and found wanting before you spit on the project so openly please.

[pete_1967]

Originally Posted by jpollard

Yes, he does.

And that doesn't prevent security problems due to the complex parsing of the file required. That complexity also translates into having to have "Yet Another Configuration Editor" to get the formatting right... and hope that version mismatch between editor, file, and processing (by firewalld) doesn't cause massive screwups.

And that has nothing what so ever to do with the data and configuration file format, same errors can happen, and have happened, no matter what type of configuration files you use. Simply ridiculous to blame and claim that XML is the cause of the problem (not to mention saying that XML has "security flaws").

What comes to parsing errors, all you need is to provide DTD or Schema to ensure that the configuration is valid before the file gets even near the application using it. Lot simpler and safer than trying to code validator into your application itself. And of course, making that DTD or schema public, it becomes easy to ensure updates are applied immediately and anyone can easily verify it for issues. And if I want to use that configuration file in other application, or format, it is easy to do with XSL. Of course, all of these are standardised methods and techniques. Once done all that, I can pick and choose the XML parser for my language of choice and let that deal with the processing of the file instead of writing a custom parser to my application to deal with my custom configuration file format.

XML isn't solution to everything and you don't have to like it, or if you have hard time to understand it, fine, but don't spread FUD about it.

[jpollard]

You still haven't addressed the security problem when file/editor/server have mismatched versions, nor the complexity added to the editor/server that increases the likelyhood of both security errors, and general failures. In addition, all of this ends up having to run as root/privileged, which only makes errors worse.

The more complex you make the pluming the easier it is to stop it up.

[pete_1967]

Originally Posted by jpollard

You still haven't addressed the security problem when file/editor/server have mismatched versions, nor the complexity added to the editor/server that increases the likelyhood of both security errors, and general failures. In addition, all of this ends up having to run as root/privileged, which only makes errors worse.

The more complex you make the pluming the easier it is to stop it up.

And what exactly any of that has to do with XML?

[jpollard]

It is called "least privilege".

A parser is a complex item to get right - giving it privileges is stupid.

A simple parser is easier to get right - minimal software required means it is easier to verify.

XML, though very nice for providing inter-system translation, sucks big time for internal use. All it does is introduce additional bloat.

[pete_1967]

Originally Posted by jpollard

It is called "least privilege".

A parser is a complex item to get right - giving it privileges is stupid.

A simple parser is easier to get right - minimal software required means it is easier to verify.

XML, though very nice for providing inter-system translation, sucks big time for internal use. All it does is introduce additional bloat.

Not sure whether you don't understand a thing about software development or XML and life's too short to try to find out which, so I leave you with your delusions.