RE: [FRnOG] [Tech] Optimisation bascule BGP arista

[Michel Py via frnog]

> Julien OHAYON a écrit :
> Je te rejoins Michel. Si j'ai 3 reproches à faire à Arista ce sont : 
> - La lenteur BGP

Pas d'excuse. Vu que je suis le troll institutionnel de cette liste, j'ai le 
déplaisir de constater, à mon grand regret, que faire du BGP ce n'est pas à la 
portée de tous les vendeurs. Tant que j'y suis, et malgré que j'aime bien 
Mikrotik comme vendeur, il y a tellement de gens (dont plusieurs connaissent 
BGP mieux que moi) qui m'on dit que leur code BGP c'était de la daube que 
j'essaie même pas. La même chose avec Arista. Ca me fait profondément chier, 
mais pour un routeur de coeur, je ferme ma gueule et laisse ma boite acheter la 
marque "Junisco".


> - Ne pouvoir avoir que 4000 VLAN sur une machine. Tu ne peux pas comme sur 
> IOS-XE
> ou XR par exemple avoir des sub avec un vlan déjà existant mais différent.

"que" 4000 VLAN ?

Michel.


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

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[Julien OHAYON]

Oui mais c’est le même vlan ça Clément :)

Julien OHAYON

> Le 14 avr. 2021 à 08:40, Clement Cavadore  a écrit :
> 
> Le mercredi 14 avril 2021 à 06:30 +, Julien OHAYON a écrit :
>> - Ne pouvoir avoir que 4000 VLAN sur une machine. Tu ne peux pas
>> comme sur IOS-XE ou XR par exemple avoir des sub avec un vlan déjà
>> existant mais différent.
> 
> Ah bon ?
> 
> CR01-TH2#sh run int eth 5/3.666
> interface Ethernet5/3.666
>   encapsulation dot1q vlan 666
> (...)
> CR01-TH2#sh run int eth 7/4.666
> interface Ethernet7/4.666
>   encapsulation dot1q vlan 666
> (...)
> CR01-TH2#
> 
> -- 
> Clément Cavadore
> 

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

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[Clement Cavadore]

Le mercredi 14 avril 2021 à 06:30 +, Julien OHAYON a écrit :
> - Ne pouvoir avoir que 4000 VLAN sur une machine. Tu ne peux pas
> comme sur IOS-XE ou XR par exemple avoir des sub avec un vlan déjà
> existant mais différent.

Ah bon ?

CR01-TH2#sh run int eth 5/3.666
interface Ethernet5/3.666
   encapsulation dot1q vlan 666
(...)
CR01-TH2#sh run int eth 7/4.666
interface Ethernet7/4.666
   encapsulation dot1q vlan 666
(...)
CR01-TH2#

-- 
Clément Cavadore


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

RE: [FRnOG] [Tech] Optimisation bascule BGP arista

[Julien OHAYON]

Je te rejoins Michel.

Si j'ai 3 reproches à faire à Arista ce sont :

- La lenteur BGP

- Ne pouvoir avoir que 4000 VLAN sur une machine. Tu ne peux pas comme sur 
IOS-XE ou XR par exemple avoir des sub avec un vlan déjà existant mais 
différent.

- Ne pas faire de PPPoE ou L2TP (mais ca je leur pardonne)


En gros il faut se dire qu'à la base Arista ce sont des switchs pour du DC. Ils 
n'avaient pas prévu faire des full à ce que j'ai compris donc c'est pas opti 
pour ca...


Julien


De : Michel Py 
Envoyé : mercredi 14 avril 2021 08:13:19
À : Julien OHAYON
Cc : Alexis Lameire; Gregory CAUCHIE; Laurent Laurent; Pierre LANCASTRE; David 
Ponzone; Clement Cavadore; FRnOG
Objet : RE: [FRnOG] [Tech] Optimisation bascule BGP arista

Salut Julien,

> Julien OHAYON a écrit :
> Michel, Il faut lire... Arista a un gros défaut oui c’est son temps pour 
> programmer les routes.
> Tout est en CPU est c’est long très long trop long (coucou quand tu as plus 
> de 3M de routes)

Mais c'est pas une excuse ? j'ai un full-feed sur un Cisco 3900, j'ai 100K 
préfixes sur un Cisco 1841, c'est que du CPU aussi, et en plus, c'est un peu 
mieux qu'un ZX81 mais pas de beaucoup.
Non vraiment sans déconner, j'ai un 3900 avec un full-feed et un 1841 avec le 
full CBBC, il y a des lecteurs/lectrices qui étaient encore en train de chier 
dans leurs couches quand je les ai installés, ça me fait mal de dire que c'est 
parce que c'est tout en CPU que ça prend du temps. J'essaie de pas pourrir 
Arista, mais 3M de routes, si j'avais pas mieux à faire je ferais ça sur un 
Raspberry Pi.

Il ya a des jours ou j'ai 25K préfixes BGP qui se barrent et qui reviennent 
quelques secondes après. Je sais pourquoi : code écrit avec les pieds. On vit 
dans un monde qui tourne avec du code écrit avec les pieds, dont le mien. Tant 
que ça plante pas mon Cisco 1841, si tu veux re-écrire le code pour gratos, 
t'es embauché.

> "bgp additional-paths install" c'est magique pour ne pas attendre 20 min.

Ca devrait être la config par défaut.

Michel.

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

RE: [FRnOG] [Tech] Optimisation bascule BGP arista

[Michel Py via frnog]

Salut Julien,

> Julien OHAYON a écrit :
> Michel, Il faut lire... Arista a un gros défaut oui c’est son temps pour 
> programmer les routes.
> Tout est en CPU est c’est long très long trop long (coucou quand tu as plus 
> de 3M de routes)

Mais c'est pas une excuse ? j'ai un full-feed sur un Cisco 3900, j'ai 100K 
préfixes sur un Cisco 1841, c'est que du CPU aussi, et en plus, c'est un peu 
mieux qu'un ZX81 mais pas de beaucoup.
Non vraiment sans déconner, j'ai un 3900 avec un full-feed et un 1841 avec le 
full CBBC, il y a des lecteurs/lectrices qui étaient encore en train de chier 
dans leurs couches quand je les ai installés, ça me fait mal de dire que c'est 
parce que c'est tout en CPU que ça prend du temps. J'essaie de pas pourrir 
Arista, mais 3M de routes, si j'avais pas mieux à faire je ferais ça sur un 
Raspberry Pi.

Il ya a des jours ou j'ai 25K préfixes BGP qui se barrent et qui reviennent 
quelques secondes après. Je sais pourquoi : code écrit avec les pieds. On vit 
dans un monde qui tourne avec du code écrit avec les pieds, dont le mien. Tant 
que ça plante pas mon Cisco 1841, si tu veux re-écrire le code pour gratos, 
t'es embauché.

> "bgp additional-paths install" c'est magique pour ne pas attendre 20 min.

Ca devrait être la config par défaut.

Michel.

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

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[Julien OHAYON]

Michel,

Il faut lire...
Arista a un gros défaut oui c’est son temps pour programmer les routes. Tout 
est en CPU est c’est long très long trop long (coucou quand tu as plus de 3M de 
routes)

A la place ils ont fait des mécanismes pour qu’en moins de 60ms si je ne me 
trompe pas ça bascule sur un chemin pré calculé via un autre neighbor.


 "bgp additional-paths install" c'est magique pour ne pas attendre 20 min.


Une petite doc pour optimiser le tout : https://eos.arista.com/inet-edge-config/

Julien OHAYON

Le 14 avr. 2021 à 07:39, Michel Py  a écrit 
:


Alexis Lameire a écrit :
C'est quelque chose qui est de l'ordre du protocole BGP. Au sein du même AS 
dans lequel tes routeurs
de bordures font partis, il n'y a pas de prepend de l'AS-PATH quand la route 
est apprise de l'autre
côté. Donc il cherche la route la plus courte d'un point de vue de "l'extérieur"

Je plussoie.

