Waarom ben je begonnen met een frontend voor IP-tables?

Julien: Ik beheerde in mijn studentenhuis een Linux gateway om mij en mijn 11 huisgenoten toegang tot internet te geven. Ik merkte dat het bijhouden van een script niet erg efficiënt was en dat de tools die ik probeerde me geen van allen bevielen. Toen ben ik gaan nadenken over zelf een tool bouwen. Daar kwam bij dat ik mijn programmeervaardigheden graag wilde verbeteren. De beste manier om dit te doen leek me via een eigen project. Ik was al enige jaren met Linux en andere open source producten bezig en ik wilde graag deel uitmaken van de open source community. Vandaar dat het open source is.

Waarom IP-Tables en niet PF of ipfw?

Julien: Tsja, eigenlijk om geen andere reden dan dat ik altijd met Linux heb gewerkt en er nooit aan toe ben gekomen om me serieus te verdiepen in *BSD. Overigens werd ik onlangs benaderd door iemand die misschien pf ondersteuning voor Vuurmuur wilde gaan bouwen, maar het is afwachten of daar iets van terecht komt. Ik heb inmiddels wel geleerd dat er in de open source community veel mensen zijn die alleen maar praten, maar vervolgens niet veel doen.

Wat onderscheid Vuurmuur van andere frontends?

Julien: Verschillende zaken, maar ik denk dat het belangrijkste punt realtime
monitoring is. De meeste IPTables frontends zijn puur gericht op het creëren van een ruleset. Dit is uiteraard een belangrijke taak, maar slechts een deel van het totale firewall beheer. Voor de monitoring kun je natuurlijk 3rd party tools gebruiken, maar deze sluiten vaak slecht aan. Doordat Vuurmuur deze functionaliteiten integreert is het geheel veel consistenter. Een naam die je bijvoorbeeld aan een host geeft komt zowel in de regels, logviewer en connection viewer terug. Hierdoor blijft het beheer overzichtelijker en neemt de kans op het maken van fouten af. Daarnaast kan Vuurmuur de firewall volledig via de ncurses GUI beheren, op een veilige manier via ssh. Vuurmuur schaalt ook goed. Een sysadmin kan het gebruiken voor een enkele server maar ook voor zeer complexe setups. Ik heb over setups gehoord met tientallen netwerkinterfaces en honderden regels.

Het beheren en opstellen van een goede ruleset is vaak een probleem. Wat zijn de meest gemaakte fouten die je tegenkomt?

Julien: De meest gemaakte fouten komen doordat mensen de concepten achter Vuurmuur niet begrijpen. In Vuurmuur is het de bedoeling dat de sysadmin zones, netwerken, hosts, groepen, interfaces en services definieren om het programma in te lichten over de omgeving van de firewall. Hoe accurater en vollediger de informatie, hoe beter de firewall functioneert en gemakkelijker die configureerbaar is. Helaas vindt nog niet iedereen dit even duidelijk. Deze mensen gaan dan snel gebruik maken van 'any' zones en services, waardoor de firewall meestal veel te veel open komt te staan.

Niet echt een fout, maar toch wel het vermelden waard is het volgende. Veel mensen denken nog steeds dat een firewall op zich voldoende beveiliging is. Veruit de meeste hacks gaan tegenwoordig over poorten die een firewall open *moet* zetten, dus verdere beveiliging is noodzakelijk. Vuurmuur kan goed samenwerken met Snort_inline, zodat op de openstaande poorten content inspection kan worden gedaan. Verder kun je denken aan proxies, ModSecurity voor Apache, etc.

Vuurmuur is open source, in hoeverre heeft de open source gemeenschap aan de ontwikkeling van het programma bijgedragen?

Julien: Slechts beperkt met programmeren, maar wel veel in de ondersteuning. Denk aan hosting, vullen van de wiki, vertalingen, bug meldingen, ideeën en feature requests. Maar veruit het meeste werk wordt toch door mij verricht. Ik hoop nog steeds op iemand die ook aan de programmeerkant significant wil bijdragen.

Hoeveel tijd ben je kwijt aan de ontwikkeling van Vuurmuur?

Julien: Tegenwoordig niet zoveel meer, voornamelijk omdat ik niet zoveel tijd meer aan het project kan besteden door werk en andere projecten. Bovendien is het redelijk af voor een pure IPv4 packet filter.

Ooit gedacht om commercieel te gaan?

