Dans quelle mesure la liaison avec localhost est-elle sécurisée pour empêcher les connexions à distance?
Supposons que nous exécutons un service lié à localhost (127.0.0.1), et l'objectif est de n'autoriser que les clients locaux (c'est-à-dire à partir de la même machine uniquement)
Quelles techniques pourraient être utilisées pour briser cette sécurité, existe-t-il des mesures supplémentaires qui pourraient être utilisées pour la faire respecter?
La première et principale chose est de s'assurer que le pare-feu sur votre hôte est configuré pour supprimer correctement les paquets entrants avec l'adresse source ou de destination définie sur 127.0.0.1.
Dans des circonstances normales, aucun paquet ne devrait provenir du réseau et afficher de telles adresses. Cependant, un attaquant peut tenter de forger de tels paquets afin d'atteindre vos services d'écoute locaux.
Je ne sais pas quel type d'autres services écoutent sur votre machine, mais si un service peut être utilisé comme relais, vous devez vous assurer qu'il est correctement configuré pour empêcher de relayer quoi que ce soit aux services d'écoute locaux.
Par exemple, si vous avez un proxy HTTP en cours d'exécution sur cet hôte, un attaquant peut utiliser ce proxy pour demander l'hôte "127.0.0.1": du point de vue du pare-feu, il s'agira d'une connexion légitime provenant du réseau vers le service proxy, et localement, ce sera une communication légitime entre deux services locaux (le proxy et le port local ciblé). Le proxy HTTP n'est ici qu'un exemple, une telle technique peut également fonctionner avec d'autres services, y compris des services où le relais des connexions n'est pas la fonctionnalité principale (la attaque par rebond FTP par exemple est un exemple classique d'une telle menace) .
Une vulnérabilité potentielle serait de compromettre un compte/service à faible privilège et de l'utiliser comme pivot pour accéder au service lié à l'hôte local.
Je préfère généralement les sockets UNIX à cet effet car vous pouvez leur appliquer des autorisations utilisateur/groupe (qui seront gérées de manière transparente par le système d'exploitation, l'utilisateur n'aura pas à conserver un autre mot de passe). De plus, ils sont également un peu plus rapides, ce qui les rend préférables pour IPC sur la même machine.
Notez que les autorisations de socket ne sont pas toujours respectées sur certaines variantes UNIX et un réglage spécifique au système d'exploitation peut être nécessaire (comme l'augmentation du nombre de connexions autorisées par socket).
Si le service fournit une interface Web, il peut être vulnérable aux attaques CSRF, aux attaques XSS ou scriptage "même site" . Tout cela peut être déclenché en visitant simplement le site Web externe de l'attaquant, ce qui pourrait être provoqué par malvertising ou phishing. Pour ces attaques, peu importe que le service écoute uniquement sur l'hôte local, car il suffit que l'hôte soit accessible par le navigateur Web local. Les mêmes problèmes existent avec l'attaque des hôtes intranet de l'extérieur.
Considérez également que le nom d'hôte localhost n'est pas exactement le même que l'IP 127.0.0.1 (il doit naturellement être résolu en premier) et, dans la plupart des situations, repose sur une entrée dans le fichier hosts ou sur un serveur resolver/dns capable de résoudre 127.0 .0.1. Donc, assurez-vous que vous pouvez spécifier strictement 127.0.0.1 au lieu de localhost lors de la mise en œuvre des mesures de sécurité, sinon vous devrez prendre du recul et également prendre en compte les problèmes de sécurité dans le résolveur.
La réponse dépend de différents facteurs. Quelques-unes qui peuvent s'appliquer ou non:
- De quel protocole s'agit-il? (Par exemple, UDP est plus sujet aux problèmes de sécurité dans ce cas car il fonctionne sans état et vous pouvez réaliser quelque chose avec un seul paquet usurpé).
- Considérez-vous les attaques ou uniquement l'accès aux données. (Voir ci-dessus: vous pourriez être en mesure de faire une attaque DoS pour un service UDP défectueux avec un seul paquet, mais vous n'atteindrez pas le flux de données).
- Avez-vous un accès à distance au niveau utilisateur (par conception ou comme problème de sécurité lui-même)? (Par exemple, un utilisateur peut configurer un tunnel SSH.)
- Avez-vous un accès root à distance (par conception ou en tant que problème de sécurité lui-même)? (On pourrait mettre en place un NAT pour rediriger le trafic IP public vers 127.0.0.1)
- Avez-vous un pare-feu, un filtrage d'entrée correctement configuré?
- Avez-vous d'autres services réseau ouverts sur des hôtes non locaux qui peuvent être "trompés" pour accéder au service local uniquement en votre nom?