C'est une question qui revient régulièrement et qui, en plus, est vieille comme 
le monde. Il y a des jours ou je me demande si on devrait pas écrire un tuto, 
mais il y en déjà plein.
J'ai relu le fil, c'est quand même vague comme info de base :-(

Il y a quand même un truc qui me dérange : la bascule qui prend des minutes, ça 
veut dire que quelque part, il y a un routeur qui a pas compris que la session 
s'était barrée en cacahouète. Recalculer un full-feed, ça ne prend que quelques 
secondes, même avec un vieux bousin ou alors faut changer de crèmerie. Pendant 
quelques secondes, avec un control-plane à base de ZX81, il peut y avoir de la 
casse; mais des minutes c'est un problème de config ou de compréhension. Bon je 
connais pas Arista, mais comme tout bon routeur, ça devrait pas avoir en 
mémoire un ou plusieurs chemins de remplacement pour chaque préfixe, justement 
pour le cas ou un pair se barre en cacahouète, on n'attend pas d'apprendre la 
route de secours ?

Si tu veux jouer sur ça, J'aurais tendance à modifier le local-pref des routes 
apprises
depuis ton intersite pour les rendre moins prioritaires. Il faut l'appliquer 
dans une
route-map qui est à appliquer sur tes peer entre DC. A noter que cet attribut 
est
transitif au sein de ton AS mais n'est pas transitif à l'extérieur de celui-ci.

J'aurais pu écrire la même chose, mais comme la liste est calme ces jours-ci, 
il faudrait peut-être écouter le coté obscur de la force qui dit que prépender 
en entrée, ça marche aussi :P
A vendre : stock à peine moisi de croquettes à troll :P

Michel.


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

RE: [FRnOG] [Tech] Optimisation bascule BGP arista

[Michel Py via frnog]

> Alexis Lameire a écrit :
> C'est quelque chose qui est de l'ordre du protocole BGP. Au sein du même AS 
> dans lequel tes routeurs
> de bordures font partis, il n'y a pas de prepend de l'AS-PATH quand la route 
> est apprise de l'autre
> côté. Donc il cherche la route la plus courte d'un point de vue de 
> "l'extérieur"

Je plussoie.

C'est une question qui revient régulièrement et qui, en plus, est vieille comme 
le monde. Il y a des jours ou je me demande si on devrait pas écrire un tuto, 
mais il y en déjà plein.
J'ai relu le fil, c'est quand même vague comme info de base :-(

Il y a quand même un truc qui me dérange : la bascule qui prend des minutes, ça 
veut dire que quelque part, il y a un routeur qui a pas compris que la session 
s'était barrée en cacahouète. Recalculer un full-feed, ça ne prend que quelques 
secondes, même avec un vieux bousin ou alors faut changer de crèmerie. Pendant 
quelques secondes, avec un control-plane à base de ZX81, il peut y avoir de la 
casse; mais des minutes c'est un problème de config ou de compréhension. Bon je 
connais pas Arista, mais comme tout bon routeur, ça devrait pas avoir en 
mémoire un ou plusieurs chemins de remplacement pour chaque préfixe, justement 
pour le cas ou un pair se barre en cacahouète, on n'attend pas d'apprendre la 
route de secours ?

> Si tu veux jouer sur ça, J'aurais tendance à modifier le local-pref des 
> routes apprises
> depuis ton intersite pour les rendre moins prioritaires. Il faut l'appliquer 
> dans une
> route-map qui est à appliquer sur tes peer entre DC. A noter que cet attribut 
> est
> transitif au sein de ton AS mais n'est pas transitif à l'extérieur de 
> celui-ci.

J'aurais pu écrire la même chose, mais comme la liste est calme ces jours-ci, 
il faudrait peut-être écouter le coté obscur de la force qui dit que prépender 
en entrée, ça marche aussi :P
A vendre : stock à peine moisi de croquettes à troll :P

Michel.


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

Re: [FRnOG] [TECH] Migration d'AS à chaud

[Cedric Schwoerer]

Hello,

Bon j'ai eu pas mal de retours, où tout converge vers la création d'un
2e objet route en parallèle, avec le nouvel ASN. 

Effectivement, on m'a mis en garde sur les "mnt", surtout quand un
transfert de ressource est impliqué. On peut vite s'emmeler les
pinceaux quand on manipule des ressources de 2 organisations
différentes.

Et vu que je n'y arrivais pas, j'ai lu la doc mais mal. L'origin est
bien une clé primaire... mais le préfixe aussi. Donc il est bien
possible de créer plusieurs ASN originaires du même préfixe sur
plusieurs objets. My bad.

En tout cas, merci à tous ! Je vais pouvoir faire ça proprement sans
couper des gens, merci pour eux.

Cédric.

Le mardi 13 avril 2021 à 21:09 +0200, Spyou a écrit :
> 
> Le 13/04/2021 à 18:57, Cedric Schwoerer a écrit :
> > Bonsoir,
> > 
> > On a repris un opérateur récemment et ses ressources IP & ASN
> > publiques
> > (d'autres vont suivre). Les ressources sont en train d'être migrées
> > au
> > niveau du RIPE pour être rattaché à notre LIR principal. 
> > 
> > Dans un souci de simplification (et soulager vos routeurs), je
> > voudrais
> > éteindre le vieil AS (et le rendre au RIPE) et annoncer ces mêmes
> > IP
> > avec mon AS principal. C'est la première fois que je réalise une
> > telle
> > opération. J'ai déjà un peu regardé pour faire ça de façon douce,
> > en
> > déclarant 2 origin dans l'object "route", peut pas, en déclarant 2
> > objet route, peut pas. 
> 
> 
> Pourquoi "peut pas" ?
> 
> C'est comme ça que ça se fait, tu annonce tes deux AS comme origin
> des
> prefix au RIPE quelques jours/semaines avant ta migration, et tu
> delete
> l'ancien quelques jours/semaines après.
> 
> Peut être que tu ne peux pas pour de bête raisons de mnt: incohérent
> ou
> d'autorisations manquantes ? La première chose à faire est de
> normaliser
> tous les mnt: et mnt-*: de tes objets :)
> 
> 
> ++
> 


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

Re: [FRnOG] [TECH] Migration d'AS à chaud

[Cedric Schwoerer]

C'est ce que je fais actuellement. 

Mais le but c'est de vraiment simplifier au maximum le travail, la doc,
le réseau. 

Mais il y a une paire de Mikrotik qui tient l'ASN actuellement que je
souhaite supprimer. Lui faire rentrer du trafic pour le faire ressortir
sur l'ASN principal derrière (avec un préfixe plus spécifique), mmhhh,
voilà quoi :p 
Je pense que c'est plus propre d'annoncer le supernet par l'ASN
principal (tenu par des Cisco), et j'alloue les ranges comme je veux en
aval.

Cédric.

Le mardi 13 avril 2021 à 22:31 +0200, Clement Cavadore a écrit :
> A ta place: Je transite (exclusivement) l'AS repris, et même s'il est
> annoncé derriere ton AS, fais ce que tu veux niveau routage réel.
> 
> Pourquoi s'emmerder: Ton AS transite l'AS repris, le supernet semble
> annoncé depuis l'AS origin d'origine, mais tu le routes comme tu
> l'entends. Et derrière, tu rationnalises :)
> 
> 
> Clément


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

Re: [FRnOG] [TECH] Migration d'AS à chaud

[Clement Cavadore]

Hello,

Le mardi 13 avril 2021 à 18:57 +0200, Cedric Schwoerer a écrit :
> On a repris un opérateur récemment et ses ressources IP & ASN
> publiques (d'autres vont suivre). Les ressources sont en train d'être
> migrées au niveau du RIPE pour être rattaché à notre LIR principal. 
> 
> Dans un souci de simplification (et soulager vos routeurs), je
> voudrais éteindre le vieil AS (et le rendre au RIPE) et annoncer ces
> mêmes IP avec mon AS principal. C'est la première fois que je réalise
> une telle opération. J'ai déjà un peu regardé pour faire ça de façon
> douce, en déclarant 2 origin dans l'object "route", peut pas, en
> déclarant 2 objet route, peut pas. 
> 
> Mais ces IPs sont en production et utilisés par le grand public.
> Quoiqu'ils pourront supporter un downtime de qq heures la nuit par
> ex. 
> 
> Je cherche donc un moyen de faire ça proprement et sans lever une
> fausse alerte sur le hijack de mes propres préfixes.

A ta place: Je transite (exclusivement) l'AS repris, et même s'il est
annoncé derriere ton AS, fais ce que tu veux niveau routage réel.

Pourquoi s'emmerder: Ton AS transite l'AS repris, le supernet semble
annoncé depuis l'AS origin d'origine, mais tu le routes comme tu
l'entends. Et derrière, tu rationnalises :)


Clément



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

Re: [FRnOG] [TECH] Migration d'AS à chaud

[Alarig Le Lay]

On Tue 13 Apr 2021 18:57:27 GMT, Cedric Schwoerer wrote:
> Dans un souci de simplification (et soulager vos routeurs)

Un préfixe est un préfixe, sauf si tu peux aggréger des préfixes
ensembles (et ne plus annoncer les more-spec) ça prendra exactement la
même place en TCAM.

-- 
Alarig


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

Re: [FRnOG] [TECH] Migration d'AS à chaud

[Will van Gulik]

On Tue, Apr 13, 2021 at 09:09:33PM +0200, Spyou wrote:
> 
> Le 13/04/2021 à 18:57, Cedric Schwoerer a écrit :
> > Bonsoir,
> >
> > On a repris un opérateur récemment et ses ressources IP & ASN publiques
> > (d'autres vont suivre). Les ressources sont en train d'être migrées au
> > niveau du RIPE pour être rattaché à notre LIR principal. 
> > [...]
> > J'ai déjà un peu regardé pour faire ça de façon douce, en
> > déclarant 2 origin dans l'object "route", peut pas, en déclarant 2
> > objet route, peut pas. 
> 
> Pourquoi "peut pas" ?
> 
> C'est comme ça que ça se fait, tu annonce tes deux AS comme origin des
> prefix au RIPE quelques jours/semaines avant ta migration, et tu delete
> l'ancien quelques jours/semaines après.
> 
> Peut être que tu ne peux pas pour de bête raisons de mnt: incohérent ou
> d'autorisations manquantes ? La première chose à faire est de normaliser
> tous les mnt: et mnt-*: de tes objets :)
> 

Je confirme, on fait ça pour un de nos prefixes anycast, on a créé
plusieurs route-objects, du coup on peut annoncer ça avec l'ASN qui est
aproprié : 
https://apps.db.ripe.net/db-web-ui/query?searchtext=62.220.150.0/24&rflag=true&source=RIPE&bflag=false

Tu peux donc te simplifier la vie ;)

Will


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

Re: [FRnOG] [TECH] Migration d'AS à chaud

[thomas brenac via frnog]

+1

et mettre les deux AS (anciens et nouveaux) dans RPKI pour le meme 
subnet, histoire de.


Bien sur cela n'est possible que lorsque tous les subnets sont sous le 
meme LIR. Le 'peut pas' viens peut etre de la..


CQFD

On 13/04/2021 21:09, Spyou wrote:

Le 13/04/2021 à 18:57, Cedric Schwoerer a écrit :

Bonsoir,

On a repris un opérateur récemment et ses ressources IP & ASN publiques
(d'autres vont suivre). Les ressources sont en train d'être migrées au
niveau du RIPE pour être rattaché à notre LIR principal.

Dans un souci de simplification (et soulager vos routeurs), je voudrais
éteindre le vieil AS (et le rendre au RIPE) et annoncer ces mêmes IP
avec mon AS principal. C'est la première fois que je réalise une telle
opération. J'ai déjà un peu regardé pour faire ça de façon douce, en
déclarant 2 origin dans l'object "route", peut pas, en déclarant 2
objet route, peut pas.


Pourquoi "peut pas" ?

C'est comme ça que ça se fait, tu annonce tes deux AS comme origin des
prefix au RIPE quelques jours/semaines avant ta migration, et tu delete
l'ancien quelques jours/semaines après.

Peut être que tu ne peux pas pour de bête raisons de mnt: incohérent ou
d'autorisations manquantes ? La première chose à faire est de normaliser
tous les mnt: et mnt-*: de tes objets :)


++


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


--
Thomas BRENAC
+33686263575

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

Re: [FRnOG] [TECH] Migration d'AS à chaud

[Spyou]

Le 13/04/2021 à 18:57, Cedric Schwoerer a écrit :
> Bonsoir,
>
> On a repris un opérateur récemment et ses ressources IP & ASN publiques
> (d'autres vont suivre). Les ressources sont en train d'être migrées au
> niveau du RIPE pour être rattaché à notre LIR principal. 
>
> Dans un souci de simplification (et soulager vos routeurs), je voudrais
> éteindre le vieil AS (et le rendre au RIPE) et annoncer ces mêmes IP
> avec mon AS principal. C'est la première fois que je réalise une telle
> opération. J'ai déjà un peu regardé pour faire ça de façon douce, en
> déclarant 2 origin dans l'object "route", peut pas, en déclarant 2
> objet route, peut pas. 


Pourquoi "peut pas" ?

C'est comme ça que ça se fait, tu annonce tes deux AS comme origin des
prefix au RIPE quelques jours/semaines avant ta migration, et tu delete
l'ancien quelques jours/semaines après.

Peut être que tu ne peux pas pour de bête raisons de mnt: incohérent ou
d'autorisations manquantes ? La première chose à faire est de normaliser
tous les mnt: et mnt-*: de tes objets :)


++


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

Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Vincent Bernat]

 ❦ 13 avril 2021 18:28 +02, Will van Gulik:

> De ce que j'ai lu dans le man et en re-regardant ma conf, j'utilise le
> forwarding-agent dans ma config, et je me connecte à un host (final) via 
> un bastion. Dans ce cas, j'ai une clef pour mon bastion, et des clefs/une 
> clef pour mes
> serveurs derrière, et je ne stocke pas de clef sur le bastion, en toute 
> logique. Dans mon fichier ssh j'utilise les paramèẗres ProxyCommand et
> ForwardAgent .

Pas besoin de ForwardAgent du coup.
-- 
Don't sacrifice clarity for small gains in "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)


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

[FRnOG] [TECH] Migration d'AS à chaud

[Cedric Schwoerer]

Bonsoir,

On a repris un opérateur récemment et ses ressources IP & ASN publiques
(d'autres vont suivre). Les ressources sont en train d'être migrées au
niveau du RIPE pour être rattaché à notre LIR principal. 

Dans un souci de simplification (et soulager vos routeurs), je voudrais
éteindre le vieil AS (et le rendre au RIPE) et annoncer ces mêmes IP
avec mon AS principal. C'est la première fois que je réalise une telle
opération. J'ai déjà un peu regardé pour faire ça de façon douce, en
déclarant 2 origin dans l'object "route", peut pas, en déclarant 2
objet route, peut pas. 

Mais ces IPs sont en production et utilisés par le grand public.
Quoiqu'ils pourront supporter un downtime de qq heures la nuit par ex. 

Je cherche donc un moyen de faire ça proprement et sans lever une
fausse alerte sur le hijack de mes propres préfixes.

Du coup j'avais pensé à faire ça comment ça :
1) à minuit, je cesse d'annoncer les préfixes avec l'ancien ASN
2) je modifie l'attribut "origin" de l'objet route, sur le LIR portal
3) (j'attends ?) j'annonce les préfixes sous le nouvel ASN

Est-ce que c'est une bonne pratique ? Est-ce utile de prévenir et
d'annoncer ce changement sur les IXP et mes upstreams ?

Merci à tous !

Cédric.



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

Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Will van Gulik]

