Le livre "Kali Linux des développeurs"

image Salut, habrozhiteli! Les auteurs vous présenteront étape par étape les bases et les capacités de Kali Linux. Le livre propose un court cours sur l'utilisation de la ligne de commande Linux et ses concepts, décrit des scénarios d'installation typiques pour Kali Linux. Après avoir lu ce livre, vous apprendrez comment configurer, déboguer et protéger Kali Linux, ainsi que travailler avec le puissant gestionnaire de paquets du paquet de distribution Debian. Apprenez à installer correctement Kali Linux dans n'importe quel environnement, y compris les grands réseaux d'entreprise. Enfin, vous devez vous familiariser avec des sujets complexes: compilation du noyau, création de vos propres images ISO, cryptage industriel et protection professionnelle des informations confidentielles.


Chapitre 7. Protection et contrôle de Kali Linux


Dès que vous commencez à utiliser Kali Linux pour des tâches plus confidentielles et de haut niveau, vous devrez très probablement prendre la sécurité de votre installation plus au sérieux. Dans ce chapitre, nous discutons d'abord de la politique de sécurité, en soulignant les points les plus importants pour la déterminer, et prêtons attention à certaines menaces pour votre système et pour vous en tant que professionnel de la sécurité. Nous discuterons également des mesures de sécurité pour les ordinateurs portables et les ordinateurs de bureau et envisagerons séparément les pare-feu et le filtrage des paquets. En conclusion, nous aborderons les outils et stratégies de surveillance et montrerons les moyens les plus efficaces de les utiliser pour détecter les menaces potentielles pour votre système.

7.1. Définition de la politique de sécurité


Il n'est pas approprié de discuter de la sécurité en termes généraux, car ce concept représente un large éventail de concepts, d'outils et de procédures qui ne sont pas universels. Le choix parmi eux nécessite une représentation précise de vos objectifs. La protection du système commence par des réponses à plusieurs questions. La mise en œuvre rapide et imprudente d'un ensemble arbitraire d'utilitaires entraîne le risque de définir par erreur des aspects de sécurité.

Il est préférable d'identifier initialement un objectif spécifique. L'approche correcte pour résoudre ce problème sera les réponses aux questions suivantes.

1. Qu'essayez-vous de protéger? La politique de sécurité variera en fonction de ce que vous souhaitez protéger: ordinateurs ou données. Dans ce dernier cas, vous devez également savoir quelles informations doivent être protégées.

2. De quoi essayez-vous de vous protéger? De la fuite de données confidentielles? De la perte accidentelle d'informations? D'une perte causée par une défaillance dans la prestation de services?

3. De qui essayez-vous de vous protéger? Les mesures de sécurité seront complètement différentes pour la protection contre les fautes de frappe d'un simple utilisateur du système et la protection contre un groupe spécifique d'intrus.

Le terme «risque» est généralement utilisé pour définir de manière générique ces facteurs: ce qui doit être protégé, ce qui doit être évité et à cause de qui cela peut se produire. La modélisation des risques nécessite des réponses aux trois questions. Sur la base du modèle résultant, vous pouvez développer une politique de sécurité et l'implémenter à l'aide d'actions spécifiques.

Bruce Schneier, un expert mondial en sécurité (pas seulement en informatique), essaie de contrer l'un des principaux mythes de la sécurité en agissant sous la devise: «La sécurité est un processus, pas un produit». Les actifs qui doivent être protégés évoluent avec le temps, tout comme les menaces et les moyens dont disposent les attaquants potentiels. Même si la politique de sécurité était initialement conçue et mise en œuvre de manière idéale, vous ne devriez jamais vous arrêter là. Les composantes du risque évoluent et les méthodes de prévention devraient être développées en conséquence.

