Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Philippe Bourcier]

Re,

Je vais faire un peu le SAV Crowdsec (je précise que je n'ai pas de billes dans 
cette société).
Mais c'est un projet Français fait par des gens que je connais et apprécie et 
qui ont pensé à beaucoup des points évoqués ci-dessous.
D'ailleurs, ils ont fait une prez lors d'une réunion FRnOG, si vous voulez...
https://www.dailymotion.com/video/x8asnpp?playlist=x7hb3i

> J'ai trois objections à propos d'une protection participative telle que 
> crowdsec :
> 
> 1. les règles de détection d'une attaque potentielle devrait être définie
> relativement au contexte particulier de chaque serveur,

Bof, quelle raison de laisser passer un truc qui ne te voudra *clairement* 
jamais du bien ?

> 2. si les IP à bannir sont partagées, comment empêcher que cette liste soit
> polluée par malveillance,

Ca c'est parfaitement géré, tu peux aller lire sur leur site comment ca 
fonctionne...

> 3. comment s'assurer que l'on installe pas un accès dérobé avec crowdsec ?

C'est open-source, c'est Français et c'est des gens qui ont toujours bossé dans 
la cybersécurité, donc pour lever tout doute par rapport à un bout de code, 
etc, ne pas hésiter à les contacter. 🤷‍♂️


Cordialement,
--
Philippe Bourcier
https://twitter.com/irukanji_invest
https://www.linkedin.com/in/philippebourcier/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Interface marque blanche téléphonie OVH

[Martin]

Merci pour ton retour David

Je comprends parfaitement ton point de vue. Pour le coup, je connais plutôt
bien le monde de la VoIP, et je te rejoins sur certains aspects de l'offre
OVH.
Ceci étant dit, la solution d'ovh est pour le coup très adaptée pour le
revendeur qui n'y connaît pas grand chose, et qui va toucher des clients
qui n'ont pas de besoin spécifique, et se contentent de recevoir des
appels, appeler un peu, et veulent juste un joli message d'accueil.
C'est plug and play, tout en ligne, ça juste marche, c'est du lowcost et du
lowservice. Oui, ça manque d'humain, mais on est en 2024, c'est à la mode.

Pour ce qui me concerne, ce n'est pas mon activité principale, mais j'en
mets quand ça répond au besoin du client, et tout le monde est content.

Inutile donc de me faire des MP pour des propositions autres, ce n'est pas
ce que je recherche ;o)

Martin

Le ven. 26 janv. 2024 à 11:46, David Ponzone  a
écrit :

> Je vais répondre ce que je pense, et d’autres ne seront probablement
> peut-être pas d’accord.
>
> 1/ sur la liste, il y a pas mal d’opérateurs qui n’ont pas très bien vu
> l’arrivée d’OVH sur ce secteur en faisant du low-cost car ça n’aide pas à
> donner une bonne image de la VOIP, pas seulement à cause d’OVH (dont le
> service VOIP marche, sauf quand il a des soucis), mais aussi à cause de la
> cible de ce produit: des revendeurs/« intégrateurs » pas très compétents du
> tout en VOIP, et qui pensent que revendre de la VOIP, c’est comme revendre
> du MS365 (je ne parle pas pour toi, je ne te connais pas, mais la
> quasi-totalité de ceux que j’ai croisé n’y entravaient rien)
> 2/ c’est bradé, donc pas beaucoup de revenus à faire, donc pas beaucoup de
> motivation pour développer une UI qui tape dans l’API OVH (qui peut changer
> du jour au lendemain), sans parler du fait que les features proposés par
> OVH sont très restreints pour une entreprise en 2024
> 3/ si un mec a fait une telle UI, c’est un revendeur OVH avec des skills
> en dev, et il va se la garder, vu la VA que ça lui procure
>
> Conclusion: tu vas probablement recevoir des tonnes de MP de gens qui vont
> te proposer leur solution Centrex. Pourquoi pas...mais demande-toi si tu
> n’as pas intérêt à sortir de ce modèle (si ton parc est grandissant et si
> tu considères que c’est un business important pour toi, quitte à faire
> moins du low-cost). Après, personne va te sortir un truc à 1€/mois comme
> OVH… Bon courage :)
>
> David
>
> > Le 26 janv. 2024 à 11:28, Martin  a écrit :
> >
> > Bonjour à tous,
> >
> > j'ai un petit parc grandissant de clients chez qui j'ai installé de la
> > téléphonie OVH. J'en suis content sur la partie téléphonie qui fonctionne
> > bien.
> >
> > Mais certains clients et prospects me réclament une interface qui leur
> > permette d'accéder à et gérer eux-mêmes un certain nombre de choses
> > (Journaux d'appels, horaires d'ouverture, files d'appels, etc...)
> >
> > Le manager marque blanche d'ovh ne me semble pas adapté.
> > L'API OVH existe, mais je ne suis pas dans une démarche de développer moi
> > même ce genre de chose, faute de temps et peut être de compétences ;o)
> >
> > Quelqu'un connait il une solution qui réponde à ce besoin ?
> >
> > Martin
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] Interface marque blanche téléphonie OVH

[Gérald Vannier]

Comme le dit David, bcp d'acteurs sur la marque blanche (nous 😉 )
Nous avons des partenaires qui ont aussi du OVH, effectivement plutôt qd le 
besoin de service est quasi inexistant (juste passer/recevoir des appels 
simples) ou que le prix est 100% de la décision (ceci dit, 1€/mois pas cher, 
mais le prix des communications sont élevés, donc ça dépend de l'usage). 
Certains en sont contents...
Gérald

-Original Message-
From: frnog-requ...@frnog.org  On Behalf Of David 
Ponzone
Sent: vendredi 26 janvier 2024 11:46
To: Martin 
Cc: frnog-t...@frnog.org
Subject: Re: [FRnOG] [TECH] Interface marque blanche téléphonie OVH

Je vais répondre ce que je pense, et d’autres ne seront probablement peut-être 
pas d’accord.

1/ sur la liste, il y a pas mal d’opérateurs qui n’ont pas très bien vu 
l’arrivée d’OVH sur ce secteur en faisant du low-cost car ça n’aide pas à 
donner une bonne image de la VOIP, pas seulement à cause d’OVH (dont le service 
VOIP marche, sauf quand il a des soucis), mais aussi à cause de la cible de ce 
produit: des revendeurs/« intégrateurs » pas très compétents du tout en VOIP, 
et qui pensent que revendre de la VOIP, c’est comme revendre du MS365 (je ne 
parle pas pour toi, je ne te connais pas, mais la quasi-totalité de ceux que 
j’ai croisé n’y entravaient rien) 2/ c’est bradé, donc pas beaucoup de revenus 
à faire, donc pas beaucoup de motivation pour développer une UI qui tape dans 
l’API OVH (qui peut changer du jour au lendemain), sans parler du fait que les 
features proposés par OVH sont très restreints pour une entreprise en 2024 3/ 
si un mec a fait une telle UI, c’est un revendeur OVH avec des skills en dev, 
et il va se la garder, vu la VA que ça lui procure

Conclusion: tu vas probablement recevoir des tonnes de MP de gens qui vont te 
proposer leur solution Centrex. Pourquoi pas...mais demande-toi si tu n’as pas 
intérêt à sortir de ce modèle (si ton parc est grandissant et si tu considères 
que c’est un business important pour toi, quitte à faire moins du low-cost). 
Après, personne va te sortir un truc à 1€/mois comme OVH… Bon courage :)

David

> Le 26 janv. 2024 à 11:28, Martin  a écrit :
> 
> Bonjour à tous,
> 
> j'ai un petit parc grandissant de clients chez qui j'ai installé de la 
> téléphonie OVH. J'en suis content sur la partie téléphonie qui 
> fonctionne bien.
> 
> Mais certains clients et prospects me réclament une interface qui leur 
> permette d'accéder à et gérer eux-mêmes un certain nombre de choses 
> (Journaux d'appels, horaires d'ouverture, files d'appels, etc...)
> 
> Le manager marque blanche d'ovh ne me semble pas adapté.
> L'API OVH existe, mais je ne suis pas dans une démarche de développer 
> moi même ce genre de chose, faute de temps et peut être de compétences 
> ;o)
> 
> Quelqu'un connait il une solution qui réponde à ce besoin ?
> 
> Martin
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Interface marque blanche téléphonie OVH

[David Ponzone]

Je vais répondre ce que je pense, et d’autres ne seront probablement peut-être 
pas d’accord.

1/ sur la liste, il y a pas mal d’opérateurs qui n’ont pas très bien vu 
l’arrivée d’OVH sur ce secteur en faisant du low-cost car ça n’aide pas à 
donner une bonne image de la VOIP, pas seulement à cause d’OVH (dont le service 
VOIP marche, sauf quand il a des soucis), mais aussi à cause de la cible de ce 
produit: des revendeurs/« intégrateurs » pas très compétents du tout en VOIP, 
et qui pensent que revendre de la VOIP, c’est comme revendre du MS365 (je ne 
parle pas pour toi, je ne te connais pas, mais la quasi-totalité de ceux que 
j’ai croisé n’y entravaient rien)
2/ c’est bradé, donc pas beaucoup de revenus à faire, donc pas beaucoup de 
motivation pour développer une UI qui tape dans l’API OVH (qui peut changer du 
jour au lendemain), sans parler du fait que les features proposés par OVH sont 
très restreints pour une entreprise en 2024
3/ si un mec a fait une telle UI, c’est un revendeur OVH avec des skills en 
dev, et il va se la garder, vu la VA que ça lui procure

Conclusion: tu vas probablement recevoir des tonnes de MP de gens qui vont te 
proposer leur solution Centrex. Pourquoi pas...mais demande-toi si tu n’as pas 
intérêt à sortir de ce modèle (si ton parc est grandissant et si tu considères 
que c’est un business important pour toi, quitte à faire moins du low-cost). 
Après, personne va te sortir un truc à 1€/mois comme OVH… Bon courage :)

David

> Le 26 janv. 2024 à 11:28, Martin  a écrit :
> 
> Bonjour à tous,
> 
> j'ai un petit parc grandissant de clients chez qui j'ai installé de la
> téléphonie OVH. J'en suis content sur la partie téléphonie qui fonctionne
> bien.
> 
> Mais certains clients et prospects me réclament une interface qui leur
> permette d'accéder à et gérer eux-mêmes un certain nombre de choses
> (Journaux d'appels, horaires d'ouverture, files d'appels, etc...)
> 
> Le manager marque blanche d'ovh ne me semble pas adapté.
> L'API OVH existe, mais je ne suis pas dans une démarche de développer moi
> même ce genre de chose, faute de temps et peut être de compétences ;o)
> 
> Quelqu'un connait il une solution qui réponde à ce besoin ?
> 
> Martin
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Interface marque blanche téléphonie OVH

[Martin]

Bonjour à tous,

j'ai un petit parc grandissant de clients chez qui j'ai installé de la
téléphonie OVH. J'en suis content sur la partie téléphonie qui fonctionne
bien.

Mais certains clients et prospects me réclament une interface qui leur
permette d'accéder à et gérer eux-mêmes un certain nombre de choses
(Journaux d'appels, horaires d'ouverture, files d'appels, etc...)

Le manager marque blanche d'ovh ne me semble pas adapté.
L'API OVH existe, mais je ne suis pas dans une démarche de développer moi
même ce genre de chose, faute de temps et peut être de compétences ;o)

Quelqu'un connait il une solution qui réponde à ce besoin ?

Martin

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Daniel Caillibaud]

Le 25/01/24 à 21:36, Stéphane Rivière  a écrit :
> S'il faut mettre des fail2ban pour se protéger de chatouilles en mode
> force brute, c'est qu'il reste des accès à mots de passe.

J'ai aussi viré fail2ban y'a pas mal d'années, en imposant les clé ssh partout 
(et en virant
tous les password des users), mais y'a des services basés sur une auth en 
login/pass pour
lesquels ça reste utile (imap par ex).

Après, faut quand même faire attention à ce que ça consomme vs de quoi ça 
protège, faire du grep
permanent sur des logs qui grossissent très vite n'est pas négligeable.

-- 
Daniel

La vie c'est ce qui nous tombe dessus alors
qu'on avait d'autres plans en tète.
John Lennon.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Erwan David]

Le 26/01/2024 à 09:33, Laurent Barme a écrit :


Le 26/01/2024 à 08:57, Stéphane Rivière a écrit :
>Ce test illustre bien la facilité avec laquelle ce dispositif peut 
être contourné, merci !


Sauf si tu bans les IP des VPN connus pour officier en France...



Ah, et où trouves-tu la liste des VPN connus pour officier en France ?

Et qu'est-ce qui empêcherait un pirate d'utiliser (depuis n'importe 
quelle origine géographique) une adresse IP "géolocalisée" en France 
qui ne soit pas dans cette liste ?


Pour prendre un peu de recul, on est bien d'accord que la 
géolocalisation des adresses IP sous-entends celle de celui qui 
l'utilise ?


Alors, seuls les FAI ont une visibilité (toute relative) sur cette 
information et je doute qu'ils la partagent, sauf injonction 
judiciaire bien sûr et sans doute très peu avec une instance étrangère.


La géolocalisation d'une IP est déjà une gageure  en soit mais en plus 
son utilisateur peut agir de presque n'importe où ; les tunnels ssh 
sont très commodes…



Même sans ça. J'ai bossé chez Cisco, en France. La sortie sur internet 
était à Amsterdam. Dans un pool d'IP PI de Cisco (avantage d'avoir été 
une des premières boites sur internet). Toute l'Europe sortait par le 
même pool d'IP. Et la geoloc foirait 9 fois sur 10. Parfois localisés au 
siège de Cisco à San Jose, parfois ailleurs en Europe (google était 
spécialiste, le jeu était de deviner si ce jour là on serait polonais, 
ukrainien, anglais, etc..)


Le pire étant les sites qui imposent la langue selon la géolocalisation 
en se foutant des réglages du navigateur...



--
Erwan David


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[David Ponzone]

Oh on peut pas avoir une bonne idée en mélangeant:
whois -i origin AS3215 | grep ‘^route:’
et
sh ip bcp reg _3215$

?

> Le 26 janv. 2024 à 10:00, Laurent Barme <5...@barme.fr> a écrit :
> 
> 
> Tout à fait d'accord ; je rêverais d'avoir les plages d'adresse IP des FAI !
> Alors oui, j'ai gglé la question mais la réponse est un peu périmée (20 juin 
> 2013 à 23:06:39) : https://lafibre.info/ipv6/plages-ip-par-fai/
> Et j'ai comme un doute sur une mise à jour régulière de cette liste :-\
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Laurent Barme]

Update : https://api.iplocation.net/ a l'air vraiment intéressant, merci !

Le 26/01/2024 à 10:00, Laurent Barme a écrit :


Le 26/01/2024 à 09:47, Stéphane Rivière a écrit :

>Ah, et où trouves-tu la liste des VPN connus pour officier en France ?

En tapant dans le gougle quelques caractères genre well known vpn ip. en 
rajoutant in france peut aider mais y'a d'autres moyens de filtrer, justement 
avec les bases de ip2location dans cette thread.


Et qu'est-ce qui empêcherait un pirate d'utiliser (depuis n'importe quelle 
origine géographique) une adresse IP "géolocalisée" en France qui ne soit 
pas dans cette liste ?


En (prenant le pb à l'envers en) ne gardant que les ranges des FAI, c'est 
encore plus simple.

Tout à fait d'accord ; je rêverais d'avoir les plages d'adresse IP des FAI !
Alors oui, j'ai gglé la question mais la réponse est un peu périmée (20 juin 
2013 à 23:06:39) : https://lafibre.info/ipv6/plages-ip-par-fai/

Et j'ai comme un doute sur une mise à jour régulière de cette liste :-\



Parce qu'on va quand même pas envisager que le dodoze de Mme Michu pourrait 
être botté :>>>



Ben voyons :-)


---
Liste de diffusion du FRnOG
http://www.frnog.org/




---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Laurent Barme]

Le 26/01/2024 à 09:47, Stéphane Rivière a écrit :

>Ah, et où trouves-tu la liste des VPN connus pour officier en France ?

En tapant dans le gougle quelques caractères genre well known vpn ip. en 
rajoutant in france peut aider mais y'a d'autres moyens de filtrer, justement 
avec les bases de ip2location dans cette thread.


Et qu'est-ce qui empêcherait un pirate d'utiliser (depuis n'importe quelle 
origine géographique) une adresse IP "géolocalisée" en France qui ne soit pas 
dans cette liste ?


En (prenant le pb à l'envers en) ne gardant que les ranges des FAI, c'est 
encore plus simple.

Tout à fait d'accord ; je rêverais d'avoir les plages d'adresse IP des FAI !
Alors oui, j'ai gglé la question mais la réponse est un peu périmée (20 juin 
2013 à 23:06:39) : https://lafibre.info/ipv6/plages-ip-par-fai/

Et j'ai comme un doute sur une mise à jour régulière de cette liste :-\



Parce qu'on va quand même pas envisager que le dodoze de Mme Michu pourrait 
être botté :>>>



Ben voyons :-)


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Stéphane Rivière]

>Ah, et où trouves-tu la liste des VPN connus pour officier en France ?

En tapant dans le gougle quelques caractères genre well known vpn ip. en 
rajoutant in france peut aider mais y'a d'autres moyens de filtrer, 
justement avec les bases de ip2location dans cette thread.


Et qu'est-ce qui empêcherait un pirate d'utiliser (depuis n'importe 
quelle origine géographique) une adresse IP "géolocalisée" en France 
qui ne soit pas dans cette liste ?


