Journal Statistiques de tentatives de connexion SSH par des bots

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
45
6
mar.
2021

Sommaire

Ceci est une compilation de tentatives de connexion SSH issus de fichier /var/log/auth.log récupéré en mai 2020, août 2020 et février 2021 sur deux serveurs différents.

Ces statistiques (sauf pour root et www-data) sont issues de la commande :

grep "Invalid user" *.log | awk 'BEGIN { FS=" " } { print $8}' | sort | uniq --count | sort --reverse --numeric-sort

Bien que ces statistiques sont à prendre avec des pincettes, les ordres de grandeur semblent cohérents. J'ai ignoré les noms qui ont été tenté moins d'une cinquantaine de fois.

Les cinq comptes les plus requêtés (les quantités sont entre parenthèses) :

  1. root (205434)
  2. admin (6136)
  3. test (3871)
  4. ubuntu (3275)
  5. postgres (3003)

Il existe deux types de comptes visés :

A. Les utilisateurs réels

Compte root et variantes

root (205434), toor (83), root1 (83)
Les nombres de tentative sur root est de loin le plus grand. L'intérêt est évident mais je me demande s'il y a encore des serveurs avec ce compte accessible en SSH. Une configuration « PermitRootLogin: "no" » est conseillé un peu partout.

Des comptes associés au service informatique

admin (6136), dev (658), administrator (565), support (518), sysadmin (303), suporte (253), webadmin (200), administrador (192), admin1 (151), helpdesk (136), Administrator (81), Admin (78), tech (76), sysop (66), admin2 (57), webmin (49), operator (49)

Attaquer un compte admin semble une bonne idée : il a probablement des droits proche de root, sans s'appeler root. Je ne sais pas si cette pratique existe beaucoup aujourd'hui. J'ai l'impression que l'usage de sudo a pu la remplacer.

Des comptes associés aux autres services

student (345), service (213), manager (93), team (92), appuser (89), sales (73), marketing (68), students (61), family (57), work (56), student2 (51), teacher (49), market (49)

On voit principalement des comptes génériques d'entreprises et d'universités.

 Des utilisateurs de tests

test (3871), test_user (735), test1 (547), tester (412), teste (294), test123 (88), Test (79), testtest (72), testuser1 (71), test01 (67), test_user (62)

Je suppose que c'est très intéressant à tenter : si un compte pour tester a été créé, il a probablement un mot de passe faible.

 Des comptes invités

guest (834), demo (560), public (141)

Pleins de prénoms

daniel (270), john (254), jack (141), james (134), yang (74), etc.
Il y a beaucoup de prénoms à consonance asiatique avec de faibles occurrences. Peut-être que c'est nouveau ?

Des utilisateurs nommés sans aucune créativité

user1 (576), user2 (229), user3 (175), username (126), user4 (77), user01 (63),

Probablement une situation comparable aux utilisateurs de tests (mot de passe faible).

B. Des comptes associés à des logiciels, services

Noms de distribution

ubuntu (3275), pi (449), debian (301), centos (225), ubnt (165)
L'écart entre les requêtes sur « ubuntu » et le reste est assez étonnant. L'utilisateur « pi » provient probablement de raspian, une distribution basée sur Debian et visant les Raspberry Pi.

Bases de données et autres

postgres (3003), oracle (1932), hadoop (625), kafka (283), mysql (214), elasticsearch (191), db2fenc1 (140), informix (121), db2inst1 (115), elastic (98), mongo (97), mongodb (94), spark (94), redis (81), rabbitmq (71), dbuser (68), db (63)

Gestion de version

git (1504), svn (174), gitlab (94), gituser (69), gitlab-runner (54)

FTP

ftpuser (1345), ftp (564), uftp (307), ftptest (253), testftp (211), ftpadmin (177), ftp_user (145), sftp (141), userftp (95), sftpuser (78), ftp-user (66), ftp1 (61), ftpuser1 (57), myftp (52), sftptest (49)

FTP est le protocole avec la plus grande diversité de noms attaqués.

Progiciel de Gestion Intégré

odoo (313), openerp (115), erp (71)

E-mail

vmail (111), testmail (85), postmaster (82), noreply (60), zimbra (122)

Je suis étonné par le niveau faible d'attaque sur ce service. Et encore , zimbra est un webmail donc on pourrait se demander s'il est dans la bonne catégorie.

HTTP

www (839), web (627), webmaster (343), www-data (305), apache (150), nginx (139), webuser (137)

Et plus spécifiquement Wordpress

wp (122), wordpress (106), wp-user (69), cms (51)

Jeux

minecraft (648), csgoserver (238), arkserver (122), ark (122), factorio (115), cs (110), csgo (105), csserver (94), gmodserver (82)

Teamspeak

teamspeak (602), ts3 (596), teamspeak3 (329), ts (328), ts3server (236), ts3bot (157), ts3srv (72), ts3user (63)

Teamspeak est (était ?) beaucoup utilisé par les joueurs pour discuter entre eux pendant leurs parties.

Diffusion de musique

sinusbot (332), sinus (139), musikbot (118), musicbot (64)

