NuFW Howto

Le service nufw dépend de :

Ces dépendances sont valables si votre système utilise un noyau de version supérieure à 2.6.14. Pour les noyaux plus anciens les dépendances sont

Un système avec noyau plus ancien que 2.6.14 nécessitera une version modifiée du module ip_queue et de sa librairie correspondante libipq.

Depuis les noyau 2.6.14, ipq est obsolète et doit être remplacé par libnetfilter_queue qui utilise le système nfnetlink. Nous vous encourageons à utiliser cette dernière librairie dans la mesure où elle représente l'avenir. De plus, nfnetlink procure également libnetfilter_conntrack qui est utilisée par NuFW pour implémenter les ACL horaires.

Pour pouvoir bénéficier de ces fonctionnalités, les librairies suivantes sont nécessaires: Vous pouvez trouver des versions fonctionnelles de ces librairies ici : http://nufw.org/download/libs/index.html Si vous utilisez GNU/Debian, les paquets adaptés sont disponibles là : http://packages.inl.fr/stable/

Si vous souhaitez utiliser les ACL horaires, il est recommandé d'utiliser les versions 2.6.18 du noyau ou supérieures ou d'appliquer le correctif disponible sur le site de NuFW.

Il s'agit ici de copier les certificats par défaut. Vous ne devriez vraiment pas procéder de la sorte sauf en cas de tests; dans le cas contraire, vous voudrez sûrement utiliser vos propres certificats : consultez pour cela la section suivante.

Pour nufw

cp conf/certs/nufw-*.pem /etc/nufw/

Pour nuauth :

cp conf/certs/nuauth*.pem /etc/nufw/
cp conf/certs/NuFW*.pem /etc/nufw/

Générez votre propre Authorité de Certification:

mkdir private
chmod 700 private
openssl req -new -x509 -keyout private/CAkey.pem -out private/CAcert.pem

Vous devriez utiliser ici un mot de passe particulièrement robuste, et, bien entendu, le garder secret.

Générer les clefs privées pour nufw et nuauth:

openssl genrsa -out private/nufw-key.pem

openssl genrsa -out private/nuauth-key.pem

Générer les demandes de certificats pour nufw et nuauth:

openssl req -new -key private/nufw-key.pem -out nufw.csr

openssl req -new -key private/nuauth-key.pem -out nuauth.csr

Signer les demandes de certificats grâce à l'AC:

openssl x509 -req -days 365 -in nufw.csr -CA private/CAcert.pem \
      -CAkey private/CAkey.pem -CAcreateserial -out nufw-cert.pem

openssl x509 -req -days 365 -in nuauth.csr -CA private/CAcert.pem \
      -CAkey private/CAkey.pem -CAcreateserial -out nuauth-cert.pem

Enfin, comme dans la section précédente, copier les fichiers comme demandé: Pour nufw:

cp private/nufw-key.pem /etc/nufw/

cp nufw-cert.pem /etc/nufw/

Pour nuauth:

cp private/nuauth-key.pem /etc/nufw/

cp nuauth-cert.pem /etc/nufw/

Avertissement: N'oubliez pas que les fichiers contenant les clefs privées (ici, nufw-key.pem et nuauth-key.pem) doivent rester secrètes.

NuFW fourni un exemple de fichier de configuration pour nuauth, nuauth.conf, qui est disponible dans le répertoire conf.

Les deux plus importantes directives de configuration sont : nuauth_client_listen_addr : définit l'adresse à laquelle nuauth va attendre les requètes des clients nuauth_nufw_listen_addr : définit l'adresse à laquelle nuauth va attendre les requètes de nufw. La liste des machines nufw autorisées à se connecter au serveur nuauth constitue la variable nufw_gw_addr.

Ensuite, vous devez choisir votre module d'authentification et de vérification des ACL. Les modules suivants sont disponibles :

Ceci est paramétrable via l'option nuauth_user_check_module dont la valeur par défaut est libsystem (si non défini dans le fichier de configuration). D'autre paramètres concernant la vérification des ACL doivent être précisés si vous choisissez l'authentification parmi :

en définissant la variable nuauth_acl_check_module.

