Un ancien informaticien a probablement laissé quelques portes dérobées. Comment puis-je les éliminer?
J'ai commencé à travailler pour une entreprise qui a licencié un ancien informaticien pour fuite de données.
Je peux seulement dire les choses suivantes:
Nous utilisons une base de données Firebird avec une application écrite par une autre société, Proxmox, pour la virtualisation de Windows Server 2008 R2, SQL Server, le routeur Mikrotik de base cloud et quelques autres appareils Mikrotik.
Je ne suis pas sûr à 100%, mais existe-t-il un moyen rapide de vérifier s'il reste des portes dérobées, sans interrompre les processus internes et tout reformater?
Ce gars précédent était vraiment bon, ayant écrit des logiciels en C++ et C #. Je sais aussi qu'il a fait un assembleur et cracké quelques programmes dans ollydbg.
La seule façon d'être absolument certain est de nettoyer chaque système et de le réinstaller à partir de zéro. Vous devrez également auditer tous les logiciels et configurations générés localement pour vous assurer qu'ils ne contiennent pas de portes dérobées. Il s'agit d'une tâche non triviale qui s'accompagne d'un coût non trivial.
Au-delà de cela, vous ne pouvez pas vraiment faire grand-chose.
De toute évidence, pendant que vous décidez quoi faire
- Vérifier la validité de toutes les règles de pare-feu
- Vérifier la validité de tous les comptes
- Audit de la validité de tous les fichiers sudoers
- Changer tous les mots de passe et clés
mais cela ne fait qu'effleurer la surface.
Premièrement, l'objectif le plus important d'un administrateur système renvoyé est de nettoyer son passé, surtout s'il s'agit d'un départ en mauvaise position. Si une attaque contre son système précédent devait se produire, il ne gagnerait rien (en particulier pas son ancien emploi), mais il pourrait perdre beaucoup. J'ai été confronté à plusieurs reprises à des craintes similaires, mais à mon avis, elles sont largement infondées. Je pense qu'il est beaucoup plus probable que si vous lui posiez des questions, il serait très gentil et serviable pour vous (que vous devriez ensuite à votre tour mentionner à votre patron).
Considérons maintenant le cas très improbable où il veut vraiment faire quelque chose de dangereux.
Faites une archive de l'ensemble de votre réseau dans un emplacement inaccessible - pour lui - (derrière un pare-feu hors de sa responsabilité, disque dur dans une armoire verrouillée, etc.).
Dès que vous avez fait cette sauvegarde, il ne peut plus couvrir ses traces. Dans le cas d'une attaque frauduleuse, elle servira de preuve.
Vous ne pouvez jamais être sûr à 100% (sauf dans le cas d'une réinstallation de l'ensemble du réseau). Vous pouvez passer par une liste de contrôle, mais vous ne pouvez jamais être sûr d'avoir tout vérifié.
Même dans le cas où vous trouvez un trou, vous ne pouvez pas prouver qu'il y a été placé intentionnellement. Remarque, le même problème existe pour les développeurs de logiciels. Un mauvais travail n'est pas une infraction pénale et vous ne pouvez pas prouver qu'il a "oublié", par exemple, de modifier intentionnellement le mot de passe administrateur de la base de données par défaut. Ou que les utilisateurs, dont le mot de passe a été défini par lui, ont "accidentellement" obtenu les privilèges nécessaires pour se connecter à vos bases de données top secrètes.
Dans la plupart des cas, la partie la plus importante de votre système n'est pas vos systèmes d'exploitation, mais les données qui y sont gérées. C'est particulièrement le cas si ces données sont des données privées et la propriété de vos clients. Il aurait pu les voler bien avant sa dernière journée de travail, les chiffrer et les sauver dans des endroits connus de lui seul. Assurez-vous donc de vérifier également les traces qui indiquent qu'il a fait des copies de vos données avant de partir. Notez cependant que s'il l'a fait "correctement", vous ne trouverez rien.
@JonasWielicki a comparé cette question à l'une de nos questions de sécurité canoniques ( Comment gérer un serveur compromis ). Je maintiens ma réponse à cette question mais il y a une différence importante.
Dans cette question, le serveur était connu comme étant compromis. Pour autant que je comprends cette question qui n'a pas été établie dans ce cas. En tant que tel, je ne suis pas sûr que nous devons briser le lance-flammes pour l'instant.
Les gens quittent une organisation tout le temps sans que rien ne se passe, même lorsqu'ils sont partis dans de mauvaises conditions. Le simple fait d'être bon en programmation, qui est toute la "preuve" que vous nous avez montrée dans la question OP, ne signifie pas que quelqu'un est un pirate en soi, ni qu'il est susceptible de vous attaquer maintenant qu'il est parti.
Si vous êtes vraiment inquiet, je vous suggère d'embaucher une société de sécurité externe pour auditer votre système. Non seulement cela permettra, espérons-le, de découvrir les petites surprises qui pourraient avoir été laissées par l'ancien administrateur système, mais cela servira également de bonne base pour tous vos problèmes et préoccupations de sécurité à l'avenir.
La seule façon de s'assurer qu'aucune porte dérobée n'existe à coup sûr est de neutraliser le système comme vous l'avez dit.
Si ce n'est pas tout à fait possible,
- Envisagez une configuration de base sécurisée et l'analyse de la configuration actuelle en est différente.
- Vérifiez tous les programmes suid.
- Analysez tous les processus en cours.
- Effectuez une analyse des ports sur le système pour identifier les ports et services ouverts.
- Surveillez régulièrement toutes les connexions sortantes et entrantes et recherchez les connexions non fiables.
Vous devrez décider à quel point vous voulez être sûr. Le rapport coût-avantage ne va jamais disparaître de la mise en orbite.
Les gestionnaires demandent-ils des assurances ou essayez-vous simplement de faire un examen raisonnable des systèmes dont vous avez hérité?
S'il s'agit de gestionnaires, vous pouvez maintenant découvrir à quel point ils sont raisonnables. Sont-ils prêts à se contenter de "assez sûr"? Peut-être que vous pouvez suivre le gars renvoyé à son nouveau travail!
Si vous cherchez à examiner vos propres systèmes, je commencerais par configurer un système de surveillance réseau, comme snort. Recherchez le trafic inattendu, par exemple "pourquoi le système parle-t-il quotidiennement à ce serveur en Russie?" ou "pourquoi les gens font-ils IRC sur mon serveur Web?" (celui-là m'est arrivé).
Je pense que la suggestion de @ peterh de créer une grande archive est une très bonne idée. Je pense également que sa suggestion selon laquelle le type renvoyé est utile est totalement réaliste. Des problèmes comme celui-ci s'avèrent être une gestion stupide dans 90% des cas.
Vous devriez faire un audit des fonctionnalités et de l'utilisation actuelles, mais honnêtement, vous devriez recommencer à zéro.
En d'autres termes, ne vous contentez pas de "supprimer l'orbite" mais notez toutes les fonctionnalités et exigences essentielles telles que, par exemple, les ports qui doivent être ouverts sur le pare-feu pour la boîte, les restrictions d'adresse IP ou de nom d'hôte et les autres " plomberie "comme ça.
Ensuite, recréez un nouvel environnement en fonction de ce que vous avez vu, exécutez des tests pour confirmer que la fonctionnalité est la même en cas de basculement, puis planifiez la maintenance pour effectuer un basculement officiel: c'est-à-dire copier les données de l'ancienne configuration vers la nouvelle, puis activer les IP la boîte pour reprendre les anciennes adresses IP de l'ancienne boîte ou configurer d'autres systèmes qui ont besoin d'accéder pour pouvoir se connecter à la nouvelle configuration.
Mais cela dit, même si vous faites cela, vous ne pourrez peut-être pas faire confiance aux données dans la base de données, mais au moins dans un cas comme celui-ci, le système central est déplacé vers quelque chose de plus stable et "sain" afin que vous ayez un nettoyeur point de départ.
Vous avez également mentionné le précédent I.T. les gens pouvaient programmer en assembleur et en C++. Ma question serait: pourquoi? Faites donc un audit de tout code personnalisé qui pourrait exister et évaluez la fonctionnalité. Parce que tandis que les autres personnes pourraient ont été "fantaisistes" dans leurs compétences en programmation, qui sait s'ils ont programmé quelque chose en C++ qui - par exemple - peut facilement être recréé en Python = ou un script Bash/Batch. J'ai rencontré beaucoup de programmeurs C++ de nos jours qui utilisent vraiment trop le code C++ lorsque des outils plus simples peuvent être utilisés pour obtenir des fonctionnalités équivalentes.
Mais à la fin de la journée, la reconstruction de l'architecture à partir de zéro pourrait être la seule chose - et la plus sûre - à faire.
La première chose, c'est que tout le monde change son mot de passe. Deuxièmement, vous devez sécuriser le pare-feu et tout ce qui s'y connecte directement. Changez TOUS les mots de passe partout.
S'il ne parvient pas à traverser le pare-feu, il devra s'appuyer sur quelque chose établissant une connexion avec lui et rendre le retour beaucoup plus difficile.
Vous devrez tout apprendre sur le pare-feu, les règles et la configuration et les vérifier ligne par ligne pour les choses qui n'appartiennent pas. Même dans ce cas, il serait préférable d'obtenir un nouveau routeur et de transférer manuellement la configuration. Vérifier que chaque modification de la configuration est à la fois correcte, pas une porte dérobée, et qu'elle est même toujours nécessaire. C'est le moment idéal pour nettoyer la gouttière de votre système.