Catégories
Open-source Reseau Systeme

Nagisk passe en version 1.1

Nagisk, le script Perl permettant de surveiller son serveur Asterisk à partir de Nagios passe en version 1.1.

Les nouveautés sont les suivantes:

  • supervision des cartes Zaptel connecté(s) au serveur
  • supervision des ports des cartes Zaptel

Toutes les infos (procedure d’installation/configuration) sont disponibles sur cette page.

Catégories
Open-source Reseau Systeme

Durées et fréquences des checks Nagios

nagios_logo.pngPour surveiller votre réseau, Nagios utilise un certain nombre d’objets (machines, services, contacts…). Par défaut, un objet hérite une grande partie de ses paramètres du template nommé « generic-* ». Nous allons dans ce billet nous focaliser sur les notions de temps et de fréquences de ces objets.

Pour rappel, à un instant t, un objet peut avoir un des les états suivants:

  • OK: tout va bien, votre objet fonctionne correctement
  • WARNING: votre objet ne fonctionne pas nominalement
  • CRITICAL: votre objet ne fonctionne plus
  • UNKNOWN: impossible de déterminer l’état de votre objet

Un exemple: imaginons un service qui surveille la débit de votre liaison Internet…

  • OK: le débit est inférieure à 70% de la bande passante totale
  • WARNING: la débit est supérieure à 70% de la bande passante totale
  • CRITICAL: la liaison Internet est DOWN (plus de connectivité avec Internet)
  • UNKNOWN: impossible de récupérer les valeurs du débit

Définition de la période d’activité d’un objet

La variable check_period permet de définir l’intervalle de temps durant lequel l’objet est actif. On définie une période de temps en utilisant la structure timeperiod.

Par exemple pour définir une période de temps correspondant aux heures ouvrées de votre entreprise vous pouvez utiliser la définition suivante:

define timeperiod {

timeperiod_name workhours

alias Heures ouvrées

monday 09:00-18:00 ; Lundi

tuesday 09:00-18:00; Mardi

wednesday 09:00-18:00; Mercredi

thursday 09:00-18:00; Jeudi

Friday 09:00-18:00; Vendredi

}

La déclaration de cette période de temps dans notre objet (par exemple un service) se fera ainsi:

define service {

check_period workhours

}

Définition des intervalles de vérification d’un objet

Quand on se trouve dans une période d’activité d’un service, plusieurs paramètres rentrent en jeu pour fixer la durée et la fréquence des vérifications (checks) du objet en question.

Quand un objet est OK, il est vérifié toutes les check_interval minutes. Si il passe WARNING, CRITICAL ou UNKNOWN, il est alors vérifié max_check_attempts fois à un intervalle de retry_interval minutes. Si l’état de l’objet n’est pas revenu à OK au bout des max_check_attempts essais, l’intervalle de vérification redevient de check_interval minutes…

Je sais ce n’est pas très simple mais ce schéma devrait vous aider à comprendre.

nagios-check.jpg
Un exemple de paramètrage avec un valeur de check_interval (quand tout va bien) à 10 minutes puis un retry_interval (quand cela commence à aller mal) à 2 minutes et un nombre de max_check_attempts à 3:

define service {

check_interval 10

retry_interval 2

max_check_attempts 3

}

Et les notifications ?

Il existe des variables permettant de fixer comment les notifications sont remontés aux administrateurs.

La première variable est first_notification_delay. Elle permet de définir le temps (en secondes) que Nagios doit attendre avant d’envoyer une notification quand un objet passe d’un état OK à un état WARNING, CRITICAL ou UNKNOWN. Une valeur de 0 permet d’envoyer la notification dès ce changement d’état.

La variable notification_interval permet, en cas de problème sur un objet, de fixer l’intervalle de temps (en minutes) entre deux notifications. Pour que Nagios n’envoie qu’une seule fois une alerte, il faut fixer cette variable à 0.

Par exemple, pour que la première notification se fasse immédiatement, sans répétition, un objet doit être défini ainsi:

define service {

first_notification_delay 0

notification_interval 0

}

Conclusion

Comme on vient de le voir il est relativement facile de configurer finement les fréquences et durées de vérifications en fonction de l’importance des objets à surveiller.

Catégories
Open-source Reseau Systeme

Enfin un livre de référence sur Nagios en Français

Il n’y a qu’à voir les demandes des lecteurs de ce blog concernant Nagios et les outils de supervision open-source pour comprendre qu’il y a manifestement un manque de documentations en Français sur le sujet. Heureusement, quelques bons samaritains prennent les choses en main.