On Tue, Apr 13, 2021 at 03:24:48PM +0200, Julien Escario wrote:
> 
> Le 13/04/2021 à 13:33, Will van Gulik a écrit :
> > Question bête (encore une ;)), est-ce qu'avoir ssh 8.2 pour le support
> > u2f sur le bastion (uniquement) pourrait fonctionner si les serveurs 
> > derrnière n'ont pas encore de ssh 8.2 ? Je suis dans un cas similaire, 
> > j'aimerai faire du 2FA, probablement fido/u2f, mais je peux pas passer 
> > tout mes hosts en ssh 8.2 . (vieux cisco, mikrotik, et autre variantes
> > mignonnes) .
> >
> > [...] 
> 
> J'aurais tendance à dire que oui tant que tu ne cherches pas à faire de
> l'agent-forwarding (c'est à dire que ton client SSH sur le bastion a la
> capacité de se connecter à l'agent sur ton poste au travers de la
> session que tu as avec le bastion, c'est assez dangereux quand tu ne
> maîtrises pas le serveur intermédiaire). Note : gpg-agent ne semble pas
> supporter l'agent-forwarding (ou j'ai loupé un truc).
> 
> Dans ce cas, tu as bien du 2FA entre ton poste et le bastion mais plus
> entre le bastion et les hôtes finaux/finals.
> 
> Je n'ai jamais joué avec les bastions, préférant me concentrer sur les
> clés et le 2FA mais j'imagine que l'idée c'est que tu te connectes à une
> machine qui stocke les clés utilisées pour se connecter sur les autres
> serveurs ? (en verrouillant l'IP source de connexion à celle du bastion
> uniquement).