En (prenant le pb à l'envers en) ne gardant que les ranges des FAI, 
c'est encore plus simple.


Parce qu'on va quand même pas envisager que le dodoze de Mme Michu 
pourrait être botté :>>>


--
Stéphane Rivière
Ile d'Oléron - France


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[Toussaint OTTAVI]

Le 25/01/2024 à 21:44, Pierre Emeriaud a écrit :

Et encore, maintenant y'a junos evo, où on abandonne complètement
freebsd pour passer sur un os linux...


M'ouais... Si je comprends bien, je me suis fait fourguer des pièces de 
musée avec ces EX2300, qui ont des hardware obsolètes pour faire tourner 
les versions actuelles de l'OS, et ne semblent pas supporter les 
versions futures ?


Décidément, c'est ma fête tous les jours en ce moment :-D

Et en plus, Juniper a été racheté par hpe, donc je retourne exactement 
là d'où je voulais me barrer :-D Entre autres parce qu'ils rachetaient 
n'importe quoi sans aucune cohérence dans les gammes :-D


En plus de changer de nom, il faut aussi que je change de boulot :-) 
J'avais envisagé agriculteur :-)

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Laurent Barme]

En tout cas, si on en doutait, ta contribution à la discussion le confirme :-)

Le 26/01/2024 à 08:40, David Ponzone a écrit :

Ah on sent que c’est vendredi :)


Le 26 janv. 2024 à 08:03, Laurent Barme <5...@barme.fr> a écrit :


Le 25/01/2024 à 09:08, Stéphane Rivière a écrit :
…

Merci pour crowdsec, jamais utilisé mais on emploie ce principe dans d'autres 
écosystèmes et le retour est bon :)


J'ai trois objections à propos d'une protection participative telle que 
crowdsec :

1. les règles de détection d'une attaque potentielle devrait être définie
   relativement au contexte particulier de chaque serveur,
2. si les IP à bannir sont partagées, comment empêcher que cette liste soit
   polluée par malveillance,
3. commet s'assurer que l'on installe pas un accès dérobé avec crowdsec ?


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/




---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Laurent Barme]

Le 26/01/2024 à 08:57, Stéphane Rivière a écrit :
>Ce test illustre bien la facilité avec laquelle ce dispositif peut être 
contourné, merci !


Sauf si tu bans les IP des VPN connus pour officier en France...



Ah, et où trouves-tu la liste des VPN connus pour officier en France ?

Et qu'est-ce qui empêcherait un pirate d'utiliser (depuis n'importe quelle 
origine géographique) une adresse IP "géolocalisée" en France qui ne soit pas 
dans cette liste ?


Pour prendre un peu de recul, on est bien d'accord que la géolocalisation des 
adresses IP sous-entends celle de celui qui l'utilise ?


Alors, seuls les FAI ont une visibilité (toute relative) sur cette information 
et je doute qu'ils la partagent, sauf injonction judiciaire bien sûr et sans 
doute très peu avec une instance étrangère.


La géolocalisation d'une IP est déjà une gageure  en soit mais en plus son 
utilisateur peut agir de presque n'importe où ; les tunnels ssh sont très commodes…



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Stéphane Rivière]

>Ce test illustre bien la facilité avec laquelle ce dispositif peut 
être contourné, merci !


Sauf si tu bans les IP des VPN connus pour officier en France...

Ça protège du kikoo-hackinou et des bots moyens.

Ça ne protégera jamais d'une institution (et ce n'est pas le but).

--
Stéphane Rivière
Ile d'Oléron - France


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[David Ponzone]

Ah on sent que c’est vendredi :)

> Le 26 janv. 2024 à 08:03, Laurent Barme <5...@barme.fr> a écrit :
> 
> 
> Le 25/01/2024 à 09:08, Stéphane Rivière a écrit :
> …
>> Merci pour crowdsec, jamais utilisé mais on emploie ce principe dans 
>> d'autres écosystèmes et le retour est bon :)
>> 
> J'ai trois objections à propos d'une protection participative telle que 
> crowdsec :
> 
> 1. les règles de détection d'une attaque potentielle devrait être définie
>   relativement au contexte particulier de chaque serveur,
> 2. si les IP à bannir sont partagées, comment empêcher que cette liste soit
>   polluée par malveillance,
> 3. commet s'assurer que l'on installe pas un accès dérobé avec crowdsec ?
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Switch SFP en 48V

[Sebastien FOURCADE]

Bonjour à tous,

Je suis à la recherche d'un switch manageable disposant d'un minimum de 18 
ports SFP, ayant une profondeur de moins de 30cm et pouvant être alimenté en DC 
48V.

Côté features du grand classique : VLAN/SPT/IPV4&IPV6/SNMP/SPT/LACP/ACL/QOS - 
MGT SSH + port console

Connaissez-vous une référence qui coche les cases ci-dessus ?

Bonne journée !

Sébastien



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Laurent Barme]

Le 25/01/2024 à 09:08, Stéphane Rivière a écrit :
…
Merci pour crowdsec, jamais utilisé mais on emploie ce principe dans d'autres 
écosystèmes et le retour est bon :)



J'ai trois objections à propos d'une protection participative telle que 
crowdsec :

1. les règles de détection d'une attaque potentielle devrait être définie
   relativement au contexte particulier de chaque serveur,
2. si les IP à bannir sont partagées, comment empêcher que cette liste soit
   polluée par malveillance,
3. commet s'assurer que l'on installe pas un accès dérobé avec crowdsec ?


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Laurent Barme]

Le 25/01/2024 à 17:17, Stéphane Rivière a écrit :
…

Test ON/OFF avec divers VPN internationaux OK

Ce test illustre bien la facilité avec laquelle ce dispositif peut être 
contourné, merci !



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Laurent Barme]

Le 24/01/2024 à 20:31, Philippe Bourcier a écrit :
…

Je trouve que le réflexe sanitaire du moment (quand tu peux) c'est un geofilter 
+ CrowdSec.
Comme ca même le national p0wné ne passe pas...


Ce conseille est similaire au dogme des mises à jour : il est simple à 
comprendre, facile à mettre en œuvre et donc très rassurant.


En bonus, le "sanitaire" lui ajoute une connotation "sûr et efficace".

Bon vendredi :-)


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[Pierre Emeriaud]

Le jeu. 25 janv. 2024 à 15:24, ic  a écrit :
>
> io,
>
> > On 25 Jan 2024, at 14:16, Toussaint OTTAVI  wrote:
> >
> >> Parceque (comme d'autes), ils ont collé leur nom et "bricolé" leur OS
> >> pour le faire rentrer dans du matériel sous-traité ou provenant d'un
> >> rachat ?
>
> non plutôt depuis que le développement a déménagé en Inde… et leur qualité de 
> code réputée mondialement...
>
> > L'OS Juniper, et sa base FreeBSD, çà me semble quand même pas trop mauvais, 
> > non ? Sur un CPU qui ne met pas 16 minutes à booter, et avec 10 € de 
> > mémoire flash en plus, çà pourrait dépoter…
>
>
> Aux dernières nouvelles pour des questions de drivers (entre autres), les 
> restes de FreeBSD chez Jun tournent dans une VM dans un Linux…

Et encore, maintenant y'a junos evo, où on abandonne complètement
freebsd pour passer sur un os linux...


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Stéphane Rivière]

C'est quoi l'avantage de Crowdsec par rapport à un bon vieux Fail2ban ? 


Ce qui m'a séduit dans l'approche de Crowdsec est une technique que l'on 
apprécie dans d'autres écosystèmes : l'échange communautaire d'ip 
malveillantes. C'est de l'entraide intelligente.


Identifier et bloquer les adresses IP dangereuses, même si elles ne 
t'ont pas encore attaquées.
On pourrait se demander si c'est intéressant d'anticiper une attaque : 
Ça rapporte quoi ? Du travail pour gratuit, des emmerdes d'un nouveau 
logiciel et pas un kopeck.


;) haha tu recycles. Installer Crowdsec se fait en 2mn, c'est pas plus 
long, voire plus court, qu'un fail2ban un peu tuné et qu'on a fini par 
abandonner car, en fait, il ne sert à rien... Soit la cible est solide 
soit elle ne l'est pas. S'il faut mettre des fail2ban pour se protéger 
de chatouilles en mode force brute, c'est qu'il reste des accès à mots 
de passe.


Crowdsec, que je viens de découvrir, m'ouvre des perspectives en tant 
qu'hébergeur (et donc Wordpress, donc PHP, donc des plugins parfois en 
mousse et les 0 day qui en découlent), sur certains aspects de mon 
métier. On verra à l'usage. Pour l'instant c'est en test.


On pourrait même ergoter en étudiant la probabilité qu'une IP ayant 
attaquée un service tiers, dont on ne connaît rien des pratiques ou 
services, attaque aussi mes propres services, en la comparant à la 
probabilité que IPv6 soit un jour largement répandue et nécessaire.
J'admire ce raisonnement d'une mauvaise foi capilotractée au cube et je 
te tire mon chapeau en connaisseur :)))
Perso, j'ai fait mes choix, je garde mes vieux Fail2ban et mes 
services sont IPv6 ready.

L'essentiel étant d'être en accord avec soi même, je t'approuve à 100 % !

--
Stéphane Rivière
Ile d'Oléron - France


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[David Ponzone]

Je pense que ça permet aussi de protéger en une seule fois tous tes services 
quand une IP en scanne un (mais pas forcément dans la version gratuite).
Et ça c’est un scénario probable.

> Le 25 janv. 2024 à 19:13, Guy Larrieu via frnog  a écrit :
> 
> Le 2024-01-25 18:03, Stéphane Rivière a écrit :
>> ...
> 
> C'est quoi l'avantage de Crowdsec par rapport à un bon vieux Fail2ban ? 
> Identifier et bloquer les adresses IP dangereuses, même si elles ne t'ont pas 
> encore attaquées.
> On pourrait se demander si c'est intéressant d'anticiper une attaque : Ça 
> rapporte quoi ? Du travail pour gratuit, des emmerdes d'un nouveau logiciel 
> et pas un kopeck.
> 
> On pourrait même ergoter en étudiant la probabilité qu'une IP ayant attaquée 
> un service tiers, dont on ne connaît rien des pratiques ou services, attaque 
> aussi mes propres services, en la comparant à la probabilité que IPv6 soit un 
> jour largement répandue et nécessaire.
> 
> Perso, j'ai fait mes choix, je garde mes vieux Fail2ban et mes services sont 
> IPv6 ready.
> 
> Guy.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Guy Larrieu via frnog]

Le 2024-01-25 18:03, Stéphane Rivière a écrit :

...


C'est quoi l'avantage de Crowdsec par rapport à un bon vieux Fail2ban ? 
Identifier et bloquer les adresses IP dangereuses, même si elles ne 
t'ont pas encore attaquées.
On pourrait se demander si c'est intéressant d'anticiper une attaque : 
Ça rapporte quoi ? Du travail pour gratuit, des emmerdes d'un nouveau 
logiciel et pas un kopeck.


On pourrait même ergoter en étudiant la probabilité qu'une IP ayant 
attaquée un service tiers, dont on ne connaît rien des pratiques ou 
services, attaque aussi mes propres services, en la comparant à la 
probabilité que IPv6 soit un jour largement répandue et nécessaire.


Perso, j'ai fait mes choix, je garde mes vieux Fail2ban et mes services 
sont IPv6 ready.


Guy.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Stéphane Rivière]

Le 25/01/2024 à 17:23, Daniel via frnog a écrit :

Sauf que l'api CrowdSec ne fonctionne pas en ipv6 => apt purge

Ben repasse en ipv4 ! Avant l'heure c'est pas l'heure.

Pour nous, le sketch de 30 ans ipv5, d'ipv 5.5 et d'ipv6 ne sert 
toujours à rien. Pourquoi migrer toute notre infra en dual stack pour rien ?


Pour être ipv6 ready ? Ça me rapporte quoi ? Du travail pour gratuit, 
des emmerdes de dual stack et pas un kopeck.


Et apparemment, vu la population du crowdsec, je ne suis pas le seul à 
garder les pieds sur terre ou d'avoir un contexte qui peut ignorer (sans 
mépris) ipv6.


Le jour où ipv6 deviendra incontournable, il y aura une période de 
transition et, ce moment venu, on basculera intégralement sous ipv6.


Sans dual stack. Et en prime, la peinture aura fini par sécher.

Un malin aurait rajouté : Ou je serais à la retraite. mais ça, on le 
sait bien, c'était dans le monde d'avant.


--
Stéphane Rivière
Ile d'Oléron - France


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Daniel via frnog]

Sauf que l'api CrowdSec ne fonctionne pas en ipv6 => apt purge

Le 25/01/2024 à 17:17, Stéphane Rivière a écrit :

Bonjour Philippe,
Je trouve que le réflexe sanitaire du moment (quand tu peux) c'est 
un geofilter + CrowdSec.


J'ai donc suivi tes conseils, cette instance étant susceptible d'être 
particulièrement exposée.


Et rassemblé mes notes, si ça peut servir à quelqu'un...


GEOFENCING
==

À la recherche de la base de données perdue en accès libre (merci 
maxmind)


ip2location.com

Mention à mettre : This software uses the IP2Location LITE database 
for https://lite.ip2location.com";>IP geolocation.


Création du compte gratuit

email : **
password : **
token obtenu: Js**7tI

Installation convertisseur ip décimales

https://github.com/ip2location/ip2location-python-csv-converter
pip install ipaddress
pip install ip2location-python-csv-converter

Installation ipset

apt install ipset

Extraction automatisée

Also available here (without token, with less options) : 
https://download.ip2location.com/lite


https://lite.ip2location.com/database-download

wget 
"https://www.ip2location.com/download/?token=Js**tI&file=DB1LITECSV"; 
-O db1litecsv.zip

unzip db1litecsv.zip
...
  inflating: IP2LOCATION-LITE-DB1.CSV

Le format est en ip décimales et multi-colonnes, il nécessite un 
retraitement pour être compatible ipset


https://blog.ip2location.com/knowledge-base/convert-ip2location-csv-data-into-ip-ranges-or-cidr 



cat IP2LOCATION-LITE-DB1.CSV | grep FR > fr1.csv
ip2location-csv-converter -cidr -replace fr1.csv fr2.csv
awk -F',' '{print $1}' fr2.csv > fr3.csv
awk '{gsub(/"/,"")};1' fr3.csv > fr.cidr

Exemple d'utilisation dans le script de service firewall

# Init french IPv4 ~8000 ranges

ipset -q destroy fr4
ipset create fr4 hash:net family inet
for ip in $(cat ./geoloc/fr.cidr); do ipset add fr4 $ip; done

# Exemple pour un accès SSH

iptables -A INPUT  -i $EXTIF -m set --match-set fr4 src  -m state 
--state NEW,ESTABLISHED -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -o $EXTIF -m set --match-set fr4 dst  -m state 
--state ESTABLISHED -p tcp --sport 22 -j ACCEPT


Test ON/OFF avec divers VPN internationaux OK


CROWD-SOURCING IP
=

https://fr.wikipedia.org/wiki/CrowdSec

/!\ le port 8080 doit être libre...

curl -s 
https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh 
| bash (ou sudo bash si sudo installé)

apt install crowdsec
apt install crowdsec-firewall-bouncer-iptables

Enrôler l'instance

https://app.crowdsec.net/signup

email : **
password : **

Dans le back office, exécuter la ligne proposée sur la nouvelle instance
cscli console enroll cl**np

systemctl restart crowdsec
systemctl status crowdsec
systemctl status crowdsec-firewall-bouncer.service

Dans le back office, rafraîchir et accepter la nouvelle instance

Il y a des scénarios pour toute une foultitude de cas d'usage, 
l'expérience utilisateur est limpide, beaucoup de doc et de tools 
divers, tant que ça reste en free pour nos moyens, c'est topisssime...


Merci pour le tuyau !


--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Stéphane Rivière]

Bonjour Philippe,

Je trouve que le réflexe sanitaire du moment (quand tu peux) c'est un geofilter 
+ CrowdSec.


J'ai donc suivi tes conseils, cette instance étant susceptible d'être 
particulièrement exposée.


Et rassemblé mes notes, si ça peut servir à quelqu'un...


GEOFENCING
==

À la recherche de la base de données perdue en accès libre (merci maxmind)

ip2location.com

Mention à mettre : This software uses the IP2Location LITE database for 
https://lite.ip2location.com";>IP geolocation.


Création du compte gratuit

email : **
password : **
token obtenu: Js**7tI

Installation convertisseur ip décimales

https://github.com/ip2location/ip2location-python-csv-converter
pip install ipaddress
pip install ip2location-python-csv-converter

Installation ipset

apt install ipset

Extraction automatisée

Also available here (without token, with less options) : 
https://download.ip2location.com/lite


https://lite.ip2location.com/database-download

wget 
"https://www.ip2location.com/download/?token=Js**tI&file=DB1LITECSV"; 
-O db1litecsv.zip

unzip db1litecsv.zip
...
  inflating: IP2LOCATION-LITE-DB1.CSV

Le format est en ip décimales et multi-colonnes, il nécessite un 
retraitement pour être compatible ipset


https://blog.ip2location.com/knowledge-base/convert-ip2location-csv-data-into-ip-ranges-or-cidr

cat IP2LOCATION-LITE-DB1.CSV | grep FR > fr1.csv
ip2location-csv-converter -cidr -replace fr1.csv fr2.csv
awk -F',' '{print $1}' fr2.csv > fr3.csv
awk '{gsub(/"/,"")};1' fr3.csv > fr.cidr

Exemple d'utilisation dans le script de service firewall

# Init french IPv4 ~8000 ranges

ipset -q destroy fr4
ipset create fr4 hash:net family inet
for ip in $(cat ./geoloc/fr.cidr); do ipset add fr4 $ip; done

# Exemple pour un accès SSH

