Étiquette : bsd

Catégories
Open-source Planet-libre Reseau Systeme

Installation et configuration de Munin, le maître des graphes

Munin est un logiciel de supervision permettant de centraliser la gestion des graphes de données RRDTools. Il permet en quelques commandes que nous allons détailler dans ce billet de générer des graphes complexes pour surveiller vous machines et les processus qui tournent dessus.

Voici un exemple de graphe sur les statistiques remontées par un serveur utilisant Varnish:

Introduction

Munin est proposé sous la forme de deux packages complémentaires: munin et munin-node.

Le premier (munin) est à installer sur votre serveur de supervision (appelé maître). Son objectif principal est de récupérer les données venant des machines à surveiller puis de générer des graphes qui seront présentés aux utilisateurs via une interface Web.

Le second  (munin-node) est à installer sur toutes les machines à superviser (appelées noeuds). Son objectif est de collecter les informations systèmes en utilisant des plugins (présent dans le package munin-node et dans munin-plugins-extra).

La communication entre le serveur maître et les machines noeuds utilise, par défaut le protocole TCP/4949 (initialisation de la connexion TCP de la part du serveur maître).

Installation de Munin

Pour la suite de ce billet (et sauf mention spécifique), je partirai sur le principe ou vous utilisez des machines sous Debian/Ubuntu.

Installation de Munin sur le serveur maître

Le serveur maître doit disposer d’un serveur Web (voir ce billet pour installer simplement NGinx sur votre système) configuré avec le répertoire root par défaut: /var/www.

Comme Munin est présent dans les dépôts officiels, il suffit de saisir la commande suivant qui va installer le package maître ainsi que le package esclave histoire de pouvoir superviser son serveur de supervision…:

sudo apt-get install munin munin-node munin-plugins-extra

sudo ln -s /var/cache/munin/www /var/www/munin

sudo /etc/init.d/munin-node restart

En faisant pointer un navigateur Web vers l’URL:

http://votreserveurdesupervision/munin

Vous devriez voir s’afficher les statistiques de votre serveur. Il faut attendre quelques minutes avant de voir les premiers graphes, le temps que les bases de données soient renseignées.

Installation de Munin sur les machines noeuds

Installation des noeuds sous GNU/Linux

Là encore c’est assez simple:

sudo apt-get install munin-node munin-plugins-extra

La configuration de Muni sur les machines noeuds est centralisée dans le fichier /etc/munin/munin-node.conf. Il faut éditer ce fichier pour y configurer l’adresse IP de votre serveur maître à la ligne suivante:

# A list of addresses that are allowed to connect. This must be a

# regular expression, since Net::Server does not understand CIDR-style

# network notation unless the perl module Net::CIDR is installed. You

# may repeat the allow line as many times as you'd like

allow ^192\.168\.1\.200$

Cette configuration (à adapter à votre besoin) va autoriser la machine maître d’adresse IP 192.168.1.200 à se connecter sur cette machine noeud pour y récupérer les données à superviser.

Il faut ensuite relancer le service Munin-node pour faire prendre en compte la nouvelle configuration:

sudo /etc/init.d/munin-node restart

Installation des noeuds sous Windows

Le projet Munin ne fourni pas de « node » pour WIndows, il faut donc se retourner du coté de la communauté pour trouver notre bonheur. En l’occurrence du coté du logiciel Munin-Node-Win32 disponible au téléchargement sur cette page.  Il suffit de lancer l’installer pour que l’installation et le lancement du processus en tache de fond soit effectué (procédure testé sous Windows 7).

Installation des noeuds sous MacOS

Si vous avez à surveiller des machines sous Mac OS X, il va falloir mettre un peu plus les mains dans le cambouis. En effet, il faut obligatoire passer par l’installation des gestionnaires de paquets Fink ou MacPorts. Je vous conseille la lecture du Wiki officiel.

Configuration des plugins sur les machines noeuds

Nous allons voir dans cette sections comment configurer ce que l’on souhaite superviser sur les machines noeuds. Munin utilise le fichier  /etc/munin/plugin-conf.d/munin-node (ainsi que tous les fichiers se trouvant dans le même répertoire) pour configurer les paramètres des plugins (bien souvent de simples script Perl).

