Possible SYN flooding on port 22. Sending cookies. Check SNMP counters

[crustyourmind]

Bonsoir

Mon serveur YunoHost

Matériel: Olimex lime 2, autohébergé
Version de YunoHost: 4.2.8.3 (stable). A jour.
J’ai accès à mon serveur : En SSH
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non
Si oui, expliquer:

Description du problème

La sortie de dmesg me donne cette ligne que j’ai du mal interpréter

TCP: request_sock_TCP: Possible SYN flooding on port 22. Sending cookies. Check SNMP counters

Quelqu’un peut il m’aiguiller ?

Merci d’avance

[wbk]

Bonjour,

Excuser ma Francais, c’est tres mal, mais j’essayez le pour la prateque
De plus je n’ai pas 100% de la reponse.

Au Wikipedia il y a une description du 3-way-handshake de TCP. Le premier pas est ‘SYN’.

Imaginer si votre ordinateur pouvait repondre 10 foix par seconde. Quand il y a moins de 10 SYN requets, il n’y a pas de probleme.

Quand il y a plus de 10 requets, votre serveur a un probleme: la 11e requet ne recu pas une reponse. Le service a ete refuse.

Les 11 requets peut etre les visiteurs valide, c’est tant pis pour le 11e visiteur.
A l’autre cote les premiere 10 requets peut etre d’un attaque par ‘SYN inondation’, un voie du DoS.

L’Olimex n’est pas tres lentement, ma aussi pas rapidement quand il y a beaucoup de services.
Port 22 pour SSH est tres aime pour essayez d’acces.

Quand vous regardez
tail -f /var/log/auth.log
est ca tres occupe?

Et dans top / htop, est l’Olimex tres occupe?

On peut agrandir le numbre des requets autorisee. Red Hat a un article en Anglais.

[crustyourmind]

Merci beaucoup pour réponse et les explications

Thx a lot for your answer and explanations. No pb with your french, I understand all, my english is worst

C’est apparu suite à une mise à jour de navidrome depuis plus rien.

It’s appear after a navidrome update, since nothing.

bpyTOP seems OK

Par contre il semble y a avoir de l’activité via tail -f /var/log/auth.log , je ne sais trop quoi en penser

On the other hand there seems to be some activity via tail -f /var/log/auth.log, I don’t really know what to think about i

sudo  tail -f /var/log/auth.log
Oct 16 10:10:02 crust CRON[10185]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 16 10:10:06 crust CRON[10185]: pam_unix(cron:session): session closed for user root
Oct 16 10:10:17 crust sshd[10190]: Connection from 82.156.232.205 port 50538 on 192.168.0.46 port 22
Oct 16 10:10:18 crust sshd[10190]: Invalid user lca from 82.156.232.205 port 50538
Oct 16 10:10:18 crust sshd[10190]: pam_unix(sshd:auth): check pass; user unknown
Oct 16 10:10:18 crust sshd[10190]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=82.156.232.205 
Oct 16 10:10:20 crust sshd[10190]: Failed password for invalid user lca from 82.156.232.205 port 50538 ssh2
Oct 16 10:10:23 crust sshd[10190]: Received disconnect from 82.156.232.205 port 50538:11: Bye Bye [preauth]
Oct 16 10:10:23 crust sshd[10190]: Disconnected from invalid user lca 82.156.232.205 port 50538 [preauth]
Oct 16 10:11:46 crust sudo:    admin : TTY=pts/0 ; PWD=/home/admin ; USER=root ; COMMAND=/usr/bin/tail -f /var/log/auth.log
Oct 16 10:11:46 crust sudo: pam_unix(sudo:session): session opened for user root by admin(uid=0)
Oct 16 10:11:54 crust sshd[10199]: Connection from 47.254.215.122 port 46858 on 192.168.0.46 port 22
Oct 16 10:11:55 crust sshd[10199]: Invalid user kjt from 47.254.215.122 port 46858
Oct 16 10:11:55 crust sshd[10199]: pam_unix(sshd:auth): check pass; user unknown
Oct 16 10:11:55 crust sshd[10199]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=47.254.215.122 
Oct 16 10:11:56 crust sshd[10199]: Failed password for invalid user kjt from 47.254.215.122 port 46858 ssh2
Oct 16 10:11:57 crust sshd[10199]: Received disconnect from 47.254.215.122 port 46858:11: Bye Bye [preauth]
Oct 16 10:11:57 crust sshd[10199]: Disconnected from invalid user kjt 47.254.215.122 port 46858 [preauth]
Oct 16 10:11:59 crust sshd[10202]: Connection from 106.53.139.191 port 51960 on 192.168.0.46 port 22
Oct 16 10:12:00 crust sshd[10202]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=106.53.139.191  user=root
Oct 16 10:12:03 crust sshd[10202]: Failed password for root from 106.53.139.191 port 51960 ssh2
Oct 16 10:12:04 crust sshd[10202]: Received disconnect from 106.53.139.191 port 51960:11: Bye Bye [preauth]
Oct 16 10:12:04 crust sshd[10202]: Disconnected from authenticating user root 106.53.139.191 port 51960 [preauth]
Oct 16 10:12:23 crust sshd[10204]: Connection from 115.246.73.210 port 35310 on 192.168.0.46 port 22
Oct 16 10:12:24 crust sshd[10204]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=115.246.73.210  user=root
Oct 16 10:12:27 crust sshd[10204]: Failed password for root from 115.246.73.210 port 35310 ssh2
Oct 16 10:12:28 crust sshd[10204]: Received disconnect from 115.246.73.210 port 35310:11: Bye Bye [preauth]
Oct 16 10:12:28 crust sshd[10204]: Disconnected from authenticating user root 115.246.73.210 port 35310 [preauth]