iptables -A INPUT  -i $EXTIF -m set --match-set fr4 src  -m state 
--state NEW,ESTABLISHED -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -o $EXTIF -m set --match-set fr4 dst  -m state 
--state ESTABLISHED -p tcp --sport 22 -j ACCEPT


Test ON/OFF avec divers VPN internationaux OK


CROWD-SOURCING IP
=

https://fr.wikipedia.org/wiki/CrowdSec

/!\ le port 8080 doit être libre...

curl -s 
https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh 
| bash (ou sudo bash si sudo installé)

apt install crowdsec
apt install crowdsec-firewall-bouncer-iptables

Enrôler l'instance

https://app.crowdsec.net/signup

email : **
password : **

Dans le back office, exécuter la ligne proposée sur la nouvelle instance
cscli console enroll cl**np

systemctl restart crowdsec
systemctl status crowdsec
systemctl status crowdsec-firewall-bouncer.service

Dans le back office, rafraîchir et accepter la nouvelle instance

Il y a des scénarios pour toute une foultitude de cas d'usage, 
l'expérience utilisateur est limpide, beaucoup de doc et de tools 
divers, tant que ça reste en free pour nos moyens, c'est topisssime...


Merci pour le tuyau !

--
Stéphane Rivière
Ile d'Oléron - France

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Stéphane Rivière]

un bête fail2ban pour commencer…
Nous n'utilisons plus fail2ban depuis un paquet d'années. Passwords 
désactivés partout. Bastion blindé. Minimum d'instances exposées. J'aime 
assez l'idée qu'ils perdent des ressources à grattouiller en vain...


--
Stéphane Rivière
Ile d'Oléron - France

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[Toussaint OTTAVI]

Le 25/01/2024 à 15:23, ic a écrit :


Aux dernières nouvelles pour des questions de drivers (entre autres), 
les restes de FreeBSD chez Jun tournent dans une VM dans un Linux…


:-o

Vendredi, c'est demain ? Non ?


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[ic]

io,

> On 25 Jan 2024, at 14:16, Toussaint OTTAVI  wrote:
> 
>> Parceque (comme d'autes), ils ont collé leur nom et "bricolé" leur OS
>> pour le faire rentrer dans du matériel sous-traité ou provenant d'un
>> rachat ?

non plutôt depuis que le développement a déménagé en Inde… et leur qualité de 
code réputée mondialement...

> L'OS Juniper, et sa base FreeBSD, çà me semble quand même pas trop mauvais, 
> non ? Sur un CPU qui ne met pas 16 minutes à booter, et avec 10 € de mémoire 
> flash en plus, çà pourrait dépoter…


Aux dernières nouvelles pour des questions de drivers (entre autres), les 
restes de FreeBSD chez Jun tournent dans une VM dans un Linux…

++ ic



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[ic]

io,

> On 25 Jan 2024, at 14:16, Toussaint OTTAVI  wrote:
> 
> Et sinon, en switch 24 / 48 ports qui supporte OpenWRT, ou toute autre 
> solution libre, il y aurait quelque chose de correct ?

vu que tu ne précises pas la vitesse des ports, j’en profite pour coller ça : 
https://www.linkedin.com/pulse/debian-mellanox-100g-switch-pim-van-pelt-3pivf/

++ ic


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[Erwan David]

Le 25/01/2024 à 14:16, Toussaint OTTAVI a écrit :


Le 25/01/2024 à 11:17, Dominique Rousseau a écrit :

Parceque (comme d'autes), ils ont collé leur nom et "bricolé" leur OS
pour le faire rentrer dans du matériel sous-traité ou provenant d'un
rachat ?


Heu, non, çà, c'était hpe avant le rachat :-D  Quoique, hpe ne bricole 
que le logo. 5 gammes de switches = 5 OS différents :-) Quand il n'y a 
pas deux interfaces différentes simultanément sur le même appareil :-)


L'OS Juniper, et sa base FreeBSD, çà me semble quand même pas trop 
mauvais, non ? Sur un CPU qui ne met pas 16 minutes à booter, et avec 
10 € de mémoire flash en plus, çà pourrait dépoter...


--
Et sinon, en switch 24 / 48 ports qui supporte OpenWRT, ou toute autre 
solution libre, il y aurait quelque chose de correct ?

---
Liste de diffusion du FRnOG
http://www.frnog.org/

En tout cas c'est pas la base FreeBSD qui va rebuter HPE, leurs switches 
Commware 7 c'est déjà une base FreeBSD


--
Erwan David


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[Toussaint OTTAVI]

Le 25/01/2024 à 11:17, Dominique Rousseau a écrit :

Parceque (comme d'autes), ils ont collé leur nom et "bricolé" leur OS
pour le faire rentrer dans du matériel sous-traité ou provenant d'un
rachat ?


Heu, non, çà, c'était hpe avant le rachat :-D  Quoique, hpe ne bricole 
que le logo. 5 gammes de switches = 5 OS différents :-) Quand il n'y a 
pas deux interfaces différentes simultanément sur le même appareil :-)


L'OS Juniper, et sa base FreeBSD, çà me semble quand même pas trop 
mauvais, non ? Sur un CPU qui ne met pas 16 minutes à booter, et avec 10 
€ de mémoire flash en plus, çà pourrait dépoter...


--
Et sinon, en switch 24 / 48 ports qui supporte OpenWRT, ou toute autre 
solution libre, il y aurait quelque chose de correct ?

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[ic]

io,

> On 25 Jan 2024, at 09:08, Stéphane Rivière  wrote:
> 
> 
>> Je trouve que le réflexe sanitaire du moment (quand tu peux) c'est un 
>> geofilter + CrowdSec.
>> Comme ca même le national p0wné ne passe pas...
> Merci pour crowdsec, jamais utilisé mais on emploie ce principe dans d'autres 
> écosystèmes et le retour est bon :)

un bête fail2ban pour commencer…

++ ic


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[Dominique Rousseau]

Le Wed, Jan 24, 2024 at 09:48:29AM +0100, David Ponzone 
[david.ponz...@gmail.com] a écrit:
> Juniper a fait des boulettes sur certains modèles, aucun expert de la marque 
> ici ne le niera:
> -les switchs qui meurent quand ils se prennent des snmpwalk
> -les switchs qui freezent pendant un court instant quand on insère un
> module dans le port uplink (je sais, c???est documenté, mais c???est
> quand même surprenant sur cette gamme de matos)
> 
> Pourquoi ils en sont arrivés là, c???est une question intéressante
> mais dont la réponse risque de nous échapper.

Parceque (comme d'autes), ils ont collé leur nom et "bricolé" leur OS
pour le faire rentrer dans du matériel sous-traité ou provenant d'un
rachat ?


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
6 rue des Hautes cornes - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Stéphane Rivière]

Je trouve que le réflexe sanitaire du moment (quand tu peux) c'est un geofilter 
+ CrowdSec.
Comme ca même le national p0wné ne passe pas...
Merci pour crowdsec, jamais utilisé mais on emploie ce principe dans 
d'autres écosystèmes et le retour est bon :)


--
Stéphane Rivière
Ile d'Oléron - France


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Stéphane Rivière]

Le 24/01/2024 à 20:57, David Ponzone a écrit :

Faut juste bloquer OVH et Scaleway en plus :)


et digitalocean, aws, azure et le cloude du gougle ? En fait, arracher 
la fibre et là plus de problème :)


quand on observe tous les petits et très spécialisés providers de l'est 
qui mangent du monero au petit dej, on se dit que les gros cloudistes ne 
sont peut être pas nécessairement les pires.


--
Stéphane Rivière
Ile d'Oléron - France


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[David Ponzone]

Faut juste bloquer OVH et Scaleway en plus :)

> Le 24 janv. 2024 à 20:31, Philippe Bourcier  a écrit :
> 
> Re,
> 
>>> Ok tu peux pas mettre un geofilter sur le port 22 et on en parle plus ? :)
>> 
>> Bien vu !
> 
> Je trouve que le réflexe sanitaire du moment (quand tu peux) c'est un 
> geofilter + CrowdSec.
> Comme ca même le national p0wné ne passe pas...
> 
> 
> Cordialement,
> --
> Philippe Bourcier
> https://twitter.com/irukanji_invest
> https://www.linkedin.com/in/philippebourcier/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Philippe Bourcier]

Re,

>> Ok tu peux pas mettre un geofilter sur le port 22 et on en parle plus ? :)
> 
> Bien vu !

Je trouve que le réflexe sanitaire du moment (quand tu peux) c'est un geofilter 
+ CrowdSec.
Comme ca même le national p0wné ne passe pas...


Cordialement,
--
Philippe Bourcier
https://twitter.com/irukanji_invest
https://www.linkedin.com/in/philippebourcier/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Stéphane Rivière]

Nope, pas tout a fait d'accord. Ca veut dire que ton install est pas
vulnerable. Ca veut pas dire qu'elle ne logge plus rien si des scripts
essaient de la chatouiller avec un vieux CVE.

Oui, tu as raison. Erreur de raisonnement de mon coté... Merci :)

--
Stéphane Rivière
Ile d'Oléron - France


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Stéphane Rivière]

Le 24/01/2024 à 18:06, David Ponzone a écrit :

Ok tu peux pas mettre un geofilter sur le port 22 et on en parle plus ? :)


Bien vu !

Compte tenu que l'exploitation de cette instance est strictement 
nationale (4G multi-ops ou FAI FR coté machines et IP FR coté web), 
c'est ce que je vais faire.


J'aurais du y penser :)

Merci David.

--
Stéphane Rivière
Ile d'Oléron - France


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Paul Rolland (ポール・ロラン)]

Hello,

On Wed, 24 Jan 2024 17:58:36 +0100
Stéphane Rivière  wrote:

> 8.4 > 7.7, ça ne devrait pas être ça. Merci en tout cas pour cette idée :)

Nope, pas tout a fait d'accord. Ca veut dire que ton install est pas
vulnerable. Ca veut pas dire qu'elle ne logge plus rien si des scripts
essaient de la chatouiller avec un vieux CVE.

Paul

-- 
Paul RollandE-Mail : rol(at)witbe.net
CTO - Witbe.net SA  Tel. +33 (0)1 47 67 77 77
18 Rue d'Arras, Bat. A11Fax. +33 (0)1 47 67 77 99
F-92000 NanterreRIPE : PR12-RIPE

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un
navigateur "Some people dream of success... while others wake up and work
hard at it" 

"I worry about my child and the Internet all the time, even though she's
too young to have logged on yet. Here's what I worry about. I worry that 10
or 15 years from now, she will come to me and say 'Daddy, where were you
when they took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[David Ponzone]

Ok tu peux pas mettre un geofilter sur le port 22 et on en parle plus ? :)

> Le 24 janv. 2024 à 17:58, Stéphane Rivière  a écrit :
> 
> Bonsoir Paul,
>> Ca serait pas plutot CVE-2018-15473 ? (tentative d'enumeration des users)
> 
> En tout cas ce n'était pas l'autre CVE car je viens d'en avoir un nouveau...
> 
> Ce CVE (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15473) dit 
> OpenSSH through 7.7 is prone to a user enumeration vulnerability. Et pour 
> Debian (https://lists.debian.org/debian-security-announce/2018/msg00209.html) 
> For the stable distribution (stretch), this problem has been fixed in version 
> 1:7.4p1-10+deb9u4.
> 
> Cette instance en Debian 11.8 à jour est en OpenSSH_8.4p1 Debian-5+deb11u3, 
> OpenSSL 1.1.1w  11 Sep 2023
> 
> 8.4 > 7.7, ça ne devrait pas être ça. Merci en tout cas pour cette idée :)
> 
> -- 
> Stéphane Rivière
> Ile d'Oléron - France
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Stéphane Rivière]

Bonsoir Paul,

Ca serait pas plutot CVE-2018-15473 ? (tentative d'enumeration des users)


En tout cas ce n'était pas l'autre CVE car je viens d'en avoir un nouveau...

Ce CVE (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-15473) 
dit OpenSSH through 7.7 is prone to a user enumeration vulnerability. Et 
pour Debian 
(https://lists.debian.org/debian-security-announce/2018/msg00209.html) 
For the stable distribution (stretch), this problem has been fixed in 
version 1:7.4p1-10+deb9u4.


Cette instance en Debian 11.8 à jour est en OpenSSH_8.4p1 
Debian-5+deb11u3, OpenSSL 1.1.1w  11 Sep 2023


8.4 > 7.7, ça ne devrait pas être ça. Merci en tout cas pour cette idée :)

--
Stéphane Rivière
Ile d'Oléron - France


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Paul Rolland (ポール・ロラン)]

Hello,

Ca serait pas plutot CVE-2018-15473 ? (tentative d'enumeration des users)

Paul

On Wed, 24 Jan 2024 17:10:57 +0100
Stéphane Rivière  wrote:

> Le 24/01/2024 à 16:39, Thierry Chich a écrit :
> > C'est peut-être pour exploiter ça ?
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31124  
> 
> Intéressant.
> Du serpent en mousse autour d'openssh. Pour parser les fichiers de clés.
> J'ai du mal à saisir pourquoi openssh a besoin de ça au lieu de parser 
> lui-même les fichiers de clé.
> 
> Le bidule est openssh_key_parser > 
> https://pypi.org/project/openssh-key-parser
> 
> apt install python3-pip
> pip install openssh-key-parser
> Version 0.0.7 débugguée.
> 
> Merci pour le tuyau Thierry ! On verra si ces messages continuent :)
> 


-- 
Paul RollandE-Mail : rol(at)witbe.net
CTO - Witbe.net SA  Tel. +33 (0)1 47 67 77 77
18 Rue d'Arras, Bat. A11Fax. +33 (0)1 47 67 77 99
F-92000 NanterreRIPE : PR12-RIPE

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un
navigateur "Some people dream of success... while others wake up and work
hard at it" 

"I worry about my child and the Internet all the time, even though she's
too young to have logged on yet. Here's what I worry about. I worry that 10
or 15 years from now, she will come to me and say 'Daddy, where were you
when they took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Stéphane Rivière]

Le 24/01/2024 à 16:39, Thierry Chich a écrit :

C'est peut-être pour exploiter ça ?
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31124


Intéressant.
Du serpent en mousse autour d'openssh. Pour parser les fichiers de clés.
J'ai du mal à saisir pourquoi openssh a besoin de ça au lieu de parser 
lui-même les fichiers de clé.


Le bidule est openssh_key_parser > 
https://pypi.org/project/openssh-key-parser


apt install python3-pip
pip install openssh-key-parser
Version 0.0.7 débugguée.

Merci pour le tuyau Thierry ! On verra si ces messages continuent :)

--
Stéphane Rivière
Ile d'Oléron - France

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Thierry Chich]

C'est peut-être pour exploiter ça ?
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-31124


Thierry 




-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Stéphane 
Rivière
Envoyé : mercredi 24 janvier 2024 16:04
À : frnog-tech 
Objet : [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

Bonjour à toutes et tous,

2024 Jan 24 15:09:56 hostname *fatal: userauth_pubkey: parse request
failed: incomplete message [preauth]*

Mes logs sont (vaguement, c'est pas l'invasion non plus) pollués par ce message 
cryptique qui n'inspire guère Google.

J'ai (vaguement) cru comprendre que c'est généré par SSH via une "chatouille" 
pas finie dans une tentative de connexion illégitime par clé mais c'est pas 
clair (pour moi).

L'instance contient peu de chose : un openvpn, un ssh et un nginx en proxy. 
Ports ouverts 1194, 22, 80 443.

Avez vous un avis ? ;)

Merci d'avance...

--
Stéphane Rivière
Ile d'Oléron - France

---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[David Ponzone]

tshark -w ssh.pcap -i ens18 -f ‘port 22’

jusqu’à ce que ça arrive à nouveau, et regarde de qui ça venait.

> Le 24 janv. 2024 à 16:03, Stéphane Rivière  a écrit :
> 
> Bonjour à toutes et tous,
> 
> 2024 Jan 24 15:09:56 hostname *fatal: userauth_pubkey: parse request failed: 
> incomplete message [preauth]*
> 
> Mes logs sont (vaguement, c'est pas l'invasion non plus) pollués par ce 
> message cryptique qui n'inspire guère Google.
> 
> J'ai (vaguement) cru comprendre que c'est généré par SSH via une "chatouille" 
> pas finie dans une tentative de connexion illégitime par clé mais c'est pas 
> clair (pour moi).
> 
> L'instance contient peu de chose : un openvpn, un ssh et un nginx en proxy. 
> Ports ouverts 1194, 22, 80 443.
> 
> Avez vous un avis ? ;)
> 
> Merci d'avance...
> 
> -- 
> Stéphane Rivière
> Ile d'Oléron - France
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Filtrage ou mitigation d'un message cryptique

[Stéphane Rivière]

Bonjour à toutes et tous,

2024 Jan 24 15:09:56 hostname *fatal: userauth_pubkey: parse request 
failed: incomplete message [preauth]*


Mes logs sont (vaguement, c'est pas l'invasion non plus) pollués par ce 
message cryptique qui n'inspire guère Google.


J'ai (vaguement) cru comprendre que c'est généré par SSH via une 
"chatouille" pas finie dans une tentative de connexion illégitime par 
clé mais c'est pas clair (pour moi).


L'instance contient peu de chose : un openvpn, un ssh et un nginx en 
proxy. Ports ouverts 1194, 22, 80 443.


Avez vous un avis ? ;)

Merci d'avance...

--
Stéphane Rivière
Ile d'Oléron - France

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[Toussaint OTTAVI]

Le 24/01/2024 à 09:48, David Ponzone a écrit :

-les switchs qui meurent quand ils se prennent des snmpwalk


:-o

Et avec un ping6, je peux gagner un accès root, comme sous Windows ? :-D


Pourquoi ils en sont arrivés là, c’est une question intéressante mais
dont la réponse risque de nous échapper.


