K-Tux » remote

Unhide : découverte des processus et ports cachés

KXan — Thu, 24 Nov 2011 13:53:42 +0000

Unhide est un outil simple de détection de process et de ports cachés qui n'apparaîtraient pas avec les outils classiques. Il a le bon goût d'être Open Source et disponible également pour les plateformes sous Windows. Commençons dans un premier temps par rapatrier et détarer l'archive de l'outil. La dernière version en date à l'heure de la manip est estampillée du 13 Janvier 2011. L'installation est très simple, mais rompt complètement avec la routine des ./configure; make && make install à laquel on est habitué. Ici, il s'agit simplement de compiler le code c qui va bien afin d'utiliser les outils. Encore une fois, le README.txt est à disposition et nous donne les bonnes inforamtions.

$ wget http://downloads.sourceforge.net/project/unhide/unhide-20110113.tgz
$ tar xzvf unhide-20110113.tgz
$ cd unhide-20110113
$ gcc --static unhide.c -o unhide
$ gcc --static unhide-tcp.c -o unhide-tcp
$ gcc -Wall -O2 --static -pthread unhide-linux26.c -o unhide-linux26

On se retrouve directement les exécutables sous la main. Ils sont 3 : unhide, unhide-linux26 et unhide-tcp. Commençons par unhide tout court. Cet outil est destiné à démasquer les processus cachés. Un premier run nous renvoie les options à fournir pour que cela fonctionne :

# unhide
Unhide 20110113
http://www.unhide-forensics.info

usage: unhide proc | sys

Très succint, n'est-ce pas ? Clair aussi : proc pour lister les processus cachés en utilisant la comparaison entre ps et /proc, et sys pour comparer ps avec les informations issues des appels système.

# unhide proc
Unhide 20110113
http://www.unhide-forensics.info

[*]Searching for Hidden processes through /proc scanning

Found HIDDEN PID: 762
Command: /usr/sbin/console-kit-daemon

Found HIDDEN PID: 763
Command: /usr/sbin/console-kit-daemon

Found HIDDEN PID: 764
Command: /usr/sbin/console-kit-daemon

Found HIDDEN PID: 1749
Command: auditd

Found HIDDEN PID: 3199
Command: dsmcad

Found HIDDEN PID: 3200
Command: dsmcad
[...]

Voyons ce que ça donne pour sys. Personnellement, j'ai complète correspondance pour sys et pour proc.

# unhide sys
Unhide 20110113
http://www.unhide-forensics.info

[*]Searching for Hidden processes through getpriority() scanning

Found HIDDEN PID: 762
Command: /usr/sbin/console-kit-daemon

Found HIDDEN PID: 763
Command: /usr/sbin/console-kit-daemon

Found HIDDEN PID: 764
Command: /usr/sbin/console-kit-daemon
[...]

[*]Searching for Hidden processes through getpgid() scanning

Found HIDDEN PID: 762
Command: /usr/sbin/console-kit-daemon

Found HIDDEN PID: 763
Command: /usr/sbin/console-kit-daemon

Found HIDDEN PID: 764
Command: /usr/sbin/console-kit-daemon
[...]

Pour les modes plus intensifs, il faut utiliser unhide-linux26 avec l'option adéquate. La liste des modes et des options est tout de suite plus conséquente comme on peut le voir.

# unhide-linux26
Unhide 20110113
http://www.unhide-forensics.info
Usage: unhide-linux26 [options] test_list

Option :
-V          Show version and exit
-v          verbose
-h          display this help
-m          more checks (available only with procfs command)
-r          use alternate sysinfo test in meta-test
-f          log result into unhide.log file
Test_list :
Test_list is one or more of the following
Standard tests :
brute
proc
procall
procfs
quick
reverse
sys
Elementary tests :
checkbrute
checkchdir
checkgetaffinity
checkgetparam
checkgetpgid
checkgetprio
checkRRgetinterval
checkgetsched
checkgetsid
checkkill
checknoprocps
checkopendir
checkproc
checkquick
checkreaddir
checkreverse
checksysinfo
checksysinfo2

Par exemple, avec l'option brute :

# unhide-linux26 brute
Unhide 20110113
http://www.unhide-forensics.info
[*]Starting scanning using brute force against PIDS with fork()

[*]Starting scanning using brute force against PIDS with pthread functions
Found HIDDEN PID: 21443 "  ... maybe a transitory process"

Autre exemple avec reverse :

# unhide-linux26 reverse
Unhide 20110113
http://www.unhide-forensics.info
[*]Searching for Fake processes by verifying that all threads seen by ps are also seen by others

Un bon compromis est de tourner unhide proc et si problème ou résultats étranges, lancer sa version approfondie agrémentée de la liste de tests qui va bien :

# unhide-linux26 procall checkbrute checkchdir checkgetaffinity checkgetparam checkgetpgid checkgetprio checkRRgetinterval  checkgetsched checkgetsid checkkill checknoprocps checkopendir checkproc checkquick checkreaddir checkreverse checksysinfo checksysinfo2
Unhide 20110113
http://www.unhide-forensics.info
[*]Searching for Hidden processes through /proc stat scanning

[*]Searching for Hidden processes through /proc chdir scanning

[*]Searching for Hidden processes through /proc opendir scanning

[*]Searching for Hidden thread through /proc/pid/task readdir scanning

[*]Searching for Hidden processes through getpriority() scanning

[*]Searching for Hidden processes through getpgid() scanning

[*]Searching for Hidden processes through getsid() scanning

[*]Searching for Hidden processes through sched_getaffinity() scanning

[*]Searching for Hidden processes through sched_getparam() scanning

[*]Searching for Hidden processes through sched_getscheduler() scanning

[*]Searching for Hidden processes through sched_rr_get_interval() scanning

[*]Searching for Hidden processes through kill(..,0) scanning

[*]Searching for Hidden processes through  comparison of results of system calls

[*]Starting scanning using brute force against PIDS with fork()

Found HIDDEN PID: 28354 "  ... maybe a transitory process"
Found HIDDEN PID: 28604 "  ... maybe a transitory process"
Found HIDDEN PID: 28610 "  ... maybe a transitory process"
[*]Starting scanning using brute force against PIDS with pthread functions
Found HIDDEN PID: 24819 "  ... maybe a transitory process"
[*]Searching for Fake processes by verifying that all threads seen by ps are also seen by others

[*]Searching for Hidden processes through  comparison of results of system calls, proc, dir and ps

[*]Searching for Hidden processes through sysinfo() scanning

[*]Searching for Hidden processes through sysinfo() scanning

L'outil unhide-tcp, quant à lui, s'attache plus à découvrir quels sont les ports TCP et UDP qui auraient été "oubliés" par netstat.

# unhide-tcp

Starting TCP checking

Starting UDP checking

Dans le cas où vous avez un peu quelques ports qui sont ouverts mais cachés à netstat, vous aurez quelque chose du genre : Bien entendu, si vous tournez en user simple, tous les ports seront listés vu que netstat ne vous permet pas de tout voir :)

Starting TCP checking
Found Hidden port that not appears in netstat: 1021
Found Hidden port that not appears in netstat: 1022

Starting UDP checking
Found Hidden port that not appears in netstat: 1021
Found Hidden port that not appears in netstat: 1022

Au final, unhide est un set complet qui trouve facilement une place dans les outils. Bien pour les paranoïaques mais également pour ceux qui veulent vérifier ce qu'il en est exactement. A conjuguer avec temps, outils complémentaires, skills et à volonté !

OSSEC : Surveillance du système et réponse active

KXan — Mon, 10 Oct 2011 13:00:59 +0000

Le dernier post était axé sur la surveillance de certaines données via auditd. Et bien cette fois, câblons plus efficace, et englobons dans un joli package surveillance du système ET réponse active ! C'est le rôle d'OSSEC.

OSSEC

OSSEC est un HIDS (Host-based Intrusion Detection System). Il s'agit en quelque sorte d'une sonde qui travaille sur une machine en particulier et analyse les éléments propres à cette machine. OSSEC dispose de fonctionnalités adaptées à son utilisation, comme l'analyse de logs, la détection de rootkit, les alertes en temps réel et les réponses actives. OSSEC fonctionne sur la plupart des OS communément rencontrés : Windows, Linux, Mac OS, HP-UX, solaris, ... Il s'appuie sur un schéma client / Serveur :

d'une part le Manager, qui met à disposition les éléments permettant d'évaluer les clients et stocke les informations renvoyées par ces clients
d'autre part un agent, qui se charge de récupérer les éléments nécessaires aux analyses et pousse le tout au Manager

Cependant, OSSEC peut très bien se passer de l'agent, par exemple pour le cas où les systèmes à monitorer seraient plus de l'ordre des équipements réseaux. Ce mode ne sera pas testé ici, mais sachez qu'il est tout-à-fait envisageable.

Installation et configuration en standalone

Comme d'habitude, l'installation se fera depuis les sources, non pas que l'outil ne soit pas disponible sur les dépôts, mais il se peut qu'il date un peu par rapport à la fraiche mouture du site référent. L'installation est on ne peut plus simple : ./install

$ wget http://www.ossec.net/files/ossec-hids-2.6.tar.gz
$ tar zxvf ossec-hids-2.6.tar.gz
$ cd ossec-hids-2.6
$ sudo "./install.sh "
Password:

** Pour une installation en français, choisissez [fr]
(en/br/cn/de/el/es/fr/it/jp/nl/pl/ru/sr/tr) [en]: fr

OSSEC HIDS v2.6 Script d'installation - http://www.ossec.net

Vous êtes sur le point d'installer OSSEC HIDS.
Vous devez avoir une compilateur C préinstallé sur votre système.
Si vous avez des questions ou des commentaires, envoyez un email
à dcid@ossec.net (ou daniel.cid@gmail.com).

- Système: Linux ossec-server.k-tux Debian
- Utilisateur: root
- Hôte: ossec-server.k-tux

-- Appuyez sur Entrée pour continuer ou Ctrl-C pour annuler. --

1- Quel type d'installation voulez-vous (serveur, agent, local ou aide) ? serveur
- Installation du serveur choisie.

2- Définition de l'environnement d'installation.
- Choisissez votre répertoire d'installation de OSSEC HIDS [/var/ossec]:
- L'installation sera faite sur  /var/ossec .

3- Configuration de OSSEC HIDS.
3.1- Voulez-vous une alerte par email ? (o/n) [o]: o
- Quel est votre adresse email ? k-tux@k-tux.com
- Quel est l'adresse IP ou le nom d'hôte de votre serveur SMTP ? smtp.k-tux.com