Le répertoire /etc/munin/plugins/ contient la liste des plugins utilisables par la machine noeud et le répertoire /usr/share/munin/plugins/ l’ensemble des plugins. En y regardant de plus prêt, le répertoire  /etc/munin/plugins/ fait des liens symboliques vers le répertoire /usr/share/munin/plugins/.

Pour voir la liste des plugins disponibles sur le noeud, on peut utiliser:

# sudo munin-node-configure

Exemple de l’ajout des plugins NGinx (permettant de surveiller un serveur Web NGinx) sur un noeud:

Pour faire prendre en compte un nouveau plugin sur un noeud (node) il faut faire un lien symbolique entre le fichier en question dans ce répertoire et /etc/munin/plugins/. Par exemple pour accéder aux stats de mon serveur NGinx:

sudo ln -s /usr/share/munin/plugins/nginx_status /etc/munin/plugins/nginx_status

sudo ln -s /usr/share/munin/plugins/nginx_request /etc/munin/plugins/nginx_request

Il est quelquefois necessaire d’installer des dependances pour que le plugin fonctionne.

Pour voir les dépendances nécessaire il suffit de saisir la commande:

sudo munin-node-configure --suggest | grep nginx

nginx_request | yes | no [LWP::UserAgent not found]

nginx_status | yes | no [LWP::UserAgent not found]

Il faut donc installer la librairie perl contenant le module LWP qui est présente dans le package libwww-perl sur Debian/Ubuntu:

sudo apt-get install libwww-perl

Cela a l’air OK:

sudo munin-node-configure --suggest

nginx_request | yes | yes

nginx_status | yes | yes

On peut faire prendre en compte la configuration par Munin-node:

sudo /etc/init.d/munin-node restart

Configuration du maître pour prendre en compte les machines noeuds

Une fois toutes vos machines noeuds configurés (voir le chapitre précédant), il faut maintenant modifier la configuration du serveur maître pour les prendre en compte. Là encore, fidèle à la philosophie Unix, la configuration est centralisé dans le fichier /etc/munin/munin.conf.

En plus des répertoires systèmes en début de fichier:

# The next three variables specifies where the location of the RRD

# databases, the HTML output, logs and the lock/pid files. They all

# must be writable by the user running munin-cron. They are all

# defaulted to the values you see here.

#

dbdir /var/lib/munin

htmldir /var/cache/munin/www/

logdir /var/log/munin

rundir /var/run/munin

Il faut configurer la liste des noeuds de la manière suivante:

# A simple host tree for mondomaine.com

[maitre.mondomaine.com]

address 127.0.0.1

[noeud1.mondomaine.com]

address noeud1.mondomaine.com

[noeud2.mondomaine.com]

address noeud2.mondomaine

Reste à relancer le serveur Munin pour prendre en compte la configuration:

su - munin --shell=/bin/bash

/usr/share/munin/munin-update

exit

En faisant pointer un navigateur Web vers l’URL:

http://votreserveurdesupervision/munin

Puis par exemple les graphes sur l’occupation mémoire:

Pour voir une démonstration en ligne des capacités de Munin, vous pouvez consulter ce serveur maître qui est en accès libre.

Plus de plugins ?

Un des gros avantage de Munin est le fait de pouvoir simplement écrire de nouveaux plugins en utilisant votre langage favori (nous reviendrons bientôt sur ce sujet dans un prochain billet).  Pas mal d’exemples sont proposés  dans le dépôt GitHub suivant (vous devriez trouver votre bonheur).
Catégories
Open-source Planet-libre Reseau

Mesurer le débit dans son réseau avec NutTCP

NutTCP est un outil de plus pour les administrateurs réseaux afin de mesurer simplement les liaisons entre deux machines (ou vers votre serveur dédié ou VPS sous GNU/Linux|BSD).

Installation de NutTCP

Rien de plus simple sous Debian ou Ubuntu:

sudo aptitude install nuttcp

Le logiciel se présente sous la forme d’un unique exécutable (nuttcp) qui fait office de client et de serveur selon les options qui lui sont accolés.

Un premier test basée sur TCP

Nous allons donc tester le réseau se trouvant entre deux machines (A et B soyons originaux). Nous utiliserons dans ce premier exemple un test basé sur le protocole TCP.

Sur la machine A, on lance le « serveur »:

A# nuttcp -S –nofork

