Démarrer

Installer l’agent

Une commande par serveur : l’agent s’installe, s’inscrit et envoie ses premières mesures en moins d’une minute.

Ce qu’il faut

Un serveur Linux avec systemd (Debian, Ubuntu ou la famille Red Hat), en x86_64 ou arm64.
Un accès root, par sudo.
curl, ou wget : remplacez alors curl -fsSL par wget -qO- dans les commandes envoyées à sh.
Une connexion HTTPS sortante vers get.kelva.sh pour l’installation, puis vers ingest.kelva.sh.

Windows Server et macOS arrivent bientôt.

La commande

Dans Kelva, ouvrez « Ajouter une machine », choisissez le système et copiez la commande : elle contient un jeton d’inscription valable 15 minutes, utilisable une fois. Collez-la sur le serveur.

$curl -fsSL https://get.kelva.sh | sudo sh -s -- --token kv_enr_…

La machine apparaît dans Kelva en moins d’une minute. Avec les offres Pro et Équipe, choisissez d’abord son dossier : il est porté par la commande, et la machine y arrive directement (voir Dossiers).

Pour lire le script avant de le lancer, téléchargez-le, puis passez le jeton sur l’entrée standard : il ne reste pas dans l’historique du shell.

shell

curl -fsSL https://get.kelva.sh -o install.sh

Avec wget, le téléchargement s’écrit autrement.

shell

wget -qO install.sh https://get.kelva.sh

shell

sudo sh install.sh --token -

Ce qu’elle installe

1
L’agent pour l’architecture du serveur, vérifié par son empreinte SHA-256.
2
L’utilisateur système kelva, sans shell de connexion.
3
/usr/local/bin/kelva, avec un lien /usr/bin/kelva pour que sudo kelva le trouve sur toutes les distributions, le service systemd kelva et un fichier de configuration commenté, /etc/kelva/agent.conf, jamais modifié s’il existe.
4
La clé de la machine, contre le jeton, lisible par kelva seul.
5
Puis le service démarre, et la commande attend le premier envoi.

Relancée, la commande met l’agent à jour et garde la clé de la machine.

Ce que fait l’agent

Il n’ouvre que des connexions sortantes, en HTTPS, vers ingest.kelva.sh : il n’écoute sur aucun port.
Il lit sans rien modifier. Il ne lance que des commandes en lecture seule (apt-get -s, systemctl list-units…) et jamais une commande venue du serveur, que le protocole ne sait pas envoyer.
Il tourne sous l’utilisateur kelva, dans un bac à sable systemd : le système entier en lecture seule, sauf /var/lib/kelva.
Quand Kelva ne répond pas, il garde ses mesures sur le disque, jusqu’à 24 heures, et les envoie dans l’ordre au retour.

Une seule capacité, CAP_DAC_READ_SEARCH : lire n’importe quel fichier, n’en écrire aucun. Quatre contrôles en ont besoin, pour des fichiers que seul root peut lire : les deux de SSH, celui des certificats TLS et celui des sauvegardes. Pour la refuser, ajoutez --no-read-all à la commande ; Kelva marque alors ces contrôles « non vérifiable » pour ces fichiers. --read-all la rend.

Vérifier

kelva status dit si l’agent est inscrit et s’il envoie, et sinon pourquoi. Ses messages sont en anglais.

shell

sudo kelva status

kelva check lance les contrôles de l’agent une fois et les affiche, sans rien envoyer.

shell

sudo kelva check

Le journal du service garde le reste.

shell

sudo journalctl -u kelva

Une machine en pause

Quand l’organisation passe à une offre qui suit moins de machines, Kelva met en pause celles en trop : leur historique et leur clé sont gardés, et leur agent continue de tourner.

Il ne garde plus de mesures sur le disque et ne lance plus de contrôle ; celles qu’il gardait d’avant la pause partent à la reprise.
Il redemande toutes les 15 minutes, et reprend de lui‑même dès que la machine redevient active, sans réinstallation ni redémarrage.

kelva status le dit (paused), avec l’heure de la pause et celle de la prochaine vérification. La commande d’installation, relancée, le dit aussi.

Proxy et pare-feu