3.2- Voulez-vous démarrer le démon de vérification d'intégrité ? (o/n) [o]: o
- Lancement de syscheck (démon de vérification d'intégrité).

3.3- Voulez-vous démarrer le moteur de détection de rootkit ? (o/n) [o]: o
- Lancement de rootcheck (détection de rootkit).

3.4- La réponse active vous permet d'éxécuter des commandes  spécifiques en fonction d'évènement. Par exemple, vous pouvez bloquer une adresse IP ou interdire l'accès à un utilisateur spécifique. Plus d'information sur : http://www.ossec.net/en/manual.html#active-response
- voulez-vous démarrer la réponse active ? (o/n) [o]: o
- Réponse active activée.

- Par défaut, nous pouvons activer le contrôle d'hôte
et le pare-feu (firewall-drop). Le premier ajoute un hôte dans /etc/hosts.deny et le second bloquera l'hôte dans iptables (sous linux) ou dans ipfilter (sous Solaris, FreeBSD ou NetSBD).
- Ils peuvent aussi être utilisés pour arrêter les scans en force brute de SSHD, les scans de ports ou d'autres formes d'attaques. Vous pouvez aussi les bloquer par rapport à des évènements snort, par exemple.
- Voulez-vous activer la réponse pare-feu (firewall-drop) ? (o/n) [o]:
- pare-feu (firewall-drop) activé (local) pour les levels >= 6
- liste blanche (white list) par défaut pour la réponse active :
- Voulez-vous d'autres adresses IP dans votre liste (white list) ? (o/n)? [n]:

3.5- Voulez-vous activer fonctionnalité syslog (port udp 514) ? (o/n) [o]:
- Fonctionnalité syslog activé.

3.6- Mise en place de la configuration pour analyser les logs suivants :
-- /var/log/messages
-- /var/log/auth.log
-- /var/log/secure
-- /var/log/syslog
-- /var/log/security
-- /var/log/maillog
-- /var/log/proftpd/proftpd.log
-- /var/log/httpd/error_log (apache log)
-- /var/log/httpd/access_log (apache log)

- Si vous voulez surveiller d'autres fichiers, changez le fichier ossec.conf en ajoutant une nouvelle valeur de nom de fichier local. Pour toutes vos questions sur la configuration, consultez notre site web http://www.ossec.net
--- Appuyez sur Entrée pour continuer ---

5- Installation du système
- Exécution du Makefile INFO: Little endian set.
[...]
- Le Système est Debian Linux.
- Script d'initialisation modifié pour démarrer OSSEC HIDS pendant le boot.
- Configuration correctement terminée.
- Pour démarrer OSSEC HIDS:
/var/ossec/bin/ossec-control start
- Pour arrêter OSSEC HIDS:
/var/ossec/bin/ossec-control stop
- La configuration peut être visualisée ou modifiée dans /var/ossec/etc/ossec.conf

Merci d'utiliser OSSEC HIDS.
Si vous avez des questions, suggestions ou si vous trouvez un bug, contactez nous sur contact@ossec.net ou en utilisant la liste de diffusion publique sur ossec-list@ossec.net ( http://www.ossec.net/en/mailing_lists.html ).
Plus d'information peut être trouver sur http://www.ossec.net

- Vous devez ajouter le(s) agent(s) avant qu'ils aient un accés autorisé. Lancez 'manage_agent' pour les ajouter ou les supprimer:
/var/ossec/bin/manage_agents

Plus d'information sur http://www.ossec.net/en/manual.html

C'est plutôt verbeux, ce qui nous permet de bien maîtriser ce qui est fourni à OSSEC et de savoir par où commencer. Allons faire un tour sur le basedir d'OSSEC : /var/ossec.

$ cd /var/ossec/
$ ll
total 76
4 dr-xr-x--- 15 root  ossec 4096 2011-08-25 15:28 .
4 drwxr-xr-x 21 root  root  4096 2011-08-25 15:28 ..
4 dr-xr-x---  3 root  ossec 4096 2011-08-25 15:28 active-response
4 dr-xr-x---  2 root  ossec 4096 2011-08-25 15:28 agentless
4 -r-xr-x---  1 root  ossec   24 2011-08-25 15:28 .bash_logout
4 -r-xr-x---  1 root  ossec  191 2011-08-25 15:28 .bash_profile
4 -r-xr-x---  1 root  ossec  124 2011-08-25 15:28 .bashrc
4 dr-xr-x---  2 root  ossec 4096 2011-08-25 15:28 bin
4 dr-xr-x---  3 root  ossec 4096 2011-08-25 15:28 etc
4 dr-xr-x---  2 root  ossec 4096 2011-08-25 15:28 .gnome2
4 drwxr-x---  5 ossec ossec 4096 2011-08-25 15:28 logs
4 dr-xr-x---  2 root  ossec 4096 2011-08-25 15:28 .mozilla
4 dr-xr-x--- 11 root  ossec 4096 2011-08-25 15:28 queue
4 dr-xr-x---  3 root  ossec 4096 2011-08-25 15:28 rules
4 -r-xr-x---  1 root  ossec 3793 2011-08-25 15:28 .screenrc
4 drwx------  2 ossec ossec 4096 2011-08-25 15:28 .ssh
4 drwxr-x---  2 ossec ossec 4096 2011-08-25 15:28 stats
4 dr-xr-x---  2 root  ossec 4096 2011-08-25 15:28 tmp
4 dr-xr-x---  3 root  ossec 4096 2011-08-25 15:28 var

Comme on peut le voir, toute une arborescence a été créée et remplie avec les informations données à l'installation.

La configuration se trouve sous etc, profitons-en pour jeter un oeil dessus :

$ cat etc/ossec.conf


yes
k-tux@k-tux.com
smtp.k-tux.com
ossecm@ossec-server.k-tux



rules_config.xml
pam_rules.xml
sshd_rules.xml
telnetd_rules.xml
syslog_rules.xml
arpwatch_rules.xml
symantec-av_rules.xml
symantec-ws_rules.xml
pix_rules.xml
named_rules.xml
smbd_rules.xml
vsftpd_rules.xml
pure-ftpd_rules.xml
proftpd_rules.xml
ms_ftpd_rules.xml
ftpd_rules.xml
hordeimp_rules.xml
roundcube_rules.xml
wordpress_rules.xml
cimserver_rules.xml
vpopmail_rules.xml
vmpop3d_rules.xml
courier_rules.xml
web_rules.xml
apache_rules.xml
nginx_rules.xml
php_rules.xml
mysql_rules.xml
postgresql_rules.xml
ids_rules.xml
squid_rules.xml
firewall_rules.xml
cisco-ios_rules.xml
netscreenfw_rules.xml
sonicwall_rules.xml
postfix_rules.xml
sendmail_rules.xml
imapd_rules.xml
mailscanner_rules.xml
dovecot_rules.xml
ms-exchange_rules.xml
racoon_rules.xml
vpn_concentrator_rules.xml
spamd_rules.xml
msauth_rules.xml
mcafee_av_rules.xml
trend-osce_rules.xml
ms-se_rules.xml

zeus_rules.xml
solaris_bsm_rules.xml
vmware_rules.xml
ms_dhcp_rules.xml
asterisk_rules.xml
ossec_rules.xml
attack_rules.xml
openbsd_rules.xml
clam_av_rules.xml
bro-ids_rules.xml
dropbear_rules.xml
local_rules.xml




79200


/etc,/usr/bin,/usr/sbin
/bin,/sbin


/etc/mtab
/etc/mnttab
/etc/hosts.deny
/etc/mail/statistics
/etc/random-seed
/etc/adjtime
/etc/httpd/logs
/etc/utmpx
/etc/wtmpx
/etc/cups/certs
/etc/dumpdates
/etc/svc/volatile


C:\WINDOWS/System32/LogFiles
C:\WINDOWS/Debug
C:\WINDOWS/WindowsUpdate.log
C:\WINDOWS/iis6.log
C:\WINDOWS/system32/wbem/Logs
C:\WINDOWS/system32/wbem/Repository
C:\WINDOWS/Prefetch
C:\WINDOWS/PCHEALTH/HELPCTR/DataColl
C:\WINDOWS/SoftwareDistribution
C:\WINDOWS/Temp
C:\WINDOWS/system32/config
C:\WINDOWS/system32/spool
C:\WINDOWS/system32/CatRoot



/var/ossec/etc/shared/rootkit_files.txt
/var/ossec/etc/shared/rootkit_trojans.txt
/var/ossec/etc/shared/system_audit_rcl.txt
/var/ossec/etc/shared/cis_debian_linux_rcl.txt
/var/ossec/etc/shared/cis_rhel_linux_rcl.txt
/var/ossec/etc/shared/cis_rhel5_linux_rcl.txt



127.0.0.1
^localhost.localdomain$



syslog



secure



1
7



host-deny
host-deny.sh
srcip
yes



firewall-drop
firewall-drop.sh
srcip
yes



disable-account
disable-account.sh
user
yes



restart-ossec
restart-ossec.sh




route-null
route-null.sh
srcip
yes





host-deny
local
6
600




firewall-drop
local
6
600





syslog
/var/log/messages



syslog
/var/log/auth.log



syslog
/var/log/secure



syslog
/var/log/syslog



syslog
/var/log/security



syslog
/var/log/maillog



syslog
/var/log/proftpd/proftpd.log



apache
/var/log/httpd/error_log



apache
/var/log/httpd/access_log

Par défaut telle quelle, la configuration est tout-à-fait viable. On recevra alors des mails du genre :

[...]Received: from notify.ossec.net (ossec-server.k-tux.com)[...]
To: 
From: "OSSEC HIDS" 
Date: Wed, 21 Sep 2011 14:23:41 +0200
Subject: OSSEC Notification - ossec-server.k-tux - Alert level 4

OSSEC HIDS Notification.
2011 Sep 21 14:23:28

Received From: ossec-server.k-tux->/var/log/messages
Rule: 10100 fired (level 4) -> "First time user logged in."
Portion of the log(s):

Sep 21 14:23:26 ossec-server.k-tux sshd[3185]: Accepted password for k-user1 from 192.168.10.105 port 62205 ssh2

 --END OF NOTIFICATION

C'est pratique, notamment pour garder un oeil sur ce qui se passe sur votre infrastructure, cela s'inscrit notamment dans la même veine que le monitoring via Nagios, à ceci près qu'il n'a besoin que des logs de la cible. D'ailleurs, on pourrait mettre également en place la centralisation de logs, afin de pouvoir sécuriser les éléments sur lesquels OSSEC s'appuie.

Active responses

Les actives responses -ou réponses actives en français- sont une des principales fonctionnalités d'OSSEC. Ce sont des actions qui, selon certaines conditions, permettent d'agir immédiatement et de prendre les mesures qui s'imposent. Comme on peut s'en douter, il est facile de mesurer les avantages et inconvénients de ces mécanismes : rapidité de réponse, efficacité (trop parfois), faux positifs, ... Tout est contenu dans la définition : il s'agit d'une part de paramétrer une action / une commande, et de l'autre, de spécifier les conditions déclenchant l'action. Comme vous pouvez le constater, la cnfiguration par défuat en contient déjà quelques unes, comme par exemple :


firewall-drop
firewall-drop.sh
srcip
yes

[...]


firewall-drop
local
6
600

En ce qui concerne la définition de la commande, on a principalement :

le nom de la commande
l'exécutable auquel OSSEC doit se référer pour l'action, situé sous /var/ossec/active-response/bin/
expect, qui contient l'argument nécessaire pour effectuer l'action
la possibilité d'autoriser un timeout

Pour ce qui est de la définition de la réponse active, on doit spécifier :

le nom de la commande
location : où la commande doit être exécutée. 4 choix s'offrent à vous :

local ; c'est-à-dire sur la machine cliente, où l'agent s'est exécuté
server ; donc sur le serveur OSSEC lui-même
defined-agent ; sur un agent spécifique, il faut alors renseigner un champ agent_id pour que cela soit fait correctement
all : partout

agent_id : le fameux agent sur lequel l'action sera faite si on a mentionné defined-agent dans les balises de location
level : la réponse sera exécutée sur chaque évènement ayant un niveau supérieur ou égal à celui spécifié
timeout : combien de temps avant que la réponse soit défaite (par exemple, ici, l'ip débloquée)

Voyons ce que cela donne dans le cadre d'une installation d'un client seulement...

Clients / Serveur

L'installation d'un client distinct fonctionne à peu près pareil que pour l'installation du serveur, à ceci près que l'on mention agent au lieu de server.

# cd /usr/lcoal/src/ossec-hids-2.6
-bash-4.0# ls
active-response/  BUGS  CONFIG  contrib/  CONTRIBUTORS  doc/  etc/  INSTALL  install.sh*  LICENSE  README  src/
-bash-4.0# ./install.sh
** Pour une installation en français, choisissez [fr]
(en/br/cn/de/el/es/fr/it/jp/nl/pl/ru/sr/tr) [en]: fr

OSSEC HIDS v2.6 Script d'installation - http://www.ossec.net
[...]

- Système: Linux Debian
- Utilisateur: root
- Hôte: ossec-agent.k-tux.com

1- Quel type d'installation voulez-vous (serveur, agent, local ou aide) ? agent
- Installation de l'agent (client) choisie.
2- Définition de l'environnement d'installation.
- Choisissez votre répertoire d'installation de OSSEC HIDS [/var/ossec]:
- L'installation sera faite sur  /var/ossec .
3- Configuration de OSSEC HIDS.
3.1- Quelle est l'adresse IP de votre serveur OSSEC HIDS ?: 192.168.206.145
- Ajout de l'IP du Serveur 192.168.206.145
3.2- Voulez-vous démarrer le démon de vérification d'intégrité ? (o/n) [o]: o
- Lancement de syscheck (démon de vérification d'intégrité).
3.3- Voulez-vous démarrer le moteur de détection de rootkit ? (o/n) [o]:
- Lancement de rootcheck (détection de rootkit).
3.4 - voulez-vous démarrer la réponse active ? (o/n) [o]:
3.5- Mise en place de la configuration pour analyser les logs suivants :
-- /var/log/messages
-- /var/log/auth.log
-- /var/log/secure
-- /var/log/syslog
-- /var/log/security
-- /var/log/maillog
-- /var/log/proftpd/proftpd.log
-- /var/log/httpd/error_log (apache log)
-- /var/log/httpd/access_log (apache log)

5- Installation du système
- Exécution du Makefile [...]
- Le Système est Debian Linux.
- Script d'initialisation modifié pour démarrer OSSEC HIDS pendant le boot.
- Configuration correctement terminée.
- Pour démarrer OSSEC HIDS:
/var/ossec/bin/ossec-control start
- Pour arrêter OSSEC HIDS:
/var/ossec/bin/ossec-control stop
- La configuration peut être visualisée ou modifiée dans /var/ossec/etc/ossec.conf
- Vous devez d'abord ajouter cet agent sur le serveur pour
qu'ils communiquent entre eux. Quand cela sera fait,
vous pourrez lancer l'outil 'manage_agents' pour
importer la clef d'authentification depuis le serveur.

/var/ossec/bin/manage_agent

Comme mentionné, il faut ajouter manuellement l'agent sur le serveur, car sinon, il ne voit que lui-même. Pour cela il faut utiliser manage_agent, qui, sur mon serveur, se situe sous /var/ossec/bin. Quant à agent_control, il permet d'avoir la main sur la liste des agents référencés et de leur faire subir quelques contrôles.

 ossec-server.k-tux# agent_control -l

OSSEC HIDS agent_control. List of available agents:
ID: 000, Name: ossec-serv.k-tux (server), IP: 127.0.0.1, Active/Local

# manage_agents
****************************************
* OSSEC HIDS v2.6 Agent manager.     *
* The following options are available: *
****************************************
(A)dd an agent (A).
(E)xtract key for an agent (E).
(L)ist already added agents (L).
(R)emove an agent (R).
(Q)uit.
Choose your action: A,E,L,R or Q: A

- Adding a new agent (use '\q' to return to the main menu).
Please provide the following:
* A name for the new agent: ossec-agent.k-tux
* The IP Address of the new agent: 192.168.206.151
* An ID for the new agent[001]:
Agent information:
ID:001
Name:ossec-agent.k-tux
IP Address:192.168.206.151
Confirm adding it?(y/n): y
Agent added.

****************************************
* OSSEC HIDS v2.6 Agent manager.     *
* The following options are available: *
****************************************
(A)dd an agent (A).
(E)xtract key for an agent (E).
(L)ist already added agents (L).
(R)emove an agent (R).
(Q)uit.
Choose your action: A,E,L,R or Q: Q

** You must restart the server for your changes to have effect.
manage_agents: Exiting ..

Et de redémarrer le serveur ossec :

# ossec-control restart
Deleting PID file '/var/ossec/var/run/ossec-remoted-7684.pid' not used...
Killing ossec-monitord ..
Killing ossec-logcollector ..
ossec-remoted not running ..
Killing ossec-syscheckd ..
Killing ossec-analysisd ..
Killing ossec-maild ..
Killing ossec-execd ..
OSSEC HIDS v2.6 Stopped
Starting OSSEC HIDS v2.6 (by Trend Micro Inc.)...
OSSEC analysisd: Testing rules failed. Configuration error. Exiting.
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-remoted...
Started ossec-syscheckd...
Started ossec-monitord...
Completed.

Du client, si rien de plus n'est fait, on part tout de même en erreur sur une histoire de clé :

 ossec-agent.k-tux # /var/ossec/bin/ossec-control start
Starting OSSEC HIDS v2.6 (by Trend Micro Inc.)...
Started ossec-execd...
2011/10/05 13:21:39 ossec-agentd(1402): ERROR: Authentication key file '/var/ossec/etc/client.keys' not found.
2011/10/05 13:21:39 ossec-agentd(1750): ERROR: No remote connection configured. Exiting.
2011/10/05 13:21:39 ossec-agentd(4109): ERROR: Unable to start without auth keys. Exiting.

Pour récupérer la clé du client, il faut créer un fichier /var/ossec/etc/client.keys qui contiendra la clé du client que le serveur garde sous son /var/ossec/etc/clients.keys (attention, il y a bien un s à clients, contrairement à celui du client).

ossec-agent.k-tux # cat /var/ossec/etc/client.keys
001 ossec-agent.k-tux 192.168.206.151 3ba007429eb3f283e85cc18eefcf4e01e64604e82757723db94c23fd1026df88

Une autre méthode, mais qui n'a pas fonctionné pour moi, est, depuis le client, de passer par manage_agent avec un bon cut/paste de la clé :

ossec-agent.k-tux # ./manage_agents

****************************************
* OSSEC HIDS v2.6 Agent manager.     *
* The following options are available: *
****************************************
(I)mport key from the server (I).
(Q)uit.
Choose your action: I or Q: I

* Provide the Key generated by the server.
* The best approach is to cut and paste it.
*** OBS: Do not include spaces or new lines.

Paste it here (or '\q' to quit): 3ba007429eb3f283e85cc18eefcf4e01e64604e82757723db94c23fd1026df88

** Invalid authentication key. Starting over again.
** Press ENTER to return to the main menu.

Dans un cas comme dans l'autre -du moins si votre manage_agent fonctionne sur l'import-, vous pouvez dès que cela est réglé, lancer ossec-agent sur le client :

ossec-agent.k-tux # /var/ossec/bin/ossec-control start
Starting OSSEC HIDS v2.6 (by Trend Micro Inc.)...
ossec-execd already running...
Started ossec-agentd...
Started ossec-logcollector...
Started ossec-syscheckd...
Completed.

A partir de là, votre agent fonctionne tout comme votre serveur, notifications et réponses actives !

Conclusion

Il est indéniable qu'OSSEC dispose de fonctionnalités clé qui permettent d'avoir un état en temps réel de votre infrastructure. En cela, il devient un des outils nécessaires à tout administrateur voulant contrôler un peu plus ce qui se passe sur son parc. Cependant, comme pour tous les outils puissants, il reste maintenant à faire un peu de tri dans les informations renvoyées, afin de distinguer celles qui sont vraiment importantes de celles qui relèvent plus de l'anecdote. Car c'est un risque identifié : plus il y a de bruit, et moins on voit le problème...

Mutt : client mail en ligne de commande

KXan — Mon, 29 Aug 2011 11:45:44 +0000

Bonjour à tous ! Parlons peu, parlons bien, j'ai été confrontée il y a peu au besoin d'envoyer de manière récurrence un backup de configurations. J'ai donc été amenée à jouer avec Mutt. Mutt est un client mail en ligne de commande qui permet, entre autre, de pouvoir faire toutes les opérations du client mail natif de Linux, avec des options non négligeables en plus, comme, au hasard, la prise en charge des pièces jointes.

Mutt : Installation et... Utilisation

L'installation n'est pas plus difficile que ça, le maniement encore moins :

$ apt-get install mutt
$ mutt
q:Quitter  d:Effacer  u:RM-CM-)cup  s:Sauver  m:Message  r:RM-CM-)pondre  g:Groupe  ?:Aide
1 N F Aug 29 To k-tux@192.168.1.105 (   2) test



---Mutt: /var/spool/mail/k-tux [Msgs:1 New:1 0,6K]---(date/date)-------------------(all)---

Au premier lancement, il vous demande où stocker les préférences, etc... Et l'emplacement par défaut de la mailbox sera très classique : sous /var/spool/mail/. Mutt se présente un peu comme iftop, avec une interface directement faite en ligne de commande. Comme vous pouvez le constater, les principales commandes sont renseignées en haut de l'écran Mutt, qui permettent d'interagir tout-à-fait comme un client mail graphique, comme Thunderbird. Mais il peut également s'utiliser en ligne de commande sans passer par l'interface, ce qui est tout de même mieux pour le scripting :) Ici, pour l'exemple, test est un fichier contenant la chaine de caractère "Testing Mutt" :

$ mutt -s "k-tux test" k-tux@k-tux.com < test

Les mails envoyés seront stockés sous ~/sent, qui est un fichier text :

$ cat sent
From k-tux@192.168.1.105 Mon Aug 29 10:50:34 2011
Date: Mon, 29 Aug 2011 10:50:34 +0200
From: k-tux 
To: k-tux@k-tux.com
Subject: k-tux test
Message-ID: <20110829085034.GA14010@192.168.1.105>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Status: RO
Content-Length: 13
Lines: 1

Testing Mutt

Et maintenant, test d'envoi de pièce jointes :

$ mutt -s "k-tux test" k-tux@k-tux.com -a /data/k-tux/backup.tar.gz < test

Le ~/sent a rajouté :
From k-tux@192.168.1.105 Mon Aug 29 10:56:51 2011
Date: Mon, 29 Aug 2011 10:56:51 +0200
From: k-tux 
To: k-tux@k-tux.com
Subject: k-tux test
Message-ID: <20110829085651.GA14297@192.168.1.105>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="ZGiS0Q5IWpPtfppv"
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2009-06-14)
Status: RO
Content-Length: 6256
Lines: 96


--ZGiS0Q5IWpPtfppv
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline

Mutt : Testing enclosed data

--ZGiS0Q5IWpPtfppv
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="backup.tar.gz"
Content-Transfer-Encoding: base64

H4sIAJATVk4AA+1dbZPbthH2V9+vYC8fnIxLHUmRVOpxPJMmbuMZx/bEdjqdTKeFSIhCRBI0
AOpO/vVdAJROOgOk7sVMbOOZxDphl3hb7GIXL9Q8WxTRhGO2xmwSJcG3YXh2744RAGZJoj4B
Vz/V32GYRkkchtM0uheEURrE97zkritiQssFYp53j1Eq+viG6J8o5gb5q7Q7HAVHyj8MgSmK
YpD/NJlFTv5jwC7/V6uiKthdDIOj5Z+ABYinIP8kCFMn/zHQI3+UrVCB+e1HwLHynyZROotn
Uv7TKHDyHwNHyD9D2RLfZhRcZ/5PppAeptM4cfIfA8fIn9YLUkwuqvKGZUgBp3FslX8SR1v7
H0aR9P9m0Qz0P7jTllrwhcv/8WvasgzzJyf3Pe/x96/e6O/66z8ZbZsnOZ4TVPv8XYvxe/z4
TKcqhre/PH+yFKJ5dHa2EM0kxxPNPKGsONN/nj0+k1ySXeLxr5hxQusnu+y2CTuOH2jV0BrX
4kmFSP347PK7iaUtBYGxy/EAI8NcMJIJnA8wtnVPft+zbPkEVXkaPz5Tf594HeD7Zec9Ptt1
[...]

PGP

Il est possible d'utiliser PGP pour signer le mail, le chiffrer ou les deux. Pour cela, en interface, il suffit de taper "p" lors du récapitulatif du mail à envoyer :

y:Envoyer  q:Abandonner  t:To  c:CC  s:Subj  a:Attacher fichier  d:Description  ?:Aide
From: K-Tux 
To: k-tux@k-tux.com
Cc:
Bcc:
Subject: Mutt : Test PGP
Reply-To:
Fcc: ~/sent
Security: Clair


-- Attachements
- I     1 /tmp/mutt-192.168.1.105-3100-15158-0      [text/plain, 7bit, iso-8859-1, 0,1K]
-- Mutt: Compose  [Approx. msg size: 0,1K   Atts: 1]---------------------------------------
(c)hiffrer PGP, (s)igner, (e)n tant que, les (d)eux, en l(i)gne, en clai(r)M-BM- ?

Ici, on veut chiffrer, donc "c". Cela provoque la mise à jour du champ Security :

y:Envoyer  q:Abandonner  t:To  c:CC  s:Subj  a:Attacher fichier  d:Description  ?:Aide
From: K-Tux 
To: k-tux@k-tux.com
Cc:
Bcc:
Subject: Mutt : Test PGP
Reply-To:
Fcc: ~/sent
PGP: Chiffrer (PGP/MIME)


-- Attachements
- I     1 /tmp/mutt-192.168.1.105-3100-15158-0   [text/plain, 7bit, iso-8859-1, 0,1K]
-- Mutt: Compose  [Approx. msg size: 0,1K   Atts: 1]---

Mutt demandera alors la clé PGP avant d'envoyer le mail. Et avec ça, mon besoin est totalement comblé -du moins pour l'usage que je voulais en faire :). Il existe pas mal d'option et de fonctionnalités dans Mutt, que je ne détaillerais pas car à la fois la doc en ligne et le man -voire pour le reste, mutt -h- renvoient de manière concise les options et les fonctionnalités qu'il est possible d'utiliser :) En bref, pourquoi se priver ?