En outre, des contraintes supplémentaires susceptibles de limiter l'éventail des politiques disponibles doivent être prises en compte. Qu'êtes-vous prêt à faire pour protéger le système? Cette question revêt une grande importance pour le choix de la politique. Très souvent, la réponse n'est déterminée que du point de vue des coûts décaissés, mais d'autres éléments doivent être pris en compte, tels que les éventuels inconvénients que subiront les utilisateurs du système, ou la dégradation de ses performances.

Une fois le risque modélisé, vous pouvez penser à développer une politique de sécurité adaptée.

Il y a des extrêmes qui doivent être pris en compte pour décider du niveau de sécurité nécessaire. D'une part, il est extrêmement simple d'assurer la sécurité de base du système.

Par exemple, si un système défini pour la protection comprend uniquement un ordinateur utilisé, qui n'est utilisé que pour ajouter quelques chiffres à la fin de la journée, il serait raisonnable de ne rien faire de spécial pour le protéger. La valeur réelle d'un tel système est faible et la valeur des données est complètement nulle, car elles ne sont pas stockées sur l'ordinateur. Un attaquant potentiel qui pénètre dans ce système ne recevra qu'une calculatrice. Le coût de la protection d'un tel système est probablement supérieur au coût du piratage.

La situation inverse sera le cas de la protection de la confidentialité des données confidentielles de la manière la plus complète en surmontant les éventuelles restrictions. Dans ce cas, la destruction complète des informations (effacement sûr des fichiers, déchiquetage des disques durs en petits morceaux, puis dissolution de ces morceaux dans de l'acide, etc.) est une solution appropriée. S'il existe une exigence supplémentaire selon laquelle les données doivent être stockées pour une utilisation future (pas nécessairement en disponibilité constante) et que le coût n'est toujours pas dissuasif, la meilleure idée serait de stocker les données sur les plaques d'alliage d'iridium et de platine dans des abris anti-bombes sous les montagnes environnantes. le monde, dont chacun (bien sûr) est classé et protégé par une armée.

Bien que ces méthodes puissent sembler exagérées, elles peuvent néanmoins être des solutions adaptées à certains risques, car elles vous permettent d'atteindre vos objectifs avec des restrictions données. Sur la base d'une décision éclairée, aucune politique de sécurité n'est plus ou moins suffisante que les autres.

Pour revenir à un cas plus typique, un système d'information peut être segmenté en sous-systèmes compatibles et principalement indépendants. Chacun d'eux a ses propres exigences et limites, par conséquent, l'évaluation des risques et le développement d'une politique de sécurité doivent être effectués séparément pour chacun de ces sous-systèmes. Vous devez toujours vous rappeler qu'une petite surface d'attaque est plus facile à protéger qu'une grande surface. Les organisations de réseau doivent être conçues de cette manière: les services vulnérables doivent être concentrés sur un petit nombre d'ordinateurs et ces derniers doivent être accessibles par un nombre minimum de routes ou de points de contrôle. La logique est simple: il est plus facile de protéger les points d'arrêt que tous les ordinateurs vulnérables du monde extérieur entier. C'est à ce stade que les avantages du filtrage du réseau (y compris les pare-feu) deviennent apparents. Ce filtrage peut être implémenté à l'aide d'équipements spéciaux, mais une solution plus simple et plus flexible consiste à utiliser un pare-feu logiciel similaire à celui intégré au noyau Linux.

7.2. Mesures de sécurité possibles


Comme mentionné ci-dessus, il n'y a pas de réponse unique à la question de savoir comment protéger Kali Linux. Tout dépend de la façon dont vous l'utilisez et de ce que vous essayez de protéger exactement.

Sur le serveur

Si vous utilisez Kali Linux sur un serveur public, vous devez protéger les services réseau en modifiant tous les mots de passe par défaut qui peuvent être configurés, et probablement en restreignant l'accès à ceux-ci à l'aide d'un pare-feu (sections 7.3 «Sécurisation des services réseau» et 7.4 «Pare-feu ou filtrage de paquets », voir ci-dessous).

Si vous transférez des informations de compte d'utilisateur directement sur le serveur ou sur l'un des services réseau, assurez-vous de définir des mots de passe forts (ils doivent résister aux attaques par force brute). Dans le même temps, vous pouvez configurer le programme fail2ban, qui complique considérablement la fissuration des mots de passe par une recherche exhaustive sur le réseau (en filtrant les adresses IP qui dépassent la limite des tentatives de connexion infructueuses). Vous pouvez installer fail2ban à l'aide de la commande apt update, puis installer apt fail2ban.

Si vous utilisez des services Web, configurez-les pour qu'ils fonctionnent via le protocole HTTPS afin que les intermédiaires du réseau ne surveillent pas votre trafic (ce qui peut inclure l'authentification des cookies).