Julien: Ja, maar eigenlijk nooit echt serieus overwogen. Ik vind het erg leuk om
Vuurmuur juist als een echt open source project te beschouwen. Een businessmodel waar je zowel open source als commercieel combineert is erg lastig, hoewel er natuurlijk wel voorbeelden van zijn. Waar ik wel open voor sta is maatwerk. Ik werk momenteel als freelance security programmeur. Dus als een bedrijf een feature request heeft kunnen ze me inhuren om de feature te laten bouwen.

Hoe schaalt Vuurmuur in een onderneming. Open source, op een enkel project na, heeft een hoog "hobby" gehalte. Ondanks dat de prestaties vaak die van commerciële tegenhagers overstijgen, zijn bedrijven huiverig hiervoor te kiezen. Ook door het ontbreken van support. Hoe sta jij hier tegenover?

Julien: Ik kan me wel voorstellen dat bedrijven huiverig zijn. Aan de andere kant is mijn persoonlijke ervaring dat als mensen en bedrijven bugs melden deze meestal snel door mij worden opgelost. Aangezien de code publiek is, kan zo'n bedrijf zelf direct de fix uitproberen. Mijn ervaring met commercieel ondersteunde software is dat het meestal toch behoorlijk lang duurt voordat je dan een nieuwe versie kan testen. Voor feature requests werkt dat wel wat anders. Tenzij het kleine dingen zijn zal ik niet zomaar iets implementeren. Hier staat natuurlijk tegenover dat bedrijven dat ook zelf kunnen (laten) doen. Ik weet dat er veel bedrijven zijn die Vuurmuur gebruiken, dus ik denk zelf dat Vuurmuur het hobby gehalte wel ontstegen is.

Wat betreft het schalen van Vuurmuur denk ik dat het programma behoorlijk goed schaalt. Er zijn geen ingebouwde limieten wat betreft het aantal regels, netwerkkaarten, etc. De interface zal niet altijd even efficiënt zijn voor heel complexe setups, maar het werkt allemaal wel. Er is geen mogelijkheid tot het centraal gelijktijdig beheren van meerdere firewalls, behalve dan dat je via ssh natuurlijk je firewalls kunt beheren. Hierbij blijft de sysadmin wel gewoon elke firewall afzonderlijk beheren.

Een ander vervelende klus voor sysadmins is het doorlopen van logs op anomalies. Vuurmuur beschikt over "powerful monitoring features". Kan je daar iets over vertellen en hoe voorkom je dat je de gebruiker overspoelt met info, zodat door alle ruis de echte info verloren gaat?

Julien: Bij het instellen van de logging kan de sysadmin per regel logging in en uitschakelen, er nog een eigen tekst aan toevoegen en een limiet instellen voor de hoeveelheid logs per firewall regel. In de GUI kan worden gefilterd en kunnen ook oude logs worden doorzocht. Een mogelijkheid voor het maken van rapporten ontbreekt nog. Ik zit hiervoor te denken aan een integratie met het eveneens open source Sguil project, omdat er dan gelijk kan worden gecorreleerd met Snort events en andere events.

Vuurmuur is een mooi Nederlandse vertaling, maar dat kan toch geen enkele buitenlander uitspreken, vanwaar deze benaming? ;)

Julien: Heh, het was eigenlijk een soort werknaam toen ik er aan begon. Later, toen ik voor het eerst een publieke release deed, had ik nog steeds niks beters gevonden. Een naam als YYAFW (yet yet another firewall) sprak me niet erg aan ;). Maar het klopt wel dat de naam lastig is voor buitenlanders. De voor mij zichtbare gebruikers zitten vooral in Duitstalige gebieden en in Zuid Amerika. Ik weet niet of dit iets met de naam te maken heeft.

Wat heb je in de toekomst voor Vuurmuur in petto?

Julien: Ik ben op dit moment bezig met een grote toevoeging: traffic shaping. Dit is het limiteren van bandbreedte, toewijzen van prioriteiten en het garanderen van minimale bandbreedte voor regels. Dit zal in de bestaande regels worden geïntegreerd. Ik hoop hiervan binnen een paar weken een test release uit te kunnen geven. Verder zijn er weinig concrete plannen maar veel ideeen. Denk aan een web frontend, IPv6 ondersteuning, integratie met Snort_inline, etc. Mensen die geinteresseerd zijn kunnen het beste mijn weblog in de gaten houden.

Enthousiast over Vuurmuur, probeer hem zelfs eens via vuurmuur.org.