Trust an IP address with firewalld’s rich rules

Managing firewall rules with iptables can be tricky at times. The rule syntax itself isn’t terribly difficult but you can quickly run into problems if you don’t save your rules to persistent storage after you get your firewall configured. Things can also get out of hand quickly if you run a lot of different tables with jumps scattered through each.

Why FirewallD?

FirewallD’s goal is to make this process a bit easier by adding a daemon to the mix. You can send firewall adjustment requests to the daemon and it handles the iptables syntax for you. It can also write firewall configurations to disk. It’s especially useful on laptops since you can quickly jump between different firewall configurations based on the network you’re using. You might run a different set of firewall rules at a coffee shop than you would run at home.

Adding a trusted IP address to a device running firewalld requires the use of rich rules.

An example

Consider a situation where you have a server and you want to allow unrestricted connectivity to that server from a bastion or from your home internet connection. First off, determine your default zone (which is most likely “public” unless you’ve changed it to something else):

# firewall-cmd --get-default-zone

We will use as our example IP address. Let’s add the rich rule:

firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="" accept'

Let’s break down what we’re asking firewalld to do. We’re asking to allow IPv4 connectivity from to all ports on the server and we’re asking for that rule to be added to the public (default) zone. If you list the contents of your public zone, it should look like this:

# firewall-cmd --list-all --zone=public
public (default, active)
  interfaces: eth0
  services: dhcpv6-client mdns ssh
  masquerade: no
  rich rules:
	rule family="ipv4" source address="" accept

A response to Infoworld’s confusing article about Fedora

Working with the Fedora community is something I really enjoy in my spare time and I was baffled by a article I saw in Infoworld earlier last week. Here’s a link:

The article dives into the productization of Fedora 21 that hopes to deliver a better experience for workstation, server, and cloud users. The article suggests that Red Hat drove Fedora development and that the goals of Red Hat and Fedora are closely aligned.

That couldn’t be further from the truth.

I was heavily involved with the changes as a Fedora board member in 2013 and we had many lively discussions about which products should be offered, the use cases for each, and how development would proceed for each product. FESCo and the working groups trudged through the process and worked diligently to ensure that users and developers weren’t alienated by the process. It was impressive to see so many people from different countries, companies and skill levels come together and change the direction of the project into a more modern form.

Some of those board members, FESCo members, and working group members worked for Red Hat at the time. Based on the discussions, it was obvious to me that these community members wanted to make changes to improve the project based on their own personal desires. I never heard a mention of “Red Hat wants to do…” or “this doesn’t align with …” during any part of the process. It was entirely community driven.

Some projects and products from Fedora eventually make it into the Red Hat product list (Red Hat Atomic is an example) but that usually involves Red Hat bringing a community effort under their umbrella and adding formal processes so they can offer it to their customers (and support it).

Fedora’s community is vibrant, independent, and welcoming. If anyone is ever confused by the actions of the community, there are many great ways to join the community and learn more.

Test Fedora 21 at Rackspace with Ansible

Fedora Infinity Logo - Fedora 21Fedora 21 reached Alpha status last month and will reach beta status at the end of October. There are plenty of new features planned for the final release.

You can test Fedora 21 now using Rackspace’s Cloud Servers. I’ve assembled a small Ansible playbook that will automate the upgrade process from Fedora 20 to 21 and it takes around 7-9 minutes to complete.

The Ansible playbook is on GitHub along with instructions: ansible-rax-fedora21

Xen’s XSA-108 patch and Fedora

Xen LogoXen’s latest vulnerability, XSA-108, has generated a lot of buzz over the last week. Most of the attention has come from the reboot notifications from large cloud providers (including my employer).

The vulnerability allows a user within a guest to potentially read memory from another guest or the hypervisor itself. The window of available memory is small but it could be read many times over — much like how the Heartbleed vulnerability was exploited. In some situations, these actions could cause the guest or the hypervisor to crash.

The fix involves a small patch to the Xen hypervisor kernel. The patch is essentially a one-liner since the write operation was merely a no-op already.

Thanks to the efforts of Michael Young, new packages are in testing for Fedora 19, 20, and 21:

If you’d like to test these packages now, you can install koji and download the RPM’s directly:

yum -y install koji
koji download-build --arch=x86_64 xen-4.2.5-3.fc19  # For Fedora 19
koji download-build --arch=x86_64 xen-4.3.3-3.fc20  # For Fedora 20
koji download-build --arch=x86_64 xen-4.4.1-6.fc21  # For Fedora 21

Use yum or rpm to install the new packages. Some servers may need to install all of the downloaded RPM’s or only a portion of them. All of that depends on which Xen-related packages were installed already.

After testing, please leave karma in Bodhi on the appropriate package page.

Apache’s mod_proxy, mod_ssl, and BitTorrent Sync

Merging railway tracksBitTorrent Sync allows you to keep files synchronized between multiple computers or mobile devices. It’s a handy way to do backups, share files with friends, or automate the movement of data from device to device. It comes with a web frontend, called the Web UI, that allows for connections over HTTP or HTTPS.

Using HTTP across the internet to administer Sync seems totally absurd, so I decided to enable HTTPS. I quickly realized two things:

  • My SSL certificates were now specified in Apache and Sync
  • Sync’s Web UI is relatively slow with SSL enabled (especially over higher latency links)

I really wanted to keep things simple by wedging Sync into my existing Apache configuration using mod_proxy.  That was easier said than done since the Web UI has some hard-coded paths for certain assets, like CSS and Javascript.  After quite a bit of trial end error, this configuration works well:

  ProxyPass /btsync
  ProxyPassReverse /btsync
  ProxyHTMLURLMap /btsync
  Redirect permanent /gui /btsync/gui

The ProxyPass and ProxyPassReverse lines tell Apache where to proxy the requests and it also tells Apache to make requests on behalf of the browser making the request. The ProxyHTMLURLMap directive tells Apache that any requests to /btsync from a client browser should be translated as a request to the root directory (/) of the Web UI. The last line redirects hard-coded requests to /gui up to /btsync/gui instead.

When your configuration is in place, be sure to run a configuration check (httpd -S) and reload the Apache daemon. If you’d like to access your application at a different URI, just replace /btsync in the example configuration with that URI.

Once all this is done, I’m able to access Sync at and Apache handles all of the backend requests properly. On some distributions, you may find that mod_proxy_html isn’t installed by default. You’ll need to install it if you want to use ProxyHTMLURLMap in your configuration. For Fedora users, just install it via yum:

yum install mod_proxy_html

Photo: Old Vintage Railway by Viktor Hanacek