Le 06/06/2019 à 20:10, Florian Blanc a écrit :
Lol tu réduis la charge serveur au lieu de laisser ssh écouter et
répondre à tout le net... (valable pour tous les types
d'authentification ssh)
Merci de me faire savoir si je me trompe 👌
Je pense que oui:
. avec tes règles ssh écoute également tout le net, il doit bien savoir
si c'est toi qui tente une connexion
. tu génères du trafic cron inutile toutes les 20mn
. tu génères du trafic pour mettre noip à jour
T'es le meilleur Daniel
Je suis d'accord, sa solution est la meilleure
On Thu, Jun 6, 2019, 19:42 Daniel Caillibaud <m...@lairdutemps.org
<mailto:m...@lairdutemps.org>> wrote:
Le 06/06/19 à 16:51, Florian Blanc <florian.blanc....@gmail.com
<mailto:florian.blanc....@gmail.com>> a écrit :
> 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 <http://lolilol.dyndnsnoiplalala.io>
--dport 22 -j ACCEPT # j'autorise
> lolilol.dyndnsnoiplalala.io <http://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.
C'est bien ce que je disais :
> > Pourquoi faire (compliqué) ?
Car je ne vois aucun avantage par rapport à ne rien faire (en dehors de
virer l'auth par mot de passe si c'est pas déjà le cas).
--
Daniel
Certaines zones de pêche commencent a être tellement polluées
par les hydrocarbures qu'on y pêche des turbots diesels.
Philippe Geluck, Le chat