Décidément, mon coté "chat noir" ne m'a pas trahi sur ce coup là ;-) Et 
dire qu'à l'origine, j'ai testé Juniper car je voulais quitter hpe, et 
que Juniper vient d'être racheté par... :-D




---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Configuration ISL sur Brocade

[D Caradec]

Bonjour à tous,

C'est mon premier post sur frnog, merci pour votre indulgence.

Ma problématique :

4 Switchs Brocade 1000 FOS 8.2.3 répartis sur 2 fabric  dans 2 
Datacenter reliés par 3 fibres noires FC.


Je rencontre des difficultés pour la configuration ISL de ces 3 liens 
interDC


Mes questions :

 * Pourquoi lors de l'activation du troisième lien, celui-ci se
   retrouve groupé en trunk avec un des 2 autres liens ?
 * Peut-on avoir 3 liens Master ? en fonctionnement actif/passif
 * Pourquoi cette configuration 3 liens modifie la topology en activant
   du trafic sur le port In 4 sur l'autre lien, générant ainsi du
   trafic sur les 2 liens en même temps
 * Comment configure-t-on le mode DSL ? y-a-t-il des préconisations ?

Très peu de support côté constructeur !

Merci d'avance pour votre aide.


--
Didier CARADEC  
 



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[David Ponzone]

Juniper a fait des boulettes sur certains modèles, aucun expert de la marque 
ici ne le niera:
-les switchs qui meurent quand ils se prennent des snmpwalk
-les switchs qui freezent pendant un court instant quand on insère un module 
dans le port uplink (je sais, c’est documenté, mais c’est quand même surprenant 
sur cette gamme de matos)

Pourquoi ils en sont arrivés là, c’est une question intéressante mais dont la 
réponse risque de nous échapper.

David

> Le 24 janv. 2024 à 09:25, Toussaint OTTAVI  a écrit :
> 
> 
> Le 23/01/2024 à 17:35, Cyril LAVIER a écrit :
>> Les EX2300 ne sont clairement pas du haut de gamme. En tant que switch 
>> edge/top of rack, c'est l'entrée de gamme chez Juniper.
> 
> En fait, je n'ai pas besoin de plus. Il n'y a que du L2 dessus, une dizaine 
> de VLANs, et aucun des liens n'atteint le gigabit.
> 
>> Pas pour rien que VChassis est soumis à licence et limité à 4 membres (au 
>> lieu de 10 pour les EX3400 ou EX4400).
> 
> Dans mon cas, deux me suffisent (tolérance de panne basique LACP). Donc, le 
> choix des EX2300 me semblait pertinent. D'autant plus que les prédécesseurs 
> EX2200 en "refurb" m'avaient été recommandés ici...
> 
>> Bien sûr, ça n'excuse pas le fait que le stockage local soit ridiculement 
>> petit comparé à la taille d'un package de firmware (y compris sur les QFX au 
>> final...).
> 
> Et surtout, pas suffisant pour faire un snapshot recovery ! On se moque 
> souvent (assez gentiment) des marques "premier prix", pour des problèmes 
> moins critiques que çà, et pour des appareils qui, finalement, coûtent le 
> quart de celui-ci...
> 
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[Toussaint OTTAVI]

Le 23/01/2024 à 17:35, Cyril LAVIER a écrit :
Les EX2300 ne sont clairement pas du haut de gamme. En tant que switch 
edge/top of rack, c'est l'entrée de gamme chez Juniper.


En fait, je n'ai pas besoin de plus. Il n'y a que du L2 dessus, une 
dizaine de VLANs, et aucun des liens n'atteint le gigabit.


Pas pour rien que VChassis est soumis à licence et limité à 4 membres 
(au lieu de 10 pour les EX3400 ou EX4400).


Dans mon cas, deux me suffisent (tolérance de panne basique LACP). Donc, 
le choix des EX2300 me semblait pertinent. D'autant plus que les 
prédécesseurs EX2200 en "refurb" m'avaient été recommandés ici...


Bien sûr, ça n'excuse pas le fait que le stockage local soit 
ridiculement petit comparé à la taille d'un package de firmware (y 
compris sur les QFX au final...).


Et surtout, pas suffisant pour faire un snapshot recovery ! On se moque 
souvent (assez gentiment) des marques "premier prix", pour des problèmes 
moins critiques que çà, et pour des appareils qui, finalement, coûtent 
le quart de celui-ci...





---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[A Gaillard]

Hello,

Sur la problématique de ce qu'il faut log ou ne pas log sur les services
Wi-Fi  Guests et Hotspot d'après les textes, j'ai co rédigé un livre blanc
il y a une paire d'années, qui reste encore valable.

https://almond.eu/livre-blanc/livre-blanc-comment-mettre-en-place-un-service-de-wifi-public-conforme-au-droit-francais/

Normalement il y a tout dedans pour répondre à ce qu'on doit faire sur le
papier :)

Après on est d'accord que les investigations judiciaires ça n'arrivent
quasi jamais pour des petites entités, donc dans la vraie vie le calcul
effort/risque pourrait faire pencher la balance dans le sens de ne pas se
faire ch*** à mettre tout ça en place.

My 2 cents,
Adrien.

Le mar. 23 janv. 2024, 16:54, julien soula  a
écrit :

> On Mon, Jan 22, 2024 at 07:59:16PM +0100, David Ponzone wrote:
> > C’est ça qui est énorme: la finalité, c’est que l’autre branche du
> gouvernement, celle qui chasse les méchants, m’y oblige.
>
> La loi n'est pas a 1 contradiction pres. Par exemple, pour les demandes
> d'acces a un document administratif, il est dit << l'administration doit
> repondre dans le mois et tout refus doit etre justifie >> et + loin << une
> non-reponse de l'administration au bout d'1 mois vaut pour "non" >> !!!
>
>
> > Bon, pour revenir à la question de l’OP, ma devise c’est: on log un peu,
> pas trop, histoire d’avoir qqchose à donner aux chiens, et puis le reste on
> s’en fout.
> >
> > Tiens, il y a des experts dans la salle donc il faut que je demande: les
> impôts sont soumis au RGPD ? Je peux leur demander d’effacer mes données
> vieilles de plus de 12 mois ?
>
> je ne suis pas du tout un expert mais il se trouve que je viens de suivre
> une formation la-dessus, donc c'est encore frais. Pour les impots, on tombe
> dans la loi sur les "archives publiques" et c'est derogatoire au RPGD pour
> des raisons "d'interet publique ou scientifique". Ne m'en demandez pas + :)
>
> a+,
> --
> Julien
><< Vous n'avez rien a dire... Parlons-en! >>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[Cyril LAVIER]

Salut.

Les EX2300 ne sont clairement pas du haut de gamme. En tant que switch
edge/top of rack, c'est l'entrée de gamme chez Juniper.

Pas pour rien que VChassis est soumis à licence et limité à 4 membres (au
lieu de 10 pour les EX3400 ou EX4400).

Les EX3400 sont le milieu de gamme et les EX4400 sont plus haut en gamme
pour tout ce qui est edge/top of rack.

J'ai des EX2300 et EX3400 en production, et j'fais passer aucune data
sensible sur les EX2300, ils me servent de switchs pour du IPMI ou
management interfaces. Mon switch de base dans ce cas est l'EX3400.

Bien sûr, ça n'excuse pas le fait que le stockage local soit ridiculement
petit comparé à la taille d'un package de firmware (y compris sur les QFX
au final...).

On Tue, 23 Jan 2024 at 03:57, Toussaint OTTAVI  wrote:

>
> Le 22/01/2024 à 22:49, Jarod G. via frnog a écrit :
> > Pour les majs je te conseille en premier temps de passer les commandes
> > suivantes :
> >
> >> request system storage cleanup
> >> clear log wtmp
> >> request system snapshot delete previous
> >
> > Puis de pousser ton tgz de maj sur /tmp et pousser la commande
> > d'upgrade avec no-validate et no-copy
>
> Merci pour les réponses.
>
> Concernant les mises à jour, oui, j'ai réussi à m'en tirer en appliquant
> les différentes commandes de nettoyage, et en mettant mon package.tgz
> dans /tmp (et pas dans /var/tmp). Du coup, çà passe.
>
> En revanche, là où je n'ai pas de solution, c'est pour faire un snapshot
> en mode recovery :
>request system snapshot recovery :
>  mkuzip: write(/var/tmp/.snap.22622/recovery.ufs.uzip): No space
> left on device
>
> Si j'interprète bien le message d'erreur, ce n'est pas la place dans la
> partition /oam qui manque pour stocker le snapshot, mais c'est l'espace
> disque temporaire pour générer le fichier zip. Et là, je ne sais pas
> comment lui dire d'utiliser autre chose que /var/tmp comme espace
> temporaire.
>
>
> Le 22/01/2024 à 20:06, Cyril LAVIER a écrit :
> > Concernant ta question sur la clé USB, je dirais que techniquement, ça
> > ne devrait pas gêner, mais quid de la survie de la clé USB, même si ça
> > s'améliore, je trouve ça toujours trop peu fiable pour en laisser une
> > à demeure.
>
> Entre laisser une clef USB à demeure et prendre le risque de péter le
> fonctionnement parce que le disque est plein, mon choix est vite fait :-)
> Ceci étant, j'ai bien compris comment monter une clef USB en tant que
> stockage supplémentaire, par exemple pour y stocker mes .tgz. Mais je
> n'ai pas compris comment monter cette clef à la place de /var/tmp, pour
> que le système l'utilise pour ses propres fichiers temporaires...
>
> --
> Corollairement, pour un truc positionné assez haut en gamme, je trouve
> quand même çà assez peu sérieux. Ce truc bat à ce jour, et de loin, le
> temps passé en lab avant de pouvoir valider les tests de base ! Si je
> mets çà en prod, et que je vais devoir serrer les fesses chaque fois que
> j'ai une mise à jour à faire, autant installer une machine sous Windows
> et faire un routeur avec :-D
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
Cyril Lavier

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[julien soula]

On Mon, Jan 22, 2024 at 07:59:16PM +0100, David Ponzone wrote:
> C’est ça qui est énorme: la finalité, c’est que l’autre branche du 
> gouvernement, celle qui chasse les méchants, m’y oblige.

La loi n'est pas a 1 contradiction pres. Par exemple, pour les demandes d'acces 
a un document administratif, il est dit << l'administration doit repondre dans 
le mois et tout refus doit etre justifie >> et + loin << une non-reponse de 
l'administration au bout d'1 mois vaut pour "non" >> !!!


> Bon, pour revenir à la question de l’OP, ma devise c’est: on log un peu, pas 
> trop, histoire d’avoir qqchose à donner aux chiens, et puis le reste on s’en 
> fout.
> 
> Tiens, il y a des experts dans la salle donc il faut que je demande: les 
> impôts sont soumis au RGPD ? Je peux leur demander d’effacer mes données 
> vieilles de plus de 12 mois ?

je ne suis pas du tout un expert mais il se trouve que je viens de suivre une 
formation la-dessus, donc c'est encore frais. Pour les impots, on tombe dans la 
loi sur les "archives publiques" et c'est derogatoire au RPGD pour des raisons 
"d'interet publique ou scientifique". Ne m'en demandez pas + :)

a+,
-- 
Julien
   << Vous n'avez rien a dire... Parlons-en! >>


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS

[Olivier Cochard-Labbé]

On Mon, Jan 22, 2024 at 2:47 PM Julien Beaucourt 
wrote:

> Sinon j'ai toujours aimé cette marque concurrente de super micro, leurs
> cartes mères sont hyper robustes et les prix corrects c'est Tyan :
> https://www.tyan.com/
>
>
On déploie du serveur à base de Tyan depuis quelques années, et j’apprécie
l'accessibilité de leur support.
Que ce soit pour remplacer leur BMC propriétaire par de l’OpenBMC, ou nous
assister avec des SFP mal supportés par leur NIC embarqués, ils sont plus
réactifs que l’autre constructeur mentionné.

Olivier

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS

[Stéphane Rivière]

Aujourd'hui, on est full Dell en refurb.

+1 !

--
Stéphane Rivière
Ile d'Oléron - France

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Vinz Jumpertz via frnog]

le problème est que la france légifère dans son coin sans prendre en 
compte que certaines lois peuvent être contraire au droit européen, du 
coup c'est susceptible de changer.
par exemple dans ton article cité, il faut anonymiser toutes les données 
sauf dans les cas cités art II bis L34-1 CPCE. Bref un vrai casse-tête a 
la professeur shadoko


Mais bon il faut que la politique de confidentialité détaille bien tout 
et tu ne devrais pas avoir trop de soucies. Après la plupart des 
chambres d’hôtes utilisent la boite opérateur sans se préoccuper de tous 
cela


FYI, si vous ne suivez pas @alexArchambault sur twitter et que cela vous 
 intéresse il est recommandable.


Bon mardi


On 1/22/24 19:55, Jérôme Berthier via frnog wrote:

Le 22/01/2024 à 18:33, Vinz Jumpertz via frnog a écrit :
je vais poser la question qui fâche: quid de la RGPD? Est-ce vraiment 
nécessaire de collecter toutes ces données, car en cas de pépins ça va 
te retomber dessus. 


Je pense qu'on peut lancer une discussion dédiée. 🙂

J'ai toujours entendu dire que fournir un accès Internet à un visiteur 
nécessite la traçabilité d'un opérateur fournissant le service équivalent.


Vrai ou pas, je trouve ça intéressant de pouvoir se dédouaner de 
certains usages s'ils étaient réalisés depuis une connexion à mon nom.


Pour avoir regarder un peu le RGPD pour d'autres contextes, sans être 
juriste donc sans garantie, je dirai que dans ce cas, la base légale est 
l'obligation légale du fournisseur de l'accès Wifi : 
https://www.cnil.fr/fr/les-bases-legales/obligation-legale


ça justifie la collecte qui doit effectivement être strictement limitée 
au nécessaire, pour la durée utile et être documentée d'un affichage 
l'expliquant y compris les recours possible pour accéder aux données 
récoltées.


En théorie, je crois qu'il faut aussi tenir un registre des traitements 
documentant pourquoi on stocke ces données et qui y a accès.  Bon, dans 
le cas d'un hébergement, des données y en a bien d'autres et tout le 
monde se fout de comment c'est géré... genre les copies de pièce 
d'identité, ça me fait toujours halluciner. Aparté, le service Filigrane 
est sympa pour ça : https://filigrane.beta.gouv.fr/


Pour en revenir au contenu à collecter, j'en suis resté décret 2006-358 
du 24 mars 2006 donc :


« a) Les informations permettant d’identifier l’utilisateur ;
« b) Les données relatives aux équipements terminaux de communication 
utilisés ;
« c) Les caractéristiques techniques ainsi que la date, l’horaire et la 
durée de chaque communication ;
« d) Les données relatives aux services complémentaires demandés ou 
utilisés et leurs fournisseurs ;
« e) Les données permettant d’identifier le ou les destinataires de la 
communication.


donc le triptyque user/MAC/accounting IP habituel...

Depuis je crois que ça a été confirmé par la (magnifique) loi n° 
2021-998 du 30 juillet 2021 relative à la prévention d'actes de 
terrorisme et au renseignement : 
https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI43887545





---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[David Ponzone]

> Le 23 janv. 2024 à 10:42, Arnaud Launay  a écrit :
> 
> 
> Depuis, on est passés sur du Mikrotik et du FRR soft. Pas un ennui. Ça switch 
> à 40G,
> et ça route à 10G (oui, petite bite, je sais) sans broncher, sur une caisse 
> 10 fois
> moins chère qu'un Juniper et avec 16 fois de plus de ram et de cpu.
> 
> Ça encaisse sans broncher les ± 925000 routes actuelles, avec plusieurs full 
> transit,
> des peerings, etc.
> 

J’ai déjà dit que le VSR de 6Wind, ça déchire sa race, et le support est à la 
hauteur ? :)
Ah ben si je l’ai pas dit, je le dis :)



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[Arnaud Launay]

Le Tue, Jan 23, 2024 at 09:57:32AM +0100, Toussaint OTTAVI a écrit:
> Corollairement, pour un truc positionné assez haut en gamme, je trouve quand
> même çà assez peu sérieux. Ce truc bat à ce jour, et de loin, le temps passé
> en lab avant de pouvoir valider les tests de base ! Si je mets çà en prod,
> et que je vais devoir serrer les fesses chaque fois que j'ai une mise à jour
> à faire, autant installer une machine sous Windows et faire un routeur avec
> :-D

T'inquiètes pas, la prochaine fois que tu voudras faire une mise à jour, il te 
dira
que la cartouche d'encre bleue est vide à 70% et qu'il refuse de faire quoi que 
ce
soit tant que tu ne l'auras pas changée.

Plus sérieusement, le problème de stockage, que ce soit disque ou ram, est 
récurrent
chez Juniper. On ne vit pas dans le même monde qu'eux. Quand je vois les MX5 
d'il y a
10 ans qui avaient 2Go de ram et un processeur asthmatique... On aurait pu faire
abstraction du proc, mais les 2Go de ram, c'est ce qui les a tué pour nous.

Depuis, on est passés sur du Mikrotik et du FRR soft. Pas un ennui. Ça switch à 
40G,
et ça route à 10G (oui, petite bite, je sais) sans broncher, sur une caisse 10 
fois
moins chère qu'un Juniper et avec 16 fois de plus de ram et de cpu.

Ça encaisse sans broncher les ± 925000 routes actuelles, avec plusieurs full 
transit,
des peerings, etc.

Le MX5 serait en PLS depuis longtemps.

Arnaud.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS

[David Touitou]

Re-

> David, tu utilises Tyan ? Tu en es contant au niveau fiabilité et robustesse ?

Il y a plus de 20 ans, oui, quand je montais mes serveurs.
Aujourd'hui, on est full Dell en refurb.

David


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[Toussaint OTTAVI]

