Re: Authentification failure

[Florian Blanc <florian.blanc.adm@gmail.com>]

Bon je vais vous livrer un petit secret.

J'utilise des noip qui mettent à jour mon ip public cliente sur un dns.

Sur mon script principal iptables je crée une chain qui s'appelle INDYNAMIC à partir de INPUT:

/sbin/iptables -A INPUT -j INDYNAMIC

Ensuite j'ai un second script iptables pour écraser mes regles dynamique comme ceci:

/sbin/iptables -F INDYNAMIC # ici je flush

/sbin/iptables -A INDYNAMIC -m tcp -p tcp --src lolilol.dyndnsnoiplalala.io --dport 22 -j ACCEPT # j'autorise lolilol.dyndnsnoiplalala.io sur le port 22 (il fait la résolution comme un grand).

je crontab ce dernier script qui s'execute toutes les x minutes (20 par exemple).

tu le combine à fail2ban et c'est bon.

Le jeu. 6 juin 2019 à 15:45, Daniel Caillibaud <ml@lairdutemps.org> a écrit :

Le 06/06/19 à 10:31, Arnaud Gambonnet <arnaud.gambonnet@gmail.com> a écrit :
> Bonjour la liste,
>
> Je n'ai pas lu en détails le fil, mais pour protéger les demandes
> intempestives de connexions ssh (et d'autres si besoin), il existe la
> solution de port knocking.

Pourquoi faire (compliqué) ?

> Ce qui n’empêche pas de mettre en place une authentification par
> certificat et fail2ban pour les services moins sensibles.

Au contraire, auth par certif pour tous les serveurs, sensibles ou pas, et
plus besoin de port knocking ni port exotique ni fail2ban, on peut rester
sur du standard avec ssh sur le port 22 qui fonctionne comme attendu.

--
Daniel

On devient jeune à soixante ans.
Malheureusement c'est trop tard.
Pablo Picasso