Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

fail2ban prison qui se vide au reload

gotcha5832

Est ll normal que les prisons se vide quand je reload?

$ sudo fail2ban-client status ssh
Status for the jail: ssh
|- filter
|  |- File list:	/var/log/auth.log 
|  |- Currently failed:	6
|  `- Total failed:	45207
`- action
   |- Currently banned:	[…]
   `- Total banned:	222

$ sudo fail2ban-client reload
$ sudo fail2ban-client status ssh
Status for the jail: ssh
|- filter
|  |- File list:	/var/log/auth.log 
|  |- Currently failed:	0
|  `- Total failed:	0
`- action
   |- Currently banned:	0
   |  `- IP list:	
   `- Total banned:	0

gotcha5832

ca n'inspire personne?

jean-luc5629

gotcha5832 a écritca n'inspire personne?

Salut,

Sans doute que non... 😃

Bannir et collectionner des ip au ban qui ont juste frappées à la porte de ton serveur; au fait ça sert à quoi ? ; tout comme pour portsentry d'ailleurs ...

Vaut mieux renforcer la façon par laquelle on se connecte à ton serveur :

-Des mots de passes dignes de ce nom pour tes connexions web sensibles : (aléatoires avec majuscules, minuscules, chiffres, caractères spéciaux) et d'un longueur > 16 et changés de temps en temps (vaut mieux un mdp de 16 aléatoire et changé tous les 3 mois qu'un de 20 jamais changé..).

-En SSH connexion par clefs exclusivement en 2048 ou + et banissement après test des clefs de la connexion par mot de passe : (PasswordAuthentication no dans le sshd_config).

Et avec çà, tu pourras laisser tous ces gadgets de côté !!! et ça allègera d'autant ton serveur de ces trucs inutiles...

🙂

gotcha5832

J'ai déja mis ces sécu en place

authentification par clé
suppression des connexion par mot de passe.

tu dis que fail2ban est inutile?

jean-luc5629

gotcha5832 a écritJ'ai déja mis ces sécu en place

authentification par clé
suppression des connexion par mot de passe.

tu dis que fail2ban est inutile?

Tout à fait,...à part collectionner des ip sur ton serveur qui ont frappé à la porte, surcharger ton serveur inutilement,...

D'ailleurs si tu as une connexion/clefs exclusivement, regarde dans /var/log/auth.log ....pas grand chose côté SSH !!! et tu remarqueras que quand il y en a, ils n'insistent pas dès qu'ils s'aperçoivent que la connexion n'est pas possible par mot de passe.

J'ai d'ailleurs mis des liens dur ce post :

https://forum.ubuntu-fr.org/viewtopic.php?id=2010240

ET sur mondedie, regarde un peu l'avis de arckosft:

https://mondedie.fr/d/9505-aide-administration-je-l-ai-voulue-je-l-ai-eue/6

moko138

Une nuit où j''étais resté connecté en filaire à une box qui - c'est ce que le forum m'a expliqué ensuite - n'était pas "en mode routeur", j'ai subi des tentatives d'intrusion toutes les onze secondes pendant quatre heures.
C'est ce que contenait au matin mon auth.log.

Depuis, moi qui n'ai ni serveur ni compétences en matière de serveurs, j'installe systématiquement fail2ban (6 échecs ==> bannissement). Et je n'y touche plus.
🙂
Et mon auth.log plafonne à environ 100 kio :

   40,0KiB [          ]  auth.log
   92,0KiB [#         ]  auth.log.1

Ensuite que les spécialistes comme pires et jean-luc5629 puissent t'en dire plus, certainement !

jean-luc5629

Une nuit où j''étais resté connecté en filaire à une box qui - c'est ce que le forum m'a expliqué ensuite - n'était pas "en mode routeur", j'ai subi des tentatives d'intrusion toutes les onze secondes pendant quatre heures.
C'est ce que contenait au matin mon auth.log.

Si t'avais une connexion/clefs exclusivement, je suis très surpris; ça fait plus de 5 ans que j'ai un dédié OVH (pas derrière un routeur ou une box !!!); et voici un exemple sur 2 jours:

May 28 13:50:10 serveur sshd[31193]: Accepted publickey for root from xxx.xxx.xxx.xxx port 30584 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 28 13:50:11 serveur sshd[31196]: Accepted publickey for root from xxx.xxx.xxx.xxx port 30586 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 28 18:58:35 serveur sshd[8432]: Accepted publickey for root from xxx.xxx.xxx.xxx port 4330 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 28 18:58:37 serveur sshd[8435]: Accepted publickey for root from xxx.xxx.xxx.xxx port 4331 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 29 13:42:15 serveur sshd[23375]: Accepted publickey for root from xxx.xxx.xxx.xxx port 5836 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 29 13:42:17 serveur sshd[23378]: Accepted publickey for root from xxx.xxx.xxx.xxx port 5837 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 29 13:50:26 serveur sshd[23999]: Accepted publickey for root from xxx.xxx.xxx.xxx port 5902 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 29 15:44:51 serveur sshd[8478]: Accepted publickey for root from xxx.xxx.xxx.xxx port 6826 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 29 16:20:58 serveur webmin[13269]: Successful login as administration from xxxx.yyyy.com
May 29 16:57:50 serveur sshd[20231]: Accepted publickey for root from xxx.xxx.xxx.xxx port 7219 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 30 09:56:59 serveur sshd[27698]: Accepted publickey for root from xxx.xxx.xxx.xxx port 2742 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 30 09:57:01 serveur sshd[27701]: Accepted publickey for root from xxx.xxx.xxx.xxx port 2743 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 30 10:05:20 serveur sshd[30582]: Accepted publickey for root from xxx.xxx.xxx.xxx port 2765 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 30 17:07:27 serveur sshd[24375]: Accepted publickey for root from xxx.xxx.xxx.xxx port 5392 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 30 17:07:29 serveur sshd[24378]: Accepted publickey for root from xxx.xxx.xxx.xxx port 5393 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 30 17:07:51 serveur sshd[24537]: Accepted publickey for root from xxx.xxx.xxx.xxx port 5395 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 30 17:08:07 serveur sshd[855]: Received signal 15; terminating.
May 30 17:08:07 serveur sshd[24588]: Server listening on 0.0.0.0 port 22.
May 30 17:08:07 serveur sshd[24588]: Server listening on :: port 22.
May 30 17:08:26 serveur sshd[24589]: Accepted publickey for root from xxx.xxx.xxx.xxx port 5397 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 30 17:08:29 serveur sshd[24592]: Accepted publickey for root from xxx.xxx.xxx.xxx port 5398 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 30 17:18:59 serveur sshd[25536]: Accepted publickey for root from xxx.xxx.xxx.xxx port 5478 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 30 17:23:06 serveur sshd[24588]: Received signal 15; terminating.
May 30 17:24:02 serveur systemd-logind[640]: New seat seat0.
May 30 17:24:02 serveur systemd-logind[640]: Watching system buttons on /dev/input/event2 (Power Button)
May 30 17:24:02 serveur systemd-logind[640]: Watching system buttons on /dev/input/event3 (Video Bus)
May 30 17:24:02 serveur systemd-logind[640]: Watching system buttons on /dev/input/event0 (Power Button)
May 30 17:24:02 serveur systemd-logind[640]: Watching system buttons on /dev/input/event1 (Sleep Button)
May 30 17:24:11 serveur sshd[850]: Server listening on 0.0.0.0 port 22.
May 30 17:24:11 serveur sshd[850]: Server listening on :: port 22.
May 30 17:24:15 serveur webmin[847]: Webmin starting
May 30 17:25:04 serveur sshd[1560]: Accepted publickey for root from xxx.xxx.xxx.xxx port 5517 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 30 17:25:06 serveur sshd[1563]: Accepted publickey for root from xxx.xxx.xxx.xxx port 5518 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
May 30 17:26:12 serveur sshd[1721]: Did not receive identification string from 181.26.150.52 port 42984
May 30 17:30:28 serveur sshd[2567]: Accepted publickey for root from xxx.xxx.xxx.xxx port 5650 ssh2: RSA SHA256:5DiL3AWDbd1Rq/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
root@serveur:~#

Juste une tentative (181.26. )....et pourtant le ssh sur le 22; mais comme je dis plus haut, il y a des tentatives, mais jamais d'insistance avec la même ip; donc avec clefs, fail2ban est inutile...

moko138

jean-luc5629,
Il ne s'agissait pas d'un serveur mais de mon poste individuel.

Je viens de retrouver le fil ./viewtopic.php?id=1317431. On y voit que fail2ban installé avait limité à 6 le nombre de tentatives (juillet 2013).

Mais en décembre précédent (2012), 4 heures de tentatives à 11 6 sec. d'intervalle faisaient :
environ 2.400 tentatives.
J'ai aussi retrouvé un extrait de log de décembre 2012 :

Dec  7 01:36:54 mon-pc sshd[8248]: Invalid user PRÉNOM1 from 122.143.4.100
Dec  7 01:36:54 mon-pc sshd[8248]: pam_unix(sshd:auth): check pass; user unknown
Dec  7 01:36:54 mon-pc sshd[8248]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=122.143.4.100
Dec  7 01:36:57 mon-pc sshd[8248]: Failed password for invalid user PRÉNOM1 from 122.143.4.100 port 57927 ssh2
Dec  7 01:37:00 mon-pc sshd[8250]: reverse mapping checking getaddrinfo for 100.4.143.122.adsl-pool.jlccptt.net.cn [122.143.4.100] failed - POSSIBLE BREAK-IN ATTEMPT!

Dec  7 01:37:00 mon-pc sshd[8250]: Invalid user PRÉNOM2 from 122.143.4.100
Dec  7 01:37:00 mon-pc sshd[8250]: pam_unix(sshd:auth): check pass; user unknown
Dec  7 01:37:00 mon-pc sshd[8250]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=122.143.4.100
Dec  7 01:37:02 mon-pc sshd[8250]: Failed password for invalid user PRÉNOM2 from 122.143.4.100 port 58250 ssh2
Dec  7 01:37:06 mon-pc sshd[8252]: reverse mapping checking getaddrinfo for 100.4.143.122.adsl-pool.jlccptt.net.cn [122.143.4.100] failed - POSSIBLE BREAK-IN ATTEMPT!

Dec  7 01:37:06 mon-pc sshd[8252]: Invalid user PRÉNOM3 from 122.143.4.100

On voit :
1) que le compte root n'était pas ciblé, mais des prénoms variés [que j'ai ici remplacés par "PRÉNOM"+ un nombre] comme users possibles.
Ce qui suggère que l'assaillant avait supposé ou détecté que j'utilisais une distribution sans compte root.

2) que l'assaillant connaissait le vrai nom [que j'ai ici remplacé par "mon-pc"] de mon système sur le réseau.

jean-luc5629

@moko138

Justement comme le dit tiramiseb en 2013 dans le post que tu cites:

https://forum.ubuntu-fr.org/viewtopic.php?pid=14044681#p14044681

Pour ma part, j'ai complètement désactivé le mot de passe de "root", je ne passe que par des clés SSH (avec phrases de passe bien sûr) : aucun risque d'être piraté de cette manière-là.

Et, ça reste vrai en 2017...que ce soit sur un serveur direct sur le net ou derrière une box ou autres routeurs avec redirection de ports pour pouvoir s'y connecter de l'extérieur, ou en dmz, ...etc..

Et si tu ne t'étais connecté qu'avec des clefs avec bannissement de la connexion/mdp en 2013; ton attaquant n'aurait pas attendu x heures avant d'abandonner...que ce soit des tentatives compte root ou autres..et si tu appliques cette méthode, je ne pense pas que ton auth.log se remplira très vite...et pour le peu que j'y trouvais, ça fait un moment que j'ai abandonné fail2ban, et ça ne m'a jamais inquiété depuis.

Par contre, toujours garder son système à jour, éviter d'installer des paquets exotiques; surveiller régulièrement avec netstat si tous les ports en écoute sont légitimes; faire écouter le maximum d'applications sur le local car certaines écoutent sur le 0.0.0.0 par défaut alors que pas toujours nécessaire.

Pour un serveur perso, je trouve que ça vaut tous les trucs que la plupart des gens installent suite à des tutos glanés ici et là et par forcément adaptés à leur cas en plus d'être inutiles, mais les installent par ce que ils ont entendu que c'était bien, voir vital !!!

Plus c'est simple, mieux c'est en général...

moko138

Merci !
Mais à part

toujours garder son système à jour, éviter d'installer des paquets exotiques;

(ce que j'applique scrupuleusement),
à partir de

connecté qu'avec des clefs avec bannissement de la connexion/mdp

je ne comprends plus rien ! 🙁

Sur ce forum, j'ai vu quelques retours de netstat : c'était du chinois pour moi...

jean-luc5629

Bonjour,
@moko138

connecté qu'avec des clefs avec bannissement de la connexion/mdp

je ne comprends plus rien !
Sur ce forum, j'ai vu quelques retours de netstat : c'était du chinois pour moi...

Pour le ssh : connexion par clefs et "PasswordAuthentication no" dans /etc/sshd_config ...clair ?

Pour netstat, un exemple basique pour repérer si tout ce qui est en écoute sur ton serveur est légitime:

root@serveur:~# netstat -lntup | grep LISTEN
tcp        0      0 0.0.0.0:54321           0.0.0.0:*               LISTEN      4253/transmission.j
tcp        0      0 0.0.0.0:54322           0.0.0.0:*               LISTEN      849/transmission.ch
tcp        0      0 0.0.0.0:54323           0.0.0.0:*               LISTEN      838/transmission.in
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      844/named
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      10771/sshd
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1648/exim4
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      844/named
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      901/nginx: master p
tcp        0      0 127.0.0.1:51421         0.0.0.0:*               LISTEN      4253/transmission.j
tcp        0      0 127.0.0.1:51422         0.0.0.0:*               LISTEN      849/transmission.ch
tcp        0      0 127.0.0.1:51423         0.0.0.0:*               LISTEN      838/transmission.in
tcp        0      0 127.0.0.1:8000          0.0.0.0:*               LISTEN      1118/gunicorn: mast
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      1094/mysqld
tcp        0      0 127.0.0.1:11211         0.0.0.0:*               LISTEN      845/memcached
tcp        0      0 127.0.0.1:10000         0.0.0.0:*               LISTEN      1232/perl
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      901/nginx: master p
tcp6       0      0 :::54321                :::*                    LISTEN      4253/transmission.j
tcp6       0      0 :::54322                :::*                    LISTEN      849/transmission.ch
tcp6       0      0 :::54323                :::*                    LISTEN      838/transmission.in
tcp6       0      0 :::22                   :::*                    LISTEN      10771/sshd
root@serveur:~#

-Les 3 premières lignes, je vois 3 sessions de transmission (54321,54322,54326) écoutant sur le 0.0.0.0 (ou ::: pour ipv6) c'est à dire le net; dans mon cas ceci est normal puisque j'ai mis en place ces 3 sessions, et il faut bien qu'elles écoutent sur le 0.0.0.0 pour échange avec les peers.
-Le ssh sur le 22 : normal
-nginx sur le 80 et 443 : normal

Tout le reste n'écoute qu'en local:
Mais certaines applications dans mon cas je leur ai forcé la main en modifiant leur configuration pour les forcer à n'écouter qu'en local (127.0.0.1); mais celles ci j'en ai l'utilité sinon il m'aurait suffit de les désinstaller.

-Par exemple les 3 sessions de transmission; logiquement par défaut le rpc de transmission écoute sur le 0.0.0.0:9091 pour pouvoir joindre l'interface web de ce soft; dans mon cas, j'ai modifié le settings.json pour que le rpc écoute sur le 127.0.0.1; et donc pour pouvoir joindre mon interface web de chaque session de transmission j'utilise un reverse-proxy dans nginx qui de toute façon est ouvert, celà permet de diminuer dans cet exemple 3 ports d'écoute vers l'extérieur.

-Idem pour perl qui écoute sur le 127.0.0.1:10000; en réalité c'est webmin que je joins aussi via le reverse proxy de nginx
-Idem pour le port 8000 vers reverse proxy, pour bind, mysql,.... n'ont pas lieu d'écouter que sur le 127.0.0.1

Netstat est pour moi un outil permettant de repérer sur le serveur si toutes les applications communiquantes sont légitime.

-Soit toutes les applications sont légitimes, on revient revérifier ceci de temps en temps quand même au cas ou, et sinon après chaque installation de nouvelle application.

-Si ça ne l'est pas soit ton système est corrompu et qu'un truc non désiré communique avec l'extérieur.

-Soit c'est un truc qui s'est installé pour satisfaire la dépendance d'une autre application; dans ce cas à toi de juger si celle ci a lieu réellement d'écouter sur le 0.0.0.0 ou si tu ne peux pas la mettre en listen local.

Sinon désinstaller les applications en écoute qui ne sont pas nécessaires.

Regarde le man de netstat, il y a pas mal de possibilités pour ensuite affiner les informations en fonction des paramètres utilisés.

moko138

jean-luc5629 a écritNetstat est pour moi un outil permettant de repérer sur le serveur si toutes les applications communiquantes sont légitimes.

Merci de cette définition !
Et merci de ton mode d'emploi simplifié !

$ sudo -s
[sudo] password for : 
root@mon-pc:~# netstat -lntup | grep LISTEN
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      15439/dnsmasq   
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      24771/cupsd     
root@mon-pc:~# exit
... $

- -

Pour le ssh : connexion par clefs et "PasswordAuthentication no" dans /etc/sshd_config ...clair ?

Euh... non : je n'ai jamais utilisé ssh ni sshd. Tu me fais donc découvrir que j'ai un fichier
/etc/ssh/ssh_config (sans "d"). En excluant les lignes commentées, il contient :

Host *
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no

Dois-je remplacer GSSAPIAuthentication yes par GSSAPIAuthentication no ?
- -

À ma connaissance, je n'ai jamais installé de serveur, sauf remmina et vino... jadis. Et que je n'ai pas maîtrisés. (Peut-être bien à l'époque des tentatives d'intrusion.)
D'où ma stupeur : je me branche en filaire à une box de ma famille... et paf !

jean-luc5629

@moko138

J'ai été trop vite dans mes écritures !!! c'est : /etc/ssh/sshd_config en réalité.. qui correspond à la partie config serveur
Toi tu as : /etc/ssh/ssh_config qui correspond à la partie config client

Mais t'en as sans doute pas l'utilité; moi c'est sur un serveur chez ovh, et à domicile je n'ai besoin que du client au minimum pour m'y connecter.

LanXor

@gotcha5832 ------------------------------------------------------------------------------------------

Pour répondre à ta question explicitement :
Oui c'est normal que les IP Bannis par Fail2Ban se réinitialise lorsque que tu "reload" le service Fail2Ban.

Fail2Ban écrit de nouvelles règles dans le service iptables pour pouvoir bloquer des couples IP/PORT.
Pour ce faire il crée de nouvelles tables spécifiques dans le service iptables qu'il gère lui même.
Lorsque tu lance le service Fail2Ban, il va crée les tables, analyser les logs, bannir en ajoutant des règles dans ces tables.
Ensuite lorsque tu stop le service Fail2Ban il va supprimer les tables qu'il a crée.
Lorsque tu "reload" il "stop" et "start" le service. Ce qui fait que les adresses bannis ultérieurement sont supprimé définitivement.

Vulgairement on pourrais dire que Fail2Ban est une sorte de cache d'adresse bannis.

@jean-luc5629 -------------------------------------------------------------------------------------------

Je voudrais cependant revenir sur ce tu as dis !
Tu dis que Fail2Ban est inutiles. Je voudrais te contredire sur ce sujet tout en relativisant sur serveur dédié chez ovh.

Oui je suis d'accord que Fail2Ban est un outils gadgets. Cependant il est utile à de nombreuse occasion. En effet si tu as fais de la sécurité informatique, où même que tu t'es renseigner sur les différentes attaques réseaux. Tu devrais savoir que aujourd'hui toutes les personnes qui "frappe à ta porte" ne sont pas toutes aussi gentil que des humains bien intentionné.
Je veux parler des BOTS qui automatise les taches sans chercher à comprendre. Ils peuvent se faire passé pour un utilisateur "raisonnable" (je veux dire par là qu'il ne se différencie pas à l'utilisation normal d'un utilisateur humain, ex: visite d'une page web normal)
Ou directement faire du brut-force explicitement.
Dans ce dernier cas il faut pouvoir se protéger de manière automatique et instantané.

Oui avec le protocole SSH tu as la possibilité de définir exclusivement une clé pour te connecter.
Seulement d'autre service n'ont pas besoins d'authentification. Serveur web, serveur dns. Dans ces dernier cas il est utile d'envisager des moyens drastique pour contrôler les mauvais utilisateur.

Je peux comprendre que personnellement tu n'utilise pas ce genre d'outils car tu utilise un serveur dédier qui est contrôlé par ovh. En effet même si c'est un serveur dédier, ovh contrôle les différents accès à ton serveur et ont différents moyen d'éviter ce genre de désagrément (qualité de service). C'est pour cela que tu retrouve moins d'attaque dans tes logs.

gotcha5832

Merci à vous

jean-luc5629

LanXor : Je peux comprendre que personnellement tu n'utilise pas ce genre d'outils car tu utilise un serveur dédier qui est contrôlé par ovh. En effet même si c'est un serveur dédier, ovh contrôle les différents accès à ton serveur et ont différents moyen d'éviter ce genre de désagrément (qualité de service). C'est pour cela que tu retrouve moins d'attaque dans tes logs.

Que tu utilises, ovh, online, hetzner ou autres, ils ont tous des protection anti-ddos, des sondes sur chaque serveur détectant les anomalies ...un prestataire sans ceci, ça doit être rare !!!

Mais ce n'est pas çà qui réduit les logs sur ton serveur; au début je me connectais comme beaucoup en ssh par login et mot de passe, en bannissant le login via root; et tous les jours, j'avais des centaines de tentatives, voir +; depuis que je suis passé chez le même prestataire en connexion/clefs exclusivement, paradoxalement il n'y en a plus que quelques unités !!! et je me connecte en root comme tu peux le voir + haut...

Je pencherais plutôt sur le fait que les bots qui scannent les serveurs identifient la réponse du serveur ssh, et en fonction de celle ci, quand ils identifient que la connexion par mot de passe est impossible sur ce serveur, et ils passent au serveur suivant; c'est d'ailleurs pour celà que dans les logs on ne voit pas la même ip successivement.