gratifiant > linux.debian.user.french

Florian Blanc (06/06/2019, 20h20)
Lol tu réduis la charge serveur au lieu de laisser ssh écouter etrépondre
à tout le net... (valable pour tous les types d'authentification ssh)
Merci de me faire savoir si je me trompe ?
T'es le meilleur Daniel

On Thu, Jun 6, 2019, 19:42 Daniel Caillibaud <ml> wrote:
[..]
Daniel Huhardeaux (06/06/2019, 23h30)
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
[..]
Florian Blanc (07/06/2019, 04h00)
C'est dommage on arrive dans tes retranchements, pour quelqu'un
d'omniscient ça doit faire bizarre.

Alors non ssh ne recevra seulement les requêtes provenant de l'adresseIp
autorisée dans iptables tu le sais, donc tout le reste du traffic sera
traité par iptables et non par le service.

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.
Si tu es nomade, cette solution peut t'intéresser également.

C'est dommage car c'est pas la première fois que je te vois répondre ici et
tu as plein de connaissances. Malheureusement tu n'aime vraiment pas le
contre exemple ou solution qui ne va pas en ton sens.
Cependant t'as une bonne habileté rhétorique en général..

Un esprit humble plus communautaire et moins "mentorisé" serait apprécié.

Pour finir, iptables est livré avec un hitcount qui est très utile si vous
êtes capable de définir un nombre max de hit sur une durée par user pour
tel service. Finissez avec Fail2ban qui regarde les logs. (Ceux utilisant
des certificats ne sont pas exempts).

Bonne journée.
Daniel Caillibaud (07/06/2019, 14h30)
Le 07/06/19 =C3=A0 03:53, Florian Blanc <florian.blanc.adm> a =C3=
=A9crit :
> Alors non ssh ne recevra seulement les requ=C3=AAtes provenant de l'adres= se Ip
> autoris=C3=A9e dans iptables tu le sais, donc tout le reste du traffic s= era
> trait=C3=A9 par iptables et non par le service.


Et =C3=A7a change vraiment grand chose ?

Car un ssh qui =C3=A9coute, ouvre une connexion pour attendre une cl=C3=A9 =
et
referme, m=C3=AAme avec des ssh souvent attaqu=C3=A9s en bruteforce, =C3=A7=
a se voit pas
sur mes mesures tellement c'est n=C3=A9gligeable devant le reste.

Avec ta solution iptables =C3=A7a lui fait une cha=C3=AEne de plus =C3=A0 t=
raiter pour
chaque paquet entrant, =C3=A7a doit pas =C3=AAtre bien cher non plus mais j=
e ne suis
pas s=C3=BBr que ce soit meilleur cot=C3=A9 perfs (j'en sais rien, et amha =
la perf
n'est pas le pb ici).

[..]
>=20
> Ma solution n'est pas la meilleure mais c'est une bonne alternative si on
> n'a pas d'ip fixe c=C3=B4t=C3=A9 client bien entendu.


C'est =C3=A7a que je comprends pas trop, quel rapport avec ip fixe ou pas ?

Sans ip fixe =C3=A7a fonctionne aussi tr=C3=A8s bien avec un ssh classique =
sur le
port 22 (sans ces r=C3=A8gles iptables).=20

Ta solution bloque le port 22 si on arrive pas de la bonne ip, qu'elle soit
fixe ou pas, et c'est =C3=A7a que je trouve pas tr=C3=A8s utile (car me con=
cernant
je veux pas restreindre l'acc=C3=A8s ssh =C3=A0 une seule ip, mais je pensa=
is surtout
au gain du port ferm=C3=A9 si on vient pas du bon endroit vs l'=C3=A9nergie=
=C3=A0 d=C3=A9ployer
pour maintenir ces r=C3=A8gles et la perte potentielle de temps le jour o=
=C3=B9 on
voudra comprendre pourquoi un truc standard marche pas), mais =C3=A7a reste=
mon
avis, y'a pas de jugement de valeur.

Amicalement,

--=20
Daniel

Un clavier azerty en vaut deux.
Florian Blanc (07/06/2019, 16h50)
> 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 <ml> a
écrit :
[..]
Daniel Caillibaud (07/06/2019, 17h50)
Le 07/06/19 =C3=A0 16:39, Florian Blanc <florian.blanc.adm> a =C3=
=A9crit :
> > Et =C3=A7a change vraiment grand chose ?


> cf. modele OSI ton firewall refusera les connexions layer 3/4.


Merci ;-)