Puis sur la machine client on va générer un flux TCP dans le sens B vers A (l’équivalent d’un upload). NutTCP va utiliser les ports TCP/5000 (pour le contrôle) et TCP/5001 (pour le transfert proprement dit des données). Il faut donc bien vérifier que ces deux ports sont ouverts entre vos deux machines.

B# nuttcp -b -t @IP_A

0.5068 MB / 10.59 sec = 0.4013 Mbps 0 %TX 0 %RX 0 retrans 33.81 msRTT

Dans mon test, on obtient donc un débit de 401 Kbps (0.4013 Mbps).

Pour faire le même test mais dans le sens A vers B (c’est à dire un download):

B# nuttcp -b -r @IP_A

Il est possible d’ajouter certaines options:

-l : taille du buffer de lecture et d’écriture

-w : taille du buffer permettant de définir la taile de la fenêtre TCP

Un autre test basée sur UDP

Contrairement à TCP qui utilise la totalité de la bande passante disponible, le débit des flux UDP doit être fixé au niveau de l’application. On doit donc ajouter deux options:

-u : pour forcer NutTCP à travailler en UDP

-R <debit> : pour fixer le débit du flux UDP à <debit> Kbps

Sur la machine A, on lance le « serveur » comme pour le mode TCP:

A# nuttcp -S –nofork

Puis on lance la commande suivante:

B# nuttcp -b -u -R 256 -t @IP_A

0.3057 MB / 10.02 sec = 0.2560 Mbps 96 %TX 0 %RX 0 / 313 drop/pkt 0.00 %loss

Conclusion

Un outil bien pratique à comparer à Iperf, NetPerf ou NtTCP !

Catégories
Open-source Planet-libre Reseau Systeme

Sauvegarde journalisée de votre machine avec RSnapShot

Suite à un commentaire de Xavier sur un de mes billets, je me suis penché sur l’utilisation de RSnapshot. Ce logiciel libre permet d’automatiser une sauvegarde journalisée de vos machines et ceci localement comme à distance.

RSnapShot est disponible dans la plupart des dépôts des distributions GNU/Linux et *BSD. Nous allons illustrer cet article avec une installation et une configuration de RSnapShot sur un serveur Gandi sous Ubuntu 10.04 LTS.

Installation de RSnapShot

On utilise la version disponible dans les dépôts officiel:

sudo aptitude install rsnapshot

Configuration de RSnapShot

L’ensemble de la configuration est centralisé dans le fichier /etc/rsnapshot.conf.

sudo vi /etc/rsnapshot.conf

Attention à la syntaxe dans ce fichier, RSnapShot est assez pointilleux. Il veut que tout les répertoires finissent par un / et des tabulations entre chaque variables.

Les variables importantes à configurer sont les suivantes:

snapshot_root   /.snapshots/

La variable snapshot_root permet de configurer le répertoire racine ou les sauvegardes seront stockées. Ce répertoire peut être sur le même disque que le disque système (c’est le cas de la configuration par défaut avec l’utilisation du répertoire /.snapshots/).

Je vous conseille pour ma part d’utiliser si possible un répertoire stocké sur un deuxième disque physique. Par exemple sur mon serveur Gandi, j’ai un deuxième disque qui est monté sur le répertoire /srv/backup. Je vais donc configurer la variable à /srv/backup/snapshots/ (noter le / à la fin du répertoire !).

Exemple: snapshot_root /srv/backup/snapshots/

cmd_ssh /path/to/ssh

Si vous voulez utiliser les fonctions de sauvegarde de serveur distant (en utilisant le protocole SSH), il faut dé-commenter la ligne précédente. Si vous avez besoin de passer des arguments spécifique à SSH, il faudra compléter la ligne ssh_args.

Exemple: cmd_ssh /usr/bin/ssh

interval monthly 3

Activation de la sauvegarde mensuelle (désactivé par défaut).

On passe ensuite aux variables permettant de configurer ce que l’on veut sauvegarder.

Sauvegardes locales

On parle ici d’une sauvegarde journalisée de répertoires de la machine ou RSnapShot est installé.

backup /home/ localhost/

Le répertoire /home/ sera sauvegardé dans le sous répertoire $snapshot_root/localhost/.

Exemple:

backup /home/ localhost/

backup /etc/ localhost/

backup /var/svn/ localhost/

Sauvegardes distantes

On peut également sauvegarder des répertoires de machines distantes. On utilise pour cela la configuration suivante:

