---

## 1. Introduction

Architecture de LMD, étapes de détection et plateformes prises en charge.

Linux Malware Detect (LMD) est un scanner de malwares pour Linux publié sous licence GNU GPLv2, conçu autour des menaces rencontrées dans les environnements d'hébergement mutualisé. Il utilise les données de menace des systèmes de détection d'intrusion en périphérie de réseau pour extraire les malwares activement utilisés dans les attaques et génère des signatures pour leur détection. En outre, les données de menace proviennent de soumissions d'utilisateurs via la fonctionnalité de vérification (checkout) de LMD et de ressources communautaires dédiées aux malwares.

LMD se concentre sur les classes de malwares que les produits antivirus traditionnels manquent fréquemment : shells PHP, injecteurs JavaScript, backdoors encodées en base64, bots IRC et autres menaces de la couche application web qui ciblent les comptes d'utilisateurs d'hébergement mutualisé plutôt que les composants internes du système d'exploitation.

**Étapes de détection**
- Correspondance d'empreintes MD5 pour l'identification exacte des menaces
- Correspondance de motifs HEX via le moteur natif de recherche par lots (grep) avec workers parallèles
- Analyse par signatures composées (csig) avec logique booléenne multi-motifs (AND/OR/seuil), correspondance insensible à la casse, correspondance étendue (UTF-16LE) et jokers à espacement borné
- Analyse native de règles YARA avec prise en charge complète des modules et règles personnalisées
- Analyse statistique de la longueur des chaînes pour détecter les menaces obscurcies (base64, gzinflate)
- Intégration ClamAV pour une couverture étendue avec les signatures ClamAV maintenues par LMD

**Analyse et surveillance**
- Analyse de tous les fichiers, des fichiers récemment modifiés ou d'une liste de fichiers
- Surveillance de fichiers en temps réel via l'inotify du noyau (événements create/modify/move)
- Analyse des téléversements HTTP via le hook `inspectFile` de ModSecurity2
- Analyse en arrière-plan pour les opérations massives sans surveillance
- Filtrage par expression régulière d'inclusion/exclusion par analyse

**Quarantaine et réponse**
- File de quarantaine avec stockage de fichiers à zéro permission
- Quarantaine/restauration par lot par identifiant d'analyse
- Règles de nettoyage spécifiques aux signatures pour la suppression des malwares
- Restauration complète des fichiers (contenu, propriétaire, permissions, mtime)

**Alertes et rapports**
- Alertes e-mail HTML + texte avec le design unifié rfxn (marque bleu sarcelle, entrées en cartes)
- Prise en charge du relais SMTP (TLS/SSL) pour les environnements sans MTA local
- Alertes par entrée via Slack Block Kit, Telegram MarkdownV2, Discord embed
- Modèles d'alerte personnalisables via les remplacements `alert/custom.d/`
- Rapports d'analyse avec détails de correspondance par fichier, types de correspondance codés par couleur

**Infrastructure**
- Liaison automatique des signatures ClamAV pour une couverture double moteur
- Cron quotidien avec détection automatique de plus de 12 panneaux de contrôle d'hébergement
- Contrôle des ressources CPU/IO (nice, ionice, cpulimit)
- Mises à jour automatiques des signatures et de la version
- Unité de service systemd et prise en charge du script init SysV

### Plateformes prises en charge

LMD fonctionne sur toute distribution Linux avec bash et les utilitaires GNU standard. Plateformes testées :