Le 22/01/2024 à 22:49, Jarod G. via frnog a écrit :
Pour les majs je te conseille en premier temps de passer les commandes 
suivantes :



request system storage cleanup
clear log wtmp
request system snapshot delete previous


Puis de pousser ton tgz de maj sur /tmp et pousser la commande 
d'upgrade avec no-validate et no-copy 


Merci pour les réponses.

Concernant les mises à jour, oui, j'ai réussi à m'en tirer en appliquant 
les différentes commandes de nettoyage, et en mettant mon package.tgz 
dans /tmp (et pas dans /var/tmp). Du coup, çà passe.


En revanche, là où je n'ai pas de solution, c'est pour faire un snapshot 
en mode recovery :

  request system snapshot recovery :
    mkuzip: write(/var/tmp/.snap.22622/recovery.ufs.uzip): No space 
left on device


Si j'interprète bien le message d'erreur, ce n'est pas la place dans la 
partition /oam qui manque pour stocker le snapshot, mais c'est l'espace 
disque temporaire pour générer le fichier zip. Et là, je ne sais pas 
comment lui dire d'utiliser autre chose que /var/tmp comme espace 
temporaire.



Le 22/01/2024 à 20:06, Cyril LAVIER a écrit :
Concernant ta question sur la clé USB, je dirais que techniquement, ça 
ne devrait pas gêner, mais quid de la survie de la clé USB, même si ça 
s'améliore, je trouve ça toujours trop peu fiable pour en laisser une 
à demeure.


Entre laisser une clef USB à demeure et prendre le risque de péter le 
fonctionnement parce que le disque est plein, mon choix est vite fait :-)
Ceci étant, j'ai bien compris comment monter une clef USB en tant que 
stockage supplémentaire, par exemple pour y stocker mes .tgz. Mais je 
n'ai pas compris comment monter cette clef à la place de /var/tmp, pour 
que le système l'utilise pour ses propres fichiers temporaires...


--
Corollairement, pour un truc positionné assez haut en gamme, je trouve 
quand même çà assez peu sérieux. Ce truc bat à ce jour, et de loin, le 
temps passé en lab avant de pouvoir valider les tests de base ! Si je 
mets çà en prod, et que je vais devoir serrer les fesses chaque fois que 
j'ai une mise à jour à faire, autant installer une machine sous Windows 
et faire un routeur avec :-D


---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS

[Gilles SAUVAIRE]

Bonjour,

David, tu utilises Tyan ? Tu en es contant au niveau fiabilité et robustesse ?



-Message d'origine-
De : frnog-requ...@frnog.org  De la part de David 
Touitou
Envoyé : mardi 23 janvier 2024 09:02
À : Gilles SAUVAIRE 
Cc : Julien Beaucourt ; frnog-tech 
Objet : Re: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS

'jour.

> Oui effectivement https://www.tyan.com/ J'avoue que je n'avais jamais 
> entendu parler...

OMG.

#Team dino.
#Team "bi-Pentium Pro".

Mon premier serveur d'hébergement, au bout d'une 64 kb Oleane.

Le PR de la Talon (un peu plus de 25 ans) est toujours sur leur site : 
https://www.tyan.com/en-US@179~PRDetail 

David


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS

[David Touitou]

'jour.

> Oui effectivement https://www.tyan.com/
> J'avoue que je n'avais jamais entendu parler...

OMG.

#Team dino.
#Team "bi-Pentium Pro".

Mon premier serveur d'hébergement, au bout d'une 64 kb Oleane.

Le PR de la Talon (un peu plus de 25 ans) est toujours sur leur site : 
https://www.tyan.com/en-US@179~PRDetail 

David


---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS

[Gilles SAUVAIRE]

Oui effectivement https://www.tyan.com/
J'avoue que je n'avais jamais entendu parler...



-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Julien
Beaucourt
Envoyé : lundi 22 janvier 2024 14:48
À : Gilles SAUVAIRE ; frnog-t...@frnog.org
Objet : RE: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS

Sinon j'ai toujours aimé cette marque concurrente de super micro, leurs
cartes mères sont hyper robustes et les prix corrects c'est Tyan :
https://www.tyan.com/

Ju

-Original Message-
From: frnog-requ...@frnog.org  On Behalf Of Julien
Beaucourt
Sent: lundi 22 janvier 2024 13:58
To: Gilles SAUVAIRE ; frnog-t...@frnog.org
Subject: RE: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS

Hello Gilles,

Pour ma part j'ai aussi eu quelques problèmes de fiabilité sur mes
supermicro, ce sont des nœud badgés nutanix (NX), donc de grosses
configurations, les problèmes viennent tous pour ma part des contrôleurs
disques qui lâchent au bout de 6 ans, du coup perte du nœud et il faut
remplacer la CM... Sinon j'aime bien ce matériel globalement je les trouve
bien construits et bien assemblés (et l'ipmi est sympa). Après partir sur du
asus, pas sûr, ça fait trop grand public pour être fiable pour moi, pourquoi
tu ne tentes pas un constructeur 'legacy' type Dell ou Lenovo ? J'ai pas mal
de Dell ça tient fort, pour le coup que des disques qui ont pétés. 

Sinon contactes-moi pour échanger.

Bonne journée,


Julien Beaucourt - CEO - Fondateur 
+33 6 61 76 66 34 - +33 1 84 19 80 94
74 rue du château, 92100 Boulogne-Billancourt

  


This message and any attachments (the « message ») is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. Mikado Labs SAS shall (will) not therefore be
liable for the message if modified.
Ce message et toutes les pièces jointes (ci-après le « message ») sont
établis a l’intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur, merci de le détruire et d’en avertir
immédiatement expéditeur. Toute utilisation de ce message non conforme a sa
destination, toute diffusion ou toute publication, totale ou partielle, est
interdite, sauf autorisation expresse. Internet ne permettant pas d’assurer
l'intégrité de ce message, Mikado Labs SAS décline toute responsabilité au
titre de ce message, dans hypothèse ou il aurait été modifié




 

-Original Message-
From: frnog-requ...@frnog.org  On Behalf Of Gilles
SAUVAIRE
Sent: lundi 22 janvier 2024 13:14
To: frnog-t...@frnog.org
Subject: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS
Importance: High

[Vous ne recevez pas souvent de courriers de gil...@sauvaire.com. Découvrez
pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification
]

Bonjour,



J'utilise pas mal les serveurs 2U ou 1U de chez SuperMicro.

(Avec IPMI, double proc...)

Ces derniers temps, je ne suis pas contant de la fiabilité...



Mon fournisseur SuperMicro me propose de l'ASUS ??

Je ne savais même pas que ASUS fabriquait cela.

Exemple :  Asus RS700-E11-RS12U

Avec double alim, IPMI...



Est-ce que quelqu'un utilise ce type de serveur de marque ASUS ?

Fiabilité ? Depuis longtemps ?



Merci pour vos avis,



Gilles












---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[Jarod G. via frnog]

Salut,

On a une blinde d'EX2300 et EX3400 (les deux ont le même soucis) à $job

Il y a une KB à ce sujet : 
https://kb.juniper.net/InfoCenter/index?page=content&id=KB31198


Pour les majs je te conseille en premier temps de passer les commandes 
suivantes :



request system storage cleanup
clear log wtmp
request system snapshot delete previous

(s'assurer également qu'il y a pas des snapshots qui traînent)

Puis de pousser ton tgz de maj sur /tmp et pousser la commande d'upgrade 
avec no-validate et no-copy


Si ça passe pas car toujours pas assez de place, tu peux faire un


file list /packages/sets/ detail
et vérifier qu'il y a que la version "active" des paquets JunOS qui 
existent.
J'ai toujours nettoyé manuellement mais à priori y a des commandes fait 
pour dans la KB plus haut, je t'invite à y jeter un oeil.



À défaut si t'es vraiment désespéré : 
https://kb.juniper.net/InfoCenter/index?page=content&id=KB31265



A+

Jarod G.

Le 22/01/2024 à 16:32, Toussaint OTTAVI a écrit :

Salut les pros de Juniper,

J'ai deux EX2300 en lab, avec lesquels je me casse les dents depuis un 
moment, au point que je n'ai nulle confiance à les mettre en prod ! 
Les problèmes, assez récurrents, tournent toujours autour de l'espace 
disponible dans /var/tmp, et çà bloque la plupart des opérations de 
maintenance de base.


Bien entendu, les méthodes documentées de nettoyage ne suffisent 
absolument pas (request system storage cleanup, request system 
snapshot delete snap*, start shell command "pkg setop rm previous" , 
etc...).


Par exemple, il est impossible de faire une mise à jour JunOS en 
stockant le firmware .tgz dans /var/tmp, comme c'est indiqué dans à 
peu près toutes les docs que j'ai pu lire. Je m'en tire en mettant mon 
.tgz sur clef USB. J'ai découvert également qu'il y avait un autre 
point de montage tmpfs sur lequel il y a (un peu) plus de place  : /tmp


En revanche, un autre truc plus problématique qui coince, c'est la 
création des snapshots recovery (request system snapshot recovery) :
  mkuzip: write(/var/tmp/.snap.22622/recovery.ufs.uzip): No space left 
on device


Donc, si je comprends bien, ce n'est pas l'espace sur la partition 
/oam qui manque pour stocker le snapshot final, mais plutôt l'espace 
temporaire pour créer celui-ci. Et là, je ne sais pas comment lui dire 
d'utiliser /tmp au lieu de /var/tmp !


En regardant les points de montage d'un peu plus près :
df -h | grep /tmp
  tmpfs  826M 16K    826M 0%    /.mount/tmp
  /var/tmp   1.3G    544M    712M    43% 
/.mount/packages/mnt/jweb-ex-33d6a634/jail/var/tmp


Donc, je ne connais rien à FreeBSD ni aux jails, mais on dirait que le 
package j-web a "détourné" mon /var/tmp !


Questions :
- Puis-je monter mon /var/tmp au même endroit que /tmp pour qu'il y 
ait plus de place ?
- Quelqu'un  a t-il trouvé le moyen de souder 2 Go de flash 
supplémentaires ? Peut-on laisser une clef USB à demeure, et monter 
/var/tmp de façon permanente dessus ?


Parce que là, vu le prix de base des engins, comment dire... Cà me 
donnerait presque envie de les re-flasher sous OpenWRT :-D



---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tencent sur aucun IX en France ?

[Vincent Bernat]

On 2024-01-22 09:40, David Ponzone wrote:

En plus, je viens de voir qu’ils s’amusent bien avec leurs annonces:
tous leurs biocs sont désagrégés, et annoncés à différents transits, un
peu comme on faisait pour optimiser le load-balancing à la fin des
années 90…..

On fait comment de nos jours ?

J’avais la faiblesse de penser que le ratio coût de la bande passante/besoin 
avait largement diminué.


Quand on a besoin de beaucoup de BP, c'est mieux de répartir sur 
plusieurs routeurs et dans ce cas, on ne peut pas forcément compter sur 
ceux en face pour répartir correctement le trafic.



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Jérôme Berthier via frnog]

Le 22/01/2024 à 18:33, Vinz Jumpertz via frnog a écrit :
je vais poser la question qui fâche: quid de la RGPD? Est-ce vraiment 
nécessaire de collecter toutes ces données, car en cas de pépins ça va 
te retomber dessus. 


Je pense qu'on peut lancer une discussion dédiée. 🙂

J'ai toujours entendu dire que fournir un accès Internet à un visiteur 
nécessite la traçabilité d'un opérateur fournissant le service équivalent.


Vrai ou pas, je trouve ça intéressant de pouvoir se dédouaner de 
certains usages s'ils étaient réalisés depuis une connexion à mon nom.


Pour avoir regarder un peu le RGPD pour d'autres contextes, sans être 
juriste donc sans garantie, je dirai que dans ce cas, la base légale est 
l'obligation légale du fournisseur de l'accès Wifi : 
https://www.cnil.fr/fr/les-bases-legales/obligation-legale


ça justifie la collecte qui doit effectivement être strictement limitée 
au nécessaire, pour la durée utile et être documentée d'un affichage 
l'expliquant y compris les recours possible pour accéder aux données 
récoltées.


En théorie, je crois qu'il faut aussi tenir un registre des traitements 
documentant pourquoi on stocke ces données et qui y a accès.  Bon, dans 
le cas d'un hébergement, des données y en a bien d'autres et tout le 
monde se fout de comment c'est géré... genre les copies de pièce 
d'identité, ça me fait toujours halluciner. Aparté, le service Filigrane 
est sympa pour ça : https://filigrane.beta.gouv.fr/


Pour en revenir au contenu à collecter, j'en suis resté décret 2006-358 
du 24 mars 2006 donc :


« a) Les informations permettant d’identifier l’utilisateur ;
« b) Les données relatives aux équipements terminaux de communication 
utilisés ;
« c) Les caractéristiques techniques ainsi que la date, l’horaire et la 
durée de chaque communication ;
« d) Les données relatives aux services complémentaires demandés ou 
utilisés et leurs fournisseurs ;
« e) Les données permettant d’identifier le ou les destinataires de la 
communication.


donc le triptyque user/MAC/accounting IP habituel...

Depuis je crois que ça a été confirmé par la (magnifique) loi n° 
2021-998 du 30 juillet 2021 relative à la prévention d'actes de 
terrorisme et au renseignement : 
https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI43887545


--
Jérôme Berthier


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[Cyril LAVIER]

Salut.

Concernant les mises à jour, t'as essayé de passer par un HTTP/FTP local ?

Les quelques EX2300 que j'ai en prod, je les ai tous mis à jour avec un
repo HTTP local que j'ai mis en place pour me faciliter la vie.

Concernant ta question sur la clé USB, je dirais que techniquement, ça ne
devrait pas gêner, mais quid de la survie de la clé USB, même si ça
s'améliore, je trouve ça toujours trop peu fiable pour en laisser une à
demeure.

On Mon, 22 Jan 2024 at 10:32, Toussaint OTTAVI  wrote:

> Salut les pros de Juniper,
>
> J'ai deux EX2300 en lab, avec lesquels je me casse les dents depuis un
> moment, au point que je n'ai nulle confiance à les mettre en prod ! Les
> problèmes, assez récurrents, tournent toujours autour de l'espace
> disponible dans /var/tmp, et çà bloque la plupart des opérations de
> maintenance de base.
>
> Bien entendu, les méthodes documentées de nettoyage ne suffisent
> absolument pas (request system storage cleanup, request system snapshot
> delete snap*, start shell command "pkg setop rm previous" , etc...).
>
> Par exemple, il est impossible de faire une mise à jour JunOS en
> stockant le firmware .tgz dans /var/tmp, comme c'est indiqué dans à peu
> près toutes les docs que j'ai pu lire. Je m'en tire en mettant mon .tgz
> sur clef USB. J'ai découvert également qu'il y avait un autre point de
> montage tmpfs sur lequel il y a (un peu) plus de place  : /tmp
>
> En revanche, un autre truc plus problématique qui coince, c'est la
> création des snapshots recovery (request system snapshot recovery) :
>mkuzip: write(/var/tmp/.snap.22622/recovery.ufs.uzip): No space left
> on device
>
> Donc, si je comprends bien, ce n'est pas l'espace sur la partition /oam
> qui manque pour stocker le snapshot final, mais plutôt l'espace
> temporaire pour créer celui-ci. Et là, je ne sais pas comment lui dire
> d'utiliser /tmp au lieu de /var/tmp !
>
> En regardant les points de montage d'un peu plus près :
> df -h | grep /tmp
>tmpfs  826M 16K826M 0%/.mount/tmp
>/var/tmp   1.3G544M712M43%
> /.mount/packages/mnt/jweb-ex-33d6a634/jail/var/tmp
>
> Donc, je ne connais rien à FreeBSD ni aux jails, mais on dirait que le
> package j-web a "détourné" mon /var/tmp !
>
> Questions :
> - Puis-je monter mon /var/tmp au même endroit que /tmp pour qu'il y ait
> plus de place ?
> - Quelqu'un  a t-il trouvé le moyen de souder 2 Go de flash
> supplémentaires ? Peut-on laisser une clef USB à demeure, et monter
> /var/tmp de façon permanente dessus ?
>
> Parce que là, vu le prix de base des engins, comment dire... Cà me
> donnerait presque envie de les re-flasher sous OpenWRT :-D
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
Cyril Lavier

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[David Ponzone]

C’est ça qui est énorme: la finalité, c’est que l’autre branche du 
gouvernement, celle qui chasse les méchants, m’y oblige.

Bon, pour revenir à la question de l’OP, ma devise c’est: on log un peu, pas 
trop, histoire d’avoir qqchose à donner aux chiens, et puis le reste on s’en 
fout.

Tiens, il y a des experts dans la salle donc il faut que je demande: les impôts 
sont soumis au RGPD ? Je peux leur demander d’effacer mes données vieilles de 
plus de 12 mois ?


> Le 22 janv. 2024 à 19:50, julien soula  a écrit :
> 
> bonjour,
> 
> le RGPD n'interdit nullement de collecter des donnees personnelles. Seulement 
> il faut que ce soit declare avec finalite precise, information et delai de 
> peremption.
> 
> Apres il vaut mieux que ce soit des donnees non directement identifiables 
> (MAC@, No de chambre). ca passe mieux car pas facilement exploitable si 
> divulge.
> 
> a+,


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[julien soula]

bonjour,

le RGPD n'interdit nullement de collecter des donnees personnelles. Seulement 
il faut que ce soit declare avec finalite precise, information et delai de 
peremption.

Apres il vaut mieux que ce soit des donnees non directement identifiables 
(MAC@, No de chambre). ca passe mieux car pas facilement exploitable si divulge.

a+,