backup root@example.com:/etc/  example.com/    +rsync_long_args=–bwlimit=1024,exclude=core

On va ainsi sauvegarder le répertoire /etc/ de la machine exemple.com en utilisant une connexion SSH avec l’utilisateur root (il faut bien sur que la connexion SSH entre votre machine exécutant RSnapShot et example.com soit automatisée). En bonus on demande à RSnapShot de ne pas sauvergarder les fichiers core (exclude=core) et de limiter la bande passante à 1 Mbps (–bwlimit=1024).

Sauvegardes en utilisant des scripts

Une autre fonctions intéressantes de RSnapShot est la possibilité d’utiliser des script shell pour automatiser des sauvegardes un peu plus complexes.

Par exemple imaginons que l’on veuillent sauvegarder les données de son serveur SVN. On commence par créer le script shell /usr/local/bin/backup-svn.sh:

#!/bin/sh

# Backup SVN


svnrepo= »/var/svn/ »

for i in `ls $svnrepo`

do

svnadmin -q dump $svnrepo/$i > $i.svndump

gzip -f $i.svndump

rm $i.svndump

done

Puis on le rend exécutable:

sudo chmod a+x  /usr/local/bin/backup-svn.sh

Enfin on configure RSnapShot:

backup_script /usr/local/bin/backup-svn.sh localhost/svn/

Le script backup-svn.sh va être lancé à partir du répertoire localhost/svn/

Il est bien sur possible de faire des scripts pour d’autres besoins: sauvegarde de bases de données MySQL par exemple.

Utilisation de RSnapShot

On commence par valider le fichier de configuration:

sudo rsnapshot configtest

Syntax OK

Simulation d’une sauvegarde journalière (cela va afficher ce que RSnapShot va faire mais sans le faire…):

sudo rsnapshot -t hourly

echo 3531 > /var/run/rsnapshot.pid

mkdir -m 0700 -p /srv/backup/snapshots/

mkdir -m 0755 -p /srv/backup/snapshots/hourly.0/

/usr/bin/rsync -a –delete –numeric-ids –relative –delete-excluded /home \

/srv/backup/snapshots/hourly.0/localhost/

mkdir -m 0755 -p /srv/backup/snapshots/hourly.0/

/usr/bin/rsync -a –delete –numeric-ids –relative –delete-excluded /etc \

/srv/backup/snapshots/hourly.0/localhost/

mkdir -m 0755 -p /srv/backup/snapshots/hourly.0/localhost/

mkdir -m 0755 -p /srv/backup/snapshots/tmp/

cd /srv/backup/snapshots/tmp/

/home/nicolargo/bin/backup-svn.sh

cd /home/nicolargo/

sync_if_different(« /srv/backup/snapshots/tmp/ », \

« /srv/backup/snapshots/hourly.0/localhost/svn/ »)

mkdir -m 0755 -p /srv/backup/snapshots/hourly.0/

/usr/bin/rsync -a –delete –numeric-ids –relative –delete-excluded \

–exclude=core –bwlimit=1024 –rsh=/usr/bin/ssh \

nicolargo@exemple.com:/home /srv/backup/snapshots/hourly.0/sam/

mkdir -m 0755 -p /srv/backup/snapshots/hourly.0/

/usr/bin/rsync -a –delete –numeric-ids –relative –delete-excluded \

–exclude=core –bwlimit=1024 –rsh=/usr/bin/ssh \

nicolargo@exemple.com:/etc /srv/backup/snapshots/hourly.0/sam/

touch /srv/backup/snapshots/hourly.0/

Test en ligne de commande:

sudo rsnapshot hourly

Le répertoire contenant la première sauvegarde devrait être créé sous /srv/backup/snapshots/hourly.0.

Enfin on automatise le lancement en éditant la crontab système (root):

sudo crontab -e -u root

0 */4 * * * /usr/bin/rsnapshot hourly

30 23 * * * /usr/bin/rsnapshot daily

0 23 * * 0 /usr/bin/rsnapshot weekly

30 22 28 * * /usr/bin/rsnapshot monthly

Pour une liste exhaustive des fonctions proposées par RSnapShot, je vous conseille la lecture de la documentation officielle (en Anglais).

Et voili, merci encore à Xavier pour cette belle découverte.

Catégories
Open-source Reseau Web

Installation serveur NAT-PMP sous FreeBSD

