Get best of the week

Comment ne pas protéger vos systèmes dans le cloud

Souvent, quand je parle de vulnérabilité à quelqu'un, il me regarde comme un fou avec le signe «Repentez-vous, car la fin du monde est proche»!

Maintenant, tout le monde court dans la panique et essaie d'organiser une "télécommande", commettant des erreurs simples, collectant tous les râteaux possibles, j'ai donc décidé de partager quelques histoires dramatiques avec la participation de pirates gitans, de CVE ouverts et de devops professionnels, mais un peu naïfs. Bien sûr, j'ai dû omettre certains détails ou même les dénaturer intentionnellement, afin de ne pas déranger les clients. Pour la plupart, ce n'est pas une pratique du travail actuel chez Technoserv, mais laissez ce post être un petit mémo sur la façon de ne pas le faire, même si vous le voulez vraiment.

Comment clĂ´turer le serveur


Il y avait un serveur dans le centre de données. Une telle vieille école, fer à repasser, sans conteneurs fantaisie et virtualisation. Il y a plusieurs générations d'employés, l'un des développeurs l'a configuré «temporairement, de sorte que seuls quelques gros fichiers du projet soient acceptés». Dans le même temps, l'entreprise se souciait vraiment de la sécurité des informations, mais, comme cela arrive souvent, des collègues de l'IS sont allés répondre aux besoins de l'entreprise et se sont mis d'accord sur une option temporaire avec un accès complet à Internet.

Heureusement, le serveur était situé dans la zone grise de la DMZ et n'a pas pu se connecter directement aux services critiques du circuit interne. Le 22ème port a été défini, et à l'intérieur, ils ont juste ajouté quelques utilisateurs locaux avec des mots de passe individuels pour se connecter via ssh / sftp. L'accès par certificats a été jugé trop gênant. Ensuite, les développeurs d'un autre projet sont arrivés et ont demandé d'aider à automatiser les téléchargements réguliers à partir du serveur de la contrepartie, car «vous avez un serveur pratique avec un accès coordonné au réseau». Là encore.

Le résultat a été une situation extrêmement joyeuse lorsque le serveur, qui semblait temporaire, n'a reçu aucune mise à jour, mais un tas de processus métier y étaient déjà liés et plusieurs téraoctets de données étaient pompés par mois.

Nous avons décidé de le surveiller, car le serveur est si important, et les graphiques du processeur ont immédiatement une étagère à 100%. Ils ont bien fait de le trier: et là, un tas de processus rand au nom du test des utilisateurs suspects et un tas de mémoire qu'ils avaient mangé, et les journaux avaient une force brute continue du monde entier.