On Mon, Jan 22, 2024 at 06:10:51PM +, Vinz Jumpertz via frnog wrote:
> seul problème la mac est une donnée personnelle.
> c'est un peu la peste ou le choléra
> 
> On 1/22/24 17:56, David Ponzone wrote:
> > Oui, à mon avis, il faut pas garder l’identité de la personne.
> > Juste le lien entre les connexions IP sortantes, et la MAC SRC.
> > Mais bon, dans un pays avec 500 000 lois, fallait bien s’attendre à 
> > quelques contradictions.
> > 
> > 
> > > Le 22 janv. 2024 à 18:33, Vinz Jumpertz via frnog  a 
> > > écrit :
> > > 
> > > Hello,
> > > 
> > > je vais poser la question qui fâche: quid de la RGPD? Est-ce vraiment 
> > > nécessaire de collecter toutes ces données, car en cas de pépins ça va te 
> > > retomber dessus.
> > > 
> > > Vincent
> > > 
> > > On 1/22/24 12:48, David Ponzone wrote:
> > > > > Le 22 janv. 2024 à 11:56, Jérôme Berthier via frnog  
> > > > > a écrit :
> > > > > 
> > > > > 
> > > > > Merci David pour cette remarque !
> > > > > 
> > > > > En relisant quelques docs et posts sur le forum UniFi, j'ai 
> > > > > effectivement un gros doute aussi.
> > > > > 
> > > > > L'idée du déploiement est évidemment d'avoir la traçabilité entre le 
> > > > > client (voucher hotspot) et son usage (terminal / trafic IP).
> > > > > 
> > > > > Il me faut donc la traçabilité :
> > > > > 
> > > > > - des connexions hotspot en pouvant faire le lien entre le 
> > > > > client/voucher et son terminal (idéalement sur un an).
> > > > > 
> > > > > - du trafic en lien avec le terminal (idéalement le voucher donc le 
> > > > > client)
> > > > > 
> > > > > Pour croiser tout ça, j'ai donc besoin des logs : sessions portail 
> > > > > (client/voucher <-> MAC), MAC <-> DHCP, accounting IP (src / dst / 
> > > > > ports...), translations NAT.
> > > > > 
> > > > > Je pensais que les gateways UniFi et la fonction Hotspot gérée dans 
> > > > > Network Server permettaient d'avoir ça mais c'est franchement pas 
> > > > > clair.
> > > > > 
> > > > > Je crois même comprendre le contraire en lisant le forum Community 
> > > > > UniFi.
> > > > > 
> > > > Encore un fois, c’est compliqué parce qu’en France/UE, personne ne 
> > > > semble vraiment comprendre ce qu’on doit logguer vs ce qu’on a pas le 
> > > > droit de logguer à cause d’un réglementation à la con.
> > > > Ce que je sais, c’est qu'un routeur MK devant les AP, configuré pour 
> > > > logguer les TCP SYN sortants, et tu auras MAC SRC, PROTO, SRC IP, SRC 
> > > > PORT, DST IP, DST PORT, dans syslog, une ligne par connexion sortante 
> > > > établie.
> > > > Pour UDP, c’est plus compliqué, parce que ça va être plus verbeux. 
> > > > Beaucoup plus.
> > > > Mais y a-t-il encore du traffic UDP qui mérite d’être loggué ?
> > > > David
> > > > ---
> > > > Liste de diffusion du FRnOG
> > > > http://www.frnog.org/
> > > 
> > > 
> > > ---
> > > Liste de diffusion du FRnOG
> > > http://www.frnog.org/
> > 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

-- 
Julien
   << Vous n'avez rien a dire... Parlons-en! >>

-- 
Julien
   << Vous n'avez rien a dire... Parlons-en! >>


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[David Ponzone]

Ces lois sont donc encore plus ridicules que ce que je pensais.
Une donnée que n’importe qui peut falsifier est une donnée personnelle…

Ben alors, ça va, si le RGPD empêche de collecter quoi que ce soit, y a qu’à 
répondre ça à la RJ :)


> Le 22 janv. 2024 à 19:10, Vinz Jumpertz via frnog  a écrit :
> 
> seul problème la mac est une donnée personnelle.
> c'est un peu la peste ou le choléra
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Vinz Jumpertz via frnog]

seul problème la mac est une donnée personnelle.
c'est un peu la peste ou le choléra

On 1/22/24 17:56, David Ponzone wrote:

Oui, à mon avis, il faut pas garder l’identité de la personne.
Juste le lien entre les connexions IP sortantes, et la MAC SRC.
Mais bon, dans un pays avec 500 000 lois, fallait bien s’attendre à quelques 
contradictions.



Le 22 janv. 2024 à 18:33, Vinz Jumpertz via frnog  a écrit :

Hello,

je vais poser la question qui fâche: quid de la RGPD? Est-ce vraiment 
nécessaire de collecter toutes ces données, car en cas de pépins ça va te 
retomber dessus.

Vincent

On 1/22/24 12:48, David Ponzone wrote:

Le 22 janv. 2024 à 11:56, Jérôme Berthier via frnog  a écrit :


Merci David pour cette remarque !

En relisant quelques docs et posts sur le forum UniFi, j'ai effectivement un 
gros doute aussi.

L'idée du déploiement est évidemment d'avoir la traçabilité entre le client 
(voucher hotspot) et son usage (terminal / trafic IP).

Il me faut donc la traçabilité :

- des connexions hotspot en pouvant faire le lien entre le client/voucher et 
son terminal (idéalement sur un an).

- du trafic en lien avec le terminal (idéalement le voucher donc le client)

Pour croiser tout ça, j'ai donc besoin des logs : sessions portail (client/voucher 
<-> MAC), MAC <-> DHCP, accounting IP (src / dst / ports...), translations NAT.

Je pensais que les gateways UniFi et la fonction Hotspot gérée dans Network 
Server permettaient d'avoir ça mais c'est franchement pas clair.

Je crois même comprendre le contraire en lisant le forum Community UniFi.


Encore un fois, c’est compliqué parce qu’en France/UE, personne ne semble 
vraiment comprendre ce qu’on doit logguer vs ce qu’on a pas le droit de logguer 
à cause d’un réglementation à la con.
Ce que je sais, c’est qu'un routeur MK devant les AP, configuré pour logguer 
les TCP SYN sortants, et tu auras MAC SRC, PROTO, SRC IP, SRC PORT, DST IP, DST 
PORT, dans syslog, une ligne par connexion sortante établie.
Pour UDP, c’est plus compliqué, parce que ça va être plus verbeux. Beaucoup 
plus.
Mais y a-t-il encore du traffic UDP qui mérite d’être loggué ?
David
---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/





---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[David Ponzone]

Oui, à mon avis, il faut pas garder l’identité de la personne.
Juste le lien entre les connexions IP sortantes, et la MAC SRC.
Mais bon, dans un pays avec 500 000 lois, fallait bien s’attendre à quelques 
contradictions.


> Le 22 janv. 2024 à 18:33, Vinz Jumpertz via frnog  a écrit :
> 
> Hello,
> 
> je vais poser la question qui fâche: quid de la RGPD? Est-ce vraiment 
> nécessaire de collecter toutes ces données, car en cas de pépins ça va te 
> retomber dessus.
> 
> Vincent
> 
> On 1/22/24 12:48, David Ponzone wrote:
>>> Le 22 janv. 2024 à 11:56, Jérôme Berthier via frnog  a 
>>> écrit :
>>> 
>>> 
>>> Merci David pour cette remarque !
>>> 
>>> En relisant quelques docs et posts sur le forum UniFi, j'ai effectivement 
>>> un gros doute aussi.
>>> 
>>> L'idée du déploiement est évidemment d'avoir la traçabilité entre le client 
>>> (voucher hotspot) et son usage (terminal / trafic IP).
>>> 
>>> Il me faut donc la traçabilité :
>>> 
>>> - des connexions hotspot en pouvant faire le lien entre le client/voucher 
>>> et son terminal (idéalement sur un an).
>>> 
>>> - du trafic en lien avec le terminal (idéalement le voucher donc le client)
>>> 
>>> Pour croiser tout ça, j'ai donc besoin des logs : sessions portail 
>>> (client/voucher <-> MAC), MAC <-> DHCP, accounting IP (src / dst / 
>>> ports...), translations NAT.
>>> 
>>> Je pensais que les gateways UniFi et la fonction Hotspot gérée dans Network 
>>> Server permettaient d'avoir ça mais c'est franchement pas clair.
>>> 
>>> Je crois même comprendre le contraire en lisant le forum Community UniFi.
>>> 
>> Encore un fois, c’est compliqué parce qu’en France/UE, personne ne semble 
>> vraiment comprendre ce qu’on doit logguer vs ce qu’on a pas le droit de 
>> logguer à cause d’un réglementation à la con.
>> Ce que je sais, c’est qu'un routeur MK devant les AP, configuré pour logguer 
>> les TCP SYN sortants, et tu auras MAC SRC, PROTO, SRC IP, SRC PORT, DST IP, 
>> DST PORT, dans syslog, une ligne par connexion sortante établie.
>> Pour UDP, c’est plus compliqué, parce que ça va être plus verbeux. Beaucoup 
>> plus.
>> Mais y a-t-il encore du traffic UDP qui mérite d’être loggué ?
>> David
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Anthony Deshayes]

Salut,

Si ça peut aider, ma dernière installation dans un hôtel avec des bornes
Unifi (une vingtaine), j'avais utilisé la solution Hotspot LC+ de MHZShop (
https://www.mhzshop.com/shop/Hotspot/Autonome).

Tu reçois un routeur MK / un miniPC avec le software et licence
pré-installés.
Ensuite tu configures selon tes souhaits (type de voucher/clé
individuelleetc) avec l'interface simple à prendre en main.
En cas de soucis le support de MHZShop répond présent.

J'ai installé cette solution en 2018 et ça fonctionne toujours.

Je précise que je n'ai aucun lien avec ce prestataire mais j'ai un rex
suffisamment long maintenant pour dire que cela fonctionne.
A voir maintenant si le coût est raisonnable pour ton besoin

Anthony

Le lun. 22 janv. 2024 à 13:17, Jérôme Berthier via frnog 
a écrit :

> Le 22/01/2024 à 12:09, Pierre-Henry Muller via frnog a écrit :
> > Petit retour d'expérience, UI ne permet pas le niveau de détail que tu
> > demandes.
> >
> > Le réseau guest avec voucher ou avec portail, ne demande même pas les
> > infos obligatoires que son nom / prénom / email, le portail ne peut
> > être modifié sur ce point, seule les couleurs et les CGV peuvent être
> > modifiées.
> >
> > De plus même une dream machine qui fait office de firewall / routeur,
> > lorsqu'on active le flux syslog vers un concentrateur, on ne reçoit
> > pas le détail du traffic, assignation dhcp et autres infos
> > intéressantes mais seulement les logs systèmes de la dream machine et
> > des bornes ...
>
>
> CQFD. Merci
>
>
> >
> > Bilan on a viré notre wifi guest
>
> Oui mais en 2024, c'est pas une option pour des chambres d'hôtes. 🙂
>
> Je vais voir :
>
> - soit pour intercaler un service de portail captif qui fera le job :
> Alcasar, CloudSpot, Ucopia (mais j'ai pas de canal d'achat) ou tout
> autre suggestion bienvenue
>
> - soit pour ne pas compléter la base UniFi et partir sur autre chose qui
> ferait le job sans sortir des montagnes d'euro.
>
> On me souffle TP-Link Omada (cité aussi mi décembre dans la discussion
> sur une problématique similaire). ça serait un équivalent de la logique
> UniFi mais les traces portail captif / trafic sont-elles correctes et
> exhaustives ?
>
> --
> Jérôme Berthier
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Vinz Jumpertz via frnog]

Hello,

je vais poser la question qui fâche: quid de la RGPD? Est-ce vraiment 
nécessaire de collecter toutes ces données, car en cas de pépins ça va 
te retomber dessus.


Vincent

On 1/22/24 12:48, David Ponzone wrote:



Le 22 janv. 2024 à 11:56, Jérôme Berthier via frnog  a écrit :


Merci David pour cette remarque !

En relisant quelques docs et posts sur le forum UniFi, j'ai effectivement un 
gros doute aussi.

L'idée du déploiement est évidemment d'avoir la traçabilité entre le client 
(voucher hotspot) et son usage (terminal / trafic IP).

Il me faut donc la traçabilité :

- des connexions hotspot en pouvant faire le lien entre le client/voucher et 
son terminal (idéalement sur un an).

- du trafic en lien avec le terminal (idéalement le voucher donc le client)

Pour croiser tout ça, j'ai donc besoin des logs : sessions portail (client/voucher 
<-> MAC), MAC <-> DHCP, accounting IP (src / dst / ports...), translations NAT.

Je pensais que les gateways UniFi et la fonction Hotspot gérée dans Network 
Server permettaient d'avoir ça mais c'est franchement pas clair.

Je crois même comprendre le contraire en lisant le forum Community UniFi.



Encore un fois, c’est compliqué parce qu’en France/UE, personne ne semble 
vraiment comprendre ce qu’on doit logguer vs ce qu’on a pas le droit de logguer 
à cause d’un réglementation à la con.
Ce que je sais, c’est qu'un routeur MK devant les AP, configuré pour logguer 
les TCP SYN sortants, et tu auras MAC SRC, PROTO, SRC IP, SRC PORT, DST IP, DST 
PORT, dans syslog, une ligne par connexion sortante établie.
Pour UDP, c’est plus compliqué, parce que ça va être plus verbeux. Beaucoup 
plus.
Mais y a-t-il encore du traffic UDP qui mérite d’être loggué ?

David


---
Liste de diffusion du FRnOG
http://www.frnog.org/



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[David Ponzone]

Mais non, un MK à 50€ devant tout ça, et c’est bon.

Après, faut se détendre: en plusieurs années, j’ai jamais eu une réquisition 
pour une IP, alors que pour des numéros de téléphone, c’est une par mois au 
moins.
Pour les IP, on a un mail de Paramount de temps en temps, mais ça a pas 
vraiment la valeur d’une RJ :)

David


> Le 22 janv. 2024 à 18:17, Jérôme Berthier via frnog  a écrit 
> :
> 
> Le 22/01/2024 à 12:09, Pierre-Henry Muller via frnog a écrit :
>> Petit retour d'expérience, UI ne permet pas le niveau de détail que tu 
>> demandes.
>> 
>> Le réseau guest avec voucher ou avec portail, ne demande même pas les infos 
>> obligatoires que son nom / prénom / email, le portail ne peut être modifié 
>> sur ce point, seule les couleurs et les CGV peuvent être modifiées.
>> 
>> De plus même une dream machine qui fait office de firewall / routeur, 
>> lorsqu'on active le flux syslog vers un concentrateur, on ne reçoit pas le 
>> détail du traffic, assignation dhcp et autres infos intéressantes mais 
>> seulement les logs systèmes de la dream machine et des bornes ...
> 
> 
> CQFD. Merci
> 
> 
>> 
>> Bilan on a viré notre wifi guest 
> 
> Oui mais en 2024, c'est pas une option pour des chambres d'hôtes. 🙂
> 
> Je vais voir :
> 
> - soit pour intercaler un service de portail captif qui fera le job : 
> Alcasar, CloudSpot, Ucopia (mais j'ai pas de canal d'achat) ou tout autre 
> suggestion bienvenue
> 
> - soit pour ne pas compléter la base UniFi et partir sur autre chose qui 
> ferait le job sans sortir des montagnes d'euro.
> 
> On me souffle TP-Link Omada (cité aussi mi décembre dans la discussion sur 
> une problématique similaire). ça serait un équivalent de la logique UniFi 
> mais les traces portail captif / trafic sont-elles correctes et exhaustives ?
> 
> -- 
> Jérôme Berthier
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Jérôme Berthier via frnog]

Le 22/01/2024 à 12:09, Pierre-Henry Muller via frnog a écrit :
Petit retour d'expérience, UI ne permet pas le niveau de détail que tu 
demandes.


Le réseau guest avec voucher ou avec portail, ne demande même pas les 
infos obligatoires que son nom / prénom / email, le portail ne peut 
être modifié sur ce point, seule les couleurs et les CGV peuvent être 
modifiées.


De plus même une dream machine qui fait office de firewall / routeur, 
lorsqu'on active le flux syslog vers un concentrateur, on ne reçoit 
pas le détail du traffic, assignation dhcp et autres infos 
intéressantes mais seulement les logs systèmes de la dream machine et 
des bornes ...



CQFD. Merci




Bilan on a viré notre wifi guest 


Oui mais en 2024, c'est pas une option pour des chambres d'hôtes. 🙂

Je vais voir :

- soit pour intercaler un service de portail captif qui fera le job : 
Alcasar, CloudSpot, Ucopia (mais j'ai pas de canal d'achat) ou tout 
autre suggestion bienvenue


- soit pour ne pas compléter la base UniFi et partir sur autre chose qui 
ferait le job sans sortir des montagnes d'euro.


On me souffle TP-Link Omada (cité aussi mi décembre dans la discussion 
sur une problématique similaire). ça serait un équivalent de la logique 
UniFi mais les traces portail captif / trafic sont-elles correctes et 
exhaustives ?


--
Jérôme Berthier


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Juniper EX2300 /var/tmp : no space left

[Toussaint OTTAVI]

Salut les pros de Juniper,

J'ai deux EX2300 en lab, avec lesquels je me casse les dents depuis un 
moment, au point que je n'ai nulle confiance à les mettre en prod ! Les 
problèmes, assez récurrents, tournent toujours autour de l'espace 
disponible dans /var/tmp, et çà bloque la plupart des opérations de 
maintenance de base.


Bien entendu, les méthodes documentées de nettoyage ne suffisent 
absolument pas (request system storage cleanup, request system snapshot 
delete snap*, start shell command "pkg setop rm previous" , etc...).