MiniUPnP est une implémentation libre du protocole NAT-PMP. Développé par Apple, ce successeur de UPnP IGD permet de configurer automatique et à la demande des applications des règles de NAT sur votre routeur d’accès. Free vient d’ajouter cette fonction sur le firmware des Freebox.

Nous allons voir dans ce billet comment fonctionne ce protocole et comment transformer votre routeur/firewall PF FreeBSD en un daemon NAT-PMP.

C’est quoi NAT-PMP ?

NAT-PMP est un protocole basée sur le protocole Bonjour. Ce dernier utilise des trames UDP sur le port 5351 qui sont envoyé vers l’adresse de la passerelle par défaut de votre réseau.

Il permettant à une application de:

  • récupérer son adresse IP publique (comment le PC va être vu sur Internet)
  • ajouter une règle de NAT PF (ou IPFW) sur le routeur

Si l’adresse publique de la passerelle par défaut change, une alerte au format multicast (adresse 224.0.0.1 sur le port 5351) sera envoyée sur le réseau. Elle contiendra en donnée la nouvelle adresse.

Installation du daemon sur FreeBSD

Le daemon en question s’appelle minipnpd et est présent dans les ports de FreeBSD (/usr/ports/net/miniupnpd).

L’installation est classique:

portinstall net/miniupnpd

Il faut également ajouter les règles suivantes dans votre fichier de configuration PF (/etc/pf.conf par défaut):

# NAT section
# UPnPd rdr anchor
rdr-anchor « miniupnpd »

# Rules section
# uPnPd rule anchor
anchor « miniupnpd »

puis relancer les règles PF:

pfctl -f /etc/pf.conf

et enfin ajouter la ligne suivante dans votre fichier /etc/rc.conf:

miniupnpd_enable= »YES »

La configuration doit se faire par un fichier /usr/local/etc/miniupnpd.conf. Vous pouvez utiliser le template suivant (à adapter à votre réseau):

# WAN network interface
ext_ifname=em0
# if the WAN interface has several IP addresses, you
# can specify the one to use below
#ext_ip=

# there can be multiple listening ips for receiving SSDP traffic.
# the 1st IP is also used for UPnP Soap traffic.
listening_ip=192.168.0.254
port=5555

# bitrates reported by daemon in bits per second
bitrate_up=131072
bitrate_down=524288

# default presentation url is http address on port 80
#presentation_url=

# report system uptime instead of daemon uptime
system_uptime=yes

# notify interval in seconds default is 30 seconds.
#notify_interval=240

# log packets in pf
#packet_log=no

# uuid : generated by the install a new one can be created with
# uuidgen
uuid=%%UUID%%

# UPnP permission rules
# (allow|deny) (external port range) ip/mask (internal port range)
# A port range is <min port>-<max port> or <port> if there is only
# one port in the range.
# ip/mask format must be nn.nn.nn.nn/nn
allow 1024-65535 192.168.0.0/24 1024-65535
deny 0-65535 0.0.0.0/0 0-65535

Pour lancer le daemon, il faut lancer la commande suivante:

/usr/local/etc/rc.d/miniupnpd start

Pour tester

Le plus simple est d’utiliser une des applications compatibles UPnP (voir liste dans le Wiki) ou bien d’utiliser le client en ligne de commande miniupnpc (compilable sous Linux, BSD, Mac OS X et Windows…).

Conclusion

Bien sûr ce daemon peut présenter un trou de sécurité assez important (possibilité d’ajouter des règles sur votre Firewall), il faut donc prendre toutes les précautions nécessaires sur les réseaux sensibles (notamment au niveau de la configuration de la section UPnP permission rules).

Catégories
Open-source Systeme

Tester d’autres OS à partir d’une clès USB

Si vous aimez tester d’autres systèmes d’exploitation, UNetBootIn va sûrement vous intéresser. Ce logiciel open-source disponible sous Linux ou Windows (XP ou Vista) automatise la création d’une live-usbkey. Il prend en entré une liste d' »operating system » (de Linux Mint à FreeBSD) ou bien un fichier ISO et va construire pour vous une clès USB live. Il ne restera plus qu’à booter sur ce support pour tester le système en question sur votre PC.

Installation du logiciel UNetBootIn

Sous Windows, il faut récuperer l’éxecutable ici.

Sous Linux, c’est par là (ne pas oublier de le rendre executable avec une bonne veille commande):

