Auditer l'accès aux fichiers linux. Durcissement Linux. Nous sélectionnons des outils pour un audit de sécurité complet. Paramètres au niveau du système d'exploitation

La plupart des systèmes d'entreprise et multicomposants tels que SÈVE , OracleDB utilisent dans leur plate-forme un système d'exploitation basé sur linux . De ce fait, une attention particulière leur est portée par les auditeurs informatiques. Aujourd'hui, dans l'article, nous présenterons à votre attention plusieurs outils gratuits présentés sous forme de scripts et utilisant des mécanismes de système d'exploitation réguliers pour fournir un audit express de la configuration de sécurité.

Les commandes système et les scripts suivants utilisés pour l'audit express des options de sécurité des systèmes d'exploitation Linux sont basés sur les recommandations pour les contrôles de sécurité publiées par la communauté ISACA dans le manuel UNIX/LINUX Operating System Security Audit/Assurance Program.

1.Vérification des comptes

1.1 Lister tous les utilisateurs
La liste des utilisateurs est stockée dans /etc/passwdfile. Pour obtenir une liste d'utilisateurs, vous pouvez utiliser le script suivant :

  1. bin/bash
  2. # listesd'utilisateursdanslesystème.sh
  3. # compte et répertorie les utilisateurs "réels" existants dans le système.
  4. echo "[*] Utilisateurs existants (triés par ordre alphabétique) :"
  5. grep ‘/bin/bash’ /etc/passwd | grep -v 'racine' | coupe-f1
  6. -d':' | sorte
  7. echo -n "[*] Nombre d'utilisateurs réels trouvés : "
  8. grep ‘/bin/bash’ /etc/passwd | grep -v 'racine' | wc -l
1.2 Liste des comptes bloqués
Lors de l'audit, vous devez vérifier la liste des utilisateurs bloqués et non bloqués ( nom du compte ). La commande suivante fonctionnera pour cela :
  1. #!/bin/bash
  2. # passwd –s nom_compte

