Sécurisation des services / Linux
Résolu/Fermé
Lynow
-
2 févr. 2022 à 17:09
mamiemando Messages postés 33371 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 22 novembre 2024 - 10 févr. 2022 à 13:54
mamiemando Messages postés 33371 Date d'inscription jeudi 12 mai 2005 Statut Modérateur Dernière intervention 22 novembre 2024 - 10 févr. 2022 à 13:54
A voir également:
- Sécurisation des services / Linux
- Linux mint 32 bits - Télécharger - Systèmes d'exploitation
- Diskinternals linux reader - Télécharger - Stockage
- Linux live usb creator - Télécharger - Outils Internet
- Quel linux choisir - Guide
- Backtrack linux - Télécharger - Sécurité
1 réponse
mamiemando
Messages postés
33371
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
22 novembre 2024
7 801
3 févr. 2022 à 14:24
3 févr. 2022 à 14:24
Bonjour,
La sécurité est un vaste sujet, donc voici quelques éléments de réponses assez généraux :
Bonne chance
La sécurité est un vaste sujet, donc voici quelques éléments de réponses assez généraux :
- On minimise les droits / accès (au sens des utilisateurs et du réseau)
- On essaye de lancer un service avec un utilisateur dédié. Généralement il est automatiquement créé à l'installation et la chaîne de démarrage l'utilise pour lancer le démon. Cela évite, si le service est compromis, que l'intrus soit directement root. Cependant, certains services nécessitent des droits root (par exemple à cause du port qu'ils utilisent, parce qu'ils doivent avoir accès à des opérations administrateurs, etc...)
- On choisit une bind address adéquate. Par exemple un serveur mysql n'a généralement besoin d'être accédé que par le serveur web colocalisé, et donc n'a besoin que d'écouter que le trafic interne à la machine. Dans ce scénario très classique, mysqld sera bindé avec
127.0.0.1
au lieu de0.0.0.0
. - On peut utiliser un pare-feu "réseau"
iptables
pour contrôler qui accède au service. Plus généralement, la manière dont tu architectures ton réseau et qui peut accéder à quoi (IP publique vs IP locale, redirections de ports, etc...) influence les points d'entrées sur lesquels tu peux être attaqués - Cloisonner les services à l'aide de container limite aussi les risques d'escalade.
- On bannit les connexions suspectes
- On peut utiliser des solutions comme
fail2ban
pour automatiquement ajouter dans iptables un filtre empêchant une IP cliente suspecte de se connecter.fail2ban
se base typiquement sur les erreurs d'authentifications recensées dans les logs. - On peut utiliser des NIDS comme
snort
pour détecter des tentatives d'intrusions.
- On peut utiliser des solutions comme
- On sécurise autant que possible les connexions entre clients et serveurs et on surveille l'activité.
- On évite autant que possible les authentifications par mot de passe. Par exemple on préfère une clé ssh à un mot de passe, ou plus généralement un token si le service concerné en propose (cf par exemple des services comme pypi pour la CI).
- On utilise autant que possible des protocoles sécurisés et certifiés (ssh, https...) pour éviter que le trafic soit sniffé et s'assurer d'avec qui on communique.
- Si on est contraint d'utiliser des mots de passe, on s'assure autant que possible que ceux-ci ne sont pas triviaux.
- Des solutions de monitoring (
nagios
,cacti
,munin
) permettent de surveiller en temps réel la disponibilité des services et le taux d'utilisation des ressources. Cela permet de détecter des anomalies au sens large et peut en cas d'intrusion te mettre la puce à l'oreille.
- On essaye de maintenir le système à jour pour bénéficier des dernières mises à jour de sécurité. Certains site comme https://blog.qualys.com permettent de se tenir informé des dernières grosses menaces.
- Pour les plus motivés, on fait des tests de pénétrations (pas forcément besoin d'une distribution spécifique pour en faire).
Bonne chance
Modifié le 3 févr. 2022 à 14:45
Je me suis déjà penché sur un outil spécifique, qui est Cortex.
Pour commencer, j'ai créé un certificat SSL auto-signé, afin d'avoir du https.
Pour ce faire, il n'est pas possible de configurer ce certificat directement avec Cortex, il faut utiliser un reverse proxy. Ce que j'ai fait, et cela fonctionne.
Ensuite, j'ai créé un iptables comme ceci :
J'ai également entré la commande pour refuser tous les autres trafics. Je n'ai donc ajouté que le strict nécessaire :
- https / http pour les connexions du serveur
- L'adresse IP provenant d'un outil TheHive, qui a besoin d'envoyer des données à Cortex
- Le loopback
Ensuite, au niveau de la surveillance des logs, NIDS, fail2ban etc. J'ai déjà des agents Wazuh permettant de le faire, ainsi que Suricata.
En ce qui concerne le conteneur virtuel Cortex, il me reste donc à créer un utilisateur qui aura pour but de lancer le service, uniquement.
Est-ce que cela te semble cohérent ?
Pour le reverse proxy, j'utilise nginx, installé sur le conteneur Cortex, je ne sais pas s'il y a un apport de sécurité à effectuer sur celui-ci.
3 févr. 2022 à 15:11
Un point a attiré mon attention : tu parles de certificats auto signés. Ça peut être contraignant au niveau du client (certificat suspect etc...) : cela l'oblige soit a ignorer l'alerte soit à importer ledit certificat. Cela concerne également les applications clientes qui doivent bien souvent ajouter des "flags" pour ignorer le fait que le certificat soit auto signé (e.g. ) , ce qui n'est pas très élégant en terme d'implémentation. Bref, quand le service en question est public, une solution comme peut s'avérer idéale. (Let's encrypt)
Bonne chance
Modifié le 3 févr. 2022 à 15:54
Pour revenir à la partie
On essaye de lancer un service avec un utilisateur dédié
de ton message, je veux être sûr de bien comprendre : j'ai un utilisateur qui est effectivement déjà créé, appelé cortex. J'ai fais chmod u+x cortex.service pour lui permettre d’exécuter le service.
Ensuite, si j'ai bien compris l'idée est que cet utilisateur n'ait aucun autre droit que celui-ci. Il y a t-il une façon de faire pour supprimer tous les droits de l'utilisateur (hormis le faire pour chaque fichier) ?
PS : Je découvre un peu la sécurité informatique (au sens purement technique et opérationnel), par contre je connais très bien les outils de Threat Intelligence comme Cortex :p
Modifié le 3 févr. 2022 à 16:42
> J'ai fais chmod u+x cortex.service pour lui permettre d’exécuter le service
Les unités systemd ne sont pas des exécutables, ce sont des fichiers de configuration qui sont lus par systemd. Le propriétaire d'une unité systemd système (définie dans /etc/systemd/system/) est généralement root et, de toutes façons, le propriétaire de ce fichier de configuration n'indique pas l'utilisateur avec lequel le service sera exécuté, changer le propriétaire du fichier d'unité ne permet pas de changer le propriétaire du processus. L'unité sera toujours lancée par systemd avec ses droits root.
Il est possible de définir l'utilisateur / groupe exécutant le processus dans l'unité.
Exemple :
Il est possible de définir des unités au niveau utilisateur (dans ~/.config/systemd/user/) et d'appeler systemctl sans privilège avec le drapeau --user.
Voir ici : https://wiki.archlinux.org/title/systemd/User
Modifié le 3 févr. 2022 à 16:58
Effectivement, j'avais essayé de changer le propriétaire pour mettre cortex, mais comme tu l'as expliqué, cela ne fonctionne pas.
Dans l'unité cortex.service, il est bien indiqué :
> Il est possible de définir des unités au niveau utilisateur (dans ~/.config/systemd/user/) et d'appeler systemctl sans privilège avec le drapeau --user.
Voir ici : https://wiki.archlinux.org/title/systemd/User
Très bien, je vais regarder cela, merci !