chmod +x unetbootin-linux-200

Sur ma distribution Ubuntu 8.10, j’ai également dû installer le package p7zip-full:

sudo apt-get install p7zip-full

Lancement et utilisation du logiciel

On double clique sur l’exécutable, l’écran suivant devrait s’afficher:

Image 1.png

Il ne reste plus qu’a:

  • sélectionner l’OS parmi la liste
  • sélectionner la version de l’OS
  • sélectionner le disque USB (clès, disque dur externe…) cible
  • cliquer sur OK

Image 1.png

Enfin, il ne reste plus qu’a redémarrer votre machine, sélectionner dans le bios un boot sur la clés USB et… utiliser le nouvel OS !

Du vrai bonheur en barre ce logiciel 🙂

Catégories
Open-source Systeme

Toutes les expressions régulières sur une page A4

… enfin presque toutes… C’est sur le site AddedBytes que j’ai trouvé cet aide mémoire centralisant toutes les expressions régulières sur une simple page A4. Idéal pour les administrateurs Unix !

regular-expressions-cheat-sheet-v2.png

A imprimer et a garder sur vos bureaux !

Catégories
Open-source Reseau

De IPFW à PF

istockphoto_143506_burning_fire_wall.jpgFidèle utilisateur de l’operating système FreeBSD pour toutes les fonctions réseaux (notamment les Firewall), je suis tombé il y a quelques temps sur un problème d’interopérabilité entre l’utilisation du couple CARP/PFSYNC (le truc pour faire de la redondance de Firewall) avec IPFW.

J’ai donc décidé de switcher de IPFW vers PF. Je vais donc abordé dans ce billet les quelques choses à avoir en tête si vous suivez le même chemin… Si vous souhaitez vous formez sur PF, je vous conseille la lecture de l’excellent article paru dans Linux Magazine HS n°29, dont vous trouverez une version électronique ici.

Un peu d’histoire

IPFW (IPFireWall) est un module logiciel permettant de faire du filtrage de paquets réseau sous BSD (c’est actuellement le module de firewall utilisé par défaut sous Mac OS X).

Jusqu’à la version 3.0 de OpenBSD, ce module était intégré par défaut au noyau du système, mais de sombres histoires de licences et de batailles interne entre Darren Reed (l’auteur de IPFW) et les développeurs d’OpenBSD ont débouché par son remplacement par PF (Packet Filter).

PF est maintenant fourni en standard sur l’OS FreeBSD (depuis la version 5.3).

Les principales différences entre IPFW et PF

Voici une liste non-exhaustive:

  • le fichier de configuration unique (/etc/pf.conf) comprend, la définition des règles (comme sous IPFW) mais aussi la configuration du NAT et du PAT (délégué au processus IPNAT avec IPFW)
  • comportement atomique du chargement de la configuration: si une erreur est détectée dans le fichier de configuration, aucune règle n’est appliquée
  • l’interprétation des règles est de type “last matching rules wins”: la dernière règle qui correspond au paquet est appliquée
  • le suivi de connexions complexes comme FTP se fait via un module externe (ftp-proxy)
  • il est possible de rediriger les paquets en fonction de l’OS émetteur (ne marche pas dans tout les cas de figures)
  • assure une compatibilité native avec CARP et PFSYNC pour faire de la redondance active de Firewall

Architecture du fichier de configuration /etc/pf.conf

Le fichier comporte plusieurs sections (l’ordre est important).

1) Définition des macros, listes et des tables

En plus des listes (comme sous IPFW), il est possible d’utiliser des tables pour stocker des adresses IP. L’avantage des tables par rapport aux listes est la rapidité d’accès à l’information. En effet, basées sur des tables de hachage, le temps pour accéder à une information est constant quel que soit la taille de la table. De plus il est possible de modifier dynamiquement ces tables (à l’aide de la commande “pfctl -t …”) sans avoir à recharger les règles.

Quelques exemples de macros:

Définition

ip_interne=”192.168.1.254”

ip_externe=”80.80.80.80”

Utilisation dans les règles

pass quick proto tcp from $ip_interne to any port 80

pass quick from $lan_interne to any keep state

Quelques exemples de listes:

Définition

lan_interne=”{ 192.168.1.0/24 192.168.2.0.24 }”

lan_interne_saufdmz=”{ 192.168.1.0/24 192.168.2.0.24 !192.168.2.0/29 }”