Afin d'être capable de procéder rapidement aux tests, nous utiliserons le module system pour l'authentification et le module plaintext pour les ACL. Un fichier d'exemple, acls.nufw, pour le module ACL plaintext est disponible dans le répertoire conf. Copiez le dans /etc/nufw et modifiez au besoin le groupe pour l'ACL ssh afin d'utiliser le groupe d'appartenance de l'utilisateur que vous allez utiliser pour les connexions de test.

Nous devons ajouter les règles de filtrages de façon à déclencher une demande d'authentification pour toute connection vers ssh:

iptables -A OUTPUT -s 192.168.75.0/24 -p tcp --dport 22 -m state --state NEW --syn -j QUEUE
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

^[2]

Nous devons ajouter les règles de filtrages de façon à déclencher une demande d'authentification pour toute connection vers ssh:

iptables -A OUTPUT -s 192.168.75.0/24 -p tcp --dport 22 -m state --state NEW --syn -j NFQUEUE
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

^[3]

En premier lieu, il faut démarrer le service nuauth dans un terminal

nuauth -vvvvvvvvv

Ensuite, nous démarrons

nufw -vvvvvvvvv

dans un autre terminal.

Enfin, nous pouvons essayer de connecter un utilisateur (au sens nufw du terme). Sous Linux, ceci peut être fait par la commande :

nutcpc -d -H [NUAUTH IP]

Entrez le login et le mot de passe d'un utilisateur.

Dans le terminal nuauth, vous devriez voir quelques chose comme:

user bill@nufw uses OS Linux, 3.0.10, #1 Tue Oct 19 23:51:32 CEST 2008

Si votre configuration PAM utilise les fichiers shadow, nuauth pourra seulement authentifié l'utilisateur sous lequel il est lancé à moins d'être lancé en root. ^[4]

La connection SSH va déclencher la procédure d'authentification :

L'installation du serveur OpenLDAP est standard. Utilisez les paquets de votre distribution Linux, exemple avec Debian :

apt-get install slapd

Lisez OpenLDAP Software Administrator's Guide, section "Building and Installing OpenLDAP Software" pour plus d'informations.

Le fichier acls.schema doit être placé dans le répertoire /etc/ldap/schema et une ligne

include         /etc/ldap/schema/acls.schema

ajoutée au début du fichier /etc/ldap/slapd.conf. Au niveau du contrôle d'accès, on peut ajouter les lignes :

#INL access for acls
access to  dn="ou=acls,dc=inl,dc=fr"
       by dn="uid=nufw,ou=Users,dc=inl,dc=fr" write
       by dn="uid=nuauth,ou=Users,dc=inl,dc=fr" read
       by dn="cn=admin,dc=inl,dc=fr" write
       by * none

L'utilisateur nufw est autorisé à modifier la politique de sécurité alors que l'utilisateur nuauth n'a qu'un droit de lecture sur les ACL.

Pour activer la vérification des ACL sur un annuaire LDAP, nous devons modifier le fichier nuauth.conf comme suit :

nuauth_acl_check_module="libldap"

Ensuite, il faut préciser les paramètres de connection à l'annuaire :

ldap_bind_dn="uid=nuauth,ou=Users,dc=inl,dc=fr"
ldap_bind_password="secretpassword"
ldap_basedn="dc=inl,dc=fr"
ldap_acls_base_dn="ou=Acls,dc=inl,dc=fr"

INL a développé un puissant générateur de règles pour NuFW et Netfilter. Cet outil s'appelle Nuface. Il est disponible ici : http://software.inl.fr/trac/trac.cgi/wiki/EdenWall/NuFace Il permet de générer des règles pour NuFW et Netfilter, règles qui sont directement applicables depuis l'interface web.

nuaclgen est un script qui vous permet de gérer des ACL dans un annuaire LDAP.

Il est préférable d'utiliser Nuface plutôt que Nuaclgen dans la mesure où le premier simplifie grandement les opérations. Notamment, lorsque vous utilisez nuaclgen, vous devez modifier manuellement les règles Netfilter alors que Nuface s'en charge pour vous.

Le fichier nuaclgen.conf renferme les informations de connexion à l'annuaire LDAP. Elle doivent être adaptées à votre configuration :

$ldap_host="localhost";
$username="uid=nufw,ou=Users,dc=inl,dc=fr";
$password="writepasswd";
$basedn="ou=Acls,dc=inl,dc=fr";

^[5]

Pour autoriser les connexions SSH aux membres du groupe 513 à l'aide de l'application /usr/bin/ssh, la règle sera :

