Le weblog entièrement nu

Roland, entièrement nu... de temps en temps.

In English

FusionForge 6.0 final release available

Hi all,

After 4 release candidates, the FusionForge community is proud to announce the new major Fusionforge 6.0 final release.

The major changes in this version are:

  • Immediate system actions (0-delay for new project, new repository, new SSH key...)
  • Unified, concurrent SSH & HTTPS access to Git and SVN
  • Technology preview: new TaskBoard plugin supporting Scrum and Kanban agile methodologies

Here is a more detailed list of visible changes:

Standard features:

  • New install system (Inria)
  • Reactivity: system replication is now performed immediately (rather than waiting for cron jobs) (Inria)
  • SCM:
    • Concurrent SSH and HTTPS access, relying on Apache mod_itk (Roland Mas and Inria)
    • Allow projects to use several SCM engines in parallel (Roland Mas, for CEA)
    • Support read-only access to private projects via SSH (Inria)
    • Browsing support for (Git) private repositories (Roland Mas, for AdaCore)
    • Anonymous read-only access through xinetd and rsync (Inria)
  • System: users now use a common default group ("users") rather than per-user group; avoids conflicts with project groups (Inria)
  • Docman:
    • Basic Webdav write mkcol, delete, put, move support (TrivialDev)
    • Add move mass actions (TrivialDev)
    • Direct link to file details (TrivialDev)
    • Rewrite parser using unoconv, support more file formats (Roland Mas, for CEA)
  • FRS:
    • Enable widget "My monitored packages" (TrivialDev)
    • Provide new role settings (TrivialDev)
    • Add delete packages, releases or files mass action (TrivialDev)
    • Provide link to download any release as ZIP file (TrivialDev)
  • Web UI:
    • Drop tipsy plugin, use standard jQuery UI tooltip already provided (TrivialDev)
    • FusionForge Theme & jQuery UI theme sync (TrivialDev)
  • Gadgets:
    • Public Area: display FRS link (TrivialDev)
    • My Latest Commits: New widget to display user commits on "My Page" (TrivialDev)
    • Project Latest Commits: New widget to display the 5 latest commits on the project page (TrivialDev)
    • Project Latest Documents: enhancement, add actions buttons (monitor, delete) (TrivialDev)
  • Tracker: enable support for multi-select extrafield in roadmap (TrivialDev)
  • Forum: store the attached files on FS (TrivialDev)
  • vhosts: allow customization from /custom/httpd.vhosts.tmpl (Inria) Plugins:
  • SCM SVN: Improved ViewVC integration, using external installation (Inria, TrivialDev)
  • SCM Git: Activity log entry link to commit log in SCM browsing tab (TrivialDev)
  • SCM Hg (Mercurial)
    • Display the Repository History stats block (TrivialDev)
    • Add support for project activity tab (TrivialDev)
    • Activity log entry link to commit log in SCM browsing tab (TrivialDev)
  • scmhook
    • Update git post-receive email hook (tarent solutions GmbH, Teckids e.V.)
    • Install hooks as the requesting system user (Inria)
  • AuthLDAP: Support LPAP_OPT_REFERRALS option, needed by ActiveDirectory Server (TrivialDev)
  • Task Board: New Agile TaskBoard supporting Scrum and Kanban methodologies (Vitaliy Pylypiv and TrivialDev)

Tracker roadmap of the 6.0 release: roadmap.

Some metrics about 6.0:

  • 14 months of development since 5.3
  • ~ 2900 commits between 5.3 and 6.0
  • 36 contributors
  • 43 feature requests implemented
  • 10 bugs fixed (in addition to those that were not in the tracker)

FusionForge 6.0 can be downloaded in source form from our file release system. Packages will be available in some distributions soon.

Enjoy! Your feedback to fusionforge-general@lists.fusionforge.org is welcome!

For more information on FusionForge, refer to FusionForge.org.

-- The FusionForge community

Tags: en
Posted ven. 29 mai 2015 16:01:08 CEST
Rsyncing a BackupPC storage pool, efficiently