Ce que je voulais dire, c'est que le gain de perfs[1] est tellement
n=C3=A9gligeable que je pense qu'on arrive m=C3=AAme pas =C3=A0 le mesurer =
sur une machine
en prod (qui bosse).

Mais ici le pb est pas tellement la perf, tu veux bloquer des connexions
ssh avec un liste blanche d'ip (dynamique dans ton cas), =C3=A7a n'est pas
envisageable dans mon contexte (mes ssh publics doivent rester accessibles
par trop d'ip =E2=89=A0 qui changent tout le temps), et sur le fond je vois=
pas
d'int=C3=A9r=C3=AAt =C3=A0 s=C3=A9curiser davantage ssh que de forcer la co=
nnexion par cl=C3=A9.

[1] si y'en a un, faudrait comparer ce que co=C3=BBte une r=C3=A8gle iptable
suppl=C3=A9mentaire (qq cycles cpu sur tous les paquets re=C3=A7us) vs qq c=
onnexions
ssh inutiles (sshd doit attendre une cl=C3=A9 qui ne vient pas puis couper).

--=20
Daniel

La m=C3=A9decine est un m=C3=A9tier dangereux :
les clients qui ne meurent pas peuvent porter plainte.
Coluche
Eric Degenetais (07/06/2019, 18h40)
bonjour,
si on peut lister les URL légitimes, un silent DROP systématique permet de
ne pas confirmer la présence d'une cible potentielle, non ?
À l'inverse, fail2ban, qui est utile quoi qu'il arrive pour arrêter les
tentatives de brute force qui atteignent le service protégé, a besoin
d'enregistrer un certain nombre d'échecs avant de bannir, donc l'existence
et la nature de la cible (sshd) sont confirmées à l'attaquant.

Éric Dégenètais

Le ven. 7 juin 2019 17:48, Daniel Caillibaud <ml> a écrit :
[..]
Florian Blanc (07/06/2019, 18h40)
> si on peut lister les URL légitimes, un silent DROP systématique permet
de ne pas confirmer la présence d'une cible potentielle, non ?
exactement

Le ven. 7 juin 2019 à 18:34, Eric Degenetais <edegenetais> a
écrit :
[..]
Florian Blanc (07/06/2019, 18h50)
le client va timeout

Le ven. 7 juin 2019 à 18:39, Florian Blanc <florian.blanc.adm> a
écrit :
[..]
daniel huhardeaux (07/06/2019, 19h40)
Le 07/06/2019 à 18:40, Florian Blanc a écrit :
> le client va timeout


Sauf qu'un attaquant ne va pas utiliser des scanners habituels mais des
outils spécifiques qui pour eux DROP ou REJECT ne change rien, leur
timeout sera très court

Une lecture par ex.


[..]
Florian Blanc (07/06/2019, 20h30)
Je persiste et signe qu'un DROP est je ne sais combien de fois mieux qu'un
REJECT sur du traffic non legit.
Il le bénéfice de masquer ton service.
Le botnets peuvent avoir le timeout qu'ils veulent même de 1s c'est pas un
problème.
Justement à chaque DROP tu économise un ICMP destination-unreachable par
rapport au REJECT...

après niveau lectures tu trouveras toujours de tout du style: les
reptiliens existent et voici un peu de lecture :


Le ven. 7 juin 2019 à 19:37, daniel huhardeaux <no-spam> a
écrit :
[..]
steve (14/06/2019, 22h40)
Le 05-06-2019, à 14:23:04 +0200, Yahoo a écrit :

>Il est donc possible que 2222 soit trop simple


C'est ce qui semble en effet. J'ai choisi un port différent (guess what)
et depuis 4 jours, pas une seule tentative !

Discussions similaires