Pourquoi utiliser SSH et VPN en combinaison?

Mon employeur exige que je me connecte d'abord à un VPN, et seulement alors je peux SSH dans les serveurs. Mais, compte tenu de la sécurité de SSH, le VPN est-il exagéré?

À quoi sert un VPN en termes de sécurité si j'utilise déjà SSH ?

Le raisonnement derrière votre configuration actuelle est probablement une combinaison des trois raisons suivantes.

Le VPN est une solution de sécurité pour l'extérieur du réseau de votre entreprise (voir n ° 1 ci-dessous) . SSH cependant, pourrait être une deuxième couche de sécurité en dehors du réseau de votre entreprise ... mais son objectif principal est de sécuriser le trafic au sein du réseau de votre entreprise (voir n ° 2 ci-dessous) . Le VPN est également nécessaire si l'appareil dans lequel vous essayez de SSH utilise une adresse privée sur le réseau de votre entreprise (voir n ° 3 ci-dessous) .

1. Le VPN crée le tunnel vers le réseau de votre entreprise par lequel vous transférez les données. Ainsi, personne ne voyant le trafic entre vous et le réseau de votre entreprise ne peut réellement voir ce que vous envoyez. Tout ce qu'ils voient, c'est le tunnel. Cela empêche les personnes extérieures au réseau de l'entreprise d'intercepter votre trafic d'une manière utile.

