> Et ça change vraiment grand chose ? cf. modele OSI ton firewall refusera les connexions layer 3/4.
> C'est ça que je comprends pas trop, quel rapport avec ip fixe ou pas ? > Sans ip fixe ça fonctionne aussi très bien avec un ssh classique sur le > port 22 (sans ces règles iptables). Si client avec ip fixe, tu ajoutes ta règle définitivement. Si client avec ip dynamique ou nomade, ta règle doit évoluer .. (d'où l'utilisation du noip avec cron). > Ta solution bloque le port 22 si on arrive pas de la bonne ip, qu'elle soit > fixe ou pas, et c'est ça que je trouve pas très utile (car me concernant > je veux pas restreindre l'accès ssh à une seule ip, mais je pensais surtout > au gain du port fermé si on vient pas du bon endroit vs l'énergie à déployer > pour maintenir ces règles et la perte potentielle de temps le jour où on > voudra comprendre pourquoi un truc standard marche pas), mais ça reste mon > avis, y'a pas de jugement de valeur. bin une règle par ip ( ou noip )/range/network. le reste du traffic non legit => DROP. (la requête est encaissée mais pas de retour client ni de propagation). Le ven. 7 juin 2019 à 14:25, Daniel Caillibaud <m...@lairdutemps.org> a écrit : > Le 07/06/19 à 03:53, Florian Blanc <florian.blanc....@gmail.com> a écrit : > > Alors non ssh ne recevra seulement les requêtes provenant de l'adresse Ip > > autorisée dans iptables tu le sais, donc tout le reste du traffic sera > > traité par iptables et non par le service. > > Et ça change vraiment grand chose ? > > Car un ssh qui écoute, ouvre une connexion pour attendre une clé et > referme, même avec des ssh souvent attaqués en bruteforce, ça se voit pas > sur mes mesures tellement c'est négligeable devant le reste. > > Avec ta solution iptables ça lui fait une chaîne de plus à traiter pour > chaque paquet entrant, ça doit pas être bien cher non plus mais je ne suis > pas sûr que ce soit meilleur coté perfs (j'en sais rien, et amha la perf > n'est pas le pb ici). > > > Effectivement je flush une chaîne iptables et je réinsére mes (3)règles > > (dynamiques seulement) avec résolution dns(3) toutes les 20 minutes. > Alors > > bench le si tu veux mais c'est rien comparé aux flux que tu as si tu > > laisse tout le monde accéder jusqu'à l'authentification du service. > > (3 car 3 postes clients, même plus ça serait pas un problème). > > > > Et pour finir la mise à jour du noip c'est côté client donc ça c'est pas > > un problème on en parle même pas. > > > > Ma solution n'est pas la meilleure mais c'est une bonne alternative si on > > n'a pas d'ip fixe côté client bien entendu. > > C'est ça que je comprends pas trop, quel rapport avec ip fixe ou pas ? > > Sans ip fixe ça fonctionne aussi très bien avec un ssh classique sur le > port 22 (sans ces règles iptables). > > Ta solution bloque le port 22 si on arrive pas de la bonne ip, qu'elle soit > fixe ou pas, et c'est ça que je trouve pas très utile (car me concernant > je veux pas restreindre l'accès ssh à une seule ip, mais je pensais surtout > au gain du port fermé si on vient pas du bon endroit vs l'énergie à > déployer > pour maintenir ces règles et la perte potentielle de temps le jour où on > voudra comprendre pourquoi un truc standard marche pas), mais ça reste mon > avis, y'a pas de jugement de valeur. > > Amicalement, > > -- > Daniel > > Un clavier azerty en vaut deux. > >
