Bloquer des tentatives d'intrusions SSH automatiquement

Je ne me connecte que depuis chez moi, donc je n’autorise que mon adresse IP à se connecter en ssh. Utiliser knockd me permet d’accéder au serveur depuis n’importe ou si par hasard j’en ai besoin.

Pour ce qui est de changer le port, ca sert surtout à bloquer des gens qui ont peu de chance d’arriver à leur fin. J’ai arrêté depuis que j’ai réussi à trouver mon port ssh (et si j’y suis arrivé…)

[quote=“lol”]Salut,
A mon sens c’est un peu beaucoup pour protéger un ssh. C’est intéressant et amusant…

Un simple changement de port et un mot de passe blindé suffisent.

Vous connaissez beaucoup de monde qui avec les précautions cités plus haut se sont fait hacker ?[/quote]
Ben il suffit qu’une faille 0-day soit exploitée automatiquement par un vers et tu risques d’être mal, surtout si elle permet une escalade de privilèges. Ca n’arrive pas tous les 4 matins mais le but est justement de se prémunir de ce genre de choses.

[quote=“Cluxter”][quote=“lol”]Salut,
A mon sens c’est un peu beaucoup pour protéger un ssh. C’est intéressant et amusant…

Un simple changement de port et un mot de passe blindé suffisent.

Vous connaissez beaucoup de monde qui avec les précautions cités plus haut se sont fait hacker ?[/quote]
Ben il suffit qu’une faille 0-day soit exploitée automatiquement par un vers et tu risques d’être mal, surtout si elle permet une escalade de privilèges. Ca n’arrive pas tous les 4 matins mais le but est justement de se prémunir de ce genre de choses.[/quote]

Oui, encore faut-il connaitre le port…
S’il est au dessus des 1024, la probabilité d’un scan est très très (très) faible.
Et avec un fail2ban dessus, le soleil à le temps d’être englouti dans le trou noir de la voie lactée avant que le mot de passe ne soit cassé…

[quote=“Clochette”][quote=“ricardo”]Va falloir que j’étudie ça de façon plus approfondie car c’est opaque pour moi.
Je ne comprends pas comment faire “toc-toc” à mon serveur étant en dehors du LAN et sans possibilité de connexion SSH et surtout de façon sécurisée ?
Si tu as un bon tuto, je suis preneur.[/quote]

Par exemple pour une première approche :
http://www.debianworld.org/securite.knockd

Après si ce n’est que pour gérer l’ouverture/fermeture du port SSH c’est assez simple, mais pour automatisé plus de choses il te faut un script derrière que tu appellera avec la ‘commande’ dans la configuration du démon knockd.[/quote]
Une dernière question avant de ma lancer :
à quoi correspond cette IP (91.207.12.87) dans le lien que tu donnes ?
signification du ‘-v’ ?

$ knock -v 91.207.12.87 6666 7532 9123

:006

[quote=“Cluxter”]
Ben il suffit qu’une faille 0-day soit exploitée automatiquement par un vers et tu risques d’être mal, surtout si elle permet une escalade de privilèges. Ca n’arrive pas tous les 4 matins mais le but est justement de se prémunir de ce genre de choses.[/quote]
Je ne pense pas q’un vers exploite une faille 0-day, ce serait vraiment un gachis incroyable.

[quote=“ricardo”][quote=“Clochette”][quote=“ricardo”]Va falloir que j’étudie ça de façon plus approfondie car c’est opaque pour moi.
Je ne comprends pas comment faire “toc-toc” à mon serveur étant en dehors du LAN et sans possibilité de connexion SSH et surtout de façon sécurisée ?
Si tu as un bon tuto, je suis preneur.[/quote]

Par exemple pour une première approche :
http://www.debianworld.org/securite.knockd

Après si ce n’est que pour gérer l’ouverture/fermeture du port SSH c’est assez simple, mais pour automatisé plus de choses il te faut un script derrière que tu appellera avec la ‘commande’ dans la configuration du démon knockd.[/quote]
Une dernière question avant de ma lancer :
à quoi correspond cette IP (91.207.12.87) dans le lien que tu donnes ?
signification du ‘-v’ ?

$ knock -v 91.207.12.87 6666 7532 9123

:006[/quote]

l’IP présenté est un exemple de cible où faire ‘toc toc’.
Remplace l’Ip par celle à laquelle tu souhaite présenté ta séquence.

1/ C’est l’adresse du serveur, donc ?
2/ Pour tester, puis-je le faire avec des IPs locales ?
3/ -v ?

J’ai commencé le test, selon http://www.debianworld.org/securite.knockd cité par Clochette mais j’ai dû louper une étape car :

De ma machine client, j’ai donc tapé

réponse :

J’me suis dit qu’il fallait certainement installer le paquet sur le client mais :

ricardo@sid:~$ apt-cache policy knock N: Impossible de trouver le paquet knock

Question :
Dois-je aussi installer le paquet “knockd” sur le client :question:

On peut voir que /usr/bin/knock est inclus dans le paquet knockd.

Oui, je me doutais que c’était ça mais je trouve bizarre de devoir installer un paquet complet sur un client, alors que l’on doit certainement n’avoir besoin que d’une partie.

J’ai déjà eu le cas avec le paquet dns2tcp qui contient à la fois le client et le serveur, avec le serveur désactivé par défaut.

C’est vrai qu’on est prévenu du besoin d’activation du serveur : 0==1.
Il ne me reste plus qu’à tester tout ça et à voir s’il n’y a pas trop de confusion avec mes règles existantes.
Réponse sitôt que j’aurai trouvé le moyen de passer par une autre IP.
Je vais ptet essayer avec mon smart en modem mais ce n’est pas toujours évident.