BackupPC is a pretty good backup system. Its configuration is rather flexible, it has nice expiry policies, and it can store duplicated file contents only once (for files that are shared across hosts or don't change in time) within a compressed pool of data. However, it doesn't do much to help pushing the data to off-site storage, or at least not very efficiently. So if you have a BackupPC instance running on a Raspberry Pi or a plug computer at home, it's a bit tricky to protect your data against loss due to burglary or home fire.

The obvious solution would be to rsync the storage pool to a remote site. However, the current pooling system relies heavily on hardlinks, and rsync is notoriously inefficient with those. In the home backup server scenario, this means that even if the computer is more powerful than a Pi and can handle the memory requirements of rsync, you'll often end up transferring way too much data.

So, since the obvious solution doesn't work straight away, what do we do? Why, we fix it, of course. With a little look into the storage pool, we notice that the bulk of the data is stored in files with an “abstract“ name (related to the contents) within a $prefix/pool directory; the files with concrete names looking much like their original are stored within $prefix/pc, and they're actually the same files because they're hardlinks. Knowing this (that rsync doesn't), we can make a smarter replication tool, by

  1. pushing only the pool with standard rsync;
  2. storing locally, and recreating remotely, the structure of hardlinks;
  3. pushing everything again with standard rsync.

Steps 1 and 3 are simple invocations of rsync -aH; step 2 can be implemented using the following two scripts. Run store-hardlinks.pl locally, push the links file, then run restore-hardlinks.pl on the remote server. This will ensure that files already present in the pool are also hardlinked in their natural location.


#! /usr/bin/perl -w

use strict;
use Storable qw(nstore);
use File::Find;

use vars qw/$prefix $poolpath $pcpath %i2cpool %todo $store/;

$prefix = '/var/lib/backuppc';

$poolpath = '$prefix/cpool';
$pcpath = '$prefix/pc';
$store = '$prefix/links';

