Comment nous chez RUVDS sauvons nos utilisateurs de la force brute





Dans l'un des articles, j'ai parlé de la façon dont le script kiddy interfère avec la vie de nos clients. Dans cet article, je voudrais parler de solutions: comment nous allons essayer de les gérer.



Jusqu'à présent, sans codes sources complets, ils figureront dans les prochains articles. En attendant, plutôt sur la stratégie et les tactiques de défense.



«Solutions» standards



Envoyer des plaintes



Une approche très courante. Si une intrusion dans votre SI est détectée, ajoutez l'attaquant au pare-feu (ou non) et envoyez une plainte automatique par mail, qui a été trouvée dans le whois.

Nous recevons des plaintes concernant nos clients du système de détection d'intrusion de diverses banques, bureaux, sites Web. Même, semble-t-il, les grandes organisations lancent simplement fail2ban et c'est tout.

Tout fonctionnera une fois sur deux, et si l'attaquant n'est pas banni? Oui, et il est faux de donner la possibilité de frapper à votre porte, que se passe-t-il si quelqu'un définit le mot de passe de niveau solarwinds123 et est piraté du premier coup?



Forcer les utilisateurs à faire ce qu'il faut.



Vous pouvez créer votre propre service, presque un malware, comme l'a fait Godaddy, ajouter un autre utilisateur sous la connexion nydys et oublier de désactiver l'administrateur cloud-init, comme l'a fait Godaddy, installer 8 certificats supplémentaires dans le système, comme l'a fait Godaddy.

Vous pouvez également bloquer AD et d'autres "ports non sécurisés", comme certains autres hébergements l'ont fait, et c'est tout.



Vous pouvez exécuter vos robots d'exploration et analyser vos propres réseaux. Analysez les ports, trouvez des services vulnérables ou essayez même de pénétrer vos propres clients sous les mots de passe les plus fréquemment piratés.



Cela aidera vraiment à quelque chose, mais ce qui et comment doit être organisé sur les serveurs de l'utilisateur doit être décidé par l'utilisateur. De plus, si vous faites tout cela, comme on dit, à une échelle, alors nous tomberons sur une propagation dans le savvy technique des utilisateurs et un malentendu, "Eh bien, qu'ai-je fait?!" et "Je ne suis pas un programmeur!", mais tout le monde doit être en sécurité.



Gérez la sécurité



Tout ce qui précède est très cool et peut être utile. Mais les utilisateurs doivent être protégés. Surtout les débutants. Les serveurs virtuels sont souvent utilisés comme un terrain d'expérimentation, une plate-forme pour se familiariser avec les systèmes de serveur, et parfois les utilisateurs se trompent.



Nous avons discuté avec les propriétaires des machines compromises, leur avons demandé de dire honnêtement quel mot de passe a été défini et, malheureusement, les identifiants et les mots de passe du test: test ou niveau 111: 111, c'est encore une pratique courante.



Les utilisateurs de Linux empirent, ils ne sont pas aussi disposés à contacter que les utilisateurs de Windows, même si, à en juger par le nombre de plaintes concernant les serveurs Linux, ils sont plus souvent piratés ou utilisés par des cybercriminels.



Il est clair que tout le monde ne perd pas ses politiques et définit les mots de passe du niveau "12345678" à la racine, mais cela arrive régulièrement, vous devriez donc essayer.



Architecture



Simple comme un dormeur. Voici une image:







  1. Le serveur d'interruption collecte des statistiques pendant 1 heure et envoie les données collectées à la base de données.
  2. Le serveur du juge recueille les données de la base de données et prend des décisions sur les interdictions. Les interdictions sont également enregistrées pour les antécédents médicaux de chaque adresse IP spécifique.
  3. Le serveur BGP analyse la liste d'interdiction générée et transmet cette liste en tant que flux BGP aux routeurs.


À partir des serveurs de traps, les données sont envoyées dans le même format par le même «Get-Bruteforce» que nous avons proposé précédemment, à savoir:



  1. Nombre de tentatives de piratage
  2. Logins utilisés
  3. adresse IP
  4. Enregistrement PTR


Comment les décisions sont pesées



Nous parlons d'une solution potentiellement de combat, par conséquent, il est impossible d'interdire tout le monde d'affilée. Il est nécessaire d'introduire des critères discrets et compréhensibles afin de savoir clairement comment, quoi et pourquoi.