SystemImager : concepts d’une solution d’automatisation de déploiement

K-TUX — Sun, 04 Jul 2010 14:59:59 +0000

SystemImager est un projet très abouti qui permet de gérer l'installation et le déploiement de logiciel et de distribution Linux, tout en s'appuyant des outils standards comme SSH et rsync. Il se distingue très nettement des outils comme Fedora kickstart et Debian debootstrap dans la mesure où il est capable de gérer plusieurs architectures et distributions différentes. D'autre part, la finesse des petites customisations et tout ce qui pourrait sortir du standard des dépôts est directement prise en compte et appliquée, sans avoir à se confronter aux fameux scripts de post-installation. En ce sens, cela fait de lui l'outil incontournable pour une gestion de parc uniforme et automatisée. Son fonctionnement est simple : il aspire dans un premier temps tout ou partie d'un système de fichier (on peut spécifier des exclusions ou même en créer un viable, via les outils du package) qu'il stocke tel quel au sein d'un dépôt d'image. Il s'agit ensuite de rebalancer l'arborescence, soit pour une installation complète, soit pour un alignement des version. Du fait que le système de fichier soit stocké en l'état, il est alors très facile de modifier et contrôler le contenu de l'image avant déploiement. La seule contrainte concerne les clients et requiert une parfaite adéquation dans le nombre de disques durs des noeuds sous la juridiction de SystemImager. La capacité peut varier, mais attention aux disques plus petits que ceux du GoldenClient. En effet, si l'on venait à balancer une install qui ne tiendrait pas sur le disque, cela ferait désordre. Pour pouvoir entrer dans les détails, il est nécessaire de définir les notions sur lesquelles s'appuie SystemImager.

