Question Gestion d'un cluster d'ordinateurs Linux derrière des pare-feu


Le produit de ma société est essentiellement une machine Linux (Ubuntu) installée sur le réseau de quelqu'un d'autre qui exécute notre logiciel. Jusqu'à présent, nous avions moins de 25 boîtes dans la nature et utilisions TeamViewer pour les gérer.

Nous sommes sur le point d’envoyer 1 000 boîtes et TeamViewer n’est plus une option. Mon travail consiste à trouver un moyen de accéder à ces boîtes et mettre à jour le logiciel sur celles-ci. Cette solution devrait pouvoir percer les pare-feu et ce que vous avez.

J'ai considéré:

1. Solution maison (par exemple un service Linux) qui établit une Tunnel inverse SSH sur un serveur dans le nuage et sur un autre service dans le nuage qui en assure le suivi et vous permet de vous y connecter.

Cela demande évidemment beaucoup de travail et, franchement, on a l'impression de réinventer la roue car de nombreuses autres entreprises ont déjà dû affronter ce problème. Malgré tout, je ne suis pas sûr que nous ferons un excellent travail dans ce domaine.

2. Outils tels que marionnette, chef ou OpenVPN

J'ai essayé de lire le plus possible, mais je n'arrive pas à pénétrer suffisamment dans le discours marketing pour comprendre le choix évident qui va avec.

Personne d'autre que nous n'a besoin de se connecter à ces boîtes. Y at-il quelqu'un avec une expérience pertinente qui peut me donner des indications?


18
2017-07-31 16:13


origine


"Nous ne sommes pas sur le point d'expédier" => "Nous sommes à présent sur le point d'expédier "? - Bob


Réponses:


Tirez les mises à jour, ne poussez pas

À mesure que vous progressez, cela deviendra irréalisable pousser mises à jour de tous vos produits.

  • Vous devrez suivre chaque un seul client, chacun pouvant avoir une configuration de pare-feu différente.
  • Tu devras créer entrant connexions via le pare-feu du client, ce qui nécessiterait un transfert de port ou un autre mécanisme similaire. C'est un risque de sécurité pour vos clients

Au lieu de cela, demandez à vos produits d'extraire périodiquement leurs mises à jour, puis vous pourrez augmenter la capacité côté serveur au fur et à mesure de votre croissance.

Comment?