Ce sont des bots pour diffuser de la musique sur Teamspeak et/ou Discord. J'ignorais leur existence avant le regarder ces statistiques.

Infrastructure

nagios (757), jenkins (546), redmine (220), zabbix (206), ansible (172), docker (171), sonar (110), stack (98), sentry (92), squid (81), cacti (74), solr (72), cactiuser (57), serverpilot (56), zookeeper (55), cisco (51),

Machines virtuelles et hébergement

ec2-user (289), cloud (221), vps (112), vm (64)

Déploiement

deploy (1459), deployer (237), build (88), uploader (68), production (52)

Et aussi

tomcat (469), samba (173), system (156), jboss (139), backups (98), scan (96), rustserver (88), node (85), sun (81), confluence (76), laravel (72), sshuser (66), smbuser (60), applmgr (60), openvpn (59), rust (56), cron (54), alfresco (51)

À noter des cas assez inclassables comme :
- une seule lettre de l'alphabet : b (136), a (122), etc.
- un seul chiffre : 1 (35), 2 (53), etc.
- nvidia (69)

Bref, la plage de tentative est assez large, en tout cas, bien plus que je ne l'aurai imaginé avant de faire quelques statistiques sur les journaux d'authentification.

  • # Un autre...

    Posté par  . Évalué à 6.

    Ah, moi, j'ai 'MikroTik' en 2ème position, juste derrière 'admin' …
    Y aurait-il une faiblesse connue sur ces éléments réseaux ? :-)

    Celui qui pose une question est bête cinq minutes, celui qui n'en pose pas le reste toute sa vie.

    • [^] # Re: Un autre...

      Posté par  . Évalué à 2.

      Il me semble avoir vu passer une bonne grosse faille des familles dernièrement sur du Mikrotik ou Ubiquity (le "ubnt").

      Mais je pense que la raison principale, cest que c'est assez souvent ce type de matos qui va être mis chez des PME/artisans avec la configuration par défaut '-_-

    • [^] # Re: Un autre...

      Posté par  . Évalué à 0.

      Salut, mikrotik a beau être farci de trous/failles, c’est le seul élément réseau qui a passé les tests et est validé par l’OTAN
      Voilà pourquoi il est répandu.
      Ah oui aussi, le VPN fait du Layer 2, et ça, c’est de la grosse balle !

  • # Port ?

    Posté par  . Évalué à 2. Dernière modification le 06 mars 2021 à 23:57.

    Salut,

    Blague involontaire.

    Sur le port standard je suppose, non ?

    Et y-a t'il un fail2ban (ça peut changer les chiffres) ?

    Matricule 23415

    • [^] # Re: Port ?

      Posté par  (Mastodon) . Évalué à 4. Dernière modification le 07 mars 2021 à 07:37.

      Je pense que fail2ban aide beaucoup. Pour ma part je suis sur un dédié OVH, je suis sur le port 22 standard mais avec fail2ban.

      Depuis début février, j'ai le résultat suivant avec le script du journal :

          644 admin
          284 user
          254 test
          214 pi
          205 ubuntu
          168 postgres
          121 oracle
           98 support
           95 ftpuser
           94 git
           ...
      

      J'ai 5600 lignes, dont l'immense majorité avec une seule occurrence.

      Sur cette même période je vois 34000 "Ban" dans les logs de fail2ban.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Port ?

        Posté par  (site web personnel) . Évalué à 2.

        Le fichier de l'article contient 11.945 lignes dont 3.398 lignes avec une seule occurence (beaucoup de combinaisons de 3 lettres, des adresses IPv4 et des tentatives ressemblant à des types déjà présentés dans l'article).

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 3.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Port ?

        Posté par  (site web personnel) . Évalué à 2.

        Je pense que fail2ban aide beaucoup

        C'est sûr ! fail2ban aide beaucoup ! Mais j'ai pas encore trouvé à quoi …

        • [^] # Re: Port ?

          Posté par  . Évalué à 1. Dernière modification le 08 mars 2021 à 18:12.

          Salut,

          Mais j'ai pas encore trouvé à quoi …

          Exemple pratique (un poil ironique :p) :

          Bah c'est comme quand tu sors de chez toi sans tes clefs, que tu ferme toutes les portes du sas, et que tu te retrouve gros jean devant la porte.

          Ça renforce le : Ne pas oublier les clefs…

          Matricule 23415

        • [^] # Re: Port ?

          Posté par  . Évalué à 2.

          Moi non plus sur les cas où tu prend suffisamment de tentatives de connexion pour que ça ai un impact je suis pas sûr que le parsing de log de fail2ban soit toujours fiable.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Port ?

            Posté par  (Mastodon) . Évalué à 4. Dernière modification le 08 mars 2021 à 19:52.

            Bin j'ai eu 34000 ban en quelques mois. C'est pas négligeable je trouve. Vu que le ban arrive après plusieurs tentatives et que donc il n'y a pas de raison que ça s'arrête, c'est au moins 34000 tentatives supplémentaires qui n'ont pas eu lieu.

            Non ?

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

            • [^] # Re: Port ?

              Posté par  . Évalué à 2.

              C'est des tentatives qui ont étaient bloquées au niveau du firewall plutôt que d'openssh ça consomme un peu moins de ressources[1], mais je doute que la plupart des gens qui utilisent fail2ban le ressentent. AMHA c'est plus que la plupart des gens ne monitor pas l'activité de leur firewall et que si c'était le cas ça les embêterait presque tout autant.

              Ça demande des mesures parce que l'activité induite par fail2ban peut être supérieure au deny d'openssh. Je ne sais pas comment il est configuré sorti d'usine, mais s'il crée une règle par ip (plutôt que d'utiliser les chains ou ipset voir nftables), ça peut induire des chargements/déchargements de conf un peu lourde.

              Par contre la règle DROP embête probablement plus les scripts qui partent en timeout plutôt qu'un reject.

              Je ne connais pas le milieu, mais un serveur qui me bloque après 30 tentatives, je le remettrais en queue pour le relancer le lendemain.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: Port ?

                Posté par  . Évalué à 1.

                Tu peux configurer fail2ban pour utiliser nftable.

                • [^] # Re: Port ?

                  Posté par  . Évalué à 3.

                  Je sais tu peux lancer n'importe quelle commande, mais est-ce que c'est ce que les gens font ou est-ce que c'est utilisé par défaut ?

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: Port ?

                Posté par  (Mastodon) . Évalué à 2. Dernière modification le 09 mars 2021 à 08:32.

                C'est des tentatives qui ont étaient bloquées au niveau du firewall plutôt que d'openssh

                Un firewall détecte 3 tentatives infructueuses consécutives de login ? Si oui, ça a en effet plus de sens de le mettre sur un firewall… encore faut-il en avoir un (et bien configuré pour ça).

                fail2ban out-of-the-box est déjà paramétré pour openssh. C'est encore plus facile à installer que de changer le port de SSH :)

                En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                • [^] # Re: Port ?

                  Posté par  . Évalué à 3.

                  C'est des tentatives qui ont étaient bloquées au niveau du firewall plutôt que d'openssh

                  Un firewall détecte 3 tentatives infructueuses consécutives de login ?

                  Non ce que je dis c'est que fail2ban va bloquer une partie des tentatives de connexion au niveau du firewall plutôt qu'un refus ssh.

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                  • [^] # Re: Port ?

                    Posté par  (Mastodon) . Évalué à 3. Dernière modification le 09 mars 2021 à 08:39.

                    Ah pardon oui. Il y a un côté anti-DDOS dans l'utilisation de fail2ban en effet.

                    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                    • [^] # Re: Port ?

                      Posté par  . Évalué à 4.

                      Sauf si c'est lui qui te DOS :) c'est ce dont je parlais, ajouter et supprimer des règles iptables n'est pas anodin et avoir un service en plus qui doit parser tes logs, manipuler ton firewall et gérer des timers n'est pas anodin.

                      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Commentaire supprimé

          Posté par  . Évalué à 3. Dernière modification le 09 mars 2021 à 06:39.

          Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Port ?

      Posté par  (site web personnel) . Évalué à 2.

      Pour les deux machines :
      - il y avait fail2ban dans tous les cas
      - par contre, c'était le port standard pour les premiers journaux et un port différent pour les derniers.

      • [^] # Effet Fail2ban ?

        Posté par  (site web personnel) . Évalué à 3.

        Sans fail2ban et sur le port 22, j'ai un nombre environ 2 fois plus élevé de tentatives de connexions. Sur la moitié du mois de février 2021 (du 7 au 22), j'ai 10478 tentatives dont :

        • 733 admin
        • 493 user
        • 349 support

        J'imaginais que l'effet de fail2ban serait plus massif que ça. Avec/sans on semble être dans un rapport de 1 à 2.

        De mon côté, l'authentification par mot de passe est désactivée.

  • # Pour LinuxFr

    Posté par  (site web personnel) . Évalué à 10.

    Sur 189374 occurrences (sur l'ensemble des /var/log/auth.log* y compris les gzippés sur les différentes machines) :

    • 13069 admin
    • 8826 user
    • 7601 user1
    • 7485 default
    • 7464 ubnt
    • 7359 MikroTik
    • 7324 profile1
    • 7249 admin1
    • 7246 administrator
    • 7216 support
    • les 100 ou plus : web tech demo telecomadmin test pi ubuntu postgres oracle ftpuser guest git test1 from mysql deploy usuario test2 ftp hadoop www testuser tomcat Administrator adm jenkins operator ts3 dev 1234 minecraft teamspeak server monitor tester sysadmin steam Admin webmaster ec2-user alex service manager info ts system svn developer anonymous a student webadmin vnc super
    • entre 10 et 100, encore pas mal de login techniques
    • dans les basses occurrences, une attaque par dictionnaire, des chiffres, des adresses IP, des @, des !, des #, à boire et à manger quoi.
  • # User "22"

    Posté par  . Évalué à 6.

    J’ai quelques tentatives de connexion pour un utilisateur nommé “22”… On dirait que quelqu’un s’est emmêlé les pinceaux avec son script, et a confondu le paramètre indiquant le nom de login avec celui indiquant le numéro de port…

    Sinon, j’ai aussi quelques petits malins qui tentent de se connecter avec le nom du domaine associé à ma machine au lieu d’essayer bêtement des noms prédéfinis, j’accorde un demi-point pour l’effort.

  • # Moins de plomberie bash

    Posté par  (site web personnel) . Évalué à 4.

    La commande me semble un peu complexe, on peut éliminer pas mal de tuyaux/processus :

    awk '$6 == "Invalid" && $7 == "user"  {count[$8]++}END{for(j in count) print count[j] , j }' /var/log/auth.log
    • [^] # Re: Moins de plomberie bash

      Posté par  (site web personnel) . Évalué à 3.

      J'aime bien la simplification mais le tri décroissant a été perdu. Évidemment, on peut envoyer la sortie standard vers la commande sort initiale. ;-)

  • # Adaptation de la commande

    Posté par  (site web personnel) . Évalué à 1. Dernière modification le 07 mars 2021 à 18:22.

    La commande ne marchait juste pas chez moi, j'ai adapté un peu:

    grep "authentication failure" *.log | awk 'BEGIN { FS="user=" } { print $3 }' | sort | uniq --count | sort --reverse --numeric-sort

    Du coup je n'ai que "root" en résultat.

    Après avec la rotation de log je n'ai que les résultats d'aujourd'hui là, sachant que les autres logs sont compressés et stockés ailleurs et que j'ai la flemme d'aller les chercher.

  • # Mes serveurs n'intéressent personnes

    Posté par  . Évalué à 3.

    Autant sur mon serveur OneProvider que sur mon Raspberry autohébergé je n'ai personne qui essaye de se connecter. Le fait d'avoir un port SSH différent de 22 plus fail2ban qui tape assez large sur le filtre SSH doit expliquer ceci.
    Je vois d'ailleurs que pas mal d'entre vous ont laissé le port 22 pour le SSH. Il y a une raison à cela (c'est le premier truc que change après une install de serveur, en général) ?

    • [^] # Re: Mes serveurs n'intéressent personnes

      Posté par  (Mastodon) . Évalué à 10.

      Il y a une raison à cela

      Oui, c'est le port standard.

      Moi c'est la question inverse que je me pose : pourquoi en changer ?

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Mes serveurs n'intéressent personnes

        Posté par  . Évalué à 6.

        Moi c'est la question inverse que je me pose : pourquoi en changer ?

        Je ne vois qu’une raison valable : pour avoir moins de "bruit" dans les logs. Mais ça ne concerne donc que ceux qui ont souvent à mettre le nez dans leurs logs SSH.

        Ici je l’ai aussi passé sur un port non-standard, mais c’est avant tout pour avoir une opportunité de jouer avec le tarpit Endlessh (qui est donc lui sur le port 22).

        • [^] # Re: Mes serveurs n'intéressent personnes

          Posté par  (Mastodon) . Évalué à 4. Dernière modification le 08 mars 2021 à 15:10.

          Si c'est juste pour faire moins de bruit dans les logs tu peux faire du port knocking. D'un point de vue sécurité, il ne faut pas se faire d'illusion c'est plus ou moins aussi nul que changer de port mais au moins tu sors moins des standard une fois ton ip autorisée (pas besoin de charger ton .ssh/config ni de spécifier le port à chaque commande qui utilise openssh pour se connecter) et ton port apparait comme fermé quand tu te fais port scanner.

          Après c'est intéressant sur des machines exposées publiquement sur internet mais sur des réseaux d'entreprises avec potentiellement plusieurs firewalls entre les deux nodes c'est plus emmerdant qu'autre chose car ça fait plus de ports à ouvrir. Il y en a néanmoins des plus avancés qui font un single knock avec un paquet udp signé, ça évite d'avoir des ports multiples pour une séquence et c'est plus rapide.

          • [^] # Re: Mes serveurs n'intéressent personnes

            Posté par  . Évalué à 3.

            Si c'est juste pour faire moins de bruit dans les logs tu peux faire du port knocking.

            J’imagine que le changement de port a plus de succès tout bêtement parce que sa mise en place se limite à changer une valeur dans la configuration de OpenSSH.

      • [^] # Re: Mes serveurs n'intéressent personnes

        Posté par  . Évalué à 3.

        Moi c'est la question inverse que je me pose : pourquoi en changer ?

        Pour une question de sécurité. L'accés SSH étant plus que sensible, je préfère utiliser un autre port que le port standard. On est jamais à l'abris d'une faille permettant de se connecter sans avoir la clé.

        • [^] # Re: Mes serveurs n'intéressent personnes

          Posté par  (Mastodon) . Évalué à 7.

          Pour une question de sécurité.

          C'est une fausse sécurité. Si c'était le cas, les installations standard utiliseraient un port random par exemple, ou t'inciteraient fortement à en changer. Scanner une IP pour y trouver un port SSH prend quelques secondes, c'est une sécurité bien fragile.

          Ok, tu t'affranchis des scripts kiddies les plus simples, mais sur une vraie attaque, il n'y aura pas de différence.

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

          • [^] # Re: Mes serveurs n'intéressent personnes

            Posté par  . Évalué à 4. Dernière modification le 08 mars 2021 à 08:31.

            On est bien d'accord que changer de port ne va pas empêcher mon accès SSH d'être pirater et que trouver le port que j'utilise n'est vraiment pas compliqué. Après je ne base pas la sécurité de mon accès SSH que sur un changement de port, je te rassure.
            Mais comme tu le dis, changer de port SSH fait qu'une partie des attaques n'arriveront jamais jusqu'à mon port SSH et se focaliseront sur le port 22.
            Changer de port SSH me prends quelques seconde et je n'y vois que des bénéfices, du coup pourquoi ne pas le faire ?

            • [^] # Re: Mes serveurs n'intéressent personnes

              Posté par  (Mastodon) . Évalué à 5. Dernière modification le 08 mars 2021 à 08:45.

              pourquoi ne pas le faire ?

              Parce que tu sors des standards. Rien que pour ça c'est un argument pour moi (rester dans les standards est toujours une bonne pratique).

              Disons que c'est un réglage supplémentaire à faire à chaque client, c'est le risque (minime c'est vrai) d'utiliser un jour une autre application qui utilise ce même port et c'est reparti pour un réglage de plus, c'est le risque d'oublier quel est le port en question (si t'as pas ton client fétiche sous la main dans lequel tu as fait le réglage, et que tu as vraiment choisi un port random, et pas 2222 comme bcp font)… bref tu sors des standards quoi :)

              En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

              • [^] # Re: Mes serveurs n'intéressent personnes

                Posté par  . Évalué à 5.

                Disons que c'est un réglage supplémentaire à faire à chaque client, c'est le risque (minime c'est vrai) d'utiliser un jour une autre application qui utilise ce même port et c'est reparti pour un réglage de plus, c'est le risque d'oublier quel est le port en question…

                J’ajouterais le risque d’oublier de changer la configuration du pare-feu en même temps que celle du serveur SSH, et donc de se retrouver avec sshd qui écoute sur (par exemple) le port 7322 alors que le pare-feu continue à ne laisser passer que les paquets à destination du port 22…

                C’est à l’administrateur de ne pas être aussi stupide, me direz-vous, mais je pense que miser sur le fait qu’on ne fera jamais ce genre de boulettes est une mauvaise idée.

                (Ne dit-on pas qu’il n’y a que deux sortes de sysadmin : ceux qui ont déjà fait une grosse boulette et ceux qui s’apprêtent à en faire une… :D )

            • [^] # Re: Mes serveurs n'intéressent personnes

              Posté par  (site web personnel) . Évalué à 4.

              J'ai une bonne raison : au travail les parefeu ne laissent passer que les ports standards. Et demander un port non standard est digne de Kafka : RSSI, AQSSI …
              Donc si l'on veut que les utilisateurs puissent travailler rapidement, on reste sur du standard (avec fail2ban).

              • [^] # Re: Mes serveurs n'intéressent personnes

                Posté par  . Évalué à 4.

                Et demander un port non standard est digne de Kafka

                Du coup, tu dois pouvoir demander le 9092

                « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Mes serveurs n'intéressent personnes

            Posté par  (Mastodon) . Évalué à 4. Dernière modification le 08 mars 2021 à 08:54.

            Si c'était le cas, les installations standard utiliseraient un port random par exemple, ou t'inciteraient fortement à en changer.

            Bon, l'ANSI recommande de changer le port. Par contre ils recommandent surtout de rester sur un port privilégié (< 1024) pour pas se le faire usurper par un autre service "utilisateur".

            Au passage ils parlent de risque sur les comptes avec mot de passe faible. Je pense que cette recommandation est faite pour des serveurs où il y a bcp d'utilisateurs non maîtrisés (ce qui n'est pas le cas chez moi où il n'y a qu'un utilisateur : moi).

            En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

            • [^] # Re: Mes serveurs n'intéressent personnes

              Posté par  . Évalué à 2.

              Intéressant je n'étais jamais allé voir, mais je me disais que mes prochains serveurs utiliseraient des réseaux séparés. Pas physiquement on est d'accord, mais avec l'arrivée de wireguard, maintenant c'est vraiment facile de mettre en place un VPN pour ça. Le truc intéressant c'est de pouvoir facilement mettre en place des services « d'administration » comme un monitoring web par exemple qui aura de base la sécu de ton VPN.

              Par contre je ne me suis pas penché dessus encore, je sais pas s'il est facile d'avoir 2 VPN : un admin et un juste pour se connecter sur des wifi publiques.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Mes serveurs n'intéressent personnes

              Posté par  . Évalué à 3.

              Au passage ils parlent de risque sur les comptes avec mot de passe faible

              Je n’ai eu qu’une lecture rapide du document, mais je vois surtout des recommandations d’utilisation d’authentification par clé.

              Je suis peut-être un admin un poil parano, mais de l’authentification SSH par mot de passe (autrement que sur un réseau local sûr) ça me fait froid dans le dos rien que d’y penser.

              • [^] # Re: Mes serveurs n'intéressent personnes

                Posté par  (Mastodon) . Évalué à 3.

                Je suis peut-être un admin un poil parano, mais de l’authentification SSH par mot de passe (autrement que sur un réseau local sûr) ça me fait froid dans le dos rien que d’y penser.

                Alors tu m'inquiètes, c'est ce que je fais depuis toujours :)

                Bon, à ma décharge, voici mes "mitigation" :
                - pas de connexion root
                - seul mon compte perso est accessible (login original donc)
                - fail2ban activé

                Donc niveau script merdiques, je suis tranquille, et brute force, ça va être compliqué. Après, je suis particulièrement peu parano j'avoue…

                En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 3.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: Mes serveurs n'intéressent personnes

                    Posté par  (Mastodon) . Évalué à 2.

                    Si ton compte perso peut utiliser sudo

                    Oui mais ce que je veux dire c'est que déjà il faut le connaître. Les scripts tentent des login standard uniquement. Par contre celui qui me connait et veut attaquer mon serveur n'aura en effet pas de mal à trouver le login. Reste ensuite la barrière du mot de passe, là, même qqu'un qui me connait aura du mal.

                    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                    • [^] # Re: Mes serveurs n'intéressent personnes

                      Posté par  . Évalué à 4.

                      Les scripts tentent des login standard uniquement.

                      Euh, non.

                      De la même manière que les scripts peuvent¹ faire du brute-force de mot de passe, ils peuvent aussi faire du brute-force de login, en testant un nombre virtuellement illimité de noms soit issus de dictionnaires, soit générés à la volée (ou une combinaison des deux).

                      Les scripts peuvent aussi s’adapter dynamiquement à l’hôte attaqué — comme mentionné plus haut, j’en ai vu qui tentent de dériver un nom de login depuis le nom d’hôte, ce qui est certes assez simpliste mais ça ne m’étonnerait pas que ça marche sur certaines machines — et on peut facilement imaginer des dérivations plus complexes.

                      Miser sur le fait que l’attaquant ne trouvera pas le login, c’est une mauvaise idée.

                      Reste ensuite la barrière du mot de passe.

                      Du coup, c’est la seule barrière réelle.


                      ¹ En l’absence de contre-mesures interdisant les tentatives répétées de connexion, du moins.

                      • [^] # Re: Mes serveurs n'intéressent personnes

                        Posté par  (Mastodon) . Évalué à 2.

                        Miser sur le fait que l’attaquant ne trouvera pas le login, c’est une mauvaise idée.

                        En tous cas, si tu considères l'attaque par brute-force possible du mot de passe, ça rajoute des bits d'entropie (va falloir réessayer tous les mots de passes pour tous les logins avant d'en trouver qui matche).

                        Mais couplé à fail2ban, ça devient compliqué de brute-forcer quoi que ce soit. Ou alors il faut être sacrément organisé (et jouer avec des IPs différentes sur chaque tentative).

                        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

              • [^] # Re: Mes serveurs n'intéressent personnes

                Posté par  . Évalué à 2.

                Je n’ai eu qu’une lecture rapide du document, mais je vois surtout des recommandations d’utilisation d’authentification par clé.

                Je trouve justement que la désactivation de la connexion par mot de passe n'est pas clairement pas recommandée. Ils indiquent juste un ordre de préférence qui inclus l'authentification par mot de passe. Ce qui n'indique pas du tout de le désactiver.

                Ils ne parlent pas non plus d'une pratique que j'ai pas mal vu qui est de trimbaler une clef privée de machine en machine (par exemple j'ai 2 machines un portable et un pc de bureau avoir la même clef privée pour les 2). C'est une utilisation symétrique à celle d'un mot de passe, mais ça pose des problèmes et ça n'est pas très pratique (si on perd une clef privée, on dégomme son empreinte sans toucher aux autres machines).

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Mes serveurs n'intéressent personnes

      Posté par  . Évalué à 10.

      Je vois d'ailleurs que pas mal d'entre vous ont laissé le port 22 pour le SSH. Il y a une raison à cela ?

      Besoin de me connecter à mon serveur depuis n’importe où, y compris depuis des réseaux que je ne contrôle pas et où seuls certains ports bien définis (typiquement 22, 53, 80, 443, 465, 993, parfois quelques autres) sont autorisés en sortie…

    • [^] # Re: Mes serveurs n'intéressent personnes

      Posté par  . Évalué à 1.

      Je +1 pour le changement de port d'ailleurs. Et, petite histoire. Je l'avais mis sur un port plus bas que 1024 au début. J'ai eu moins de log, puis ça a commencé à venir, je sais pas trop comment le port a été trouvé, d'ailleurs? Des gens qui scannent? Des gens qui utilisent des services commes shodan?

      Du coup, j'ai pris un port > 50000 et depuis, c'est le calme plat dans mes logs :-)
      Je n'ai jamais été coincé par un réseau pénible, sans doute car j'utilise de plus en plus ma connexion 4G comme point d'accès internet.

      Du coup, blindez votre conf ssh (interdire le root login, clé, etc..) et changez de port \o/

      • [^] # Re: Mes serveurs n'intéressent personnes

        Posté par  (Mastodon) . Évalué à 3.

        Des gens qui scannent?

        Bin oui. C'est la base d'une attaque ciblée. Seuls les petits scripts simplistes tentent pi/raspberry sur le port 22 et c'est tout, mais si qqu'un veut précisément jouer avec ton serveur, il va commencer par regarder quels ports sont ouverts et avec quels services (c'est trivial et ça prend quelques secondes).

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Par pays

    Posté par  . Évalué à 6.

    On peut faire un classement par pays des tentatives d'intrusion :

    for ip in $(grep "Invalid user" /var/log/*.log|grep -o -e [0-9,.]*$ | sort -u);do geoiplookup $ip | awk -F ', ' '{if ($2) print $2}';done | sort | uniq -c | sort -g

    La commande peut sans doute être simplifiée, je vous laisse voir :)

    Le résultat chez moi :
    1 Belgium
    1 Canada
    1 Chile
    1 Germany
    1 Greece
    1 Israel
    1 Korea
    1 Lao People's Democratic Republic
    1 Peru
    1 Singapore
    1 Switzerland
    1 Ukraine
    2 Cameroon
    2 France
    2 Malaysia
    2 Mexico
    2 Pakistan
    2 Spain
    2 United Arab Emirates
    3 Italy
    3 Philippines
    3 Sweden
    3 United Kingdom
    4 Bangladesh
    5 Brazil
    5 Russian Federation
    5 Turkey
    8 Indonesia
    9 China
    9 India
    9 Thailand
    20 United States
    52 Vietnam

    Pourquoi les vietnamiens, peuple charmant, m'en veulent à ce point, ça me laisse perplexe…

    • [^] # Re: Par pays

      Posté par  . Évalué à 2.

      J'avais fait une recherche par pays aussi et une localisation par IP à une époque (chez moi c'était principalement les Pays-Bas et l'Amérique du sud). Pour ce dernier pays, une majorité des tentatives de connexion par bots provenaient d'universités/écoles donc on peut supposer le plus souvent des réseaux d'ordi. compromis et pas à jour.

    • [^] # Re: Par pays

      Posté par  . Évalué à 0.

      Par contre, de voir que les Younaïtide Steÿtss" devant la plupart des attendus y compris la Russie (4x plus) il ne faut surtout pas en parler hein…
      En fait ce qui me fera toujours rire dans ces chiffres, c'est que chacun relèvera ce qu'il a envie de relever, et taira ce qu'il a envie de taire…

      • [^] # Re: Par pays

        Posté par  . Évalué à 4.

        il ne faut surtout pas en parler hein…

        En fait ce qui me fera toujours rire dans ces chiffres, c'est que chacun relèvera ce qu'il a envie de relever, et taira ce qu'il a envie de taire…

        Oui enfin faire des conclusions géopolitque sur un échantillon aussi faible sur une seule machine, dans un sens ou dans l'autre, ça n'a pas grand intérêt.

        Pas la peine de s'énerver pour ça.

        • [^] # Re: Par pays

          Posté par  (Mastodon) . Évalué à 4. Dernière modification le 10 mars 2021 à 08:33.

          Surtout quand on voit la qualité de la geoloc par IP (pour avoir été considéré Russe pendant des mois sur ma connexion ADSL en France métropolitaine, je peux témoigner des emmerdes que ça m'a généré).

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Par pays

        Posté par  . Évalué à 2.

        c'est que chacun relèvera ce qu'il a envie de relever

        Perso, je ne vois pas vraiment quelle conclusion tirer de ce genre de statistiques. A part un kiddie de base, je ne vois pas qui serait idiot au point de lancer des manœuvres hostiles depuis son accès résidentiel. S'agissant donc soit de machines déjà compromises et utilisées en rebond ou de babasses louées, on peut difficilement tirer de conclusions sur la nationalité de l'attaquant qui se cache derrière.

      • [^] # Re: Par pays

        Posté par  . Évalué à 4. Dernière modification le 11 mars 2021 à 19:24.

        devant la plupart des attendus y compris la Russie (4x plus)

        Les USA, 3e pays le plus peuplé au monde (9e pour la Russie), 3e également en nombre d'internautes (8e pour la Russie), 1er pays ayant le plus d'IP allouées, soit un tiers du total (13e pour la Russie).

        Ça me paraît normal qu'ils soient devant la Russie non ? Sur des chiffres aussi faibles en plus… difficile d'en tirer quoique ce soit

  • # Pour les fans d'usines

    Posté par  . Évalué à 3.

    Le score de Factorio est très étonnant, je pensais que c'était un jeu de niche.

    • [^] # Re: Pour les fans d'usines

      Posté par  . Évalué à 3.

      Je ne vois qu’une seule explication plausible : les joueurs acharnés de Factorio finissent tous par monter une usine automatisée Turing-complete. Puis à installer un serveur SSH sur ladite usine pour la contrôler depuis une autre partie de Factorio.

      Quand je pense que de mon côté je ne suis même pas fichu d’y mettre en place une basique ligne de chemin de fer…

  • # Compte du nom de la distribution

    Posté par  . Évalué à 2.

    ubuntu (3275), pi (449), debian (301), centos (225), ubnt (165)
    L'écart entre les requêtes sur « ubuntu » et le reste est assez étonnant. L'utilisateur « pi » provient probablement de raspian, une distribution basée sur Debian et visant les Raspberry Pi.

    Sur GCP, quand tu démarre une VM avec Ubuntu, tu as un compte nommé ubuntu par défaut. C’est pareil avec Debian et CentOS.

    Sur pourquoi il y a une tel différence d’essais avec ubuntu plutôt qu’avec d’autres noms de distributions, mon hypothèse c’est qu’Ubuntu étant ce qu’elle est, elle a plus de chance d’être utilisé par des gens qui n’y comprennent rien, et qui ont potentiellement plus de chance de mal configurer leur système.

    • [^] # Re: Compte du nom de la distribution

      Posté par  . Évalué à 2.

      Marrant, je constate la même chose que toi (les noms de comptes par défaut sur des VPS) mais arrive à la conclusion inverse ;)

      Qui est qu’Ubuntu est tellement bien fichue en version serveur pour des besoins de type hébergement Web qu’elle a de bonnes chances d’être une distribution très utilisée sur les VPS de petites agences Web. Et plus généralement par toutes les entreprises ayant besoin de serveurs, mais pas les moyens d’en héberger physiquement chez eux.

      • [^] # Re: Compte du nom de la distribution

        Posté par  . Évalué à 0.

        elle a plus de chance d’être utilisé par des gens qui n’y comprennent rien, et qui ont potentiellement plus de chance de mal configurer leur système.

        mais arrive à la conclusion inverse ;)

        elle a de bonnes chances d’être une distribution très utilisée sur les VPS

        Je ne vois pas la contradiction entre d'un côté le fait qu'Ubuntu est l'une des (si ce n'est là) distribution(s) la plus utilisée et de l'autre le fait l'hypothèse qu'une partie (plus ou moins grosse) de ses utilisateurs puisse être assez néophyte dans le connaissance de son système d'exploitation.

        Ça me paraît même carrément compatible.

    • [^] # Re: Compte du nom de la distribution

      Posté par  . Évalué à 1.

      Il me semble aussi que de plus en plus de tuto et documentations officielles pour des applications web ou Internet sont faits pour ubuntu…

  • # Failed password for

    Posté par  . Évalué à 1.

    J'ai tenté le script du journal et je m'étonnais de ne pas avoir d'entrées pour root.

    Après vérification, les tentatives en root apparaissent dans les logs sous la forme "Failed password for root".

    Peut-être est-ce dû au fait que j'ai configuré mon sshd_config avec le permitRootLogin à no ?

    Dans tous les cas, j'ai rajouté cette string dans la regex et j'en ai profité pour réécrire la commande en enlevant les pipes (mais en en rajoutant un pour prendre en compte les auth.log.* gzippés), et ça me donne ça :

    zcat -f /var/log/auth.log* | \
    perl -lne '/(?:Invalid user|Failed password for) (\S+)/ and $u{$1}++;
    END{print "$u{$_}:$_" foreach (sort {$u{$a} <=> $u{$b}} keys %u)}'
    

    Sur 3 serveurs ça me donne ça (20 dernières lignes) :

    166:dev
    171:minecraft
    185:jenkins
    206:testuser
    211:nagios
    229:hadoop
    235:www
    242:guest
    309:mysql
    359:deploy
    380:ftpuser
    390:git
    489:oracle
    774:user
    811:postgres
    872:ubuntu
    1103:test
    1783:admin
    63143:invalid
    139012:root

    -

    190:administrator
    192:teamspeak
    198:minecraft
    207:web
    221:testuser
    234:www
    251:guest
    261:nagios
    328:mysql
    433:ftpuser
    454:deploy
    459:git
    499:oracle
    878:user
    1002:postgres
    1009:ubuntu
    1186:test
    1903:admin
    69090:invalid
    127322:root

    -

    145:dev
    148:server
    164:minecraft
    178:testuser
    183:hadoop
    186:nagios
    196:guest
    198:www
    310:deploy
    356:git
    410:mysql
    489:ftpuser
    578:oracle
    794:ubuntu
    833:postgres
    874:user
    1035:test
    1572:admin
    55651:invalid
    130604:root

    Amusant de voir que des serveurs avec des rôles différents, sur des réseaux différents, et une exposition différentes ont finalement des résultats assez similaires.

    • [^] # Re: Failed password for

      Posté par  (site web personnel) . Évalué à 1.

      J'ai tenté le script du journal et je m'étonnais de ne pas avoir d'entrées pour root.

      Il était bien précisé dans journal que les statistiques pour root ne venaient pas de la même commande. Je cite :

      Ces statistiques (sauf pour root et www-data) sont issues de la commande :

      Mais effectivement, il possible d’avoir tout avec une même commande.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.