Comment recherchez-vous les portes dérobées de l'informaticien précédent?
Nous savons tous que cela se produit. Un vieil homme informatique amer laisse un backdoor dans le système et le réseau afin de s'amuser avec les nouveaux gars et montrer à l'entreprise à quel point les choses vont mal sans lui.
Je n'ai jamais personnellement vécu cela. Le plus que j'ai connu, c'est quelqu'un qui a cassé et volé des trucs juste avant de partir. Je suis sûr que cela arrive, cependant.
Ainsi, lors de la prise en charge d'un réseau auquel on ne peut pas vraiment faire confiance, quelles mesures devraient être prises pour s'assurer que tout est sûr et sécurisé?
C'est vraiment, vraiment, vraiment dur. Cela nécessite un audit très complet. Si vous êtes très sûr que la personne âgée a laissé quelque chose derrière elle qui va exploser ou qu'elle a besoin d'être réembauchée parce qu'elle est la seule à pouvoir éteindre un incendie, alors il est temps de supposer que vous avez été enraciné par un partie hostile. Traitez-le comme un groupe de pirates est venu et a volé des trucs, et vous devez nettoyer après leur désordre. Parce que c'est ça.
- Auditez chaque compte sur chaque système pour vous assurer qu'il est associé à une entité spécifique.
- Les comptes qui semblent associés à des systèmes mais que personne ne peut justifier doivent être méfiants.
- Les comptes qui ne sont associés à rien doivent être purgés (cela doit être fait de toute façon, mais c'est particulièrement important dans ce cas)
- Modifiez tous les mots de passe avec lesquels ils auraient pu entrer en contact.
- Cela peut être un vrai problème pour les comptes utilitaires car ces mots de passe ont tendance à être codés en dur dans les choses.
- S'ils étaient du type helpdesk répondant aux appels des utilisateurs finaux, supposons qu'ils disposent du mot de passe de toute personne qu'ils ont aidée.
- S'ils avaient l'administrateur d'entreprise ou l'administrateur de domaine vers Active Directory, supposons qu'ils aient récupéré une copie des hachages de mot de passe avant de partir. Ceux-ci peuvent être résolus si rapidement maintenant qu'un changement de mot de passe à l'échelle de l'entreprise devra être forcé en quelques jours.
- S'ils avaient un accès root à n'importe quelle boîte * nix, supposons qu'ils soient partis avec les hachages de mot de passe.
- Examinez toute l'utilisation des clés SSH à clé publique pour vous assurer que leurs clés sont purgées et vérifiez si des clés privées ont été exposées pendant que vous y êtes.
- S'ils avaient accès à un équipement de télécommunications, modifiez les mots de passe du routeur/commutateur/passerelle/PBX. Cela peut être une douleur vraiment royale car cela peut entraîner des pannes importantes.
- Audit complet de vos dispositions de sécurité de périmètre.
- Assurez-vous que tous les trous du pare-feu sont tracés jusqu'aux périphériques et ports autorisés connus.
- Assurez-vous que toutes les méthodes d'accès à distance (VPN, SSH, BlackBerry, ActiveSync, Citrix, SMTP, IMAP, WebMail, peu importe) n'ont pas d'authentification supplémentaire, et examinez-les entièrement pour les méthodes d'accès non autorisées.
- Assurez-vous que les liens à distance WAN liens vers les personnes pleinement employées et vérifiez-le. Surtout les connexions sans fil. Vous ne voulez pas qu'ils partent avec un modem cellulaire ou un téléphone intelligent payé par l'entreprise. Contactez tous ces les utilisateurs pour s'assurer qu'ils ont le bon appareil.
- Audit complet des dispositions internes d'accès privilégié. Ce sont des choses comme l'accès SSH/VNC/RDP/DRAC/iLO/IMPI à des serveurs que les utilisateurs généraux n'ont pas, ou tout accès à des systèmes sensibles comme la paie.
- Collaborez avec tous les fournisseurs et prestataires de services externes pour vous assurer que les contacts sont corrects.
- Assurez-vous qu'ils sont supprimés de toutes les listes de contacts et de services. Cela devrait être fait de toute façon après tout départ, mais c'est extrêmement important maintenant.
- Valider que tous les contacts sont légitimes et avoir des informations de contact correctes, c'est pour trouver des fantômes qui peuvent se faire passer pour.
- Commencez à chasser les bombes logiques.
- Vérifiez toutes les automatisations (planificateurs de tâches, tâches cron, listes d'appels UPS ou tout ce qui s'exécute selon un calendrier ou est déclenché par un événement) pour détecter des signes de mal. Par "tout", je veux dire tout. Vérifiez chaque crontab unique. Vérifiez chaque action automatisée unique dans votre système de surveillance, y compris les sondes elles-mêmes. Vérifiez chaque planificateur de tâches Windows; même des postes de travail. À moins que vous ne travailliez pour le gouvernement dans un domaine très sensible, vous ne pourrez pas vous permettre "tout", faites autant que vous le pouvez.
- Validez les binaires clés du système sur chaque serveur pour vous assurer qu'ils sont ce qu'ils devraient être. C'est délicat, en particulier sous Windows, et presque impossible à faire rétroactivement sur des systèmes ponctuels.
- Commencez à chasser les rootkits. Par définition, ils sont difficiles à trouver, mais il existe des scanners pour cela.
Pas facile du tout, même pas à distance. Justifier les dépenses de tout cela peut être très difficile sans une preuve définitive que l'administrateur maintenant ex-était en fait mauvais. L'intégralité de ce qui précède n'est même pas réalisable avec les actifs de l'entreprise, ce qui nécessitera l'embauche de consultants en sécurité pour effectuer une partie de ce travail.
Si un mal réel est détecté, en particulier si le mal est dans une sorte de logiciel, des professionnels de la sécurité qualifiés sont les meilleurs pour déterminer l'ampleur du problème. C'est également le moment où une affaire pénale peut commencer à être construite, et vous voulez vraiment que des personnes formées à la gestion des preuves fassent cette analyse.
Mais, vraiment, jusqu'où devez-vous aller? C'est là que gestion des risques entre en jeu. Simplement, il s'agit de la méthode pour équilibrer le risque attendu et la perte. Les administrateurs système le font lorsque nous décidons quel emplacement hors site nous voulons placer des sauvegardes; coffre-fort bancaire vs centre de données hors région. Déterminer quelle part de cette liste doit suivre est un exercice de gestion des risques.
Dans ce cas, l'évaluation commencera par quelques éléments:
- Le niveau de compétence attendu du défunt
- L'accès des défunts
- L'attente que le mal a été fait
- Les dommages potentiels de tout mal
- Exigences réglementaires pour signaler le mal perpétré contre le mal trouvé de manière préventive. En règle générale, vous devez signaler le premier, mais pas le dernier.
La décision de savoir jusqu'où plonger dans le lapin ci-dessus dépendra des réponses à ces questions. Pour les départs administratifs de routine où l'attente du mal est très faible, le cirque complet n'est pas requis; changer les mots de passe au niveau administrateur et retaper les hôtes SSH externes est probablement suffisant. Encore une fois, la posture de sécurité de gestion des risques de l'entreprise détermine cela.
Pour les admins licenciés pour cause, ou le mal apparu après leur départ normal, le cirque devient plus nécessaire. Le pire des cas est un type BOFH paranoïaque qui a été informé que sa position sera licenciée dans 2 semaines, car cela lui laisse suffisamment de temps pour se préparer; dans des circonstances comme celles-ci l'idée de Kyle d'un programme d'indemnisation généreux peut atténuer toutes sortes de problèmes. Même les paranoïdes peuvent pardonner beaucoup de péchés après l'arrivée d'un chèque de 4 mois de salaire. Ce chèque coûtera probablement moins que le coût des consultants en sécurité nécessaires pour dénicher leur mal.
Mais en fin de compte, cela revient au coût de déterminer si le mal a été fait par rapport au coût potentiel de tout mal réellement fait.
Je dirais que c'est un équilibre entre votre inquiétude et l'argent que vous êtes prêt à payer.
Très inquiet:
. Si cette personne était particulièrement intelligente, vous pourriez avoir des ennuis, elle pourrait avoir quelque chose qui restera en sommeil pendant un certain temps. L'autre option consiste à tout simplement reconstruire tout. Cela peut sembler très excessif, mais vous apprendrez bien l'environnement et vous réaliserez également un projet de reprise après sinistre.
légèrement préoccupé:
Si vous n'êtes que légèrement inquiet, vous pourriez simplement vouloir faire:
- Une analyse de port de l'extérieur.
- Analyse de virus/spyware. Analyse Rootkit pour les machines Linux.
- Examinez la configuration du pare-feu pour tout ce que vous ne comprenez pas.
- Modifiez tous les mots de passe et recherchez tous les comptes inconnus (assurez-vous qu'ils n'ont pas activé quelqu'un qui n'est plus avec la société afin qu'ils puissent l'utiliser, etc.).
- Cela pourrait également être un bon moment pour étudier l'installation d'un système de détection d'intrusion (IDS).
- Regardez les journaux de plus près que d'habitude.
Pour l'avenir:
Aller de l'avant quand un administrateur part lui faire une belle fête, puis quand il a bu, offrez-lui de rentrer chez lui - puis jetez-le dans la rivière, le marais ou le lac le plus proche. Plus sérieusement, c'est l'une des bonnes raisons d'accorder aux administrateurs une indemnité de départ généreuse. Vous voulez qu'ils se sentent bien de partir autant que possible. Même s'ils ne devraient pas se sentir bien, qui s'en soucie?, Aspirer et les rendre heureux. Imaginez que c'est votre faute et non la leur. Le coût d'une augmentation des coûts de l'assurance-chômage et des indemnités de départ ne se compare pas aux dommages qu'ils pourraient causer. Il s'agit de la voie de la moindre résistance et de la création du moins de drame possible.
N'oubliez pas les goûts de Teamviewer, LogmeIn, etc ... Je sais que cela a déjà été mentionné, mais un audit logiciel (de nombreuses applications) de chaque serveur/poste de travail ne nuirait pas, y compris les analyses de sous-réseau avec nmap. Scripts NSE.
Tout d'abord - obtenez une sauvegarde de tout sur le stockage hors site (par exemple, une bande ou un disque dur que vous déconnectez et stockez). De cette façon, si quelque chose de malveillant se produit, vous pourrez peut-être récupérer un peu.
Ensuite, passez en revue vos règles de pare-feu. Tout port ouvert suspect doit être fermé. S'il y a une porte dérobée, empêcher son accès serait une bonne chose.
Comptes d'utilisateurs - recherchez votre utilisateur mécontent et assurez-vous que son accès est supprimé dès que possible. S'il existe des clés SSH, des fichiers/etc/passwd ou des entrées LDAP, même des fichiers .htaccess, tous doivent être analysés.
Sur vos serveurs importants, recherchez des applications et des ports d'écoute actifs. Assurez-vous que les processus en cours d'exécution qui leur sont attachés semblent raisonnables.
En fin de compte, un employé mécontent déterminé peut tout faire - après tout, il connaît tous les systèmes internes. On espère qu'ils ont l'intégrité de ne pas prendre de mesures négatives.
Une infrastructure bien gérée aura les outils, la surveillance et les contrôles en place pour éviter cela en grande partie. Ceux-ci inclus:
- Segmentation appropriée du réseau et pare-feu
- IDS basé sur l'hôte
- IDS basé sur le réseau
- Journalisation centrale
- Contrôle d'accès
- Le contrôle des changements
Si ces outils sont en place correctement, vous aurez une piste d'audit. Sinon, vous devrez effectuer un test de pénétration complet .
La première étape serait de vérifier tous les accès et de modifier tous les mots de passe. Concentrez-vous sur l'accès externe et les points d'entrée potentiels - c'est là que votre temps est le mieux dépensé. Si l'empreinte externe n'est pas justifiée, supprimez-la ou réduisez-la. Cela vous donnera le temps de vous concentrer sur plus de détails en interne. Soyez également conscient de tout le trafic sortant, car les solutions programmatiques pourraient transférer des données restreintes en externe.
En fin de compte, être un administrateur système et réseau permettra un accès complet à la plupart, sinon à toutes les choses. Avec cela, vient un degré élevé de responsabilité. L'embauche avec ce niveau de responsabilité ne doit pas être prise à la légère et des mesures doivent être prises pour minimiser les risques dès le départ. Si un professionnel est embauché, quitte même en mauvais termes, il ne prendrait aucune mesure qui serait non professionnelle ou illégale.
Il existe de nombreux articles détaillés sur Server Fault qui couvrent l'audit du système approprié pour la sécurité ainsi que ce qu'il faut faire en cas de résiliation de quelqu'un. Cette situation n'est pas unique à celles-ci.
Un BOFH intelligent pourrait faire l'une des choses suivantes:
Programme périodique qui initie une connexion sortante netcat sur un port bien connu pour prendre des commandes. Par exemple. Port 80. S'il est bien fait, le trafic aller-retour aurait l'apparence du trafic pour ce port. Donc, si sur le port 80, il aurait des en-têtes HTTP et la charge utile serait des morceaux intégrés dans les images.
Commande apériodique qui recherche dans des endroits spécifiques les fichiers à exécuter. Les emplacements peuvent se trouver sur les ordinateurs des utilisateurs, les ordinateurs du réseau, les tables supplémentaires dans les bases de données, les répertoires de fichiers spoule temporaires.
Programmes qui vérifient si une ou plusieurs des autres portes dérobées sont toujours en place. Si ce n'est pas le cas, une variante est installée et les détails sont envoyés par courrier électronique au BOFH
Étant donné que la plupart des sauvegardes sont désormais effectuées avec le disque, modifiez les sauvegardes pour qu'elles contiennent au moins certains de vos kits racine.
Façons de vous protéger de ce genre de chose:
Lorsqu'un employé de la classe BOFH part, installez une nouvelle boîte dans la DMZ. Il obtient une copie de tout le trafic passant par le pare-feu. Recherchez des anomalies dans ce trafic. Ce dernier n'est pas trivial, surtout si le BOFH est bon pour imiter les modèles de trafic normaux.
Rétablissez vos serveurs afin que les fichiers binaires critiques soient stockés sur des supports en lecture seule. Autrement dit, si vous souhaitez modifier/bin/ps, vous devez vous rendre sur la machine, déplacer physiquement un commutateur de RO vers RW, redémarrer un seul utilisateur, remonter cette partition rw, installer votre nouvelle copie de ps, sync, reboot, toggle switch. Un système fait de cette façon a au moins quelques programmes de confiance et un noyau de confiance pour faire d'autres travaux.
Bien sûr, si vous utilisez des fenêtres, vous êtes arrosé.
- Compartimentez votre infrastructure. Pas raisonnable avec les petites et moyennes entreprises.
Façons d'empêcher ce genre de chose.
Examiner soigneusement les candidats.
Découvrez si ces personnes sont mécontentes et résolvez les problèmes de personnel à l'avance.
Lorsque vous renvoyez un administrateur avec ces sortes de pouvoirs, adoucissez le gâteau:
une. Son salaire ou une fraction de son salaire continue pendant une période de temps ou jusqu'à ce qu'il y ait un changement majeur dans le comportement du système qui n'est pas expliqué par le personnel informatique. Cela pourrait être sur une décroissance exponentielle. Par exemple. il reçoit un salaire complet pendant 6 mois, 80% de celui-ci pendant 6 mois, 80% de que pour les 6 prochains mois.
b. Une partie de son salaire prend la forme d'options d'achat d'actions qui ne prennent effet qu'un à cinq ans après son départ. Ces options ne sont pas supprimées lorsqu'il part. Il est incité à s'assurer que l'entreprise fonctionnera bien dans 5 ans.
Il me semble que le problème existe avant même le départ de l'administrateur. C'est juste que l'on remarque le problème plus à ce moment-là.
-> Il faut un processus pour auditer chaque changement, et une partie du processus est que les changements ne sont appliqués qu'à travers lui.
Assurez-vous de prévenir tout le monde dans l'entreprise une fois qu'il est parti. Cela éliminera le vecteur d'attaque d'ingénierie sociale. Si l'entreprise est grande, assurez-vous que les personnes qui ont besoin de savoir le savent.
Si l'administrateur était également responsable du code écrit (site Web de l'entreprise, etc.), vous devrez également effectuer un audit de code.
Il y en a un gros que tout le monde a laissé de côté.
N'oubliez pas qu'il n'y a pas que des systèmes.
- Les vendeurs savent-ils que cette personne ne fait pas partie du personnel et ne devrait pas être autorisée à y accéder (colo, telco)
- Existe-t-il des services hébergés externes qui peuvent avoir des mots de passe distincts (échange, crm)
- Pourraient-ils avoir du matériel de chantage de toute façon (d'accord, cela commence à atteindre un peu ...)
Vérifiez les journaux sur vos serveurs (et les ordinateurs sur lesquels ils travaillent directement). Recherchez non seulement leur compte, mais également les comptes qui ne sont pas des administrateurs connus. Recherchez des trous dans vos journaux. Si un journal des événements a été effacé récemment sur un serveur, il est suspect.
Vérifiez la date de modification sur les fichiers de vos serveurs Web. Exécutez un script rapide pour répertorier tous les fichiers récemment modifiés et les consulter.
Vérifiez la dernière date de mise à jour de toutes vos stratégies de groupe et objets utilisateur dans AD.
Vérifiez que toutes vos sauvegardes fonctionnent et que les sauvegardes existantes existent toujours.
Vérifiez que les serveurs sur lesquels vous exécutez les services de cliché instantané des volumes manquent dans l'historique précédent.
Je vois déjà beaucoup de bonnes choses répertoriées et je voulais juste ajouter ces autres choses que vous pouvez vérifier rapidement. Il vaudrait la peine de faire un examen complet de tout. Mais commençons par les endroits avec les changements les plus récents. Certaines de ces choses peuvent être vérifiées rapidement et peuvent déclencher des signaux d'alarme précoces pour vous aider.
À moins que vous ne soyez vraiment vraiment paranoïaque, ma suggestion serait simplement d'exécuter plusieurs outils de scan TCP/IP (tcpview, wirehark, etc.) pour voir s'il y a quelque chose de suspect qui tente de contacter le monde extérieur.
Modifiez les mots de passe administrateur et assurez-vous qu'il n'y a pas de comptes administrateur "supplémentaires" qui n'ont pas besoin d'être là.
N'oubliez pas non plus de modifier les mots de passe d'accès sans fil et de vérifier les paramètres de votre logiciel de sécurité (AV et pare-feu en particulier)
Fondamentalement, je dirais que si vous avez un BOFH compétent, vous êtes condamné ... il existe de nombreuses façons d'installer des bombes qui ne passeraient pas inaperçues. Et si votre entreprise est habituée à expulser "manu-militaires" ceux qui sont licenciés, assurez-vous que la bombe sera bien plantée avant la mise à pied !!!
Le meilleur moyen est de minimiser les risques d'avoir un administrateur en colère ... Évitez la "mise à pied pour une réduction des coûts" (s'il est un BOFH compétent et vicieux, les pertes que vous pourriez subir seront probablement beaucoup plus importantes que ce que vous obtiendrez la mise à pied) ... S'il a fait une erreur inacceptable, il vaut mieux lui faire corriger (non rémunéré) comme alternative à la mise à pied ... Il sera plus prudent la prochaine fois de ne pas répéter l'erreur (ce qui sera une augmentation dans sa valeur) ... Mais assurez-vous d'atteindre la bonne cible (il est courant que les personnes non compétentes avec un bon charisme rejettent leur propre faute à la compétente mais moins sociale).
Et si vous faites face à un vrai BOFH dans le pire des sens (et que ce comportement est la raison de la mise à pied), vous feriez mieux d'être prêt à réinstaller à partir de zéro tout le système avec lequel il a été en contact (ce qui signifie probablement chaque ordinateur).
N'oubliez pas qu'un simple changement de bit peut faire des ravages dans tout le système ... (bit setuid, Jump if Carry to Jump if No Carry, ...) et que même les outils de compilation peuvent avoir été compromis.
Je vous suggère de commencer par le périmètre. Vérifiez que vos configurations de pare-feu s'assurent que vous n'avez pas de points d'entrée inattendus dans le réseau. Assurez-vous que le réseau est physiquement sécurisé contre toute nouvelle entrée et accès à tous les ordinateurs.
Vérifiez que vous disposez de sauvegardes pleinement opérationnelles et restaurables. De bonnes sauvegardes vous empêcheront de perdre des données s'il fait quelque chose de destructeur.
Vérifier tous les services autorisés à travers le périmètre et vous assurer que l'accès lui a été refusé. Assurez-vous que ces systèmes disposent de bons mécanismes de journalisation.
Bonne chance s'il sait vraiment quelque chose et a mis en place quoi que ce soit à l'avance. Même un dimwit peut appeler/envoyer par e-mail/faxer le telco avec des déconnexions ou même leur demander d'exécuter des modèles de test complets sur les circuits pendant la journée.
Sérieusement, montrer un peu d'amour et quelques mille dollars au départ réduit vraiment le risque.
Oh oui, au cas où ils appellent pour "obtenir un mot de passe ou quelque chose", rappelez-leur votre taux de 1099 et les 1 heure min et 100 frais de déplacement par appel, peu importe si vous devez être n'importe où ...
Hé, c'est la même chose que mes bagages! 1,2,3,4!
Brûlez-le ... brûlez tout.
C'est le seul moyen d'en être sûr.
Ensuite, gravez tous vos intérêts externes, les registraires de domaine, les fournisseurs de paiement par carte de crédit.
À la réflexion, il est peut-être plus facile de demander à n'importe quel compagnon de Bikie de convaincre l'individu qu'il est plus sain pour lui de ne pas vous déranger.
Supprimez tout, recommencez;)
Vraisemblablement, un administrateur compétent quelque part en cours de route a fait ce qu'on appelle une SAUVEGARDE de la configuration du système de base. Il serait également prudent de supposer que des sauvegardes sont effectuées avec un certain niveau de fréquence raisonnable permettant de restaurer une sauvegarde sûre connue.
Étant donné que certaines choses faire changent, c'est une bonne idée d'exécuter à partir de votre sauvegarde virtualisée si possible jusqu'à ce que vous puissiez vous assurer que l'installation principale n'est pas compromise.
En supposant que le pire devient évident, vous fusionnez ce que vous êtes en mesure de faire et saisissez manuellement le reste.
Je suis choqué que personne n'ait mentionné avoir utilisé une sauvegarde sûre avant moi. Cela signifie-t-il que je devrais soumettre mon CV à vos services RH?
Essayez de prendre son point de vue.
Vous connaissez votre système et ce qu'il fait. Ainsi, vous pourriez essayer d'imaginer ce qui pourrait être inventé pour se connecter de l'extérieur, même lorsque vous n'êtes plus administrateur système ...
Selon la façon dont l'infrastructure réseau et le fonctionnement de tout cela, vous êtes la meilleure personne qui peut savoir quoi faire et où cela pourrait se trouver.
Mais comme vous semblez parler d'un bofh expérimenté , vous devez chercher près de partout ...
Suivi du réseau
Comme l'objectif principal est de prendre à distance le contrôle de votre système, à travers votre connexion Internet, vous pouvez regarder (même remplacer car cela pourrait être corrompu aussi !!) le pare-feu et essayer d'identifier chacun connexion active.
Le remplacement du pare-feu n'assurera pas une protection complète mais veillera à ce que rien ne reste caché. Donc, si vous surveillez les paquets transmis par le pare-feu, vous devez tout voir, y compris le trafic indésirable.
Vous pouvez utiliser tcpdump pour tout suivre (comme le fait US paranoïaque;) et parcourir le fichier de vidage avec un outil avancé comme wireshark. Prenez un peu de temps pour voir ce que cette commande (besoin de 100 Go d'espace libre sur le disque):
tcpdump -i eth0 -s 0 -C 100 -w tcpdump- -W 1000 >tcpdump.log 2>tcpdump.err </dev/null &
Ne fais pas confiance à tout
Même si vous trouvez quelque chose, vous ne serez pas sûr d'avoir été trouvé de mauvaises choses!
Enfin, vous ne serez pas vraiment silencieux avant d'avoir été réinstallé tout (à partir de sources fiables!)
Si vous ne pouvez pas refaire le serveur, la meilleure chose à faire est probablement de verrouiller vos pare-feu autant que possible. Suivez chaque connexion entrante possible et assurez-vous qu'elle est réduite au minimum absolu.
Modifiez tous les mots de passe.
Remplacez toutes les clés ssh.
Généralement c'est assez dur ...
mais si c'est un site Web, regardez le code juste derrière le bouton de connexion.
Nous avons trouvé une chose de type "si username = 'admin'" une fois ...
Essentiellement, faites en sorte que la connaissance des informaticiens précédents soit sans valeur.
Changez tout ce que vous pouvez changer sans impact sur l'infrastructure informatique.
Changer ou diversifier ses fournisseurs est une autre bonne pratique.