De ce que j'ai lu dans le man et en re-regardant ma conf, j'utilise le
forwarding-agent dans ma config, et je me connecte à un host (final) via 
un bastion. Dans ce cas, j'ai une clef pour mon bastion, et des clefs/une clef 
pour mes
serveurs derrière, et je ne stocke pas de clef sur le bastion, en toute 
logique. Dans mon fichier ssh j'utilise les paramèẗres ProxyCommand et
ForwardAgent . Je ferai le test dès que j'arrive a me fabriquer un
bastion en 8.2, et un client en 8.2 . (Ralala, encore une raison de
passer a FB13 ;) )

> 
> Ceci dit, si c'est le cas, si ton bastion se fait pourrir, l'ensemble de
> ton processus sécu est pawned non ?
> 

A moitié, parcque pas de clef sur le bastion. Mais on peut supposer que
si je me suis fait pwn le bastion, j'aurais probablement la même vuln'
sur mes hosts derrières.

> Et Mikrotik, avec leur R&D soft de bulot, ne supporte toujours pas ni
> les autorités SSH, ni les clés ECC (nist p384, ed25519). C'est moche
> mais ils l'ont promis pour Ros7 (avec l'auto-génération d'éléphants roses).
> 

Right, autant prévoir une teuf officiel dans une salle fermée la semaine
prochaine. ;)

> Julien
> 
> 




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

Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Antoine via frnog]

Le 13/04/2021 à 15:24, Julien Escario a écrit :

  Note : gpg-agent ne semble pas
supporter l'agent-forwarding (ou j'ai loupé un truc).


gpg-agent supporte l'agent-forwarding. Je l'utilise avec une clé Yubico. 
C'est assez pratique et, je pense, pas si dangereux que ça car tu dois 
valider chaque utilisation de ta clé par ssh en tapotant la Yubikey. Tu 
maitrises ainsi un petit peu l'utilisation de ta clé.


Antoine


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

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[Pierre LANCASTRE]

Hello

Je rajouterais que sur Cisco et Arista (peut être d autres) il y a l
attribut weight qui reste purement local et prévaut devant le localpref.

++

Pierre

Le mar. 13 avr. 2021 à 16:29, Alexis Lameire  a
écrit :

> Hello.
> C'est quelque chose qui est de l'ordre du protocole BGP.
>
> Au sein du même AS dans lequel tes routeurs de bordures font partis, il
> n'y a pas de prepend de l'AS-PATH quand la route est apprise de l'autre
> côté. Donc il cherche la route la plus courte d'un point de vue de
> "l'extérieur"
>
> Si tu veux jouer sur ça, J'aurais tendance à modifier le local-pref des
> routes apprises depuis ton intersite pour les rendre moins prioritaires. Il
> faut l'appliquer dans une route-map qui est à appliquer sur tes peer entre
> DC. A noter que cet attribut est transitif au sein de ton AS mais n'est pas
> transitif à l'extérieur de celui-ci.
>
> Cordialement
> Alexis Lameire
>
> Le mar. 13 avr. 2021 à 15:30, Gregory CAUCHIE  a
> écrit :
>
>> Il semble que Arista-2, quand il reçoit les routes de Arista-1, juge ces
>> routes meilleures que celles apprises en eBGP. Cela se voit au nombre de
>> routes reçues en retour par Arista-1 (i.e. quasi rien). Arista-2 juge donc
>> que pour sortir de ton AS il faut aller vers Arista-1 via le lien « iBGP »,
>> et ton temps de bascule est donc lié au fait que Arista-2 doit apprendre
>> les withdraw de Arista-1, ou que le timer de session tombe si c’est
>> arista-1 qui est HS, pour ne plus prendre en compte les routes de Arista-1
>> et alors sortir en direct via les routes restantes.
>> Aurais-tu une ingénierie de local-pref, ou autre, pour expliquer tout
>> cela ?
>>
>> Je vois les solutions suivantes à ton cas :
>> 1/ faire en sorte qu’il n’y ait pas de préférence, au niveau tie-break
>> BGP et jusqu’au niveau ebgp vs. ibgp, entre tes routeurs
>> 2/ sinon annonce ton préfixe d’interco eBGP dans un IGP, et ne met pas de
>> next-hop-self, comme ça en qqn ms après que ton lien tombe, toutes les
>> routes préférées sur arista-1 seront automatiquement invalidées
>> 3/ t’as enfin la possibilité de jouer sur le timer de withdraw, et le
>> mettre à 0 pour annoncer les pertes de routes sans attente. Ça a des
>> conséquences, et donc on évite chez les opérateurs, mais si tu ne proposes
>> pas de transit le risque est faible.
>>
>> --
>> Greg
>>
>> > Le 7 avr. 2021 à 16:32, Alexis Lameire  a
>> écrit :
>> >
>> > J'étais en train de lire le début du thread et alais proposer du BGP
>> PIC.
>> >
>> > Et que vois-je plus loin, la réponse de Julien.
>> >
>> > Je pense vraiment que c'est la bonne voie où aller. Ça permet à tes
>> > routeurs de calculer une route de backup pour chaque préfix qui sera
>> promue
>> > en cas de coupure.
>> >
>> > Cordialement
>> > Alexis Lameire
>> >
>> > Le mer. 7 avr. 2021 à 10:10, Julien OHAYON  a écrit :
>> >
>> >> Je confirme, "bgp additional-paths install" c'est magique pour ne pas
>> >> attendre 20 min.
>> >>
>> >>
>> >> Une petite doc pour optimiser le tout :
>> >> https://eos.arista.com/inet-edge-config/
>> >>
>> >>
>> >> 
>> >>
>> >> Arista EOS Central - Configurations and Optimizations for Internet Edge
>> >> Routing
>> >> eos.arista.com
>> >> ContentsIntroductionA Note on 32 vs. 64 Bit EOSArista Multi-Agent BGP
>> >> ConfigurationArista FlexRoute ConfigurationChanging ACL
>> >> ImplementationAdjusting show tech-support OutputsISP Peering
>> Configurations
>> >> and OptimizationValidating Hardware before AdvertisingEnabling Fast
>> Failure
>> >> Detection with BFDEnabling missing route-map handling (RFC 8212
>> >> behavior)Removing Private BGP ASNsEnabling BGP CommunitiesAdjusting
>> >> community processing orderAdjusting BGP Maximum-Routes ValueFiltering
>> >> Extraneous or Malicious RoutesBGP Prefix Independent
>> ConvergenceResource
>> >> Public... Continue reading →
>> >>
>> >>
>> >>
>> >> 
>> >> De : frnog-requ...@frnog.org  de la part de
>> >> Pierre LANCASTRE 
>> >> Envoyé : mercredi 7 avril 2021 09:56:01
>> >> À : Laurent Laurent
>> >> Cc : David Ponzone; Clement Cavadore; FRnOG
>> >> Objet : Re: [FRnOG] [Tech] Optimisation bascule BGP arista
>> >>
>> >> Hello
>> >>
>> >> Tu peux explorer la piste du pic-edge pour préinstaller en FIB le
>> backup
>> >> path
>> >>
>> >> router bgp 
>> >> bgp additional-paths install
>> >>
>> >> Tu devrais avoir tes routes comme suit :
>> >>
>> >> * > x.x.x.x/yy 
>> >> * b x.x.x.x/yy 
>> >>
>> >> J'ai pas encore testé avec un full feed mais en principe ça fonctionne.
>> >>
>> >> En tout cas en lab ca fait le boulot
>> >>
>> >> ++
>> >>
>> >> Pierre
>> >>
>> >>
>> >> Le mer. 7 avr. 2021 à 09:42, Laurent Laurent <
>> laurent.lecomt...@gmail.com>
>> >> a écrit :
>> >>
>> >>> Je n'ai pas encore ouvert un ticket chez Arista car on est passé par
>> un
>> >>> intégrateur et lui est au courant, ça va être la prochaine étape ;)
>> >>>
>> >>> Voici le sh ip bgp summary de l'arista 2 :

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[Alexis Lameire]