Sur un ordinateur portable

L'ordinateur portable d'un spécialiste des tests de pénétration ne présente pas les mêmes risques qu'un serveur ouvert: par exemple, vous êtes moins susceptible aux attaques accidentelles d'un pirate amateur, et si cela se produit, vous n'aurez probablement pas de services réseau actifs à ce stade.

Le vrai risque survient souvent lorsque vous voyagez d'un client à un autre. Par exemple, votre ordinateur portable peut être volé lors d'un voyage ou saisi par les douanes. C'est pourquoi il vaut la peine d'utiliser le chiffrement complet du disque (voir la section «Installation sur un système de fichiers entièrement chiffré» de la section 4.2) et éventuellement de configurer la fonction nuke (voir l'encadré «Définition d'un mot de passe d'auto-destruction pour plus de sécurité» au chapitre 9): données qui Les informations recueillies lors de votre travail sont confidentielles et nécessitent une protection maximale.

Vous pouvez également avoir besoin de règles de pare-feu (voir la section 7.4 ci-dessous), mais pas dans le même but que sur le serveur. Vous voudrez probablement bloquer tout le trafic sortant, à l'exception du trafic généré par votre accès VPN. Ces paramètres sont similaires aux paramètres de sécurité du réseau, donc lorsque le VPN cesse de fonctionner, vous le remarquerez immédiatement (au lieu de revenir à l'accès au réseau local). Ainsi, vous ne donnez pas les adresses IP de vos clients lors de la navigation sur le Web ou d'autres activités réseau. De plus, si vous effectuez une interaction interne locale, il est préférable de surveiller en permanence vos activités afin de réduire le bruit créé dans le réseau, ce qui peut attirer l'attention des clients et de leurs systèmes de protection.

7.3. Protection des services réseau


Il est recommandé de désactiver les services que vous n'utilisez pas. Kali simplifie cette tâche, car la plupart des services réseau sont déjà désactivés par défaut.
Tant que les services restent désactivés, ils ne présentent pas de risque pour la sécurité. Cependant, vous devez être prudent lorsque vous les activez en raison des facteurs suivants.

1. Par défaut, ils n'ont pas de pare-feu, donc s'ils écoutent sur toutes les interfaces réseau, ils sont largement accessibles au public.

2. Certains services n'ont pas d'informations d'identification et vous permettent de les définir lors de la première utilisation; d'autres ont des informations d'identification standard (et donc largement connues). Assurez-vous d'avoir (re) défini un mot de passe qui n'est connu que de vous.