1.3 Affichage des statistiques pour tous les utilisateurs

  • L'auditeur doit s'assurer que l'équipe courant alternatif inclus dans le système, pour un aperçu de l'activité de l'utilisateur :
    1. #!/bin/bash
    Pour afficher l'activité de la session de connexion d'un utilisateur avec les totaux pour chaque jour, utilisez la commande :
    1. #!/bin/bash
    2. # ac -d
    Pour afficher des informations sur l'activité de la session (en heures) de la connexion de l'utilisateur "utilisateur" :
    1. #!/bin/bash
    2. # utilisateur ac
    1.4 Afficher l'activité de l'utilisateur
    Les applications système psacct ou acct s'exécutent en arrière-plan et gardent une trace de l'activité de chaque utilisateur sur le système, ainsi que des ressources qu'ils consomment. Pour vérifier l'activité des utilisateurs dans le système, exécutez le script suivant :
    1. #!/usr/bin/envksh
    2. dernier -Fa|awk ‘
    3. /wtmp commence/ ( suivant; )
    4. /toujours connecté/ ( suivant; )
    5. $0 == redémarrer ( suivant; )
    6. FN > 0 (
    7. si(NR > 1)
    8. printf("
      ”);
    9. printf("Utilisateur : t%s
      ”, 1 $); # utilisateur
    10. printf(" Début :t%s %s %s %s
      ”, $3, $4, $5, $6);
    11. si($9 == "vers le bas")
    12. printf(" Fin : arrêt
      ”);
    13. printf(" Fin :t%s %s %s %s
      ”, $9, $10, $11, $12);
    14. if(substr ($NF, 1, 1) == "(")
    15. t = $NF ;
    16. h = "hôte local" ;
    17. t = $(NF-1);
    18. h = $NF ;
    19. gsub("[()]", "", t);
    20. printf("Temps sur : t%s
      ”, t);
    21. printf("Hôte distant : t%s
      ”, h);
  • 2. Vérification de la politique de mot de passe

    2.1 Comptes avec un mot de passe vide
    Au cours de l'audit, vous devez vous assurer qu'il n'y a pas de comptes ou qu'il n'y a pas de comptes bloqués dans le système qui vous permettent de vous connecter au système sans entrer de mot de passe. Cette règle peut être vérifiée avec la commande :

    # chat /etc/ombre | awk -F : ($2=="")(print $1)'

    2.2 Vérification de la complexité du mot de passe
    Lors de l'audit, il est nécessaire de vérifier les paramètres de complexité du mot de passe pour réduire le risque d'attaques par force brute (brute-force) ou par dictionnaire sur le mot de passe. Des modules d'authentification enfichables (PAM) doivent être utilisés pour définir cette stratégie sur le système.
    L'auditeur peut vérifier le paramètre approprié dans le fichier de configuration :

    # vi /etc/pam.d/system-auth

    2.3 Vérification de l'expiration du mot de passe

    Dans le cadre de l'audit, vous devez vérifier le paramètre d'expiration du mot de passe. Pour vérifier le délai d'expiration du mot de passe, utilisez la commande monnaie. Cette commande affiche des informations détaillées sur la date d'expiration du mot de passe, ainsi que la date à laquelle il a été modifié pour la dernière fois.
    La commande suivante est utilisée pour afficher des informations sur "l'âge" des mots de passe :

    #chage -l nom d'utilisateur

    Pour modifier le délai d'expiration du mot de passe pour un utilisateur spécifique, vous pouvez utiliser les commandes ci-dessous :

    #chage -M 60 nom d'utilisateur
    #chage -M 60 -m 7 -W 7 nomutilisateur

    Options (pour définir la date d'expiration du mot de passe) :
    -M - date d'expiration maximale en jours.
    -m est la date d'expiration minimale en jours.
    -W - paramètre d'avertissement en jours.

    2.4 Utilisation de mots de passe répétés
    Les paramètres d'autorisation du système doivent être conformes à la politique de mot de passe. Le fichier contenant l'historique des mots de passe se trouve dans /etc/security/opasswd. Pour vérifier, suivez ces étapes :

    pour RHEL : ouvrez le fichier '/etc/pam.d/system-auth' :

    # vi /etc/pam.d/system-auth

    pour Ubuntu/Debian/Linux Mint : ouvrez le fichier '/etc/pam.d/common-password' :

    # vi /etc/pam.d/common-password

    Ajoutez la ligne suivante à la section "auth" :

    auth suffisante pam_unix.so likeauthnullok

    Pour désactiver l'utilisation des six derniers mots de passe, ajoutez la ligne suivante :

    Mot de passe suffisant pam_unix.so nullokuse_authtok md5 shadow Remember=6

    Après avoir exécuté la commande, le système conservera un historique des six mots de passe précédents, et si un utilisateur essaie de mettre à jour le mot de passe en utilisant l'un des six derniers, il recevra un message d'erreur.

    3. Paramètres de connexion sécurisés
    Les protocoles de connexion à distance Telnet et Rlogin sont très anciens et vulnérables, en raison de la transmission du mot de passe sur le réseau sous une forme non cryptée. Un protocole sécurisé doit être utilisé pour une connexion distante et sécurisée Coquille sécurisée (SSH). L'auditeur doit également s'assurer que l'option connexion racine désactivé, port SSH par défaut modifié, accès à distance autorisé uniquement pour des utilisateurs autorisés spécifiques. Les paramètres à vérifier se trouvent dans le fichier de configuration SSH :

    1. #vi /etc/ssh/sshd_config

    3.1 Connexion en tant que superutilisateur (connexion root)

    Au cours de l'audit, l'auditeur doit vérifier que la connexion à distance avec les droits de superutilisateur root est interdite.

    # PermitRootLogin = oui
    3.2 Vérifier la connexion SSH du compte de service

    Pendant l'audit, l'auditeur doit vérifier le compte de service avec une connexion SSH sans mot de passe. Généralement, les administrateurs système utilisent cette fonctionnalité pour les sauvegardes programmées, les transferts de fichiers et l'exécution de scripts en mode de contrôle à distance.

    Vérifiez vos paramètres sshd_config (/etc/ssh/sshd_config) sont corrects une dernière fois.

    # PermitRootLogin sans mot de passe

    # Authentification RSA = oui

    #PubkeyAuthentication=oui

    3.3 Vérification des listes d'accès dans DenyHosts et Fail2ban
    Lors de l'audit, il est nécessaire de vérifier les paramètres des listes d'accès Refuser les hôtes et Fail2ban . Ce sont des scripts utilisés pour surveiller et analyser les journaux d'accès SSH et se protéger contre les attaques par force brute par mot de passe.

    Fonctionnalités de DenyHost :

    • enregistre et suit les journaux à partir d'un fichier /var/log/sécurisé , marquant toutes les tentatives de connexion réussies et infructueuses, et les filtre.
    • surveille les tentatives de connexion infructueuses
    • envoie une notification par e-mail des hôtes bloqués et des tentatives de connexion suspectes
    Fonctionnalités Fail2ban :
    • Enregistre et suit les journaux à partir de fichiers /var/log/sécurisé et /var/log/auth.log , /var/log/pwdfail
    • hautement personnalisable et multithread
    • surveille régulièrement les fichiers journaux

    4. Vérification des journaux système
    Au cours de l'audit, vous devez vous assurer que le démon SysLog est en cours d'exécution et que tous les événements importants qui se produisent dans le système sont enregistrés dans les journaux des événements. L'audit doit également garantir que la politique de conservation des journaux d'événements tient compte des exigences de la loi et de la politique de sécurité applicables.

    4.1 Journaux d'événements sous Linux :

    /var/log/auth.log – journal du système d'autorisation (logins et mécanisme d'authentification).
    /var/log/dpkg.log - journal d'installation/suppression de packages à l'aide de dpkg.
    /var/log/yum.log - journal d'installation/suppression de packages à l'aide de yum.
    /var/log/faillog - Un journal des tentatives de connexion infructueuses et leur limite pour chaque compte.
    /var/log/kern.log – journal du noyau, (journal détaillé des messages du noyau Linux).
    /var/log/maillog ou /var/log/mail.log – journal du serveur de messagerie.
    /var/log/wtmp – journal de connexion (heure et durée d'enregistrement de tous les utilisateurs du système).
    /var/run/utmp - informations sur les utilisateurs actuellement connectés au système.
    /var/log/lastlog - enregistrements des connexions précédentes.
    /var/log/boot - informations consignées lors du démarrage du système

    5. Protéger les fichiers système

    5.1 Protection du chargeur de démarrage GRUB

    Pour protéger le chargeur de démarrage GRUB, l'administrateur doit utiliser le cryptage du mot de passe dans format MD5 :

    # grub-md5-crypt

    Après avoir exécuté la commande, l'administrateur doit ouvrir le fichier /boot/grub/menu.lst ou alors /boot/grub/grub.conf et ajoutez le mot de passe MD5 :

    # vi /boot/grub/menu.lst

    #vi /boot/grub/grub.conf

    Le mot de passe MD5 nouvellement créé peut être ajouté au fichier de configuration GRUB.

    5.2 Protection du répertoire de démarrage /BOOT

    Lors de l'audit, vous devez vérifier l'état du répertoire /démarrage, puisque le cœur du système et les fichiers associés se trouvent dans le répertoire /démarrage. Vous devez vous assurer que ce répertoire dispose d'un accès en lecture seule, ce qui empêche les modifications non autorisées des fichiers importants du système. Pour vérifier, ouvrez le fichier /etc/fstab et vérifiez la configuration :

    Le fichier doit contenir la ligne :

    LABEL=/boot /boot ext2 par défaut,ro 1 2

    5.3 Vérification des ports ouverts et des connexions actives

    Le script suivant peut être utilisé pour vérifier les services en cours d'exécution sur le système :

    #!/bin/bash
    si (($(ps -ef | grep -v grep | grep $service | wc -l) > 0))
    alors
    echo "$service est en cours d'exécution !!!"
    autre
    /etc/init.d/$service start
    Fi

    Afficher les connexions réseau

    # netstat-anop
    ou alors
    # lsof -i(lsof -ni)
    ou alors
    #iptraf

    Ports d'écoute
    À l'aide de la commande Netstat, vous pouvez afficher tous les ports ouverts et leurs commandes associées. Exemple de scénario :

    # netstat-tulpn
    Un script pour l'analyse des ports est :
    analyse() (
    si [[ -z $1 || -z$2]] ; alors
    echo "Utilisation : $0
    retourner
    Fi
    hôte local=$1
    ports locaux=()
    caisse 2 $ en
    *-*)
    IFS=- lecture début fin<<< “$2”
    pour ((port=début ; port<= end; port++)); do
    port+=($port)
    Fini
    ;;
    *,*)
    IFS=, lire les ports -ra<<< “$2”
    ;; *)
    port+=($2) ;;
    esac
    pour le port dans « $(ports[@]) » ; faire
    alarme 1 "echo >/dev/tcp/$host/$port" &&
    echo "le port $port est ouvert" ||
    echo "le port $port est fermé"
    Fini
    }

    pare-feu iptables

    Lors de l'audit, vous devez vérifier la configuration du pare-feu Linux pour empêcher tout accès non autorisé. Pour contrôler le trafic, des règles doivent être créées dans iptables qui filtreront les paquets entrants, sortants et transférés en fonction de l'adresse IP et du numéro de port TCP/UDP.

    # iptables -n -L -v --numéros de ligne

    Requêtes ICMP/diffusion

    Au cours de l'audit, vous devez vérifier que les systèmes sont configurés pour ignorer les pings et les requêtes de diffusion. Pour ce faire, assurez-vous que le fichier "/etc/sysctl.conf" ajouté les lignes suivantes :

    # ignorer les requêtes ICMP :
    net.ipv4.icmp_echo_ignore_all = 1
    # ignorer les requêtes de diffusion :
    net.ipv4.icmp_echo_ignore_broadcasts = 1

    5.4 Vérification des mises à jour installées

    Les systèmes doivent avoir les dernières mises à jour installées :

    # mises à jour miam
    # yum check-update

    6. Vérification des tâches CRON exécutées automatiquement

    L'auditeur doit vérifier qui est autorisé et interdit d'exécuter des tâches dans cron. L'accès Cron est contrôlé à l'aide de fichiers /etc/cron.allow et /etc/cron.deny.

    # echo ALL >>/etc/cron.deny

    7. Contrôle de sécurité forcé SELINUX

    Lors de l'audit, il est important de vérifier l'état SELinux . Ce mécanisme doit être activé dans le système.
    Il existe trois modes SELinux :

    • Application : la politique SELinux est appliquée. SELinux refuse l'accès en fonction des règles de politique SELinux.
    • Permissive : la politique SELinux n'est pas appliquée. SELinux ne refuse pas l'accès, mais les refus sont consignés comme des actions qui seraient refusées si la politique était configurée pour s'appliquer.
    • Désactivé : SELinux est désactivé. Seules des règles DAC discrètes sont utilisées.

    Lors d'un audit, vous pouvez utiliser le script suivant pour vérifier l'état de SELinux ou utiliser les commandes system-configselinux, getenforce ou sestatus :

    ENABLED=`cat /selinux/enforce`
    si [ "$ ACTIVÉ" == 1 ] ; alors
    echo "SELinux est activé, désactiver ? (Oui Non):"
    lecture désactiver
    si [ $disable == "oui"] ; alors
    echo "désactiver selinux"
    mettre en vigueur 0
    Fi
    Fi

    Script LBSA pour vérifier les options de sécurité de base

    LBSA (script d'audit de sécurité de base Linux) est un script d'audit de configuration de sécurité Linux de base. Le script doit être exécuté à partir d'une ligne de commande avec des privilèges racine, ou idéalement programmé pour s'exécuter régulièrement en utilisant cron pour vérifier systématiquement les changements de configuration.

    Le but de ce script est d'auditer rapidement les paramètres de sécurité et de télécharger un rapport décrivant les paramètres possibles qui peuvent être modifiés pour fournir un degré de sécurité plus élevé. Dans le cas où il n'y a aucune recommandation pour aucune option, le script affiche simplement une ligne avec le traitement de la vérification, et la décision finale appartient toujours à l'administrateur. Avant d'exécuter un test, les développeurs vous recommandent fortement de lire le manuel et d'étudier les sections recommandées pour plus d'informations.

    Dans l'édition actuelle (version 1.0.49), le script recherche les options suivantes :

    • vulnérabilités dans les paramètres de compte
    • vulnérabilités dans les paramètres SSH
    • vulnérabilités dans les répertoires temporaires et les répertoires du système de fichiers chargés en RAM (par exemple, dans /tmp, /var/tmp /dev/)
    • autorisations de fichiers, état des répertoires système
    • -configuration des services DRBD et Hearbeat

    Le script est assez volumineux, nous ne l'avons donc pas mis sur la page.

    Dans cet article, nous allons nous familiariser avec les principaux utilitaires de durcissement de Linux. En russe, cela s'appelle quelque chose comme "vérifier le niveau de sécurité des systèmes Linux et évaluer l'exactitude des configurations en termes de sécurité de l'information". Bien sûr, nous ne passerons pas seulement en revue les programmes, mais nous donnerons également des exemples de leur utilisation.

    Votre propre auditeur ou votre propre sécurité

    Les administrateurs, et plus encore les auditeurs du SI, sont souvent confrontés à la tâche de vérifier la sécurité d'un grand nombre d'hôtes en un temps très court. Et bien sûr, il existe des outils spécialisés dans le segment Enterprise pour résoudre ces problèmes, par exemple, comme les scanners de sécurité réseau. Je suis sûr que tous - des sources ouvertes du moteur OpenVAS aux produits commerciaux comme Nessus ou Nexpose - sont connus de nos lecteurs. Cependant, ce logiciel est généralement utilisé pour rechercher des logiciels obsolètes et donc vulnérables, puis exécuter la gestion des correctifs. De plus, tous les scanners ne prennent pas en compte certaines fonctionnalités spécifiques des mécanismes de sécurité intégrés de Linux et d'autres produits open source. Et enfin, le prix de l'émission compte, car seules les entreprises qui allouent des budgets à cette activité sont en mesure de s'offrir des produits commerciaux.

    C'est pourquoi nous parlerons aujourd'hui d'un ensemble spécialisé d'utilitaires librement distribués qui peuvent diagnostiquer le niveau actuel de sécurité du système, évaluer les risques potentiels, par exemple, des "services supplémentaires" sur Internet, ou une configuration par défaut non sécurisée, et même suggérer des options pour corriger les lacunes constatées. Un autre avantage de l'utilisation de ces outils est la possibilité de répliquer des scripts de test de ferme typiques à partir de n'importe quel nombre de systèmes Linux et de former une base documentée de tests sous la forme de journaux et de rapports séparés.

    Aspects pratiques de l'audit de sécurité

    Si vous regardez à travers les yeux de l'auditeur, l'approche des tests peut être divisée en deux types.

    Première- c'est le respect des exigences dites de conformité, ici la présence d'éléments de sécurité obligatoires prescrits dans toute norme internationale ou "best practice" est vérifiée. Un exemple classique est les exigences PCI DSS pour les systèmes informatiques de paiement, SOX404, série NIST-800, .

    Seconde- il s'agit d'une approche purement rationnelle basée sur la question "Que peut-on faire d'autre pour renforcer la sécurité ?". Il n'y a pas d'exigences obligatoires - seulement vos connaissances, votre tête brillante et vos mains habiles. Par exemple, il s'agit de mettre à jour la version du noyau et/ou des packages d'applications, d'activer, de forcer, de mettre en place un pare-feu.

    Tout ce qui concerne la deuxième approche est généralement appelé un terme spécial. durcissement, qui peuvent aussi être définies comme « des actions visant à renforcer le niveau de sécurité initial du système d'exploitation (ou du programme) principalement par des moyens réguliers ».

    Le respect des exigences de conformité est généralement vérifié en vue de réussir un audit obligatoire tel que PCI DSS ou un autre audit de certification. Nous accorderons plus d'attention au composant Durcissement. Tous les principaux développeurs proposent pour leurs produits Directives de durcissement- des guides contenant des conseils et des recommandations sur la façon d'améliorer la sécurité, en tenant compte des mécanismes de sécurité habituels et des spécificités du logiciel. Ainsi, Red Hat, Debian, Oracle, Cisco ont des manuels similaires.

    INFO

    Le durcissement est un terme du monde de la sécurité de l'information, qui fait référence au processus visant à assurer la sécurité d'un système (programme) en réduisant sa vulnérabilité et, en règle générale, en utilisant uniquement des utilitaires ou des mécanismes de protection standard.

    sudo apt-get mettre à jour sudo apt-get installer lynis

    Et pour les distributions orientées RPM (après avoir ajouté les dépôts appropriés) :

    Miam installer linus -y

    Installation sur macOS :

    $ brew rechercher lynis $ brew installer lynis

    Pour lancer Lynis, il suffit de spécifier au moins une clé. Par exemple, pour exécuter tous les tests disponibles, vous devez spécifier le commutateur -c (vérifier tout, vérifier tout) :

    # Suite de test typique du système d'audit sudo lynis # Suite de test complète du système d'audit sudo lynis -c # Analyser un système d'audit d'hôte distant à distance







    C'est toujours une bonne idée de vérifier si une nouvelle version de Lynis est disponible avant un audit :

    Informations sur la mise à jour de Lynis et vérification de la mise à jour de Lynis

    L'utilitaire Lynis, en plus de l'utilitaire standard, a un mode supplémentaire - course non privilégiée:

    Audit Lynis --pentest

    Si vous voulez mettre le nom de l'auditeur qui a commencé le test, ajoutez simplement le paramètre -auditor :

    Système d'audit Sudo Lynis -c -auditor Papa

    À n'importe quelle étape de l'audit, le processus de vérification peut être poursuivi (Entrée) ou interrompu de force (Ctrl+C). Les résultats des tests effectués seront écrits dans le journal Lynis dans /var/log/lynis.log . Veuillez noter que le journal sera écrasé à chaque lancement de l'utilitaire.

    Pour effectuer des tests systématiques en mode automatique, vous pouvez affecter la tâche appropriée au planificateur Cron à l'aide du commutateur -cronjob. Dans ce cas, l'utilitaire s'exécutera selon le modèle (config) spécifié et n'affichera aucun message interactif, question ou avertissement. Tous les résultats seront enregistrés dans le journal. Par exemple, voici un script de lancement d'utilitaire avec une configuration par défaut une fois par mois :

    #!/bin/sh AUDITOR="automated" DATE=$(date +%Y%m%d) HOST=$(nom d'hôte) LOG_DIR="/var/log/lynis" REPORT="$LOG_DIR/report-$( HOST).$(DATE)" DATA="$LOG_DIR/report-data-$(HOST).$(DATE).txt" cd /usr/local/lynis ./lynis -c –auditor "$(AUDITOR)" --cronjob > $(REPORT) mv /var/log/lynis-report.dat $(DATA) # Fin

    Enregistrez ce script dans le répertoire /etc/cron.monthly/lynis. Et n'oubliez pas d'ajouter des chemins pour enregistrer les journaux (/usr/local/lynis et /var/log/lynis), sinon cela risque de ne pas fonctionner correctement.

    Vous pouvez voir une liste de toutes les commandes disponibles pour appeler :

    Commandes d'affichage de Lynis

    Les particulièrement curieux peuvent regarder les paramètres de la config par défaut :

    Lynis afficher les paramètres

    Brève instruction sur l'utilisation de l'utilitaire :

    homme lynis

    Les options pour les statuts possibles en fonction des résultats de la vérification sont limitées à la liste suivante : AUCUN, FAIBLE, TERMINÉ, TROUVÉ, NOT_FOUND, OK, AVERTISSEMENT.


    Exécution de tests individuels dans Lynis

    En pratique, il peut être nécessaire de n'effectuer que quelques essais. Par exemple, si votre serveur exécute uniquement les fonctions de Mail Server ou d'Apache. Nous pouvons utiliser l'option -tests pour cela. La syntaxe de la commande est la suivante :

    Lynis -tests "Test-IDs"

    Si vous avez du mal à comprendre en raison du grand nombre d'ID de test, vous pouvez utiliser le paramètre de groupe -test-category . Avec cette option, Lynis n'exécute que les ID de test qui appartiennent à une catégorie spécifique. Par exemple, nous prévoyons d'exécuter des tests de pare-feu et de noyau :

    ./lynis -tests-category "noyau de pare-feu"

    De plus, la fonctionnalité de Lynis est étendue par divers plugins que vous pouvez ajouter vous-même, ou vous pouvez en mettre de nouveaux dans un répertoire existant.

    Suggestions de corrections

    Tous les avertissements seront répertoriés après les résultats. Chacun commence par le texte d'avertissement, puis le test qui l'a généré est indiqué entre parenthèses à côté. La ligne suivante suggère une solution au problème, s'il en existe une. En fait, la dernière ligne est une URL où vous pouvez voir les détails et trouver des recommandations supplémentaires sur la façon de résoudre le problème.

    Profils

    Les profils qui gèrent l'audit sont définis dans des fichiers avec l'extension .prf situé dans le répertoire /etc/lynis. Le profil par défaut est nommé de manière prévisible : default.prf . Les développeurs ne recommandent pas de le modifier directement : il est préférable d'ajouter les modifications que vous souhaitez apporter à l'audit dans le fichier custom.prf situé dans le même répertoire.

    Suite disponible uniquement pour les membres

    Option 1. Rejoignez la communauté "site" pour lire tous les documents sur le site

    L'adhésion à la communauté pendant la période spécifiée vous donnera accès à TOUS les matériaux Hacker, augmentera votre remise cumulée personnelle et vous permettra d'accumuler une note professionnelle Xakep Score !

    La question de la sécurité de l'infrastructure informatique est d'une grande pertinence pour tout type d'entreprise. Qu'il s'agisse d'un groupe d'entreprises avec un vaste réseau de succursales ou d'une boutique en ligne avec 1 à 2 vendeurs.
    Pour chaque serveur dont la vocation principale est d'héberger des sites, se pose un enjeu aigu d'assurer la protection des données des utilisateurs.
    Notre société propose un service d'audit de la sécurité des serveurs.

    Cette prestation comprend :

    — Analyse des versions logicielles installées sur le serveur pour conformité avec les versions réelles actuelles, dépourvues de problèmes de sécurité connus. En règle générale, la pertinence des versions des logiciels suivants est importante pour les serveurs Web : serveur de messagerie, serveur Web, serveur Web de mise en cache (le cas échéant), interpréteur de langage de programmation (dans lequel les sites Web sont écrits, par exemple, PHP), ftp serveur, applications Web (pour fournir un accès simplifié à certains paramètres du serveur et travailler avec des données) ;
    — Analyse des paramètres du serveur Web, paramètres logiciels associés pour la conformité aux exigences de sécurité de base ;
    — Analyse des paramètres du système d'exploitation. Cet article analyse les principaux points liés à la possibilité pour un attaquant de prendre le contrôle du serveur. En règle générale, les paramètres du serveur ssh, les options de travail avec les disques durs sont examinés;
    — Analyse des droits d'accès aux principaux fichiers et dossiers du système contenant des informations confidentielles. En règle générale, dans le cadre de cet article, il y a une inspection des principaux dossiers système, des fichiers du panneau de configuration du serveur, des répertoires avec des sauvegardes, des droits sur les dossiers des utilisateurs ;
    – Sur un serveur soupçonné d'avoir été compromis et pouvant être utilisé par des attaquants pour mener des actions malveillantes, nos spécialistes prendront les mesures nécessaires pour le nettoyer des logiciels malveillants et empêcher que cette situation ne se reproduise ;

    La sécurité de l'information est une question prioritaire pour toute entreprise en ligne. Les infections virales et les attaques externes, ainsi que l'accès non autorisé à l'information, comportent tous des risques financiers et de réputation majeurs. Par conséquent, lors du choix d'une plate-forme de serveur, les propriétaires d'entreprise sont toujours intéressés par le degré de sécurité des ressources.
    Et afin de vérifier le bon fonctionnement du système de protection, s'il contient des vulnérabilités et des «trous», il est recommandé d'effectuer un audit de sécurité du serveur au moins une fois par mois.

    Ce qui est inclus dans un audit de sécurité de serveur

    Même un facteur apparemment insignifiant, tel que des paramètres incorrects du serveur lui-même ou un logiciel obsolète, peut devenir une menace pour la sécurité. L'audit permet d'identifier les faiblesses de sécurité et de prendre des mesures en temps opportun pour y remédier avant que les données ne soient compromises ou volées.
    L'administrateur du serveur vérifie le logiciel installé, sa conformité aux dernières mises à jour, évalue les paramètres de sécurité du serveur et élimine les erreurs, le cas échéant, et analyse également la conformité des paramètres des droits d'accès des employés à certaines ressources.

    Comment auditer un serveur privé virtuel de vos propres mains

    Chaque utilisateur peut vérifier la sécurité des serveurs sur les plateformes Windows ou Linux, pour cela il n'est pas nécessaire d'avoir des connaissances particulières en programmation.
    Le contrôle de sécurité peut être divisé en plusieurs étapes :

    Accès physique

    Dans le cas d'un serveur dédié, l'accès physique au serveur des tiers est limité par défaut, celui-ci est assuré par le centre de données. Mais l'utilisateur peut également définir un mot de passe pour accéder au BIOS.

    Pare-feu

    Pour une surveillance continue des logiciels et des ports, le pare-feu Windows doit être correctement configuré et activé. Pour Linux, vous pouvez utiliser le système SELinux pour le contrôle d'accès. Vous pouvez également louer chez nous un pare-feu matériel Cisco ASA ou Fortinet FortiGate 60D.

    Système de fichiers

    vérification des mises à jour

    Configurez le serveur pour qu'il reçoive et installe automatiquement les mises à jour.

    Politique de mot de passe

    Utilisez les stratégies de sécurité Windows locales pour appliquer l'exigence de mots de passe complexes, leur date d'expiration et le verrouillage du compte après plusieurs échecs de connexion ou un mot de passe vide.

    Contrôle du journal

    Activez la journalisation pour les segments d'infrastructure critiques et vérifiez-les régulièrement.

    Sécurité Internet

    VPN et VLAN sont recommandés pour la segmentation de l'hôte et la sécurité des liens.
    Vous devez également modifier les paramètres par défaut et transférer les ports des services de l'équipement réseau.
    Vous pouvez utiliser le service IPsec pour chiffrer le trafic. Et pour afficher les ports ouverts - l'utilitaire Netstat.

    Contrôle d'accès

    Différenciez les droits d'accès des utilisateurs aux fichiers critiques, désactivez l'accès invité et les utilisateurs avec un mot de passe vide. Désactivez les rôles et applications inutilisés sur le serveur.

    Sauvegarde

    Utilisez le service de sauvegarde de fichiers, il est rentable et fiable. Ne stockez pas les sauvegardes non chiffrées. Si vous louez un serveur chez nous, vous pouvez choisir un emplacement pour les sauvegardes.

    Accès à la base de données

    Les bases de données critiques doivent être stockées sur différents serveurs SQL. Vous devez configurer le lancement au nom d'un utilisateur avec des privilèges minimaux ou à partir d'une liste blanche préconfigurée d'adresses IP.

    Protection antivirus

    Pour le fonctionnement du serveur sous Windows, l'installation d'un logiciel antivirus mis à jour automatiquement est recommandée lorsque les utilisateurs travaillent avec des stockages réseau. Pour Linux, l'installation d'un antivirus n'est pas nécessaire, sous réserve d'une surveillance régulière de la sécurité du serveur et d'un contrôle des accès non autorisés. L'utilitaire Tiger peut être utile pour cela.

    Un tel audit une fois par mois permettra de vérifier le bon fonctionnement du serveur, d'éliminer les vulnérabilités et de contrôler la sécurité de l'infrastructure réseau.

    Effectuez un audit de sécurité du serveur une fois par mois pour détecter en temps opportun d'éventuels problèmes liés à la pénétration d'intrus dans le serveur.

    Si vous ne voyez aucun signe d'activité de tiers sur le VPS ou le site, effectuez la série suivante de vérifications et d'ajustements pour protéger le serveur contre le piratage.

    Paramètres de la couche d'application

    Si CMS est installé sur le serveur, vérifiez si toutes les dernières mises à jour sont installées.

    Joomla

    Recherchez le fichier changelog.txt dans le répertoire racine du site, où vous trouverez des informations sur la version du CMS. S'il est obsolète, mettez à jour Joomla.

    WordPress

    Recherchez le fichier wp-includes/version.php pour les informations de version du CMS. S'il est obsolète, mettez à jour Wordpress.

    DLE

    Recherchez le fichier engine/data/config.php, recherchez la ligne version_id et assurez-vous que la version est à jour.

    Vérifiez également les fichiers engine/ajax/updates.php et upgrade/index.php (paramètre $dle_version).

    1C-Bitrix

    Recherchez le fichier /bitrix/modules/main/classes/general/version.php, où vous trouverez des informations sur la version du CMS. Vérifiez également le fichier /bitrix/admin/update_system.php. Si la version est obsolète, mettez à jour 1C-Bitrix.

    Drupal

    Recherchez le fichier changelog.txt dans le répertoire racine du site, où vous trouverez des informations sur la version du CMS. S'il est obsolète, mettez à jour Drupal.

    Vérifiez la version du noyau dans le fichier /modules/system/system.info.

    En outre, vous pouvez détecter la version du CMS via le panneau de configuration.

    Vérifier serveur Web.

    apache

    Ouvrez le fichier de configuration Apache (selon la version, il peut s'agir de fichiers httpd.conf, httpd2.conf, apache.conf, apache2.conf) et vérifiez s'il contient une directive qui désactive la sortie d'informations sur la version du Web serveur:

    ServerTokensProd

    Si cette directive n'est pas présente, ajoutez et enregistrez le fichier.

    Recherchez le fichier secure.conf, ouvrez-le pour l'afficher et vérifiez son contenu par rapport à l'exemple suivant :

    Options +Includes -FollowSymLinks +SymLinksIfOwnerMatch AllowOverride FileInfo AuthConfig Limit Indexes Options Order allow,deny Allow from all php_admin_value open_basedir "." Options-Index Action php-cgi /php-bin/php

    Votre secure.conf ne doit pas être significativement différent de l'exemple ci-dessus.

    Vérifiez le MPM installé avec la commande

    Apachectl -V

    Pour une sécurité renforcée, utilisez mpm_itk sauf si vous avez absolument besoin de mpm_prefork.

    Si vous souhaitez modifier MPM, effectuez une réinstallation après avoir effectué des copies de sauvegarde des fichiers de configuration. Après la réinstallation, vérifiez si le propriétaire du site et de tous ses répertoires est bien l'utilisateur.

    Nginx

    Ouvrez le fichier de configuration du serveur Web (nginx.conf), allez dans la section http et vérifiez s'il contient des directives qui limitent le nombre de connexions à partir d'une adresse IP :

    Limit_zone slimits $binary_remote_addr 5m ; limit_conn slimits 10 ; ou (pour les versions récentes) limit_conn_zone $binary_remote_addr zone=addr:10m; limit_conn addr 10 ;

    Si ces directives ne sont pas présentes, ajoutez et enregistrez le fichier.

    Bloquez certains agents utilisateurs pour bloquer le trafic indésirable. Dans la section http du fichier de configuration Nginx, ajoutez la directive

    Si ($http_user_agent ~* LWP::Simple|BBBike|wget|msnbot) (retourne 403 ;)

    Bloquez le spam de référence en ajoutant la directive à la section http du fichier de configuration Nginx

    Si($http_referer ~*(babes|forsale|girl|jewelry|love|nudit|organic|poker|porn|sex|teen))(return 403;)

    ISPmanager

    Effectuez les vérifications suivantes dans le panneau de configuration ISPmanager.

    Vérifiez si l'accès au panneau de commande est limité par l'adresse IP.

    Configurez la sauvegarde des données si elle n'est pas activée. Nous vous recommandons d'utiliser un lecteur externe pour la sauvegarde afin d'éviter la perte de données avec l'archive.

    PHP

    Ouvrez le fichier de configuration php.ini et ajoutez les directives suivantes.

    Expose_php=Off - désactive la transmission des informations de version de PHP dans l'en-tête HTTP ; sql.safe_mode=On - active le mode sans échec SQL ; post_max_size=8M - taille limite pour les données transmises par la méthode POST ; disable_functions exec, system, passthru, proc_open, shell_exec - désactive certaines fonctions pour des raisons de sécurité.

    NTP

    Dans le fichier de configuration NTP (/etc/ntp.conf par défaut), ajoutez des lignes pour désactiver les requêtes récursives :

    Restreindre default kod limited nomodify notrap nopeer noquery restrict -6 default kod limited nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6::1

    Lier

    Placez les lignes suivantes dans le fichier named.conf pour désactiver les requêtes récursives :

    Autoriser la récursivité( 127.0.0.1; 82.146.32.0/19; 78.24.216.0/21; 92.63.96.0/20; 62.109.0.0/19; 188.120.224.0/19; 149.154.64.0/21; 37.230.119.11 248.0/21 ); );

    Vérification du propriétaire du répertoire de sites

    Vérifiez à qui appartient le répertoire principal du site et tous ses sous-répertoires.

    Dans la barre d'outils d'ISPmanager, allez dans la section "Système" -> "Gestionnaire de fichiers" et ouvrez le répertoire du site. Assurez-vous que les colonnes "Propriétaire" et "Groupe" correspondent à l'utilisateur propriétaire du site. Pour modifier ces attributs, cliquez sur le bouton Attributs de la barre d'outils.

    Les noms de propriétaire de site Web valides sont apache, www, www-data si vous utilisez mpm_prefork. Nous vous recommandons d'utiliser mpm_itk pour améliorer la sécurité.

    Si le site contient des dossiers partagés (par exemple, upload, tmp), alors le nom de propriétaire 777 est valide pour eux. Assurez-vous que cet utilisateur est défini uniquement sur les répertoires nécessaires en exécutant la commande

    Trouver ./ -perm 0777

    Il trouvera tous les dossiers et fichiers appartenant au 777.

    Paramètres au niveau du système d'exploitation

    chasseur

    Utilisez l'utilitaire rkhunter pour identifier les vulnérabilités potentielles du serveur.

    Pour installer l'utilitaire, utilisez la commande :

    Yum install rkhunter - CentOS OS apt-get install rkhunter - Debian/Ubuntu OS make all install clean -C /usr/ports/security/rkhunter or pkg install rkhunter - FreeBSD OS

    Pour mettre à jour la base de données de cet utilitaire, exécutez les commandes

    Rkhunter --mise à jour

    Rkhunter --propupd

    Exécutez une vérification du système avec la commande

    Rkhunter -c --cs2

    Pendant le processus de vérification, vous devez appuyer plusieurs fois sur la touche Entrée pour continuer. Une fois terminé, un résumé du résultat du test apparaîtra.

    Les résultats de la vérification sont placés dans le fichier journal /var/log/rkhunter/rkhunter.log, consultez-le pour les avertissements et les erreurs.

    sysctl

    Utilisez l'utilitaire sysctl pour gérer les paramètres du noyau du système. Ouvrez le fichier de configuration de l'utilitaire /etc/sysctl.conf et entrez les lignes suivantes.

    Désactivez la possibilité d'acheminer le trafic entrant, car un attaquant peut utiliser cette capacité pour usurper les adresses IP :

    net.ipv4.conf.all.accept_source_route = 0

    Désactivez les réponses aux requêtes ICMP sur le canal de diffusion - cela aidera à prévenir les attaques smurf :

    Net.ipv4.icmp_echo_ignore_broadcasts = 1

    Désactivez la journalisation des messages d'erreur non valides :

    Net.ipv4.icmp_ignore_bogus_error_responses = 1

    Activer la protection contre le débordement de mémoire :

    Kernel.exec-shield=1 (CentOS)

    Activer l'utilisation de la mémoire ASLR :

    kernel.randomize_va_space = 2

    Désactivez la possibilité de transférer les messages ICMP :

    net.ipv4.conf.all.accept_redirects=0 net.ipv4.conf.default.accept_redirects=0

    Si vous n'utilisez pas de VPN ou d'autres applications spéciales sur le serveur, désactivez le transfert :

    Net.ipv4.conf.all.forwarding=0

    Activer la protection contre les inondations SYN - utilisation des cookies SYN :

    Net.ipv4.tcp_syncookies=1

    Définissez le nombre de tentatives d'envoi de paquets SYN-ACK :

    Net.ipv4.tcp_synack_retries = 3

    Définissez le délai après lequel le serveur vérifie la connexion si elle n'a pas été utilisée pendant une longue période (la valeur par défaut est de 2 heures) :

    Net.ipv4.tcp_keepalive_time=1800

    Définissez le nombre de vérifications de connexion avant qu'il ne soit terminé :

    Net.ipv4.tcp_keepalive_probes=3

    Définissez le délai d'expiration du socket dans l'état FIN-WAIT-2 :

    net.ipv4.tcp_fin_timeout=30

    fstab

    Vérifiez le fichier de configuration fstab (/etc/fstab), qui contient des informations sur les disques, les partitions et les périphériques de stockage, et comment ils sont montés sur le système.

    Vi /etc/fstab

    Notez que les partitions non root doivent avoir l'option nodev. Si /tmp est monté sur une partition séparée, ajoutez nodev, noexec, nosuid pour cette partition.

    rsyslog

    Vérifiez le fichier journal système /etc/rsyslog.conf.

    Vi /etc/rsyslog.conf

    Faites attention aux lignes suivantes, qui devraient ressembler à :

    Assurez-vous également que le fichier journal n'est pas vide, c'est-à-dire la journalisation est correcte.

    sudo

    Vérifiez si l'utilitaire sudo (ou su) est correctement configuré, ce qui permet à l'utilisateur d'exécuter certaines commandes et programmes en tant que root. Les paramètres de cet utilitaire se trouvent dans le fichier de configuration /etc/sudoers ou /usr/local/etc/sudoers. Ouvrez-le pour l'éditer

    Vi /etc/sudoers

    Recherchez la ligne qui est écrite par défaut et qui permet au superutilisateur root d'exécuter n'importe quelle commande.

    Pour donner à tous les utilisateurs le privilège d'exécuter des commandes en tant qu'utilisateur root, ajoutez la ligne suivante :

    TOUS TOUS=/bin/su ou TOUS TOUS=/usr/bin/su

    Pour donner à un utilisateur spécifique le privilège d'exécuter uniquement certaines commandes en tant que root, ajoutez la ligne :

    %users ALL=/sbin/mount - le groupe d'utilisateurs ne pourra utiliser sudo qu'avec la commande mount user ALL=/sbin/mount - l'utilisateur user ne pourra utiliser sudo qu'avec la commande mount

    Paramètres au niveau du réseau

    Vérifiez quels ports sont ouverts sur le serveur et quels services les utilisent en exécutant la commande

    Netstat-tuplnw | awk "(imprimer $4,$NF)" | trier | unique

    Par exemple, l'entrée 127.0.0.1:53 748/named signifie que le service nommé utilise le port 53. Vérifiez que seuls les services nécessaires figurent parmi les services en cours d'exécution, désactivez tous les autres.

    FTP

    Définissez la plage de ports à utiliser pour le mode FTP passif. Pour cela, ouvrez le fichier de configuration de votre serveur FTP pour édition et ajoutez les lignes :

    pour vsftpd.conf :

    pasv_min_port=1028 pasv_max_port=1048

    pour proftpd.conf :

    Ports passifs 1028 1048

    N'utilisez pas le protocole FTP sauf en cas d'absolue nécessité, utilisez plutôt SFTP. Si FTP est toujours requis, ajoutez les lignes suivantes au fichier de configuration :

    pour vsftpd.conf :

    Xferlog_enable=OUI (journalisation ftp) anonyme_enable=NON (refuser les connexions utilisateur anonymes) anon_upload_enable=NON anon_mkdir_write_enable=NON

    pour proftpd.conf :

    dans la section ... supprimer toutes les rubriques et ajouter des lignes

    Nier tous Nier tous

    iptables

    Vérifiez si le pare-feu est configuré correctement. Pour iptables, exécutez la commande

    Iptables-nL

    Cette commande imprime toutes les règles de pare-feu iptables sur la ligne de commande. De plus, ces règles peuvent être visualisées et modifiées dans le fichier de configuration du pare-feu /etc/sysconfig/iptables - pour CentOS OS, /etc/network/if-up.d/ispmgrfw - pour Debian/Ubuntu OS.

    Dans les règles de pare-feu, fermez tous les ports sauf ceux utilisés par les services exécutés sur le serveur. Pour ce faire, changez les lignes

    :ENTRÉE ACCEPTÉE :AVANCEMENT ACCEPTÉ :SORTIE ACCEPTÉE à :ENTRÉE BAISSE :AVANT BAISSE :SORTIE BAISSE

    Pour ouvrir les ports nécessaires, ajoutez des lignes comme

    A ENTRÉE -p tcp -m tcp --dport 53 -j ACCEPTER -A ENTRÉE -p udp -m udp --dport 53 -j ACCEPTER -A ENTRÉE -p tcp -m multiport --sports 53,80,25,443,953 -j J'ACCEPTE

    où 53 est le numéro de port à ouvrir.

    Avant d'apporter des modifications au fichier de configuration du pare-feu, faites une copie du fichier de travail.

    Les règles de pare-feu peuvent être configurées à partir du panneau de configuration ISPmanager.

    SSH

    Ouvrez le fichier de configuration SSH :

    Vi /etc/ssh/sshd_config

    Vérifiez que les lignes suivantes ne sont pas commentées :

    Protocol 2 (pour utiliser la deuxième version du protocole) IgnoreRhosts oui (ne pas utiliser le fichier .rhost) HostbasedAuthentication non (ne pas authentifier l'hôte) PermitRootLogin non (refuser l'accès root) PermitEmptyPasswords non (ne pas utiliser de mots de passe vides) PermitUserEnvironment non (interdire à l'utilisateur de définir des variables d'environnement) PasswordAuthentication oui (autoriser l'authentification par mot de passe)

    Activez SFTP en ajoutant la ligne suivante à sshd_config :

    Sous-système sftp /usr/lib/openssh/sftp-server

    Vérifiez la file d'attente de courrier pour le débordement et assurez-vous qu'il n'y a pas de messages de spam parmi les messages.

    Exécutez la commande mailq et affichez la liste des messages. Si la liste est très longue, recherchez sélectivement les messages susceptibles d'être du spam. Par identifiant (par exemple, BD65F10DEE4) déterminer l'expéditeur de la lettre. Équipe

    Exim -Mvh message_id

    affiche l'entête de l'email, et la commande

    Exim -Mvb message_id

    affichera le corps du message.

    Parmi les en-têtes de message, le champ From: contient l'expéditeur et X-PHP-Originating-Script contient le script auquel le message a été envoyé.

    Logiciel

    Vérifiez le logiciel serveur pour les vulnérabilités.

    Système d'exploitation CentOS

    Exécutez une commande qui répertorie les fichiers logiciels installés récemment modifiés :

    Rpm -qVa - pour afficher tous les fichiers, rpm -qVa | awk "$2!="c" (print $0)" - pour imprimer les fichiers à l'exception des journaux.

    Analysez quels fichiers ont été modifiés et comment, en utilisant les valeurs de paramètres suivantes :

    S - taille du fichier modifiée M - autorisations par défaut modifiées 5 - somme de contrôle MD5 modifiée D - numéros majeurs/mineurs pour l'appareil modifiés L - lien symbolique modifié U - propriétaire du fichier modifié G - groupe modifié T - date de modification du fichier (mtime) modifiée ) c - fichier de configuration d - fichier de documentation g - fichier non inclus dans le package l - fichier de licence r - fichier README

    Par exemple, la ligne S.5....T. c /etc/httpd/conf/httpd.conf signifie que httpd.conf est un fichier de configuration, sa taille, sa somme de contrôle et sa date de dernière modification ont été modifiés. Comme il s'agit d'un fichier de configuration, ces modifications ne sont pas suspectes.

    Faites attention aux fichiers dont les valeurs de somme de contrôle ont été modifiées sans raison apparente. Pour ces fichiers, exécutez la commande :

    Stat /usr/sbin/sshd && fichier /usr/sbin/sshd où usr/sbin/sshd est le chemin d'accès au fichier.

    À la suite de la commande, des informations détaillées sur la modification de ce fichier sont affichées à l'écran.

    Exécutez la commande :

    Miam --mise à jour de sécurité

    pour installer la mise à jour de sécurité.

    Système d'exploitation Debian

    Exécutez les commandes qui vérifient les sommes de contrôle MD5 pour les programmes installés :

    # apt-get install debsums # debsums -c

    Exécutez les commandes suivantes pour vérifier la mise à jour de sécurité :

    # echo 'deb http://security.debian.org wheezy/updates main contrib non-free' >> /etc/apt/sources.list # grep security /etc/apt/sources.list > /etc/apt/secsrc .list # apt-get -s -o Dir::Etc::sourcelist="secsrc.list" -o Dir::Etc::sourceparts="-"

    Pour installer security-update, exécutez la commande :

    # apt-get -o Dir::Etc::sourcelist="secsrc.list" -o Dir::Etc::sourceparts="-"

    Vérifiez que tous les dépôts disposent d'une réconciliation gpg en exécutant les commandes :

    # grep -ri gpgcheck /etc/yum.conf # grep -ri gpgcheck /etc/yum.repos.d/ Assurez-vous que les lignes ressemblent à : gpgcheck=1 # grep -ri AllowUnauthenticated /etc/apt/

    Lignes du formulaire

    APT::Get::AllowUnauthenticated "true" ;

    ne devrait pas être.

    Services non utilisés

    Système d'exploitation CentOS

    chkconfig --list

    Chkconfig --del nom_service où nom_service est le nom du service.

    Système d'exploitation Debian

    Exécutez une commande qui répertorie les services inutilisés :

    sysv-rc-conf

    Pour désactiver le démarrage d'un service inutilisé, exécutez la commande :

    Sysv-rc-conf off service_name où service_name est le nom du service.

    Vous avez aimé l'article ? A partager entre amis :