Ainsi, en plus de se lancer dans la traduction de la documentation officielle et de maintenir le portail Nagios-fr, Olivier va publier dans les prochains jours un livre nommé « Nagios et la supervision Open Source ».

ojan-nagios.png

« NAGIOS et la supervision Open Source – De l’installation à l’optimisation » (Olivier JAN)

Ce bouquin a de forte chance de devenir le livre de chevet des administrateurs réseaux. Vous pouvez dès à présent en commander un exemplaire (livraison prévue mi-novembre 2008).

Catégories
Open-source Reseau

Mise à jour de Nagios 3.0.4

La nouvelle version de Nagios (3.0.4) est en ligne. La liste des changements est disponible içi. Comme toujours, il est fortement conseillé de mettre à jour vos serveurs. Pour celà vous pouvez suivre une de ces procédures:

Je viens de tester la migration d’une version 3.0.3 vers 3.0.4 sans problème:

A vous de jouer !

Catégories
Open-source Reseau Systeme

Supervision d’Asterisk avec Nagios

Les plugins pour surveiller son serveur SIP Asterisk à partir de Nagios sont assez nombreux. Mais aucun d’eux ne me convenait parfaitement. J’ai donc écrit un petit script nommé Nagisk (quel humour…) a exécuter localement sur le serveur Asterisk. J’utilise NRPE pour récupérer la sortie de ce script et l’intégrer à Nagios.

Nagisk permet de:

  • récupérer la version d’Asterisk (et donc au passage de savoir si le serveur est lancé…)
  • récupérer le nombre de d’utilisateurs SIP (online et offline)
  • récupérer le nombre de communications actives (appels en cours)

Récupération de Nagisk

J’ai créé un nouveau projet sous GitHUB ou vous pouvez télécharger la dernière version disponible de Nagisk.

Installation de Nagisk

Avant d’installer Nagisk sur votre serveur Asterisk, il faut d’abord y installer NRPE (par exemple en suivant ce tuto).

On commence par décompresser l’archive préalablement récupérée:

tar zxvf nagisk-1.2.tgz

Puis on copie le script Perl dans le répertoire des plugins Nagios:

cd nagisk

cp nagisk.pl /usr/local/nagios/libexec

On lui donne les bons droits:

chown nagios:nagios /usr/local/nagios/libexec/nagisk.pl

chmod 750 /usr/local/nagios/libexec/nagisk.pl

Certaines variables sont en durs dans le code (rien de méchant, juste le path pour accèder à Asterisk). J’utilise personnellement la commande sudo pour executé les commandes sur Asterisk afin que le script soit lancé par l’utilisateur nagios. Pour celà j’ai ajouté la ligne suivante dans le fichier /etc/sudoers:

nagios    ALL= NOPASSWD: /usr/sbin/asterisk

Configuration de NRPE pour lancer Nagisk

Il suffit d’ajouter les lignes suivantes dans le fichier de configuration de NRPE (/usr/local/nagios/etc/nrpe.conf):

command[check_asterisk_version]=/usr/local/nagios/libexec/nagisk.pl -c version

command[check_asterisk_peers]=/usr/local/nagios/libexec/nagisk.pl -c peers

command[check_asterisk_channels]=/usr/local/nagios/libexec/nagisk.pl -c channels

command[check_asterisk_zaptel]=/usr/local/nagios/libexec/nagisk.pl -c zaptel

command[check_asterisk_span]=/usr/local/nagios/libexec/nagisk.pl -c span -s 1

ps: il est possible de faire plus propre en utilisant les arguments NRPE mais je trouve cette solution plus lisible…

Une fois le fichier mofifié, il faut relancer NRPE:

/etc/init.d/nrpe restart

Configuration de Nagios pour surveiller son serveur Asterisk

Si vous souhaitez superviser un serveur SIP Asterisk dont le host_name est sip, il suffit d’ajouter les lignes suivantes dans un de vos fichiers de configurations:

define service{
use                     generic-service
host_name               sip
service_description     Check SIP
servicegroups           sip
check_command           check_nrpe!check_asterisk_version
}

define service{
use                     generic-service
host_name               sip
service_description     Check SIP peers
servicegroups           sip
check_command           check_nrpe!check_asterisk_peers
}

define service{
use                     generic-service
host_name               sip
service_description     Check SIP channels
servicegroups           sip
check_command           check_nrpe!check_asterisk_channels
}

