Différences

Ci-dessous, les différences entre deux révisions de la page.

--- linux:rewinged [2026/09/12 08:41] – root
+++ linux:rewinged [2026/09/18 17:40] (Version actuelle) – [13.2 Règles personnalisées] root
@@ Ligne 130: / Ligne 130: @@
 Restart=on-failure
 RestartSec=5
+# Journalisation vers fichier, pour collecte Wazuh en JSON natif
+StandardOutput=append:/var/log/rewinged/rewinged.log
+StandardError=append:/var/log/rewinged/rewinged.log
 # Durcissement
@@ Ligne 141: / Ligne 145: @@
 MemoryDenyWriteExecute=true
 ReadOnlyPaths=/srv/winget/manifests
-ReadWritePaths=/srv/winget/installers
+ReadWritePaths=/srv/winget/installers /var/log/rewinged
 [Install]
@@ Ligne 148: / Ligne 152: @@
 <code bash>
+mkdir -p /var/log/rewinged
+chown rewinged:rewinged /var/log/rewinged
 systemctl daemon-reload
 systemctl enable --now rewinged
 systemctl status rewinged
 </code>
+Rotation du journal :
+<file - /etc/logrotate.d/rewinged>
+/var/log/rewinged/rewinged.log {
+    daily
+    rotate 30
+    compress
+    missingok
+    notifempty
+    copytruncate
+    su rewinged rewinged
+}
+</file>
 ===== 4. Pare-feu de la VM =====
@@ Ligne 290: / Ligne 311: @@
 if [ "$BEFORE" != "$AFTER" ]; then
-    logger -t winget-sync "Publication: ${BEFORE:0:8} -> ${AFTER:0:8}"
+    # Verification de signature : voir section 13.3
+    if ! git verify-commit HEAD >/dev/null 2>&1; then
+        logger -t winget-sync -p auth.crit \
+            "SIGNATURE INVALIDE sur ${AFTER:0:8} - retour a ${BEFORE:0:8}"
+        git reset --hard "$BEFORE"
+        exit 1
+    fi
+    logger -t winget-sync "Publication verifiee: ${BEFORE:0:8} -> ${AFTER:0:8}"
 fi
 exit 0
 </file>
+Le bloc ''verify-commit'' suppose que les commits sont signés en GPG et que la
+clé publique du signataire est présente dans le trousseau du compte
+''rewinged''. Le retirer si la signature n'est pas en place — mais le conserver
+est ce qui rend la détection Wazuh exploitable (13.3).
 <code bash>
@@ Ligne 479: / Ligne 512: @@
 clients. Sans conséquence sur l'accès aux machines, mais à connaître.
-==== 9.4 Alternative documentée ====
+==== 9.4 Alternative : paquet unique ====
-RustDesk Server Pro permet d'assigner carnet d'adresses, alias, stratégie et
+Le paquet par client existe parce que le mot de passe non-surveillé est
-mot de passe **après** installation, via un token API :
+préconfiguré dans le MSI. Ce mot de passe peut aussi être posé **après**
+installation, ce qui autorise un paquet unique pour tout le parc.
-<code>
+=== Ce qui n'est pas possible ===
-RustDesk.exe --assign --token rapi_xxx ^
-  --address_book_name "Client-XXX" ^
+Le mot de passe permanent **ne se propage pas par API ni par stratégie**.
-  --address_book_alias %COMPUTERNAME%
+C'est un secret local à la machine. La demande d'en faire un paramètre de
-</code>
+stratégie Pro est ouverte depuis 2023 et n'a pas abouti.
+Ne pas confondre trois objets distincts :
+^ Élément ^ Où il vit ^ Comment il se pose ^
+| Mot de passe permanent | Sur la machine, haché localement | ''RustDesk.exe --password'' en local |
+| Mot de passe du carnet | Côté serveur Pro | ''--assign --address_book_password'' |
+| Stratégie Pro | Côté serveur Pro | Réglages client, **hors** mot de passe |
+Le premier authentifie les connexions entrantes. Le second est celui que le
+client technicien utilise pour remplir automatiquement le champ.
+=== Le flux en deux temps ===
+Le secret naît sur la machine, puis remonte vers le serveur.
+<file powershell onboard-rustdesk.ps1>
+$rd = "C:\Program Files\RustDesk\RustDesk.exe"
+# 1. Generer un mot de passe propre a CETTE machine
+$pw = -join ((48..57)+(65..90)+(97..122) | Get-Random -Count 20 | % {[char]$_})
+# 2. Le poser localement
+& $rd --password $pw
+# 3. Recuperer l'ID attribue
+$id = (& $rd --get-id).Trim()
+# 4. Rattacher au carnet du client et y stocker le mot de passe
+& $rd --assign `
+    --token $env:RUSTDESK_API_TOKEN `
+    --address_book_name "Client-$ClientCode" `
+    --address_book_alias $env:COMPUTERNAME `
+    --address_book_password $pw
+# 5. Archiver dans Vaultwarden (ID + mot de passe)
+</file>
+=== Ce que cela change ===
+  * **Un seul manifest** RustDesk pour l'ensemble du parc
+  * **Un mot de passe par machine** au lieu d'un par client : la fuite d'un
+    secret n'expose plus tout le parc d'un client
+  * Plus de régénération de MSI à chaque release
+  * Prérequis : Server Pro 1.5.8 et client 1.4.1 pour ''--address_book_alias''
+=== À valider avant de basculer ===
+<WRAP center round important>
+Un dysfonctionnement de ''RustDesk.exe --password'' sous Windows a été
+signalé en mai 2025 : la commande retourne sans effet. Tester sur un poste
+témoin, service arrêté puis démarré, avant de bâtir l'onboarding dessus.
+</WRAP>
-Cette voie autorise un paquet unique pour tout le parc, la différenciation
+Vérifier également que le token API utilisé porte les seules permissions
-passant dans le script d'onboarding. Elle exige Server Pro 1.5.8 et client
+''Device'' et ''Address Book'', et qu'il n'est pas écrit en clair dans le
-.4.1 minimum. À réévaluer si la charge de publication devient contraignante.
+script — le passer par variable d'environnement ou le récupérer depuis
+Vaultwarden au moment de l'exécution.
 ===== 10. Extraction des codes MSI =====