Par exemple, il est impossible de faire une mise à jour JunOS en 
stockant le firmware .tgz dans /var/tmp, comme c'est indiqué dans à peu 
près toutes les docs que j'ai pu lire. Je m'en tire en mettant mon .tgz 
sur clef USB. J'ai découvert également qu'il y avait un autre point de 
montage tmpfs sur lequel il y a (un peu) plus de place  : /tmp


En revanche, un autre truc plus problématique qui coince, c'est la 
création des snapshots recovery (request system snapshot recovery) :
  mkuzip: write(/var/tmp/.snap.22622/recovery.ufs.uzip): No space left 
on device


Donc, si je comprends bien, ce n'est pas l'espace sur la partition /oam 
qui manque pour stocker le snapshot final, mais plutôt l'espace 
temporaire pour créer celui-ci. Et là, je ne sais pas comment lui dire 
d'utiliser /tmp au lieu de /var/tmp !


En regardant les points de montage d'un peu plus près :
df -h | grep /tmp
  tmpfs  826M 16K    826M 0%    /.mount/tmp
  /var/tmp   1.3G    544M    712M    43% 
/.mount/packages/mnt/jweb-ex-33d6a634/jail/var/tmp


Donc, je ne connais rien à FreeBSD ni aux jails, mais on dirait que le 
package j-web a "détourné" mon /var/tmp !


Questions :
- Puis-je monter mon /var/tmp au même endroit que /tmp pour qu'il y ait 
plus de place ?
- Quelqu'un  a t-il trouvé le moyen de souder 2 Go de flash 
supplémentaires ? Peut-on laisser une clef USB à demeure, et monter 
/var/tmp de façon permanente dessus ?


Parce que là, vu le prix de base des engins, comment dire... Cà me 
donnerait presque envie de les re-flasher sous OpenWRT :-D



---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS

[Julien Beaucourt]

Sinon j'ai toujours aimé cette marque concurrente de super micro, leurs cartes 
mères sont hyper robustes et les prix corrects c'est Tyan : 
https://www.tyan.com/

Ju

-Original Message-
From: frnog-requ...@frnog.org  On Behalf Of Julien 
Beaucourt
Sent: lundi 22 janvier 2024 13:58
To: Gilles SAUVAIRE ; frnog-t...@frnog.org
Subject: RE: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS

Hello Gilles,

Pour ma part j'ai aussi eu quelques problèmes de fiabilité sur mes supermicro, 
ce sont des nœud badgés nutanix (NX), donc de grosses configurations, les 
problèmes viennent tous pour ma part des contrôleurs disques qui lâchent au 
bout de 6 ans, du coup perte du nœud et il faut remplacer la CM... Sinon j'aime 
bien ce matériel globalement je les trouve bien construits et bien assemblés 
(et l'ipmi est sympa). Après partir sur du asus, pas sûr, ça fait trop grand 
public pour être fiable pour moi, pourquoi tu ne tentes pas un constructeur 
'legacy' type Dell ou Lenovo ? J'ai pas mal de Dell ça tient fort, pour le coup 
que des disques qui ont pétés. 

Sinon contactes-moi pour échanger.

Bonne journée,


Julien Beaucourt - CEO - Fondateur 
+33 6 61 76 66 34 - +33 1 84 19 80 94
74 rue du château, 92100 Boulogne-Billancourt

  


This message and any attachments (the « message ») is intended solely for the 
addressees and is confidential. If you receive this message in error, please 
delete it and immediately notify the sender. Any use not in accord with its 
purpose, any dissemination or disclosure, either whole or partial, is 
prohibited except formal approval. The internet can not guarantee the integrity 
of this message. Mikado Labs SAS shall (will) not therefore be liable for the 
message if modified.
Ce message et toutes les pièces jointes (ci-après le « message ») sont établis 
a l’intention exclusive de ses destinataires et sont confidentiels. Si vous 
recevez ce message par erreur, merci de le détruire et d’en avertir 
immédiatement expéditeur. Toute utilisation de ce message non conforme a sa 
destination, toute diffusion ou toute publication, totale ou partielle, est 
interdite, sauf autorisation expresse. Internet ne permettant pas d’assurer 
l'intégrité de ce message, Mikado Labs SAS décline toute responsabilité au 
titre de ce message, dans hypothèse ou il aurait été modifié




 

-Original Message-
From: frnog-requ...@frnog.org  On Behalf Of Gilles 
SAUVAIRE
Sent: lundi 22 janvier 2024 13:14
To: frnog-t...@frnog.org
Subject: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS
Importance: High

[Vous ne recevez pas souvent de courriers de gil...@sauvaire.com. Découvrez 
pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]

Bonjour,



J'utilise pas mal les serveurs 2U ou 1U de chez SuperMicro.

(Avec IPMI, double proc...)

Ces derniers temps, je ne suis pas contant de la fiabilité...



Mon fournisseur SuperMicro me propose de l'ASUS ??

Je ne savais même pas que ASUS fabriquait cela.

Exemple :  Asus RS700-E11-RS12U

Avec double alim, IPMI...



Est-ce que quelqu'un utilise ce type de serveur de marque ASUS ?

Fiabilité ? Depuis longtemps ?



Merci pour vos avis,



Gilles












---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[David Ponzone]

Il est possible d’avoir une session HTTP entièrement en UDP ou l’établissement 
initial sera de toute façon en TCP ?

David

> Le 22 janv. 2024 à 14:07, Florent Daigniere 
>  a écrit :
> 
> On Mon, 2024-01-22 at 13:48 +0100, David Ponzone wrote:
>> 
>> Mais y a-t-il encore du traffic UDP qui mérite d’être loggué ?
>> 
> 
> HTTP/3 - rfc9114
> 
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Florent Daigniere via frnog]

On Mon, 2024-01-22 at 13:48 +0100, David Ponzone wrote:
> 
> Mais y a-t-il encore du traffic UDP qui mérite d’être loggué ?
> 

HTTP/3 - rfc9114



---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS

[Julien Beaucourt]

Hello Gilles,

Pour ma part j'ai aussi eu quelques problèmes de fiabilité sur mes supermicro, 
ce sont des nœud badgés nutanix (NX), donc de grosses configurations, les 
problèmes viennent tous pour ma part des contrôleurs disques qui lâchent au 
bout de 6 ans, du coup perte du nœud et il faut remplacer la CM... Sinon j'aime 
bien ce matériel globalement je les trouve bien construits et bien assemblés 
(et l'ipmi est sympa). Après partir sur du asus, pas sûr, ça fait trop grand 
public pour être fiable pour moi, pourquoi tu ne tentes pas un constructeur 
'legacy' type Dell ou Lenovo ? J'ai pas mal de Dell ça tient fort, pour le coup 
que des disques qui ont pétés. 

Sinon contactes-moi pour échanger.

Bonne journée,


Julien Beaucourt - CEO - Fondateur 
+33 6 61 76 66 34 - +33 1 84 19 80 94
74 rue du château, 92100 Boulogne-Billancourt

  


This message and any attachments (the « message ») is intended solely for the 
addressees and is confidential. If you receive this message in error, please 
delete it and immediately notify the sender. Any use not in accord with its 
purpose, any dissemination or disclosure, either whole or partial, is 
prohibited except formal approval. The internet can not guarantee the integrity 
of this message. Mikado Labs SAS shall (will) not therefore be liable for the 
message if modified.
Ce message et toutes les pièces jointes (ci-après le « message ») sont établis 
a l’intention exclusive de ses destinataires et sont confidentiels. Si vous 
recevez ce message par erreur, merci de le détruire et d’en avertir 
immédiatement expéditeur. Toute utilisation de ce message non conforme a sa 
destination, toute diffusion ou toute publication, totale ou partielle, est 
interdite, sauf autorisation expresse. Internet ne permettant pas d’assurer 
l'intégrité de ce message, Mikado Labs SAS décline toute responsabilité au 
titre de ce message, dans hypothèse ou il aurait été modifié




 

-Original Message-
From: frnog-requ...@frnog.org  On Behalf Of Gilles 
SAUVAIRE
Sent: lundi 22 janvier 2024 13:14
To: frnog-t...@frnog.org
Subject: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS
Importance: High

[Vous ne recevez pas souvent de courriers de gil...@sauvaire.com. Découvrez 
pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]

Bonjour,



J'utilise pas mal les serveurs 2U ou 1U de chez SuperMicro.

(Avec IPMI, double proc...)

Ces derniers temps, je ne suis pas contant de la fiabilité...



Mon fournisseur SuperMicro me propose de l'ASUS ??

Je ne savais même pas que ASUS fabriquait cela.

Exemple :  Asus RS700-E11-RS12U

Avec double alim, IPMI...



Est-ce que quelqu'un utilise ce type de serveur de marque ASUS ?

Fiabilité ? Depuis longtemps ?



Merci pour vos avis,



Gilles












---
Liste de diffusion du FRnOG
http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[David Ponzone]

> Le 22 janv. 2024 à 11:56, Jérôme Berthier via frnog  a écrit 
> :
> 
> 
> Merci David pour cette remarque !
> 
> En relisant quelques docs et posts sur le forum UniFi, j'ai effectivement un 
> gros doute aussi.
> 
> L'idée du déploiement est évidemment d'avoir la traçabilité entre le client 
> (voucher hotspot) et son usage (terminal / trafic IP).
> 
> Il me faut donc la traçabilité :
> 
> - des connexions hotspot en pouvant faire le lien entre le client/voucher et 
> son terminal (idéalement sur un an).
> 
> - du trafic en lien avec le terminal (idéalement le voucher donc le client)
> 
> Pour croiser tout ça, j'ai donc besoin des logs : sessions portail 
> (client/voucher <-> MAC), MAC <-> DHCP, accounting IP (src / dst / ports...), 
> translations NAT.
> 
> Je pensais que les gateways UniFi et la fonction Hotspot gérée dans Network 
> Server permettaient d'avoir ça mais c'est franchement pas clair.
> 
> Je crois même comprendre le contraire en lisant le forum Community UniFi.
> 

Encore un fois, c’est compliqué parce qu’en France/UE, personne ne semble 
vraiment comprendre ce qu’on doit logguer vs ce qu’on a pas le droit de logguer 
à cause d’un réglementation à la con.
Ce que je sais, c’est qu'un routeur MK devant les AP, configuré pour logguer 
les TCP SYN sortants, et tu auras MAC SRC, PROTO, SRC IP, SRC PORT, DST IP, DST 
PORT, dans syslog, une ligne par connexion sortante établie.
Pour UDP, c’est plus compliqué, parce que ça va être plus verbeux. Beaucoup 
plus.
Mais y a-t-il encore du traffic UDP qui mérite d’être loggué ?

David


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS

[David Ponzone]

Non, jamais pratiqué.
Et je doute qu’il y ait des gens avec 5 ou 10 ans de RETEX.

C’est pour garder longtemps ?
Absolument besoin d’une machine récente ?

David

> Le 22 janv. 2024 à 13:13, Gilles SAUVAIRE  a écrit :
> 
> Bonjour,
> 
> 
> 
> J’utilise pas mal les serveurs 2U ou 1U de chez SuperMicro.
> 
> (Avec IPMI, double proc…)
> 
> Ces derniers temps, je ne suis pas contant de la fiabilité…
> 
> 
> 
> Mon fournisseur SuperMicro me propose de l’ASUS ??
> 
> Je ne savais même pas que ASUS fabriquait cela.
> 
> Exemple :  Asus RS700-E11-RS12U
> 
> Avec double alim, IPMI…
> 
> 
> 
> Est-ce que quelqu’un utilise ce type de serveur de marque ASUS ?
> 
> Fiabilité ? Depuis longtemps ? 
> 
> 
> 
> Merci pour vos avis, 
> 
> 
> 
> Gilles
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS

[Gilles SAUVAIRE]

Bonjour,

 

J’utilise pas mal les serveurs 2U ou 1U de chez SuperMicro.

(Avec IPMI, double proc…)

Ces derniers temps, je ne suis pas contant de la fiabilité…

 

Mon fournisseur SuperMicro me propose de l’ASUS ??

Je ne savais même pas que ASUS fabriquait cela.

Exemple :  Asus RS700-E11-RS12U

Avec double alim, IPMI…

 

Est-ce que quelqu’un utilise ce type de serveur de marque ASUS ?

Fiabilité ? Depuis longtemps ? 

 

Merci pour vos avis, 

 

Gilles

 

 

 

 

 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Pierre-Henry Muller via frnog]

Petit retour d'expérience, UI ne permet pas le niveau de détail que tu 
demandes.


Le réseau guest avec voucher ou avec portail, ne demande même pas les 
infos obligatoires que son nom / prénom / email, le portail ne peut être 
modifié sur ce point, seule les couleurs et les CGV peuvent être modifiées.


De plus même une dream machine qui fait office de firewall / routeur, 
lorsqu'on active le flux syslog vers un concentrateur, on ne reçoit pas 
le détail du traffic, assignation dhcp et autres infos intéressantes 
mais seulement les logs systèmes de la dream machine et des bornes ...


Bilan on a viré notre wifi guest

Email Signature
Le 22/01/2024 à 11:56, Jérôme Berthier via frnog a écrit :

Le 18/01/2024 à 23:01, David Ponzone a écrit :
Le 18 janv. 2024 à 22:52, Merwan Zenati  a 
écrit :


Hello

En effet les bornes sont managées avec un controller, pour du 
basique, si tu ne veux pas mettre de vrai firewall sur place, une 
cloud key fait amplement l’affaire (sinon tu peux héberger une vm 
Windows/linux avec un controller mais prix de l’instance + 
maintenance + gestion du fw si ip dynamique etc etc etc… prise de 
tête pour la taille)
Ce cloud key est manageable a distance (tu l’adopte dans 
console.ui.com si je dis pas de bêtise) donc c’est top.
Tu couple ça a un 8POE unifi (ou plus selon le besoin et le tour est 
joué)


Concernant ton wifi guest, unifi, c’est simple ! Tu setup ton lan 
guest sans « network », tu crée ton wifi dans « wifi » tu dis « 
c’est du guest » boom il isole lui même chaque périphérique connecté 
automatiquement…
Mais sauf erreur de ma part (j’ai éliminé tous les routeurs UI de la 
liste du possible il y a un moment), dans cette conf, tu n’as pas les 
logs des guests sur 12 mois.
C’est un produit US, donc ils connaissent pas trop nos petites 
contraintes UE (qui sont, il faut le dire, ubuesques).


Merci David pour cette remarque !

En relisant quelques docs et posts sur le forum UniFi, j'ai 
effectivement un gros doute aussi.


L'idée du déploiement est évidemment d'avoir la traçabilité entre le 
client (voucher hotspot) et son usage (terminal / trafic IP).


Il me faut donc la traçabilité :

- des connexions hotspot en pouvant faire le lien entre le 
client/voucher et son terminal (idéalement sur un an).


- du trafic en lien avec le terminal (idéalement le voucher donc le 
client)


Pour croiser tout ça, j'ai donc besoin des logs : sessions portail 
(client/voucher <-> MAC), MAC <-> DHCP, accounting IP (src / dst / 
ports...), translations NAT.


Je pensais que les gateways UniFi et la fonction Hotspot gérée dans 
Network Server permettaient d'avoir ça mais c'est franchement pas clair.


Je crois même comprendre le contraire en lisant le forum Community UniFi.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Jérôme Berthier via frnog]

Le 18/01/2024 à 23:01, David Ponzone a écrit :

Le 18 janv. 2024 à 22:52, Merwan Zenati  a écrit :

Hello

En effet les bornes sont managées avec un controller, pour du basique, si tu ne 
veux pas mettre de vrai firewall sur place, une cloud key fait amplement 
l’affaire (sinon tu peux héberger une vm Windows/linux avec un controller mais 
prix de l’instance + maintenance + gestion du fw si ip dynamique etc etc etc… 
prise de tête pour la taille)
Ce cloud key est manageable a distance (tu l’adopte dans console.ui.com si je 
dis pas de bêtise) donc c’est top.
Tu couple ça a un 8POE unifi (ou plus selon le besoin et le tour est joué)

Concernant ton wifi guest, unifi, c’est simple ! Tu setup ton lan guest sans « 
network », tu crée ton wifi dans « wifi » tu dis « c’est du guest » boom il 
isole lui même chaque périphérique connecté automatiquement…

Mais sauf erreur de ma part (j’ai éliminé tous les routeurs UI de la liste du 
possible il y a un moment), dans cette conf, tu n’as pas les logs des guests 
sur 12 mois.
C’est un produit US, donc ils connaissent pas trop nos petites contraintes UE 
(qui sont, il faut le dire, ubuesques).


Merci David pour cette remarque !

En relisant quelques docs et posts sur le forum UniFi, j'ai 
effectivement un gros doute aussi.


L'idée du déploiement est évidemment d'avoir la traçabilité entre le 
client (voucher hotspot) et son usage (terminal / trafic IP).


Il me faut donc la traçabilité :

- des connexions hotspot en pouvant faire le lien entre le 
client/voucher et son terminal (idéalement sur un an).


- du trafic en lien avec le terminal (idéalement le voucher donc le client)

Pour croiser tout ça, j'ai donc besoin des logs : sessions portail 
(client/voucher <-> MAC), MAC <-> DHCP, accounting IP (src / dst / 
ports...), translations NAT.


Je pensais que les gateways UniFi et la fonction Hotspot gérée dans 
Network Server permettaient d'avoir ça mais c'est franchement pas clair.


Je crois même comprendre le contraire en lisant le forum Community UniFi.

--
Jérôme Berthier

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tencent sur aucun IX en France ?

[David Ponzone]