Pour le moment, 6 facteurs sont pris en compte:



  1. Combien de fois l'attaquant a-t-il tenté de s'introduire
  2. Combien d'appâts différents at-il frappé
  3. L'adresse IP est-elle statique
  4. L'adresse IP appartient-elle à l'hébergement ou au fournisseur domestique
  5. L'attaquant a-t-il utilisé de «mauvaises» connexions
  6. Ce que disent les autres gentils


Expressions quantitatives



Tout est clair ici. Plus la recherche est intensive et plus sa zone est étendue, et plus le dictionnaire est volumineux, plus la menace posée par l'attaquant est élevée. Il est inutile d'agrandir cet élément.



PTR et tout ce qui y est lié



Lorsque nous avons publié l'analyse initiale de la force brute, il est devenu évident que le dossier PTR en dit long.



Le nombre de sociétés d'hébergement chinoises attaquant nos serveurs était tout simplement écrasant, mais cela ne fait pas exception, les clients Azure et AWS ont également très joyeusement participé et n'ont pas pris les dernières places.



Le plus grand nombre d'attaques provenait d'adresses IP statiques de fournisseurs d'hébergement, donc si les serveurs représentent la plus grande menace pour la sécurité, pourquoi interdire les utilisateurs réguliers?



Mauvaises connexions



Il y a quelques. Par exemple, à partir du facilement googlé "k8h3d" est le premier candidat à une interdiction. Il s'agit d'une connexion d'un ver crypto-mineur très stupide qui a laissé une porte dérobée dans RDP sous ce nom d'utilisateur. Il en va de même pour les connexions tapées en hindi, en chinois et dans d'autres mises en page qui ne sont pas typiques de nos clients.



Vous pouvez imaginer une situation où une personne fait une erreur dans un chiffre de l'adresse IP, n'entre pas et commence à trier tous les mots de passe qui étaient dans sa vie. Mais il est difficile d'imaginer attendre de notre client qu'il commence à taper autre chose que l'administrateur standard. Nous fournissons le système d'exploitation uniquement sous les connexions anglaises, par conséquent, l'interdiction de la disposition du clavier est peut-être la plus efficace et la plus sûre.



D'autres bons gars



Spamhaus comme exemple des gentils, merci à eux pour les listes de blocage ouvertes. Disons qu'un attaquant n'a touché qu'un seul pot de miel, mais son adresse est dans la SBL depuis longtemps, alors pourquoi tirer?

C'est la même chose avec les listes fail2ban ouvertes, l'opinion des autres bons vous permet de prendre des décisions avec plus de confiance.



Essai



Comme en médecine. Étude randomisée en double aveugle. Les serveurs surveillés (à l'exception des interruptions) sont divisés en deux groupes.



  • Groupe de contrôle
  • Les patients


Pendant les deux premières semaines, nous appliquons les règles de filtrage aux patients uniquement. Le groupe de contrôle reçoit tout le trafic sans filtrage. Après cela, exactement la moitié des serveurs des deux groupes sont échangés.



Des groupes de contrôle supplémentaires seront situés dans d'autres CD afin de prendre en compte la «saisonnalité» et d'exclure l'influence d'autres facteurs, par exemple, la fermeture des contrôleurs, etc.

Ainsi, il sera possible d'établir de la manière la plus fiable à quel point le pot de miel est efficace en tant que méthode de protection autre que les pots de miel eux-mêmes.



Et après?



Après avoir collecté les données primaires, des tests de combat rapproché seront effectués sur seulement quelques centres de données, et si cela réduit considérablement le nombre d'attaques, nous publierons:



  1. Feuille de blocage ouverte avec des commentaires étendus au format txt, xml et json
  2. Script pour RouterOS et feuille de blocage séparée pour RouterOS
  3. Ouvrir le flux pour les routeurs avec prise en charge BGP.
  4. Codes source.


Eh bien, s'il n'y a pas moins d'attaques ou plus de problèmes, nous publierons uniquement le code source et un rapport sur les raisons pour lesquelles il a brûlé.



J'espère que le sujet vous intéresse autant qu'il attend vos réflexions sur le système proposé, toute réflexion vous sera utile.






All Articles