| Plateforme | Système d'init | Chemin de configuration du paquet |
|----------|-------------|---------------------|
| RHEL / Rocky / AlmaLinux 8, 9, 10 | systemd | `/etc/sysconfig/maldet` |
| CentOS 6, 7 | SysV / systemd | `/etc/sysconfig/maldet` |
| Debian 10, 11, 12 | systemd | `/etc/default/maldet` |
| Ubuntu 20.04, 22.04, 24.04 | systemd | `/etc/default/maldet` |
| Gentoo | OpenRC | — |
| Slackware | SysV | — |
| FreeBSD | — | — (partiel ; pas d'inotify) |

---

## 2. Installation

Installation, mise à niveau et suppression de LMD d'un système.

Le script `install.sh` inclus gère toutes les tâches d'installation. Les installations précédentes sont automatiquement sauvegardées.```bash
./install.sh

### 3.1 Options générales

| Variable | Description | Défaut |
|----------|---------|---------|
| `autoupdate_signatures` | Mettre à jour automatiquement les signatures chaque jour via cron | `1` |
| `autoupdate_version` | Mettre à jour automatiquement la version de LMD chaque jour via cron | `1` |
| `autoupdate_version_hashed` | Vérifier le hash SHA-256 de l'exécutable LMD par rapport à la version en amont (repli sur MD5) | `1` |
| `sigup_interval` | Heures entre les vérifications automatiques de mise à jour des signatures via une tâche cron indépendante (`/etc/cron.d/maldet-sigup`) ; 0 = désactivé | `6` |
| `cron_prune_days` | Jours de conservation des données de quarantaine/session/temp | `21` |
| `cron_daily_scan` | Activer l'analyse automatique quotidienne via cron | `1` |
| `scan_days` | Jours à prendre en compte pour les fichiers modifiés lors des analyses cron quotidiennes | `1` |
| `import_config_url` | URL de téléchargement d'une configuration distante de remplacement | — |
| `import_config_expire` | Expiration du cache pour la configuration importée (secondes) | `43200` |
| `sig_import_md5_url` | URL de téléchargement des signatures MD5 personnalisées | — |
| `sig_import_hex_url` | URL de téléchargement des signatures HEX personnalisées | — |
| `sig_import_yara_url` | URL de téléchargement des règles YARA personnalisées | — |
| `sig_import_sha256_url` | URL de téléchargement des signatures SHA-256 personnalisées | — |
| `sig_import_csig_url` | URL de téléchargement des signatures composées personnalisées | — |
| `session_legacy_compat` | Générer des fichiers de session texte brut hérités en plus du TSV : `auto` (détecter les sessions au format ancien), `1` (toujours), `0` (TSV uniquement) | `auto` |

### 3.2 Alertes

| Variable | Description | Défaut |
|----------|---------|---------|
| `email_alert` | Activer les alertes par e-mail après les analyses | `0` |
| `email_addr` | Adresse du destinataire des alertes | `[email protected]` |
| `email_subj` | Modèle d'objet de l'e-mail | `maldet alert from $(hostname)` |
| `email_ignore_clean` | Supprimer les alertes lorsque toutes les détections ont été nettoyées | `1` |
| `email_panel_user_alerts` | Envoyer des alertes aux utilisateurs du panneau lors d'une détection | `0` |
| `email_panel_from` | En-tête De pour les alertes des utilisateurs du panneau | `[email protected]` |
| `email_panel_replyto` | En-tête Répondre à pour les alertes des utilisateurs du panneau | `[email protected]` |
| `email_panel_alert_subj` | Objet des alertes pour les utilisateurs du panneau | `maldet alert from $(hostname)` |
| `email_format` | Format de l'e-mail : `text`, `html` ou `both` | `html` |
| `smtp_relay` | URL du relais SMTP (par ex., `smtps://smtp.gmail.com:465`) | — |
| `smtp_from` | Adresse de l'expéditeur pour l'envoi via relais SMTP | — |
| `smtp_user` | Nom d'utilisateur pour l'authentification SMTP | — |
| `smtp_pass` | Mot de passe pour l'authentification SMTP | — |
| `slack_alert` | Activer les alertes Slack par téléversement de fichier | `0` |
| `slack_subj` | Nom de fichier pour le téléversement Slack | `maldet alert from $(hostname)` |
| `slack_token` | Jeton de l'API Bot Slack (portées : `files:write`, `files:read`) | — |
| `slack_channels` | Liste de noms ou d'identifiants de canaux séparés par des virgules | `maldetreports` |
| `telegram_alert` | Activer les alertes Telegram | `0` |
| `telegram_bot_token` | Jeton de l'API Bot Telegram | — |
| `telegram_channel_id` | Identifiant du chat ou du groupe Telegram | — |
| `discord_alert` | Activer les alertes Discord via webhook | `0` |
| `discord_webhook_url` | URL du webhook Discord pour l'envoi des alertes | — |

### 3.3 Options d'analyse

| Variable | Description | Défaut |
|----------|---------|---------|
| `scan_hashtype` | Algorithme de hachage pour l'étape 1 : `auto`, `sha256`, `md5`, `both` | `auto` |
| `scan_max_depth` | Profondeur maximale de répertoire pour find | `15` |
| `scan_min_filesize` | Taille de fichier minimale à analyser | `24` octets |
| `scan_max_filesize` | Taille de fichier maximale à analyser | `2048k` |
| `scan_hexdepth` | Profondeur en octets pour la correspondance des signatures HEX | `262144` |
| `scan_hex_chunk_size` | Fichiers par micro-lot lors de l'analyse HEX+CSIG (plage : 1024-20480) | `10240` |
| `scan_csig` | Activer l'analyse par signatures composées (csig) (mode natif uniquement) | `1` |
| `scan_workers` | Workers parallèles pour les passes d'analyse MD5, SHA-256, HEX et CSIG | `auto` |
| `scan_cpunice` | Priorité nice du processus d'analyse (-19 à 19) | `19` |
| `scan_ionice` | Priorité de la classe d'ordonnancement E/S (0 à 7) | `6` |
| `scan_cpulimit` | Limite CPU stricte en pourcentage (0=désactivé) | `0` |
| `scan_ignore_root` | Ignorer les fichiers appartenant à root lors des analyses (non appliqué en mode surveillance par défaut ; voir `monitor_scan_owner_filters`) | `1` |
| `scan_ignore_user` | Ignorer les fichiers appartenant à des utilisateurs spécifiques | — |
| `scan_ignore_group` | Ignorer les fichiers appartenant à des groupes spécifiques | — |
| `scan_user_access` | Autoriser les utilisateurs non root à lancer des analyses | `0` |
| `scan_user_access_minuid` | UID minimal pour la création des répertoires utilisateur avec --mkpubpaths | `100` |
| `scan_find_timeout` | Délai d'expiration pour la génération de la liste de fichiers find (0=désactivé, min 60 s, 14400=4 h recommandé) | `0` |
| `scan_export_filelist` | Enregistrer les résultats de find dans tmp/find_results.last | `0` |
| `scan_tmpdir_paths` | Chemins temporaires inscriptibles par tous inclus dans les analyses -a/-r | `/tmp /var/tmp /dev/shm /var/fcgi_ipc` |
| `string_length_scan` | Activer l'analyse statistique de la longueur des chaînes | `0` |
| `string_length` | Longueur minimale de chaîne suspecte | `150000` |
| `scan_progress_log_interval` | Secondes entre les points de contrôle du journal de progression lors des analyses en arrière-plan (0=désactivé) | `60` |
| `scan_meta_cleanup_age` | Heures de conservation des fichiers méta d'analyse terminés/interrompus (0=désactivé) | `48` |
| `maint_compress_age` | Jours avant que les fichiers de session terminés soient compressés en gzip (0=désactivé) | `30` |
| `maint_archive_age` | Jours avant que les sessions compressées soient regroupées dans des archives mensuelles (0=désactivé) | `90` |

### 3.4 Analyse YARA

L'analyse YARA native invoque le binaire `yara` (ou `yr` de YARA-X) indépendamment de ClamAV, et prend en charge les modules YARA complets, les règles compilées et les fichiers de règles personnalisés que le sous-ensemble YARA limité de ClamAV ne peut pas traiter. Lorsque les deux sont disponibles, `yr` (YARA-X) est préféré. En mode `auto`, l'analyse YARA native n'est activée que si ClamAV est indisponible et qu'un binaire yara/yr est trouvé, évitant ainsi la double évaluation des règles.

| Variable | Description | Défaut |
|----------|---------|---------|
| `scan_yara` | Activer l'étape d'analyse YARA native : `auto` (détecter le binaire, repli sur ClamAV), `0` (désactivé), `1` (activé) | `auto` |
| `scan_yara_timeout` | Délai d'expiration en secondes (0=aucun délai) | `300` |
| `scan_yara_scope` | Portée des règles lorsque ClamAV est également actif : `all` (analyse native complète) ou `custom` (uniquement les règles personnalisées en natif, ClamAV gère rfxn.yara) | `custom` |
| `sig_import_yara_url` | URL de téléchargement des règles YARA personnalisées lors de la mise à jour des signatures | — |

**Règles YARA personnalisées** peuvent être placées à deux emplacements, tous deux préservés lors des mises à niveau :
- `sigs/custom.yara` — règles dans un fichier unique
- `sigs/custom.yara.d/` — répertoire drop-in pour les fichiers de règles `.yar` et `.yara`

Compatible avec les ensembles de règles tiers tels que [YARA Forge](https://yarahq.github.io/) et [Signature Base](https://github.com/Neo23x0/signature-base). Les règles compilées (sortie de `yarac`) sont également prises en charge via `sigs/compiled.yarc`.

**Analyse par lots :** YARA 4.0+ et toutes les versions de YARA-X utilisent `--scan-list` pour une analyse par lots efficace des fichiers. Les versions plus anciennes de YARA reviennent automatiquement à une analyse fichier par fichier.

Activer à l'exécution sans modifier la configuration :```bash
maldet -co scan_yara=1 -a /home/?/public_html

### 4.1 Codes de sortie

| Code | Signification |
|------|---------------|
| `0` | Succès, aucune détection de malware |
| `1` | Erreur ou tous les chemins de scan inexistants |
| `2` | Détections de malware trouvées |

**Exemples :**```bash
# Scan all files under user web roots
maldet -a /home/?/public_html

# Scan recent files with auto-quarantine and YARA enabled
maldet -co quarantine_hits=1,scan_yara=1 -r /home/?/public_html 2

# Background scan with email alert to specific address
maldet -b -co [email protected] -a /var/www

# View the most recent scan report
maldet -e

# Email a specific report
maldet --mailto [email protected] -e 050910-1534.21135

# Output scan report as JSON (pipe to jq for formatting)
maldet --format json -e 050910-1534.21135

# List all reports as JSON
maldet --format json -e list

# Shorthand JSON output (equivalent to --format json -e)
maldet --json-report 050910-1534.21135

# Restore all quarantined files from a scan
maldet -s 050910-1534.21135

**Reprise du point de contrôle :** `--stop` écrit un fichier de point de contrôle enregistrant l'étape d'analyse,
le nombre de correspondances, les options de configuration et la progression par worker. `--continue` valide le point de contrôle,
avertit si les signatures ont changé, reconstruit la liste de fichiers à partir de l'état actuel du système de fichiers, restaure
les correspondances précédentes et reprend l'analyse depuis l'étape interrompue. Les workers HEX reprennent à la granularité
des chunks (~30s de travail perdu par worker).

**Support du moteur :** Le moteur natif (workers HEX/CSIG/hash) et le `clamscan` autonome
prennent en charge toutes les opérations du cycle de vie. Le ClamAV basé sur un démon (`clamdscan`/`clamd`) ne prend en charge
que `--kill` — `--pause` et `--stop` sont rejetés avec un message d'erreur, car
l'état des E/S du démon est opaque et partagé avec d'autres clients.

---

## 5. Options d'exclusion

Exclure des chemins, des types de fichiers et des signatures des analyses et de la surveillance.

Quatre fichiers d'ignore contrôlent ce qui est exclu de l'analyse :

| Fichier | Format | Rôle |
|------|--------|---------|
| `ignore_paths` | Chemins un par ligne | Exclure des répertoires ou fichiers des analyses |
| `ignore_file_ext` | Extensions un par ligne | Exclure des extensions de fichiers (`.js`, `.css`) |
| `ignore_sigs` | Motifs un par ligne | Ignorer les signatures correspondantes (regex, correspondance de sous-chaîne) |
| `ignore_inotify` | Chemins littéraux un par ligne | Exclure les événements de surveillance inotify |

Tous les fichiers d'ignore sont situés sous `/usr/local/maldetect/`.

**Exemples :**```
# ignore_paths
/home/user/public_html/cgi-bin

# ignore_file_ext
.js
.css

# ignore_sigs
base64.inject.unclassed

# ignore_inotify (user-owned — your additions only)
/home/user/public_html/cache/
backup-

# ignore_inotify.defaults (LMD-managed — refreshed on every upgrade)
# Ships under /usr/local/maldetect/internals/ with curated defaults
# for systemd-private tmpdirs, MariaDB temp tables, Redis, ClamAV, etc.
# Do NOT edit — add your own entries to ignore_inotify instead.

**Comment ça fonctionne :**

`maldet -m` exécute un processus superviseur au premier plan par défaut. Le superviseur gère un enfant `inotifywait` et assure la récupération après crash, les rechargements de configuration et les alertes de synthèse (digest). Utilisez `-b` pour démarrer le superviseur en démon et revenir immédiatement.

1. `monitor_init()` configure des watches inotify sur tous les fichiers des chemins surveillés
2. Les événements fichier sont mis en file d’attente et analysés par lots toutes les `inotify_sleep` secondes (par défaut : 15)
3. La configuration est rechargée toutes les `inotify_reloadtime` secondes (par défaut : 3600)
4. Les paramètres noyau `max_user_watches` et `max_user_instances` sont automatiquement ajustés pour des performances optimales
5. Si `inotifywait` plante, le superviseur le redémarre avec un backoff exponentiel (2, 4, 8, 16, 32 secondes) ; après 3 échecs consécutifs, le superviseur se termine

**Alertes de synthèse :** elles sont envoyées périodiquement à l’intervalle défini par `digest_interval` (par défaut : `24h`). Si le nombre de détections depuis le dernier digest dépasse `digest_escalate_hits`, une alerte d’escalade immédiate est envoyée (par défaut : `0`, désactivé).

**Chemins additionnels :** Pour surveiller des chemins supplémentaires sans modifier `conf.maldet`, ajoutez-les un par ligne au fichier référencé par `monitor_paths_extra` (par défaut : `/usr/local/maldetect/monitor_paths.extra`). Ils sont fusionnés avec la liste de surveillance principale à chaque rechargement de la configuration.

En mode `users`, seuls les sous-répertoires correspondant à `inotify_docroot` (par défaut : `public_html,public_ftp`) sont surveillés, ainsi que les répertoires temporaires système `/tmp`, `/var/tmp` et `/dev/shm`.

**Fichiers d’ignorance (inotify) :** Les exclusions de surveillance regroupent deux fichiers — le fichier utilisateur `/usr/local/maldetect/ignore_inotify` et le fichier géré par LMD `/usr/local/maldetect/internals/ignore_inotify.defaults`. Les deux sont séparés par lignes et acceptent les commentaires `#` et les lignes vides. Le fichier utilisateur `ignore_inotify` accepte par défaut les expressions rationnelles étendues POSIX (ERE) — les ancres (`^`, `$`) et les jokers (`.*`, `.+`) fonctionnent. Pour exclure un chemin littéral contenant des métacaractères d’expression rationnelle, préfixez l’entrée avec `literal:` (p. ex. `literal:/tmp/app.cache`). Le fichier `ignore_inotify.defaults` géré par LMD est traité comme des sous-chaînes littérales — ses entrées sélectionnées sont automatiquement échappées au chargement. Le fichier de défauts est écrasé à chaque mise à jour de LMD ; ajoutez les exclusions spécifiques au site uniquement dans `ignore_inotify`.

---

## 8. Système de signatures

Types de signatures, conventions de nommage, mises à jour et fichiers de règles personnalisés.

LMD est fourni avec cinq types de signatures :

| Type | Fichier | Format | Nombre |
|------|------|--------|-------|
| Hachages MD5 | `sigs/md5v2.dat` | `HASH:SIZE:{MD5}sig.name.N` | ~14,801 |
| Hachages SHA-256 | `sigs/sha256v2.dat` | `HASH:SIZE:{SHA256}sig.name.N` | CDN |
| Motifs HEX | `sigs/hex.dat` | `HEXSTRING:{HEX}sig.name.N` | ~2,054 |
| Signatures composées | `sigs/csig.dat` | `SUBSIG1\|\|SUBSIG2:signame` | CDN |
| Règles YARA | `sigs/rfxn.yara` | syntaxe YARA | ~783 règles |
| YARA compilé | `sigs/compiled.yarc` | sortie `yarac` | optionnel |

Des signatures compatibles ClamAV sont également maintenues :
- `sigs/rfxn.hdb` — format MD5 ClamAV
- `sigs/rfxn.ndb` — format HEX ClamAV
- `sigs/rfxn.hsb` — format SHA-256 ClamAV (nécessite ClamAV >= 0.97)

**Convention de nommage des signatures :** `{TYPE}category.name.variant_number`

Les catégories incluent : `bin.` (binaire), `c.` (langage C), `exp.` (exploit), `php.` (PHP), `js.` (JavaScript), `perl.` (Perl), `html.` (hameçonnage), `base64.inject.`, `gzbase64.`

**Préfixes de détection dans les rapports d’analyse :**

| Préfixe | Source |
|--------|--------|
| `{MD5}` | Correspondance de hachage MD5 (étape 1) |
| `{SHA256}` | Correspondance de hachage SHA-256 (étape 1) |
| `{HEX}` | Correspondance de motif HEX (étape 2) |
| `{CSIG}` | Correspondance de signature composée (étape 2.5) |
| `{SA}` | Analyse statistique (longueur de chaîne) |
| `{YARA}` | Analyse YARA native (`scan_yara=1`) |
| `{CAV}` | Moteur ClamAV (clamd/clamscan) |

### 8.1 Mises à jour des signatures

Les signatures sont mises à jour quotidiennement via la tâche cron ou manuellement :```bash
maldet -u            # update signatures
maldet -u --force    # force update even if current

**Nommage des fichiers en quarantaine :** `FILENAME.INODE` (p. ex., `config.php.23754`)

Pour les scans non-root (p. ex., l'analyse d'envoi de fichiers ModSecurity2), les données de quarantaine sont stockées sous `/usr/local/maldetect/pub/USERNAME/quar/`. Utilisez l'option `-U` pour interagir avec la quarantaine non-root :```bash
maldet -U nobody -s 112012-0032.13771

Les téléversements malveillants sont rejetés avec une action de refus et consignés dans le journal d'audit ModSecurity. Aucun argument de mode n'est nécessaire — `hookscan.sh` utilise par défaut le mode ModSecurity pour la rétrocompatibilité. ModSecurity v2 et v3 (libmodsecurity) utilisent tous deux le même contrat `popen()`.

### 10.2 pure-ftpd```bash
# pure-ftpd.conf (or command-line flags):
CallUploadScript yes

# Start the upload-script daemon:
pure-uploadscript -r /usr/local/maldetect/hookscan.sh -B

Les trois champs séparés par des deux-points sont : le modèle de commande, l'expression régulière de déclenchement et l'expression régulière de capture du nom. Lorsqu'un malware est détecté, Exim rejette le message en utilisant le nom de signature capturé.

### 10.5 API générique

Pour les intégrations personnalisées, l'analyse par lots et l'utilisation par des tiers :```bash
# Single file scan
hookscan.sh generic /path/to/file
# Exit: 0 = clean, 1 = error, 2 = infected
# Stdout: CLEAN: /path, INFECTED: signame /path, ERROR: reason

# Batch scan from a file list
hookscan.sh generic --list /tmp/filelist.txt

# Batch scan from stdin
find /uploads -newer /tmp/marker -type f | hookscan.sh generic --stdin

Les alertes de test utilisent le pipeline de rendu réel avec des données synthétiques. La ligne d'objet est préfixée par `[TEST]`. L'isolation des canaux garantit que seul le canal spécifié se déclenche.

### 10.8 Digest des hooks

Les détections de hooks sont résumées via des alertes digest périodiques :```bash
# On-demand digest (reads all sources: monitor + hooks)
maldet --digest

# View hook scan activity
maldet --report hooks                    # last 24 hours
maldet --report hooks --last 7d          # last 7 days
maldet --report hooks --mode modsec      # filter by mode

Voir `man maldet`(1) pour le schéma JSON v1.2 (forme uniforme `{schema_version, scanner, host, reports[]}` pour `-e SCANID` et `-e list`).

### Détection des panneaux d'hébergement

Le cron quotidien détecte automatiquement plus de 12 panneaux de contrôle d'hébergement et ajuste les chemins d'analyse. Voir [6. Cron quotidien](#6-cron-daily) pour la matrice complète des panneaux.

---

## Licence

LMD est développé et supporté à titre bénévole par Ryan MacDonald [[email protected]].

Linux Malware Detect (LMD) est distribué sous la GNU General Public License (GPL) v2
sans restrictions d'utilisation ou de redistribution. La déclaration de copyright et la GNU GPL
sont incluses dans le fichier `COPYING.GPL`. Le crédit doit être accordé aux œuvres dérivées comme
l'exige la GNU GPL.

---

## Support

Le dépôt source de LMD se trouve à l'adresse : https://github.com/rfxn/linux-malware-detect

Les bogues, les demandes de fonctionnalités et les questions générales peuvent être signalés via les issues GitHub ou envoyés à [email protected].

La page officielle du projet se trouve à l'adresse : https://www.rfxn.com/projects/linux-malware-detect/