|
|
||
|---|---|---|
| 3cx_Rules.xml | ||
| Brut-force-VPN.xml | ||
| Brut-force-linux.xml | ||
| Connexion-admin.xml | ||
| Logon-failure-win.xml | ||
| README.md | ||
| Suricata.xml | ||
| brut-force.xml | ||
| local_rules.xml | ||
| unifi-rules.xml | ||
README.md
Wazuh - Custom Rules (local_rules)
Repo de gestion de version pour les custom rules Wazuh (et optionnellement decoders / lists). Objectif : versionner, documenter, tester, et déployer proprement sur un ou plusieurs Wazuh Manager.
Contenu
rules/: règles locales (local_rules.xmlou fichiers découpés par thèmes)decoders/: decoders locaux (si utilisés)lists/: CDB lists (si utilisées)tests/: exemples d'événements/logs de testscripts/: scripts de validation / déploiement (optionnel)
Prérequis
- Accès au Wazuh Manager
- Droits root / wazuh selon votre infra
- Connaissance de base Wazuh ruleset (
<group>,<rule>,<if_sid>, etc.)
Chemins classiques sur le manager :
- Rules locales :
/var/ossec/etc/rules/local_rules.xml - Decoders locaux :
/var/ossec/etc/decoders/local_decoder.xml - Lists :
/var/ossec/etc/lists/
Bonnes pratiques
1) Règles : petites et lisibles
- 1 règle = 1 objectif
- Commenter les règles non triviales
- Garder une logique de nommage
Exemple de convention :
- IDs : réserver une plage (ex:
100000-109999) pour votre org - Groupes :
local,windows,authentication/local,linux,hardeningetc.
2) Ne pas casser le pipeline
- Toujours valider la syntaxe XML
- Tester avec des logs réels/samples avant mise en prod
- Éviter les conditions trop larges (sinon alert storm)
3) Versionner ce qui est "source"
- Versionner : règles, decoders, lists, samples de test
- Ne pas versionner : secrets, exports complets, archives, fichiers temporaires
Déploiement (manuel)
1) Sauvegarde (recommandé)
sudo cp /var/ossec/etc/rules/local_rules.xml /var/ossec/etc/rules/local_rules.xml.bak.$(date +%F_%H%M)