> Le 20 janv. 2024 à 19:12, Vincent Bernat  a écrit :
> 
> On 2024-01-20 16:41, David Ponzone wrote:
>> En plus, je viens de voir qu’ils s’amusent bien avec leurs annonces:
>> tous leurs biocs sont désagrégés, et annoncés à différents transits, un
>> peu comme on faisait pour optimiser le load-balancing à la fin des
>> années 90…..
> 
> On fait comment de nos jours ?

J’avais la faiblesse de penser que le ratio coût de la bande passante/besoin 
avait largement diminué.


> Le 20 janv. 2024 à 19:47, Nicolas VUILLERMET  a écrit 
> :
> 
> +1,
> 
> Sachant que pour des raisons de latences ou d’éviter de transporter du trafic 
> dans ton backbone, quand tu as vraiment un AS à travers plusieurs régions, le 
> moyen de s’en sortir est d’avoir plusieurs blocs annoncés différemment entre 
> toutes les régions.
> 
> Nous avons des caches @job chez nous qui débitent du 30G sur Marseille et le 
> double à Paris, juste à cause de notre présence sur Francis Paris, on doit 
> transporter 7G de Marseille à Paris… on imagine bien que certains réseaux 
> toujours en n*10G régionaux, ce n’est forcément tenable…
> 
> Nicolas

On a pas inventé Unicast aussi pour limiter ces problèmes ?


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tencent sur aucun IX en France ?

[Nicolas VUILLERMET]

+1,

Sachant que pour des raisons de latences ou d’éviter de transporter du trafic 
dans ton backbone, quand tu as vraiment un AS à travers plusieurs régions, le 
moyen de s’en sortir est d’avoir plusieurs blocs annoncés différemment entre 
toutes les régions.

Nous avons des caches @job chez nous qui débitent du 30G sur Marseille et le 
double à Paris, juste à cause de notre présence sur Francis Paris, on doit 
transporter 7G de Marseille à Paris… on imagine bien que certains réseaux 
toujours en n*10G régionaux, ce n’est forcément tenable…

Nicolas

> Le 20 janv. 2024 à 19:13, Vincent Bernat  a écrit :
> 
> On 2024-01-20 16:41, David Ponzone wrote:
>> En plus, je viens de voir qu’ils s’amusent bien avec leurs annonces:
>> tous leurs biocs sont désagrégés, et annoncés à différents transits, un
>> peu comme on faisait pour optimiser le load-balancing à la fin des
>> années 90…..
> 
> On fait comment de nos jours ?
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tencent sur aucun IX en France ?

[Vincent Bernat]

On 2024-01-20 16:41, David Ponzone wrote:

En plus, je viens de voir qu’ils s’amusent bien avec leurs annonces:
tous leurs biocs sont désagrégés, et annoncés à différents transits, un
peu comme on faisait pour optimiser le load-balancing à la fin des
années 90…..


On fait comment de nos jours ?


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tencent sur aucun IX en France ?

[David Ponzone]

Ah oui, c’est rigolo ça.
Peut-être parce qu’ils achètent de la capa sur un câble qui atterrit à MRS, et 
ils estiment que le peering avec les big4 à MRS est suffisant ?
En plus, je viens de voir qu’ils s’amusent bien avec leurs annonces: tous leurs 
biocs sont désagrégés, et annoncés à différents transits, un peu comme on 
faisait pour optimiser le load-balancing à la fin des années 90…..

> Le 20 janv. 2024 à 16:10, Hugues Voiturier  a 
> écrit :
> 
> Il me semble qu’ils sont encore sur France-IX Marseille ?
> 
> Hugues
> 
> Hugues Voiturier
> Consultant en architecture réseau
> AS2027
> 
>> On Jan 20, 2024, at 16:01, David Ponzone  wrote:
>> 
>> Je remarque que Tencent n’est sur plus aucun IX en France.
>> 
>> Ils ont confirmé leur retrait de France-IX il y a 2 semaines:
>> 
>> -
>> The service listed below has been terminated at Paris since January 4 2024 .
>> 
>> Member: Tencent
>>  - AS number: AS132203
>>  - IPv4 address: 37.49.238.19/22
>>  - IPv6 address: 2001:7f8:54::2:19/64 
>> ——
>> 
>> Quelqu’un a une idée de la raison de ce retrait ?
>> Ils ont bougé le contenu sur un autre AS du groupe, ou c’est le gouvernement 
>> chinois qui les force à dégonfler ?
>> 
>> David
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Tencent sur aucun IX en France ?

[Hugues Voiturier]

Il me semble qu’ils sont encore sur France-IX Marseille ?

Hugues

Hugues Voiturier
Consultant en architecture réseau
AS2027

> On Jan 20, 2024, at 16:01, David Ponzone  wrote:
> 
> Je remarque que Tencent n’est sur plus aucun IX en France.
> 
> Ils ont confirmé leur retrait de France-IX il y a 2 semaines:
> 
> -
> The service listed below has been terminated at Paris since January 4 2024 .
> 
> Member: Tencent
>  - AS number: AS132203
>  - IPv4 address: 37.49.238.19/22
>  - IPv6 address: 2001:7f8:54::2:19/64 
> ——
> 
> Quelqu’un a une idée de la raison de ce retrait ?
> Ils ont bougé le contenu sur un autre AS du groupe, ou c’est le gouvernement 
> chinois qui les force à dégonfler ?
> 
> David
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [TECH] Tencent sur aucun IX en France ?

[David Ponzone]

Je remarque que Tencent n’est sur plus aucun IX en France.

Ils ont confirmé leur retrait de France-IX il y a 2 semaines:

-
The service listed below has been terminated at Paris since January 4 2024 .

Member: Tencent
  - AS number: AS132203
  - IPv4 address: 37.49.238.19/22
  - IPv6 address: 2001:7f8:54::2:19/64 
——

Quelqu’un a une idée de la raison de ce retrait ?
Ils ont bougé le contenu sur un autre AS du groupe, ou c’est le gouvernement 
chinois qui les force à dégonfler ?

David


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[David Ponzone]

> Le 18 janv. 2024 à 22:52, Merwan Zenati  a écrit :
> 
> Hello 
> 
> En effet les bornes sont managées avec un controller, pour du basique, si tu 
> ne veux pas mettre de vrai firewall sur place, une cloud key fait amplement 
> l’affaire (sinon tu peux héberger une vm Windows/linux avec un controller 
> mais prix de l’instance + maintenance + gestion du fw si ip dynamique etc etc 
> etc… prise de tête pour la taille) 
> Ce cloud key est manageable a distance (tu l’adopte dans console.ui.com si je 
> dis pas de bêtise) donc c’est top. 
> Tu couple ça a un 8POE unifi (ou plus selon le besoin et le tour est joué) 
> 
> Concernant ton wifi guest, unifi, c’est simple ! Tu setup ton lan guest sans 
> « network », tu crée ton wifi dans « wifi » tu dis « c’est du guest » boom il 
> isole lui même chaque périphérique connecté automatiquement… 

Mais sauf erreur de ma part (j’ai éliminé tous les routeurs UI de la liste du 
possible il y a un moment), dans cette conf, tu n’as pas les logs des guests 
sur 12 mois.
C’est un produit US, donc ils connaissent pas trop nos petites contraintes UE 
(qui sont, il faut le dire, ubuesques).

David



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE

[Merwan Zenati]

Hello 

En effet les bornes sont managées avec un controller, pour du basique, si tu ne 
veux pas mettre de vrai firewall sur place, une cloud key fait amplement 
l’affaire (sinon tu peux héberger une vm Windows/linux avec un controller mais 
prix de l’instance + maintenance + gestion du fw si ip dynamique etc etc etc… 
prise de tête pour la taille) 
Ce cloud key est manageable a distance (tu l’adopte dans console.ui.com si je 
dis pas de bêtise) donc c’est top. 
Tu couple ça a un 8POE unifi (ou plus selon le besoin et le tour est joué) 

Concernant ton wifi guest, unifi, c’est simple ! Tu setup ton lan guest sans « 
network », tu crée ton wifi dans « wifi » tu dis « c’est du guest » boom il 
isole lui même chaque périphérique connecté automatiquement… 

Pour les bornes, selon la superficie à couvrir les lite peuvent être… lite.. à 
voir le signal que tu as ainsi que l’âge des AP, certains sont plus maintenues 

N’hésite pas à me dm si t’as besoin d’aide à la conf

Merwan 

> On 13 Jan 2024, at 4:33 PM, Jérôme Berthier via frnog  wrote:
> 
> Salut la liste,
> 
> Je file un coup de main pour une installation Wifi d'un petit établissement 
> qui a des chambres d'hôtes.
> 
> C'est un rachat. Le proprio précédent a laissé du matos à installer : cinq 
> APs UniFi UAP-AC-LITE et un switch POE Netgear non manageable (champagne !).
> 
> Je ne connais pas les solutions Unifi. Après un peu de lecture, si je pige 
> bien :
> 
> 1) ce sont des AP légères donc faut un contrôleur à part (même s'il 
> semblerait possible de les paramétrer unitairement)
> 
> 2) il faut donc l'application UniFi Network Server
> 
> 4) soit on héberge ce service, soit on le consomme chez UI
> 
> 5) y a des gateway qui intègrent UniFi Console qui permet d'instancier UniFi 
> Network Server ou de joindre le cloud UI
> 
> 
> Comme le tenancier n'est pas vraiment informaticien, je vais plutôt lui 
> conseiller des éléments packagés qui "juste marchent".
> 
> Du coup, en regardant les boîtiers type gateway, pour pas trop cher, j'ai 
> l'impression qu'il y aurait :
> 
> - le boîtier CloudKey+ UCK-G2-PLUS (console OnPrem)
> 
> - le boîtier UniFi Express UX (console Cloud UI) mais limité à quatre devices 
> pilotés
> 
> - le boîtier Dream Router UDR (40W) (console Cloud UI)
> 
> Est-ce bien ça ?
> 
> 
> J'ai démarré une instance UniFi Network Server pour voir à quoi ça ressemble.
> 
> Je vois qu'on peut demander une fonction portail captif. Par contre, après 
> l'avoir activé, je ne vois aucun menu de gestion des comptes guest. Ce n'est 
> pas proposé ??
> 
> 
> Je vais aussi tenter de lui faire changer son parpaing POE pour avoir une 
> gestion de vlan (histoire de séparer l'adressage des APs, le guest et 
> surement un SSID privé). Une idée du modèle de switch UniFi (10 ports utiles) 
> ?
> 
> 
> Côté docs, j'ai du mal à trouver des réponses à mes questions...
> 
> Si une bonne âme veut bien m'aiguiller. 🙂
> 
> 
> Merci d'avance
> 
> Bon week-end
> 
> -- 
> Jérôme Berthier
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Pb d'upload entre AS288 vers OVH via GTT et Cogent

[Clement Cavadore]

On Wed, 2024-01-17 at 14:54 +0100, Jean-Francois Maeyhieux wrote:
> PS: Je n'avais pas cette vision du transit (graphe que tu as
> communiqué), quel outil as tu utilisé ?

Ce sont les sites de tools bgp:

https://bgp.tools/as/288#connectivity

https://bgp.he.net/AS288#_graph4


Ils font des graphes en fonction de sources qu'ils observent. Ce n'est
jamais totalement exact, car parfois les AS font routage différent en
fonction des préfixes source, mais au moins, ca donne une idée :)

Quand il y a pas mal d'anycast et du routage différents depuis divers
ilots, ca peut donner des trucs vraiment amusant:
https://bgp.he.net/AS13335#_graph6

Clément


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] LACP et EVPN

[Étienne Wan via frnog]

Bonjour à tous,

Je bump le sujet car j'expérimente aussi dans cette direction et avec la 
même base qu'au début du thread : deux Arista en PE, de l'EVPN 
Ethernet-Segment, et des Port-Channel dans lesquels sont fixés les LACP 
system-id.


Jusque-là, tout va bien... sauf avec certains CPE en face : après 
expérimentation, j'ai des différences de comportement entre Mikrotik et 
Cisco Nexus (et donc sûrement d'autres équipements, mais ce sont les 
seuls que j'aie sous la main pour l'instant).


Sur les Nexus, un des deux ports du LACP tombe en état suspended et en 
creusant avec les commandes `show lacp ...`, le Partner Operational Key 
du deuxième lien à bundler est différent du lien déjà dans le bundle, et 
donc le Nexus considère ça comme une erreur pour le port-channel 
connecté à deux partenaires distincts.


Sur Mikrotik, j'observe aussi les Partner Operational Key différentes 
mais là tout va bien : LACP In_Sync, états Collecting+Distributing, pour 
les deux liens côté Arista et Mikrotik.


Par observation sur les PE, je confirme justement que les deux Arista 
ont bien des Actor Operational Key différentes, même en utilisant le 
même numéro de Port-Channel.



Et c'est donc de ces observations et d'un manque de doc sur cette notion 
d'OperKey que je me pose les questions : qui a tort ? qui a raison ?


Les Mikrotik sont-ils laxistes en ne vérifiant pas le Partner 
Operational Key, et les Nexus respectent le standard ? Ou au contraire, 
les Nexus trop stricts et les Mikrotik conformes à ne vérifier que le 
LACP system-id ?


D'ailleurs, quel standard ? Certains CPE réfèrent encore au 802.3ad, 
est-ce qu'il y a eu des modifications avec le 802.1ax ? Si vous avez des 
pointeurs vers des documents de l'IEEE, je suis preneur car ça reste 
plus difficile d'accès que les RFC.


Sinon côté Arista, est-ce qu'on peut mettre en cause la plateforme sur 
la dérivation de l'OperKey qui donne des résultats différents ? Car dans 
mon cas, les OperKey sont juste décalés de 1. Et manifestement, je n'ai 
pas de commande de config sur Arista pour fixer l'OperKey, mais est-ce 
que d'autres constructeurs laissent cette liberté là ? En soit, si c'est 
juste une valeur qui peut être bidouillée pour des besoins internes de 
MLAG/vPC/..., ça ne semble pas infaisable de pouvoir le faire hors des 
implémentations propriétaires des constructeurs.


Curieux de vous lire notamment s'il y a des barbus sur le LACP dans la 
salle :)


Étienne


Le 20/07/2023 à 22:53, Olivier E a écrit :

Pas de souci, c’est interessant comme sujet et effectivement la documentation 
n’est pas prolifique.

Il y a deux relations :
  - PE et CE
  - PE et PE


Dans le cas du PE-CE je dirais que ce qui se passe c’est que les 2 PE mentent 
aux CE en se faisant passer pour un seul et meme système.
D’ou le fait de devoir configurer le meme LACP system MAC sur les deux PE.

Dans le cas du PE-PE, les PE sont bien conscient qu’ils n’ont qu’un seul port 
vers le CE.
Par contre grave a l’ethernet segment et a son mode (All Active), ils peuvent 
se parler et se dire : «  On va faire du ALL-ACTIVE, on a chacun un lien vers 
un meme Segment Ethernet. Pour le traffic Unicast et BUM qui vient du CE on 
peut tous les 2 FWD. Pour le BUM traffic qui vient du Backbonne on va regarder 
ce que dit le Carving associe a notre ESI pour savoir qui FWD. Pour le unicast 
traffic qui vient du Backbonne on peut tout les 2 le prendre car on a tous les 
deux un lien vers le CE (Aliasing).

Donc enfaite la relation PE-CE est un artifice ou on les PE font croire au CE 
que c’est un seul et meme équipement. Ca ressemble au VPC de Nexus finalement. 
Sauf que le control Plane de la gestion du LACP est gérer par EVPN pas pas un 
proto propriétaire.

Voila ce que j’en ai compris.


Olivier.




Le 20 juil. 2023 à 22:34, Lucas REYMOND  a écrit :

Merci pour la réponse.

Donc c'est bien que LACP n'a pas besoin de synchronisation entre les PEs.

J'en profite pour poser ma question car j'ai terriblement de mal à trouver
une documentation claire à ce sujet. On sort un peu de l'EVPN pour le coup.

N'y a t'il pas une notion d'élection dans le processus 802.3ad entre les
switchs pour savoir qui déclare les liens à mettre dans le LAG ou non ?

Car si je comprends bien, dans le cas où les PEs sont "masters", on a une
sorte de split brain où chaque PEs déclare ses propres liens comme actif
sans avoir aucune information sur les liens de l'autre PE. Et le CE ne
voyant qu'un seul system-id en face ne comprend même pas qu'il y a 2
systèmes en face.

Est ce que je vois juste ?

Je ne sais pas si je suis bien clair mais je fais de mon mieux ;)

Le jeu. 20 juil. 2023 à 21:52, Vincent Bernat  a écrit :


On 2023-07-20 16:12, Lucas REYMOND wrote:

Ma question est la suivante et je pense découle d'une méconnaissance du
protocole LACP, Comment les PEs peuvent monter un LACP "commun" alors
qu'ils n'échangent manifestement aucune information ?

Ils n'ont besoin de rien échanger car tu configures le system-id
manue

[FRnOG] [TECH] signalement ARCEP dysfonctionnement support FTTH

[Fabien H]

Bonjour,

cela fait plusieurs fois récemment que le support de l'opérateur OW..
n'honore pas les RDV de dépannage FTTH planifiés et cloture le ticket en
mentant sur la réalité (client non présent, non joignable sur le numéro
indiqué, ..) sans que nous puissions répondre, et donc avec responsabilité
client.

Avez vous déjà fait un signalement ARCEP, est-ce efficace ? Ou alors passer
par l'AOTA ?

Je tiens à préciser que nous n'avions pas ces problèmes de fiabilité sur
les dépannages SDSL et FTTO, qui se passaient globalement biens. Le fait
que ce soit du dépannage avec des sous traitants Grand Public sur la FTTH
ne doit surement pas aider, mais ça n'est pas mon problème, et surtout ça
ne justifie pas de mentir sur les suivis et de cloturer sans droit de
réponse.

Merci,
Fabien

---
Liste de diffusion du FRnOG
http://www.frnog.org/