Hello.
C'est quelque chose qui est de l'ordre du protocole BGP.

Au sein du même AS dans lequel tes routeurs de bordures font partis, il n'y
a pas de prepend de l'AS-PATH quand la route est apprise de l'autre côté.
Donc il cherche la route la plus courte d'un point de vue de "l'extérieur"

Si tu veux jouer sur ça, J'aurais tendance à modifier le local-pref des
routes apprises depuis ton intersite pour les rendre moins prioritaires. Il
faut l'appliquer dans une route-map qui est à appliquer sur tes peer entre
DC. A noter que cet attribut est transitif au sein de ton AS mais n'est pas
transitif à l'extérieur de celui-ci.

Cordialement
Alexis Lameire

Le mar. 13 avr. 2021 à 15:30, Gregory CAUCHIE  a
écrit :

> Il semble que Arista-2, quand il reçoit les routes de Arista-1, juge ces
> routes meilleures que celles apprises en eBGP. Cela se voit au nombre de
> routes reçues en retour par Arista-1 (i.e. quasi rien). Arista-2 juge donc
> que pour sortir de ton AS il faut aller vers Arista-1 via le lien « iBGP »,
> et ton temps de bascule est donc lié au fait que Arista-2 doit apprendre
> les withdraw de Arista-1, ou que le timer de session tombe si c’est
> arista-1 qui est HS, pour ne plus prendre en compte les routes de Arista-1
> et alors sortir en direct via les routes restantes.
> Aurais-tu une ingénierie de local-pref, ou autre, pour expliquer tout cela
> ?
>
> Je vois les solutions suivantes à ton cas :
> 1/ faire en sorte qu’il n’y ait pas de préférence, au niveau tie-break BGP
> et jusqu’au niveau ebgp vs. ibgp, entre tes routeurs
> 2/ sinon annonce ton préfixe d’interco eBGP dans un IGP, et ne met pas de
> next-hop-self, comme ça en qqn ms après que ton lien tombe, toutes les
> routes préférées sur arista-1 seront automatiquement invalidées
> 3/ t’as enfin la possibilité de jouer sur le timer de withdraw, et le
> mettre à 0 pour annoncer les pertes de routes sans attente. Ça a des
> conséquences, et donc on évite chez les opérateurs, mais si tu ne proposes
> pas de transit le risque est faible.
>
> --
> Greg
>
> > Le 7 avr. 2021 à 16:32, Alexis Lameire  a
> écrit :
> >
> > J'étais en train de lire le début du thread et alais proposer du BGP PIC.
> >
> > Et que vois-je plus loin, la réponse de Julien.
> >
> > Je pense vraiment que c'est la bonne voie où aller. Ça permet à tes
> > routeurs de calculer une route de backup pour chaque préfix qui sera
> promue
> > en cas de coupure.
> >
> > Cordialement
> > Alexis Lameire
> >
> > Le mer. 7 avr. 2021 à 10:10, Julien OHAYON  a écrit :
> >
> >> Je confirme, "bgp additional-paths install" c'est magique pour ne pas
> >> attendre 20 min.
> >>
> >>
> >> Une petite doc pour optimiser le tout :
> >> https://eos.arista.com/inet-edge-config/
> >>
> >>
> >> 
> >>
> >> Arista EOS Central - Configurations and Optimizations for Internet Edge
> >> Routing
> >> eos.arista.com
> >> ContentsIntroductionA Note on 32 vs. 64 Bit EOSArista Multi-Agent BGP
> >> ConfigurationArista FlexRoute ConfigurationChanging ACL
> >> ImplementationAdjusting show tech-support OutputsISP Peering
> Configurations
> >> and OptimizationValidating Hardware before AdvertisingEnabling Fast
> Failure
> >> Detection with BFDEnabling missing route-map handling (RFC 8212
> >> behavior)Removing Private BGP ASNsEnabling BGP CommunitiesAdjusting
> >> community processing orderAdjusting BGP Maximum-Routes ValueFiltering
> >> Extraneous or Malicious RoutesBGP Prefix Independent ConvergenceResource
> >> Public... Continue reading →
> >>
> >>
> >>
> >> 
> >> De : frnog-requ...@frnog.org  de la part de
> >> Pierre LANCASTRE 
> >> Envoyé : mercredi 7 avril 2021 09:56:01
> >> À : Laurent Laurent
> >> Cc : David Ponzone; Clement Cavadore; FRnOG
> >> Objet : Re: [FRnOG] [Tech] Optimisation bascule BGP arista
> >>
> >> Hello
> >>
> >> Tu peux explorer la piste du pic-edge pour préinstaller en FIB le backup
> >> path
> >>
> >> router bgp 
> >> bgp additional-paths install
> >>
> >> Tu devrais avoir tes routes comme suit :
> >>
> >> * > x.x.x.x/yy 
> >> * b x.x.x.x/yy 
> >>
> >> J'ai pas encore testé avec un full feed mais en principe ça fonctionne.
> >>
> >> En tout cas en lab ca fait le boulot
> >>
> >> ++
> >>
> >> Pierre
> >>
> >>
> >> Le mer. 7 avr. 2021 à 09:42, Laurent Laurent <
> laurent.lecomt...@gmail.com>
> >> a écrit :
> >>
> >>> Je n'ai pas encore ouvert un ticket chez Arista car on est passé par un
> >>> intégrateur et lui est au courant, ça va être la prochaine étape ;)
> >>>
> >>> Voici le sh ip bgp summary de l'arista 2 :
> >>>
> >>>  Description Neighbor V  AS   MsgRcvd
> >>> MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
> >>>  Operateur 2xx.xx.xx.xx  4  x   17670891
> >>> 53466800   27d23h Estab   833592 833527
> >>>  arista-1 198.18.255.1 4  x   20127835
> >>> 365120500   27d2

Re: [FRnOG] [Tech] Optimisation bascule BGP arista

[Gregory CAUCHIE]

Il semble que Arista-2, quand il reçoit les routes de Arista-1, juge ces routes 
meilleures que celles apprises en eBGP. Cela se voit au nombre de routes reçues 
en retour par Arista-1 (i.e. quasi rien). Arista-2 juge donc que pour sortir de 
ton AS il faut aller vers Arista-1 via le lien « iBGP », et ton temps de 
bascule est donc lié au fait que Arista-2 doit apprendre les withdraw de 
Arista-1, ou que le timer de session tombe si c’est arista-1 qui est HS, pour 
ne plus prendre en compte les routes de Arista-1 et alors sortir en direct via 
les routes restantes. 
Aurais-tu une ingénierie de local-pref, ou autre, pour expliquer tout cela ?

Je vois les solutions suivantes à ton cas :
1/ faire en sorte qu’il n’y ait pas de préférence, au niveau tie-break BGP et 
jusqu’au niveau ebgp vs. ibgp, entre tes routeurs
2/ sinon annonce ton préfixe d’interco eBGP dans un IGP, et ne met pas de 
next-hop-self, comme ça en qqn ms après que ton lien tombe, toutes les routes 
préférées sur arista-1 seront automatiquement invalidées
3/ t’as enfin la possibilité de jouer sur le timer de withdraw, et le mettre à 
0 pour annoncer les pertes de routes sans attente. Ça a des conséquences, et 
donc on évite chez les opérateurs, mais si tu ne proposes pas de transit le 
risque est faible.

--
Greg