2. SSH est un moyen crypté de se connecter aux appareils de votre réseau (contrairement à Telnet, qui est en texte clair). Les entreprises ont souvent besoin de connexions SSH même sur un réseau d'entreprise pour des raisons de sécurité. Si j'ai installé un logiciel malveillant sur un périphérique réseau et que vous vous connectez telnet (même si vous traversez un tunnel VPN - car le tunnel VPN se termine généralement au périmètre du réseau d'une entreprise), je peux voir votre nom d'utilisateur et votre mot de passe. Si c'est SSH que vous utilisez, je ne peux pas.

3. Si votre entreprise utilise un adressage privé pour le réseau interne, il est possible que l'appareil auquel vous vous connectez ne soit pas routable sur Internet. La connexion via un tunnel VPN serait comme si vous étiez directement connecté au bureau, vous utiliseriez donc le routage interne du réseau de l'entreprise qui ne serait pas accessible en dehors du réseau de l'entreprise.

SSH est une cible extrêmement populaire pour les tentatives de forçage brutal. Si vous avez un serveur SSH directement sur Internet, en quelques minutes, vous verrez des tentatives de connexion avec toutes sortes de noms d'utilisateurs (et mots de passe) - souvent des milliers par jour, même sur de petits serveurs insignifiants.

Il est maintenant possible de durcir les serveurs SSH (les trois principaux mécanismes nécessitent une clé SSH, refusant l'accès root à SSH et, si possible, restreignant les adresses IP qui sont même autorisées à se connecter). Pourtant, la meilleure façon de durcir un serveur SSH est de ne même pas l'avoir du tout sur Internet.

Pourquoi est-ce important? Après tout, SSH est fondamentalement sécurisé, non? Eh bien, oui, mais il n'est aussi sûr que les utilisateurs le font - et votre employeur pourrait bien être préoccupé par les mots de passe faibles et le vol des clés SSH.

L'ajout d'un VPN ajoute une couche de défense supplémentaire qui est contrôlée au niveau de l'entreprise, plutôt qu'au niveau du serveur individuel comme SSH.

Dans l'ensemble, je félicite votre employeur d'avoir mis en œuvre ici de bonnes pratiques de sécurité. Au détriment de la commodité, bien sûr (la sécurité se fait généralement au détriment de la commodité).

Le VPN vous permet de vous connecter au réseau privé de votre employeur et d'acquérir une adresse IP de ce réseau privé. Une fois connecté au VPN, c'est comme si vous utilisiez l'un des ordinateurs de l'entreprise - même si vous êtes physiquement situé à l'autre bout du monde.

Très probablement, votre employeur vous demande de vous connecter via VPN d'abord parce que les serveurs ne sont pas accessibles depuis Internet (c'est-à-dire qu'ils n'ont pas d'adresse IP publique), ce qui est une bonne idée. Le VPN ajoute une autre couche de sécurité, comme si les serveurs étaient accessibles au public via SSH, ils seraient vulnérables à une gamme d'attaques.

SSH est un protocole de chiffrement utilisé pour plusieurs choses. Le chiffrement du trafic dans un tunnel VPN en fait partie. Votre trafic est chiffré à l'aide de SSH, mais il doit ensuite être enveloppé dans des paquets IP valides (tunnel) pour traverser un réseau comme Internet. Ce tunnel est le VPN.

Fondamentalement, votre employeur bloque le trafic réseau extérieur, pour des raisons de sécurité, à moins que ce trafic ne passe par un VPN que l'employeur contrôle. Un VPN peut ou non chiffrer le contenu du tunnel. L'utilisation de SSH chiffrera le trafic transporté dans le tunnel VPN.

Vous avez besoin du VPN pour accéder au réseau local.

Vous n'avez alors pas besoin de sécuriser votre connexion à des serveurs individuels, car elle sera déjà cryptée par le lien VPN.

Cependant, comment pourriez-vous vous y connecter autrement? SSH est le protocole d'accès de facto à la console pour les serveurs distants; l'installation et la configuration d'une connexion non sécurisée constitueraient une surcharge de gestion supplémentaire et réduiraient la sécurité au sein du réseau local (ce qui peut ou non être un problème).

N'oubliez pas que tout le monde, même au sein de l'entreprise, n'aura pas un accès total à tous les serveurs, et la possibilité d'utiliser le chiffrement par clé, même au sein du réseau local, permet à votre administrateur réseau de s'assurer facilement et en toute sécurité que seules les personnes qui savent ostensiblement ce qu'elles font, même au sein de l'entreprise, sont autorisés à toucher le serveur.

Vous pouvez également générer des couches de sécurité supplémentaires via le VPN. Tels que les vérifications des critères de l'appareil, l'authentification à 2 facteurs, etc.

Le raisonnement typique est que vous voulez réduire autant que possible l'exposition et les vecteurs d'attaque possibles.

Si vous partez du principe que SSH et VPN sont requis (à leurs propres fins), alors les deux font face à l'extérieur signifie que les attaquants ont deux voies potentielles dans votre environnement. Si vous définissez SSH uniquement local, cela ajoute une couche supplémentaire à la sécurité du serveur. Considérez les scénarios suivants:

1. SSH + VPN en externe. L'attaquant n'a besoin que de compromettre SSH pour compromettre le serveur.

2. SSH externe. Fonctionnellement identique au scénario précédent.

3. VPN externe (SSH interne). Double la sécurité. L'attaquant doit percer les deux avant de pouvoir faire quoi que ce soit au serveur.

Considérez que, parallèlement au fait que le VPN serait nécessaire pour d'autres fonctions, et pourrait être mieux configuré pour un accès externe et c'est une évidence.

Je risquerais que la réponse soit simplement que le NAT est impliqué et (comme beaucoup d'autres l'ont déclaré) exposer le serveur cible ultime au monde invite un autre point d'attaque. À moins que vous ne fassiez de gros transferts de données en masse avec de grandes clés, SSH ne vous gêne généralement pas. Le goulot d'étranglement sera presque toujours le réseau. (Presque! = Toujours).

Si vous avez la chance d'avoir IPv6, ce n'est probablement pas autant un problème, mais avec IPv4 et l'espace d'adressage limité, le NAT est (IMO) en fin de compte ce que je pense derrière cette `` politique '' plus que tout autre. sécurité «accidentelle» ou «délibérée».

D'après ma compréhension actuelle, SSH - car il utilise simplement un échange de clé tcp pour vérifier qu'un utilisateur client dispose des informations d'identification correctes pour accéder à l'ID utilisateur sur le serveur, est susceptible d'être attaqué par l'homme au milieu lorsqu'un FAI ou un routeur compromis pourrait intercepter la demande de prise de contact et agir comme celui qui envoie l'authentification, détournant en fait la connexion. Cela permet d'injecter des commandes dans le flux, puis de filtrer la sortie avant qu'elle n'atteigne le client authentique initial, cachant ainsi l'homme au milieu de l'injection de commandes arbitraires dans le shell ssh du serveur.

Cependant, un tunnel VPN permet quelque chose que ssh ne fait pas. Une clé de chiffrement symétrique supplémentaire convenue au préalable. Cela signifie que le trafic entre les deux machines n'est pas susceptible d'être attaqué par un homme au milieu car le trafic, s'il est intercepté et transféré au nom du client authentique afin de contrôler la couche de chiffrement SSL, ne pourrait pas transmettre la clé de chiffrement VPN. exigences car le tiers n'aurait pas la possibilité d'usurper les clés vpn de la même manière qu'il serait en mesure de contrôler un transfert intermédiaire de la connexion ssh tcp ssl.

Donc, ssh n'est pas assez bon pour arrêter l'homme au milieu d'un FAI ou d'un routeur compromis qu'un client doit traverser pour se connecter au serveur.