Les éléments

L'image server

SystemImager a besoin d'un maître d'orchestre, appelé le serveur d'image, afin de pouvoir centraliser toute la partie gestion des images et des noeuds. Notre serveur contiendra donc tous les packages et toute la configuration nécessaire à SystemImager. La racine de SystemImager se situe au niveau de /var/lib/systemimager, et est enrichie de plusieurs éléments :

# ll /var/lib/systemimager/
total 28
-rw-r--r--  1 root root 14361 2010-06-29 11:13 clients.xml
drwxr-xr-x  9 root root  4096 2010-06-23 10:21 images/
drwxr-xr-x 55 root root  4096 2010-06-23 10:21 overrides/
drwxr-xr-x  4 root root  4096 2010-06-23 10:21 scripts/

Les explications relatives aux différents éléments seront fournies un peu plus loin. Afin de pouvoir distribuer les images correctement -et surtout lors du boot PXE-, le server devra regrouper le duo TFTP server et DHCP server. A noter que SystemImager permet de rapidement mettre en place une configuration complète de serveur de boot grâce à l'outil si_mkbootserver, intégré au package systemimager-server. Il existe plusieurs façons d'installer via SystemImager. PXE, comme nous l'avons mentionné un peu plus haut, Bittorent, ou par multicast. Ces variations sont à l'origine de certains packages qui ont été spécialement crée sur ces spécificités. A titre d'information, les packages intéressants sont :

systemimager-server : le core du serveur SystemImager,
systemimager-common : les outils qui vont avec,
systemimager-*boot-standard : les outils relatifs à la partie boot server, * regroupe i386 et x86_64

systemimager-server-flamethrower* : pour utiliser le mode multicast
systemimager-server-bittorrent : pour utiliser le mode BitTorrent.

Il va sans dire que, si vous projetez d'installer plusieurs distributions, il faudra assurer au niveau stockage des images. Même réflexion concernant la partie réseau, surtout si l'intention de virtualiser vous taraude. Le paramétrage fin de SystemImager se fait comme d'habitude, via un fichier de configuration : /etc/systemimager.conf, ou /etc/systemimager/systemimager.conf.

Les nodes

Les nodes sont les postes clients qui vont faire l'objet d'une installation automatisée par SystemImager. Ils sont rattachés préalablement à une image bien précise, et optionnellement à un ou plusieurs overrides. Accessoirement, ils disposent d'une entrée dans le fichier /etc/dhcpd.conf du serveur afin de pouvoir obtenir une adresse et pouvoir rapatrier, via TFTP par exemple, un noyau minimal qui se chargera de l'installation. Le paramétrage des clients et leur association à une image peut passer par si_addclients (c'est d'ailleurs historique)ou par si_clusterconfig. Je ne vous éplucherais pas toutes les options qui sont disponibles, sachez que vous pouvez absolument tout faire, grouper vos clients en liste FQDN, IP, avec un domainname qui leur pend, en interactif,... Bref, man est votre meilleur ami. On retrouve les informations relatives aux nodes dans le fichier /var/lib/systemimager/clients.xml. Point important, si_clusterconfig est un outil au-dessus de la gestion de node, c'est-à-dire qu'il définit l'ensemble de votre cluster en terme de groupe, de priorité, d'image, d'override, et de node.

Le GoldenClient

Le GoldenClient est un poste de même calibre que les nodes, et qui leur servira indirectement de référence. Il doit être installé et configuré manuellement et est à l'origine de l'image référente que vous déployerez. systemimager-common et systemimager-client devront être présents sur le GoldenClient.

Les images

Les images sont des répertoires chrootables qui contiennent l'intégralité du système de fichier à déployer sur les clients. Elles sont identifiées par un nom intelligible, fourni en entrée lors de leur récupération du GoldenClient. Toutes les images sont stockées sous la racine de SystemImager, c'est-à-dire sous /var/lib/systemimager/images. Gardez sous le coude si_lsimage pour les voir, si_rmimage pour les supprimer et surtout si_getimage pour en rapatrier une (oui, aussi si_mvimage et si_cpimage mais pas besoin de vous expliquer ce que ça vaut).

Les overrides

Parce qu'on ne va pas stocker plusieurs systèmes de fichiers juste pour une différence de configuration sur une poignée de fichiers, SystemImager a défini la notion d'override. Les overrides concernent les customisations appliquées à une image en particulier, il y peut donc y avoir plusieurs overrides pour une image. De la même façon que les images ont un nom, les overrides en disposent également d'un. Les overrides contiennent une portion de l'arborescence du système de fichier, qui diffère de celle proposée par l'image, et qui viendra écraser celle issue de l'image originale après que celle-ci ait été mise en place.

ls overrides/ide/
boot/  etc/

On retrouve les overrides sous /var/lib/systemimager/overrides, et pour les pousser sur les nodes, il vous suffit d'un si_pushoverrides.

Fonctionnement

Voila commence ça se passe... Premièrement, vous avez dû monter, à la sueur de votre front, votre petit serveur DHCP/TFTP/SystemImager. Deux-trois tips sympa qui vous permettront d'avancer rapidement : - si_mkdhcpserver / si_mkdhcpstatic, qui va vous arquer sur la configuration d'un DHCP opérationnel, - si_mkbootserver, pour l'aspect PXE / TFTP, - /etc/systemimager/systemimager.conf, pour la conf. Et puis on attaque le gros œuvre !

From Scratch ! L'installation automatisée

Le plus pénible d'abord. Prenez votre GoldenClient et, gentillement, patiemment, installez-le et configurez au poil toutes les options qui vont bien. Saupoudrez de systemimager-common et de systemimager-client, vos petits outils qui vous sauveront une énorme quantité de temps. N'oubliez pas de customiser le /etc/systemimager/client.conf pour tout ce qui est port d'adressage, exclude,... si_prepareclient va vous permettre de lancer tout ce qui va bien -rsync, fichiers,... afin que votre server SystemImager puisse récupérer l'image. En clair, il déduit de la conf actuelle toutes les informations utiles, dont le partitionnement des disques.

$ si_prepareclient  --server kaster
Welcome to the SystemImager si_prepareclient command.  This command may modify
the following files to prepare your golden client for having it's image
retrieved by the imageserver.  It will also create the /etc/systemimager
directory and fill it with information about your golden client.  All modified
files will be backed up with the .before_systemimager-4.1.6 extension.

/etc/services:
This file defines the port numbers used by certain software on your system.
Entries for rsync will be added if necessary.

/tmp/filerNi0f5:
This is a temporary configuration file that rsync needs on your golden client
in order to make your filesystem available to your SystemImager server.

inetd configuration:
SystemImager needs to run rsync as a standalone daemon on your golden client
until it's image is retrieved by your SystemImager server.  If rsyncd is
configured to run as a service started by inetd, it will be temporarily
disabled, and any running rsync daemons or commands will be stopped.  Then,
an rsync daemon will be started using the temporary configuration file
mentioned above.

See "si_prepareclient --help" for command line options.

Continue? (y/[n]): y
*********************************** WARNING ***********************************
This utility starts an rsync daemon that makes all of your files accessible
by anyone who can connect to the rsync port of this machine.  This is the
case until you reboot, or kill the 'rsync --daemon' process by hand.  By
default, once you use si_getimage to retrieve this image on your imageserver,
these contents will become accessible to anyone who can connect to the rsync
port on your imageserver.  See rsyncd.conf(5) for details on restricting
access to these files on the imageserver.  See the systemimager-ssh package
for a more secure method of making images available to clients.
*********************************** WARNING ***********************************

Continue? (y/[n]): y

Signaling xinetd to restart...
...
Using "sfdisk" to gather information about disk:
/dev/sda

