Journal Statistiques de tentatives de connexion SSH par des bots

Posté par srb (site web personnel) le 06 mars 2021 à 23:07. Licence CC By‑SA.

Étiquettes :

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) :

root (205434)
admin (6136)
test (3871)
ubuntu (3275)
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 redo_fr le 06 mars 2021 à 23:43. É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 Ambroise le 07 mars 2021 à 11:03. É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 negatif le 08 mars 2021 à 13:41. É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 _kaos_ le 06 mars 2021 à 23:55. É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 gUI (Mastodon) le 07 mars 2021 à 07:35. É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 srb (site web personnel) le 07 mars 2021 à 10:14. É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 Anonyme le 07 mars 2021 à 11:32. Évalué à 3.
    
    Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: Port ?
    
    Posté par Joris Dedieu (site web personnel) le 08 mars 2021 à 18:05. É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 _kaos_ le 08 mars 2021 à 18:11. É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 barmic 🦦 le 08 mars 2021 à 18:45. É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 gUI (Mastodon) le 08 mars 2021 à 19:51. É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 barmic 🦦 le 08 mars 2021 à 23:02. É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 Ambroise le 08 mars 2021 à 23:55. Évalué à 1.
        
        Tu peux configurer fail2ban pour utiliser nftable.
        
        [^] # Re: Port ?
        
        Posté par barmic 🦦 le 09 mars 2021 à 07:45. É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 gUI (Mastodon) le 09 mars 2021 à 08:32. É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 barmic 🦦 le 09 mars 2021 à 08:35. É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 gUI (Mastodon) le 09 mars 2021 à 08:39. É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 barmic 🦦 le 09 mars 2021 à 14:27. É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 Anonyme le 09 mars 2021 à 06:39. É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 srb (site web personnel) le 07 mars 2021 à 10:08. É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 Samuel (site web personnel) le 07 mars 2021 à 12:23. É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 Benoît Sibaud (site web personnel) le 07 mars 2021 à 10:36. É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 gouttegd le 07 mars 2021 à 13:29. É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 kaliko (site web personnel) le 07 mars 2021 à 15:15. É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 srb (site web personnel) le 07 mars 2021 à 22:22. É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 Christie Poutrelle (site web personnel) le 07 mars 2021 à 18:20. É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 fate le 07 mars 2021 à 19:16. É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 gUI (Mastodon) le 07 mars 2021 à 19:41. É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 vv222 le 07 mars 2021 à 19:49. É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 Psychofox (Mastodon) le 08 mars 2021 à 15:06. É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 vv222 le 08 mars 2021 à 15:57. É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 fate le 07 mars 2021 à 23:14. É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 gUI (Mastodon) le 08 mars 2021 à 08:06. É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 fate le 08 mars 2021 à 08:31. É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 gUI (Mastodon) le 08 mars 2021 à 08:44. É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 gouttegd le 08 mars 2021 à 10:38. É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 eric gerbier (site web personnel) le 08 mars 2021 à 12:57. É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 claudex le 08 mars 2021 à 16:56. É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 gUI (Mastodon) le 08 mars 2021 à 08:54. É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 barmic 🦦 le 08 mars 2021 à 12:22. É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 vv222 le 08 mars 2021 à 16:07. É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 gUI (Mastodon) le 08 mars 2021 à 16:53. É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 Anonyme le 09 mars 2021 à 06:48. Évalué à 3.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: Mes serveurs n'intéressent personnes
        
        Posté par gUI (Mastodon) le 09 mars 2021 à 08:29. É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 gouttegd le 09 mars 2021 à 10:47. É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 gUI (Mastodon) le 09 mars 2021 à 14:48. É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 barmic 🦦 le 08 mars 2021 à 18:43. É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 gouttegd le 07 mars 2021 à 20:15. É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 octane le 07 mars 2021 à 21:47. É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 gUI (Mastodon) le 08 mars 2021 à 08:09. É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 harlock974 le 08 mars 2021 à 05:02. É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 Refuznik le 08 mars 2021 à 12:54. É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 AlexTérieur le 08 mars 2021 à 20:25. É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 George_abitbol le 09 mars 2021 à 18:22. É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 gUI (Mastodon) le 10 mars 2021 à 08:32. É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 oinkoink_daotter le 09 mars 2021 à 21:28. É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 Faya le 11 mars 2021 à 19:24. É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 Lutin le 08 mars 2021 à 11:03. É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 vv222 le 08 mars 2021 à 16:15. É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…
  - [^] # Re: Pour les fans d'usines
    
    Posté par Lutin le 08 mars 2021 à 20:19. Évalué à 3.
    
    Je suis dans le même cas que toi :D
    
    D'ailleurs, Factorio est Turing-complet (et c'est loin d'être le seul).
# Compte du nom de la distribution

Posté par Anonyme le 08 mars 2021 à 15:56. É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 vv222 le 08 mars 2021 à 16:20. É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 George_abitbol le 09 mars 2021 à 18:27. É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 Ambroise le 09 mars 2021 à 00:03. É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 George_abitbol le 09 mars 2021 à 19:30. É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 Tibo cocoecolo (site web personnel) le 10 mars 2021 à 15:18. É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.