nuaclgen -A cn=ssh,ou=Acls,dc=inl,dc=fr -p 6 --dport 22 -AppName "/usr/bin/ssh" -j ACCEPT -g 513

Ou pour une connexion vers un serveur web :

nuaclgen -A cn=apt,ou=Acls,dc=inl,dc=fr -p 6 --dport 80 \
  -AppName "/usr/lib/apt/methods/http" -j ACCEPT -g 1042

Cette ACL autorise les connexions aux membres du groupe 1042 qui est utilisé par les administrateurs de certains de nos serveurs. Ainsi, les administrateurs ne sont autorisés qu'à récupérer les mise à jour depuis Internet, mais tous les autres utilisateurs se verront refuser l'accès à Internet.

Pour activer le suivi de connexion avec NuFW, il est nécessaire de paramétrer les options suivantes dans le fichier nuauth.conf :

nuauth_log_users_sync=1
nuauth_log_users=9

L'installation du seveur MySQL est standard. Utilisez les paquets de votre distribution Linux, exemple avec Debian :

apt-get install mysql-server

Lisez MySQL Documentation, section "2 Installing and Upgrading MySQL" pour plus d'informations.

L'installation du serveur PostgreSQL est standard. Utilisez les paquets de votre distribution Linux, exemple avec Debian (remplacez 8.2 par la dernière version stable) :

apt-get install postgresql-8.2

Lisez PostgreSQL Documentation, section "III. 14. Installation Instructions" pour plus d'informations.

Le suivi de connexion révèle toute sa puissance lorsqu'il est associé à la journalisation SQL. Nous allons décrire ici le paramétrage du module MySQL.

Vous devrez créer la base SQL à partir du fichier dump disponible dans le sous-répertoire conf/ de l'archive. Créez un utilisateur dans MySql. Celui-ci doit disposer des droits UPDATE et INSERT sur la table "conntrack_ulog". Enfin, ajoutez les informations de connexions au serveur SQL dans le fichier nuauth.conf.

Lors du déploiement de NuFW en environnement de production, vous devez utiliser le script clean_conntrack.pl qui est disponible dans le sous-répertoire scripts/ de l'archive NuFW à partir de la version 1.0.12. Pour les versions antérieures, vous pouvez récupérer le script ici : Nulog project homepage. Vous devrez créer un utilisateur SQL disposant des privilèges suivants: : SELECT et DELETE sur la table "conntrack_ulog", INSERT sur la table "ulog". Ce script doit être exécuté très régulièrement, à intervalles de quelques minutes seulement, par l'intermédiaire de cron, notamment en cas de trafic important. Si vous ne faites pas cela, la table "conntrack_ulog" sera vite saturée de connexions "mortes" ce qui provoquera un ralentissement de NuFW. La seule opération réalisée par le script est de transférer les connexions "mortes" (ie les connexions fermées ou refusées) vers la tables ulog, qui est en fait une table d'archivage. Celle-ci n'est pas utilisée en production, ni par NuFW, ni par les modules SSO.

Vous pouvez également envisager d'archiver régulièrement la table "ulog", afin d'éviter qu'elle ne grossisse indéfiniment. A partir de la version 1.0.12, les scripts nécessaires sont disponibles dans le sous-répertoire scripts/ de l'archive. Pour les versions antérieures, pour pouvez récupérer les 2 scripts concernés là : Nulog project homepage Recherchez les scripts ulog_rotate_*.sh. Actuellement, vous devez exécuter ces scripts en tant que root via cron. Bien évidemment, une meilleure solution serait de créer un utilisateur particulier pour exécuter ces scripts, en lui donnant les droits appropriés. Merci de fournir une mise à jour à cette documentation si vous l'implémentez avant nous.

Si nuauth est parametré pour journaliser les flux dans une base SQL, voici le fonctionnement du système :

Le mode de journalisation en SQL conserve donc tout l'historique de chaque connexion, et les différentes mises à jour de la base de données n'effacent en aucun cas les données journalisées précédemment. Ce mode de journalisation est le plus puissant que puisse offir un pare-feu, car il est très synthétique : une seule entrée est maintenue pour chaque connexion ; et il conserve tout l'historique de tous les événements de connexion.

nutop est un script perl fourni avec les sources de nufw. Il permet d'afficher en temps réel les connexions authentifiées actives de façon similaire à la commande top.