define service{
use                     generic-service
host_name               sip
service_description     Check Zaptel card
servicegroups           sip
check_command           check_nrpe!check_asterisk_zaptel
}

define service{
use                     generic-service
host_name               sip
service_description     Check Zaptel Span 1
servicegroups           sip
check_command           check_nrpe!check_asterisk_span
}

Et voilà le résultat:

Conclusion

Nagisk semble remplir sa fonction, le script tourne depuis quelques temps chez moi sans problème. Il est distribué sous licence libre GPL v3 et il est bien sûr possible de le modifier pour l’adapter à vos besoins.

Catégories
Open-source Reseau Systeme

Installation de NRPE depuis les sources

Afin de disposer de la dernière version de NRPE (le plugin pour superviser vos serveurs GNU/Linux, BSD ou Mac OS X sous Nagios), il est parfois nécessaire de la compiler depuis les sources. Voici donc une simple procédure pour installer NRPE 2 et les plugins Nagios « standards » sous une distribution GNU/Linux.

Récupération des sources

Nous partons, bien sûr, sur l’hypothèse ou votre machine cible (c’est à dire celle ou vous aller compiler NRPE) dispose des logiciels de développement de base (configure, make, gcc…).

Si votre machine dispose d’un accès internet, vous pouvez saisir les commandes suivantes (en remplacent les numéros de versions par les dernières disponibles):

wget http://surfnet.dl.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz

wget http://heanet.dl.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.13.tar.gz

Préalablement à l’installation de NRPE, il faut créer un utilisateur ‘nagios’ sur votre machine:

adduser nagios

Pour des raisons de sécurité, il est préférable que cet utilisateur n’ait pas de shell:

vipw

Remplacer la ligne:

nagios:x:500:500::/home/nagios:/bin/bash

Par:

nagios:x:500:500::/home/nagios:/bin/noshell

Installation de NRPE

On lance la fameuse séquence:

tar zxvf nrpe-2.12.tar.gz

cd nrpe-2.12

./configure

make all

make install

Lors de la compilation il est possible qu’il manque des dépendances. Par exemple, si vous avez le message suivant:

checking for SSL headers… configure: error: Cannot find ssl headers

Il faut installer les librairies SSL (libssl-dev sous Ubuntu):

apt-get install libssl-dev

Installation des plugins Nagios standards

Pareil que miguel…:

tar zxvf nagios-plugins-1.4.13.tar.gz

cd nagios-plugins-1.4.13

./configure

make install

Puis une initialisation du script de configuration (/usr/local/nagios/etc/nrpe.conf):

mkdir /usr/local/nagios/etc

cp sample-config/nrpe.cfg /usr/local/nagios/etc

Correction des droits sur les fichiers

De base, les plugins sont installés avec les droits de l’utilisateur qui à lancé la compilation. Pour être sûr que NRPE puisse lancer les plugins, on doit saisir la commande suivante:

chown -R nagios:nagios /usr/local/nagios/

Lancement automatique au démarrage

Un script standard est fourni dans les sources:

cp init-script /etc/init.d/nrpe

chmod 755 /etc/init.d/nrpe

Configuration de NRPE

Sous GNU/Linux, suivre ce tutoriel, sous BSD et Mac OS X, suivre celui là.

Catégories
Open-source Reseau

Installation de BASE (reporting snort)

Avoir un Firewall c’est bien, y installer un logiciel de détection d’intrusion (IDS) c’est encore mieux. Mais pour atteindre les sommets de la sécurité informatique, il faudra passer par une étape ingrate: l’analyse des logs générés par votre IDS…

SNORT est un IDS libre facile à installer sur les OS GNU/Linux et BSD. Il produit en sorti des logs avec les alertes repérées sur votre réseau. Ces logs peuvent devenir très volumineux et donc impossible à analyser. Heureusement, BASE (de SecureIdeas) est là pour vous donner un coups de main.

BASE est une interface Web permettant d’analyser les logs de SNORTS stockés dans une base de données MySQL (ou PgSQL).

capture_200810095414.jpg

Installation de base sous une GNU/Linux Fedora

On commence par installer la librairie AdoDB pour permettre à l’application BASE de communiquer avec la base de donnée.

cd /var/www

wget http://ovh.dl.sourceforge.net/sourceforge/adodb/adodb505.tgz

tar zxvf adodb505.tgz

ln -s adodb5 adodb

rm adodb505.tgz

