Au niveau sécurité, deux contôles valent souvent mieux qu’un seul.
C’est pourquoi, après avoir installé chkrootkit pour la détection des rootkits, je vais également installer RootKit Hunter.

Je fais cette installation sous Ubuntu server Gutsy 7.10, mais les explications données ici devraient fonctionner ou être très facilement adaptable pour toute distribution Linux.
Rkhunter fonctionne autrement. Il calcule une check somme MD5 de vos programmes et fichiers de configuration.
Il faut donc l’avoir installer assez tôt après l’installation du serveur pour être certain que le code MD5 soit basé sur un serveur “clean”. En cas de doute, vous réexécutez Rkhunter qui signalera les fichiers et programmes ayant été modifiés.
Rkhunter demande l’installation d’un serveur de mails, Exim4, pour pouvoir envoyer les alertes par mail.
sudo aptitude install rkhunter Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Lecture de l'information d'état étendu Initialisation de l'état des paquets... Fait Construction de la base de données des étiquettes... Fait Les NOUVEAUX paquets suivants vont être automatiquement installés : exim4 exim4-base exim4-config exim4-daemon-light libdb4.3 liblockfile1 libmd5-perl mailx Les NOUVEAUX paquets suivants vont être installés : exim4 exim4-base exim4-config exim4-daemon-light libdb4.3 liblockfile1 libmd5-perl mailx rkhunter 0 paquets mis à jour, 9 nouvellement installés, 0 à enlever et 0 non mis à jour. Il est nécessaire de télécharger 2470ko d'archives. Après dépaquetage, 5792ko seront utilisés. Voulez-vous continuer ? [Y/n/?] ... Sélection du paquet mailx précédemment désélectionné. Dépaquetage de mailx (à partir de .../mailx_1%3a8.1.2-0.20070424cvs-1_i386.deb) ... Sélection du paquet rkhunter précédemment désélectionné. Dépaquetage de rkhunter (à partir de .../rkhunter_1.3.0-1_all.deb) ... Paramétrage de libdb4.3 (4.3.29-8ubuntu2) ... Paramétrage de exim4-config (4.67-5build1) ... Adding system-user for exim (v4) Paramétrage de exim4-base (4.67-5build1) ... Paramétrage de exim4-daemon-light (4.67-5build1) ... * Starting MTA [ OK ] Paramétrage de exim4 (4.67-5build1) ... Paramétrage de liblockfile1 (1.06.2) ... Paramétrage de libmd5-perl (2.03-1) ... Paramétrage de mailx (1:8.1.2-0.20070424cvs-1) ... Paramétrage de rkhunter (1.3.0-1) ... Updating the file properties database: [ Rootkit Hunter version 1.3.0 ] File created: searched for 150 files, found 122 ...
Un des paramètres modifiables pour rkhunter est l’envoie d’un mail en cas de problème détecté :
sudo vi /etc/rkhunter.conf
Ajouter une ligne “MAIL-ON-WARNING” :
# Email a message to this address when a warning is found. # Multiple addresses may be specified simply be separating them # with a space. # #MAIL-ON-WARNING=me@mydomain root@mydomain MAIL-ON-WARNING=webmaster@mondomaine.be didier@gmail.com
Vous pouvez spécifier plusieurs adresses mails séparées par un espace.
(le logo Exim est de Jenniger Greenley)
ATTENTION : Exim4, bien qu’installé automatiquement lors de l’installation de Rkhunter, n’est probablement pas configuré automatiquement.
Je n’ai en fait pas besoin d’un serveur de mails complet, avec des boites locales, sur ce serveur.
Ce dont j’ai besoin, c’est que les mails de warning générés par chkrootkit ou par rkhunter, soient envoyés à une adresse mail sur Internet (Gmail ou un mail chez un fournisseur Internet par exemple).
Pour cela, il faut au minimum configurer le nom du SMTP serveur de mon fournisseur ADSL.
Reconfigurons Exim4 :
sudo dpkg-reconfigure exim4-config
J’ai 4 configurations possible.
Celle qui me convient est “Envoi via relais (« smarthost ») - pas de courrier local“.
En effet, je ne veux pas de boites locales, juste du courrier sortant vers le SmartHost (le relais SMTP) de mon fournisseur Internet.
Exim4 me demande avec quoi vais-je compléter une adresse mail qui ne possède pas de domaine ?
J’introduis mon “nomdedomaine.be“, ainsi un mail envoyer par un programme tournant sous “root” enverra un mail depuis l’adresse “root@mondomaine.be”
Je laisse 127.0.0.1 comme adresse d’écoute : aucun mail entrant ne doit être accepté.
Je n’ajoute rien à la question suivante : aucun domaine ne doit avoir ses mails arrivant sur ce serveur.
Finalement, la question que j’attendais : le nom ou adresse IP du système “smarthost”.
C’est le serveur SMTP de mon fournisseur EDPnet : relay.edpnet.be
Les autres réponses sont assez simples. Vous pouvez laisser les options par défaut (quoi que personnellement je préfère les fichiers de configuration séparés et pas monolithique)
Remarque : rkhunter DOIT être mis à jour régulièrement.
Pour cela, il a besoin d’un outil du genre “wget” ou “lynx” pour accéder au Web en ligne de commande.
Wget est déjà installé dans Ubuntu-server.
Cette page de Nicolas Martinez explique bien ce sujet.
Vérifiez régulièrement si vous disposez de la dernière version :
sudo rkhunter --versioncheck [ Rootkit Hunter version 1.3.0 ] Checking rkhunter version... This version : 1.3.0 Latest version: 1.3.0
Ok, mon Rootkit Hunter est bien à la dernière version.
Faite la mise à jour des détections :
sudo rkhunter --update [ Rootkit Hunter version 1.3.0 ] Checking rkhunter data files... Checking file mirrors.dat [ No update ] Checking file programs_bad.dat [ No update ] Checking file backdoorports.dat [ No update ] Checking file suspscan.dat [ No update ] Checking file i18n/cn [ No update ] Checking file i18n/en [ Updated ]
Pour vérifier si votre système est sain :
sudo rkhunter --check [ Rootkit Hunter version 1.3.0 ] Checking system commands... Performing 'strings' command checks Checking 'strings' command [ OK ] Performing 'shared libraries' checks Checking for preloading variables [ None found ] Checking for preload file [ Not found ] Checking LD_LIBRARY_PATH variable [ Not found ] Performing file properties checks Checking for prerequisites [ OK ] /bin/bash [ OK ] /bin/cat [ OK ] /bin/chmod [ OK ] /bin/chown [ OK ] /bin/cp [ OK ] /bin/date [ OK ] ... [Pressto continue] Checking for rootkits... Performing check of known rootkit files and directories 55808 Trojan - Variant A [ Not found ] ADM Worm [ Not found ] AjaKit Rootkit [ Not found ] aPa Kit [ Not found ] Apache Worm [ Not found ] ... Performing Linux specific checks Checking kernel module commands [ OK ] Checking kernel module names [ OK ] [Press to continue] Checking the network... Performing check for backdoor ports Checking for UDP port 2001 [ Not found ] Checking for TCP port 2006 [ Not found ] Checking for TCP port 2128 [ Not found ] Checking for TCP port 14856 [ Not found ] Checking for TCP port 47107 [ Not found ] Checking for TCP port 60922 [ Not found ] Performing checks on the network interfaces Checking for promiscuous interfaces [ None found ] [Press to continue] Checking the local host... Performing system boot checks Checking for local host name [ Found ] Checking for local startup files [ Found ] Checking local startup files for malware [ None found ] Checking system startup files for malware [ None found ] Performing group and account checks Checking for passwd file [ Found ] Checking for root equivalent (UID 0) accounts [ None found ] Checking for passwordless accounts [ None found ] Checking for passwd file changes [ None found ] Checking for group file changes [ None found ] Checking root account shell history files [ None found ] Performing system configuration file checks Checking for SSH configuration file [ Found ] Checking if SSH root access is allowed [ Warning ] Checking if SSH protocol v1 is allowed [ Not allowed ] Checking for running syslog daemon [ Found ] Checking for syslog configuration file [ Found ] Checking if syslog remote logging is allowed [ Not allowed ] Performing filesystem checks Checking /dev for suspicious file types [ None found ] Checking for hidden files and directories [ Warning ] ...
Rkhunter a donc détecté un problème dans la configuration du serveur OpenSSH.
En effet, le logon root est autorisé.
Je ne suis pas sur que ce soit un risque en Ubuntu, puisque par défaut le userid “root” n’est pas utilisable.
Malgré tout, je vais éditer le fichier SSH et modifier cette ligne :
sudo vi /etc/ssh/sshd_config ... # Authentication: LoginGraceTime 120 PermitRootLogin no StrictModes yes
Après avoir modifié une option dans la configuration, il faut redémarrer le serveur SSH :
sudo /etc/init.d/ssh restart * Restarting OpenBSD Secure Shell server sshd
Rkhunter m’a également signalé un problème sur les fichiers et dossiers cachés.
Je vais vérifier dans le log :
sudo less /var/log/rkhunter.log ... [00:28:04] Info: Emailing warnings to 'webmaster@mondomaine.be didier@gmail.com' using command '/usr/bin/mail -s "[rkhunter] Warnings fou nd for ${HOST_NAME}"' ... [00:32:25] Checking for hidden files and directories [ Warning ] [00:32:25] Warning: Hidden directory found: /dev/.static [00:32:25] Warning: Hidden directory found: /dev/.udev [00:32:25] Warning: Hidden directory found: /dev/.initramfs [00:32:25] Warning: Hidden file found: /dev/.tmp-2-0: block special (2/0)
D’abord, on remarque que l’envoie de mails est bien prévu
J’ai lu des messages dans des forums disant que certains de ces warnings étaient normaux.
Je le pense ici : les fichiers cachés (commençant par un point) dans le /dev me semble normaux.
Je devrais malgré tout m’en assurer.
Donc, exepté ce warning qui semble être un faux positif, tout est normal sur ce serveur.
Mais cela pose malgré tout un problème !
Rkhunter a détecté un problème, et même si c’est un faux positif (pas de risque), il m’envoie un mail.
Je reçois dans ma boite le mail suivant :
Sujet : [rkhunter] Warnings found for server3 De : root@mondomaine.be Pour : didier@gmail.com ... Please inspect this machine, because it may be infected.
A coup sûr, ce mail ne va pas m’aider du tout s’il arrive dans ma boite tous les jours alors qu’il n’y a pas de problème !
Evidemment, je n’y ferai pas attention quand un réel problème sera détecté…
Je dois trouver une solution pour ne pas avoir ces faux positifs sur ces 4 dossiers commençant par “/dev.”
L’explication sur les faux positifs se trouve sur le site de RKhunter.
Si on est CERTAIN que ces fichiers et dossiers sont normaux, on peut les ajouter dans la “whitelist” de rkhunter.
En cherchant sur le net, on trouve que le fichier “/dev/.tmp-2-0” semble être créé lors du boot d’Ubuntu Gutsy 7.10.
Un bug est ouvert à ce sujet dans le Lauchpad.
Donc, si ce fichier n’est pas vraiment normal, il s’agit d’un bug sans conséquence et pas d’un rootkit.
Pour éviter que RootKit Hunter ne détecte ce fichier et les 3 dossiers, puisque nous sommes certains qu’ils sont normaux, il faut les ajouter dans la whitelist de la configuration de rkhunter. En fait, les 3 dossiers sont déjà dans le fichier de configuration, mais en commentaire. Il suffit de supprimer le “#” en début de ligne, et d’ajouter un ligne “ALLOWHIDDENFILE” pour le fichier “/dev/.tmp-2-0″ :
sudo vi /etc/rkhunter.conf
# # Allow the specified hidden directories. # One directory per line (use multiple ALLOWHIDDENDIR lines). # #ALLOWHIDDENDIR=/etc/.java ALLOWHIDDENDIR=/dev/.udev #ALLOWHIDDENDIR=/dev/.udevdb #ALLOWHIDDENDIR=/dev/.udev.tdb ALLOWHIDDENDIR=/dev/.static ALLOWHIDDENDIR=/dev/.initramfs #ALLOWHIDDENDIR=/dev/.SRC-unix # # Allow the specified hidden files. # One file per line (use multiple ALLOWHIDDENFILE lines). # ALLOWHIDDENFILE=/dev/.tmp-2-0 #ALLOWHIDDENFILE=/etc/.java #ALLOWHIDDENFILE=/usr/share/man/man1/..1.gz #ALLOWHIDDENFILE=/etc/.pwd.lock #ALLOWHIDDENFILE=/etc/.init.state
Il reste à rendre la mise à jour, programme et détection, et le scanning automatique toutes les nuits, et à envoyer un mail avec le résultat.
Le plus simple est de le faire exécuter par la tâche Crontab.
Dans la “Crontab” du système, il est prévu d’exécuter automatiquement certaines tâches toutes les heures, tous les jours, toutes les semaines ou tous les mois.
Cela correspond aux besoins les plus courants, et c’est facilité car il existe un dossier propre à chacun de ces 4 groupes de tâches.
Si je vérifie la Crontab qu’Ubuntu server a installé, je vois :
cat /etc/crontab
SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # m h dom mon dow user command 17 * * * * root cd / && run-parts --report /etc/cron.hourly 25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ) 47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly ) 52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly ) #
On voit que les scripts se trouvant dans “/etc/cron.daily” seront exécuter tous les jours à 6h25.
Cela me convient parfaitement !
Le script suivant fait ces 4 opérations :
#!/bin/sh ( /usr/local/bin/rkhunter -versioncheck /usr/local/bin/rkhunter -update /usr/local/bin/rkhunter -cronjob --report-warnings-only ) | /bin/mail -s ‘Scan rkhunter server3’ webmaster@mondomain.be
MAIS… je vois qu’il existe déjà un script pour rkhunter (et aussi pour chkrootkit) dans le cron.daily :
ls -l /etc/cron.daily/ total 64 -rwxr-xr-x 1 root root 633 2007-10-05 00:54 apache2 -rwxr-xr-x 1 root root 5811 2007-10-15 22:40 apt -rwxr-xr-x 1 root root 314 2007-09-15 11:25 aptitude -rwxr-xr-x 1 root root 502 2007-05-15 11:47 bsdmainutils -rwxr-xr-x 1 root root 577 2007-04-27 19:48 chkrootkit -rwxr-xr-x 1 root root 4197 2007-10-04 22:52 exim4-base -rwxr-xr-x 1 root root 473 2007-10-03 20:36 find -rwxr-xr-x 1 root root 89 2006-06-19 20:21 logrotate -rwxr-xr-x 1 root root 946 2007-05-23 08:52 man-db -rwxr-xr-x 1 root root 1154 2007-10-04 22:59 ntp -rwxr-xr-x 1 root root 671 2007-10-02 21:58 rkhunter -rwxr-xr-x 1 root root 383 2007-10-04 08:39 samba -rwxr-xr-x 1 root root 3283 2006-12-20 15:46 standard -rwxr-xr-x 1 root root 1309 2007-09-17 22:54 sysklogd
Que contient ce fichier /etc/cron.daily/rkhunter ?
#!/bin/sh RKHUNTER=/usr/bin/rkhunter if [ ! -x $RKHUNTER ]; then exit 1 fi if [ ! $NICE ]; then NICE=0 fi # source our config . /etc/default/rkhunter case "$CRON_DAILY_RUN" in [Yy]*) OUTFILE=`mktemp` || exit 1 /usr/bin/nice -n $NICE $RKHUNTER --cronjob --report-warnings-only \ --createlogfile /var/log/rkhunter.log $RK_OPT > $OUTFILE if [ $(stat -c %s $OUTFILE) -ne 0 ]; then ( echo "Subject: [rkhunter] Daily run" echo "" cat $OUTFILE ) | /usr/sbin/sendmail $REPORT_EMAIL fi rm -f $OUTFILE ;; *) exit 0 ;; esac
C’est bien un script pour exécuter RKhunter et envoyer le résultat par mail si le fichier $OUTFILE n’est pas de longueur nule. Je vais utiliser ce script.
Comme je désire recevoir un mail si un problème est détecté et que j’ai plusieurs serveurs, je rajoute le nom du serveur dans le script, dans le sujet du mail :
echo "Subject: [rkhunter] Daily run : Server3"
Mais ce script ne fait pas les mises à jour…
Il utilise le fichier de paramètre /etc/default/rkhunter.
On y voit des choses intéressantes :
less /etc/default/rkhunter # Defaults for rkhunter cron jobs # sourced by /etc/cron.*/rkhunter # # This is a POSIX shell fragment # # Set this to the email address where reports and run output should be sent REPORT_EMAIL="root" # Set this to yes to enable rkhunter weekly database updates CRON_DB_UPDATE="yes" # Set this to yes to enable reports of weekly database updates DB_UPDATE_EMAIL="no" # Set this to yes to enable rkhunter daily runs CRON_DAILY_RUN="yes" # Nicenesses range from -20 (most favorable scheduling) to 19 (least favorable). NICE="0" # Extra options to pass to rkhunter daily cron job # see `man rkhunter' for available options RK_OPT=""
Une variable CRON_DAILY_RUN est à “YES”, et elle fait exactement ce qu’elle “dit”…
Dans le script /etc/cron.daily/rkhunter, qui tourne tous les jours, cette variable permet oui ou non d’exécuter rkhunter journellement.
Sur ce point, nous n’avons donc rien à faire !
RootKit Hunter tourne automatiquement toutes les nuits.
La variable CRON_DB_UPDATE semble indiquer que les mises à jour tournent toutes les semaines.
Effectivement !
On trouve aussi dans Crontab un script qui tourne toutes les semaines :
less /etc/cron.weekly/rkhunter #!/bin/sh RKHUNTER=/usr/bin/rkhunter if [ ! -x $RKHUNTER ]; then exit 0 fi # source our config . /etc/default/rkhunter case "$CRON_DB_UPDATE" in [Yy]*) [ -x /usr/bin/wget ] || exit 1 OUTFILE=`mktemp` || exit 1 case "$DB_UPDATE_EMAIL" in [Yy]*) ( echo "Subject: [rkhunter] Weekly database update : Server3 " echo "" $RKHUNTER --versioncheck --nocolors $RKHUNTER --update --nocolors ) | /usr/sbin/sendmail $REPORT_EMAIL ;; *) $RKHUNTER --versioncheck 1>/dev/null 2>$OUTFILE $RKHUNTER --update 1>/dev/null 2>$OUTFILE ;; esac if [ $(stat -c %s $OUTFILE) -ne 0 ]; then ( echo "Subject: [rkhunter] Weekly database update" echo "" cat $OUTFILE ) | /usr/sbin/sendmail $REPORT_EMAIL fi rm -f $OUTFILE ;; *) exit 0 ;; esac
On remarque que le script de mise à jour vérifie que WGET est bien installé et exécutable. Vous devez donc avoir wget sur votre serveur. (c’est le cas après l’installation d’Ubuntu serveur 7.10)
Donc ok, la mise à jour devrait se faire une fois par semaine.
Je trouve par contre intéressant de recevoir un mail confirmant cette mise à jour (au moins au début pour voir si tout va bien).
Comme j’ai plusieurs serveurs, j’ai modifié le script précédant pour ajouter le nom du serveur dans le titre du mail.
Ensuite je modifie la variable dans le fichier de paramètres par défaut, et également l’adresse mail de destination :
sudo vi /etc/default/rkhunter ... # Set this to the email address where reports and run output should be sent REPORT_EMAIL="webmaster@mondomaine.be didier@gmail.com" # Set this to yes to enable rkhunter weekly database updates CRON_DB_UPDATE="yes" # Set this to yes to enable reports of weekly database updates DB_UPDATE_EMAIL="yes" # Set this to yes to enable rkhunter daily runs CRON_DAILY_RUN="yes"
Voilà, tout devrait être correct.
Je laisse volontairement un fichier caché détecté, en commentaire dans la White list, pour vérifier si j’ai bien un mail ce matin à 6h25…
De la même façon, je verrai lors de l’exécution automatique toutes les dimanches (je pense… le 7ème jour… mais je croyais les jours numérotés de 0 à 6 ?) à 6h47, si je reçois bien un mail de confirmation.
Vérification des mises à jour :
Simplement, je peux forcer l’exécution du script de mise à jour de RKhunter :
sudo /etc/cron.weekly/rkhunter
et je reçois bien un mail confirmant la mise à jour :
Sujet : [rkhunter] Weekly database update : Server3 [ Rootkit Hunter version 1.3.0 ] Checking rkhunter version... This version : 1.3.0 Latest version: 1.3.0 [ Rootkit Hunter version 1.3.0 ] Checking rkhunter data files... Checking file mirrors.dat [ No update ] Checking file programs_bad.dat [ No update ] Checking file backdoorports.dat [ No update ] Checking file suspscan.dat [ No update ] Checking file i18n/cn [ No update ] Checking file i18n/en [ No update ]
Ca me semble correct. Je verrai si le script tourne automatiquement cette semaine.
De la même façon, je peux faire tourner manuellement le contrôle journalier pour vérifier si tout est ok :
sudo /etc/cron.daily/rkhunter
Après environ 4 min 30 d’exécution sur ce Pentium III à 866 MHz, le job se termine et je reçois… DEUX mails.
Le premier :
[rkhunter] Daily run : Server3 Warning: Hidden file found: /dev/.tmp-2-0: block special (2/0) One or more warnings have been found while checking the system. Please check the log file (/var/log/rkhunter.log)
J’avais en effet laissé un élément pour forcer la détection.
Le deuxième mail :
[rkhunter] Warnings found for Server3 Please inspect this machine, because it may be infected.
Ce 2ème mail n’est pas informatif, et il est inutile.
Il arrive tous les jours même s’il n’y a rien à détecter, alors que le 1er mail n’arrivera que s’il y a un élément à vérifier.
Je peux donc le supprimer. Un seul suffit !
Ce mail provient d’un paramètre que j’avais modifié au début dans le fichier de paramètre de RootKit Hunter :
sudo vi /etc/rkhunter.conf # # Email a message to this address when a warning is found. # Multiple addresses may be specified simply be separating them # with a space. # #MAIL-ON-WARNING=me@mydomain root@mydomain MAIL-ON-WARNING=webmaster@mondomaine.be didier@gmail.com
Il me suffit de supprimer cette ligne “MAIL-ON-WARNING” que j’avais ajoutée.
Je réessaye.
Ok, je ne reçois plus qu’un seul mail “[rkhunter] Daily run : Server3″
Et s’il n’y a pas d’erreur détectée ?
Je remets le dernier fichier, qui était un faux positif, dans la Whitelist :
sudo vi /etc/rkhunter.conf # # Allow the specified hidden files. # One file per line (use multiple ALLOWHIDDENFILE lines). # ALLOWHIDDENFILE=/dev/.tmp-2-0
et je relance le script…
le script se termine, et PAS de mail.
C’est ce que je voulais : un mail seulement si un problème est détecté.
Mais… on peut aussi dire que sans mail, on n’est pas certain que RKhunter tourne…
Exact, mais je préfère ça plutôt qu’un mail tous les jours au quel on fini par ne plus faire attention et qu’on n’ouvre pas, ou rarement…
De plus, si vraiment votre serveur est hacké, si l’attaquant est assez malin pour désactiver le passage de RKhunter, en théorie il serait aussi assez malin pour … générer à sa place un mail “tout va bien” comme tous les jours, même si RKhuter ne tournait plus !
Ici on essaye de se protéger contre la majorité des attaques (de les détecter), celles qui sont automatiques et qui profitent de failles connues et pas corrigées, ou très récentes, ou contre les attaques de pseudo hackeurs qui utilisent des rootkits tout fait, trouvés sur le net, mais qui n’ont pas toujours les compétences pour bricoler le serveur au point d’effacer totalement leurs traces…
La sécurité à 100% n’existe pas.
Dés qu’un serveur est sur le Net, il peut être attaqué, il peut y avoir des failles non connues ou que vous n’avez pas le temps de corriger dans l’heure où elles sont révélées…
Le seul serveur sûr à 100%, c’est celui qui n’est pas connecté au Net… seul problème : alors il ne “sert” plus à rien !
Précision :
J’installe maintenant RKhunter sur un serveur Debian.
L’installation sous Debian me pose 2 questions.
Ces questions sont CLAIRES.
Je ne pense pas que je les avais eu lors de l’installation en Ubuntu.
Possible… on fait parfois des choses, tard le soir… la nuit même… et la documentation un peu après et on oublie certaines choses.
Voici ces 2 questions, au quelles il est préférable de répondre “OUI”
Vous l’avez compris : en répondant simplement à ces 2 questions, on est assuré d’avoir l’exécution automatique de RootKit Hunter toutes les nuits, et les mises à jour toutes les semaines.