3. De nombreux services sont émis avec des privilèges root (avec des droits d'administrateur complets), de sorte que les conséquences d'un accès non autorisé ou de violations de sécurité sont généralement graves.

Nous ne répertorierons pas ici tous les outils fournis avec les informations d'identification par défaut. Au lieu de cela, vous devriez vérifier le fichier README.Debian pour les packages respectifs, ainsi que les pages docs.kali.org et tools.kali.org pour savoir si le service a besoin d'une maintenance spéciale pour assurer la sécurité nécessaire.

Si vous démarrez en temps réel, le mot de passe root est toor. Par conséquent, vous ne devez pas activer SSH avant de modifier le mot de passe du compte root ou avant de configurer l'interdiction de connexion par mot de passe dans la configuration du compte.

Notez également le fait bien connu que le projet BeEF (du package beef-xss déjà installé) a les informations d'identification par défaut: le nom d'utilisateur et le mot de passe de boeuf, qui sont définis «de force» dans le fichier de configuration.

7.4. Pare-feu ou filtrage de paquets


Un pare-feu est un équipement informatique avec matériel, logiciel ou les deux qui analyse les paquets réseau entrants ou sortants (entrants ou sortants du réseau local) et ne transmet que ceux qui remplissent certaines conditions prédéfinies.

Une passerelle réseau de filtrage est un type de pare-feu qui protège l'ensemble du réseau. En règle générale, il est installé sur un ordinateur dédié configuré en tant que passerelle vers le réseau de manière à pouvoir analyser tous les paquets entrant et sortant du réseau. Il existe également un pare-feu local, qui est un service logiciel exécuté sur un ordinateur spécifique, pour filtrer ou restreindre l'accès à un certain nombre de services sur cet ordinateur ou, éventuellement, pour empêcher les connexions sortantes de logiciels espions que l'utilisateur pourrait installer par accident ou intentionnellement.

Le noyau Linux possède un pare-feu netfilter intégré. Il n'y a pas de solution unique pour configurer un pare-feu, car les exigences du réseau et de l'utilisateur sont différentes. Cependant, vous pouvez contrôler netfilter depuis l'espace utilisateur à l'aide des commandes iptables et ip6tables. La différence entre ces derniers est que le premier fonctionne pour les réseaux IPv4, tandis que le dernier fonctionne sur IPv6. Étant donné que les deux piles de protocoles réseau sont susceptibles de fonctionner pendant de nombreuses années, les deux outils doivent être utilisés en parallèle. Vous pouvez également utiliser l'excellent utilitaire fwbuilder basé sur une interface graphique, qui fournit une représentation graphique des règles de filtrage.

Cependant, si vous décidez de configurer netfilter (l'implémentation du pare-feu Linux), nous examinerons de plus près comment cela fonctionne.

Comportement du protecteur de surtension Netfilter

Le filtre Netfilter utilise quatre tables différentes qui stockent les règles régissant les trois types d'opérations sur les packages:

1. filtre fait référence aux règles de filtrage (accepter, rejeter ou ignorer un paquet);

2. nat (Network Address Translation) fait référence à la traduction des adresses source ou de destination et des ports de paquets;

3. mangle fait référence à d'autres changements dans les paquets IP (y compris le champ ToS (Type de service) et les options);

4. raw permet d'autres modifications manuelles des packages avant qu'ils (les packages) n'atteignent le système de suivi des connexions.

Chaque table contient des listes de règles appelées chaînes. Le pare-feu utilise des chaînes standard pour traiter les paquets en fonction de conditions prédéfinies. L'administrateur peut créer d'autres chaînes qui seront utilisées uniquement lors du transfert d'une des chaînes standard (directement ou indirectement).

La table des filtres contient trois chaînes standard:

1. ENTRÉE - fait référence aux paquets dont le but est le pare-feu lui-même;

2. SORTIE - fait référence aux paquets provenant du pare-feu;

3. FORWARD - fait référence aux paquets passant par le pare-feu (qui n'est ni leur source ni leur destination).

La table nat possède également trois chaînes standard:

1. PRÉOUVERTURE - pour changer les colis immédiatement après leur arrivée;

2. POSTROUTING - pour changer les colis lorsqu'ils sont prêts à être envoyés;

3. SORTIE - pour modifier les paquets générés par le pare-feu lui-même.

Ces chaînes sont représentées sur la fig. 7.1.

image

Chaque chaîne est une liste de règles; chaque règle est un ensemble de conditions et une action exécutée lorsque les conditions sont remplies. Lors du traitement d'un paquet, le pare-feu analyse la chaîne correspondante, une règle après l'autre, et lorsque les conditions d'une règle sont remplies, il passe (d'où le paramètre -j dans les commandes) à l'action spécifiée pour continuer le traitement. Les types de comportement les plus courants sont standardisés et il existe des actions spéciales pour eux. L'exécution de l'une de ces actions standard interrompt le traitement de la chaîne, car le sort ultérieur des paquets est déjà prédéterminé (sans tenir compte de l'exception mentionnée ci-dessous). Voici les actions Netfilter.

1. ACCEPTER (ACCEPTER) - permet au paquet de se déplacer plus loin le long de son itinéraire.

2. REJETER - rejeter le paquet en utilisant le paquet d'erreur ICMP (protocole de message de contrôle Internet) (le type --reject-with pour iptables détermine le type d'erreur pour le rejet).