[...]
>>> Choosing filesystem for new initrd:  cpio
>>> Creating new initrd from staging dir:  /tmp/.systemimager.0
>> cd /tmp/.systemimager.0 && find . ! -name "*~" | cpio -H newc --create | gzip -9 > /etc/systemimager/boot/initrd.img
123093 blocks
>> ls -l /etc/systemimager/boot/initrd.img
-rw-r--r-- 1 root root 44150730 Jul  1 16:02 /etc/systemimager/boot/initrd.img

>> Evaluating initrd size to be added in the kernel boot options
>> (e.g. /etc/systemimager/pxelinux.cfg/syslinux.cfg):
>>     suggested value -> ramdisk_size=71786.5

>>> Using kernel from:          /boot/vmlinuz-2.6.31.13-server-1mnb
>> ls -l /etc/systemimager/boot/kernel
-rw-r--r-- 1 root root 2748752 Jul  1 16:02 /etc/systemimager/boot/kernel

Starting or re-starting rsync as a daemon.....
done!

This client is ready to have its image retrieved.  You must now run
the "si_getimage" command on your imageserver.

Your client has been successfully prepared.  Boot kernel (copied from
this Linux distribution) and an initrd.img (generated by the
initrd_template package) can be found in /etc/systemimager/boot.

Automatically create configuration file for systemconfigurator:
>> /etc/systemconfig/systemconfig.conf

Ici, le transport se fera par rsync, mais il est possible d'utiliser rsync over SSH, BitTorrent, multicast,... Switchez sur votre serveur SystemImager et lancez le si_getimage qui va bien, avec -golden-client et image en entrée. En optionnel, des options sur des exclusions, les assignements IP, le comportement postinstallation (reboot, beep, shutdown,...), bref, de quoi bien jouer. Une fois l'image rapatriée, et mise au frais, si_clusterconfig -e pour organiser votre cluster -tel node va avec telle image, tel overrides,... Pour la petite idée de ce à quoi ça ressemble :



kaster
absolutely_all_nodes
override_for_absolutely_all_nodes

kluster.knBSD.overBSD
1
knBSD
overBSD
knod1


kluster.kDeb.overDeb
2
kDeb
overDeb
knod2,knod3,knod4

Tous vos nodes paramétrés bien comme il faut dans votre SystemImager, il ne vous reste plus qu'à forcer leur boot réseau avec si_mkclientnetboot...

si_mkclientnetboot --client=knod2 --netboot
[netboot] using the kernel and initrd.img for architecture: i386
[netboot] using the flavor: standard

...Et de les rebooter en PXE. si_pushinstall prend alors le contrôle des choses et le server va tout simplement redescendre par SSH, brute de force, l'image sur le node.

Les synchronisations

Evidemment, je vous avais parlé de SystemImager en tant qu'outil de déploiement d'OS, oui, mais de logiciel également. En soi, le processus est le même, il s'agit d'une synchronisation -initiée par le serveur SystemImager à destination des nodes- entre l'image assignée au node et le système de fichier du node en lui-même. Ce qui diffère, ce sont les outils.

si_pushupdate

L'outil adapté à tout ce qui doit découler d'une mise à jour de l'image référente. si_pushupdate va, ici via rsync, transférer tout ce qui manque du server aux nodes. Vu que c'est du rsync, la gestion de la bande passante est optimisée -on ne redescend pas absolument toute l'image-, malgré tout, le multicast est, à mon avis, beaucoup plus adapté à ce genre de redescente, surtout si vous avez beaucoup de node à mettre à jour.

si_pushupdate --server kaster --hosts="knod2"
knod2 : ======================= WARNING =================================
knod2 :  This command will update this host with the image: kDeb
knod2 :  and overrides (in order of importance):
knod2 :
knod2 :  overDeb, override_for_absolutely_all_nodes
knod2 :
knod2 :  Some files could be deleted or overwritten, so probably it is a
knod2 :  good idea to run this command with --dry-run before and stop the
knod2 :  production on this host.
knod2 : ======================= WARNING =================================
knod2 :
knod2 : Are you sure to continue? (y / N)? y
knod2 : [...]
knod2 : Excluding (filesystem ext2): /tmp
knod2 : >> Updating image from module kDeb...
knod2 : receiving incremental file list
knod2 : deleting .readahead_collect
knod2 : sent 86986 bytes  received 23829894 bytes  621217.66 bytes/sec
knod2 : total size is 10895198915  speedup is 455.54
knod2 : >> Updating image from module overrides/override_for_absolutely_all_nodes...
knod2 : Running bootloader...Kernel /boot/...

si_pushoverrides

Comme son nom l'indique, il s'agit en réalité non pas d'aligner le node avec son image mais avec ses overrides.

si_pushoverrides -v knod2
Building clients list...
Grouping clients by common overrides...
WARNING: in case of file overlaps the overrides will be distributed using the following order (first hit wins):
WARNING: -->
Performing the updates...
>> si_pcp -v    -n knod2 /var/lib/systemimager/overrides/overDeb/ /
knod2 :/: sending incremental file list
[...]
knod2 :/: sent 898 bytes  received 203 bytes  734.00 bytes/sec
knod2 :/: total size is 2510  speedup is 2.28

Le monitoring

Monitorer un node revient, sous SystemImager, à se faire une idée d'où il en est au niveau de l'installation. Pour cela, SystemImager exploite grandement /var/lib/systemimager/clients.xml et met à disposition 2 outils, l'un étant la version graphique de l'autre, il s'agit de si_monitor et si_monitortk.

Conclusion

SystemImager apporte donc une réponse simple, complète et très satisfaisante aux besoins d'automatisation d'installation et de déploiement. De par ce fait, il est tout-à-fait dans la ligne de mire des exploitation en cluster, et se marie très bien avec des systèmes de répartition de charge dans des environnements de calcul, comme c'est le cas pour OSCAR, Torque, MAUI, et autres. Attention toutefois, car même s'il correspond également au besoin d'uniformisation dans un parc constitué de postes de travail, il peut s'avérer que la synchronisation provoque des problèmes d'incohérence et d'instabilité au niveau de l'environnement graphique ou du noyau, selon ce qui a été mis à jour. Il est donc sage de l'utiliser avec parcimonie quand vous êtes en première ligne face à vos utilisateurs. Il ne vous reste plus qu'à vous en faire une idée par vous-même, et, pourquoi pas, l'adopter !

Cfengine, cet outil qui facilite la vie des ASR…

K-TUX — Sun, 17 Jan 2010 18:47:41 +0000

Une grande partie de l'activité d'un Administrateur Système consiste à suivre, à bichonner, à soigner et à updater ses serveurs. Certains ont choisi de le faire manuellement, comme sur une bonne vieille architecture constituée d'une poignée de serveurs. Sachez qu'il existe plusieurs moyens de s'en dispenser, pas totalement, mais suffisamment pour pouvoir se dégager du temps libre et donc attaquer des activités à plus forte plus-value et plus intéressantes. Cfengine est un puissant outil qui permet de s'affranchir des contraintes machinales dues à un parc de serveurs dépassant en nombre notre enjouement à passer tout bien tout comme il faut manuellement et unitairement. Le but du jeu étant de centraliser et d'organiser les traitements selon des classes d'objet. Cfengine fonctionne en utilisant TCP/IP (port 5308 tcp/udp) et les outils libres, en mode client / serveur, et dont les principaux acteurs sont :

Sur le client :
- cf-agent, process client, qui va analyser et traiter les différentes configurations, on peut l'apparenter à un interpréteur,
- cf-execd, un process scheduler,
- cf-runagent, un outil qui permet de déclencher manuellement les traitements et de solliciter des hosts précis,
Sur le serveur :
- cf-servd, process serveur, qui a la responsabilité du partage des fichiers,
- cf-key, le process permettant de sécuriser un minimum les flus de données, qui fonctionne à la manière du keygen d'OpenSSH.

La version 3 est implémentée à l'heure où j'écris ces lignes, c'est donc sur elle que je vais baser mon article.

Mais avant cela, pourquoi dois-je choisir entre les versions ? Et bien parce que la dernière version amène un schisme au niveau du langage utilisé par Cfengine. Malgré tout, la Communauté a fait les choses intelligemment en faisant collaborer les binaires de Cfengine 2 et ceux de Cfengine 3.

On peut donc sans soucis utiliser la version 2 de cfservd avec les versions 3 de cf-agent. C'est ce qu'on appelle être run-time compatible.

Pour analyser la version 3, il est donc nécessaire de détailler un peu le fonctionnement sous la version 2, et c'est ce que nous allons faire.

En version 2, ça se passait comment déjà ?

En version 2, l'installation construit l'outil, génère un couple de clés grâce à cfkey, et stocke tout ça dans /var/cfengine/ppkeys. Notez bien au passage que le répertoire important qui contient pratiquement tout ce qui est intéressant est justement situé sous /var/cfengine/.

Notamment concernant /var/cfengine/inputs/, qui contient tous les fichiers de configuration, par défaut et customisés, que vous serez amené à éditer. On y trouve donc :

cfagent.conf, le fichier de conf de l'agent,
update.conf, lu avant cfagent.conf et chargé, comme son nom l'indique, de rapatrier les mises à jour de configuration,
cfservd.conf, notre configuration de serveur. Utile surtout pour encadrer correctement les droits d'accès de certains serveurs sur certains répertoires,
cfrun.conf, un listing des serveurs à joindre en cas d'utilisation de cfrun.

Ce qu'il est important de savoir, c'est que vous n'êtes pas tenu de bourrer de suite toutes vos règles dans cfagent.conf, mais vous pouvez, à volonté, utiliser autant de fichier de configuration que vous le voulez, grouper certaines règles en fonction de vos critères. Au contraire cela ne fera que vous faciliter un peu plus le boulot. Il est également intéressant de préciser que Cfengine adopte un comportement de non surcharge des ressources. Ainsi, les boucles infernales de commandes sont évitées, et un délai aléatoire est introduit pour éviter que toutes les requêtes ne convergent et viennent s'étrangler sur notre serveur. Les fichiers de configuration sont donc au cœur de Cfengine et leur skeleton n'est pas crée par défaut à l'installation. Un fichier de configuration typique est structuré tel quel :

section1 :
classe1::
directives11
section2 :
classe1::
directives21
classe2::
directives22

Il peut contenir en lui-même plusieurs sections distinctes.

Les sections.

Les sections constituent le moteur même de Cfengine. On peut diviser les sections en 2 catégories : celles qui vont moduler le comportement de Cfengine, et celles qui, à proprement parler, vont faire tout le boulot.

Les classes.

Elles servent à cibler les conditions qui déclencheront les actions à entreprendre. La plupart des classes sont prédéfinies mais il est possible d'en créer de nouvelles. Elles peuvent concerner très spécifiquement une configuration donnée, à un temps t, comme l'OS, la date, la distribution, l'architecture (32 bits, 64bits), on parle alors de hard classes, ou être beaucoup plus abstraites, ce sont alors des evaluated classes. La troisième catégorie contient les classes que nous, administrateurs, nous allons définir. Notez également l'existence d'une hard classe any, qui regroupe toute machine, quel qu'elle soit. Le fonctionnement est simple. Cfagent détecte que c'est l'heure à laquelle il doit déclencher un traitement. Avant toute chose, il va chercher sur notre serveur -le policy host- via update.conf la version à jour, s'il y en a une, de cfagent.conf. En cas d'impossibilité de joindre le serveur, il se basera alors sur celui dont il dispose en local. Les traitements seront alors fait selon ce qui est écrit dans ce cfagent.conf. C'est une stratégie de pull, c'est-à-dire que le client est autonome et c'est lui qui sollicite le serveur. Et, bien sûr, pour plus de fun, tout cela est à votre charge ! Petit exemple de cfservd.conf :