> Le 7 avr. 2021 à 16:32, Alexis Lameire  a écrit :
> 
> J'étais en train de lire le début du thread et alais proposer du BGP PIC.
> 
> Et que vois-je plus loin, la réponse de Julien.
> 
> Je pense vraiment que c'est la bonne voie où aller. Ça permet à tes
> routeurs de calculer une route de backup pour chaque préfix qui sera promue
> en cas de coupure.
> 
> Cordialement
> Alexis Lameire
> 
> Le mer. 7 avr. 2021 à 10:10, Julien OHAYON  a écrit :
> 
>> Je confirme, "bgp additional-paths install" c'est magique pour ne pas
>> attendre 20 min.
>> 
>> 
>> Une petite doc pour optimiser le tout :
>> https://eos.arista.com/inet-edge-config/
>> 
>> 
>> 
>> 
>> Arista EOS Central - Configurations and Optimizations for Internet Edge
>> Routing
>> eos.arista.com
>> ContentsIntroductionA Note on 32 vs. 64 Bit EOSArista Multi-Agent BGP
>> ConfigurationArista FlexRoute ConfigurationChanging ACL
>> ImplementationAdjusting show tech-support OutputsISP Peering Configurations
>> and OptimizationValidating Hardware before AdvertisingEnabling Fast Failure
>> Detection with BFDEnabling missing route-map handling (RFC 8212
>> behavior)Removing Private BGP ASNsEnabling BGP CommunitiesAdjusting
>> community processing orderAdjusting BGP Maximum-Routes ValueFiltering
>> Extraneous or Malicious RoutesBGP Prefix Independent ConvergenceResource
>> Public... Continue reading →
>> 
>> 
>> 
>> 
>> De : frnog-requ...@frnog.org  de la part de
>> Pierre LANCASTRE 
>> Envoyé : mercredi 7 avril 2021 09:56:01
>> À : Laurent Laurent
>> Cc : David Ponzone; Clement Cavadore; FRnOG
>> Objet : Re: [FRnOG] [Tech] Optimisation bascule BGP arista
>> 
>> Hello
>> 
>> Tu peux explorer la piste du pic-edge pour préinstaller en FIB le backup
>> path
>> 
>> router bgp 
>> bgp additional-paths install
>> 
>> Tu devrais avoir tes routes comme suit :
>> 
>> * > x.x.x.x/yy 
>> * b x.x.x.x/yy 
>> 
>> J'ai pas encore testé avec un full feed mais en principe ça fonctionne.
>> 
>> En tout cas en lab ca fait le boulot
>> 
>> ++
>> 
>> Pierre
>> 
>> 
>> Le mer. 7 avr. 2021 à 09:42, Laurent Laurent 
>> a écrit :
>> 
>>> Je n'ai pas encore ouvert un ticket chez Arista car on est passé par un
>>> intégrateur et lui est au courant, ça va être la prochaine étape ;)
>>> 
>>> Voici le sh ip bgp summary de l'arista 2 :
>>> 
>>>  Description Neighbor V  AS   MsgRcvd
>>> MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
>>>  Operateur 2xx.xx.xx.xx  4  x   17670891
>>> 53466800   27d23h Estab   833592 833527
>>>  arista-1 198.18.255.1 4  x   20127835
>>> 365120500   27d23h Estab   827988 827988
>>> 
>>> On voit que le arista 2 possède presque toutes les routes via l'ibgp.
>>> 
>>> Merci encore pour votre aide.
>>> 
>>> Le mer. 7 avr. 2021 à 09:30, David Ponzone  a
>>> écrit :
>>> 
 Tu peux envoyer le sh ip bgp sum de arista2, au cas où.
 
 Tu as ouvert un case chez Arista ? C’est peut-être un bug connu chez
>> eux.
 
 Le 7 avr. 2021 à 09:25, Laurent Laurent 
>> a
 écrit :
 
 J'ai peur aussi que ce soit le cas, mais pas forcément la partie BGP
>> mais
 plus la partie hardware.
 
  Description  Neighbor V  AS   MsgRcvd
 MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  Operateur1   xx.xx.xx.xxx4  X1586
 14998200   12:30:04 Estab   827948 827948
  Arista2  198.18.255.2   4  X3080607
 162422170027d2

Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Julien Escario]

Le 13/04/2021 à 13:33, Will van Gulik a écrit :
> Question bête (encore une ;)), est-ce qu'avoir ssh 8.2 pour le support
> u2f sur le bastion (uniquement) pourrait fonctionner si les serveurs 
> derrnière n'ont pas encore de ssh 8.2 ? Je suis dans un cas similaire, 
> j'aimerai faire du 2FA, probablement fido/u2f, mais je peux pas passer 
> tout mes hosts en ssh 8.2 . (vieux cisco, mikrotik, et autre variantes
> mignonnes) .
>
> Un avis ? (Spoiler : je ne suis pas très familier avec ssh-agent, etc) . 
>
> Will

Salut Will,

On est plus à une question bête près, hein.

J'aurais tendance à dire que oui tant que tu ne cherches pas à faire de
l'agent-forwarding (c'est à dire que ton client SSH sur le bastion a la
capacité de se connecter à l'agent sur ton poste au travers de la
session que tu as avec le bastion, c'est assez dangereux quand tu ne
maîtrises pas le serveur intermédiaire). Note : gpg-agent ne semble pas
supporter l'agent-forwarding (ou j'ai loupé un truc).

Dans ce cas, tu as bien du 2FA entre ton poste et le bastion mais plus
entre le bastion et les hôtes finaux/finals.

Je n'ai jamais joué avec les bastions, préférant me concentrer sur les
clés et le 2FA mais j'imagine que l'idée c'est que tu te connectes à une
machine qui stocke les clés utilisées pour se connecter sur les autres
serveurs ? (en verrouillant l'IP source de connexion à celle du bastion
uniquement).

Ceci dit, si c'est le cas, si ton bastion se fait pourrir, l'ensemble de
ton processus sécu est pawned non ?

Et Mikrotik, avec leur R&D soft de bulot, ne supporte toujours pas ni
les autorités SSH, ni les clés ECC (nist p384, ed25519). C'est moche
mais ils l'ont promis pour Ros7 (avec l'auto-génération d'éléphants roses).

Julien




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Will van Gulik]

On Tue, Apr 13, 2021 at 11:01:29AM +0200, Julien Escario wrote:
> 
> Le 13/04/2021 à 10:26, Mickael Hubert a écrit :
> > Bonjour à tous,
> > Actuellement pour prendre la main sur nos serveurs (SSH), nous nous
> > connectons à des accès VPN, il y a X profils (Ex: admin, développeurs, etc
> > ..) et chaque profil n'a accès qu'à ce qu'il a besoin.
> > Mais dans le cadre de notre compliance PCI-DSS, il nous manque 2 points à
> > valider, l'un d'eux est la mise en place du 2FA sur nos accès SSH
> > justement.
> > [...]
> > Peut-être du 2FA en hard (avec une clé)...
> 
> Alors, écoute, clairement, un yubikey en guise de 2FA, ca fonctionne
> vraiment très bien. Nous n'avons pas de bastion ici encore mais toutes
> les sessions SSH sont basées sur clé SSH privée exportée depuis
> l'identité GnuPG de la yubikey (gpg-agent) + certificat SSH pour éviter
> de devoir gérer une liste de clé SSH (le bastion rempli déjà ce rôle du
> coup).
> 
> Si toutes tes machines sont parfaitement à jour, tu peux aussi partir
> sur ed25519_sk. Je n'ai pas beaucoup jouer avec parce que OpenSSH 8+
> obligatoire et honnêtement, on en est pas encore là. Ca évite de se
> coller la partie GnuPG qui est assez mal documentée et même parfois
> bugguée (spoiler : ne faites pas de ed25519 avec GnuPG).
> [...]
> Julien
> 
> 

Question bête (encore une ;)), est-ce qu'avoir ssh 8.2 pour le support
u2f sur le bastion (uniquement) pourrait fonctionner si les serveurs 
derrnière n'ont pas encore de ssh 8.2 ? Je suis dans un cas similaire, 
j'aimerai faire du 2FA, probablement fido/u2f, mais je peux pas passer 
tout mes hosts en ssh 8.2 . (vieux cisco, mikrotik, et autre variantes
mignonnes) .

Un avis ? (Spoiler : je ne suis pas très familier avec ssh-agent, etc) . 