3. DROP - supprime (ignore) le package.

4. LOG (REGISTER) - enregistrez (via le démon syslogd) un message décrivant le paquet. Veuillez noter que cette action n'interrompt pas le traitement et que l'exécution de la chaîne se poursuit à partir de la règle suivante. Par conséquent, l'enregistrement des paquets rejetés nécessite à la fois les règles LOG et REJECT / DROP. Les paramètres généraux liés à l'enregistrement comprennent:

  • --log-level, avec un avertissement par défaut, indique la gravité de Syslog;
  • --log-prefix vous permet de spécifier un préfixe de texte pour distinguer les messages enregistrés;
  • --log-tcp-sequence, --log-tcp-options et --log-ip-options indiquent les données supplémentaires qui doivent être placées dans le message: numéro de série TCP, paramètres TCP et paramètres IP, respectivement.

5. ULOG - enregistrer un message via ulogd, qui peut être mieux adapté et plus efficace que syslogd pour traiter un grand nombre de messages; notez que cette action, comme LOG, renvoie également le traitement à la règle suivante de la chaîne d'appel.

6. nom_chaîne - accédez à la chaîne spécifiée et évaluez ses règles.

7. RETOUR - abandonner le traitement de la chaîne actuelle et revenir à la chaîne appelante; si la chaîne actuelle est standard, il n'y a pas de chaîne d'appel, donc l'action par défaut est exécutée à la place (définie à l'aide du paramètre -P pour iptables).

8. SNAT (uniquement dans la table nat) - appliquez la traduction d'adresse réseau source (SNAT). Des paramètres supplémentaires décrivent les modifications exactes à appliquer, y compris le paramètre --to-source address: port, qui définit la nouvelle source de l'adresse IP et / ou du port.

9. DNAT (uniquement dans le tableau nat) - appliquez la traduction d'adresse de réseau de destination (DNAT). Des paramètres supplémentaires décrivent les modifications exactes à utiliser, y compris le paramètre d'adresse --to-destination: le port qui définit la nouvelle source de l'adresse IP et / ou du port.

10. MASQUERADE (uniquement dans le tableau nat) - appliquer le masquage (cas particulier du NAT source).

11. REDIRECT (uniquement dans la table nat) - transfère ouvertement le paquet à ce port du pare-feu lui-même. Vous pouvez utiliser un proxy Web pour configurer un serveur ouvert, qui fonctionne sans configuration côté client, et pendant que le client pense qu'il se connecte au destinataire, les messages transitent en fait par le serveur proxy. Le paramètre --to-ports port (s) spécifie le port ou la plage de ports où les paquets doivent être transmis.

D'autres actions, notamment celles relatives à la table mangle, n'étaient pas incluses dans cette sous-section. Pour une liste complète, consultez les pages de manuel iptables (8) et ip6tables (8).

Syntaxe des commandes iptables et ip6tables


Les commandes iptables et ip6tables sont utilisées pour gérer les tables, les chaînes et les règles. Leur paramètre -t table indique la table avec laquelle travailler (par défaut, la table de filtre).

