Question Debian - Système sécurisé de l'administrateur actuel


Je suis l'administrateur de réseaux et de systèmes dans une organisation comptant un peu moins de 500 utilisateurs. Nous avons plusieurs serveurs Windows, et c'est certainement mon domaine d'expertise.

Nous avons également une très petite poignée de serveurs Debian.

Nous sommes sur le point de mettre fin à l'administrateur système de ces systèmes Debian.

Faute de mettre les systèmes hors tension, j'aimerais savoir comment je peux m'assurer que le précédent administrateur n'en aura plus le contrôle, à moins que nous n'embauchions un administrateur système de remplacement sous Linux.

J'ai un accès physique / virtuel à chacun des systèmes, ce qui me permet de les redémarrer dans différents modes utilisateur. Je ne sais juste pas quoi faire.

Veuillez supposer que je n'ai actuellement pas d'accès root à tout de ces systèmes (un oubli de ma part que je reconnais maintenant.)

J'ai de l'expérience dans Linux et je l'utilise quotidiennement sur mon bureau, mais je dois admettre que je suis compétent utilisateur de linux, pas un administrateur système.

Je n'ai pas peur de la ligne de commande cependant ...

Existe-t-il une liste de mesures à prendre pour "sécuriser" un système de quelqu'un d'autre?

Encore une fois, je vous assure que cela est légitime, je reprends le contrôle des systèmes de mon employeur, à la demande de mon employeur.

J'espère ne pas avoir à fermer les systèmes de manière permanente et à être raisonnablement certains qu'ils sont sécurisés.


6
2018-04-01 14:04


origine


Ces systèmes sont-ils accessibles de l'extérieur du réseau de l'entreprise? Sinon, le simple fait de s'assurer que ses identifiants VPN sont révoqués devrait suffire à le tenir à l'écart du système. - 3dinfluence


Réponses:


Cette réponse vise principalement à tirer parti des avantages liés au maintien adéquat des accès au sein de votre service informatique.

Votre situation illustre les avantages d’une piste d’audit et d’un contrôle d’accès approprié. Par exemple, tout accès nécessiterait un ticket de demande d'accès avec approbation, sans exception. En cas de résiliation, vous auditez le système de tickets.

Pour les rôles communs au sein de votre entreprise, l'accès peut être normalisé et encore plus facile à éliminer.

Pour les rôles informatiques, nous avons un tableur sur lequel nous travaillons pour les terminaisons. Il répertorie tout pour empêcher la surveillance. Nous auditons également nos tickets de demande d'accès et notre système de journalisation des travaux, car toutes les modifications de production y sont documentées.

Les administrateurs doivent également avoir des comptes d'utilisateur individuels, qu'ils utilisent pour accéder aux privilèges d'administration. Les comptes root et administratifs ne doivent pas être authentifiés directement. Bien que cela ne soit pas techniquement infaillible, cela permet une piste d'audit ainsi que la responsabilité individuelle. Avec cela, verrouiller tous ses comptes serait une première étape, puis vous modifieriez tous les comptes d’administrateur.

Si vous ne l'avez pas déjà fait, je vous encouragerais à mettre en œuvre certaines de ces solutions, voire toutes. Je les considère comme faisant partie intégrante et cela réduit les risques en cas de résiliation involontaire.

Tout d’abord, supprimez tous les accès extérieurs. Tout accès que la personne pourrait utiliser sans être sur les lieux. Ensuite, changez tous les mots de passe. Chaque mot de passe administrateur, chaque mot de passe système, chaque mot de passe d'application, chaque mot de passe de compte fournisseur, chaque mot de passe de compte d'assistance - tout. Si le risque de représailles est grand, vous pouvez également supprimer les mots de passe de tous les employés.

Comme vous ne disposez pas des mots de passe root sur les serveurs Linux, vous pouvez démarrer en mode mono-utilisateur et le modifier. Avec VER et LILO, vous voudriez simplement annexer single. Les méthodes sont similaires.

Comme d'autres l'ont recommandé, auditez tous les crontabs (situés dans / var / spool / cron), les utilisateurs du système, les démons en cours d'exécution, les paires de clés ssh et les systèmes en général.

Bien que la reconstruction soit le seul moyen d’en être certain, elle ne devrait pas être nécessaire dans la plupart des cas. Tout professionnel respectueux ne risquerait pas sa carrière sur une telle réaction gutturale. Cela permettrait également à votre employeur d'engager des poursuites à la fois pénales et civiles. En fin de compte, je suggérerais de discuter sérieusement des risques avec votre responsable après avoir procédé à une vérification préalable avec élimination.


5
2018-04-01 16:24



C'est excellent et c'est exactement la leçon que j'apprends ici. Je laisse ce gars construire ces boîtes et les mettre dans une position sur laquelle nous nous appuyons maintenant. Ceci est entièrement mon échec.
Oh, la personne qui le résilie pourrait toujours demander les mots de passe aussi. ;) La plupart des gens raisonnables leur fourniraient. - Warner
Cela sera fait, mais j'espère qu'il ne sera pas entièrement disponible


Vous pouvez redémarrer les systèmes Debian en mode utilisateur unique et modifier le mot de passe du compte root, mais vous devrez également vous assurer qu'il n'y a pas d'autres utilisateurs disposant d'un accès SSH auxquels l'administrateur sys a accès.

Tous les mots de passe FTP ou MySQL doivent également être modifiés. Vous pouvez également commencer à vérifier les services et les tâches cron et vous assurer que chaque programme en cours d'exécution est censé s'exécuter.

Le chemin le plus sûr et le plus rapide serait de sauvegarder vos données et de réinstaller les serveurs, bien que cela dépende de l'acceptation du temps d'arrêt que cela crée.


3
2018-04-01 14:10



Le temps d'arrêt serait sûrement prolongé. Ces systèmes fournissent principalement une intégration entre d’autres systèmes ... et je ne suis pas sûr d’avoir l’expertise nécessaire pour recréer le travail actuel de l’administrateur système. Merci pour la suggestion cependant, il se peut que je doive suivre cette voie.
Recherchez également les clés ssh, car elles contourneront les mots de passe masqués. - Scott Pack


Supprimez les clés ssh unkonwn de /root/.ssh/authorized_keys et recherchez si d’autres utilisateurs ont des utilisateurs inconnus dans leur fichier allowed_keys.


2
2018-04-01 14:58





Base deux semaines de congé payer sur le mot de passe root!


1
2018-04-01 20:55