################################################################
#
# cfservd.conf
#
################################################################
control:
   domain = ( k-tux.com )
   AllowConnectionsFrom = ( 192.168.0 )
   TrustKeysFrom = ( 192.168.0 )
   Access = ( root kbux )

# Variables internes, pour faciliter les choses.
   cfrunCommand = ( "/usr/local/sbin/cfagent" )

# Utile pour que 'cfrun' sache ce qu'il a à faire...
grant:
   any::
      /usr/local/sbin   $(policyhost)

   policyhost::
      /var/cfengine/inputs   *.k-tux.com

# Sans cette spécification-là, c'est l'action 'copy' de 'update.conf'
# qui ferait une erreur
# EOF cfservd.conf.

Petit exemple de cfagent.conf.

################################################################
#
# cfagent.conf basique, tout juste fonctionnel.
#
################################################################
control:
   domain  = ( k-tux.com )
   actionsequence = ( shellcommands )

shellcommands:
   "/bin/echo cfagent OK"

# Dans un premier temps, cela suffit !
# En effet, cfagent requiert essentiellement la présence d'une
# 'actionsequence' dans son fichier de conf'.
#
# EOF cfagent.conf.

Petit exemple d'update.conf.

##############################################################
#
# Ceci est le fichier update.conf, simple et fonctionnel,
# servant à tenir à jour tous les fichiers de conf,
# (soit l'intégralité du répertoire /var/cfengine/inputs)
# sur les machines locales.
# En tout état de cause, le garder simple et fonctionnel !
#
##############################################################
control:
   domain = ( k-tux.com )
   actionsequence = ( copy )

# En fait, l'action 'copy' sera utilisé ici pour 'update',
# mais comme cette dernière n'existe pas...
# De toute façon, basiquement, c'est bien une copie de fichiers que l'on demande.
   policyhost = ( policyhost )
   masterdir = ( /var/cfengine/inputs )
   localdir = ( /var/cfengine )

# Bien entendu, 'policyhost' existe dans le fichier /etc/hosts de la machine locale.
# En-dehors de ça, nous venons de déclarer nos propres variables.
# Elles ne tarderons pas à servir...
copy:
   !policyhost::

# Inutile de spécifier une classe, 'any' ou autre,
# car nous voulons que TOUS les hôtes soient à jour de leurs fichiers de conf...
# Tous, sauf le ‘policyhost’, bien sûr
# Précédée du signe '!', toute machine ou classe de machine sera
# exclue de l'action entreprise.
      $(masterdir)   dest=$(localdir)/inputs

# L'action 'copy' est structurée de cette façon.
# L'usage de l'espace autour de la source et de la destination est libre,
# mais pas d'espace à l'intérieur de celles-ci.
# Règle d'or : si la source est un fichier, la destination doit être un fichier.
# Ici, la source est un répertoire, la destination doit en être un aussi.
# Tout ce que contient l'un sera copié dans l'autre.
                     server=$(policyhost)
                     r=inf

# Option obligatoire car copie de répertoire.'r' pour récursif
# (peut également s'écrire 'recurse'). 'inf' pour niveau maximum de récursivité,
                     purge=true

# Sans cette option, 'copy' générerait des fichiers *.cfsaved
# dans le répertoire de destination.
# Ici, nous obtiendrons une réplication exacte et fidèle du répertoire source, sans plus.
                     type=binary

# Le fichier 'dest' sera comparé bit à bit à son homologue source.
                     mode=644

# Là, 'copy' se "contente" de vérifier les permissions d'accès des fichiers
# présents dans $(localdir)/inputs, et de corriger le tir en cas de besoin.
                     trustkey=true

# Le point sensible.
# Ici, nous voulons que $(policyhost) fasse confiance à la machine locale,
# et accepte sa clef publique lors du premier contact entre les deux hôtes.
# Cela nous évitera d'avoir à faire cette échange de clefs manuellement,
# mais bien évidemment nous créons ainsi une petite faille de sécurité...
#
# EOF update.conf.

En version 3, ce n'est plus pareil alors ?

Presque ! On peut voir déjà une subtile différence au niveau du nom des binaires, cf-servd au lieu de cfservd, cf-agent au lieu de cfagent,... Mais vous me direz, et vous n'avez pas tort, que ce ne sont que des détails. D'abord, un petit état des lieux. Voici, après installation, ce qui vous a bourgeonné sur le filesystem. Notez en passant que Cfengine tourne sous root par défaut, mais il est possible de changer ce comportement en retouchant un peu le fichier de configuration du serveur. Toutefois, gardez à l'esprit qu'il lui faut certains privilèges pour pouvoir fonctionner normalement.

[kbux@policyhost cfengine]$ ls -lsa /var/lib/cfengine/
total 80
4 drwxr-xr-x 13 root root 4096 2010-01-13 11:43 ./
4 drwxr-xr-x 31 root root 4096 2010-01-12 12:44 ../
4 drwxr-xr-x  2 root root 4096 2010-01-12 12:44 bin/
4 -rw-------  1 root root 1252 2010-01-13 11:43 cf3.localhost.runlog
8 -rw-------  1 root root 8192 2010-01-13 11:43 cfengine_lock_db
4 -rw-------  1 root root    5 2010-01-13 11:43 cf-execd.pid
4 -rw-------  1 root root    5 2010-01-13 11:43 cf-monitor.pid
4 -rw-------  1 root root    5 2010-01-13 11:43 cf-serverd.pid
0 lrwxrwxrwx  1 root root   21 2010-01-12 12:44 inputs -> ../../../etc/cfengine/
4 drwxr-xr-x  2 root root 4096 2009-08-23 21:03 lastseen/
4 drwxr-xr-x  2 root root 4096 2009-08-23 21:03 modules/
4 drwxr-xr-x  2 root root 4096 2010-01-13 11:45 outputs/
4 drwx------  2 root root 4096 2010-01-12 12:45 ppkeys/
4 -rw-------  1 root root  185 2010-01-13 11:18 promise.log
4 drw-r--r--  2 root root 4096 2009-08-23 21:03 randseed/
4 drwxr-xr-x  2 root root 4096 2009-08-23 21:03 reports/
4 drwx------  2 root root 4096 2009-08-23 21:03 rpc_in/
4 drwx------  2 root root 4096 2009-08-23 21:03 rpc_out/
4 drwxr-xr-x  2 root root 4096 2009-08-23 21:03 rpc_state/
4 drwxr-xr-x  2 root root 4096 2010-01-13 11:43 state/

[kbux@policyhost cfengine]# ls -lsa /usr/sbin/cf*
72 -rwxr-xr-x 1 root root 72008 2009-08-23 21:03 /usr/sbin/cf-agent*
60 -rwxr-xr-x 1 root root 60256 2009-10-14 18:54 /usr/sbin/cfdisk*
32 -rwxr-xr-x 1 root root 30896 2009-08-23 21:03 /usr/sbin/cf-execd*
12 -rwxr-xr-x 1 root root 10116 2009-08-23 21:03 /usr/sbin/cf-key*
80 -rwxr-xr-x 1 root root 79908 2009-08-23 21:03 /usr/sbin/cf-know*
52 -rwxr-xr-x 1 root root 51272 2009-08-23 21:03 /usr/sbin/cf-monitord*
12 -rwxr-xr-x 1 root root  9960 2009-08-23 21:03 /usr/sbin/cf-promises*
56 -rwxr-xr-x 1 root root 55700 2009-08-23 21:03 /usr/sbin/cf-report*
20 -rwxr-xr-x 1 root root 18244 2009-08-23 21:03 /usr/sbin/cf-runagent*
76 -rwxr-xr-x 1 root root 76160 2009-08-23 21:03 /usr/sbin/cf-serverd*

[kbux@policyhost cfengine]$ ls -lsa /etc/cfengine/
total 32
4 drwxr-xr-x  2 root root 4096 2010-01-12 12:44 ./
4 drwxr-xr-x 91 root root 4096 2010-01-12 12:45 ../
4 -rw-r--r--  1 root root  204 2009-08-23 21:03 failsafe.cf
4 -rw-r--r--  1 root root 2518 2009-08-23 21:03 library.cf
4 -rw-r--r--  1 root root 1898 2009-08-23 21:03 promises.cf
8 -rw-r--r--  1 root root 6006 2009-08-23 21:03 site.cf
4 -rw-r--r--  1 root root  971 2009-08-23 21:03 update.cf

[kbux@policyhost cfengine]$ grep cfengine /etc/services
cfengine        5308/tcp                        # CFengine
cfengine        5308/udp                        # CFengine

Les éléments importants se situent au niveau de /var/lib/cfengine, ce sont les répertoires inputs, outputs et bin.

Inputs servira de référence pour ce qui est de passer les paramètres aux cf-agents, il faut donc faire en sorte que ce répertoire soit copié et maintenu à jour fréquemment par toutes les machines concernées. Vu que dans l'installation, le répertoire est en fait un lien symbolique vers /etc/cfengine, nous retrouvons dedans les 5 fichiers *.cf.
Outputs sert de conteneur de reports qui peuvent alors être entreposés et mailés via cf-execd, si on le souhaite.
Bin, en revanche, ne contient qu'un lien symbolique vers le binaire /usr/sbin/cf-promises.

Finalement, on retrouve une arborescence tout à fait comparable à celle de cfengine 2. Et oui, car la majeure différence en version 3 est palpable au niveau du langage en lui-même, ce qui amène à une réorganisation complète de la structure interne aux fichiers de configuration. Par ailleurs, de nouveaux composants se sont rajoutés et on nous parle de promises (oui, c'est de l'anglais). Les promises synthétisent les états que l'on veut maintenir, autrement dit, ce sont vos fichiers de configuration. D'ailleurs, tout ce qui concerne leur gestion, vérification, tout cela dépend de cf-promises. Par exemple, pour vérifier que votre test.cf est correct, rien ne vaut un