On récupère ensuite la dernière version de BASE sur le site officiel (http://base.secureideas.net/).

wget http://ovh.dl.sourceforge.net/sourceforge/secureideas/base-1.4.1.tar.gz

tar zxvf base-1.4.1.tar.gz

ln -s base-php4 base

chown -R apache:apache base base-php4

rm base-1.4.1.tar.gz

On finalise l’installation en se rendant, à l’aide d’un navigateur Web, vers la page suivante: http://<adresse-ip-serveur>/base/

Puis on suit le wizard avec en premier la vérification des pré-requis:

capture_200810095022.jpg

on choisit ensuite la langue (1), le chemin d’accès à AdoDB (2) puis on continu (3):

capture_200810095101.jpg

on configure la base de donnée (1 et 2) puis on continu (3):

capture_200810095139.jpg

on force une authentification sur les accès à BASE (1), le login/password (2) et on continu (3):

capture_200810095241.jpg

On finalise l’installation :

capture_200810095305.jpg

capture_200810095329.jpg

Et voilà, il ne reste plus qu’a consulter régulièrement les rapports générés par ces beaux outils.

Utilisation de BASE

Il suffit de se rendre à l’URL suivante: http://<adresse-ip-serveur>/base/

Les rapports sont disponibles par jours, derniers 24h, derniers 72h, alertes les plus récentes, les plus fréquentes…

Catégories
Open-source Reseau Systeme

Installation de Zenoss sous GNU/Linux

Tout comme Nagios, Zenoss est un outil de supervision open-source gratuit (il existe une version commerciale comportant plus d’options). Il se base sur une application Web qui va surveiler les noeuds de votre réseau et générer des rapports si chers aux yeux des décideurs informatiques…

Nous allons, dans ce premier billet, voir comment installer Zenoss Core (c’est à dire la version open-source sous licence GPL) sur une distribution GNU/Linux Fedora.

Catégories
Open-source Reseau Systeme

Autoriser le FTP avec un firewall PF

Si comme moi, vous utilisé la couche PF (sous OS BSD) pour protéger votre réseau des attaques extérieures, la problématique de la compatibilité du protocole FTP avec la translation d’adresse NAT devrait se poser à vous.

Nous allons donc dans ce billet voir comment configurer votre Firewall PF comme un proxy FTP efficace.

Un peu de théorie…

Si vous avez déjà eu à coder des règles de Firewall pour le protocole FTP (actif ou passif), vous savez que cela nécessite l’ouverture d’un grand nombre de ports TCP. L’idée développé dans ce billet est de passer par un mandataire (un proxy hébérgé sur votre Firewall écoutant sur le port TCP 8021) qui va effectuer les requêtes FTP à la place de votre client.

FTP proxy - Nicolargo.png

Installation de ftp-proxy

ftp-proxy est un daemon fourni en standard avec les OS BSD. Pour le lancer au démarrage du Firewall, il faut ajouter les lignes suivantes à votre fichier /etc/rc.conf:

# FTP Proxy

ftpproxy_enable= »YES »

ftpproxy_flags= »-a @IP-PUBLIQUE« 

ou vous allez remplacer @IP-PUBLIQUE par l’adresse IP publique de votre Firewall. Il est possible de changer le port d’écoute par défaut de ftp-proxy en utilisant l’option -.

Pour lancer le daemon:

/etc/rc.d/ftp-proxy start

Configuration de PF pour utiliser ftp-proxy

La première chose est de configurer les règles de NAT et de PAT en utililisant les ancres pré-définies pour ftp-proxy. Pour cela, il faut ajouter les deux lignes suivantes dans la section NAT de votre fichier /etc/pf.conf.

nat-anchor « ftp-proxy/* »

rdr-anchor « ftp-proxy/* »

Nous allons ensuite forcer les paquets TCP de vos clients (venant de votre LAN) ayant comme port de destination 21 à être re-routé vers le daemon ftp-proxy qui écoute sur le port 8021.

rdr pass proto tcp from any to any port 21 -> 127.0.0.1 port 8021

Ensuite, on autorise dans la section règles de votre fichier /etc/pf.conf, les flux FTP partant de votre Firewall.

anchor « ftp-proxy/* »

pass out proto tcp from self to any port 21

Conclusion

Voici donc un moyen simple et efficace de gérer vos connections FTP sortantes. ftp-proxy peut également être utilisé pour gérer les accès entrants vers un serveur FTP hébergé sur votre réseau local. J’y reviendrai certainement dans un prochain billet.

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…).