web_ports=”{ http https ftp }”

Utilisation dans les règles

pass quick from $lan_interne to any keep state

Quelques exemples de tables:

Définition

table <ip_clients> “{ 192.168.1.10 192.168.1.100 }”

Utilisation

pass quick from <ip_clients> to any keep state

Modification de la table

pfctl -t ip_clients -T add 192.168.1.101

pfctl -t ip_clients -T delete 192.168.1.101

2) Options et normalisation des paquets

Personnellement, j’utilise les options suivantes:

# On ne filtre pas sur l’interface locale

set skip on lo

# En cas de blocage, on envoie un RST sur les paquets TCP

# et UNREACHABLE sur les ICMP

set block-policy return

# On normalise les paquets avec gestion de la fragmentation

scrub in all fragment reassemble

3) Gestion des queues pour la QoS

Permet de faire de la qualité de service: CBQ, Priorité et HFSC. Il faut cependant passer par un module externe: altq.

Je reviendrai sûrement sur ces fonctions 12c4.

4) Translation d’adresse (NAT) et re-direction de ports (PAT)

Contrairement à IPFW qui ne gérait pas la translation d’adresse et de port (il fallait utiliser IPNAT), PF s’acquitte parfaitement de ces taches. La syntaxe est très proche de celle utilisée par IPNAT.

Exemple de NAT:

nat pass on eth0 from eth1:network to any -> $ip_externe

On notera l’utilisation de la macro eth1:network qui donne le réseau associé à l’interface réseau eth1

binat on $if_externe from 192.168.1.100 to any -> 80.80.80.81

Exemple de PAT:

rdr on $if_externe from any to $ip_externe port 8080 -> $ip_serveur port 80

5) Règles de filtrage

On entre (enfin ?) dans le vif du sujet avec l’adaptation des règles de IPFW vers PF.

La première chose à se rappeler est que l’interprétation des règles est de type “last matching rules wins”: la dernière règle qui correspond au paquet est appliquée. C’est le contraire de la logique que l’on suivait avec IPFW. Cependant, si comme moi vous avez du mal à réfléchir à l’envers, il reste la possibilité d’utiliser l’option quick. Quand cette dernière est présente dans une règle, PF arrête l’interprétation des règles suivantes.

L’option permettant de faire du suivi de connexion (sur TCP mais aussi sur UDP ou tout autre protocole IP) est “keep state” (attention c’était “keep-state” avec un – sous IPFW…). Cette option est maintenant ajouté par défaut sur les OS BSD (depuis OpenBSD 4.0 et FreeBSD 7.0).

Exemple de filtres:

pass in on $int_if from $internal_net to any

pass out on $ext_if proto tcp all modulate state flags S/SA

pass out on $ext_if proto { udp, icmp } all keep state

pass in on $ext_if inet proto tcp from any to $webserver port 80 flags S/SA synproxy state

Gestion de votre nouveau Firewall PF

La gestion de la configuration de votre Firewall PF se fait via l’utilitaire pfctl.

Quelques commandes utiles:

Vérification de la syntaxe du fichier /etc/pf.conf

pfctl -n -f /etc/pf.conf

Activation du filtrage:

pfctl -e

Dés-activation du filtrage:

pfctl -d

Rechargement des règles:

pfctl -f /etc/pf.conf

Affichage des règles de filtrage:

pfctl -s rules

Affichage des NAT et PAT:

pfctl -s nat

Affichage l’état des sessions existantes (connections):

pfctl -s state

Affichage du fichier de log (pour voir les paquets rejetés):

tcpdump -r /var/log/pflog

ou bien:

tcpdump -i pflog0 -qea -ttt

Conclusion

Je dois vous avouer que j’étais très réticent pour ce passage de IPFW et PF mais après quelques heures d’utilisations je pense que ce système de filtrage est très bon et aussi facile à administrer (en tout cas beaucoup plus simple que l’usine à gaz IPTABLES… je sais je troll…).

Catégories
Open-source Systeme

Video de la fusion de Compiz et Beryl

« Compiz fusion », voici le nom de code du futur gestionnaire de bureau 3D libre qui sera disponible prochainement sur Linux et BSD. C’est la fusion (enfin…) des deux projets phares: Compiz et Beryl.

Pour vous faire un peu saliver, voici une démonstration en vidéo.

Vivement le test final…