[kbux@policyhost cfengine]# cf-promises -v -f /var/lib/cfengine/inputs/test.cf
cf3 Cfengine - autonomous configuration engine - commence self-diagnostic prelude
cf3 ------------------------------------------------------------------------
cf3 Work directory is /var/lib/cfengine
cf3 cf3: INFO: /var/lib/cfengine/inputs is a symbolic link, not a true directory!
cf3 Making sure that locks are private...
cf3 Checking integrity of the state database
cf3 Checking integrity of the module directory
cf3 Checking integrity of the input data for RPC
cf3 Checking integrity of the output data for RPC
cf3 Checking integrity of the PKI directory
cf3 Looking for a source of entropy in /var/lib/cfengine/randseed
cf3 Could not read sufficient randomness from /var/lib/cfengine/randseed
cf3 Loaded /var/lib/cfengine/ppkeys/localhost.priv
cf3 Loaded /var/lib/cfengine/ppkeys/localhost.pub
cf3 Setting cfengine default port to 5308 = 5308
cf3 Reference time set to Sun Jan 17 11:48:27 2010
cf3 Cfengine - 3.0.2 (C) Cfengine AS 2008-
cf3 ------------------------------------------------------------------------
cf3 Host name is: policyhost
cf3 Operating System Type is linux
cf3 Operating System Release is 2.6.31.5-desktop-1mnb
cf3 Architecture = i686
cf3 Using internal soft-class linux for host localhost
cf3 The time is now Sun Jan 17 11:48:27 2010
cf3 ------------------------------------------------------------------------
cf3 # Extended system discovery is only available in version Nova and above
cf3 Additional hard class defined as: 32_bit
cf3 Additional hard class defined as: linux_2_6_31_5_desktop_1mnb
cf3 Additional hard class defined as: linux_i686
cf3 Additional hard class defined as: linux_i686_2_6_31_5_desktop_1mnb
cf3 GNU autoconf class from compile time: compiled_on_linux_gnu
cf3 Address given by nameserver: 127.0.0.1
cf3 Interface 1: lo
cf3 Interface 2: eth0
cf3 Trying to locate my IPv6 address
cf3 Found IPv6 address inet6:
cf3 Found IPv6 address fe80::a00:27ff:fe24:ef9f
cf3 Found IPv6 address inet6:
cf3 Looking for environment from cf-monitor...
cf3 Loading environment...
cf3 Environment data loaded
cf3 This appears to be a mandriva system.
cf3 Looking for Mandriva linux info in "Mandriva Linux release 2010.0 (Official) for i586
"
cf3 This appears to be a LSB compliant system.
cf3 ***********************************************************
cf3  Loading persistent classes
cf3 ***********************************************************
cf3 ***********************************************************
cf3  Loaded persistent memory
cf3 ***********************************************************
cf3   > Parsing file /var/lib/cfengine/inputs/test.cf
cf3 Initiate variable convergence...
cf3 Initiate variable convergence...
cf3 # Knowledge map reporting feature is only available in version Nova and above
cf3  -> Defined hard classes = { any verbose_mode Sunday Hr11 Morning Min48 Min45_50 Q4 Hr11_Q4 Day17 January Yr2010 Lcycle_0 GMT_Hr10 linux localhost undefined_domain 32_bit linux_2_6_31_5_desktop_1mnb i686 linux_i686 linux_i686_2_6_31_5_desktop_1mnb linux_i686_2_6_31_5_desktop_1mnb__1_SMP_Fri_Oct_23_01_46_54_EDT_2009 compiled_on_linux_gnu net_iface_lo net_iface_eth0 ipv4_10_0_2_15 ipv4_10_0_2 ipv4_10_0 ipv4_10 inet6_ fe80__a00_27ff_fe24_ef9f rootprocs_high_normal syslog_low_normal messages_low_normal entropy_netbiosns_in_low entropy_netbiosdgm_in_low entropy_netbiosssn_in_low entropy_irc_in_low entropy_cfengine_in_low entropy_nfsd_in_low entropy_smtp_in_low entropy_www_in_low entropy_ftp_in_low entropy_ssh_in_low entropy_wwws_in_low entropy_netbiosns_out_low entropy_netbiosdgm_out_low entropy_netbiosssn_out_low entropy_irc_out_low entropy_cfengine_out_low entropy_nfsd_out_low entropy_smtp_out_low entropy_ftp_out_low entropy_ssh_out_low entropy_icmp_in_low entropy_udp_in_low entropy_dns_in_low entropy_tcpsyn_in_low entropy_tcpack_in_low entropy_tcpfin_in_low entropy_misc_in_low entropy_icmp_out_low entropy_udp_out_low entropy_dns_out_low entropy_tcpsyn_out_low entropy_tcpack_out_low entropy_tcpfin_out_low entropy_misc_out_low cfengine_3_0_2 cfengine_3_0 cfengine_3 Mandrake Mandriva mandriva mandriva_2010 mandriva_2010_0 lsb_compliant mandrivalinux mandrivalinux_adelie mandrivalinux_2010_0 mandrivalinux_2010 common }
cf3  -> Negated Classes = { }
cf3 Initiate variable convergence...
cf3 Initiate control variable convergence...
cf3 Inputs are valid

Le -v vous inonde d'informations. Ne vous perdez pas, seule la dernière ligne compte, puisqu'elle vous indique explicitement que votre configuration est valide. Mais alors, comment faire votre cf, à proprement parler ? Et bien, comme vous avez pu lire, il faut d'abord revenir sur notre bon vieux concept concernant le composant central de Cfengine : les classes. Les classes sont toujours présentes et organisées en 2 grandes familles, les hard et les soft, dont on peut d'ailleurs facilement en avoir la liste avec un cf-promises -v. Elles sont définies exclusivement au sein de bundle, ces derniers pouvant être typés. Un bundle est un container qui permet de regrouper plusieurs déclarations et définitions de promesse. Le type d'un bundle est généralement le nom du composant auquel il est destiné. Le typage intervient sur la portée des classes et des traitements associés. Concrètement, un type common invoquera des classes globales au sens de la portée de la classe, un type server sera destiné... Et bien à notre cf-servd, le serveur -que nous appellerons aussi le policy host-, tandis que le type agent impliquera une utilisation locale des classes, et sera destiné à nos cf-agents -nos hosts. Il existe d'autres containers que le bundle, le body par exemple. Le body permet surtout d'organiser une série de paramétrages complexes sous une et une seule dénomination afin de faciliter son exploitation dans les divers bundles du fichier. Le nombre de body n'est pas limité, il est d'ailleurs recommandé d'en disposer plutôt que de lister toutes les variables, crûment, au sein du bundle en lui-même et de nuire ainsi à la lisibilité du fichier... Sans compter tout ce qui concerne la réutilisabilité du code... En logique, nous avons ça :

type:
classes::
"promiser"->{"promisee1","promisee2",...}
attribute_1=>value_1,
attribute_2=>value_2,
...
attribute_n=>value_n;

La promesse la plus simple est la suivante.

commands:
"/bin/echo Hello World";

commands est un type de promiser qui est défini par défaut dans Cfengine. Le promiser en lui-même ne constitue qu'une entité aux yeux de Cfengine, n'override pas les paramètres par défaut qui lui sont appliqués et n'en prend aucun. Et voici l'exemple illustrant le contenu d'un fichier /var/lib/cfengine/inputs/test.cf. L'association d'une variable avec sa valeur est faite via la syntaxe nomvariable => valeurs.

body common control {
bundlesequence => { "g", "tryclasse1", "tryclasse2" };
}

##
bundle common g {
classes:
"one" expression => "any" ;
}

##
bundle agent tryclasse1 {
classes:
"two" expression => "any" ;
}

##
bundle agent tryclasse2 {
classes:
"three" expression => "any";

reports:
one.three.!two::
"Success" ;
}

Ici, la classe one est globale à tout le fichier, alors que les two et three sont locales. Il en résulte que, dans le bundle tryclasse2, le report renvoie Success, car one est connue, three est connue, et two ne l'est pas. Toujours des détails, rien que ça, mais ça permet de mettre en lumière 2-3 éléments clés. Tout d'abord, la partie bundlesequence contenue dans la première déclaration, celle du body common control. C'est cette partie qui décide de l'enchainement des traitements. Ici, dans cet exemple succinct, nous demandons g, puis tryclasse1 et enfin tryclasse2. Il se trouve que c'est le même ordre dans lequel les classes sont déclarées, ne vous y trompez pas, la déclaration n'a aucun rapport avec l'ordre d'invocation. Seule la bundlesequence fait foi. Et c'est d'ailleurs pour ça que sa déclaration est en common. Common est le type de déclaration globale. Pour tester cette configuration, vous pouvez attaquer par un cf-promises -f pour la syntaxe et enchainer sur un cf-agent -f pour voir ce qui est vraiment fait.

[kbux@policyhost cfengine]# cf-promises -f /var/lib/cfengine/inputs/test0.cf
[kbux@policyhost cfengine]# cf-agent -f /var/lib/cfengine/inputs/test0.cf
R: Success

En un peu plus élaborée et demandant quelques argument, et nous avons :

bundle agent testbundle
{
files:
"/var/cfengine/inputs"

handle=>"update_policy",
depends_on=>"serve_updates",
perms=>system("600"),
copy_from=>mycopy("$(master_location)","$(policy_server)"),
depth_search=>recurse("inf"),
file_select=>input_files,
action=>immediate;
}

bundle server access_rules
{
access:
"/var/lib/cfengine/inputs"
admit=>{"192.168.0.*"};
}

body copy_from mycopy(from,server)
{
source=>"$(from)";
servers=>{"$(server)"};
copy_backup=>"true";
special_class::
purge=>"true";
}

Il est possible d'accéder aux variables définies au sein d'un bundle -soit dit en passant, si ce n'était pas le cas, où serait la fonctionnalité d'en disposer ?- pour peu qu'elles soient accessibles (mais si ! Rappelez-vous du scope des containers). Pour cela, la syntaxe rappelle celle du Java : nombundle.var. Nous n'en sommes toujours pas au niveau de ce que je vous avais promis, à savoir l'interaction et les traitements automatisés entre les hosts et le policy host (notre serveur Cfengine), mais nous n'en sommes pas loin. Comme je vous l'ai dit auparavant, Cfengine fonctionne sur un système de clé basé sur un modèle semblable à celui d'OpenSSH et mis en place par cf-keys. Ce qui implique donc la mise en place de l'infrastructure clé de Cfengine (vous savez, les copies des .pub sur le serveur et les hosts concernés), et naturellement, puisque Cfengine, par défaut, est imperméable aux sollicitations des nouvelles clés, un paramétrage plus fin des accès. Ca aussi, ça passe par des bundles de classe. Plus particulièrement, ces bundles étant destinés au serveur, leur typage lui aussi se distingue de ceux que nous avons vu jusqu'à présent : ils sont de type server. Le mécanisme doit passer plusieurs étapes. Tout d'abord, l'authentification.

body server control
{
allowconnects=>{"127.0.0.1","::1" ...etc };
allowallconnects=>{"127.0.0.1","::1" ...etc };
trustkeysfrom=>{"127.0.0.1","::1" ...etc };
}

Vos armes pour tester l'authentification sont principalement cf-agent -v et cf-servd -v. Éventuellement, vous pouvez passer en mode debug avec -d2. N'oubliez pas que vous devez enlever le trustkeysfrom de l'hôte qui a fini avec succès l'échange de clé. En effet, une fois la transmission acceptée, la déclaration de cet hôte à cet endroit n'a plus aucun intérêt. Petit point intéressant, si vous mettez en place sur une architecture conséquente, ça serait long de devoir se taper toutes les IPs à la main. On peut donc mettre, au lieu de notre trustkeysfrom un petit trustkey=>"true", ce qui aurait pour conséquence d'accepter toutes les sollicitations d'échange, et d'enregistrer toutes les clés associées. Avec tout ce que cela peut impliquer. Donc à faire sur un réseau safe et surtout de penser à le désactiver une fois tous les hosts enregistrées, car cela peut être dangereux. Ensuite, une fois que l'accès est ok, il vous faut spécifier qui a accès à quoi.

bundle server access_rules()
{
access:
"/var/lib/cfengine"
admit=>{"127.0.0.1","192.168.0.*"},
deny=>{"172\..*"};
}

Au final, votre configuration de serveur pourra éventuellement ressembler à ça :

#######################################################
# Server configuration
#######################################################
bundle server access_rules()
{
access:
"/var/lib/cfengine"
admit => { "127.0.0.1", "192.168.0.*" };
# Rule for cf-runagent
"/home/kbux/.cfagent/bin/cf-agent"
admit => { "127.0.0.1" };

# New in cf3 - RBAC with cf-runagent
roles:
".*" authorize => { "kbux" };
}

Il vous faut également, en plus du server.cf et du promises.cf, notre fameux update.cf qui donnera le ton aux cf-agents distants et un failsafe.cf. L'update.cf devra être le plus stable possible dans le temps, ne jamais le modifier serait l'idéal. Dans le cas où vous êtes amené à le modifier, faites en sorte de vérifier qu'il fonctionne correctement. L'officiel met à disposition cette matrice d'update.cf. A vous de jouer !