J’ai environ une ou deux tentative d’identification par minute d’ip différentes

Merci pour tout, thx for all

[wbk]

Merci pour votre mots gentilles

@crustyourmind

C’est apparu suite à une mise à jour de navidrome depuis plus rien.

It’s appear after a navidrome update, since nothing.

Pendant la mise a jour l’Olimex est tres occupe, peut-etre il n’ y a pas plus de resources pour ‘tout’ les requests SSH.

During the update the Olimex is quite busy, maybe there were not enough resources available for ‘all’ those SSH requests.

@crustyourmind

Par contre il semble y a avoir de l’activité via tail -f /var/log/auth.log , je ne sais trop quoi en penser

On the other hand there seems to be some activity via tail -f /var/log/auth.log, I don’t really know what to think about i

Toute systeme connecte sur le Net a un auth.log comme ca. Fail2ban est installe pour changer le pare-feu dynamique: apres quelques rejets, l’ IP ne peut pas connecte.

All systems on the Net have an auth.log like that. Fail2ban is installed to dynamically change the firewall: after a few rejected logins, the IP is not allowed to connect anymore.

[jarod5001]

Moi aussi j’avais remarqué une activité anormale sur le port 22. J’avais un tas de tentatives de connexion depuis des ip chinoises. J’ai alors décidé de fermer le port 22 du routeur puisque je me connecte rarement en ssh depuis l’extérieur.
Il y a un hook sur le forum pour restreindre l’accès selon l’origine géographique de l’adresse ip. Vous pouvez ainsi restreindre l’accès à votre serveur pour certains pays selon l’origine géographique de vos utilisateurs.

Le hook numéro 6 :

Share your "hooks" to apply custom configurations- Partagez vos "hooks" pour appliquer des configurations personnelles

English version Translate with DeePL A “hook” allows you to apply personal configurations to Yunohost files without the system detecting them as modified. Without a hook, Yunohost does not update these files and this is a real risk in terms of security and system stability. This is especially true with SSH by modifying sshd_config. The solution without a hook is to run the following command after each update to see if there have been any changes: yunohost tools regen-conf -n -d If the…

[metyun]

Bonjour,

Pour info le hook ne restreint que l’accès Web concernant le service Nginx. De plus seul il n’est pas suffisant, il faut l’associer au script de mise à jour de la base d’ip, voir le tuto, je l’ai mis à jour aujourd’hui.
Pour SSH, un changement du port limite le “bruit” émis dans les logs, il existe une commande yunohost pour ça. Une connexion par clefs plutôt que par mot de passe augmente fortement la sécurité. Sinon effectivement le plus simple est de fermer le port SSH sur la box lorsqu’on administre le serveur uniquement en local.