Équipes

Les principaux paramètres d'interaction avec les circuits sont répertoriés ci-dessous.

1. La chaîne -L répertorie les règles contenues dans la chaîne. Utilisé avec l'option -n pour désactiver la résolution de noms (par exemple, iptables -n -L INPUT affiche les règles pour les paquets entrants).

2.-La chaîne N crée une nouvelle chaîne. Vous pouvez créer de nouvelles chaînes à diverses fins, notamment pour tester un nouveau service réseau ou repousser une attaque réseau.

3. -X chain supprime la chaîne vide et inutilisée (par exemple, iptables -X ddos-attack).

4. -Une règle de chaîne ajoute une règle à la fin d'une chaîne donnée. N'oubliez pas que les règles sont traitées de haut en bas, n'oubliez pas de prendre en compte ce moment lors de l'ajout de règles.

5. -I chaîne règle_nombre règle insère la règle avant la règle avec le numéro spécifié. Comme pour l'option -A, tenez compte de l'ordre de traitement lorsque vous entrez de nouvelles règles dans la chaîne.

6. -D chain rule_number (ou -D chain rule) supprime la règle dans la chaîne; la première syntaxe indique que la règle avec un certain nombre doit être supprimée (la commande iptables -L --line-numbers affiche les numéros de règle), et la seconde identifie la règle à supprimer par son essence.

7. -F chaîne réinitialise la chaîne (supprime toutes ses règles). Par exemple, pour supprimer toutes les règles associées aux paquets sortants, vous devez entrer la commande iptables -F OUTPUT. Si aucune chaîne n'est spécifiée, toutes les règles du tableau sont supprimées.

8. L'action de chaîne -P définit l'action ou la "politique" par défaut pour une chaîne donnée. Remarque: cette politique ne s'applique qu'aux circuits standard. Pour supprimer tout le trafic entrant par défaut, vous devez exécuter la commande iptables -P INPUT DROP.

Les règles

Chaque règle est définie selon la syntaxe suivante: conditions -j action paramètres_action. Si plusieurs conditions sont décrites dans une règle, alors le critère est la combinaison (ET logique) de conditions, qui a une restriction au moins identique à chaque condition individuelle.

La condition de protocole -p correspond au champ de protocole de paquet IP. Les valeurs les plus courantes sont tcp, udp, icmp et icmpv6. Cette condition peut être complétée par des conditions concernant les ports TCP en utilisant les paramètres --source-port port et --destination-port port.



. , -p « , , ». .

-s -s / (source) . , -d -d / (destination).
-i , ; -o — , .

--state ( ipt_ conntrack ). NEW , , ESTABLISHED , , RELATED , , ( ftp- FTP).

iptables ip6tables, . , , — , .
, IP- 10.0.1.5 31.13.74.0/24 C , :

# iptables -A INPUT -s 10.0.1.5 -j DROP # iptables -A INPUT -s 31.13.74.0/24 -j DROP # iptables -n -L INPUT Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- 10.0.1.5 0.0.0.0/0 DROP all -- 31.13.74.0/24 0.0.0.0/0 

Une autre commande iptables est souvent utilisée pour autoriser le trafic réseau pour un service ou un port spécifique. Pour permettre aux utilisateurs de se connecter à SSH, HTTP et IMAP, vous devez exécuter les commandes suivantes:

 # iptables -A INPUT -m state --state NEW -p tcp --dport 22 -j ACCEPT # iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT # iptables -A INPUT -m state --state NEW -p tcp --dport 143 -j ACCEPT # iptables -n -L INPUT Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- 10.0.1.5 0.0.0.0/0 DROP all -- 31.13.74.0/24 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:143 