#######################################################
#
# update.cf
#
#######################################################
bundle agent update
{
files:
"/var/cfengine/inputs"
perms => system("600"),
copy_from => mycopy("/home/mark/cfengine-inputs","localhost"),
depth_search => recurse("inf");
"/var/cfengine/bin"
perms => system("700"),
copy_from => mycopy("/usr/local/sbin","localhost"),
file_select => cf3_files,
depth_search => recurse("inf");
}
############################################
body perms system(p)
{
mode => "$(p)";
}
############################################
Chapter 4: A complete conguration 51
body file_select cf3_files
{
leaf_name => { "cf-.*" };
file_result => "leaf_name";
}
#########################################################
body copy_from mycopy(from,server)
{
source => "$(from)";
compare => "digest";
}

Le failsafe.cf, quant à lui, est destiné aux cas où Cfengine n'arrive pas à lire votre configuration principale. C'est votre porte de sortie, notamment lorsqu'une migration ne s'est pas exactement passée comme prévue. Lui aussi devra subir aussi peu de changements que possible, et être testé très sérieusement pour éviter justement de ne pas vous en sortir en cas de pépin. Je vous donne également la matrice officielle du fichier.

#######################################################
#
# failsafe.cf
#
#######################################################
body common control
{
bundlesequence => { "update" };
}
#########################################################
bundle agent update
{
files:
"/var/cfengine/inputs"
perms => system,
copy_from => mycopy("/home/mark/cfengine-inputs","localhost"),
file_select => cf3_files,
depth_search => recurse("inf");
"/var/cfengine/bin"
perms => system,
copy_from => mycopy("/usr/local/sbin","localhost"),
file_select => cf3_files,
depth_search => recurse("inf");
}
#########################################################
body perms system
{
mode => "0700";
}
#########################################################
body depth_search recurse(d)
{
depth => "$(d)";
}
############################################
body file_select cf3_files
{
leaf_name => { "cf-.*" };
file_result => "leaf_name";
}
#########################################################
body copy_from mycopy(from,server)
{
source => "$(from)";
servers => { "$(server)" , "failover.domain.tld" };
#copy_backup => "true";
#trustkey => "true";
encrypt => "true";
}

Voilà. Normalement, vous êtes parés niveau configuration. Il ne vous reste plus qu'à tester, piocher sur les expressions régulières et les détails de variables, à savoir les listes, les scalaires, etc, etc, et vous serez vite enclin à adopter la solution. Allez-y doucement tout de même et n'oubliez pas d'exclure votre policy host des hosts qui doivent mettre leurs configurations à jour. Vous pouvez retrouver des ensembles consistants de fichier de configuration directement en lisant les documents officiels.

3408494K

Putty – petite piqure de rappel : X11 forwarding et Clés SSH

K-TUX — Tue, 03 Nov 2009 20:12:54 +0000

Salutations terriennes à vous, voyageurs égarés aux tréfonds des méandres trollesques tissées de mystères informatiques. Voici de quoi réconcilier les partisans GUI-Autologon-Windows avec les Linuxards X11-OpenSSHKeys grâce à la magie de Putty, d'OpenSSH et la complicité des précédemment cités. Oui, je sais. J'avais attaqué le sujet il n'y a pas si longtemps que ça, et pensais l'avoir exploré suffisamment loin... Pourtant me revoilà sur ce bout de billet, à rajouter ce qui m'avait échappé -sans que cela complète la liste exhaustive que Putty peut et sait faire. Une vraie mine d'or, cet outil ! Ce ticket concerne donc l'interaction Putty-X11, et celle impliquant Putty et OpenSSH. Commençons par le plus revendiqué chez les utilisateurs : le morceau User Friendly ! X11 Forwarding Saviez-vous, que, pour les adeptes de la GUI (Graphic User Interface), il existait le moyen de vous warper un environnement X11 (environnement graphique sous les Unix-like) de votre Linux directement sur votre poste Windows ? Et oui, c'est possible ! Tout cela grâce à la fabuleuse interaction et complémentarité de SSH avec Putty -sans oublier copain XMing- La manipulation nécessite que vous ayez un accès ssh à votre serveur Linux, que le X11 Forwarding soit déjà activé ou que vous soyez en mesure de l'activer et que vous ayez droit d'installer vos clients comme vous l'entendez pour votre machine Windows. Commencez par vous installer les outils nécessaires pour le client Windows : Putty, PuttyGen et Xming. Faites en sorte que XMing s'exécute en Service de fond, automatiquement sous Windows. Son fonctionnement est facilement repérable au X de la barre des tâches. Ensuite, il vous suffit de loader votre session SSH préférée sur Putty et, d'aller fureter au niveau des options de Connection > SSH > X11. Arrivé à ce niveau, validez la tickbox Enable X11 forwarding. Sauvegardez la session au besoin et lancez le tout. Un petit appel à firefox vous confirmera -ou non- que tout est fonctionnel. Il se peut que vous soyez tenu en échec par un message pas sympathique du tout, du genre :

connection to "localhost:10.0" refused by server
wrong authentication protocol attempted

C'est qu'en fait, votre utilisateur a déjà ouvert une session graphique sur le poste. Petite astuce, sous gnome par exemple, vous pouvez commencer par souffler ceux qui regardent par dessus votre épaule en lançant en arrière plan un gnome-panel (je rappelle, lancer un process en arrière plan sous Linux revient à finir la ligne de commande par un &). C'est bien joli tout ça, mais ce n'est pas tout. Et heureusement d'ailleurs (sinon ce serait moins amusant). Clés SSH Attention. Je dois mettre en garde -et c'est un pré-requis fort- le lecteur des risques de sécurité relatifs aux clés SSH non protégées avec une passphrase. Dangereux et passible de retourner contre vous la colère du BOFH. Les clés SSH sont des fichiers bien pratiques qui offrent à un utilisateur un autre moyen de s'authentifier que la frappe du mot de passe. Sécurisée par une passphrase, cela ne change rien dans les manipulations que l'utilisateur aura à effectuer pour s'authentifier -à la différence que la passphrase peut être différente du mot de passe. Si on ajoute à cela la possibilité d'une passphrase nulle... Pour commencer, il vous faut vous assurer que la partie suivante est activée dans /etc/ssh/sshd_config dans votre serveur Unix-like :

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile     %h/.ssh/authorized_keys

Ensuite, sur votre client Windows, générez une paire de clés SSH2-RSA en autant de bits que vous voulez avec PuttyGen. Renseignez le comment (plus facile de vous y retrouver), la Key passphrase et sa confirmation. Cliquez sur Generate et appliquez-vous à titiller votre souris pour que la génération de la clé soit le plus exotique possible. Surtout, sauvegardez la partie privée dans un emplacement bien à vous. La partie public n'est pas obligatoire, mais c'est bien de l'avoir. Gardez PuttyGen d'ouvert sur votre clé, histoire d'avoir les infos à portée de main. Ouvrez Putty et renseignez la session SSH sur laquelle vous voulez vous connecter. Dans la partie Connection > SSH > Auth, renseignez le chemin absolu de votre clé privée, sauvegardez la configuration et logguez vous sur le serveur SSH. Il bronche sur l'utilisation de la clé, normal, on ne lui a pas tout dit. Copiez le contenu de PuttyGen, dans la partie Public Key for pasting into OpenSSH authorized_keys file et, comme gentiment indiqué par PuttyGen, collez le contenu dans votre ~/.ssh/authorized_keys. Quittez la session SSH et retentez votre chance avec les mêmes paramétrages. Respirez, c'est loadé !

PSExec Tools : des outils qui changent la vie !

K-TUX — Thu, 22 Oct 2009 07:05:33 +0000

BIENVENUE sympatisant Windowsien. Comme beaucoup d'autres, tu es à la recherche d'un OS souple, simple, facile d'utilisation... Je te souhaite la bienvenue dans ton pire cauchemar !!! Tout commence par une difficile introduction au sein d'un réseau. Difficile oui, mais pas seulement pour l'utilisateur. En effet, l'administrateur, pauvre bête maltraitée, doit assurer le bon fonctionnement de tous les postes, et quand ça ne fonctionne pas... 2 solutions, [*]VNC ou le plus classique déplacement sur site. Et oui, c'est ça aussi, la magie de Windows. Oubliez tout ça. Oubliez la prise de main à distance, l'immobilisation de la machine sous l'œil agacé de l'utilisateur, l'accompagnement au bout du téléphone, pour tempérer un poil la situation et l'annulation pure et simple de vos manips par l'utilisateur. Voici venu l'ère des PSEXEC Tools et leur lot de facilité et de questions philosophiques touchant à la sécurité. PSEXEC Tools regroupe un ensemble d'outils permettant d'interagir de manière concise avec les autres Windows alentours. Concise car l'interaction se fait via un terminal DOS. Interagir car PSExec, dans sa fabuleuse panoplie d'outils, permet d'interroger la machine distante, de pousser du code, de la redémarrer,... Et PSExec car les outils s'inspirent du fameux ps des noyaux Unix-like. Maintenant qu'on a le visuel, autant rentrer un peu plus dans les détails pour savoir jusqu'où on peut aller avec. Tout d'abord, vous devez savoir une chose cruciale : PSExec utilise les admin shares présents par défaut sous Windows. Donc si, par un souci pointu de sécurité, vous avez viré ces partages, PSExec ne pourra pas s'exécuter sur votre machine -remarquez, vous êtes le Sysadmin, c'est peut-être mieux d'être effectivement dans ce cas-là. Pensez aussi à nos copains firewalls et antivirus. Pour réactiver les partages administratifs sur vos postes, un petit regedit sur le poste client vous amènera droit où ça fait mal. Attention justement, que ça fait mal quand on grifouille dans la base de registre. Soyez prudent et avancez d'un pas sûr. Explorez l'arbre jusqu'à la hive (oui, un répertoire, une arborescence, tout sauf une leaf s'appelle une hive) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters et sachez que si vous voulez que ça fonctionne, il vous faut impérativement une clé (key) de type REG_DWORD répondant au doux nom de AutoShareWks et initialisée à 1. En plus, si vous avez pris le parti de vous simplifier la vie, vous pourrez taper depuis votre poste dans la regedit de vos utilisateurs en utilisant le menu Fichier > Connexion au registre réseau. Tout est fin prêt, attaquons ! Tout d'abord, commencez par télécharger et dézipper l'outil sur http://download.sysinternals.com/. Les exécutables sont au nombre de 12 (psexec, psfile, psgetsid, psinfo, pskill, pslist, psloggedon, psloglist, pspasswd, psservice, psshutdown et pssuspend). D'ailleurs, pour plus de détails, n'hésitez pas à jeter un coup d'œil sur http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx. Il vous faut ensuite faire en sorte que votre OS cherche les exécutables au bon endroit. La solution la plus propre est bien sûr d'accorder notre variable PATH en fonction et donc d'y ajouter le chemin des exe extraits de l'archive. Pour ce faire, click droit sur Poste de travail > Propriétés > Avancées > Variables d'environnement. Arrivé là, il vous faut vous placer sur la variable PATH dans la partie inférieure, partie qui est réservée aux variables système, et ajouter à la chaine de caractère votre chemin, précédé de ; Ensuite, rien de plus simple, par exemple, d'afficher la configuration réseau d'un poste Windows distant en tapant dans une fenêtre DOS (Démarrer > Exécuter > cmd) :

psexec \\IPhotedistant ipconfig /all

Et après un petit temps de réflexion, les informations vous sont affichées sur votre terminal. Bien entendu, on peut être moins basique et balancer l'exécution d'un script en tapant sur une liste d'IP, le tout stocké sur Hote_referent avec :

psexec -d -s @\\Hote_referent\pathto\pclists.txt \\Hote_referent\pathto\script_install.cmd

Vous pouvez dès à présent croiser les pieds sur le bureau et commencer votre partie d'échec.