This article documents how I'm currently building my firewalls. It
builds on
netfilter-based-port-knocking, and tries to
integrate several components of a firewall as gracefully as possible.
For some context: I'm getting involved with servers where the firewall
policy goes beyond a handful of SSH from my home and my other
servers rules. There are many different network streams that need to
be policed, some of them are common across several (potentially many)
servers, and so on. So I'm gradually giving up on my hand-made
scripts, and trying out higher-level tools. I settled on FWbuilder,
which seems nice. However, it only allows static policies, and I
still want to keep dynamic policies such as what
fail2ban provides,
as well as my own port-knocking system.
The problem I had was that
fail2ban isn't really made to play nice
as part of a complex firewalling setup, my port-knocking system was
too tightly integrated within my firewall script, and FWbuilder wasn't
too flexible when it came to delegating part of the firewall policy to
something external. Fortunately, this was only a perceived problem
(or a real problem in my understanding), because it is actually
possible to have all three blocks playing nicely together.
More context: as usual, I'm focusing on Debian-like systems. More
precisely, on those with a Linux kernel; it may be that FreeBSD's
firewalling subsystem has a feature comparable to Linux's
recent
module, but I don't know.
Let's start with FWbuilder. This is not the place for a manual, the
official documentation is rather complete. I'll assume you have
defined most relevant blocks in there: firewall, hosts, IP addresses,
services, and so on. You define your static policy with the
standard rules. From then on, we want to integrate the external tools
for dynamic rules.
Step 1: Integrating
fail2ban
We want
fail2ban to have its own playground, so that it doesn't
overwrite anything in the standard policy. The trick is to define a
new policy rule set named
fail2ban. Leave it empty in FWbuilder.
So far so good, but
fail2ban (the daemon) still operates on the
INPUT chain in the firewall, and could therefore still mangle the
static rules. Fortunately, starting with
fail2ban 0.8.5 (available
from Debian Wheezy, or in the backports for Squeeze), you can define
what chain to operate on: with a configuration item such as
chain =
fail2ban,
fail2ban (the daemon) will now only add its rules to
fail2ban (the firewall chain), and won't be able do damage the other
chains.
The missing part is to send some of the traffic to it using the
standard policy: i defined a rule sending the incoming SSH connections
to the
fail2ban policy ( branching in FWbuilder jargon).
Voil : the static policy delegates part of the decision-making to a
sub-policy controlled by the
fail2ban daemon.
Step 2: Integrating port-knocking
This is a bit trickier, but we'll use a similar method.
First, the traffic used for port-knocking needs to be directed to the
chain that does the listening. Define a policy rule set named
portknocking, and leave it empty in FWbuilder. It'll be used by the
dynamic rules to track progression of source IP addresses through the
port-knocking sequence, so you'll need to send ( branch ) incoming
traffic there, probably after the rules allowing incoming connections
from known hosts.
The dynamic part of this will only concern the refreshing of this
listening chain , which we assume will do its work and mark IP
addresses with
PK_ESTABLISHED once the sequence is completed. What we
do with these marked IP addresses will still be defined within the
FWbuilder policy.
We're going to need some complex rules since we want to filter
according to this
PK_ESTABLISHED bit
and according to destination
port, for instance; unfortunately FWbuilder doesn't allow combining
filter criteria with
and, so we define a new policy rule set called
accept_if_pk_ok. This ruleset has two rules: the second is an
ACCEPT and should be easy to understand. The first rule needs to
ensure the
ACCEPT is only reached for connections coming from
PK_ESTABLISHED addresses, so it's going to be a bit tricky.
- The service needs to be a custom service (I called it PK not
established ), since FWbuilder doesn't know about the marking
feature in
iptables. Use -m recent ! --rcheck --seconds 86400
--name PK_ESTABLISHED for the definition (change the duration to
the number of seconds the door should stay open after the
port-knocking sequence has been completed). Note the exclamation
mark.
- The action is also going to be custom, defined as
-j RETURN.
Again, this feature is iptables-specific and FWbuilder doesn't
provide any UI for it.
(Explanation: the first rule matches packets coming from IP addresses
not marked as
PK_ESTABLISHED, and returns them to the calling
policy. Packets remaining after this rule are those coming from the
appropriate addresses, and they go on to the
ACCEPT. We could have
had the first rule match on IP addresses that
are marked, and branch
to yet another ruleset with the
ACCEPT part, but that would make it
harder to read, I feel.)
Now let's get back to the main policy and add rules concerning what
kind of traffic we want to allow once the port-knocking sequence
completed. For instance, we define a rule matching on the SSH
service , where the action is to branch to
accept_if_pk_ok. When
an incoming packet tries to establish a connection to the SSH port,
it's passed to the
accept_if_pk_ok ruleset. If it comes from the
same IP as a recent port-knocking sequence, it goes on to be
ACCEPTed. If not, it returns to the main policy. Maybe static
rules further on will allow it to go through.
Step 3: tying it all together
Now that we have all the pieces, the rest is plumbing.
- Get FWbuilder to compile a script from the data. I called mine
$hostname.fw, and stored it into /usr/local/sbin.
- Write a
/usr/local/sbin/port-knocking script that operates on the
portknocking chain and manages the PK_ESTABLISHED bit. It need
not do more than what's described in
netfilter-based-port-knocking.
- Write an initialisation script that calls both
/usr/local/sbin/$hostname.fw and /usr/local/sbin/port-knocking.
I called mine /etc/init.d/firewall.
- Make sure that
fail2ban's initialisation script is called after
ours. Either with boot sequence numbers, or with the LSB dependency
pseudo-headers: I made my firewall script to Provides: iptables;
since fail2ban's script declares that it Should-Start: [ ]
iptables, we're fine.
- Run
/usr/local/sbin/port-knocking every hour, or as often as
needed to recalculate the port numbers.
With this setup, at boot time, the
$hostname.fw script creates the
static policy and the extra playgrounds; then the
port-knocking
script implements the listening for the magic sequence; then
fail2ban inserts its own rules. And there we are: three different
parts for the firewall policy, all integrating nicely. Mission
accomplished!
Note: (Mostly copy-and-pasted from the previous article) This
article is deliberately short on details and ready-to-run scripts.
Firstly because firewall scripts vary wildly so any script would have
to be adapted anyway, but mostly because security is best handled with
one's brain switched on. Fiddling with a firewall can easily open
gaping holes or lock everyone out. So please make sure you understand
what goes on before blindly pasting stuff into your own setup. Some
bits are left as an exercise to the reader.
Panama just underwent a nasty e-voting exercise: Electronic-mediated elections were held for the committee of the PRD party. It sounds simple - Even trivial! There were only 4100 authorized voters, it was geographically trivial (all set inside a stadium)... But it blew up in smoke. I won't reiterate all what happened, I'll rather direct you to our project's (the e-voting observatorium) page: News regarding Panama (for those coming from the future, search starting at 2012-08-27 and yes, it's all in Spanish, but there are free-as-in-beer translation services.
Many e-vote proponents/sellers/pushers were very eagerly waiting for this election to brag about one more success... So much that they could not just ignore it, and started rationalizing it away. Anyway, while feeding the observatorium, I came across this opinion-article in the Voto Digital website, which makes quite a bit of pro-e-voting noise. I replied to it, and I think my analysis is worth sharing also with you:
I've never really used facebook so it's not too hard for me to 
In late July, the 
Today, 
This module allows you to be notified via 
Here s a second post on the subject of 
Arundina Sans font from 
But for legacy fonts without OpenType features, it renders badly:
In addition, according to Behdad, PUA glyphs in legacy fonts are not supported yet. This means there will be regression on fonts designed for Windows XP or below. But modern fonts designed for Windows 7 should be fine.
Changes on Bugs
The engine replacement from scratch certainly affects existing bugs. Some become obsolete, some still remain. Here are the summary for Thai/Lao engine, as resolved upstream:
Closed bugs:
One can easily spot the dotted circle glitches. And here is how I workaround it, which is like how it's rendered on other terminals:
With the HarfBuzz replacement, here is how it renders:
That is, although it s still wrong, it s more tolerable. So, the question for users is: Could they tolerate this until VTE is redesigned for Indic scripts supports? 
Almost a year has passed since my talk at pgconf.eu 2011 in Amsterdam on
IT S FINALLY IN!
With this last upload of the MiniUPnP daemon 1.7-3, I ve reached a first milestone: all of the MiniUPnP libraries, daemons and clients are finally in Debian, in a shape which I am not ashamed anymore.
What is UPnP for?
Back in the days (around Linux 2.0.3x), the only way to share a single Internet connection was to run a Linux box as your gateway. These days are far gone, and nearly every home connection is done through a mini home router, which also often provides a small switch and a WiFi access point. Every computer on the LAN gets its connectivity through the router thanks to NAT, and to be more accurate, masquerading. That works very well for outbound connections (browse the web, send a mail, etc.), but it is then a lot harder that something connects to a server located in the LAN. If you run a permanent server with a fixed LAN IP address, that s fine, you just configure your router to do some port forwarding, so that any inbound connection will be forwarded to the computer of your choice in the LAN. But if one application needs to listen on the public IP address just for a while (for example, IRC using DCC connection), so that something can connect to it, it becomes a way more tricky. That s when UPnP comes into play. UPnP stands for Universal Plug and Play. It s a protocol so that any application on the LAN can open ports on the public IP address of the gateway. Note that an UPnP router is also often referenced as UPnP IGD (Internet Gateway Device).
Why using MiniUPnP, don t we have already linux-igd?
Before my packaging work, the only UPnP server that was available in Debian was linux-igd, which has a dependency on libupnpX. That library is quite big for what it does (about 500KiB, on top of which you have to install the 200KiB daemon itself), while MiniUPnP is designed to be lightweight (only 158K, with dependencies on iptables, iproute, uuid-runtime and libc6 only). That seems ridiculous, but when you have only 8MiB of flash in your old router, saving few hundreds KiB is really important, and here, we re saving more than 500 KiB, with a full implementation of the UPnP protocol, and the Microsoft NATPmP implemented as well (yes, Microsoft decided that one protocol wasn t enough, and that they should implement their own (sic!)).
Who is using MiniUPNP?
Probably, you already have the libminiupnpc installed in your SID/wheezy desktop, because the transmission bittorent client which is installed with Gnome by default, depends on it, and minissdpd might be in your desktop too, if you installed the Recommends: packages as well. Which is why these are scoring quite high already in popcon. Previously, transmission was embedding its own version of the MiniUPnP client library, so it s nice to have it as a standalone shared library now.
Also, because of its very light weight, and the fact that UPnP is often needed for gaming (both XBOX 360 and PSP need, and can use, the MiniUPnP daemon that runs on your IGD), many ISP who ship a router to their customer, install MiniUPnP in it. For example, at least, the 2nd and 3rd largest Internet access provider in France (Free Telecom and SFR) are shipping MiniUPnPd in their box (one of them using OpenWRT on their router). So probably as well, you are also using MiniUPnP daemon without knowing it.
But isn t UPnP unsafe?
To this question, I d answer that connecting to Internet is unsafe. It isn t less safe than connecting to Internet on a WiFi hotspot for example. So adding UPnP support on your gateway doesn t make it less safe, especially since MiniUPnP has some features to help with security (like an ACL with IP and port lists, or a secure mode were the router will only open ports to the client requesting it). Also, we are running a distribution where dependencies are easy to check, so it s easy for you to check if a client uses UPnP or not, and decide to trust it (or not). I personally have no issue trusting transmission, x-chat or warzone2010 (more exactly: I don t trust that incoming connectivity will make it less safe for these applications, there are so many other things that could go wrong).
MiniUPnP consists of what?
MiniUPnP is a set of 4 source packages to handle all of your UPnP needs:
- The client library, libminiupnpc (and the corresponding -dev package), with its sidekick miniupnpc client program (you can use it to check the public IP of your gateway, or manually open ports).
- The UPnP IGD daemon, miniupnpd, which just reached Debian Experimental. The latest version, 1.7-3, also includes debconf configuration so that you can choose the NIC and IP address to bind on. If you installed previous version, I strongly recommend upgrading to fix previous problems.
- The libnatpmp client library (and the -dev package) for implementing the Microsoft protocol as a client (it also has a client package binary for your tests).
- The minissdpd daemon to keep memory of all UPnP devices that announced themselves, and speed-up using the UPnP protocol (used by the MiniUPnP client library).
A long process to have MiniUPnP in Debian
All these 4 pieces of the puzzle were not as easy as it seems to be packaged in Debian. Especially, the IGD daemon, MiniUPnPd, used to depend on some header files that were not packaged in Debian. This was a decision of the iptables maintainers, which even after a long discussion, refused to add the necessary headers because it wasn t supposed to be a kernel API. While this might really be truth, the issue was that there was no public API available in the Linux kernel at all, and other distributions (Fedora, Gentoo, etc.) really did supply these needed files. As a consequence, during a very long time (years literally), shamefully, it was impossible to build the MiniUPnP daemon in Debian, while it was no problem on other distributions. Note that I do not want to start a troll discussion here, I m just stating facts, both parties have very strong and respectable arguments. Anyway, this needed API was finally embedded in MiniUPnPd itself thanks to a contributor to the project, and now it builds on both the Squeeze and the Wheezy (that is Linux 3.2) kernel without any issue.
Call for testing
Unfortunately, I don t have a Linux box as my Internet gateway. So I did the tests that I could: I installed MiniUPnPd on one computer on my LAN, and checked that I could open ports from another computer. So it seems to work, but I had no way to really test it live , with some real clients. So if you have an Debian SID box as your Internet gateway, feedback would be highly appreciated.
What is remaining to do?
A transition from libminiupnpc5 to libminiupnpc8 has to happen. Of course, this is too late for Wheezy, so this will happen right after the release. There s not so many reverse dependencies, so it should be ok, but I (yet) have zero experience with transitions. BTW, I had hard time to find out what this transition process was, and maybe some more effort for documenting it would help others (I m thinking about adding some text in the Debian wiki for that). Also, I have called for help on debian-devel, because I m currently the only one maintaining all these 4 source packages, and I m trying to have all my packages checked by others, and team maintained. So if you want to give a hand, or just declare yourself as a backup if I m busy, please raise your hand! Upstream is a friend of mine, and is very reactive to any requests (it very rarely took more than 48 hours to get a reply).
Enjoy MiniUPnP and report bugs!
Again, feedback would be appreciated. :)
It is rare that I use social networks, but usually I do not decline
invitations to connect when they come from people I know. This said, I had
doubts when accepting invitations from other Debian Developers, most of whom
I never met in person: how can I be sure that the account really belongs to
the person ? Luckily, we have a tool to solve that problem, our