Le plus simple^[6] afin d'exploiter la journalisation effectuée par le système de suivi de connexion est d'installer nulog (autrefois nommé ulog-php) qui fourni une interface web conviviale. nulog est disponible sous licence GPL ici : http://software.inl.fr/trac/trac.cgi/wiki/EdenWall/NuLog

Tout ce dont vous avez besoin est de créer un utilisateur SQL disposant des droits SELECT sur la table "conntrack_ulog". Puis, paramétrez le module Apache mod_auth_nufw afin qu'il utilise les informations utilisateurs/base de données et table. Le code source du module pour Apache peut être récupéré là : NuFW Apache SSO page

De la même façon, il faut ajouter un utilisateur SQL disposant du droit SELECT sur la table "conntrack_ulog". Puis, paramétrez squid_nufw_helper pour qu'il utilise ces informations. Le code source correspondant est disponible ici : NuFW Squid SSO page

Les noyaux officiels sont incapables d'utiliser le marquage de paquets conjointement avec ip_queue. Il est donc nécessaire de modifier le noyau (version antérieures à 2.6.14), ce qui est possible grâce au correctif ip_queue_vwmark intégré dans patch-o-matic-ng de Netfilter. Cette opération va à la fois fournir une version modifiée du module ip_queue et du fichier libipq.a.

Une fois libipq.a installé, vous pouvez alors compiler nufw :

./configure --with-user-mark ${EXTRA_OPTIONS_YOU_LIKE}
make
make install

nufw peut alors être exécuter avec l'option -m pour activer le support du marquage utilisateur. Cette option est compatible avec l'option -M vue au-dessus.

Dans la mesure où NuFW n'utilise que les premiers paquets de chaque connexion, il ne peut effectuer le marquage des autres. Il est donc nécessaire d'utiliser la cible CONNMARK^[7]. Cette cible mémorise et rétabli automatiquement le marquage sur tous les paquets concernés d'une connexion. Exemple de paramétrage simple :

iptables -A PREROUTING -t mangle -j CONNMARK --restore-mark
iptables -A POSTROUTING -t mangle -j CONNMARK --save-mark

La première règle récupère le marquage existant à l'arrivée d'un paquet et la seconde sauvegarde le marquage appliqué afin de pouvoir le restaurer plus tard.

La variable de nuauth.conf nuauth_finalize_packet_module liste les modules qui s'attache à un hook appelé juste avant l'envoi de la réponse relative à un paquet de nufw. Cela est généralement utilisé pour marquer le paquet suivant la stratégie désirée. En découpant la marque (de 32 bits) en plusieurs champs de bits, il est possible de définir une politique de marquage complexe qui peut ensuite être utilisée

Une documentation complète est disponible dans le fichier suivant README.mark

Le marquage Netfilter peut être utilisé pour la qualité de service et le routage.

Il devient donc possible de préciser des routes spécifiques à tel ou tel utilisateur grâce, par exemple, à la commande :

ip rule add fwmark XXX lookup TABLE

Il en va de même pour les opération de QoS: en utilisant la commande tc filter on peut alors répartir le trafic dans des classes spécifiques en fonction de l'identifiant utilisateur :

tc filter add dev IFACE prio 5 protocol ip handle 102 fw flowid FLOWID

Pour plus d'information sur le routage avancé et la qualité de service, on se référera utilement au guide lartc.

Chaque option définissant l'utilisation d'un module doit être de la forme d'une liste de modules, séparés d'un espace

Pour chaque module, la syntaxe doit être de la forme : name[:type[:config file]] Exemples :

Analysons les exemples suivants : nuauth_user_logs_module="syslog dblocal:mysql maindb:mysql:/etc/nufw/mainmysql.conf" Les paquets seront journalisés plusieurs fois :

Il est particulièrement recommandé de placer nuauth dans un endroit protégé afin de garantir la sécurité des communications entre nufw et nuauth^[8]. Dans la mesure où la décision du pare-feu dépend de la réponse de nuauth, il est important de pouvoir valider l'identité du serveur nuauth. Pour cela, nous pouvons demander à nufw de vérifier le certificat présenté par nuauth lors de l'établissement du tunnel TLS. Ceci peut être mis en place grâce à l'option -a suivie du nom du fichier contenant le certificat d'autorité racine. Cette option est ajoutée à la ligne de commande démarrant nufw. Ce faisant, nufw vérifiera la validité du certificat présenté par nauth.