@@ Ligne 632: / Ligne 719: @@
 ===== 13. Surveillance Wazuh =====
-==== 13.1 FIM ====
+Trois sources distinctes : l'intégrité des fichiers, le journal applicatif de
+rewinged, et l'état des services.
-<file xml ossec.conf>
+==== 13.1 Configuration de l'agent ====
-<syscheck>
-  <directories check_all="yes" realtime="yes" report_changes="yes">
+<file xml /var/ossec/etc/ossec.conf>
-    /srv/winget/manifests
+<ossec_config>
-  </directories>
-  <directories check_all="yes" realtime="yes">
+  <!-- Integrite des fichiers -->
-    /srv/winget/installers
+  <syscheck>
-  </directories>
+    <disabled>no</disabled>
-  <directories check_all="yes" realtime="yes">
+    <frequency>3600</frequency>
-    /usr/local/bin
-  </directories>
+    <!-- Manifests : decident de ce que le parc installe -->
-</syscheck>
+    <directories check_all="yes" realtime="yes" report_changes="yes"
+                 tags="winget,manifests">/srv/winget/manifests</directories>
+    <!-- Installeurs : les binaires servis aux postes -->
+    <directories check_all="yes" realtime="yes"
+                 tags="winget,installers">/srv/winget/installers</directories>
+    <!-- Binaire rewinged et script de synchronisation -->
+    <directories check_all="yes" realtime="yes"
+                 tags="winget,binaries">/usr/local/bin</directories>
+    <!-- Unites systemd du service -->
+    <directories check_all="yes" realtime="yes"
+                 tags="winget,systemd">/etc/systemd/system</directories>
+    <!-- Bruit git interne -->
+    <ignore type="sregex">^/srv/winget/\.git/</ignore>
+  </syscheck>
+  <!-- Journal applicatif rewinged, deja en JSON -->
+  <localfile>
+    <log_format>json</log_format>
+    <location>/var/log/rewinged/rewinged.log</location>
+  </localfile>
+  <!-- Etat des services, toutes les 5 minutes -->
+  <localfile>
+    <log_format>full_command</log_format>
+    <command>systemctl is-active rewinged winget-sync.timer | tr '\n' ' '</command>
+    <alias>winget-services</alias>
+    <frequency>300</frequency>
+  </localfile>
+</ossec_config>
 </file>
