Re: [FRnOG] [BIZ] Contact français Akamai Peering
binRezXN2cW9i.bin Description: PGP/MIME Versions Identification encrypted.asc Description: OpenPGP encrypted message
Re: [FRnOG] [TECH] Cisco 3925 : 4 Gigas de mémoire
Salut Michel, Bonne question, et j'ai trouvé la réponse je pense : [quote]*** 2GB is the maximum IOS addressable memory but the system can support up to 4GB[/quote] ( https://www.cisco.com/c/en/us/products/collateral/routers/3900-series-integrated-services-routers-isr/data_sheet_c78_553924.html ) Je me posais la meme question pour mon 2921, mais j'avais pas essayer de lui monter la ram jusqu'à plus que 2.5G. Comme ça on a appris un truc ;) Will > On 02 May 2018, at 00:10, Michel Py > wrote: > > Bonjour à tous, > > Est-ce que quelqu'un a déjà mis 4 GO dans un 3925 ? Je viens de mettre à > jour, il voit bien 2 SIMMs de 2 GO (c'est supporté) mais IOS ne voit que 2 GO > total. > > Je suis au courant qu'il y avait une limite IOS de 2GO, mais c'est résolu : > sur un 2921 j'ai 2,5 GO (512 sur CM et 1 barrette de 2GO) et il voit bien les > 2,5 GO au complet (154-1.T1). > > Je suis au courant que FRnOG c'est pas TAC, j'ai gouglé sans succès, mais > c'est quoi la version sur le 3925 qui reconnait 4 GO ? j'ai mis 154-2.T2 et > 155-1.T pas glop. > > Merci, > Michel. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] system de ticket pour support
Je suis avec Raphael sur ce coup. RT est efficace et stable, et les dernières versions ne sont même pas trop moche. OTRS fonctionnait, mais c'était une usine à gaz, et beaucoup trop lourd de mon point de vue. Bonne chance ! Will On Thu, Jun 04, 2020 at 08:35:39PM +0200, Raphael Mazelier wrote: > Je ne sais pas. A titre personnel j'ai plutôt un souvenir positif de RT. En > revanche j'ai fait des cauchemar avec OTRS. > > > On 04/06/2020 18:08, David Ponzone wrote: > > Mais qu’a donc la Terre entière contre Request-Tracker…. > > > > > Le 4 juin 2020 à 17:59, Jean-Yves LENHOF a > > > écrit : > > > > > > Quelques outils OpenSource : > > > > > > OTRS > > > > > > Itop > > > > > > GLPI > > > > > > Après plus orienté Dev Web : > > > > > > Mantis > > > > > > Redmine > > > > > > Bugzilla > > > > > > > --- > > 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 ?
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 ?
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] Migration d'AS à chaud
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] Cisco 7600 - 3BXL - incident 12/08 à 09h50
Comme le mentionne Nicolas, monter les limites de la TCAM semble judicieux (pour ne pas dire indispensable). Pour référence, le graph de cymru montre le pic de routes. http://www.cymru.com/BGP/bgp_updates.html . On a eu le " premier " passage a 512k+ routes dans la tables v4 . "mel cef ip 700" peux-être ton ami dans ce cas précis. Pensez à faire le tour de vos 3/[BXL/CXL] ;) Will van Gulik IP-Max SA On 8/13/14 2:17 PM, Clement Cavadore wrote: > Bonjour Nicolas, > > Avec le partitionnement cam par défaut sur les 3BXL, tu es limité à 512K > routes IPv4. Avec une reconf, tu peux monter a 768k (au détriment > d'autres choses)... > > Il suffit d'un leak d'opérateur, et la global peut grossir subitement. > C'est pas safe de rester dans ce mode la, faut repartitionner (et/ou > upgrader, car les 3BXL, ce sont un peu des papy routeurs, pour une GRT > d'aujourd'hui) :-) > > Clément Cavadore > > On Wed, 2014-08-13 at 14:12 +0200, Nicolas KARP wrote: >> Bonjour, >> >> Nous avons atteint les limites en terme de routes sur nos 7600 hier matin à >> 09h50: >> >> *Aug 12 09:49:56 %CFIB-SP-3-CFIB_EXCEPTION: FIB TCAM exception for IPv4 >> unicast. Packets through some routes will be dropped.* >> *Aug 12 09:49:57 Use "mls cef maximum-routes" to modify the FIB TCAM >> partition or/and consider a hardware upgred.* >> *Aug 12 09:49:57 Examine your network and collect the necessary information >> from this setup. * >> *Aug 12 09:49:57 The only way to recover from this state is by reload the >> router.* >> >> >> Ça n'a pas duré assez longtemps pour qu'on trouve pourquoi mais en tout >> cas, nos 7600 se sont mis à faire un peu n'importe quoi pour certains >> préfixes. >> Nous avons donc appliquer la commande magique pour augmenter le nombre de >> routes et nous les avons rebooter. >> >> D'autres opérateurs/hébergeurs ont été impactés : >> http://www.zdnet.com/internet-hiccups-today-youre-not-alone-heres-why-732566/ >> >> Ce que je comprends pas, c'est qu'on était à 95% il y a 2 jours et tout >> d'un coup on atteint la limite. Vous savez ce qu'il s'est passé ? >> >> Merci d'avance. >> >> Nicolas >> >> --- >> 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] [ALERT] Problème sur la racine du DNS
Sur notre instance du L, un peu de changement. En revanche, c'était largement plus visible sur notre J. Je n'ai pas eu le détail des opérateurs pour ce cas, mais ils m'ont dit avoir filtré, sans préciser plus. Will van Gulik AS25091 > On 30 Nov 2015, at 14:47, Stephane Bortzmeyer wrote: > > On Mon, Nov 30, 2015 at 02:42:30PM +0100, > Pascal PETIT wrote > a message of 18 lines which said: > >> Quid de l'impact lié à l'utilisation d'anycast ? >> >> Les serveurs ciblés l'utilisaient-ils ? > > C'est le cas de presque tous désormais. Cela n'a pas complètement > suffi (K, bien anycasté, a pas mal souffert.) > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Vends Serveur DL380G4
Bonjour, Franco-nogers, Ceci message n'est pas directement lié a du network, mais derrière ces charmants switchs et routeurs que vous managez, certains pourraient avoir des serveurs connectés. Comme mentionné, j'ai donc des anciens serveurs fonctionnel que j'essaye de vendre : J'ai une dizaine de DL380 G4 avec disques, 1 ou 2 CPU, du 2.8 au 3.4 Ghz, de 2 à 6 Gb de Ram. J'ai aussi une paire de DL360 G4. Les disques sont en Scsi320, et je suppose qu'ils ne sont pas plus gros que 76Gb. Mon idée serait de vendre le lot en une fois, en revanche, je suis ouvert a toute suggestions. Évidement, j'essaye d’éviter de les jeter a la poubelle. Dans la mesure ou ils ont fonctionner dans un environnement propre depuis leurs début, ils pourraient encore servir. Un bon compromis si vous avez besoin d'un serveur avec des pièces en spare. Actuellement les serveurs sont localisé a Genève. Quoiqu'il en soit, contactez moi hors liste si vous avez des questions. Et désolé si je suis totalement off - topic. Will --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Wanadoo / Orange SMTP
Certain ISP Suisse nous ont déjà fait la même chose il n'y a pas si longtemps. Et vu la clientele ciblé (le end-user et son pc zombie), ils ne proposent pas de solution pour detourner le problème. On verra bien ce que ca donne, mais je reste dubitatif. Jerome Fleury wrote: Wanadoo / Orange pour notre plus grand bonheur viens de suivre Free sur le blocage du SMTP sortant mais en moins bien puisque le blocage n'est pas desactivable. Pour contourner le problème, selon Wanadoo, il faut passer en IP Fixe. Une bonne nouvelle pour la lutte contre les PC zombies. Peut être aurais je un peu moins de virus et autres publicités pour la petite pillule bleu dans ma boîte perso. Pour ca il faudrait que tous les ISP du monde s'y mettent. Autant dire que ton nombre de spams n'est pas près de diminuer ;-) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] prix de la baie
Même combat que tout le monde en gros, à ce que je vois. L'énergie coûte cher. Nous sommes dans la même situation en Suisse, ou je me retrouves contraintes énergétiques qui sont, à mon sens, ridicules, mais cependant réel en fonction de la capacité de refroidissement du lieu (et de l'énergie qui arrive sur place). Je suppose cependant (enfin, j'espère surtout) que les serveurs qu'on va voir à l'avenir auront tendance à consommer moins. C'est un peu le jeu marketing de la plupart des constructeurs actuellement, on trouve sans peine des " environement friendly servers ". Une réalité, un disque 2.5 SAS consomme moins qu'un 3.5, et un bon ptit core duo moins qu'un xeon de l'époque. Peut être que les prix vont se stabiliser pendant un moment. My 2 cents ;) Xavier Nicollet wrote: Je suis en train de faire le tour des salles d'hébergement pour avoir une idée du prix de la location de baie. Je suis assez choqué des prix annoncés actuellement: de 350 euros il y a un ou deux ans, on tourne aujourd'hui plutôt aux alentours de 900 euros/mois. Avez-vous le même retour d'expérience ? Merci, --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Contact français Akamai Peering
binRezXN2cW9i.bin Description: PGP/MIME Versions Identification encrypted.asc Description: OpenPGP encrypted message
Re: [FRnOG] [TECH] Cisco 7600 - 3BXL - incident 12/08 à 09h50
Comme le mentionne Nicolas, monter les limites de la TCAM semble judicieux (pour ne pas dire indispensable). Pour référence, le graph de cymru montre le pic de routes. http://www.cymru.com/BGP/bgp_updates.html . On a eu le " premier " passage a 512k+ routes dans la tables v4 . "mel cef ip 700" peux-être ton ami dans ce cas précis. Pensez à faire le tour de vos 3/[BXL/CXL] ;) Will van Gulik IP-Max SA On 8/13/14 2:17 PM, Clement Cavadore wrote: > Bonjour Nicolas, > > Avec le partitionnement cam par défaut sur les 3BXL, tu es limité à 512K > routes IPv4. Avec une reconf, tu peux monter a 768k (au détriment > d'autres choses)... > > Il suffit d'un leak d'opérateur, et la global peut grossir subitement. > C'est pas safe de rester dans ce mode la, faut repartitionner (et/ou > upgrader, car les 3BXL, ce sont un peu des papy routeurs, pour une GRT > d'aujourd'hui) :-) > > Clément Cavadore > > On Wed, 2014-08-13 at 14:12 +0200, Nicolas KARP wrote: >> Bonjour, >> >> Nous avons atteint les limites en terme de routes sur nos 7600 hier matin à >> 09h50: >> >> *Aug 12 09:49:56 %CFIB-SP-3-CFIB_EXCEPTION: FIB TCAM exception for IPv4 >> unicast. Packets through some routes will be dropped.* >> *Aug 12 09:49:57 Use "mls cef maximum-routes" to modify the FIB TCAM >> partition or/and consider a hardware upgred.* >> *Aug 12 09:49:57 Examine your network and collect the necessary information >> from this setup. * >> *Aug 12 09:49:57 The only way to recover from this state is by reload the >> router.* >> >> >> Ça n'a pas duré assez longtemps pour qu'on trouve pourquoi mais en tout >> cas, nos 7600 se sont mis à faire un peu n'importe quoi pour certains >> préfixes. >> Nous avons donc appliquer la commande magique pour augmenter le nombre de >> routes et nous les avons rebooter. >> >> D'autres opérateurs/hébergeurs ont été impactés : >> http://www.zdnet.com/internet-hiccups-today-youre-not-alone-heres-why-732566/ >> >> Ce que je comprends pas, c'est qu'on était à 95% il y a 2 jours et tout >> d'un coup on atteint la limite. Vous savez ce qu'il s'est passé ? >> >> Merci d'avance. >> >> Nicolas >> >> --- >> 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] [ALERT] Problème sur la racine du DNS
Sur notre instance du L, un peu de changement. En revanche, c'était largement plus visible sur notre J. Je n'ai pas eu le détail des opérateurs pour ce cas, mais ils m'ont dit avoir filtré, sans préciser plus. Will van Gulik AS25091 > On 30 Nov 2015, at 14:47, Stephane Bortzmeyer wrote: > > On Mon, Nov 30, 2015 at 02:42:30PM +0100, > Pascal PETIT wrote > a message of 18 lines which said: > >> Quid de l'impact lié à l'utilisation d'anycast ? >> >> Les serveurs ciblés l'utilisaient-ils ? > > C'est le cas de presque tous désormais. Cela n'a pas complètement > suffi (K, bien anycasté, a pas mal souffert.) > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Wanadoo / Orange SMTP
Certain ISP Suisse nous ont déjà fait la même chose il n'y a pas si longtemps. Et vu la clientele ciblé (le end-user et son pc zombie), ils ne proposent pas de solution pour detourner le problème. On verra bien ce que ca donne, mais je reste dubitatif. Jerome Fleury wrote: Wanadoo / Orange pour notre plus grand bonheur viens de suivre Free sur le blocage du SMTP sortant mais en moins bien puisque le blocage n'est pas desactivable. Pour contourner le problème, selon Wanadoo, il faut passer en IP Fixe. Une bonne nouvelle pour la lutte contre les PC zombies. Peut être aurais je un peu moins de virus et autres publicités pour la petite pillule bleu dans ma boîte perso. Pour ca il faudrait que tous les ISP du monde s'y mettent. Autant dire que ton nombre de spams n'est pas près de diminuer ;-) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] prix de la baie
Même combat que tout le monde en gros, à ce que je vois. L'énergie coûte cher. Nous sommes dans la même situation en Suisse, ou je me retrouves contraintes énergétiques qui sont, à mon sens, ridicules, mais cependant réel en fonction de la capacité de refroidissement du lieu (et de l'énergie qui arrive sur place). Je suppose cependant (enfin, j'espère surtout) que les serveurs qu'on va voir à l'avenir auront tendance à consommer moins. C'est un peu le jeu marketing de la plupart des constructeurs actuellement, on trouve sans peine des " environement friendly servers ". Une réalité, un disque 2.5 SAS consomme moins qu'un 3.5, et un bon ptit core duo moins qu'un xeon de l'époque. Peut être que les prix vont se stabiliser pendant un moment. My 2 cents ;) Xavier Nicollet wrote: Je suis en train de faire le tour des salles d'hébergement pour avoir une idée du prix de la location de baie. Je suis assez choqué des prix annoncés actuellement: de 350 euros il y a un ou deux ans, on tourne aujourd'hui plutôt aux alentours de 900 euros/mois. Avez-vous le même retour d'expérience ? Merci, --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco 3925 : 4 Gigas de mémoire
Salut Michel, Bonne question, et j'ai trouvé la réponse je pense : [quote]*** 2GB is the maximum IOS addressable memory but the system can support up to 4GB[/quote] ( https://www.cisco.com/c/en/us/products/collateral/routers/3900-series-integrated-services-routers-isr/data_sheet_c78_553924.html ) Je me posais la meme question pour mon 2921, mais j'avais pas essayer de lui monter la ram jusqu'à plus que 2.5G. Comme ça on a appris un truc ;) Will > On 02 May 2018, at 00:10, Michel Py > wrote: > > Bonjour à tous, > > Est-ce que quelqu'un a déjà mis 4 GO dans un 3925 ? Je viens de mettre à > jour, il voit bien 2 SIMMs de 2 GO (c'est supporté) mais IOS ne voit que 2 GO > total. > > Je suis au courant qu'il y avait une limite IOS de 2GO, mais c'est résolu : > sur un 2921 j'ai 2,5 GO (512 sur CM et 1 barrette de 2GO) et il voit bien les > 2,5 GO au complet (154-1.T1). > > Je suis au courant que FRnOG c'est pas TAC, j'ai gouglé sans succès, mais > c'est quoi la version sur le 3925 qui reconnait 4 GO ? j'ai mis 154-2.T2 et > 155-1.T pas glop. > > Merci, > Michel. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] system de ticket pour support
Je suis avec Raphael sur ce coup. RT est efficace et stable, et les dernières versions ne sont même pas trop moche. OTRS fonctionnait, mais c'était une usine à gaz, et beaucoup trop lourd de mon point de vue. Bonne chance ! Will On Thu, Jun 04, 2020 at 08:35:39PM +0200, Raphael Mazelier wrote: > Je ne sais pas. A titre personnel j'ai plutôt un souvenir positif de RT. En > revanche j'ai fait des cauchemar avec OTRS. > > > On 04/06/2020 18:08, David Ponzone wrote: > > Mais qu’a donc la Terre entière contre Request-Tracker…. > > > > > Le 4 juin 2020 à 17:59, Jean-Yves LENHOF a > > > écrit : > > > > > > Quelques outils OpenSource : > > > > > > OTRS > > > > > > Itop > > > > > > GLPI > > > > > > Après plus orienté Dev Web : > > > > > > Mantis > > > > > > Redmine > > > > > > Bugzilla > > > > > > > --- > > 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/
[FRnOG] Vends Serveur DL380G4
Bonjour, Franco-nogers, Ceci message n'est pas directement lié a du network, mais derrière ces charmants switchs et routeurs que vous managez, certains pourraient avoir des serveurs connectés. Comme mentionné, j'ai donc des anciens serveurs fonctionnel que j'essaye de vendre : J'ai une dizaine de DL380 G4 avec disques, 1 ou 2 CPU, du 2.8 au 3.4 Ghz, de 2 à 6 Gb de Ram. J'ai aussi une paire de DL360 G4. Les disques sont en Scsi320, et je suppose qu'ils ne sont pas plus gros que 76Gb. Mon idée serait de vendre le lot en une fois, en revanche, je suis ouvert a toute suggestions. Évidement, j'essaye d’éviter de les jeter a la poubelle. Dans la mesure ou ils ont fonctionner dans un environnement propre depuis leurs début, ils pourraient encore servir. Un bon compromis si vous avez besoin d'un serveur avec des pièces en spare. Actuellement les serveurs sont localisé a Genève. Quoiqu'il en soit, contactez moi hors liste si vous avez des questions. Et désolé si je suis totalement off - topic. Will --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?
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 ?
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] Migration d'AS à chaud
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/