Avant de mettre le serveur dans l'oubli, ils ont poussé un bâton sur les processus: lsof a immédiatement montré les fichiers supprimés mais non fermés qui étaient toujours suspendus dans la RAM. Malheureusement, il n'était pas possible de comprendre exactement ce que faisait l'attaquant, mais le comportement ressemblait plus à une personne qu'à l'élaboration d'un script. Lors de l'examen d'un script en RAM, des insertions comme scanez clasa (numérisation d'une classe) en roumain étaient très satisfaites:

#!/bin/bash
while["1"];do
class="
#168
"
classb="`seq 1 255`"
classb2=($classb)
num_classb=${#classb2[*]}
b=${classb2[$((RANDOM%num_classb))]}
classc="`seq 1 255`"
classc2=($classc)
num_classc=${#classc2[*]}
c=${classc2[$((RANDOM%num_classc))]}
classes=($class)
num_class=${#classes[*]}
a=${classes[$((RANDOM%num_class))]}
echo "scanez clasa ${a}.${b}"
./a ${a}.${c}
done

Pour autant que je sache, rien de grave n'a coulé (ou ils ne m'en ont pas parlé) et l'attaquant n'a pas pu pénétrer dans le périmètre, mais depuis lors, la société a parlé de pirates de voleurs de chevaux gitans.

règles


  1. Ne permettez pas à des solutions temporaires pratiques mais dangereuses d'être corrigées dans l'infrastructure. Oui, je sais qu'ils sont incohérents, mais ne subissent que la quarantaine, mais acceptez simplement quand vous les supprimerez. Après combien de jours ou d'heures. Et nettoyez sans tarder. Eh bien, au moins, dites-le aux autres, s'il vous plaît. Après tout, le service exposé commence à se rompre en 20 minutes en moyenne.
  2. Ne montrez pas ssh et RDP pur à l'extérieur, il est préférable de fournir un accès via VPN ou des services de tunneling Web. Je ne sais pas pourquoi, mais pour eux, les gens sont plus responsables de l’ensemble des comptes autorisés et de leurs mots de passe.
  3. ssh — . . ssh, .
  4. - — - fail2ban, , - . «» «». , . , , , — .
  5. , : « ?» .
  6. . . , , .

IP – , firewall !


Je comprends parfaitement que NAT était une béquille nécessaire qui a gâché la vie des développeurs et ne permettait pas d'implémenter des options pour connecter rapidement les nœuds entre eux. Néanmoins, son effet secondaire de masquer la structure interne du réseau est très utile en termes de complication d'une attaque automatisée régulière. Et oui, je comprends très bien que l'option la plus correcte consiste à utiliser un pare-feu sur liste blanche pour autoriser explicitement uniquement les connexions nécessaires. Le problème est que dans le monde de l'aggaila continue sur des bagatelles telles que la configuration dure d'un pare-feu ou Dieu ne plaise SELinux n'a jamais le temps et le budget. En général, ils interfèrent avec le débogage, réduisent l'indicateur critique du délai de commercialisation et ne permettent pas aux développeurs et aux développeurs de vivre en paix.

La situation est devenue encore plus intéressante lorsque l'infrastructure cloud, déployée automatiquement à la demande, est devenue la norme de l'industrie. Le fait est que la plupart des solutions cloud supposent que la protection d'un tas de conteneurs surélevés et de machines virtuelles incombe à l'utilisateur final. En règle générale, ils vous fournissent l'infrastructure, ils attribuent des adresses IP blanches et c'est tout, essentiellement, ils fournissent un ensemble de capacités, pas des solutions toutes faites. Par défaut, tout est fermé, mais cela n'est pas pratique et empêche donc le développement. Par conséquent, ouvrons tout et nous le testerons calmement, mais en production, nous le ferons bien.

Cela conduit souvent à des cas amusants. J'ai regardé une copie légèrement piratée du célèbre serveur MMORPG. Clans, donat, discussions continues sur les mères des autres et autres joies. Tout le monde se demandait pourquoi certains personnages pompaient si vite, et généralement omnipotents. J'ai parcouru nmap à travers la plage d'adresses la plus proche du serveur de jeu.

Il s'est avéré que toute l'infrastructure, y compris le frontend, le backend et la base de données, a simplement bloqué les ports ouverts sur le monde extérieur. Et quel est le mot de passe le plus probable pour l'utilisateur sa si la base de données est accessible sur Internet? C'est vrai, sa aussi! En conséquence, la chose la plus difficile est de comprendre la structure de la table.

Une histoire similaire s'est produite avec un client qui a ouvert l'accès à distance au panneau d'administration pour une machine à domicile tout en travaillant à domicile pendant un certain temps. Naturellement, le panneau d'administration était sans autorisation, car il était considéré comme une ressource interne sécurisée. Et le client n'a pas pris la peine et vient d'ouvrir immédiatement le port pour l'ensemble d'Internet.

Et les serveurs ELK ouverts sur le monde apparaissent chaque semaine. Ce qui ne se trouve tout simplement pas dans leur contenu. À partir de données personnelles, se terminant par des numéros de carte de crédit.

règles


  1. Le pare-feu doit être sur liste blanche. En aucun cas, le backend ne doit être accessible de l'extérieur. Et n'hésitez pas à demander aux entrepreneurs et aux employés distants à partir de quelle adresse IP ils se connecteront. Au final, une IP dédiée coûte environ 150 r / mois, ce qui est un déchet réalisable pour l'opportunité de travailler à domicile.
  2. Utilisez toujours HTTPS et l'authentification complète, même s'il ne s'agit que de «machines de test».
  3. Environnements de test et de production strictement séparés. N'utilisez jamais, jamais du tout, les mêmes comptes dans les deux environnements.

Samba


Je suis particulièrement satisfait du serveur Samba, qui est traditionnellement utilisé pour organiser l’accès partagé aux ressources. Pourquoi ne pas configurer l'accès invité pour les collègues du département voisin afin d'échanger facilement des fichiers?

Dans une petite entreprise, tout s'est bien passé jusqu'à ce qu'il n'y ait plus de services. Après un certain temps, il était nécessaire de configurer l'accès aux succursales distantes. Et une solution tout à fait «raisonnable» était d'ouvrir l'accès à la samba de l'extérieur. Eh bien, tout le monde a ses propres mots de passe, qu'est-ce qui pourrait mal tourner? Personne ne se souvenait de l'accès invité jusqu'à ce qu'il se soit avéré qu'une partie tangible du disque dur était obstruée par les données de quelqu'un d'autre. Les scanners automatiques ont rapidement trouvé un stockage de fichiers gratuit, et le disque dur a commencé à se boucher rapidement avec les archives cryptées de quelqu'un d'autre. Et dans l'un des répertoires, nous avons trouvé lors de l'audit une collection de films sélectionnés pour adultes avec la participation des actrices 60+ (et il a eu de la chance que pas 18-, sinon il aurait volé des forces de l'ordre).

résultats


  1. Ne partagez jamais de stockage sans VPN.
  2. samba ftp-. , .
  3. , , - .

,


J'avais un client qui ne comprenait pas du tout pourquoi il devait dépenser des sommes supplémentaires pour la sauvegarde si tout fonctionnait pour lui. C'est cher. Et il est bien réglé. En conséquence, les employés qui ouvrent et exécutent tout ce qui leur est envoyé par la poste en toute sécurité ont détecté un virus de chiffrement. Ils ont perdu la base 1C et n'ont pu la restaurer que grâce aux archives papier et à un entrepreneur qui a une fois copié la base pour lui-même.

J'ai parlé avec le leader, expliqué les points clés qui doivent être modifiés dans l'entreprise afin d'éliminer les risques de perdre la base. Il a hoché la tête tout au long de la conversation et s'est retrouvé avec une phrase merveilleuse: «Le projectile ne frappe pas deux fois le même trou. Maintenant, il n'y a plus rien à craindre. » Il a de nouveau refusé les sauvegardes et a naturellement perdu toutes les données dans le même scénario six mois plus tard.

règles


  1. , (- ). , .
  2. . - , .
  3. . . , helpdesk.

!


D'après mon expérience, les petites et moyennes entreprises commencent généralement par une gestion entièrement manuelle des comptes utilisateurs. Je veux dire, le nouveau directeur des ventes trébuche dans la tanière des administrateurs barbus, où il reçoit solennellement un identifiant, un mot de passe et un accès. Tout cela fonctionne bien jusqu'à ce que l'entreprise commence à croître.

Voici les personnes qui ont vendu des réservoirs en composite. Ils ont récemment changé de direction et il a été décidé de procéder à un audit de sécurité complet. Ils nous ont même amenés en excursion pour montrer la production. Le spectacle est très impressionnant: dans un immense atelier, de grandes pièces ont été tournées, sur lesquelles de la fibre de verre a été enroulée, tandis que les travailleurs ont couru avec un seau de résine époxy, en l'étalant soigneusement sur la pièce.

Dans un bâtiment séparé, il y avait une aile administrative, où nous nous enterrions directement dans l'organisation de la partie information de la production. À première vue, ils avaient organisé un schéma assez logique, lorsque l'accès à la base de données clients n'était fourni que par le biais d'un compte interne en AD avec l'approbation du responsable. Lorsqu'une personne a démissionné, elle a parcouru la liste de contrôle, remis des équipements, des cartes et le compte a été désactivé. Tout cela a été fait manuellement, car les fonds pour la gestion complète de l'identité n'étaient pas alloués.

Au cours du processus d'audit, nous avons constaté qu'ils avaient mis en place un portail autoécrit il y a de nombreuses années afin que les vendeurs puissent recevoir à distance les données dont ils ont besoin sur les clients. Ils ont même commencé à migrer leur infrastructure vers le cloud, mais ils se sont finalement arrêtés à mi-chemin en raison de certaines difficultés internes. De plus, AD n'a pas pu y être intégré et les comptes ont été supprimés exactement de la même manière sur la liste de contrôle lors du licenciement. Tout semble normal, mais dans les journaux, nous avons trouvé un compte actif d'un certain Vasily, qui a été licencié il y a plusieurs années et qui travaille maintenant avec succès dans une entreprise concurrente. De plus, à en juger par les journaux, il a déchargé la quasi-totalité de la clientèle au moins une fois par mois.

Le compte a été immédiatement bloqué et ils ont commencé à voir comment une personne pouvait contourner les réglementations internes. Il s'est avéré que Vasily a d'abord accédé au portail en tant que directeur des ventes, puis a été transféré à un poste de direction directement dans l'atelier, après quoi il a quitté. Mais la liste de contrôle pour le licenciement dans l'atelier est complètement différente et la désactivation du compte du portail n'y était pas répertoriée. Bien qu'il semble, faire une liste de contrôle générale pour le contrôle d'accès dans tous les systèmes et le problème pourrait être évité.

règles


  1. Si vous avez plus de 100 employés, envisagez d'introduire un système IDM à part entière.
  2. Ignorez les données non pas de la feuille de contournement, mais directement du service du personnel. Les mises à pied sont différentes et une solution de contournement peut ne pas vous apporter.
  3. — . . , « , », , ( , , . .).
  4. « », - .
  5. . .
  6. . , — . .

?


Pour une raison quelconque, la sécurité de l'information est traditionnellement perçue comme des individus hostiles qui courent après tout le monde avec leurs réglementations ennuyeuses et interfèrent avec leur travail. En fait, pour tous les exemples grotesques ci-dessus, ils se trouvent assez souvent dans des cas réels, et ce sont les agents de sécurité et les administrateurs paranoïaques qui aident à les éviter.

Essayez simplement de trouver une langue commune. Tout d'abord, les employés de l'EI eux-mêmes ne devraient pas devenir des gardiens qui ne s'engagent qu'à faire du cerveau une politique de mot de passe régulière sans explication. La bonne approche consiste à rencontrer des développeurs et des développeurs, à plonger dans leurs problèmes. Ensuite, développez la bonne option de compromis, qui non seulement ne brillera pas avec un accès sans mot de passe au monde extérieur, mais sera également pratique à utiliser.

Et les devops veulent parfois ĂŞtre au moins un peu paranoĂŻaques.
Le texte a été préparé par Vladimir Chikin, responsable des technologies de l'information chez Technoserv Cloud .

More articles:


All Articles