Il est aussi possible de lancer nufw en mode TLS strict en utilisant l'option -S. L'utilisation de cette option est recommandée. Elle signifie que nufw ne démarrera pas si le certificat de nuauth est :

Attention: Ce mode sera activé par défaut dans la prochaine branche stable.

Il est possible de restreindre le nombre de connexions qu'un utilisateur peut initier et de limiter le nombre de connexions depuis une adresse IP donnée.

Du côté du client, le système doit être intègre pour que les informations conernant les applications et le système d'exploitation soient pertinentes. Vous devez toujours garder à l'esprit que seul l'agent installé côté client est capable d'obtenir ces renseignements. En cas d'attaque, il est évident que ces informations PEUVENT et SERONT faussées par l'installation d'un agent NuFW modifié.

Vous devez impérativement tenir compte de cet avertissement et ne surtout pas oublier que cette fonctionnalité permet de sécuriser des flux qui auraient dû être ouvert sans vérification sur un système basique^[9].

La pertinence du filtrage d'application et/ou de système d'exploitation dépend de la confiance que vous placez dans le système qui réalisera l'authentification. Elle est "relativement bonne" sur un système sécurisé sur lequel les utilisateurs ne peuvent installer de logiciels.

Si voter serveur LDAP supporte les connexions SSL, il est possible de paramétrer nuauth pour qu'il se connecte en ldap over SSL.

Pour se faire, il faut éditer nuauth.conf et modifier le port LDAP à 636 (ldaps) :

ldap_server_port=636

L'étape suivante est l'édition du fichier /etc/ldap/ldap.conf pour indiquer la politique des connexions SSL. Pour une simple encryption des données, il suffit d'ajouter à ldap.conf:

TLS_REQCERT never

La configuration recommandée suppose d'utiliser une autorité de certification. Il faut pour cela éditer le fichier ldap.conf pour lui fournir le chemin vers le fichier de l'autorité de certification. Le fichier ldap.conf devrait ressembler à :

TLS_CACERT /etc/ldap/cacert-ldap.pem
TLS_REQCERT demand

Attention, dans ce mode de fonctionnent, il est nécessaire que le nom indiqué dans le certificat du serveur LDAP et le nom d'hôte spécifié dans la variable ldap_server_addr de nuauth.conf soient identiques.

PAM permet simplement d'étendre les méthodes d'authentification à des annuaires "exotiques". Par exemple, PAM vous permet d'interfacer nuauth avec un domaine NT, Active Directory, Radius, etc.

Pour réaliser l'authentification utilisasteur en s'appuyant sur PAM, vous devez paramétrer nuauth.conf (pour la 1.0):

nuauth_user_check_module="system"

En complément, il faut configurer correctement PAM. Ce point ne fait pas directement partie des objectifs de ce document. Voici quelques exemples de fichiers de configuration PAM basé sur la distribution GNU/Debian afin de permettre à nuauth d'utiliser l'authentification PAM : /etc/pam.d/nuauth :

#This is to set PAM-LDAP, modify to suit your needs!
  auth    required      /lib/security/pam_env.so
  auth    sufficient    /lib/security/pam_ldap.so
  auth    required      /lib/security/pam_deny.so

  account required      /lib/security/pam_ldap.so

  session required      /lib/security/pam_limits.so
  session optional      /lib/security/pam_ldap.so

Le fichier /etc/nsswitch.conf doit également être adapté :

#This is to set PAM-LDAP, modify to suit your needs!
  passwd:         compat ldap
  group:          compat ldap
  

(ne modifiez pas les autres lignes). Vous souhaiterez également adapter la configuration du fichier /etc/pam_ldap.conf. Ce fichier fonctionne correctement chez nous, à condition qu'il n'y ait pas de ligne commençant par "uri" :

  host 127.0.0.1
  ldap_version 3
  scope one
  pam_password crypt
  nss_base_passwd         ou=Users,dc=nufw,dc=org?one
  nss_base_group          ou=Group,dc=nufw,dc=org?one
  