La bonne hygiène informatique est de nettoyer les règles anciennes et inutiles. Le moyen le plus simple de supprimer la règle iptables est de se référer aux règles par numéro de ligne, que vous pouvez obtenir en utilisant le paramètre --line-numbers. Attention: lorsque vous réinitialisez une règle, toutes les règles suivantes de la chaîne seront renumérotées.

 # iptables -n -L INPUT --line-numbers Chain INPUT (policy ACCEPT) num target prot opt source destination 1 DROP all -- 10.0.1.5 0.0.0.0/0 2 DROP all -- 31.13.74.0/24 0.0.0.0/0 3 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 4 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 5 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:143 # iptables -D INPUT 2 # iptables -D INPUT 1 # iptables -n -L INPUT --line-numbers Chain INPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 2 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80 3 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:143 

Des conditions plus spécifiques existent, en fonction des conditions générales décrites ci-dessus. Consultez les manuels iptables (8) et ip6tables (8) pour plus d'informations.

Créer des règles


Chaque nouvelle règle nécessite un appel à iptables ou ip6tables. La saisie manuelle de ces commandes peut être fastidieuse, de sorte que les appels sont généralement stockés dans un script et, par conséquent, le système est automatiquement configuré de la même manière à chaque démarrage de l'ordinateur. Ce script peut être écrit à la main, mais vous pouvez également être intéressé à le préparer avec un outil de haut niveau tel que fwbuilder.

 # apt install fwbuilder 

Le principe est simple. Dans un premier temps, décrivez tous les éléments qui seront impliqués dans les nouvelles règles:

1. Le pare-feu lui-même avec ses interfaces réseau;

2. réseaux avec des plages d'adresses IP appropriées;

3. serveurs;

4. ports appartenant à des services hébergés sur des serveurs.

Ensuite, créez les règles en utilisant de simples actions de glisser-déposer, comme indiqué dans la fig. 7.2. Plusieurs menus contextuels peuvent modifier une condition (par exemple, la refuser). Ensuite, vous devez sélectionner et configurer l'action.

image

Comme pour IPv6, vous pouvez soit créer deux ensembles de règles différents pour IPv4 et IPv6, soit simplement en créer un et laisser fwbuilder traduire les règles en fonction des adresses attribuées aux objets.

L'outil fwbuilder créera un script qui configure le pare-feu selon les règles que vous définissez. Son architecture modulaire vous permet de générer des scripts pour différents systèmes, y compris iptables pour Linux, ipf pour FreeBSD et pf pour OpenBSD.

Définition de règles pour chaque démarrage


Pour implémenter des règles de pare-feu à chaque démarrage de la machine, vous devez enregistrer le script de configuration dans la directive up du fichier / etc / network / interfaces. Dans l'exemple suivant, le script est stocké dans /usr/local/etc/arrakis.fw.

 auto eth0 iface eth0 inet static address 192.168.0.1 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 up /usr/local/etc/arrakis.fw 

Cet exemple suppose que vous utilisez le package ifupdown pour configurer les interfaces réseau. Si vous utilisez autre chose (par exemple, NetworkManager ou systemd-networkd), reportez-vous à la documentation appropriée pour savoir comment exécuter le script après avoir démarré l'interface.

7.5. Surveillance et journalisation


La confidentialité et la protection des données sont des aspects importants de la sécurité, mais il est tout aussi important de garantir la disponibilité des services. En tant qu'administrateur et spécialiste de la sécurité, vous devez vous assurer que tout fonctionne correctement et votre responsabilité est d'identifier en temps opportun les comportements anormaux et la détérioration des services. Les logiciels de surveillance et de journalisation jouent un rôle clé dans cet aspect de la sécurité, car ils permettent de comprendre ce qui se passe dans le système et le réseau.

Dans cette section, nous examinerons un certain nombre d'outils qui peuvent être utilisés pour surveiller plusieurs aspects du système Kali.

Surveillance des journaux avec logcheck


Logcheck surveille les fichiers journaux toutes les heures par défaut et envoie des messages de journal non standard aux messages électroniques à l'administrateur pour une analyse plus approfondie.