# for the convenience of &wanted calls, including -eval statements:
use vars qw/*name *dir *prune/;
*name   = *File::Find::name;
*dir    = *File::Find::dir;
*prune  = *File::Find::prune;

# Scan pool
File::Find::find({wanted => \&wanted_pool}, $poolpath);

# Scan PC dirs
File::Find::find({wanted => \&wanted_pc}, $pcpath);

nstore \%todo, $store;

sub wanted_pc {
    my ($dev,$ino,$mode,$nlink,$uid,$gid);

    (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($_)) &&
      -f _ &&
      ($nlink > 1) &&
      do {
      $name =~ s,$pcpath/,,;
      if (defined $i2cpool{$ino}) {
      $todo{$name} = $i2cpool{$ino};

sub wanted_pool {
    my ($dev,$ino,$mode,$nlink,$uid,$gid);

    (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($_)) &&
      -f _ &&
      ($nlink > 1) &&
      do {
      $name =~ s,$poolpath/,,;
      $i2cpool{$ino} = $name;


#! /usr/bin/perl -w

use strict;
use Storable;
use File::Path qw/make_path/;

use vars qw/$prefix $poolpath $pcpath %todo $store/;

$prefix = '/srv/backuppc-mirror';

$poolpath = "$prefix/cpool";
$pcpath = "$prefix/pc";
$store = "$prefix/links";

%todo = %{retrieve ($store)};

my ($dev,$ino,$mode,$nlink,$uid,$gid);

foreach my $src (keys %todo) {
    my $inode;
    my $dest = $todo{$src};
    my $dpath = "$poolpath/$dest";
    my $spath = "$pcpath/$src";
    my $sdir = $spath;
    $sdir =~ s,/[^/]*?$,,;
    make_path ($sdir);
    next unless -e $dpath;
    if (! -e $spath) {
      link $dpath, $spath;
    (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($spath));
    $inode = $ino;
    (($dev,$ino,$mode,$nlink,$uid,$gid) = lstat($dpath));
    if ($ino != $inode) {
      unlink $spath;
      link $dpath, $spath;

The initial transfer can still take forever if the pool is large (and if you're pushing it through the small end of an ADSL link…), but at least the files are only transferred once.

Note: This is only useful for current versions of BackupPC. Apparently BackupPC 4 will have a different pooling system without hardlinks, and the following hack will no longer be required. For now, though, here it is.

Tags: en
Posted lun. 02 déc. 2013 11:25:31 CET
FusionForge news, June 2013

Once again, it's been some time since the last FusionForge update in here. The main explanation is that news is slow on that front. Debian Wheezy was released without FusionForge packages, as previously announced, and even Sid hadn't seen any update on the package for way too long. The latter has just been fixed though: the freshly-released 5.2.2 upstream version is on its way to Sid (via NEW, since it adds a new plugin to allow authenticating against a CAS server). If and when it reaches Debian Jessie (the current “testing”), I'll work on backporting it for Wheezy.

At some point I'll also start uploading snapshots of the upstream master branch to “experimental”, to give adventurous users a glimpse of what is to come in the future releases, although I'll stick to only uploading when the automated tests all pass.

Tags: en
Posted ven. 28 juin 2013 00:00:00 CEST
A challenge for whoever feels they have too much free time

Open question to enthusiasts, theoretical computing scientists and mathematicians of all sorts: is it possible to construct a valid QR-code that leads to interesting results when used as an initial configuration for the Game of Life?

The rules:

  • QR-code or DataMatrix or whatever, I'm not picky;
  • valid code as in maybe not exactly what would be produced from the text, but which the error-correction can reconstruct;
  • interesting results, as in not decaying to a stable state (or not too soon, at least);
  • for bonus points, it would lead to at least one glider;
  • for extra bonus points, a glider gun or a breeder of such;
  • for awesomeness, the QR-code should encode an URL pointing at the demonstration of its own evolution in Life.

For Science!

Update: The answer seems to be yes. Jurij Smakov assembled a QR-code generator and a Life engine and plugged them together for easy experimenting. And Stefano Zacchiroli noticed that using "free software" (no quotes) as the input leads to a couple of gliders endlessly traveling a field with a few still lifes. This is way beyond awesome.

Tags: en
Posted mar. 19 févr. 2013 00:00:00 CET
Various small bits

Dear reader, I know you're wondering what I'm getting up to these days. Or at least, I guess there's a possibility that you're wondering. So since there's no single bit of news that would be worthy of a post here by itself, here's one summarizing things, in the hope that the accumulation makes a tiny bit of a difference.

On the rock'n'roll front: Eleven did its first true gig on our own in a pub last Saturday. And when I say “on our own”, it could almost be taken literally, for we must have had a grand total of about 10 people. A bit of a disappointment, to say the least, especially since the pub was about 120 kilometers from home, 60 of which I rode on my motorbike at 2 AM (and close to 0 °C). However, the landlord seemed to like us and hinted at further gigs during seasons where people are more likely to go out for drinks and music than to stay warm at home.

In a related note: we got ourselves a small set of stage lights (LED-powered, of course), and they have, in addition to the power cord and various switches, two sockets at the back for plugging XLR-3 cables. On investigation, it seems that this means they can be controlled by a protocol known as DMX 512, which opens up a lot of possibilities for someone who likes to control various things from a computer. I read a few web pages to get an idea of how this is supposed to work, it seems rather simple and straightforward, but the required software isn't in Debian yet. So I guess that if/when I get the necessary hardware, I'll have a new hobby and new toys to play with. Maybe our next gig will have bursts of lights on the big accented beats, triggered by “strong enough” hits on my drum cymbals.

This allows me to link to… a new minor release of Wiimidi. The only addition is a new configuration section mapping to the default drumkit provided by Hydrogen.

And finally, to stay in the “small bits of software”, I was prompted to give my simple GPG-encrypted password store, a.k.a. SGEPS, its own page, with a proper release and so on. So there, 0.1 is out, with minimal Debian packaging included.

Tags: en
Posted mer. 30 janv. 2013 00:00:00 CET
Back to space

A long time ago, I spent many many hours playing Frontier (Elite 2) on the family Atari ST. It was nice-looking (oh, those sunrises on distant planets!), playable, varied, had ample room for progression, very different possible roles, a huge universe of which nobody could ever hope of exploring more than a tiny fraction, and it was basically the first game I encountered with no set goals. You are a spaceship pilot in a galaxy colonised left and right, and it's up to you to decide what you want the game to be. Pirate, headhunter, mercenary, trader, taxi, explorer, there's no end goal to achieve except what you fix for yourself. That was, for me as a youngster, a mind-opening experience, which I never felt as strongly since (with the possible exception of the Creatures game, but I barely tried it).

Then came modernity, the PC, and the First Encounters sequel (Elite 3). It added moderate complexity to the gameplay, some sort of political evolution among the factions and a kind of plot so the galaxy was no longer quite so static, but the end results were still a bit disappointing. It felt like Frontier with a few not-exactly-overwhelming textures stuck onto the ships, a loose plot arc, and a third faction, the Alliance of Independent Systems, beyond the Federation and the Empire. Not that exciting, although the name of the Alliance's capital star system stayed in my mind.

So, like many others, I came to wait for Elite 4. That wait started in 1995, more than seventeen years ago. During that time, Duke Nukem Forever was announced, promised, developed, postponed, abandoned, found again, developed again, and it was even actually released in 2011, while Elite 4 went into the same kind of hell only without the actual release (yet).

At some point I started trying various substitutes to help pass time.

There was Parsec which was a nice-looking space combat simulator, multiplayer and all, but never felt like finished. Development slowed down to a thin trickle, and it seems like it only recently started again as Open Parsec. Hopefully it won't wither off again, but since it's only focused on combat, it's not exactly the same spirit as Elite.

There's Oolite, but it looks and feels very much like a lightly-modernised Frontier. Better textures, sure, but the UI still looks like it got taken from the times where games mentioned they required an EGA/VGA video card.

There's Vega Strike. It's very promising too, and I did try it at some point, but it was crashing too often for my tastes. Development seems to have slowed down, but not stopped; maybe it's time I gave it another go.

I just recently found out about Pioneer, and I admit I'm excited. Really excited. It feels like… like Frontier felt at the time. It's not finished yet (the on-planet cities in particular look a bit weird), but from the alpha I tried and the videos on the website it's really impressive. I'm going to keep an eye on that, knowing I could spend quite some time in there even before it's quite finished, if only to fly a spaceship in the canyons of Europa with Jupiter rising in the distance. I'll let you know if I find a black monolith.

But the main event triggering this blog post is that apparently Elite 4 is not dead (yet). Much better, it's under heavy development, under the Elite Dangerous name, and the current state seems to be rather good already. And Frontier Developments, the company behind it, opened a Kickstarter campaign to fund the project. The screenshots and the videos look impressive, and the interviews of the lead developer imply that the gameplay will be awesome. The galaxy will apparently be really dynamic, and the player's actions could really influence its geopolitical (galactopolitical?) evolution, the profitability of trade routes, the prevalence and repartition of space pirates in various sectors, and so on. Combine with a multi-player mode, and this could become the greatest game ever made (for my personal taste at least). So I'm very much hoping the funding campaign reaches its target.

The release date is set to March 2014. It's going to be a long wait, fraught with incertitudes.

But then again, Duke Nukem Forever was eventually released, wasn't it?

[No, I never played the original Elite. I'm not that old.]

Tags: en
Posted ven. 14 déc. 2012 00:00:00 CET
Wii(gh2)midi yet again

Not that I'm bored or anything, but I spent some more time on this since last month, and apparently some people are interested enough, so here's the recent news about wiigh2midi.

  • First, I think it's got generic enough that the “GH” part is no longer warranted. I've looked for a suitable name, and the best I found was the simplest. From now on, this piece of code will be known simply as Wiimidi. Various searches on the web led me to believe that it's a traditional name that's been used a couple of times already by projects that stopped evolving years ago. So mine will either continue in that vein and maintain the tradition, or stay alive and keep the name. Time will tell.
  • I ended up doing the Debian packaging. It's fairly minimal, and I don't currently plan to actually upload it (unless asked to), but it's there.
  • I also added support for sending MIDI “program change” events in addition to notes. Why, you wonder? See next item.
  • A new set of settings called program_changes in the sample configuration file, and a new rhythmbox-midi script. The goal is to control a Rhythmbox music player with your Wiimote (or possibly the attached drumkit).
  • I also slapped a GPL-2+ license on it, which is consistent with the python-cwiid license.

Also, since the code moved (and it doesn't harm mentioning it again): Wiimidi is developed with Bazaar, and the public branch is at https://alioth.debian.org/~lolando/bzr/wiimidi/trunk/. So, to grab a copy:

 bzr checkout https://alioth.debian.org/~lolando/bzr/wiimidi/trunk/

Patches welcome, of course! Also, I'll be interested to hear about your applications. I've been told about a Wiimote-powered foot controller, which is exactly the kind of unpredictable results I was hoping to achieve by publishing my code. Keep it up, I want to hear about Wiimote-controlled robot dinosaurs next!

Update: Wiimidi now has its dedicated page at Wiimidi.

Tags: en
Posted jeu. 29 nov. 2012 00:00:00 CET
Guitar Hero drumkits and MIDI, again

Almost a year after my previous post, I felt inclined to spend another Sunday (this one was chilly rather than rainy) working on my script to integrate the drumkit of Guitar Hero World Tour for Wii within a MIDI environment. And wiigh2midi got, if not a rewrite, then at least a few enhancements since I last mentioned it here.

  • The buttons are now handled. The “cross-stick”, the A and B buttons, + and -, Home, 1 and 2. And if the Wiimote is plugged into a drumkit, you get even more buttons: another set of + and -, plus another mini-joystick. Thunder! Martians! Bubbles! Yay for sound effects!
  • A side-effect: the drumkit is no longer even necessary. Run several instances with different configurations, give a wiimote each to a bunch of kids, and get them to perform a batucada by pressing the big round button in time. I tried and failed, but it was due to the age and over-excitedness of the bunch of kids in question rather than the technical side of things.
  • Yeah, configurations. It's all in a nice .ini file now, and you can define several “kits” (input-to-MIDI-note mappings) in different sections, and select which kit to use when running.
  • The configuration can also define which MIDI device to send events to, and which channel to use. My use case is that sometimes I want to use my GHWT drumkit as a set of extra pads and send the MIDI stuff to my “real” electronic drumkit (over an USB adaptor), and sometimes I just want to send the MIDI events to a software synthesiser such as Hydrogen, to have a second, cheaper, lighter drumkit.
  • Speaking of Hydrogen: since the MIDI-to-instrument mappings are somewhat strange in there, I provided a template Hydrogen file with a reasonable drumkit that matches the example configuration if wiigh2midi.
  • Hey, you know, three toms, two cymbals and one pedal are really a small kit, even for beginners. And what about open/closed hi-hats? Well, we could, you know, split some of the pads so they can produce different “sounds” depending on context. Like, maybe if you hit the left pad real soft, you get a cross-sticks sound, but you get the standard snare drum sound if you hit it a bit harder (or very hard). And the open hi-hat could be obtained by hitting the yellow cymbal harder, with normal hits still sounding like closed hi-hats. And since the crash cymbal is usually hit markedly, while the ride is usually more of a soft-to-medium hit, you guess what we could do with the orange cymbal. Well, scratch the “could” there, that's exactly what we do now. So my cheap drumkit has hi-hats that open, a cross-stick sound on the snare drum, ride and crash cymbals, a bass drum and two toms. Not so bad.

It's still not something that I'd put in everyone's hands, but it's coming to be seriously usable. I wonder if there'd be any interest in me packaging that and uploading it to Debian? It would need some cleanup first (and a more generic name, since it's far from restricted to Guitar Hero controllers or drumkits), but I guess it could be useful. Ping me if you're interested.

Update: Wiigh2midi has been renamed to Wiimidi, and has its dedicated page at Wiimidi.

Tags: en
Posted dim. 28 oct. 2012 00:00:00 CEST
FusionForge news, September 2012

Hey, long time no see!

Okay, so what's new in FusionForge land these days? Well, I guess the most prominent news is that we've just declared 5.2 stable. It's been uploaded to fusionforge.org already, and Debian packages are on their way to Debian unstable. Yay!

Not-yay: the final weeks convinced us that the state of the 5.2 release candidates, and especially the packages in Debian Wheezy, wasn't near good enough for inclusion in a stable Debian release. So the packages won't be officially part of Wheezy when it comes out, to our great shame. The packages from unstable should work fine however, and we'll provide backports via the official Debian channel, backports.debian.org as soon as possible.

And finally: the developers (and some users) of FusionForge will gather for a work session in Paris on the 10th of October, as described on the Meeting/Oct2012 page on the FusionForge wiki. Join us if you're interested!

Tags: en
Posted ven. 28 sept. 2012 00:00:00 CEST
Integrating FWbuilder with fail2ban and port-knocking

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.

Tags: en
Posted ven. 31 août 2012 00:00:00 CEST
Creative Commons License Sauf indication contraire, le contenu de ce site est mis à disposition sous un contrat Creative Commons.