Je suis nul en sysadminage (j'ai fait des études de maths et d'info théorique, donc je peux parler de calculabilité pendant des heures, mais on me demandait d'expliquer comment fonctionne TCP et les différences avec UDP, je serais bien embêté).
J'administre deux serveurs (pour un forum Discourse, sur https://lilypond.community, mais peu importe).
En consultant les logs pour autre chose, je me suis rendu compte qu'ils étaient infestés par des tentatives échouées de connexion en SSH. Beaucoup. Je sais bien à quoi sert fail2ban, je m'attendais à ce qu'il y en ait, mais pas autant. J'ai des milliers de lignes comme ça :
May 16 22:15:17 ubuntu sshd[26057]: fatal: Timeout before authentication for 79.110.62.145 port 21922
May 16 22:15:09 ubuntu sshd[26044]: fatal: Timeout before authentication for 218.92.0.56 port 47560
May 16 22:14:09 ubuntu sshd[26151]: Connection closed by invalid user ftpuser 64.227.153.88 port 54364 [preauth]
May 16 22:14:09 ubuntu sshd[26151]: Failed password for invalid user ftpuser from 64.227.153.88 port 54364 ssh2
May 16 22:14:07 ubuntu sshd[26151]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=64.227.153.88
May 16 22:14:07 ubuntu sshd[26151]: pam_unix(sshd:auth): check pass; user unknown
May 16 22:14:07 ubuntu sshd[26151]: Invalid user ftpuser from 64.227.153.88 port 54364
May 16 22:13:29 ubuntu sshd[26057]: Failed password for invalid user admin from 79.110.62.145 port 21922 ssh2
Quelques stats :
$ journalctl --since "100 days ago" | rg -o 'pam_unix\(sshd:auth\): authentication failure; .* rhost=([^ ]+)' -r '$1' > ips.txt
$ # ips.txt est la liste des IPs sur les lignes pam_unix(sshd:auth)
$ head -5 ips.txt
85.9.100.253
104.250.50.63
47.184.120.85
182.156.254.122
60.108.212.174
$ wc -l ips.txt
145618 ips.txt
$ sort ips.txt | uniq | wc -l
7084
Sur 100 jours, j'ai donc eu presque 150 000 tentatives de connexion SSH, soit environ une tentative par minute, le tout depuis 7000 IPs différentes.
Sur l'autre serveur, c'est encore pire (celui-ci est un serveur mail) :
$ journalctl --since "100 days ago" | rg -o 'pam_unix\(sshd:auth\): authentication failure; .* rhost=([^ ]+)' -r '$1' > ips.txt
$ head -5 ips.txt
83.229.83.76
218.92.0.39
218.92.0.39
218.92.0.39
13.70.39.68
$ wc -l ips.txt
245861 ips.txt
$ sort ips.txt | uniq | wc -l
8738
soit environ 1,7 connexion par minute, le tout depuis 9000 IPs différentes.
Est-ce que c'est normal d'avoir autant de pirates / botnets / que-sais-je qui font des attaques par force brute ? Notez que fail2ban est activé sur ces deux serveurs, et j'ai vérifié qu'il fonctionnait bien, je n'ose pas imaginer ce que ce serait sans. Est-ce que ça vaut le coup de carrément restreindre l'accès à des clés SSH données (moi et les autres admins) et refuser les connexions par mot de passe, ou bien est-ce que la pollution des logs ne vous dérange pas vraiment ?
# Quelques pistes
Posté par Cyril Brulebois (site web personnel) . Évalué à 10 (+10/-0).
authorized_keys).AllowUsers/AllowGroupspeut être un bon complément (et à nouveau aucun impact sur le bruit dans les logs).Debian Consultant @ DEBAMAX
[^] # Re: Quelques pistes
Posté par gUI (Mastodon) . Évalué à 8 (+6/-1).
Je rajouterais :
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Quelques pistes
Posté par raspbeguy (site web personnel, Mastodon) . Évalué à 3 (+2/-0).
J'utilise la stratégie du VPN. Si le traffic UDP est possible entre toi et ton infra, Wireguard est un très bon candidat pour ce cas d'usage. Le petit plus de Wireguard c'est qu'il ne répond absolument rien si un paquet chiffré avec une clef qu'il ne connaît pas. Concrètement cela signifie que pour un attaquant cherchant à faire du DoS, il n'y a aucun moyen de savoir qu'il y a un service qui écoute sur le port utilisé par Wireguard.
Concernant l'UDP dans le TGV, j'ajoute que personnellement je n'ai jamais eu de soucis.
Un gentil du net
[^] # Re: Quelques pistes
Posté par NeoX . Évalué à 4 (+1/-0).
idem, je fais du wireguard avec un opensense dans le datacenter, et avec la freebox pour me connecter à la maison
aucun souci à me conencter à ces deux serveurs quand je suis en wifi dans le tgv
[^] # Re: Quelques pistes
Posté par Marc Quinton . Évalué à 3 (+1/-0).
pour ma part, j'ai un mix entre :
- autoriser l'accès avec MDP mais uniquement avec une liste d'IP ou masque réseau (local par exemple) ; c'est une white-list ;
- pour les autres, authentification uniquement avec clés ssh.
[^] # Re: Quelques pistes
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 4 (+2/-0).
J'ajoute, pour des bastions ssh dont l'objet est d'être accessible sur le Grand Ternet, sans une partie des options citées ci-dessus :
La blacklist n'est plus si longue, la machine ayant tendance à disparaitre toute seule d'Internet pour ceux qui cherchent (on ne réponds pas à un scanneur).
Pour une machine publique, exposée depuis plus de 15 ans, la blackliste oscille entre 150 et 200 IP (3 jails), en temps normal.
Les tentatives d'attaques qu'on pouvait observer il y a quelques années (avec plusieurs milliers d'IP en BL) sont invisibles maintenant avec les nouvelles jails (aggressive et multiban).
En plus, dans les "scanneurs", y'a toutes ces "entreprises de la CyberSecurity" (à qui j'ai rien demandé) qui vont vouloir proposer leurs services à la moindre faille (vécu). Le multiban a été mis en place exprès pour eux qui font du scan à bas bruit, genre un check toutes les 2h…
mes 2c…
Proverbe Alien : Sauvez la terre ? Mangez des humains !
# Même observation ici !
Posté par rycks . Évalué à 6 (+4/-0).
Avec une grosse recrudescence depuis quelques années … et tout ceci n'est qu'en IPv4 … ça commence même à poser des pb de perfs à force d'ajouter les IP dans iptables/nftables/etc.
Ce qui m'étonne de plus en plus c'est de voir l'origine des ip utilisées qui se diversifie vraiment beaucoup (ce n'est pas un "bloc" est/ouest par exemple)
eric.linuxfr@sud-ouest.org
# Éviter le bruit
Posté par Andre Rodier (site web personnel) . Évalué à 2 (+1/-1).
Sur certains serveurs, pour éviter le bruit, j'ai fini par utiliser une méthode draconienne :
Second méthode: Utiliser un port knocker (standard ou SPA)
Pour la différence entre TCP et UDP, c'est simple:
[^] # Re: Éviter le bruit
Posté par jeanas (site web personnel, Mastodon) . Évalué à 2 (+1/-0).
Merci pour ces pistes, je vais regarder ça.
En fait, j'étais surtout inquiet car cette quantité de connexions me paraissait anormale, mais de ce que je comprends de toutes les réponses, c'est en fait courant. L'Internet est encore moins joli que ce que je croyais !
Oui, je comprends la différence à ce niveau-là. Mais je ne saurais pas expliquer comment s'agencent les bits d'un message TCP (en fait je ne connais même pas la taille moyenne d'un paquet TCP). Je ne cherche pas des réponses à toutes ces questions ici (je suis en train de me renseigner sur les réseaux en ce moment, de manière générale), je dis juste que j'ai beau être compétent en informatique — surtout du côté théorique — j'ignore plein de choses qui font partie des connaissances de base des gens qui administrent de vrais systèmes et réseaux.
# SSH
Posté par tkr (Mastodon) . Évalué à 1 (+0/-0).
en espérant que tu n'aies pas laissé un test:test parmi tes utilisateurs, en redirection NAT depuis la box ;)
https://linuxfr.org/nodes/123507/comments/1902786
j'avais également fait part d'une sorte de proposition de label pour "ultra"-sécuriser ssh par défaut, avec notamment l'usage de clés au lieu du mdp, mais je sais pas si la communauté apprécierait ;)
https://linuxfr.org/users/tkr/journaux/ssh-et-si-nous-sensibilisions-par-un-label-ou-autre-imperatif
je pense que je vais mettre ca sur linuxquestions ;) mais je trouve vraiment dommage que les distros linux ne s'alignent pas sur un label sans mdp pour le ssh.. bien que debian semble par ex, ne pas l'installer par défaut.
# Contrôle d'accès du port
Posté par Thrillseeker . Évalué à 2 (+1/-0).
Depuis la backdoor sur openssh (journal) il est hors de question que le port ssh soit accessible librement sur Internet.
Dans mon cas, j'avais pensé à mettre en place le port-knocking évoqué plus haut, puis j'ai vu que cela allait être chiant pour la partie client. Même chose pour la mise en place d'un VPN pour uniquement l'accès SSH. Donc j'utilise un serveur web et un serveur proxy.
Le serveur web (en https bien sûr, et sécurisé par un mot de passe), permet d'autoriser l'IP actuelle.
Le serveur proxy est un proxy TCP, qui redirige le trafic vers le serveur ssh. A vrai dire, cela pourrait être n'importe quel service, cela redirige le trafic d'un port vers un autre.
Techniquement, le serveur proxy est superflu, le serveur web pourrait changer les règles du firewall (en utilisant tout simplement ipset). Mais il permet une mise en route rapide (sans toucher quoi que ce soit au firewall) et il permet de savoir qui est connecté sur le port à partir de l'interface web.
L'inconvénient est que ssh voit l'IP du proxy, et donc les commandes comme "last" afficheront l'IP du proxy. Personnellement, c'est un inconvénient qui ne me dérange pas.
# Changer de port
Posté par Dareg . Évalué à 3 (+2/-0).
Personnellement je suis passé d'environ une tentative de connexion par minute à zéro depuis que j'ai remplacé le port par défaut par un autre.
Peut-être que je suis seulement chanceux, mais pour moi cette solution simple a suffi pour nettoyer mes logs.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.