La liste des fichiers surveillés est stockée dans /etc/logcheck/logcheck.logfiles. Les valeurs par défaut fonctionneront correctement si le fichier /etc/rsyslog.conf n'a pas été complètement reconstruit.

Le programme logcheck peut générer des rapports en utilisant différents niveaux de détails: paranoïaque (paranoïaque), serveur (serveur) et poste de travail (pour les postes de travail). Le mode paranoïaque est très détaillé et devrait probablement être limité à des serveurs spécifiques tels que les pare-feu. Le mode serveur est utilisé par défaut et est recommandé pour la plupart des serveurs. Le mode station de travail est évidemment conçu pour les postes de travail et est extrêmement compressé, filtrant plus de messages que les autres "frères".

Dans les trois cas, la vérification du journal doit probablement être configurée pour exclure les messages supplémentaires (selon les services installés) si vous ne souhaitez pas recevoir de lots horaires de longs e-mails non enregistrés. Le mécanisme de sélection des messages étant assez compliqué, le fichier /usr/share/doc/logcheck-database/README.logcheck-database.gz doit être lu en cas de difficultés.

Les règles applicables peuvent être divisées en plusieurs types:

1. ceux qui qualifient le message de tentative de piratage (stocké dans un fichier du répertoire /etc/logcheck/cracking.d/);

2. ignoré les tentatives de piratage (/etc/logcheck/cracking.ignore.d/);

3. ceux qui classent le message comme un avertissement de sécurité (/etc/logcheck/violations.d/);

4. ignoré les avertissements de sécurité (/etc/logcheck/violations.ignore.d/);

5. Enfin, ceux qui s'appliquent à d'autres messages (traités comme des événements système).

Les fichiers ignore.d sont utilisés (évidemment) pour ignorer les messages. Par exemple, un message marqué comme une tentative de piratage ou un avertissement de sécurité (en règle générale, stocké dans /etc/logcheck/violations.d/myfile) ne peut être ignoré que par une règle dans /etc/logcheck/violations.ignore.d/myfile ou dans le fichier /etc/logcheck/changes.ignore.d/myfile- extension.

Un événement système est toujours signalé, sauf si la règle dans l'un des répertoires /etc/logcheck/ignore.d.{paranoid, server, workstation} / n'indique pas que cet événement doit être ignoré. Bien entendu, seuls les catalogues dont les niveaux de détail sont égaux ou supérieurs au mode de fonctionnement sélectionné sont pris en compte.

Surveillance de l'activité en temps réel


L'outil interactif supérieur affiche une liste des processus en cours d'exécution. Le tri par défaut est basé sur la charge actuelle du processeur et peut être obtenu à l'aide de la clé P. D'autres tri d'instructions contiennent un tri par mémoire occupée (clé M), temps total du processeur (clé T) et identificateur de processus (clé N). La clé k termine le processus avec l'identifiant entré. La touche r modifie la priorité du processus.

Lorsqu'un système semble surchargé, top est un excellent outil pour voir quels processus sont en compétition pour le temps CPU ou consomment trop de mémoire. Il est donc souvent intéressant de vérifier si les processus consommant des ressources correspondent à des services réels qui devraient être hébergés sur un ordinateur. Un processus inconnu qui fonctionne comme www-data devrait vraiment se démarquer de la liste et devrait être étudié, car il s'agit très probablement d'un exemple de logiciel installé et exécuté sur un système utilisant une vulnérabilité dans une application Web.

L'outil supérieur est très flexible et son manuel contient des informations détaillées sur la façon de personnaliser son interface et de l'adapter à vos besoins et habitudes personnels.

L'outil graphique gnome-system-monitor est similaire à top et fournit à peu près les mêmes fonctions.

»Plus d'informations sur le livre sont disponibles sur le site Web de l'éditeur
» Contenu
» Extrait

20% de réduction sur le coupon pour Linux - Linux

Source: https://habr.com/ru/post/fr422939/


All Articles