-==== 13.2 Réduction du bruit ====
+Le journal de ''winget-sync'' passe par ''logger'', donc par syslog, déjà
+collecté par la configuration Wazuh par défaut.
-La FIM se déclenche à chaque synchronisation légitime. Pour distinguer le
+==== 13.2 Règles personnalisées ====
-légitime de l'anormal :
+<file xml /var/ossec/etc/rules/local_rules.xml>
+<group name="winget,rewinged,">
+  <rule id="100600" level="0">
+    <decoded_as>json</decoded_as>
+    <location>/var/log/rewinged/rewinged.log</location>
+    <description>rewinged: evenement applicatif</description>
+  </rule>
+  <rule id="100601" level="7">
+    <if_sid>100600</if_sid>
+    <field name="level">error</field>
+    <description>rewinged: erreur applicative</description>
+  </rule>
+  <rule id="100602" level="10">
+    <if_sid>100601</if_sid>
+    <field name="message">ingestManifests</field>
+    <description>rewinged: echec ingestion des manifests - $(message)</description>
+  </rule>
+  <rule id="100610" level="3">
+    <program_name>winget-sync</program_name>
+    <match>Publication verifiee</match>
+    <description>winget: publication synchronisee et verifiee</description>
+  </rule>
+  <rule id="100611" level="14">
+    <program_name>winget-sync</program_name>
+    <match>SIGNATURE INVALIDE</match>
+    <description>winget: signature invalide - synchronisation annulee</description>
+    <group>attack,</group>
+  </rule>
+  <rule id="100612" level="10" frequency="5" timeframe="1800">
+    <if_matched_sid>100601</if_matched_sid>
+    <description>winget: erreurs applicatives repetees</description>
+  </rule>
+  <rule id="100620" level="3">
+    <if_group>syscheck</if_group>
+    <field name="file">/srv/winget/manifests/</field>
+    <description>winget: manifest modifie - $(file)</description>
+  </rule>
+  <rule id="100621" level="12">
+    <if_group>syscheck</if_group>
+    <field name="file">/srv/winget/installers/</field>
+    <description>winget: installeur modifie - $(file)</description>
+    <group>attack,</group>
+  </rule>
+  <rule id="100622" level="14">
+    <if_group>syscheck</if_group>
+    <field name="file">/usr/local/bin/rewinged</field>
+    <description>winget: binaire rewinged modifie - $(file)</description>
+    <group>attack,</group>
+  </rule>
+  <rule id="100630" level="0">
+    <location>winget-services</location>
+    <description>winget: releve d'etat des services</description>
+  </rule>
+  <rule id="100631" level="10">
+    <if_sid>100630</if_sid>
+    <regex>inactive|failed|unknown</regex>
+    <description>winget: service rewinged ou timer arrete</description>
+  </rule>
+</group>
+</file>
+<WRAP center round important>
+Les identifiants 100600–100631 sont donnés à titre indicatif. Les adapter à
+la numérotation des règles personnalisées déjà en place.
+</WRAP>
+==== 13.3 Traiter le bruit FIM ====
+La FIM se déclenche à chaque publication légitime. Wazuh ne sait pas exprimer
+nativement « alerter sauf si précédé de tel événement », il faut donc déplacer
+le contrôle plutôt que tenter de corréler.
+**Approche retenue** : la signature GPG des commits est le contrôle réel.
+  - Les commits de publication sont signés ; la clé publique du signataire est
+    dans le trousseau du compte ''rewinged''
+  - ''winget-sync.sh'' vérifie la signature et annule la synchronisation en cas
+    d'échec (section 7.2)
+  - La FIM sur ''manifests'' reste **informative** (niveau 3) : elle documente,
+    elle n'alerte pas
+  - L'alerte forte porte sur la signature invalide (100611, niveau 14)
+Une modification de manifest effectuée directement sur le serveur ne passe pas
+par un commit, donc ne déclenche pas 100611 — mais elle sera écrasée au
+prochain ''merge --ff-only'', et la FIM en garde la trace.
+Les installeurs et les binaires, eux, ne changent pas hors publication : leurs
+règles restent à niveau élevé.
+==== 13.4 Mise en place de la signature ====
+Côté poste de publication :
+<code bash>
+git config --global user.signingkey <ID_CLE>
+git config --global commit.gpgsign true
+gpg --export --armor <ID_CLE> > mis-publication.pub
+</code>
+Côté serveur rewinged :
+<code bash>
+sudo -u rewinged gpg --import mis-publication.pub
+sudo -u rewinged gpg --edit-key <ID_CLE> trust   # niveau ultimate
+sudo -u rewinged git -C /srv/winget verify-commit HEAD
+</code>
-  * signer les commits en GPG et vérifier la signature dans ''winget-sync''
+Idéalement la clé de signature réside sur une YubiKey, cohérent avec
-    avant application — un fichier modifié sans commit signé devient alors une
+l'autorité de certification SSH déjà en place.
-    alerte non ambiguë
-  * à défaut, corréler avec les logs de ''winget-sync.service''
-==== 13.3 Alertes complémentaires ====
+==== 13.5 Ce qui reste non couvert ====
-  * arrêt du service ''rewinged''
+  * **Publication légitime mais erronée** — un mauvais ''PackageIdentifier''
-  * échecs répétés de ''winget-sync.timer'' — un dépôt figé est un mode de
+    ou un SHA256 incorrect signé de bonne foi passe toutes les vérifications.
-    panne silencieux
+    Le garde-fou est la revue de la PR, pas la détection.
-  * volumétrie anormale de téléchargements sur ''/installers/''
+  * **Compromission du poste de publication** — si la clé de signature est
-  * saturation disque de la VM (croissance LFS)
+    utilisable par un attaquant, la chaîne entière est valide de son point de
+    vue. D'où la YubiKey.
+  * **Saturation disque** — à surveiller côté Zabbix plutôt que Wazuh, la
+    croissance LFS étant progressive et prévisible.
 ===== 14. Points ouverts =====
@@ Ligne 673: / Ligne 914: @@
 | Server 2019/2022 | Inventorier la proportion dans le parc |
 | Upgrade RustDesk | Vérifier que la mise à jour préserve ''RustDesk2.toml'' et le mot de passe permanent |
+| ''--password'' sous Windows | Tester le réglage du mot de passe en ligne de commande (9.4) avant d'envisager le paquet unique |
 | Rétention LFS | Définir une politique de purge des anciennes versions d'installeurs |
 | Quota Forgejo | Dimensionner le stockage LFS et surveiller sa croissance |