Will




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

Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Daniel Caillibaud]

Le 13/04/21 à 10:40, Remi Desgrange  a écrit :
> Ce que je ferai, c'est, connexion sur un bastion avec 2FA, lancement d'un
> tmux dans le shell (sur le bastion donc). Tu à ainsi l'enregistrement de ce
> que tu fais (compliance toussa) +  retour de la session si le SSH coupe.

Sauf que je suppose qu'il doit logguer ce qui se passe sur la destination, le 
tmux du bastion
peut faire ça ?

Dsl si c'est une question idiote, je connais pas PCI DSS et je sais pas du tout 
s'il faut
logguer uniquement l'accès (quel individu accède à une connexion user@host) ou 
s'il faut
ensuite aussi logguer tout ce qui est fait dans la session ssh (et j'avoue ne 
pas bien
comprendre comment on peut empêcher un admin avec des droits root de masquer 
ses traces,
peut-être que de logguer le fait qu'il les masque suffit, mais ça suppose un 
log distant vers
un host sur lequel il n'a pas de droits).

-- 
Daniel

Dieu lui même ne pourrait pas couler ce bateau.
Le capitaine du Titanic (1912)


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

[FRnOG] [BIZ] Cherche maintenance et license pour MX80

[Xavier Beaudouin]

Bonjour,

Pour ma boite je cherche des gens qui peuvent me faire maintenance software 
(pas hardware) d'un mx80 et me fournir une license S-MX80-SA-FP :)

Merci de me répondre en privé :)

Cordialement,
Xavier


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

Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Pascal PETIT]

Le mardi 13 avril 2021 (10:40), Remi Desgrange écrivait :
>
> Pour les clés 2FA phy les yubikey cpas mal. 
>

C'est hors sujet par rapport à la question posée mais je signale que
les clefs fido2/U2F peuvent aussi rendre plus souples l'usage des
clefs ssh.  Avec un ssh pas trop vieux supportant les types de clefs
"ecdsa-sk" et "ed25519-sk".

À la connexion, il suffit de mettre son doigt sur la clef de sécurité
pour que le ssh du poste local construise la clef privée.

Suis-je le seul à utiliser ça ?

-- 
Pascal Petit,

Les courriels professionnels que je pourrais envoyer en dehors des heures
de travail ne requièrent pas de réponse en dehors des heures de travail.


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

Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Julien Escario]

Le 13/04/2021 à 10:26, Mickael Hubert a écrit :
> Bonjour à tous,
> Actuellement pour prendre la main sur nos serveurs (SSH), nous nous
> connectons à des accès VPN, il y a X profils (Ex: admin, développeurs, etc
> ..) et chaque profil n'a accès qu'à ce qu'il a besoin.
> Mais dans le cadre de notre compliance PCI-DSS, il nous manque 2 points à
> valider, l'un d'eux est la mise en place du 2FA sur nos accès SSH
> justement.
> [...]
> Peut-être du 2FA en hard (avec une clé)...

Alors, écoute, clairement, un yubikey en guise de 2FA, ca fonctionne
vraiment très bien. Nous n'avons pas de bastion ici encore mais toutes
les sessions SSH sont basées sur clé SSH privée exportée depuis
l'identité GnuPG de la yubikey (gpg-agent) + certificat SSH pour éviter
de devoir gérer une liste de clé SSH (le bastion rempli déjà ce rôle du
coup).

Si toutes tes machines sont parfaitement à jour, tu peux aussi partir
sur ed25519_sk. Je n'ai pas beaucoup jouer avec parce que OpenSSH 8+
obligatoire et honnêtement, on en est pas encore là. Ca évite de se
coller la partie GnuPG qui est assez mal documentée et même parfois
bugguée (spoiler : ne faites pas de ed25519 avec GnuPG).

J'ai écrit un bout d'exemple de conf rapide pour le support Yubikey à
l'époque, c'est toujours en ligne :
https://gitlab.altinea.fr/altinea/install-scripts/src/branch/master/ssh/yubibug.md

Attention, je ne garantis pas que ça va rester encore des mois en ligne ça.

Julien




OpenPGP_signature
Description: OpenPGP digital signature

Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Tristan Rannou]

+1
Avec le bastion Wallix on peut proxyfier tous les flux d'admin et notamment
les flux SSH.
Si mes souvenirs sont bons, d'après la norme PCI-DSS une seule 2FA est
nécessaire. Celle-ci peut être faite au moment de l'authentification sur le
Bastion.

Une fois sur le Bastion, en fct des privilèges les users ont accès aux
différentes ressources sans 2FA.


Le mar. 13 avr. 2021 à 10:47, Alain Bieuzent  a
écrit :

> Salut Mickael,
>
> Regarde du côté de Wallix + OneLogin (
> https://www.onelogin.com/partners/technology-partners/wallix).
>
> A+
>
> Le 13/04/2021 10:28, « Mickael Hubert »  de mick...@winlux.fr> a écrit :
>
> Bonjour à tous,
> Actuellement pour prendre la main sur nos serveurs (SSH), nous nous
> connectons à des accès VPN, il y a X profils (Ex: admin, développeurs,
> etc
> ..) et chaque profil n'a accès qu'à ce qu'il a besoin.
> Mais dans le cadre de notre compliance PCI-DSS, il nous manque 2
> points à
> valider, l'un d'eux est la mise en place du 2FA sur nos accès SSH
> justement.
> Bon le truc, c'est qu'on ouvre 1001 fenêtres quand on travaille sur un
> serveur ;)
> Si je dois à chaque fois taper le 2FA ça va vite devenir chiant... sans
> parler du timeout d'inactivité de la session SSH.
>
> Auriez-vous des solutions "plus user friendly" ?
> J'avais imaginer mettre en place un bastion, mais bon ouvrir 1001
> sessions
> avec 2FA sur le bastion ou sur les serveurs en direct, ça revient au
> même
> pour moi.
> A moins qu'il existe un bastion qui te demande le 2FA à la première
> connexion, puis plus après pour les autres sessions que tu pourrais
> ouvrir
> ...
> Peut-être du 2FA en hard (avec une clé)...
>
> merci d'avance pour votre aide
> ++
>
> ---
> 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] 2FA, avec ou sans bastion ?

[olivier]

Hello Mickael,

Par le passé, j’ai mis en place cet solution https://goteleport.com/ en tant 
que Bastion SSH avec record session + 2FA Hard Yubikey.
Intégration transparente au niveau de OpenSSH tant que la config est bien faite 
et qu’un login au bastion est réaliser.

Je ne travaille plus dans la structure je ne pourrais donc pas partager de 
fichier de configuration ou autres...

#my2cents

Olivier 

April 13, 2021 10:45 AM, "Alain Bieuzent"  wrote:

> Salut Mickael,
> 
> Regarde du côté de Wallix + OneLogin
> (https://www.onelogin.com/partners/technology-partners/wallix).
> 
> A+
> 
> Le 13/04/2021 10:28, « Mickael Hubert »  mick...@winlux.fr> a
> écrit :
> 
> Bonjour à tous,
> Actuellement pour prendre la main sur nos serveurs (SSH), nous nous
> connectons à des accès VPN, il y a X profils (Ex: admin, développeurs, etc
> ..) et chaque profil n'a accès qu'à ce qu'il a besoin.
> Mais dans le cadre de notre compliance PCI-DSS, il nous manque 2 points à
> valider, l'un d'eux est la mise en place du 2FA sur nos accès SSH
> justement.
> Bon le truc, c'est qu'on ouvre 1001 fenêtres quand on travaille sur un
> serveur ;)
> Si je dois à chaque fois taper le 2FA ça va vite devenir chiant... sans
> parler du timeout d'inactivité de la session SSH.
> 
> Auriez-vous des solutions "plus user friendly" ?
> J'avais imaginer mettre en place un bastion, mais bon ouvrir 1001 sessions
> avec 2FA sur le bastion ou sur les serveurs en direct, ça revient au même
> pour moi.
> A moins qu'il existe un bastion qui te demande le 2FA à la première
> connexion, puis plus après pour les autres sessions que tu pourrais ouvrir
> ...
> Peut-être du 2FA en hard (avec une clé)...
> 
> merci d'avance pour votre aide
> ++
> 
> ---
> 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] 2FA, avec ou sans bastion ?