Le pare-feu doit laisser sortir le port 443 vers get.kelva.sh pendant l’installation, puis vers ingest.kelva.sh. Rien à ouvrir en entrée.

Derrière un proxy, donnez-le à votre shell pour le téléchargement, puis au script, car sudo l’efface :

shell

export HTTPS_PROXY=http://proxy.example.com:3128

Puis, dans la commande que Kelva vous donne, passez-le au script :

$curl -fsSL https://get.kelva.sh | sudo HTTPS_PROXY=$HTTPS_PROXY sh -s -- --token kv_enr_…

Avec wget, qui ne lit que https_proxy, donnez-le aussi en minuscules, au shell et au script.

Puis au service, une fois : ouvrez son fichier d’ajouts, écrivez [Service] et, dessous, Environment=HTTPS_PROXY=http://proxy.example.com:3128, enregistrez, puis redémarrez-le.

shell

sudo systemctl edit kelva

shell

sudo systemctl restart kelva

Mettre à jour

Relancez la commande, sans jeton : l’agent passe à la dernière version, la machine garde sa clé et le service redémarre.

shell

curl -fsSL https://get.kelva.sh | sudo sh

Si l’agent a été inscrit avec une autre adresse d’envoi (--endpoint), pointez-le vers ingest.kelva.sh sans le réinscrire, puis redémarrez-le :

shell

sudo kelva config set endpoint https://ingest.kelva.shsudo systemctl restart kelva

Désinstaller

--uninstall retire l’agent et son service, et garde sa clé et sa configuration : une nouvelle installation reprend la même machine.

shell

curl -fsSL https://get.kelva.sh | sudo sh -s -- --uninstall

--purge retire tout : l’agent, sa clé, sa configuration et l’utilisateur kelva.

shell

curl -fsSL https://get.kelva.sh | sudo sh -s -- --purge

Avant de s’arrêter, l’agent prévient Kelva : la machine passe « Désinstallée ». Son historique est gardé, ses alertes s’arrêtent et elle libère sa place dans votre offre ; avec --purge, sa clé est aussi révoquée. « Retirer cette machine », sur sa fiche, efface son historique.

Si Kelva n’a pas pu être prévenu, le script le dit : retirez alors la machine vous‑même, sinon elle apparaîtra hors ligne.

Les contrôles

L’agent les lance toutes les cinq minutes. Chacun a sa page, qui explique comment corriger ce qu’il trouve. Un contrôle sans objet, à configurer ou non vérifiable ne compte pas dans le score de la machine.

Mises à jour de sécurité: Kelva compte les mises à jour de sécurité disponibles que la machine n’a pas encore installées.
Services: Kelva vérifie qu’aucun service de la machine ne s’est arrêté sur une erreur.
Connexion root par SSH: Kelva vérifie que le compte root ne peut pas ouvrir de session SSH avec un mot de passe.
Authentification SSH par mot de passe: Kelva vérifie que SSH refuse les mots de passe et n’accepte que les clés.
Pare-feu: Kelva vérifie qu’un pare-feu est actif sur la machine.
Certificats TLS: Kelva vérifie la date d’expiration des certificats TLS installés sur la machine.
Espace disque: Kelva vérifie qu’aucun disque n’est près d’être plein, ni en espace ni en nombre de fichiers.
Redémarrage en attente: Kelva vérifie si des mises à jour attendent un redémarrage pour s’appliquer.
Heure synchronisée: Kelva vérifie que l’horloge de la machine est synchronisée sur un serveur de temps.
Sauvegarde récente: Kelva vérifie que la dernière sauvegarde est récente, d’après le fichier ou le dossier que vous lui indiquez.
Support du système: Kelva vérifie que la version du système reçoit encore des correctifs de sécurité.
Ports ouverts: Kelva relève les ports ouverts aux autres machines et repère les bases de données ou l’API Docker joignables de l’extérieur.
Connexions SSH refusées: Kelva compte les connexions SSH refusées sur 24 heures et vérifie qu’un outil comme fail2ban les bloque.
Mises à jour automatiques: Kelva vérifie que les mises à jour de sécurité s’installent seules, sans attendre qu’on les lance.
Chiffrement du disque: Kelva vérifie que les disques d’un serveur physique sont chiffrés.