Quel est le niveau de sécurité de RDP?
J'ai une sorte de conflit avec l'ingénieur en chef de la sécurité de mon entreprise. Il dit que Remote Desktop Protocol (RDP) n'est pas suffisamment sécurisé et nous devrions plutôt utiliser TeamViewer . Nous utilisons RDP non seulement pour accéder aux ressources locales au sein de notre réseau d'entreprise, mais aussi pour l'accès aux ressources (exécutant Windows 2012+) dans l'hébergement cloud.
Dans les deux scénarios, est-il sûr d'utiliser RDP?
Je crois que Teamviewer est un service proxy pour les connexions VNC tunnellisées. Par conséquent, la première considération de sécurité en ce qui concerne ce service est qu'il est MITM'ed par conception . Il a été suggéré que le service était compromis il y a quelques mois .
(Notez que bien que VNC utilise le cryptage, l'ensemble de l'échange n'est pas, par défaut, encapsulé - mais il est trivial de configurer un tunnel SSL/ssh/VPN).
La considération suivante est que cela signifie installer un logiciel tiers sur vos systèmes - mais si vous exécutez une plate-forme Microsoft, vous exécutez déjà un logiciel de plusieurs fournisseurs qui n'est probablement pas couvert par votre logiciel de gestion des correctifs; la mise à jour des logiciels est l'un des moyens les plus efficaces de protéger vos systèmes.
Tant que votre connexion RDP utilise SSL, elle devrait être au moins aussi sécurisée que Teamviewer et IMHO, beaucoup plus.
Edit: Selon les commentaires, il semble y avoir une combinaison d'options de configuration dans l'édition entreprise de TeamViewer qui pourrait réduire mes inquiétudes. Étant donné que je ne les ai jamais utilisés, je ne peux pas donner une évaluation de ceux-ci et de leur efficacité. Selon les commentaires, il pourrait s'agir d'une solution de buggy.
Je suis administrateur de serveur (Windows et Linux) et je bloquerais toute tentative d'installation de TeamViewer sur les serveurs pour les raisons suivantes:
- toutes les données transitent sur un serveur tiers de confiance (?) et cela se trouve sur Internet: pourquoi dois-je leur faire confiance? Êtes-vous sûr qu'aucun trou de sécurité ne permet à une personne sur le chemin de données d'attaquer les systèmes? Ai-je confiance que leurs serveurs ne sont pas compromis?
- cela dépend d'Internet: les problèmes de réseau/Internet sont plus susceptibles de désactiver la possibilité d'administrer les systèmes à distance
- logiciel tiers fermé avec protocole propriétaire (non documenté?): dois-je leur faire confiance et que leur protocole est sécurisé?
- Je ne connais pas la gestion des utilisateurs/droits pour TeamViewer mais cela pourrait également être un problème. Pour autant que je sache, TeamViewer vous donne l'écran de l'utilisateur actuellement connecté, ce qui pourrait poser des problèmes d'audits (quelle personne a fait une certaine action?) Et de droits d'utilisateur (la personne qui se connecte obtient les droits de l'utilisateur connecté précédent). J'espère que tout le monde a son propre utilisateur sur le serveur et n'utilise pas le même utilisateur (peut-être même l'administrateur!).
Pour moi, il y a trop de drapeaux rouges.
Nos serveurs sont dans un sous-réseau isolé où le pare-feu/commutateur n'autorise que les ports préconfigurés et permet aux utilisateurs de se connecter avec VPN à ce sous-réseau avec leur nom d'utilisateur/mot de passe. Nous suivons une approche défense en profondeur: seuls certains groupes ont le privilège de se connecter au VPN avec leur utilisateur. À l'intérieur du VPN, ils peuvent utiliser RDP ou SSH. S'il devait y avoir une vulnérabilité de sécurité dans RDP, l'attaquant aurait d'abord besoin d'accéder au VPN ou au LAN. Cela signifierait qu'ils seraient soit notre personnel informatique (auquel une entreprise doit faire confiance dans une certaine mesure), auraient accès à un VPN ou à un accès physique, soit pirateraient l'un des serveurs. L'accès physique signifie pénétrer dans le centre de données; si cela se produit, il y a de plus grandes inquiétudes. Il en va de même pour quelqu'un du personnel informatique qui se met à la poste. S'ils violent un des serveurs, ils auraient également besoin d'une vulnérabilité d'élévation de privilèges pour attaquer car ils sont des comptes verrouillés. Pour l'accès VPN, il aurait besoin d'une vulnérabilité dans le VPN ou obtenir le compte de quelqu'un avec des privilèges VPN.
Et tout cela uniquement dans le cas où il existe une vulnérabilité RDP. Très probablement seulement un attaquant classé comme une menace persistante avancée ( APT ), c'est-à-dire quelqu'un utilisant des techniques sophistiquées pour cibler votre système spécifique lors d'une attaque soutenue, aurait un exploit sur 0 jour pour RDP et il est plus probable qu'un tel attaquant puisse utiliser des méthodes/vulnérabilités plus faciles dans d'autres logiciels.
En plus des autres bonnes réponses, TeamViewer offre moins de sécurité physique car il nécessite que l'écran soit déverrouillé afin de faciliter une session à distance.
Autrement dit, toute personne passant devant un clavier et un moniteur d'une session administrée à distance peut l'observer et éventuellement reprendre la session si l'utilisateur distant ne fait pas attention.
Remarque, il apparaît possible de masquer l'écran après l'installation d'un pilote d'affichage, cependant cela doit être fait à chaque connexion laissant une fenêtre d'opportunité.
En outre, vous faites maintenant confiance à la sécurité de la suppression d'écran TeamViewer plutôt qu'à la sécurité de l'écran de verrouillage Windows - assurez-vous que vous êtes à l'aise avec cela.
Pour commencer, je ne connais rien à TeamViewer, donc je n'essaierai pas de le commenter.
Les serveurs RDP historiques utilisaient la "sécurité RDP", qui est en effet un protocole cassé et vulnérable au MITM. Ne fais pas ça. Même 2003r2 peut faire TLS pour RDP, il n'y a donc aucune raison moderne pour laquelle vous devriez être obligé d'utiliser la sécurité RDP.
Les serveurs modernes prendront en charge TLS, la sécurité de RDP est donc directement liée à la sécurité de TLS. Avec les réglages du registre, vous pouvez appliquer un sous-ensemble de TLS que vous aimez - forcer à 1.2, restreindre à certaines suites de chiffrement, peut-être d'autres choses.
De plus, il existe un angle spécifique RDP ici dans la mesure où le serveur peut restreindre les connexions à celles qui prennent en charge "l'authentification au niveau du réseau". NLA utilise toujours TLS, c'est juste un changement de protocole pour effectuer l'authentification plus tôt dans l'échange. Je pense que cela vise à protéger contre une attaque par déni de service où des utilisateurs non authentifiés tentent à plusieurs reprises de se connecter sans s'authentifier.
Si vous deviez décrypter et tracer une session TLS RDP à l'aide de NLA, vous verriez ce qui suit:
- X.224 Exchange, non chiffré, 1 paquet dans chaque direction pour déterminer si le client et le serveur peuvent parler NLA
- Prise de contact TLS
- Échange NLA (vraiment [MS-CSSP]) pour effectuer l'authentification
- Échange de protocole RDP normal par [MS-RDPBCGR]
En supposant que vous utilisez une version moderne de RDP et que vous la configurez correctement (par exemple, activez NLA, triez les certificats appropriés), le principal risque de l'exposer directement à Internet est généralement le problème de l'exposition d'un système d'authentification par nom d'utilisateur/mot de passe au Internet, c'est-à-dire que vous autorisez les attaquants à tenter de forcer les comptes Active Directory (en supposant qu'il s'agit d'un environnement AD et non d'un ensemble de serveurs autonomes).
Ce n'est pas génial car vous vous retrouvez avec un risque DoS avec un ensemble de verrouillage de compte ou un risque d'accès non autorisé sans aucun ensemble de verrouillage de compte (quelqu'un choisira toujours un mot de passe faible ou en utilisera un qui est violé ailleurs), donc si vous exposent directement RDP, je recommanderais l'authentification à deux facteurs aux utilisateurs autorisés à accéder via ce mécanisme.
Quant à TeamViewer, il n'y a pas de risque d'accès direct, mais vous leur faites confiance en tant qu'organisation et cela a été souligné par d'autres réponses qu'ils ont récemment eu des problèmes de sécurité.
Je vais développer Daniel Bungert explication des protocoles impliqués et pourquoi ils fonctionnent ensemble. Ayant écrit un proxy MitM pour RDP, je connais très bien le fonctionnement interne de la plupart des protocoles impliqués. (Plus que je ne voudrais être ...)
Vous pouvez le configurer pour fonctionner uniquement sur TLS. Cela offre une grande sécurité à part entière, chaque message est enveloppé d'un cryptage TLS. Vous pouvez gérer des stratégies de groupe qui définiront les protocoles de chiffrement TLS autorisés. Vous pouvez l'utiliser pour spécifier uniquement ceux avec des longueurs de clé ou des algorithmes que vous jugez appropriés. Ce sont des paramètres généraux de Windows et non spécifiques à rdp. Votre seule préoccupation serait que les utilisateurs acceptent de mauvais certificats, auquel cas une attaque MitM est possible.
Cependant, vous pouvez le configurer davantage pour qu'il fonctionne uniquement avec l'authentification NLA. Plus précisément, cela utilisera CredSSP avec NTLM. Cela empêche MitM car le certificat utilisé dans la couche TLS est utilisé (avec d'autres choses) pour crypter le mot de passe. Vous ne pouvez alors plus simplement transférer le mot de passe chiffré car le service rdp cible n'authentifiera pas un hachage qui a été généré avec un certificat autre que le sien. La raison pour laquelle mon mitm fonctionne est parce que nous connaissons les mots de passe qui sont utilisés pour se connecter au proxy, et avec cela nous pouvons extraire des informations et générer un nouveau hachage pour le service rdp cible. Un proxy rdp malveillant n'aura pas cet avantage.
Ainsi, avec TLS et NLA configurés, rdp est à l'abri des utilisateurs qui peuvent accepter de mauvais certificats. Cela contrecarre celui d'Overmind les préoccupations concernant les attaques à mitm.
J'irais avec une sorte de VPN depuis l'ordinateur distant de l'utilisateur vers un pare-feu au travail, puis exécuter RDP sur ce lien crypté.
Le problème de laisser un port ouvert est que finalement il est trouvé et vous aurez des tentatives de connexion par force brute. Soit cela ne fera que ralentir votre environnement, soit cela entraînera le verrouillage des comptes, soit ils trouveront un nom d'utilisateur avec un mot de passe faible (il y a toujours cet utilisateur ...)
Vous pouvez explorer l'authentification à 2 facteurs avec des applications pour smartphone, des jetons matériels ou des mots de passe à usage unique préimprimés.
N'oubliez pas que la sécurité est l'opposé de la commodité.
Cela a commencé comme un commentaire.
Il est important de souligner la "question de la faute". Si vous utilisez un service tiers et qu'ils ne fournissent pas, c'est leur incapacité à fournir. Si vous utilisez quelque chose à la maison et qu'il échoue, c'est maintenant la faute de la maison. De telles distinctions ont beaucoup de poids. Cela ne signifie peut-être rien pour la sécurité réelle, mais cela peut parfois aller de côté.
Par exemple, si vous devez obtenir la certification d'un contrat et que cette certification indique quelque chose comme:
Vous devez utiliser des méthodes de gestion à distance sécurisées, les méthodes de gestion à distance non cryptées ne sont pas autorisées. Les contrats avec un tiers pour fournir des services sont autorisés. Le chiffrement doit être une force foo et des exigences de barre. Les services communs qui répondent à ces exigences sont LogMeIn et TeamViewer. Les services courants qui ne répondent pas à ces exigences sont GoToMyPC et VNC standard.
Ensuite, la décision pourrait être prise d'utiliser Team Viewer.
Il y a ensuite le risque pour l'entreprise. On pourrait faire valoir que Teamviewer présente moins de risques, car vous utilisez un service de bonne foi censé être sécurisé. Dans le même temps, le RDP peut être plus risqué, car maintenant vous comparez les connaissances de votre équipe à la compréhension aléatoire des gens.
En fin de compte, bien que cela n'ait aucun lien réel avec la sécurité réelle, il est important de se rappeler que les entreprises ne font pas de sécurité car cela leur rapporte de l'argent (normalement). Ils le font comme atténuation des risques et parce qu'ils doivent continuer à gagner de l'argent. L'utilisation d'un service tiers peut éliminer certains risques pour l'entreprise.
Comme mentionné, vous devez utiliser le cryptage RDP + si possible. Mais, je n'ai vu aucune mention de mesures de sécurité de base contre les attaques (brutes ou autres) dans les réponses fournies.
TOUT logiciel/port (s) laissé (s) ouvert (s) au public va être scanné/trouvé. Période. RDP ou non. Cryptage ou pas. Si l'accès public n'est pas nécessaire, pourquoi le permettre?
La création et l'administration d'une liste "autorisée" basée sur des blocs IP peut être longue et pénible (si de nombreux hôtes y accèdent), mais elle ne doit pas être négligée. Que ce soit 1 IP ou des centaines d'adresses IP de réseau distinctes.
Vous avez mentionné un serveur basé sur le "cloud". Ainsi, par exemple, sur AWS/ec2, il faut utiliser un groupe de sécurité EC2 pour autoriser certains réseaux IP ou administrateurs et refuser le reste. La plupart des fournisseurs ont des méthodes similaires.
Le point est (et en plus des réponses fournies): RDP serait mon choix, mais rien de parfait. Cela devient encore plus imparfait si vous ne bloquez pas les réseaux indésirables.
Sur RDP, vous pouvez effectuer une attaque MiTM, puis tout le trafic du serveur RDP vers le client RDP et retour passera par notre système MiTM. C'est pourquoi il n'est pas considéré comme sûr.
Quant à Teamviewer, vous devez faire confiance à un tiers, ce qui n'est pas l'option que beaucoup choisiraient.
En ce qui concerne le meilleur des cas, vous devez configurer votre propre VPN basé sur un certificat.