[Alain Bieuzent]

Salut Mickael,

Regarde du côté de Wallix + OneLogin 
(https://www.onelogin.com/partners/technology-partners/wallix).

A+

Le 13/04/2021 10:28, « Mickael Hubert »  a écrit :

Bonjour à tous,
Actuellement pour prendre la main sur nos serveurs (SSH), nous nous
connectons à des accès VPN, il y a X profils (Ex: admin, développeurs, etc
..) et chaque profil n'a accès qu'à ce qu'il a besoin.
Mais dans le cadre de notre compliance PCI-DSS, il nous manque 2 points à
valider, l'un d'eux est la mise en place du 2FA sur nos accès SSH
justement.
Bon le truc, c'est qu'on ouvre 1001 fenêtres quand on travaille sur un
serveur ;)
Si je dois à chaque fois taper le 2FA ça va vite devenir chiant... sans
parler du timeout d'inactivité de la session SSH.

Auriez-vous des solutions "plus user friendly" ?
J'avais imaginer mettre en place un bastion, mais bon ouvrir 1001 sessions
avec 2FA sur le bastion ou sur les serveurs en direct, ça revient au même
pour moi.
A moins qu'il existe un bastion qui te demande le 2FA à la première
connexion, puis plus après pour les autres sessions que tu pourrais ouvrir
...
Peut-être du 2FA en hard (avec une clé)...

merci d'avance pour votre aide
++

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



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

Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Remi Desgrange]

Je n’ai pas la solution parfaite, mais déjà dans ton .ssh/config tu peux
mettre un "SeverAliveInterval 30" pour maintenir la connexion, on peut même
baisser a 5 pour les 4G dans le train :-)

Ce que je ferai, c'est, connexion sur un bastion avec 2FA, lancement d'un
tmux dans le shell (sur le bastion donc). Tu à ainsi l'enregistrement de ce
que tu fais (compliance toussa) +  retour de la session si le SSH coupe.

Pour les clés 2FA phy les yubikey cpas mal. Sinon on a FreeOTP au taff sur
le téléphone ça fait le job.

On Tue, Apr 13, 2021 at 10:27 AM Mickael Hubert  wrote:

> Bonjour à tous,
> Actuellement pour prendre la main sur nos serveurs (SSH), nous nous
> connectons à des accès VPN, il y a X profils (Ex: admin, développeurs, etc
> ..) et chaque profil n'a accès qu'à ce qu'il a besoin.
> Mais dans le cadre de notre compliance PCI-DSS, il nous manque 2 points à
> valider, l'un d'eux est la mise en place du 2FA sur nos accès SSH
> justement.
> Bon le truc, c'est qu'on ouvre 1001 fenêtres quand on travaille sur un
> serveur ;)
> Si je dois à chaque fois taper le 2FA ça va vite devenir chiant... sans
> parler du timeout d'inactivité de la session SSH.
>
> Auriez-vous des solutions "plus user friendly" ?
> J'avais imaginer mettre en place un bastion, mais bon ouvrir 1001 sessions
> avec 2FA sur le bastion ou sur les serveurs en direct, ça revient au même
> pour moi.
> A moins qu'il existe un bastion qui te demande le 2FA à la première
> connexion, puis plus après pour les autres sessions que tu pourrais ouvrir
> ...
> Peut-être du 2FA en hard (avec une clé)...
>
> merci d'avance pour votre aide
> ++
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
Cordialement, Rémi Desgrange

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

Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Nicolas GIRARDI]

+1

Nicolas Girardi.

> Le 13 avr. 2021 à 10:34, Francois Lesueur  a 
> écrit :
> 
> Bonjour,
> 
> Peut-être "Le Bastion" de chez OVH ? https://github.com/ovh/the-bastion
> Il avait été présenté dans ce podcast :
> https://www.nolimitsecu.fr/the-bastion/
> 
> Je ne sais pas si c'est simple à déployer...
> 
> À bientôt
> François
> 
> 
>> Le 13/04/2021 à 10:26, Mickael Hubert a écrit :
>> Bonjour à tous,
>> Actuellement pour prendre la main sur nos serveurs (SSH), nous nous
>> connectons à des accès VPN, il y a X profils (Ex: admin, développeurs, etc
>> ..) et chaque profil n'a accès qu'à ce qu'il a besoin.
>> Mais dans le cadre de notre compliance PCI-DSS, il nous manque 2 points à
>> valider, l'un d'eux est la mise en place du 2FA sur nos accès SSH
>> justement.
>> Bon le truc, c'est qu'on ouvre 1001 fenêtres quand on travaille sur un
>> serveur ;)
>> Si je dois à chaque fois taper le 2FA ça va vite devenir chiant... sans
>> parler du timeout d'inactivité de la session SSH.
>> 
>> Auriez-vous des solutions "plus user friendly" ?
>> J'avais imaginer mettre en place un bastion, mais bon ouvrir 1001 sessions
>> avec 2FA sur le bastion ou sur les serveurs en direct, ça revient au même
>> pour moi.
>> A moins qu'il existe un bastion qui te demande le 2FA à la première
>> connexion, puis plus après pour les autres sessions que tu pourrais ouvrir
>> ...
>> Peut-être du 2FA en hard (avec une clé)...
>> 
>> merci d'avance pour votre aide
>> ++
>> 
>> ---
>> 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] 2FA, avec ou sans bastion ?

[Francois Lesueur]

Bonjour,

Peut-être "Le Bastion" de chez OVH ? https://github.com/ovh/the-bastion
Il avait été présenté dans ce podcast :
https://www.nolimitsecu.fr/the-bastion/

Je ne sais pas si c'est simple à déployer...

À bientôt
François


Le 13/04/2021 à 10:26, Mickael Hubert a écrit :
> Bonjour à tous,
> Actuellement pour prendre la main sur nos serveurs (SSH), nous nous
> connectons à des accès VPN, il y a X profils (Ex: admin, développeurs, etc
> ..) et chaque profil n'a accès qu'à ce qu'il a besoin.
> Mais dans le cadre de notre compliance PCI-DSS, il nous manque 2 points à
> valider, l'un d'eux est la mise en place du 2FA sur nos accès SSH
> justement.
> Bon le truc, c'est qu'on ouvre 1001 fenêtres quand on travaille sur un
> serveur ;)
> Si je dois à chaque fois taper le 2FA ça va vite devenir chiant... sans
> parler du timeout d'inactivité de la session SSH.
> 
> Auriez-vous des solutions "plus user friendly" ?
> J'avais imaginer mettre en place un bastion, mais bon ouvrir 1001 sessions
> avec 2FA sur le bastion ou sur les serveurs en direct, ça revient au même
> pour moi.
> A moins qu'il existe un bastion qui te demande le 2FA à la première
> connexion, puis plus après pour les autres sessions que tu pourrais ouvrir
> ...
> Peut-être du 2FA en hard (avec une clé)...
> 
> merci d'avance pour votre aide
> ++
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 


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

[FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Mickael Hubert]

Bonjour à tous,
Actuellement pour prendre la main sur nos serveurs (SSH), nous nous
connectons à des accès VPN, il y a X profils (Ex: admin, développeurs, etc
..) et chaque profil n'a accès qu'à ce qu'il a besoin.
Mais dans le cadre de notre compliance PCI-DSS, il nous manque 2 points à
valider, l'un d'eux est la mise en place du 2FA sur nos accès SSH
justement.
Bon le truc, c'est qu'on ouvre 1001 fenêtres quand on travaille sur un
serveur ;)
Si je dois à chaque fois taper le 2FA ça va vite devenir chiant... sans
parler du timeout d'inactivité de la session SSH.

Auriez-vous des solutions "plus user friendly" ?
J'avais imaginer mettre en place un bastion, mais bon ouvrir 1001 sessions
avec 2FA sur le bastion ou sur les serveurs en direct, ça revient au même
pour moi.
A moins qu'il existe un bastion qui te demande le 2FA à la première
connexion, puis plus après pour les autres sessions que tu pourrais ouvrir
...
Peut-être du 2FA en hard (avec une clé)...

merci d'avance pour votre aide
++

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