Ce problème a déjà été résolu, comme vous l'avez suggéré. Voici plusieurs approches auxquelles je peux penser.

  • en utilisant apt: Utilisez le système apt intégré avec un PPA personnalisé et une liste de sources. Comment configurer un PPA?
    • Con: Sauf si vous utilisez un service d’hébergement public tel que le tableau de bord, configurer votre propre système de conditionnement apt PPA + n’est pas une mince affaire.
  • en utilisant ssh: Générez une clé publique SSH pour chaque produit, puis ajoutez la clé de ce périphérique à vos serveurs de mise à jour. Ensuite, juste avoir votre logiciel rsync / scp les fichiers requis.
    • Con: Vous devez suivre (et sauvegarder!) Toutes les clés publiques de chaque produit que vous envoyez.
    • Pro: Plus sécurisé qu'un téléchargement brut, car les seuls appareils pouvant accéder aux mises à jour seraient ceux avec la clé publique installée.
  • téléchargement brut + vérification de la signature:

    • Publiez un fichier de mise à jour signé quelque part (Amazon S3, serveur FTP, etc.)
    • Votre produit vérifie périodiquement le fichier de mise à jour à modifier, puis télécharge / vérifie la signature.
    • Con: Selon la façon dont vous déployez cela, les fichiers peuvent être accessibles au public (ce qui facilitera l'ingénierie inverse et le piratage de votre produit)
  • ansible: Ansible est un excellent outil pour gérer les configurations du système. C'est dans le domaine des marionnettes / chefs, mais il est sans agent (utilise du python) et conçu pour être idempotent. Si le déploiement de votre logiciel nécessite un script bash compliqué, j'utiliserais un outil comme celui-ci afin de simplifier vos mises à jour.

Bien sûr, il y a d'autres façons de le faire .. Mais cela m'amène à un point important.

Signer / valider vos mises à jour!

Peu importe ce que tu fais, c'est impératif que vous disposez d'un mécanisme pour vous assurer que votre mise à jour n'a pas été falsifiée. Un utilisateur malveillant pourrait emprunter l'identité de votre serveur de mise à jour dans l'une des configurations ci-dessus. Si vous ne validez pas votre mise à jour, votre boîte est beaucoup plus facile à pirater et à entrer.

Un bon moyen de le faire est de signer vos fichiers de mise à jour. Vous devrez conserver un certificat (ou payer quelqu'un pour le faire), mais vous pourrez installer votre empreinte digitale sur chacun de vos appareils avant de les expédier afin qu'ils puissent rejeter les mises à jour qui ont été falsifiées.

Sécurité physique

Bien entendu, si une personne a un accès physique au déploiement du client, elle pourrait facilement prendre le contrôle du serveur. Mais au moins, ils ne peuvent pas attaquer les autres déploiements! La sécurité physique est probablement la responsabilité de votre client.

Si vous le voulez bien, imaginez ce qui se passerait si vous utilisiez un   grand réseau OpenVPN pour les mises à jour ... Ils pourraient alors utiliser le   serveur compromis pour attaquer chaque instance sur le VPN

Sécurité

Quoi que vous fassiez, la sécurité doit être construit en Depuis le début. Ne faites pas de compromis ici - vous le regretterez si vous le faites.

La sécurisation complète de ce système de mise à jour est hors de portée de cet article et je vous recommande vivement de faire appel à un consultant si vous-même ou un membre de votre équipe ne connaissez pas bien ce domaine. Cela vaut chaque centime.


23
2017-07-31 22:13



En second lieu, j'appliquerais Ansible - il est moyennement complexe entre les scripts shell et la gestion complète de la configuration de style Puppet / Chef, et a la sophistication de faire des choses plus complexes que de simplement mettre à jour le logiciel (comme l'indique la question " gérer"). - RichVel
Si vous utilisez Ansible, vous pouvez l'écrire pour qu'il s'exécute sur «localhost». Il ne nécessite pas d'accès SSH à aucune des machines gérées. Configurez-le pour qu'il soit un travail cron, et vous êtes en or. - BobTuckerman
BTW: Si vous voulez exécuter votre propre serveur de paquets, fpm et aptly Deux excellents outils facilitent la création et l’hébergement de vos propres packages. Je viens de passer à travers ce processus récemment, et c'était très agréable. - BobTuckerman


Avez-vous réellement besoin d'y accéder?

Ou simplement les mettre à jour? Parce que vous pouvez les faire mettre à jour eux-mêmes, de la même manière que les mises à jour d'apt sont autonomes.

Si vous avez besoin de vous connecter

Pourquoi pas un démon OpenSSH à l’écoute via le transfert de port? Chaque client peut avoir une clé distincte pour la sécurité et ne serait connecté qu'en cas de besoin.

À vos clients

Vous devez également prendre en compte ce que le client est prêt à accepter. Ils peuvent ne pas être à l'aise avec un accès distant à leur réseau, ou seulement avec des technologies / configurations spécifiques.


10
2017-07-31 16:42



ce. avec 1 000 exigences différentes de la part des clients, au moins certains ne voudront pas d’une connexion openvpn permanente à leurs bureaux. Idéalement, essayez de les faire mettre à jour eux-mêmes si / quand / quand ils détectent une nouvelle version est disponible (à partir d'un fichier dans un compartiment AWS S3, par exemple. C'est ce que nous faisons. - Sirex
@Sirex - L'un des inconvénients de l'utilisation d'un compartiment S3 est qu'il n'existe pas de liste blanche IP simple que le client peut utiliser pour verrouiller ce serveur afin qu'il ne puisse atteindre que le compartiment contenant la mise à jour. Nous avons fini par configurer un serveur de mise à jour avec une adresse IP publique statique afin que les clients puissent utiliser des filtres IP pour contrôler les interlocuteurs de ce serveur. (AWS publie tous ses blocs IP, il est donc théoriquement possible de configurer un filtre permettant uniquement l'accès aux ressources AWS, mais c'est trop large pour ce cas d'utilisation) - Johnny
Nous n'avons pas les mises à jour sur S3, mais nous avons un fichier texte qui détaille la version la plus récente - utilisé par l'application pour fournir les messages de bannière 'mise à jour disponible'. Les clients peuvent ensuite déclencher (dans notre cas manuellement) le téléchargement de la dernière version, dans notre cas à partir d’un service appelé fetchapp. - Sirex


Je suggère un outil d'orchestration comme Fantoche ou Sel.

Salt est une file d'attente de messages et peut établir une connexion sortante persistante entre votre appliance et un serveur maître. Vous pouvez utiliser cela pour exécuter des commandes arbitraires sur les appliances ... comme un apt-get.

L'autre option est Puppet, où vous avez toujours un serveur maître et où les clients établissent des connexions sortantes à partir de leurs emplacements.

J'utilise ces deux outils dans un but similaire, où je n'ai peut-être pas le contrôle administratif du pare-feu.


9
2017-07-31 17:17