Vous devrez également installer et configurer libnss-ldap. La configuration suivante fonctionne pour nous (toujours sous Debian) :

  host 127.0.0.1
  base replace_with_your_base
  ldap_version 3
  rootbinddn cn=admin,dc=replace_with_your_base
  #Optional, set if you need these :
  nss_base_passwd ou=users,dc=replace_with_your_base?one
  nss_base_group ou=groups,dc=replace_with_your_base?one
  

Bien entendu, vous devez adapter ce qui précède à vos besoins propres. Souvenez-vous que ces directives ne sont peut-être pas adaptées à d'autres distribution que GNU/Debian!

Sur Debian/Ubuntu, vous aurez besoin des paquets suivants :

    krb5-user
    krb4-config
    samba
    winbind
   

le fichier /etc/krb5.conf doit contenir quelque chose du genre :

[libdefaults]
        default_realm = DOMAIN.NAME
# The following krb5.conf variables are only for MIT Kerberos.
        krb4_config = /etc/krb.conf
        krb4_realms = /etc/krb.realms
        kdc_timesync = 1
        ccache_type = 4
        forwardable = true
        proxiable = true

[realms]
        DOMAIN.NAME = {
                kdc = 10.0.122.5
                admin_server = 10.0.122.5
                default_domain = DOMAIN.NAME
        }

[domain_realm]
        .domain.name = DOMAIN.NAME
        domain.name = DOMAIN.NAME
        shortname = DOMAIN.NAME
        .shortname = DOMAIN.NAME
   

Le fichier /etc/nsswitch doit ressembler à :

passwd:         compat winbind
group:          compat winbind
shadow:         compat

hosts:          files dns mdns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis
   

Il est très important de synchroniser l'heure du système avec les serveurs Active Directory. On peut utiliser ntp pour se faire.

Le fichier /etc/samba/smb.conf doit aussi être modifié:

[global]
# Change this to the workgroup/NT-domain name your Samba server will part of
   realm = DOMAIN.NAME
   password server = AD-SERVER
   netbios name = NUAUTH-SERVER
   workgroup = SHORTNAME

# server string is the equivalent of the NT Description field
   server string = %h server sexa-prn1 (Samba, Ubuntu)

####### Authentication #######

   security = ads
   encrypt passwords = true
   guest account = nobody

############ Misc ############

   socket options = TCP_NODELAY
   domain master = no

# Some defaults for winbind (make sure you're not using the ranges
# for something else.)
   idmap uid = 10000-20000
   idmap gid = 10000-20000
   template shell = /bin/bash

   template homedir = /home/%D/%U
   client use spnego = yes
   client ntlmv2 auth = yes
   restrict anonymous = 2
   

Pour joindre le Domaine Windows, on peut utiliser:

kinit administrator@DOMAIN.NAME

net ads join -U administrator

La dernière commande devrait afficher le nom court du domaine et indiquer que l'inscription s'est bien passée.

Winbind (ou winbindd) devrait tourner sur votre système. On peut vérifier le bon fonctionnement dans les journaux samba (probablement dans /var/log/samba/*).

C'est relativement limpide à réaliser : le gros du travail doit être effectué dans le fichier nuauth.conf (les différentes options sont documentées dans le fichier lui-même). Souvenez-vous qu'utiliser une authentification directe sur un LDAP vous obligera à utiliser un schéma LDAP spécifique à NuFW ce qui pourrait se révéler bloquant pour vous. Dans ce cas, envisagez sérieusement l'utilisation de PAM comme décrit ci-dessus.

RHEL4 étant fournie avec la version 2.6.9 du noyau, ce système est sujet au problème lié à ip_queue comme mentionné ci-après. Le problème s'est systématiquement posé avec ce noyau (en tout cas sur les machines multi-processeurs).

Il existe un bug ip_queue dans les moyaux antérieurs au 2.6.12. Il provoque un crash du système lorsque qu'une décision ACCEPT est prise dans la chaîne INPUT. N'utilisez donc pas la cible QUEUE dans la chaîne INPUT avec ces noyaux ou vous risquez de geler votre machine. Dans tous les cas de figure vous devriez vraiment utiliser un noyau plus récent et la cible NFQUEUE, comme expliqué plus haut dans ce document.

NuFW devrait tourner sans soucis dans des environnements virtualisés. Il est cependant à noter que Xen 3.1 semble poser des problèmes à l'utilisation de nfnetlink. Les tests suivants ont été réalisés (avec NuFW 2.2.14, mais la version NuFW semble sans importance) :