Re: [FRnOG] [TECH] Détecter les protocoles de broadcast non grata
Salut, Le 24/03/2017 à 09:20, Alarig Le Lay a écrit : DHCP, RA, CDP, ARP spoofing et autres protocoles Si c'est pour le détecter, faut se tourner vers sFlow je pense. Si c'est pour le filtrer, comme David l'a dit, tu dois pouvoir agir au niveau de tes switchs (y compris virtuels). Les échanges cdp, lldp se désactivent (bon c'était pas la question). Pour les switchs modernes, tu vas trouver plein de trucs genre : dhcp snopping, ra guard, ipv6 dhcp snooping, dynamic arc inspection... Pour les un peu moins modernes, tu dois pouvoir coller des acls en in sur les ports pour filtrer les annonces RA, réponses dhcp... Bonne journée -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Fibre FREE en zone moyennement dense
Bonjour, Le 07/04/2017 à 14:08, Buzzer a écrit : Bonjour, Je fais parti d'un service réseau d'une banque, qui a un grand nombre d'utilisateurs en travail à distance. Nous utilisons Cisco anyconnect sur des Cisco ASA en mode dtls. Nous avons constaté que nos utilisateur clients chez Free en fibre optique et en zone moyennement dense n'arrivent pas à monter le vpn. Si DTLS ne fonctionne pas, le client est sensé utiliser la session TCP443 qui est initiée au départ. Du coup, c'est bizarre qu'ils "n'arrivent pas à monter le vpn". Pour rappel en zone moyennement dense FREE utilise le partage d'ipv4 entre les utilisateurs. Le symptôme est que le vpn tente de négocié un mtu, mais la perte de paquet sur l'infrastructure empêche cette négociation d'aboutir. Un cas "similaire" semble explicitement décrit : http://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/116881-technote-anyconnect-00.html Bon courage ;-) -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Faille WPA2
Le 18/10/2017 à 13:29, David Ponzone a écrit : Pour ceux qui ont pas encore vu, grosse faille trouvée dans WPA2. Mikrotik a corrigé: https://forum.mikrotik.com/viewtopic.php?f=21&t=126695 Meraki aussi: https://meraki.cisco.com/blog/2017/10/critical-802-11r-vulnerability-disclosed-for-wireless-networks/ --- Liste de diffusion du FRnOG http://www.frnog.org/ Salut, 9 failles sur 10 sont à corriger côté client semble-t-il. ça risque laisser pas mal de monde vulnérable un bon moment... Un billet Cisco donne un peu de contexte (et de précisions sur l'impact de leur côté) : https://gblogs.cisco.com/fr/zzfeatured/wpa-wpa2-this-is-not-the-end/ A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] smtp gmail.com
Le 18/09/2018 à 12:33, Nicolas Milano a écrit : # dig mx gmail.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mx gmail.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55135 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1680 ;; QUESTION SECTION: ;gmail.com. IN MX ;; AUTHORITY SECTION: gmail.com. 84600 IN SOA dns.mengine.net. webmaster.gmail.com. [ callto:2018091701 28810 7200 | 2018091701 28810 7200 ] 86400 84600 ;; Query time: 1 msec ;; SERVER: [ callto:185.142.52.9 | 185.142.52.9 ] # [ callto:53(185.142.52.9 | 53(185.142.52.9 ] ) ;; WHEN: Tue Sep 18 12:26:18 CEST 2018 ;; MSG SIZE rcvd: 99 Salut, Bon alors là, c'est ton serveur dns le problème. Réponses normales : => dig +short SOA gmail.com ns1.google.com. dns-admin.google.com. 213412550 900 900 1800 60 => dig +short MX gmail.com 5 gmail-smtp-in.l.google.com. 30 alt3.gmail-smtp-in.l.google.com. 40 alt4.gmail-smtp-in.l.google.com. 20 alt2.gmail-smtp-in.l.google.com. 10 alt1.gmail-smtp-in.l.google.com. Tes réponses (vu que ça répond publiquement): => dig +short SOA gmail.com @185.142.52.9 dns.mengine.net. webmaster.gmail.com. 2018091701 28810 7200 86400 84600 => dig MX gmail.com @185.142.52.9 ; <<>> DiG 9.11.4-P1-RedHat-9.11.4-2.P1.fc27 <<>> MX gmail.com @185.142.52.9 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29318 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1680 ;; QUESTION SECTION: ;gmail.com. IN MX ;; AUTHORITY SECTION: gmail.com. 84600 IN SOA dns.mengine.net. webmaster.gmail.com. 2018091701 28810 7200 86400 84600 ;; Query time: 14 msec ;; SERVER: 185.142.52.9#53(185.142.52.9) ;; WHEN: mar. sept. 18 13:19:20 CEST 2018 ;; MSG SIZE rcvd: 99 Bref, ton serveur dns.mengine.net sert une version ré-écrite de la zone gmail.com de manière foireuse ... Enfin me semble-t-il A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quel HW pour tunnel IPSEC avec APNF ?
Salut,
Le 08/11/2018 à 10:24, Joel DEREFINKO a écrit :
J'ai également eu un retour de la part de l'APNF indiquant que les ASR
1001/1002 peuvent être une alternative (on en a).
Je pense que ça nécessite des ASR 1001-*X* / 1002-*X *pour du hashage
sha256*.
*
Pour un autre besoin, je me suis pris la tête à essayer de faire le plus
robuste possible entre un ISR4331 et un ASR1001 sous IOS-XE 3.16.xS.
En ikev1, j'ai pas réussi à faire mieux que :
- policy isakmp : aes256 / group 16
- transform set ESP : aes256 / sha1
Sur les plateformes ASR1001 (pas X), j'ai bien l'impression que :
- les algos DH à courbes elliptiques ne sont pas utilisables pour la
négo isakmp
- le hashage SHA256 et supérieur n'est pas utilisable pour le tunnel
Voir la note 5 là dessus :
https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/116055-technote-ios-crypto.html#anc5
Le pire est que la cli te laisse utiliser toutes les combinaisons
possibles !
Le tunnel ne monte pas et tu loggues via un debug ipsec ce type de
message :
IPSEC(ipsec_process_proposal): transform not supported by encryption
hardware:
{esp-aes esp-sha256-hmac }
ça devait être trop dur chez Cisco de traiter le cas par plateforme pour
refuser le paramétrage en cli directement
Si quelqu'un a une expérience plus heureuse, je prend ! :-)
A+
--
Jérôme BERTHIER
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] xconnect L2TPv3 et IP interface
Salut, Il faudrait qu'il se comporte comme un switch L3. Je suppose qu'une simple "interface vlan15" ne fonctionne pas ? -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [FRNOG] [MISC]Unbound et resolveur DNS à la maison
Bonjour, Le 10/03/2019 à 20:45, Carroussel Informatique a écrit : Y a t'il un intérêt pour un particulier collé derrière une MachinBox, a utiliser Unbound (ou tout autre résolveur DNS), à part pour le "sport" ? t Trois intérêts possibles : - Utiliser un resolver validant DNSSEC - Protéger son usage de statistiques commerciales ou autres - Éviter les resolvers menteurs Question subsidiaire : est ce que ce genre d'outil ne va pas mettre la bécane à genoux ? ça ne prend quasiment rien comme ressources (raspberry pi...). Bonne journée -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco vulnérabilité Thrangrycat
Le 14/05/2019 à 16:30, S Batignolles a écrit : Bonjour, Je suis à la recherche d'infos, outils, qui pourrait m'aider à deceler une eventuelle faille sur mes ASR.. Merci d'avance Sam --- Liste de diffusion du FRnOG http://www.frnog.org/ Salut Bah regardes les deux bulletins sécurité correspondants : https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190513-secureboot https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190513-webui Tu trouveras les modèles, versions IOS-XE et configurations concernés... A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] génération de licence
Le 06/06/2019 à 21:08, Ali D a écrit : Bonjour à tous, On n'arrive pas à installer les licences sur Prime 3.4 (VM Express-Plus). Le PID et SN récupéré en CLI (sh udi) et en GUI (Administration> Dashboards> System Monitoring Dashboard) correspondent bien. mais la licence est rejetée à cause du PID (message d'erreur: Wrong PID in license file). Quelqu'un a t-il rencontré le même problème? En vous remerciant d'avance pour votre aide. Cdt, Ali D --- Liste de diffusion du FRnOG http://www.frnog.org/ Salut, A tout hasard : "As Prime Infrastructure no longer supports the node-locked licensing approach, the UDI information required to generate licenses are limited to a standard syntax as shown below: * PID = PRIME-NCS-APL (For Physical Appliance) PID = PRIME-NCS-VAPL (For Virtual Appliance/Virtual Machine) * SN = ANY:ANY You must provide the subtleties in the mentioned format to generate new licenses." Ref. : https://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/infrastructure/3-4/admin/guide/bk_CiscoPrimeInfastructure_3_4_AdminGuide/bk_CiscoPrimeInfastructure_3_4_AdminGuide_chapter_01.html#con_1092492 Cdt, -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Pylône de téléphonie mobile et élagage d'arbres gênants ?
Salut, Le 13/09/2019 à 10:56, Toussaint OTTAVI a écrit : Le 13/09/2019 à 10:31, Paul Rolland (ポール・ロラン) a écrit : Je viens de trouver le document reference ci-dessous. Il ne repond pas a la totalite de tes questions, mais indique un point : "Depuis 1996 et la loi de réglementation des télécommunications, Orange ne dispose plus des prérogatives d’élagage, contrairement aux entreprises de distribution d’énergie électrique. " Il semble donc que le monde des telecoms ne dispose pas des memes droits/avantages/regles que le reseau electrique. http://www.sdehg.fr/Documentation-Orange.pdf Merci. C'est exactement ce que je recherchais. Orange n'a peut-être pas tous les droits d'Enedis en matière d'élagage "d'office", mais la commune dispose tout de même de possibilités : - La commune peut prendre un arrêté d'élagage signifié aux propriétaires concernés "afin de permettre un fonctionnement correct du réseau de communications électroniques". A l'origine, cela a été prévu pour les risques de chute sur les lignes fixes; mais tel que c'est rédigé, à priori, cela s'applique aussi à la téléphonie mobile. - La commune peut également mettre en demeure les propriétaires, et en cas d'inaction, procéder à un élagage d'office. --- Liste de diffusion du FRnOG http://www.frnog.org/ Le droit de servitude d'élagage semble avoir été rétabli en 2015 : http://www.assemblee-nationale.fr/14/ta/ta0514.asp Toutefois, ça a l'air de concerner uniquement "l’entretien des réseaux assurant des services _/fixes/_ de communications électroniques ouverts au public et de leurs abords est d’utilité publique." Pas l'impression que ça s'applique à ton cas. Bonne journée -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq
Le 13/12/2019 à 22:45, Jeremy a écrit : Sur cette liaison, la MTU doit être à 9216 octets. J'ai pu l'appliquer sur tous les switchs sauf celui de Marly qui refuse toujours d'appliquer la Qos. En conf, j'ai appliqué ces commandes : policy-map type network-qos jumbo class type network-qos class-default mtu 9216 system qos service-policy type network-qos jumbo Sans effet sur les ports. J'ai donc appliqué une autre méthode glané sur le net, qui consiste à enlever le Trunk du port, passer un "no switchport", puis un "mtu 9216" puis repasser le port en mode Trunk. Ca a fonctionné sur celui de Valenciennes qui était récalcitrant aussi. L'interface devrait me dire ça (sur le switch de Valenciennes) : Bonjour, En fait, ça dépend du modèle Nexus. Certains supportent un MTU par port et la majorité nécessite une application Network QOS (et ne change pas le MTU renvoyé par l'interface) : https://www.cisco.com/c/en/us/support/docs/switches/nexus-9000-series-switches/118994-config-nexus-00.html#anc8 Je pense que ça explique pourquoi une partie de tes switchs affiche correctement le MTU modifié. Pas de besoin de reload (heureusement). Exemple sur un 5500 en prod sous NX-OS 7.3 : sw1# sh int Eth1/1 | i MTU MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec sw1# sh queuing int Eth1/1 | i MTU q-size: 469760, q-size-40g: 0, HW MTU: 9216 (9216 configured) => le MTU défini par Network QOS est bien appliqué Bonne journée -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq
Salut, Le 19/12/2019 à 22:48, Michel Py a écrit : Le MTU renvoyé par l'interface, il est applicable dans quel cas ? Visiblement, en l'état par défaut, si tu n'appliques pas de Network QOS... En fait, je pense que ça dépend des modèles et ça se complique sur ceux qui supportent la convergence SAN. Tu peux utiliser un MTU différent par classe de service donc au final le MTU de l'interface n'a pas vraiment d'application (sauf par défaut ?). "MTU is specified per system class. The system class allows a different MTU for each class of traffic but they must be consistent on all ports across the entire switch. You cannot configure MTU on the interfaces." "The show interface command always displays 1500 as the MTU. Because the Cisco Nexus device supports different MTUs for different QoS groups, it is not possible to represent the MTU as one value on a per interface level." Exemple Nexus 5600 : https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5600/sw/qos/7x/b_5600_QoS_Config_7x/b_6k_QoS_Config_7x_chapter_0110.html Est-ce que çà ne serait pas plus glop de le supprimer au lieu de la confusion ? On est bien d'accord que ça crée une situation illisible. ça a l'air complètement dépendant du modèle. Bref, au moins pour les 3000, il semble que la valeur soit adaptée correctement sur l'interface pour les versions NX-OS récentes : "Note: When the Nexus 3000 is on code earlier than 7.0(3)I2(2a), check the MTU value with the show queueing interface ethernet x/x command. Nexus 3000 switches that run 7.0(3)I2(2a) and later show the MTU size on a per-port basis." A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ?
Le 24/09/2014 08:05, Raphael Maunier a écrit : En pratique, l’utilisation d’IPv6 reste très anecdotique en entreprise, je dirais meme quasi nul ! Disons que l'utilisation assumée reste très anecdotique. Le fait est que tous les systèmes récents ont une pile IPv6 active par défaut donc qu'il y a surement du trafic v6 sur la plupart des réseaux locaux... Par exemple, sauf erreur de ma part, tout OS Windows récent parlera à son contrôleur de domaine en v6 quitte à utiliser une encapsulation 6to4.. Bref que les entreprises en veuillent ou non, IPv6 est déjà dans les murs, il reste à le traiter convenablement.. Jérôme smime.p7s Description: Signature cryptographique S/MIME
Re: [FRnOG] [TECH] Y a-t-il une porte dérobée dans mon routeur ?
Le 05/11/2014 05:05, Michel Py a écrit : Je remarque innocemment que personne du vendeur "C" ou "J" qui pourtant comptent tous deux nombres d'auteurs prolifiques de drafts n'a eu les c... d'écrire ou de participer. Ca serait s'abaisser : tout le monde sait que leurs routeurs n'ont jamais eu de porte dérobée. Pourtant, "J" cherche partout le backdoor qu'on aurait installé à l’insu de leur plein gré : http://kb.j[..].net/InfoCenter/index?page=content&id=JSA10605&cat=SIRT_1&actp=LIST S'ils ne l'ont toujours pas trouvé, c'est qu'il ne doit pas y en avoir ;-) ... -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
Le 05/01/2015 11:38, Raphael Mazelier a écrit : Le stacking (ou virtual chassis chez Juniper) apporte : - une facilité/simplicité d'administration (une seule configuration pour X switch) - la possibilité de faire du LACP multi-switch (et donc de la redondance + scaling). - la possibilité de faire des configurations spanning tree less. Le point négatif : un SPOF applicatif. Cela arrive rarement mais cela arrive. Bonjour, Pour avoir des dizaines de stack Cisco en prod depuis des années, je confirme les points positifs mis en avant. Je n'imagine pas faire autrement . Quelques infos côté matos : - les 2960S sont limités à quatre éléments par pile mais surtout à 6 Etherchannel par stack ! Autre point, leur coût de maintenance est assez élevé (du fait d'une soudaine augmentation de tarif cette année...) - les 2960X passent à huit éléments par pile et à 24 Etherchannel par stack. Côté matos, vu un switch HS au bout de quelques mois mais ça peut arriver... La version XR propose une double alim et 48 Etherchannel par stack. - les 3750G sont ultra fiables, proposent neuf éléments par pile, 48 Etherchannel par stack mais sont en fin de vie commerciale (en théorie) : http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3750-series-switches/eos-eol-notice-c51-731425.html - les 3750X sont leurs remplaçants théoriques sous IOS-XE like. Rien à dire côté matériel mais quelques bugs relevés sur des features access avec un suivi aléatoire côté TAC... - A prix équivalent, autant regarder côté 3850 maintenant je pense car ceux-ci peuvent être acquis si besoin avec quatre SFP+ 10G par switch et proposent 128 Etherchannels par stack : http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3850-series-switches/qa_c67-722110.html Ce pointeur compare ces gammes : http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-2960-x-series-switches/white_paper_c11-728327.html Les 3750X / 3850 sont bien devant en terme de perf de la stack mais bon... Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Remplacement solution IOS SLB
Bonjour à tous, Je cherche une solution pour remplacer un service Cisco IOS SLB (test de vie + LB + injection de route). Deux raisons : 1) la feature n'est plus supportée par Cisco depuis longtemps sauf à conserver un IOS très ancien 2) les plateformes matérielles qui traitent le service sont vraiment en fin de vie et non maintenues Actuellement, nous utilisons ce service comme suit : - deux VIP sont dual homées en BGP sur deux sites distants (une VIP prioritaire / site) - sur chaque site : -> le service est testé par des probes SLB TCP -> les deux VIP sont mappées en priorité sur le serveur réel local puis en backup sur le serveur réel de l'autre site -> les deux VIP sont annoncées dans l'aire ospf du site. Ces annonces alimentent les routeurs WAN pour déclencher l'annonce eBGP. -> en cas de plantage du service, la VIP tombe, l'annonce ospf disparait, la route disparait sur les routeurs WAN et ça coupe l'annonce eBGP du site concerné. En jouant avec ip sla + nat, on arrive à approcher un fonctionnement similaire mais avec une limite côté NAT statique : impossible de mapper deux VIP (adresse globale) sur une même adresse réelle (adresse locale). Pour l'instant, on met de côté cette solution. En parallèle, on utilise du load balancing Linux LVS. Pour l'instant, on n'a pas trouvé comment attacher l'état ldirectord à un démon ospf. Ce serait pourtant peut être la piste la plus prometteuse. Au final, on a surtout besoin des fonctionnalités test de vie + injection de route. La partie LB est facultative puisque on a déjà un RR DNS. Je précise que, pour l'instant, pas de budget à engager pour cela donc on écarte les produits dédiés type F5, A10... Auriez-vous des pistes à me conseiller d'explorer ? Merci d'avance -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Remplacement solution IOS SLB
Bonjour, Merci pour ces infos utiles Je ferai un retour sur nos tests d'ici quelques temps. Cdt, Le 02/03/2015 18:35, Romain SIBILLE a écrit : Une idée me vient à l'esprit: keepalived (ou ldirectord mais je ne sais pas comment il fonctionne) pourrait placer la VIP sur une interface type "loopback", ce qui aurait pour effet d'ajouter une route dans la table de routage de ton loadbalancer (route de type "connected", sans next-hop). Ensuite, il suffirait de bien configurer les "redistribute" de ton daemon de routage, et ton LB serait vu par tes routeurs de coeur comme "next-hop" pour joindre la VIP. Du coup, le service tombe, keepalived retire la VIP de la loopback, la route "connected" disparait, et n'est donc plus annoncée par ton IGP à tes routeurs. A tester... et ne pas hésiter à me corriger si je raconte des bêtises... Cordialement, Romain Le 02/03/2015 18:16, Jérôme BERTHIER a écrit : Bonjour, Je vais creuser keepalived. Après un peu de lecture rapide, je vois effectivement qu'on peut déclencher des scripts selon les changements d'état donc influer sur un démon tiers. L'idéal serait de rendre keepalived directement acteur du routage mais ça peut faire l'affaire. Merci pour l'info Le 02/03/2015 17:45, Romain SIBILLE a écrit : Bonjour Jérôme, Je ne sais pas si ça répond exactement à ton besoin, mais keepalived permet plein de choses, comme par exemple lancer des scripts en cas de détection de changement d'état d'un service. As tu exploré cette piste en remplacement de ldirectord? Cordialement Romain Le 02/03/2015 17:18, Jérôme BERTHIER a écrit : Bonjour à tous, Je cherche une solution pour remplacer un service Cisco IOS SLB (test de vie + LB + injection de route). Deux raisons : 1) la feature n'est plus supportée par Cisco depuis longtemps sauf à conserver un IOS très ancien 2) les plateformes matérielles qui traitent le service sont vraiment en fin de vie et non maintenues Actuellement, nous utilisons ce service comme suit : - deux VIP sont dual homées en BGP sur deux sites distants (une VIP prioritaire / site) - sur chaque site : -> le service est testé par des probes SLB TCP -> les deux VIP sont mappées en priorité sur le serveur réel local puis en backup sur le serveur réel de l'autre site -> les deux VIP sont annoncées dans l'aire ospf du site. Ces annonces alimentent les routeurs WAN pour déclencher l'annonce eBGP. -> en cas de plantage du service, la VIP tombe, l'annonce ospf disparait, la route disparait sur les routeurs WAN et ça coupe l'annonce eBGP du site concerné. En jouant avec ip sla + nat, on arrive à approcher un fonctionnement similaire mais avec une limite côté NAT statique : impossible de mapper deux VIP (adresse globale) sur une même adresse réelle (adresse locale). Pour l'instant, on met de côté cette solution. En parallèle, on utilise du load balancing Linux LVS. Pour l'instant, on n'a pas trouvé comment attacher l'état ldirectord à un démon ospf. Ce serait pourtant peut être la piste la plus prometteuse. Au final, on a surtout besoin des fonctionnalités test de vie + injection de route. La partie LB est facultative puisque on a déjà un RR DNS. Je précise que, pour l'instant, pas de budget à engager pour cela donc on écarte les produits dédiés type F5, A10... Auriez-vous des pistes à me conseiller d'explorer ? Merci d'avance -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Remplacement solution IOS SLB
Le 02/03/2015 18:42, Raphael Mazelier a écrit : Le 02/03/15 17:18, Jérôme BERTHIER a écrit : Au final, on a surtout besoin des fonctionnalités test de vie + injection de route. La partie LB est facultative puisque on a déjà un RR DNS. Généralement je fais ça avec exabgp, avec un heathcheck custom. Ça ne fait pas LB, encore que tu puisse activer le mutlipath bgp sur tes routeurs (bon en revanche pas de poids). Bonjour, En combinant les annonces iBGP conditionnées aux tests de vie avec du NAT pour mapper les VIP vers le serveur réel du site, il me semble que ça répond au besoin. Je vais regarder ça. Merci pour les infos Cdt, -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] [TECH] Boitier VPN + SWITCH + FW
Bonjour, Le 24/03/2015 11:18, Sylvain Busson a écrit : La commande monitor interface Non "monitor interface" ça classifie les paquets, erreurs... "monitor traffic interface" ça capture seulement ce qui entre et sort de la RE Si tu veux capturer le transit, tout est décrit ici : http://kb.juniper.net/InfoCenter/index?page=content&id=KB15779 C'est possible mais plutôt pénible. A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] [TECH] Boitier VPN + SWITCH + FW
Bonjour, Sauf erreur, Jflow (ou IPFIX ou Netflow) ne capture pas le trafic lui même mais les attributs liés à ce trafic (IP, port, volume échangé, interfaces, AS, label MPLS...). Il me semble que l'on parlait de faire du dump de trafic de transit. Pour JFlow, ça reste un échantillonnage. Le JTAC ne conseille pas de monter au delà d'un ratio 1:100 si ce sont les SRX eux même qui collectent... Cdt, Le 09/04/2015 09:27, Frédéric Grosjean a écrit : Bonjour, je confirme qu'avec du jflow c'est possible. (Example: Configuring Packet Capture on an Interface <http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/security/software-all/monitoring-and-troubleshooting/index.html?config-pcap-chapter.html>) En plus ça permet d'avoir un historique centralisé de tous les SRXs Branch et High-End sur un le collecteur. A+ Le 24/03/2015 11:29, Jérôme BERTHIER a écrit : Bonjour, Le 24/03/2015 11:18, Sylvain Busson a écrit : La commande monitor interface Non "monitor interface" ça classifie les paquets, erreurs... "monitor traffic interface" ça capture seulement ce qui entre et sort de la RE Si tu veux capturer le transit, tout est décrit ici : http://kb.juniper.net/InfoCenter/index?page=content&id=KB15779 C'est possible mais plutôt pénible. A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] SSH public key auth sur Cat3750G
Le 16/04/2015 18:22, David Ponzone a écrit : Bonsoir, J’ai l’impression qu’en IOS 12.2(55)SE1 (le plus récent à priori), un Cat3750G est pas capable d’authentifier une connexion au CLI sur public key (et donc sans mot de passe). Je me bats depuis un moment avec, et je ne crois pas avoir raté quelque chose. Si qqun peut confirmer, je me sentirai moins con (ou un peu plus), et j’arrêterai de perdre du temps :) Merci David --- Liste de diffusion du FRnOG http://www.frnog.org/ Bonsoir, C'est apparu en IOS 15.0 seulement : http://blog.ipspace.net/2009/10/ssh-rsa-authentication-works-in-ios.html Pas possible sur les 3750G :-\ Cdt, -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Fwd: [FRnOG] [JOBS] Coupure de connexion SSH
de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Des idées pour ce genre de problème s'il vous plait?? Merci d'avance pour votre aide Cordialement, --- 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/ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées
Bonjour, Le 27/06/2015 18:51, Frederic Dhieux a écrit : Pour moi la démarche c'est d'abord de configurer les briques en IPv4 ET en IPv6 une par une et de pouvoir un jour se dire "tiens la chaine est complète, on peut utiliser le service en IPv6 quand on est en IPv6 sur un autre end point" +1 Jeune et con depuis un paquet d'années =) En tout cas pas blasé c'est sûr. Plus concrètement, ça coûte tant que ça de configurer les 2 stacks sur un équipement quand on l'installe de nos jours ? Je ne crois pas non plus. Toutes les fonctionnalités de routage / filtrage sont disponibles pour les deux piles donc, si besoin, à part avoir à gérer un nouvel IGP (OSPFv3, RIPNG...) pour traiter IPv6, je ne vois pas la différence. Côté serveur, j'ai l'impression que l'effort est même carrément l'inverse. Tous les OS sont de base paramétrés en double pile. Si on ne veut pas faire d'IPv6 du tout (même en l'absence de service d'adressage global), il faut y travailler pour déconfigurer l'affaire. Quittes à y passer du temps (même faible) autant le faire pour déployer IPv6, non ? Côté postes client, le plus gênant pour généraliser une connectivité IPv6 reste à mon sens les contraintes de traçabilité d'allocation des adresses. Comme évoqué dans la discussion, l'utilisation du DUID et sa gestion plus ou moins rigoureuse rend difficile l'établissement d'une correspondance statique entre machine et IPv6 globale à allouer par DHCPv6. Bref, j'ai quand même l'impression que ça avance doucement et surement mais bon, comme me dit un jour, un DSI auquel je parlais déploiement IPv6 : "bah IPv6 depuis le temps qu'on en parle, si ça servait à quelque chose, ça se saurait !" Ceci explique cela ? A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées
Le 29/06/2015 11:26, Phil Regnauld a écrit : >Et quand tu utilises IS-IS même pas:) Quoi un truc même pas IP du tout :-) OSPFv3 fait v4 maintenant (j'adore expliquer ça aux nouveaux: pour v6, tu installes v3 qui fait v4). Pour l'anecdote, j'ai bien tenté de remplacer IPv4/OSPFv2 par IPv6/OSPFv3 (incluant address family IPv4) mais un vilain bug Cisco de redistribution BGP->OSPFv3 m'a coupé dans mon élan : https://tools.cisco.com/bugsearch/bug/CSCue82043 D'ailleurs, je vois qu'on est nombreux à avoir remonté le problème seulement considéré comme "Enhancement"... :-\ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco Nexus & Leap second
Bonjour, Le 30/06/2015 14:43, Cédric Paillet a écrit : Salut, Joli petit bug sympa sur nexus N5K https://tools.cisco.com/quickview/bug/CSCub38654 vos nexus risquent tout simplement de s’arrêter de ce que j'ai compris , ça risque planter le management "uniquement" D'autres avis dans ce sens ? dans la journée... et il faut un power off pour les relancer... en comptant sur le vpc hein :-\ un "no ntp server " corrige le problème. Selon le bug case, uniquement s'il a été fait deux jours avant donc au plus tard dimanche 23:59:59 UTC sinon il semblerait que le démon ntpd ait déjà passé au kernel l'update incluant la leap second... Tous les train 5 semblent impactés. n.b. On a eu le problème ce matin... alors management uniquement ? ou transit planté ? Merci A+ mais sur un seul de nos nexus (heureusement !) A+ cedric --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco Nexus & Leap second
Le 30/06/2015 15:38, Paillet Cedric a écrit : equipment 100% bloqué... pas de console (juste le msg d'erreur), pas de mgmt, tous ports giga down physiquement ! Sans commentaire :-\ Quel modèle ? Quel nx-os pour info ? Le truc marrant est que ce même train 5 est déjà impacté par un bug ntp qui le rend inopérant donc contourne le problème leap second : https://tools.cisco.com/bugsearch/bug/CSCui34757?emailclick=CNSemail Le bug qui protège du bug... ça c'est une feature ! Merci pour les infos -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco Nexus & Leap second
Le 30/06/2015 15:58, Frederic Dhieux a écrit : Hello, Le 30/06/15 15:44, Jérôme BERTHIER a écrit : Le 30/06/2015 15:38, Paillet Cedric a écrit : equipment 100% bloqué... pas de console (juste le msg d'erreur), pas de mgmt, tous ports giga down physiquement ! Sans commentaire :-\ Quel modèle ? Quel nx-os pour info ? A priori particulièrement tout ce qui touche à la virtu et aux environnement de ce style : http://www.cisco.com/web/about/doing_business/leap-second.html#~ProductInformation yep j'avais bien pris note de tout ça :-) Je me demandais quel modèle et nx-os avait planté chez Cédric. Cdt, -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
Le 23/07/2015 10:42, Clement Cavadore a écrit : 4) comment une ip src en 192.168.1.101 peut elle arriver a envoyer du >trafic vers mon 6500 alors qu'il n'y a pas de gateway/interface de >routage sur le subnet 192.168.1.0/24 >6509E#show ip route 192.168.1.0 >% Network not in table Il suffit que tu aies un host compromis, qui forge l'adresse IP source en envoyant des paquets avec 192.168.1.101 comme src. Il n'est pas nécessaire que ce soit routé/configuré chez toi. ou un proxy arp par là ? A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
Le 30/07/2015 10:13, David Ponzone a écrit : Il doit y avoir un moyen de les collecter en tout cas. Tu spannes les interfaces et/vlans potentiellement sources sur le 6500 vers un collecteur. Tu lui colles un tcpdump en filtrant sur l'IP source 192.168.1.x qui te pose problème, non ? -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Ip d'interco bgp
Le 15/09/2015 13:13, David Touitou a écrit : Question certainement idiote : quelle différence par rapport à utiliser des RFC1918 ? La réversibilité ? Les attaquants passeront bien à une autre cible et il sera alors possible de ré-annoncer les intercos ? -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RFC 5575
Le 23/09/2015 23:27, Nicolas LEDUC a écrit : Bonjour la liste, Je suis à la recherche d'information/retour sur la RFC5575et plus précisément le BGP FLOWSPEC. J'ai trouvé plusieurs articles, un très bien fait d'Alcatel mais c'est assez flou... Merci d'avance pour vos retour :) Cdt, Nicolas --- Liste de diffusion du FRnOG http://www.frnog.org/ Salut, En avril 2015, un article de présentation était passé dans MISC : http://boutique.ed-diamond.com/home/847-misc-78.html#/format_du_magazine-version_numerique_pdf A voir s'il n'y aurait pas quelques références utiles... -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP
Bonjour, Le 02/11/2015 21:05, Fabien H a écrit : la session iBGP tombe rapidement (j'ai mis un SLA icmp qui ping le loopback d'en face), BFD ne serait pas plus adapté pour faire ça ? Cdt, -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP
Le 03/11/2015 10:12, Raphael Mazelier a écrit : Le 03/11/15 09:58, Jérôme BERTHIER a écrit : BFD ne serait pas plus adapté pour faire ça ? BFD aide a une détection ultra rapide, mais en général ta session IBGP doit tomber car ta loopback a disparu de ton IGP. Donc un IGP bien tuné est le premier truc à faire. Tuner l'IGP ne suffit pas forcément si ? Quand la loopback disparait, du coup, tu attends l'expiration du timer BGP hold pour flusher la table de routage ? donc 180s par défaut ? Il me semble que bfd permet de converger en dessous de la seconde puisque tu accroches la session BGP à l'état bfd. Côté CPU, ça peut être plus light si traité par le data plane (en mode echo). Après il y a surement des cas d'usage plus pertinents que d'autres... et surtout que je ne connais pas :-) Cdt, -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper NFX 250
Le 03/11/2015 19:14, Jérôme Nicolle a écrit : Plop, Je viens de voir passer l'annonce du Juniper NFX 250 (0). Ça a l'air sympa comme bécane : c'est un serveur à base de Xeon, avec des interfaces SFP/SFP+ et RJ45, et ça tourne un hyperviseur à base de Windriver Linux pour héberger du vSRX (ou peut être aussi du vMX ?) et potentiellement des solutions tierces. Aucune idée du prix pour l'instant, et le modèle de licence vSRX / vMX m'a l'air particulièrement illisible et inadapté aux petits réseaux. Avez-vous des infos ou avis sur ce genre de produits ? En gros, ça coute combien pour utiliser ça comme CPE un peu avancé ? @+ (0) http://www.juniper.net/us/en/products-services/routing/nfx250/ Bonjour, A priori, il va y avoir aussi quelques nouveautés prochainement sur la gamme sécurité. Si l'on en croit ces bulletins, Juniper fait le vide à partir du 01/05/2016. Pas mal de modèles sortiraient du catalogue. 1) SRX branch : http://kb.juniper.net/resources/sites/CUSTOMERSERVICE/content/live/TECHNICAL_BULLETINS/16000/TSB16823/en_US/TSB16823.pdf On voit apparaitre des SRX300, 320, 340 et 1500. 2) Netscreen (canal historique) : http://kb.juniper.net/resources/sites/CUSTOMERSERVICE/content/live/TECHNICAL_BULLETINS/16000/TSB16826/en_US/TSB16826.pdf Au final, ça semble concerner presque toute la gamme SRX (y compris high end 1400, 3400, 3600) pour conformité aux directives européennes RoHS2 : http://kb.juniper.net/resources/sites/CUSTOMERSERVICE/content/live/TECHNICAL_BULLETINS/16000/TSB16829/en_US/TSB16829.pdf A suivre... -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Vraie IP et fausse IP ?
Bonjour, Le 16/02/2016 11:52, Xavier Beaudouin a écrit : ou le trucs comme les impôts par ex pouvaient au moins avoir un service dispo en IPv6 ça fait juste 5 ans que toutes les administrations y ont été explicitement invitées : http://circulaires.legifrance.gouv.fr/pdf/2011/12/cir_34250.pdf Bon faudrait peut être passer à la phase obligation. :-\ Voilà, voilà... -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] blocklist.de
Le 04/03/2016 09:47, ay pierre a écrit : mais il faut serveur linux pour pouvoir crée les regle Si tu veux un HIDS multi-OS, regardes OSSEC. Tu peux appliquer des réponses actives : http://ossec.github.io/docs/manual/ar/index.html ça reste beaucoup plus outillé pour le monde Unix cela dit. A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Délire DHCP sur Cisco 8XX
Le 02/06/2016 à 14:25, David Ponzone a écrit : Jun 2 14:15:34.236: DHCPD: Sending notification of TERMINATION: Jun 2 14:15:34.236: DHCPD: address 192.168.10.5 mask 255.255.255.0 Jun 2 14:15:34.236: DHCPD: reason flags: noalloc Salut En fait, ça ressemble à ce que ferait le routeur : - si le client demande explicitement une IP différente de celle du bail déjà alloué - si l'IP est déjà visible sur le réseau (via icmp) sans être référencée dans la binding table Dans les deux cas, je crois que le routeur est supposé le dire. ça donne quoi si tu croises avec un debug des échanges dhcp (DHCPDISCOVER / OFFER / REQUEST / ACK...) ? Y'a rien dans les conflits (sh ip dhcp conflict) ? Pour la survie au reboot, ça existe si tu demandes à stocker les leases sur la flash (c'est utile pour éviter de blacklister en conflit les IP déjà joignables après un reboot justement) : ip dhcp database flash://dhcp-leases A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Analyser de traffic (mise en forme)
Le 07/06/2016 à 12:48, Sylvain sbu a écrit : Bonjour, Le sujet a peut être déjà été abordé, mais je recherche un analyser de traffic pour chefs Qui générerait (facilement) one shoot ou journalierement des beau graphs pour chefs (camemberts, barre graphes etc..) avec le trafic par app (http, mail etc...) en fonction d'une capture de trafic ou de syslog adéquate. Si qqun à des soft a proposer cdt SBU --- Liste de diffusion du FRnOG http://www.frnog.org/ Salut ntopng ? http://www.ntop.org/products/traffic-analysis/ntop/ A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Comportement étrange avec ip nat inside
Salut, Sans les confs difficiles d'être précis mais... Le 21/07/2016 à 13:06, Antoine Durant a écrit : Bonjour, Bon... J'ai avancé et je sais quel est le problème mais je n'arrive pas à le résoudre... Cela est à cause du VPN :/Par le VPN tout fonctionne sauf dès que je rajoute une règle ip nat Inside sur le site distant. Ton NAT sur site 2, c'est du PAT sur l'interface outside pour le trafic Web ? Le VPN est traité par crypto map ou via interface VTI ? Sauf erreur, avec des crypto map, le NAT in->out s'applique avant le tunneling : http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/6209-5.html => tu dois exclure du NAT le trafic qui est sensé passer par le tunnel. Tu le fais sur site 1 mais il faut aussi le faire sur site 2 je pense. Dans l'idée à minima : ip access-list extended RM2 deny ip 172.16.2.0 0.0.0.255 172.16.1.0 0.0.0.255 permit ip any any A+ En gros hier j'étais à l'ouest complet croyant que le problème était ailleurs et pas en passant par le vpn. Sur le site 1 (172.16.1.x) pas de soucis j'accède bien au serveur en lan interne même avec la regle ip natLe problème est depuis le site 2 (172.16.2.x) lorsque j'active la règle ip nat je ne peux pas utiliser le service web (172.16.1.33). J'ai essayé de rajouter une regle comme ça sur le site 1 mais ça fonctionne pas mieux depuis le site 2 : ip nat inside source static tcp 172.16.1.33 80 X.Y.Z.1 80 route-map RM1 extendable ip access-list extended RM1 deny ip 172.16.0.0 0.0.255.255 any permit ip any any ------- Liste de diffusion du FRnOG http://www.frnog.org/ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] CVE-2016-5696 et les routeurs ?
Le 10/08/2016 à 21:24, Stephane Bortzmeyer a écrit : Cette faille TCP sérieuse touche Linux, ne touche pas FreeBSD ou Windows mais je n'ai trouvé nulle part d'analyse de la situation de Cisco, Huawei ou Juniper : http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf Cela m'étonne d'autant plus que la cible évidente de ces attaques est BGP (sessions très longues, adresses connues, port source souvent prévisible) et que le RFC 5961 avait été écrit entre autres en pensant à ces petites bêtes. Donc, est-ce que quelqu'un a testé son routeur favori pour voir si le control engine était vulnérable ? --- Liste de diffusion du FRnOG http://www.frnog.org/ Bonjour, L'exploitation en vidéo : https://www.youtube.com/watch?v=5h4rhAAFXFk Il se peut effectivement que des routeurs constructeur basés sur Linux soient concernés. Attendons les bulletins... Sauf erreur, l'attaquant doit établir lui même une connexion sur l'hôte sur lequel le client victime est connecté. Dans le cas de BGP, ça ne devrait pas pouvoir arriver (RFC 7454 / BCP 194 : ACL in, TTL security...), non ? Par contre, ça risque poser de nouveau la question de la réactivité des constructeurs. Ils utilisent massivement des sources communautaires mais ne fournissent pas la réactivité d'une distrib. Du coup, on se traine au mieux avec des lib openssl, glibc exposées... Bonne fin de journée -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] CVE-2016-5696 et les routeurs ?
Le 10/08/2016 à 21:24, Stephane Bortzmeyer a écrit : Cette faille TCP sérieuse touche Linux, ne touche pas FreeBSD ou Windows mais je n'ai trouvé nulle part d'analyse de la situation de Cisco, Huawei ou Juniper : http://www.cs.ucr.edu/~zhiyunq/pub/sec16_TCP_pure_offpath.pdf Cela m'étonne d'autant plus que la cible évidente de ces attaques est BGP (sessions très longues, adresses connues, port source souvent prévisible) et que le RFC 5961 avait été écrit entre autres en pensant à ces petites bêtes. Donc, est-ce que quelqu'un a testé son routeur favori pour voir si le control engine était vulnérable ? --- Liste de diffusion du FRnOG http://www.frnog.org/ Bonjour, L'exploitation en vidéo : https://www.youtube.com/watch?v=5h4rhAAFXFk Il se peut effectivement que des routeurs constructeur basés sur Linux soient concernés. Attendons les bulletins... Sauf erreur, l'attaquant doit établir lui même une connexion sur l'hôte sur lequel le client victime est connecté. Dans le cas de BGP, ça ne devrait pas pouvoir arriver (RFC 7454 / BCP 194 : ACL in, TTL security...), non ? Par contre, ça risque poser de nouveau la question de la réactivité des constructeurs. Ils utilisent massivement des sources communautaires mais ne fournissent pas la réactivité d'une distrib. Du coup, on se traine au mieux avec des lib openssl, glibc exposées... Bonne fin de journée -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Détecter les protocoles de broadcast non grata
Salut, Le 24/03/2017 à 09:20, Alarig Le Lay a écrit : DHCP, RA, CDP, ARP spoofing et autres protocoles Si c'est pour le détecter, faut se tourner vers sFlow je pense. Si c'est pour le filtrer, comme David l'a dit, tu dois pouvoir agir au niveau de tes switchs (y compris virtuels). Les échanges cdp, lldp se désactivent (bon c'était pas la question). Pour les switchs modernes, tu vas trouver plein de trucs genre : dhcp snopping, ra guard, ipv6 dhcp snooping, dynamic arc inspection... Pour les un peu moins modernes, tu dois pouvoir coller des acls en in sur les ports pour filtrer les annonces RA, réponses dhcp... Bonne journée -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Fibre FREE en zone moyennement dense
Bonjour, Le 07/04/2017 à 14:08, Buzzer a écrit : Bonjour, Je fais parti d'un service réseau d'une banque, qui a un grand nombre d'utilisateurs en travail à distance. Nous utilisons Cisco anyconnect sur des Cisco ASA en mode dtls. Nous avons constaté que nos utilisateur clients chez Free en fibre optique et en zone moyennement dense n'arrivent pas à monter le vpn. Si DTLS ne fonctionne pas, le client est sensé utiliser la session TCP443 qui est initiée au départ. Du coup, c'est bizarre qu'ils "n'arrivent pas à monter le vpn". Pour rappel en zone moyennement dense FREE utilise le partage d'ipv4 entre les utilisateurs. Le symptôme est que le vpn tente de négocié un mtu, mais la perte de paquet sur l'infrastructure empêche cette négociation d'aboutir. Un cas "similaire" semble explicitement décrit : http://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/116881-technote-anyconnect-00.html Bon courage ;-) -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Faille WPA2
Le 18/10/2017 à 13:29, David Ponzone a écrit : Pour ceux qui ont pas encore vu, grosse faille trouvée dans WPA2. Mikrotik a corrigé: https://forum.mikrotik.com/viewtopic.php?f=21&t=126695 Meraki aussi: https://meraki.cisco.com/blog/2017/10/critical-802-11r-vulnerability-disclosed-for-wireless-networks/ --- Liste de diffusion du FRnOG http://www.frnog.org/ Salut, 9 failles sur 10 sont à corriger côté client semble-t-il. ça risque laisser pas mal de monde vulnérable un bon moment... Un billet Cisco donne un peu de contexte (et de précisions sur l'impact de leur côté) : https://gblogs.cisco.com/fr/zzfeatured/wpa-wpa2-this-is-not-the-end/ A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Adresses publiques non annoncées : légitime ou pas ?
Le 24/09/2014 08:05, Raphael Maunier a écrit : En pratique, l’utilisation d’IPv6 reste très anecdotique en entreprise, je dirais meme quasi nul ! Disons que l'utilisation assumée reste très anecdotique. Le fait est que tous les systèmes récents ont une pile IPv6 active par défaut donc qu'il y a surement du trafic v6 sur la plupart des réseaux locaux... Par exemple, sauf erreur de ma part, tout OS Windows récent parlera à son contrôleur de domaine en v6 quitte à utiliser une encapsulation 6to4.. Bref que les entreprises en veuillent ou non, IPv6 est déjà dans les murs, il reste à le traiter convenablement.. Jérôme smime.p7s Description: Signature cryptographique S/MIME
Re: [FRnOG] [TECH] Y a-t-il une porte dérobée dans mon routeur ?
Le 05/11/2014 05:05, Michel Py a écrit : Je remarque innocemment que personne du vendeur "C" ou "J" qui pourtant comptent tous deux nombres d'auteurs prolifiques de drafts n'a eu les c... d'écrire ou de participer. Ca serait s'abaisser : tout le monde sait que leurs routeurs n'ont jamais eu de porte dérobée. Pourtant, "J" cherche partout le backdoor qu'on aurait installé à l’insu de leur plein gré : http://kb.j[..].net/InfoCenter/index?page=content&id=JSA10605&cat=SIRT_1&actp=LIST S'ils ne l'ont toujours pas trouvé, c'est qu'il ne doit pas y en avoir ;-) ... -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Conseil switches
Le 05/01/2015 11:38, Raphael Mazelier a écrit : Le stacking (ou virtual chassis chez Juniper) apporte : - une facilité/simplicité d'administration (une seule configuration pour X switch) - la possibilité de faire du LACP multi-switch (et donc de la redondance + scaling). - la possibilité de faire des configurations spanning tree less. Le point négatif : un SPOF applicatif. Cela arrive rarement mais cela arrive. Bonjour, Pour avoir des dizaines de stack Cisco en prod depuis des années, je confirme les points positifs mis en avant. Je n'imagine pas faire autrement . Quelques infos côté matos : - les 2960S sont limités à quatre éléments par pile mais surtout à 6 Etherchannel par stack ! Autre point, leur coût de maintenance est assez élevé (du fait d'une soudaine augmentation de tarif cette année...) - les 2960X passent à huit éléments par pile et à 24 Etherchannel par stack. Côté matos, vu un switch HS au bout de quelques mois mais ça peut arriver... La version XR propose une double alim et 48 Etherchannel par stack. - les 3750G sont ultra fiables, proposent neuf éléments par pile, 48 Etherchannel par stack mais sont en fin de vie commerciale (en théorie) : http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3750-series-switches/eos-eol-notice-c51-731425.html - les 3750X sont leurs remplaçants théoriques sous IOS-XE like. Rien à dire côté matériel mais quelques bugs relevés sur des features access avec un suivi aléatoire côté TAC... - A prix équivalent, autant regarder côté 3850 maintenant je pense car ceux-ci peuvent être acquis si besoin avec quatre SFP+ 10G par switch et proposent 128 Etherchannels par stack : http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-3850-series-switches/qa_c67-722110.html Ce pointeur compare ces gammes : http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-2960-x-series-switches/white_paper_c11-728327.html Les 3750X / 3850 sont bien devant en terme de perf de la stack mais bon... Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [MISC] Remplacement solution IOS SLB
Bonjour à tous, Je cherche une solution pour remplacer un service Cisco IOS SLB (test de vie + LB + injection de route). Deux raisons : 1) la feature n'est plus supportée par Cisco depuis longtemps sauf à conserver un IOS très ancien 2) les plateformes matérielles qui traitent le service sont vraiment en fin de vie et non maintenues Actuellement, nous utilisons ce service comme suit : - deux VIP sont dual homées en BGP sur deux sites distants (une VIP prioritaire / site) - sur chaque site : -> le service est testé par des probes SLB TCP -> les deux VIP sont mappées en priorité sur le serveur réel local puis en backup sur le serveur réel de l'autre site -> les deux VIP sont annoncées dans l'aire ospf du site. Ces annonces alimentent les routeurs WAN pour déclencher l'annonce eBGP. -> en cas de plantage du service, la VIP tombe, l'annonce ospf disparait, la route disparait sur les routeurs WAN et ça coupe l'annonce eBGP du site concerné. En jouant avec ip sla + nat, on arrive à approcher un fonctionnement similaire mais avec une limite côté NAT statique : impossible de mapper deux VIP (adresse globale) sur une même adresse réelle (adresse locale). Pour l'instant, on met de côté cette solution. En parallèle, on utilise du load balancing Linux LVS. Pour l'instant, on n'a pas trouvé comment attacher l'état ldirectord à un démon ospf. Ce serait pourtant peut être la piste la plus prometteuse. Au final, on a surtout besoin des fonctionnalités test de vie + injection de route. La partie LB est facultative puisque on a déjà un RR DNS. Je précise que, pour l'instant, pas de budget à engager pour cela donc on écarte les produits dédiés type F5, A10... Auriez-vous des pistes à me conseiller d'explorer ? Merci d'avance -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Remplacement solution IOS SLB
Bonjour, Merci pour ces infos utiles Je ferai un retour sur nos tests d'ici quelques temps. Cdt, Le 02/03/2015 18:35, Romain SIBILLE a écrit : Une idée me vient à l'esprit: keepalived (ou ldirectord mais je ne sais pas comment il fonctionne) pourrait placer la VIP sur une interface type "loopback", ce qui aurait pour effet d'ajouter une route dans la table de routage de ton loadbalancer (route de type "connected", sans next-hop). Ensuite, il suffirait de bien configurer les "redistribute" de ton daemon de routage, et ton LB serait vu par tes routeurs de coeur comme "next-hop" pour joindre la VIP. Du coup, le service tombe, keepalived retire la VIP de la loopback, la route "connected" disparait, et n'est donc plus annoncée par ton IGP à tes routeurs. A tester... et ne pas hésiter à me corriger si je raconte des bêtises... Cordialement, Romain Le 02/03/2015 18:16, Jérôme BERTHIER a écrit : Bonjour, Je vais creuser keepalived. Après un peu de lecture rapide, je vois effectivement qu'on peut déclencher des scripts selon les changements d'état donc influer sur un démon tiers. L'idéal serait de rendre keepalived directement acteur du routage mais ça peut faire l'affaire. Merci pour l'info Le 02/03/2015 17:45, Romain SIBILLE a écrit : Bonjour Jérôme, Je ne sais pas si ça répond exactement à ton besoin, mais keepalived permet plein de choses, comme par exemple lancer des scripts en cas de détection de changement d'état d'un service. As tu exploré cette piste en remplacement de ldirectord? Cordialement Romain Le 02/03/2015 17:18, Jérôme BERTHIER a écrit : Bonjour à tous, Je cherche une solution pour remplacer un service Cisco IOS SLB (test de vie + LB + injection de route). Deux raisons : 1) la feature n'est plus supportée par Cisco depuis longtemps sauf à conserver un IOS très ancien 2) les plateformes matérielles qui traitent le service sont vraiment en fin de vie et non maintenues Actuellement, nous utilisons ce service comme suit : - deux VIP sont dual homées en BGP sur deux sites distants (une VIP prioritaire / site) - sur chaque site : -> le service est testé par des probes SLB TCP -> les deux VIP sont mappées en priorité sur le serveur réel local puis en backup sur le serveur réel de l'autre site -> les deux VIP sont annoncées dans l'aire ospf du site. Ces annonces alimentent les routeurs WAN pour déclencher l'annonce eBGP. -> en cas de plantage du service, la VIP tombe, l'annonce ospf disparait, la route disparait sur les routeurs WAN et ça coupe l'annonce eBGP du site concerné. En jouant avec ip sla + nat, on arrive à approcher un fonctionnement similaire mais avec une limite côté NAT statique : impossible de mapper deux VIP (adresse globale) sur une même adresse réelle (adresse locale). Pour l'instant, on met de côté cette solution. En parallèle, on utilise du load balancing Linux LVS. Pour l'instant, on n'a pas trouvé comment attacher l'état ldirectord à un démon ospf. Ce serait pourtant peut être la piste la plus prometteuse. Au final, on a surtout besoin des fonctionnalités test de vie + injection de route. La partie LB est facultative puisque on a déjà un RR DNS. Je précise que, pour l'instant, pas de budget à engager pour cela donc on écarte les produits dédiés type F5, A10... Auriez-vous des pistes à me conseiller d'explorer ? Merci d'avance -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Remplacement solution IOS SLB
Le 02/03/2015 18:42, Raphael Mazelier a écrit : Le 02/03/15 17:18, Jérôme BERTHIER a écrit : Au final, on a surtout besoin des fonctionnalités test de vie + injection de route. La partie LB est facultative puisque on a déjà un RR DNS. Généralement je fais ça avec exabgp, avec un heathcheck custom. Ça ne fait pas LB, encore que tu puisse activer le mutlipath bgp sur tes routeurs (bon en revanche pas de poids). Bonjour, En combinant les annonces iBGP conditionnées aux tests de vie avec du NAT pour mapper les VIP vers le serveur réel du site, il me semble que ça répond au besoin. Je vais regarder ça. Merci pour les infos Cdt, -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] [TECH] Boitier VPN + SWITCH + FW
Bonjour, Le 24/03/2015 11:18, Sylvain Busson a écrit : La commande monitor interface Non "monitor interface" ça classifie les paquets, erreurs... "monitor traffic interface" ça capture seulement ce qui entre et sort de la RE Si tu veux capturer le transit, tout est décrit ici : http://kb.juniper.net/InfoCenter/index?page=content&id=KB15779 C'est possible mais plutôt pénible. A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] [TECH] Boitier VPN + SWITCH + FW
Bonjour, Sauf erreur, Jflow (ou IPFIX ou Netflow) ne capture pas le trafic lui même mais les attributs liés à ce trafic (IP, port, volume échangé, interfaces, AS, label MPLS...). Il me semble que l'on parlait de faire du dump de trafic de transit. Pour JFlow, ça reste un échantillonnage. Le JTAC ne conseille pas de monter au delà d'un ratio 1:100 si ce sont les SRX eux même qui collectent... Cdt, Le 09/04/2015 09:27, Frédéric Grosjean a écrit : Bonjour, je confirme qu'avec du jflow c'est possible. (Example: Configuring Packet Capture on an Interface <http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/security/software-all/monitoring-and-troubleshooting/index.html?config-pcap-chapter.html>) En plus ça permet d'avoir un historique centralisé de tous les SRXs Branch et High-End sur un le collecteur. A+ Le 24/03/2015 11:29, Jérôme BERTHIER a écrit : Bonjour, Le 24/03/2015 11:18, Sylvain Busson a écrit : La commande monitor interface Non "monitor interface" ça classifie les paquets, erreurs... "monitor traffic interface" ça capture seulement ce qui entre et sort de la RE Si tu veux capturer le transit, tout est décrit ici : http://kb.juniper.net/InfoCenter/index?page=content&id=KB15779 C'est possible mais plutôt pénible. A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] SSH public key auth sur Cat3750G
Le 16/04/2015 18:22, David Ponzone a écrit : Bonsoir, J’ai l’impression qu’en IOS 12.2(55)SE1 (le plus récent à priori), un Cat3750G est pas capable d’authentifier une connexion au CLI sur public key (et donc sans mot de passe). Je me bats depuis un moment avec, et je ne crois pas avoir raté quelque chose. Si qqun peut confirmer, je me sentirai moins con (ou un peu plus), et j’arrêterai de perdre du temps :) Merci David --- Liste de diffusion du FRnOG http://www.frnog.org/ Bonsoir, C'est apparu en IOS 15.0 seulement : http://blog.ipspace.net/2009/10/ssh-rsa-authentication-works-in-ios.html Pas possible sur les 3750G :-\ Cdt, -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Fwd: [FRnOG] [JOBS] Coupure de connexion SSH
de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Réponse de 192.168.130.5 : octets=32 temps<1ms TTL=63 Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Délai d'attente de la demande dépassé. Des idées pour ce genre de problème s'il vous plait?? Merci d'avance pour votre aide Cordialement, --- 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/ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées
Bonjour, Le 27/06/2015 18:51, Frederic Dhieux a écrit : Pour moi la démarche c'est d'abord de configurer les briques en IPv4 ET en IPv6 une par une et de pouvoir un jour se dire "tiens la chaine est complète, on peut utiliser le service en IPv6 quand on est en IPv6 sur un autre end point" +1 Jeune et con depuis un paquet d'années =) En tout cas pas blasé c'est sûr. Plus concrètement, ça coûte tant que ça de configurer les 2 stacks sur un équipement quand on l'installe de nos jours ? Je ne crois pas non plus. Toutes les fonctionnalités de routage / filtrage sont disponibles pour les deux piles donc, si besoin, à part avoir à gérer un nouvel IGP (OSPFv3, RIPNG...) pour traiter IPv6, je ne vois pas la différence. Côté serveur, j'ai l'impression que l'effort est même carrément l'inverse. Tous les OS sont de base paramétrés en double pile. Si on ne veut pas faire d'IPv6 du tout (même en l'absence de service d'adressage global), il faut y travailler pour déconfigurer l'affaire. Quittes à y passer du temps (même faible) autant le faire pour déployer IPv6, non ? Côté postes client, le plus gênant pour généraliser une connectivité IPv6 reste à mon sens les contraintes de traçabilité d'allocation des adresses. Comme évoqué dans la discussion, l'utilisation du DUID et sa gestion plus ou moins rigoureuse rend difficile l'établissement d'une correspondance statique entre machine et IPv6 globale à allouer par DHCPv6. Bref, j'ai quand même l'impression que ça avance doucement et surement mais bon, comme me dit un jour, un DSI auquel je parlais déploiement IPv6 : "bah IPv6 depuis le temps qu'on en parle, si ça servait à quelque chose, ça se saurait !" Ceci explique cela ? A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées
Le 29/06/2015 11:26, Phil Regnauld a écrit : >Et quand tu utilises IS-IS même pas:) Quoi un truc même pas IP du tout :-) OSPFv3 fait v4 maintenant (j'adore expliquer ça aux nouveaux: pour v6, tu installes v3 qui fait v4). Pour l'anecdote, j'ai bien tenté de remplacer IPv4/OSPFv2 par IPv6/OSPFv3 (incluant address family IPv4) mais un vilain bug Cisco de redistribution BGP->OSPFv3 m'a coupé dans mon élan : https://tools.cisco.com/bugsearch/bug/CSCue82043 D'ailleurs, je vois qu'on est nombreux à avoir remonté le problème seulement considéré comme "Enhancement"... :-\ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco Nexus & Leap second
Bonjour, Le 30/06/2015 14:43, Cédric Paillet a écrit : Salut, Joli petit bug sympa sur nexus N5K https://tools.cisco.com/quickview/bug/CSCub38654 vos nexus risquent tout simplement de s’arrêter de ce que j'ai compris , ça risque planter le management "uniquement" D'autres avis dans ce sens ? dans la journée... et il faut un power off pour les relancer... en comptant sur le vpc hein :-\ un "no ntp server " corrige le problème. Selon le bug case, uniquement s'il a été fait deux jours avant donc au plus tard dimanche 23:59:59 UTC sinon il semblerait que le démon ntpd ait déjà passé au kernel l'update incluant la leap second... Tous les train 5 semblent impactés. n.b. On a eu le problème ce matin... alors management uniquement ? ou transit planté ? Merci A+ mais sur un seul de nos nexus (heureusement !) A+ cedric --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco Nexus & Leap second
Le 30/06/2015 15:38, Paillet Cedric a écrit : equipment 100% bloqué... pas de console (juste le msg d'erreur), pas de mgmt, tous ports giga down physiquement ! Sans commentaire :-\ Quel modèle ? Quel nx-os pour info ? Le truc marrant est que ce même train 5 est déjà impacté par un bug ntp qui le rend inopérant donc contourne le problème leap second : https://tools.cisco.com/bugsearch/bug/CSCui34757?emailclick=CNSemail Le bug qui protège du bug... ça c'est une feature ! Merci pour les infos -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco Nexus & Leap second
Le 30/06/2015 15:58, Frederic Dhieux a écrit : Hello, Le 30/06/15 15:44, Jérôme BERTHIER a écrit : Le 30/06/2015 15:38, Paillet Cedric a écrit : equipment 100% bloqué... pas de console (juste le msg d'erreur), pas de mgmt, tous ports giga down physiquement ! Sans commentaire :-\ Quel modèle ? Quel nx-os pour info ? A priori particulièrement tout ce qui touche à la virtu et aux environnement de ce style : http://www.cisco.com/web/about/doing_business/leap-second.html#~ProductInformation yep j'avais bien pris note de tout ça :-) Je me demandais quel modèle et nx-os avait planté chez Cédric. Cdt, -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
Le 23/07/2015 10:42, Clement Cavadore a écrit : 4) comment une ip src en 192.168.1.101 peut elle arriver a envoyer du >trafic vers mon 6500 alors qu'il n'y a pas de gateway/interface de >routage sur le subnet 192.168.1.0/24 >6509E#show ip route 192.168.1.0 >% Network not in table Il suffit que tu aies un host compromis, qui forge l'adresse IP source en envoyant des paquets avec 192.168.1.101 comme src. Il n'est pas nécessaire que ce soit routé/configuré chez toi. ou un proxy arp par là ? A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
Le 30/07/2015 10:13, David Ponzone a écrit : Il doit y avoir un moyen de les collecter en tout cas. Tu spannes les interfaces et/vlans potentiellement sources sur le 6500 vers un collecteur. Tu lui colles un tcpdump en filtrant sur l'IP source 192.168.1.x qui te pose problème, non ? -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Ip d'interco bgp
Le 15/09/2015 13:13, David Touitou a écrit : Question certainement idiote : quelle différence par rapport à utiliser des RFC1918 ? La réversibilité ? Les attaquants passeront bien à une autre cible et il sera alors possible de ré-annoncer les intercos ? -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RFC 5575
Le 23/09/2015 23:27, Nicolas LEDUC a écrit : Bonjour la liste, Je suis à la recherche d'information/retour sur la RFC5575et plus précisément le BGP FLOWSPEC. J'ai trouvé plusieurs articles, un très bien fait d'Alcatel mais c'est assez flou... Merci d'avance pour vos retour :) Cdt, Nicolas --- Liste de diffusion du FRnOG http://www.frnog.org/ Salut, En avril 2015, un article de présentation était passé dans MISC : http://boutique.ed-diamond.com/home/847-misc-78.html#/format_du_magazine-version_numerique_pdf A voir s'il n'y aurait pas quelques références utiles... -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP
Bonjour, Le 02/11/2015 21:05, Fabien H a écrit : la session iBGP tombe rapidement (j'ai mis un SLA icmp qui ping le loopback d'en face), BFD ne serait pas plus adapté pour faire ça ? Cdt, -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Failover en cas de défaillance routeur BGP
Le 03/11/2015 10:12, Raphael Mazelier a écrit : Le 03/11/15 09:58, Jérôme BERTHIER a écrit : BFD ne serait pas plus adapté pour faire ça ? BFD aide a une détection ultra rapide, mais en général ta session IBGP doit tomber car ta loopback a disparu de ton IGP. Donc un IGP bien tuné est le premier truc à faire. Tuner l'IGP ne suffit pas forcément si ? Quand la loopback disparait, du coup, tu attends l'expiration du timer BGP hold pour flusher la table de routage ? donc 180s par défaut ? Il me semble que bfd permet de converger en dessous de la seconde puisque tu accroches la session BGP à l'état bfd. Côté CPU, ça peut être plus light si traité par le data plane (en mode echo). Après il y a surement des cas d'usage plus pertinents que d'autres... et surtout que je ne connais pas :-) Cdt, -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper NFX 250
Le 03/11/2015 19:14, Jérôme Nicolle a écrit : Plop, Je viens de voir passer l'annonce du Juniper NFX 250 (0). Ça a l'air sympa comme bécane : c'est un serveur à base de Xeon, avec des interfaces SFP/SFP+ et RJ45, et ça tourne un hyperviseur à base de Windriver Linux pour héberger du vSRX (ou peut être aussi du vMX ?) et potentiellement des solutions tierces. Aucune idée du prix pour l'instant, et le modèle de licence vSRX / vMX m'a l'air particulièrement illisible et inadapté aux petits réseaux. Avez-vous des infos ou avis sur ce genre de produits ? En gros, ça coute combien pour utiliser ça comme CPE un peu avancé ? @+ (0) http://www.juniper.net/us/en/products-services/routing/nfx250/ Bonjour, A priori, il va y avoir aussi quelques nouveautés prochainement sur la gamme sécurité. Si l'on en croit ces bulletins, Juniper fait le vide à partir du 01/05/2016. Pas mal de modèles sortiraient du catalogue. 1) SRX branch : http://kb.juniper.net/resources/sites/CUSTOMERSERVICE/content/live/TECHNICAL_BULLETINS/16000/TSB16823/en_US/TSB16823.pdf On voit apparaitre des SRX300, 320, 340 et 1500. 2) Netscreen (canal historique) : http://kb.juniper.net/resources/sites/CUSTOMERSERVICE/content/live/TECHNICAL_BULLETINS/16000/TSB16826/en_US/TSB16826.pdf Au final, ça semble concerner presque toute la gamme SRX (y compris high end 1400, 3400, 3600) pour conformité aux directives européennes RoHS2 : http://kb.juniper.net/resources/sites/CUSTOMERSERVICE/content/live/TECHNICAL_BULLETINS/16000/TSB16829/en_US/TSB16829.pdf A suivre... -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Vraie IP et fausse IP ?
Bonjour, Le 16/02/2016 11:52, Xavier Beaudouin a écrit : ou le trucs comme les impôts par ex pouvaient au moins avoir un service dispo en IPv6 ça fait juste 5 ans que toutes les administrations y ont été explicitement invitées : http://circulaires.legifrance.gouv.fr/pdf/2011/12/cir_34250.pdf Bon faudrait peut être passer à la phase obligation. :-\ Voilà, voilà... -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] blocklist.de
Le 04/03/2016 09:47, ay pierre a écrit : mais il faut serveur linux pour pouvoir crée les regle Si tu veux un HIDS multi-OS, regardes OSSEC. Tu peux appliquer des réponses actives : http://ossec.github.io/docs/manual/ar/index.html ça reste beaucoup plus outillé pour le monde Unix cela dit. A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Délire DHCP sur Cisco 8XX
Le 02/06/2016 à 14:25, David Ponzone a écrit : Jun 2 14:15:34.236: DHCPD: Sending notification of TERMINATION: Jun 2 14:15:34.236: DHCPD: address 192.168.10.5 mask 255.255.255.0 Jun 2 14:15:34.236: DHCPD: reason flags: noalloc Salut En fait, ça ressemble à ce que ferait le routeur : - si le client demande explicitement une IP différente de celle du bail déjà alloué - si l'IP est déjà visible sur le réseau (via icmp) sans être référencée dans la binding table Dans les deux cas, je crois que le routeur est supposé le dire. ça donne quoi si tu croises avec un debug des échanges dhcp (DHCPDISCOVER / OFFER / REQUEST / ACK...) ? Y'a rien dans les conflits (sh ip dhcp conflict) ? Pour la survie au reboot, ça existe si tu demandes à stocker les leases sur la flash (c'est utile pour éviter de blacklister en conflit les IP déjà joignables après un reboot justement) : ip dhcp database flash://dhcp-leases A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Analyser de traffic (mise en forme)
Le 07/06/2016 à 12:48, Sylvain sbu a écrit : Bonjour, Le sujet a peut être déjà été abordé, mais je recherche un analyser de traffic pour chefs Qui générerait (facilement) one shoot ou journalierement des beau graphs pour chefs (camemberts, barre graphes etc..) avec le trafic par app (http, mail etc...) en fonction d'une capture de trafic ou de syslog adéquate. Si qqun à des soft a proposer cdt SBU --- Liste de diffusion du FRnOG http://www.frnog.org/ Salut ntopng ? http://www.ntop.org/products/traffic-analysis/ntop/ A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Comportement étrange avec ip nat inside
Salut, Sans les confs difficiles d'être précis mais... Le 21/07/2016 à 13:06, Antoine Durant a écrit : Bonjour, Bon... J'ai avancé et je sais quel est le problème mais je n'arrive pas à le résoudre... Cela est à cause du VPN :/Par le VPN tout fonctionne sauf dès que je rajoute une règle ip nat Inside sur le site distant. Ton NAT sur site 2, c'est du PAT sur l'interface outside pour le trafic Web ? Le VPN est traité par crypto map ou via interface VTI ? Sauf erreur, avec des crypto map, le NAT in->out s'applique avant le tunneling : http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/6209-5.html => tu dois exclure du NAT le trafic qui est sensé passer par le tunnel. Tu le fais sur site 1 mais il faut aussi le faire sur site 2 je pense. Dans l'idée à minima : ip access-list extended RM2 deny ip 172.16.2.0 0.0.0.255 172.16.1.0 0.0.0.255 permit ip any any A+ En gros hier j'étais à l'ouest complet croyant que le problème était ailleurs et pas en passant par le vpn. Sur le site 1 (172.16.1.x) pas de soucis j'accède bien au serveur en lan interne même avec la regle ip natLe problème est depuis le site 2 (172.16.2.x) lorsque j'active la règle ip nat je ne peux pas utiliser le service web (172.16.1.33). J'ai essayé de rajouter une regle comme ça sur le site 1 mais ça fonctionne pas mieux depuis le site 2 : ip nat inside source static tcp 172.16.1.33 80 X.Y.Z.1 80 route-map RM1 extendable ip access-list extended RM1 deny ip 172.16.0.0 0.0.255.255 any permit ip any any ------- Liste de diffusion du FRnOG http://www.frnog.org/ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [FRNOG] [MISC]Unbound et resolveur DNS à la maison
Bonjour, Le 10/03/2019 à 20:45, Carroussel Informatique a écrit : Y a t'il un intérêt pour un particulier collé derrière une MachinBox, a utiliser Unbound (ou tout autre résolveur DNS), à part pour le "sport" ? t Trois intérêts possibles : - Utiliser un resolver validant DNSSEC - Protéger son usage de statistiques commerciales ou autres - Éviter les resolvers menteurs Question subsidiaire : est ce que ce genre d'outil ne va pas mettre la bécane à genoux ? ça ne prend quasiment rien comme ressources (raspberry pi...). Bonne journée -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cisco vulnérabilité Thrangrycat
Le 14/05/2019 à 16:30, S Batignolles a écrit : Bonjour, Je suis à la recherche d'infos, outils, qui pourrait m'aider à deceler une eventuelle faille sur mes ASR.. Merci d'avance Sam --- Liste de diffusion du FRnOG http://www.frnog.org/ Salut Bah regardes les deux bulletins sécurité correspondants : https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190513-secureboot https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190513-webui Tu trouveras les modèles, versions IOS-XE et configurations concernés... A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] génération de licence
Le 06/06/2019 à 21:08, Ali D a écrit : Bonjour à tous, On n'arrive pas à installer les licences sur Prime 3.4 (VM Express-Plus). Le PID et SN récupéré en CLI (sh udi) et en GUI (Administration> Dashboards> System Monitoring Dashboard) correspondent bien. mais la licence est rejetée à cause du PID (message d'erreur: Wrong PID in license file). Quelqu'un a t-il rencontré le même problème? En vous remerciant d'avance pour votre aide. Cdt, Ali D --- Liste de diffusion du FRnOG http://www.frnog.org/ Salut, A tout hasard : "As Prime Infrastructure no longer supports the node-locked licensing approach, the UDI information required to generate licenses are limited to a standard syntax as shown below: * PID = PRIME-NCS-APL (For Physical Appliance) PID = PRIME-NCS-VAPL (For Virtual Appliance/Virtual Machine) * SN = ANY:ANY You must provide the subtleties in the mentioned format to generate new licenses." Ref. : https://www.cisco.com/c/en/us/td/docs/net_mgmt/prime/infrastructure/3-4/admin/guide/bk_CiscoPrimeInfastructure_3_4_AdminGuide/bk_CiscoPrimeInfastructure_3_4_AdminGuide_chapter_01.html#con_1092492 Cdt, -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Pylône de téléphonie mobile et élagage d'arbres gênants ?
Salut, Le 13/09/2019 à 10:56, Toussaint OTTAVI a écrit : Le 13/09/2019 à 10:31, Paul Rolland (ポール・ロラン) a écrit : Je viens de trouver le document reference ci-dessous. Il ne repond pas a la totalite de tes questions, mais indique un point : "Depuis 1996 et la loi de réglementation des télécommunications, Orange ne dispose plus des prérogatives d’élagage, contrairement aux entreprises de distribution d’énergie électrique. " Il semble donc que le monde des telecoms ne dispose pas des memes droits/avantages/regles que le reseau electrique. http://www.sdehg.fr/Documentation-Orange.pdf Merci. C'est exactement ce que je recherchais. Orange n'a peut-être pas tous les droits d'Enedis en matière d'élagage "d'office", mais la commune dispose tout de même de possibilités : - La commune peut prendre un arrêté d'élagage signifié aux propriétaires concernés "afin de permettre un fonctionnement correct du réseau de communications électroniques". A l'origine, cela a été prévu pour les risques de chute sur les lignes fixes; mais tel que c'est rédigé, à priori, cela s'applique aussi à la téléphonie mobile. - La commune peut également mettre en demeure les propriétaires, et en cas d'inaction, procéder à un élagage d'office. --- Liste de diffusion du FRnOG http://www.frnog.org/ Le droit de servitude d'élagage semble avoir été rétabli en 2015 : http://www.assemblee-nationale.fr/14/ta/ta0514.asp Toutefois, ça a l'air de concerner uniquement "l’entretien des réseaux assurant des services _/fixes/_ de communications électroniques ouverts au public et de leurs abords est d’utilité publique." Pas l'impression que ça s'applique à ton cas. Bonne journée -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq
Le 13/12/2019 à 22:45, Jeremy a écrit : Sur cette liaison, la MTU doit être à 9216 octets. J'ai pu l'appliquer sur tous les switchs sauf celui de Marly qui refuse toujours d'appliquer la Qos. En conf, j'ai appliqué ces commandes : policy-map type network-qos jumbo class type network-qos class-default mtu 9216 system qos service-policy type network-qos jumbo Sans effet sur les ports. J'ai donc appliqué une autre méthode glané sur le net, qui consiste à enlever le Trunk du port, passer un "no switchport", puis un "mtu 9216" puis repasser le port en mode Trunk. Ca a fonctionné sur celui de Valenciennes qui était récalcitrant aussi. L'interface devrait me dire ça (sur le switch de Valenciennes) : Bonjour, En fait, ça dépend du modèle Nexus. Certains supportent un MTU par port et la majorité nécessite une application Network QOS (et ne change pas le MTU renvoyé par l'interface) : https://www.cisco.com/c/en/us/support/docs/switches/nexus-9000-series-switches/118994-config-nexus-00.html#anc8 Je pense que ça explique pourquoi une partie de tes switchs affiche correctement le MTU modifié. Pas de besoin de reload (heureusement). Exemple sur un 5500 en prod sous NX-OS 7.3 : sw1# sh int Eth1/1 | i MTU MTU 1500 bytes, BW 1000 Kbit, DLY 10 usec sw1# sh queuing int Eth1/1 | i MTU q-size: 469760, q-size-40g: 0, HW MTU: 9216 (9216 configured) => le MTU défini par Network QOS est bien appliqué Bonne journée -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Problème MTU sur Nexus 3064Pq
Salut, Le 19/12/2019 à 22:48, Michel Py a écrit : Le MTU renvoyé par l'interface, il est applicable dans quel cas ? Visiblement, en l'état par défaut, si tu n'appliques pas de Network QOS... En fait, je pense que ça dépend des modèles et ça se complique sur ceux qui supportent la convergence SAN. Tu peux utiliser un MTU différent par classe de service donc au final le MTU de l'interface n'a pas vraiment d'application (sauf par défaut ?). "MTU is specified per system class. The system class allows a different MTU for each class of traffic but they must be consistent on all ports across the entire switch. You cannot configure MTU on the interfaces." "The show interface command always displays 1500 as the MTU. Because the Cisco Nexus device supports different MTUs for different QoS groups, it is not possible to represent the MTU as one value on a per interface level." Exemple Nexus 5600 : https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5600/sw/qos/7x/b_5600_QoS_Config_7x/b_6k_QoS_Config_7x_chapter_0110.html Est-ce que çà ne serait pas plus glop de le supprimer au lieu de la confusion ? On est bien d'accord que ça crée une situation illisible. ça a l'air complètement dépendant du modèle. Bref, au moins pour les 3000, il semble que la valeur soit adaptée correctement sur l'interface pour les versions NX-OS récentes : "Note: When the Nexus 3000 is on code earlier than 7.0(3)I2(2a), check the MTU value with the show queueing interface ethernet x/x command. Nexus 3000 switches that run 7.0(3)I2(2a) and later show the MTU size on a per-port basis." A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] smtp gmail.com
Le 18/09/2018 à 12:33, Nicolas Milano a écrit : # dig mx gmail.com ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mx gmail.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55135 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1680 ;; QUESTION SECTION: ;gmail.com. IN MX ;; AUTHORITY SECTION: gmail.com. 84600 IN SOA dns.mengine.net. webmaster.gmail.com. [ callto:2018091701 28810 7200 | 2018091701 28810 7200 ] 86400 84600 ;; Query time: 1 msec ;; SERVER: [ callto:185.142.52.9 | 185.142.52.9 ] # [ callto:53(185.142.52.9 | 53(185.142.52.9 ] ) ;; WHEN: Tue Sep 18 12:26:18 CEST 2018 ;; MSG SIZE rcvd: 99 Salut, Bon alors là, c'est ton serveur dns le problème. Réponses normales : => dig +short SOA gmail.com ns1.google.com. dns-admin.google.com. 213412550 900 900 1800 60 => dig +short MX gmail.com 5 gmail-smtp-in.l.google.com. 30 alt3.gmail-smtp-in.l.google.com. 40 alt4.gmail-smtp-in.l.google.com. 20 alt2.gmail-smtp-in.l.google.com. 10 alt1.gmail-smtp-in.l.google.com. Tes réponses (vu que ça répond publiquement): => dig +short SOA gmail.com @185.142.52.9 dns.mengine.net. webmaster.gmail.com. 2018091701 28810 7200 86400 84600 => dig MX gmail.com @185.142.52.9 ; <<>> DiG 9.11.4-P1-RedHat-9.11.4-2.P1.fc27 <<>> MX gmail.com @185.142.52.9 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29318 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1680 ;; QUESTION SECTION: ;gmail.com. IN MX ;; AUTHORITY SECTION: gmail.com. 84600 IN SOA dns.mengine.net. webmaster.gmail.com. 2018091701 28810 7200 86400 84600 ;; Query time: 14 msec ;; SERVER: 185.142.52.9#53(185.142.52.9) ;; WHEN: mar. sept. 18 13:19:20 CEST 2018 ;; MSG SIZE rcvd: 99 Bref, ton serveur dns.mengine.net sert une version ré-écrite de la zone gmail.com de manière foireuse ... Enfin me semble-t-il A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Quel HW pour tunnel IPSEC avec APNF ?
Salut,
Le 08/11/2018 à 10:24, Joel DEREFINKO a écrit :
J'ai également eu un retour de la part de l'APNF indiquant que les ASR
1001/1002 peuvent être une alternative (on en a).
Je pense que ça nécessite des ASR 1001-*X* / 1002-*X *pour du hashage
sha256*.
*
Pour un autre besoin, je me suis pris la tête à essayer de faire le plus
robuste possible entre un ISR4331 et un ASR1001 sous IOS-XE 3.16.xS.
En ikev1, j'ai pas réussi à faire mieux que :
- policy isakmp : aes256 / group 16
- transform set ESP : aes256 / sha1
Sur les plateformes ASR1001 (pas X), j'ai bien l'impression que :
- les algos DH à courbes elliptiques ne sont pas utilisables pour la
négo isakmp
- le hashage SHA256 et supérieur n'est pas utilisable pour le tunnel
Voir la note 5 là dessus :
https://www.cisco.com/c/en/us/support/docs/security-vpn/ipsec-negotiation-ike-protocols/116055-technote-ios-crypto.html#anc5
Le pire est que la cli te laisse utiliser toutes les combinaisons
possibles !
Le tunnel ne monte pas et tu loggues via un debug ipsec ce type de
message :
IPSEC(ipsec_process_proposal): transform not supported by encryption
hardware:
{esp-aes esp-sha256-hmac }
ça devait être trop dur chez Cisco de traiter le cas par plateforme pour
refuser le paramétrage en cli directement
Si quelqu'un a une expérience plus heureuse, je prend ! :-)
A+
--
Jérôme BERTHIER
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [TECH] xconnect L2TPv3 et IP interface
Salut, Il faudrait qu'il se comporte comme un switch L3. Je suppose qu'une simple "interface vlan15" ne fonctionne pas ? -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] [MISC] Vibration DC
Le 07/03/2020 à 17:06, Stéphane Rivière a écrit : La boite de base c'est Vibrachoc (a équipé des décennies de matos mili), désormais Hutchinson-Paulstrahttps://www.paulstra-industry.com Dans la même idée : https://www.mecanocaucho.com/fr-FR/ Bonne fin de journée -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] L'étrange licensing des ASR1001X
Salut, J'ai deux cas d'ASR1001-X activés 20G + carte SPA pour avoir un troisième port 10G. Voici le contenu pour info (avec chiffrement): Cisco ASR1001-X Chassis, 6 built-in GE, Dual P/S, 8GB DRAM (ASR1001-X) Cisco ASR 1000 Advanced Enterprise Services License (SLASR1-AES) IPSEC License for ASR1000 Series (FLSASR1-IPSEC) 2.5G to 20Gbps upgrade License for ASR 1001-X, Built-in 2x10 (FLSA1-1X-2.5-20G) Cisco 1-Port 10GE LAN-PHY Shared Port Adapter (SPA-1X10GE-L-V2) Évidemment, ce contenu active bien le débit 20G : Index 31 Feature: throughput_20g Period left: Life time License Type: Permanent License State: Active, In Use License Count: Non-Counted License Priority: Medium Pour ton bundle ASR1001X-20G-K9, c'est vrai que vu de ce document, ça parait incroyable que ça n'inclut pas le débit 20G : https://www.cisco.com/c/en/us/products/collateral/routers/asr-1000-series-aggregation-services-routers/guide-c07-731639.html Si on fait le parallèle avec le 1002-X, il manquerait la ligne "Performance Upgrade License: FLSA1-1X-2.5-20G" dans ce qui est inclus.... Bon courage -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Question résolution DNS ... particulière ...
Bonjour, Le 09/04/2020 à 10:35, Pierrick CHOVELON a écrit : - Ajouter un sous-domaine en interne pour accéder à ces applications -> mais gestion de deux certificats côté appli - Récupérer les infos sur le DNS client avec une délégation -> mais se pose le problème du NAT ça parait être le plus simple. Dans le cas où vous avez un NAT entre vous, il faudrait que le serveur faisant autorité côté client vous renvoie des enregistrements adaptés (depuis une zone différenciée du même domaine interne donc soit un serveur dédié, soit une gestion de vue). sinon j'ai jamais testé (et ça fait pas rêver) mais certains pare-feux proposent un truc appelé "DNS doctoring" basé sur l'inspection DNS. En gros, si une IP est concernée par du NAT, le pare-feu modifie la réponse DNS : - Cisco ASA : https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/115753-dns-doctoring-asa-config.html - Juniper SRX : https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-dns-algs.html#id-understanding-dns-and-ddns-doctoring - Déporter la résolution DNS chez le client en utilisant un proxy web configuré au même endroit que l'appli -> très contraignant à l'utilisation - Rester sur la modif de notre fichier /etc/hosts à la main ... ... ... Quitte à maintenir des entrées manuellement alors autant déclarer une zone pour le domaine client sur un serveur faisant autorité de votre côté (avec copie sur vos resolvers ou forward) et maintenir le mapping pour les cas où il y a du NAT, non ? Bonne journée -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Question résolution DNS ... particulière ...
Bonjour, Le 14/04/2020 à 09:08, Pierrick CHOVELON a écrit : -> 1 master avec plusieurs slaves qui partagerait une VIP histoire d'avoir de la redondances ? Déjà dit par Phil Regnauld, une unique VIP sur un service DNS faisant autorité , c'est plutôt des contraintes inutiles à mon sens aussi. -> 1 seul master avec 1 seul slave ? oui par exemple (ou 1 master + n slaves sur n préfixes différents) ou un outil qui génère le contenu de la zone et le pousse directement sur tous les serveurs... Si j'ai bien compris, ce serait une zone à visibilité purement interne de votre entité (pour modifier les entrées de celles proposées par le client). Dans ce cas, la répartition multi-préfixes / AS parait moins critique mais ça reste nécessaire de cibler des infra différenciées pour avoir de la résilience... -> Faut-il plutôt gérer une zone/*domaine.fr <http://domaine.fr>*/ ou plutôt à chaque fois gérer la zone spéfifique /*application.domaine.fr <http://application.domaine.fr>*/ ? J'aurai tendance à dire la première. C'est ce que j'ai fait sur mes tests : j'arrivais à résoudre /application.domaine.fr <http://application.domaine.fr>/ mais pas /domain.fr <http://domain.fr>/. Probablement une mauvaise conf. Je dirai que ça dépend si tout le contenu de domaine.fr est à visibilité interne uniquement ou si des enregistrements restent publics. ça peut devenir ingérable d'avoir à faire le tri entre les enregistrements gérés par le client et d'autres par votre instance. Il vaut mieux cibler au plus restreint possible selon le cas. Comment ce sera géré sur les resolvers ? ils seront slaves ? ou utiliseront-ils un forward ? -> Des outils pour gérer tous les fichiers de zones ? Des astuces pour rendre cette gestion le plus logique/simple possible ? PowerAdmin (ou phpIPAM par exemple) + PowerDNS pour gérer le SOA et alimenter le master Bind ? ou plus simple une gestion de fichiers plat de zones orchestrée via puppet ou ansible par exemple ? Bon courage -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: Routage inter-vrf Cisco
Bonjour, Le 12/04/2020 à 23:09, Quentin Leconte via frnog a écrit : C'est ça, et mes VLAN en question ont chacun une VRF à eux. C'est bien le Cisco qui fera le NAT. 1 vlan = 1 vrf = 1 ip publique à bridger sur le WAN (dont l'interface physique n'est dans aucune VRF). Chaque IP publique appartient au même préfixe ? qui est celui de l'interco WAN ? -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Question résolution DNS ... particulière ...
Bonjour, Le 15/04/2020 à 13:45, Stephane Bortzmeyer a écrit : Pourquoi un outil spécifique alors que cette fonction est dans tous les serveurs DNS depuis toujours, et est normalisée <https://www.bortzmeyer.org/5936.html> ? ça reste juste une possibilité. On est d'accord que le transfert de zone fait le travail parfaitement. -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Question résolution DNS ... particulière ...
Le 15/04/2020 à 13:46, Stephane Bortzmeyer a écrit : On Wed, Apr 15, 2020 at 08:51:19AM +0200, Pierrick CHOVELON wrote a message of 21 lines which said: Je ne sais pas encore en ce qui concerne les résolveurs. Faut-il mieux avoir un slave/resolver ou alors bien distinguer les deux ? Distinguer <https://www.bortzmeyer.org/separer-resolveur-autorite.html> S'il faut que les resolvers puissent résoudre uniquement certains sous-domaines (pour tenir compte de l'application du NAT) mais par défaut , puissent interroger la zone domaine.fr publique, il y aurait au moins deux pistes sur Bind : 1) assigner chaque sous-domaine "xxx.domaine.fr" (de manière exhaustive) à une zone type forward pointant vers les serveurs faisant autorité en interne avec la directive "forward only" 2) assigner le domaine complet "domaine.fr" à une zone type forward pointant vers les serveurs faisant autorité en interne mais avec la directive "forward first" (par défaut a priori) pour initier une résolution récursive classique sur non réponse La méthode 1 limite le renvoi aux domaines listés. La méthode 2 renvoie par défaut les requêtes concernant "domaine.fr" mais déclenche une requête récursive si pas de réponse fournie. Le mix des deux doit fonctionner mais n'a pas trop d'intérêt a priori. Je n'ai pas testé. :-) -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] vmware, firewall dmz
Bonjour, Le 11/05/2020 à 15:20, Jerome Lien a écrit : Actuellement nous avons plusieurs dmz, avec des vlan's, le tout passant par un fortigate physique ... mais il faut avouer que remonter les vlan à chaque fois, fortigate..., switch, vswitch ... c'est plutôt fatiguant. Oui mais ça traite les bonnes fonctions sur un équipement qui le fait bien. Du coups, on réfléchi à monter un firewall en VM, par exemple un pfsense, opnsense pour gérer ces mini dmz et n'avoir qu'un lien propre vers l’extérieur. Si ça reste de la segmentation par vlan / préfixe, je ne comprend pas en quoi s'appuyer sur un firewall en VM va améliorer la situation. ça a l'air même pire puisque ça crée du steering entre hyperviseurs. Il faut gérer le HA donc deux VMs... Bref, ça déplace le problème. A la rigueur dans l'univers VMWare, NSX aurait un intérêt dans ce cas en faisant de la microsegmentation. Un seul vlan / préfixe + NSX qui gère la segmentation par VM au niveau de l'hyperviseur, ça ressemble à ce qui est recherché. Par contre, en dehors , de cas récurrents (pour faire de la masse), c'est plutôt très chiant à gérer pour des flux très hétérogènes (du moins de que j'en ai vu lors d'un POC qui date de 3 ans maintenant...). Bonne fin de journée -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !
Bonjour, Le 16/05/2020 à 11:37, Sébastien 65 a écrit : Pourquoi le ping depuis le CPE ne passe pas la class OTHER_TRAFFIC ou bien class class-default ? Parce qu'il faut lui appliquer une politique locale "ip local policy route-map map-tag " : https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/15-mt/iri-15-mt-book/iri-pbr.html#GUID-0BE1EBC5-C95F-43BE-92D1-0A341D6208A4 Bonne journée -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Policy-map output CISCO qui me rend fou !
Le 18/05/2020 à 09:36, Jérôme BERTHIER via frnog a écrit : Bonjour, Le 16/05/2020 à 11:37, Sébastien 65 a écrit : Pourquoi le ping depuis le CPE ne passe pas la class OTHER_TRAFFIC ou bien class class-default ? Parce qu'il faut lui appliquer une politique locale "ip local policy route-map map-tag " : https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/15-mt/iri-15-mt-book/iri-pbr.html#GUID-0BE1EBC5-C95F-43BE-92D1-0A341D6208A4 Bonne journée Oups j'ai fait un magnifique HS, désolé. ça marche pour du PBR, pas du marking COS Je vais reboire un café. Bonne journée -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] SW_DAI-4-PACKET_RATE_EXCEEDED CISCO
Salut, Le 21/05/2020 à 08:50, Sébastien 65 a écrit : Bonjour à tous, Sur un switch j'ai activé Dynamic ARP Inspection, je me retrouve de temps en temps le port UPLINK en err-disable state. Le port Gi0/1 est connecté en cascade sur différent switch du LAN qui n'ont pas de mécanisme DAI. Du coup, la logique m'échappe. Le spoofing peut avoir lieu sur n'importe quel switch aval dans ce cas. Tu sécurises quoi via ce port Gi0/1 ? Juste vérifier les correspondances MAC-IP via l'inspection DHCP snooping en parallèle ? En théorie, les ports vers d'autres devices (attendus exécutant DAI) sont à l'état trust donc il n'y a pas d'inspection (donc pas de rate limiting nécessaire). Le switch qui passe en err-disable est ensuite banché sur le routeur, le switch me permet de faire du "ménage" AVANT de passer sur le routeur... J'utilise ip arp inspection validate src-mac dst-mac ip + ip arp inspection filter *Mar 3 14:53:28.473: %SW_DAI-4-PACKET_RATE_EXCEEDED: 18 packets received in 16 milliseconds on Gi0/1. *Mar 3 14:53:28.473: %PM-4-ERR_DISABLE: arp-inspection error detected on Gi0/1, putting Gi0/1 in err-disable state *Mar 3 14:53:29.513: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down *Mar 3 14:53:30.553: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down En regardant un peux les valeurs par défaut, je constate que CISCO fixe ip arp inspection limit rate à 15 pps. Je ne sais pas comment définir cette valeur à part de faire au pifomètre ou d'utiliser ip arp inspection limit none sur Gi0/1... Si quelqu'un peut m'expliquer la méthode je suis preneur 🙂 Je ne connais pas de méthode officielle mais je tenterai un doublement de valeur jusqu'à que le défaut ne revienne plus. Ou alors plus fin, tu captures le trafic pour te faire une idée du seuil atteint mais bon, comme tous les seuils, ça va forcément devenir faux au bout d'un moment... Bonne journée Merci --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] SW_DAI-4-PACKET_RATE_EXCEEDED CISCO
Salut, Le 25/05/2020 à 20:12, Sébastien 65 a écrit : Salut Jérôme, Tu sécurises quoi via ce port Gi0/1 ? Valider que les @MAC/IP d'un VLAN sont bien celle qui doivent discuter avec le routeur ! OK mais ça laisse quand même la possibilité d'usurper une adresse MAC en aval, non ? Du coup, le filtrage concentré sur ce port là devient possible à contourner (car si je comprend bien, tout le trafic L2 se concentre sur ce port). Juste vérifier les correspondances MAC-IP via l'inspection DHCP snooping en parallèle ? Oui, j'ai des access-list ARP qui autorise sur un VLAN un couple d'@ IP/MAC. Je n'ai pas de service DHCP qui tourne sur ce réseau. ! arp access-list VLAN_101_ARP permit ip host 10.0.1.1 mac host cc2d.e0b2.6f1c permit ip host 10.0.1.2 mac host 7c69.f617.8e82 ! Je ne connais pas de méthode officielle mais je tenterai un doublement de valeur jusqu'à que le défaut ne revienne plus. C'est quitte ou double et j'aime pas du tout... Tu vas être tranquille pendant un certain temps et le jours ou il y aura plus de monde ça va merder et hop port down ! Associé à un recovery auto de 30s + une analyse de logs , ça doit permettre d'être assez réactif. La tranquillité du rate à none expose la CPU du switch donc c'est un peu sans filet si problème. J'aurais tendance à l'éviter. Bonne journée Bonne soirée ! ____ De : frnog-requ...@frnog.org de la part de Jérôme BERTHIER via frnog Envoyé : lundi 25 mai 2020 09:51 À : frnog@frnog.org Objet : Re: [FRnOG] [TECH] SW_DAI-4-PACKET_RATE_EXCEEDED CISCO Salut, Le 21/05/2020 à 08:50, Sébastien 65 a écrit : Bonjour à tous, Sur un switch j'ai activé Dynamic ARP Inspection, je me retrouve de temps en temps le port UPLINK en err-disable state. Le port Gi0/1 est connecté en cascade sur différent switch du LAN qui n'ont pas de mécanisme DAI. Du coup, la logique m'échappe. Le spoofing peut avoir lieu sur n'importe quel switch aval dans ce cas. Tu sécurises quoi via ce port Gi0/1 ? Juste vérifier les correspondances MAC-IP via l'inspection DHCP snooping en parallèle ? En théorie, les ports vers d'autres devices (attendus exécutant DAI) sont à l'état trust donc il n'y a pas d'inspection (donc pas de rate limiting nécessaire). Le switch qui passe en err-disable est ensuite banché sur le routeur, le switch me permet de faire du "ménage" AVANT de passer sur le routeur... J'utilise ip arp inspection validate src-mac dst-mac ip + ip arp inspection filter *Mar 3 14:53:28.473: %SW_DAI-4-PACKET_RATE_EXCEEDED: 18 packets received in 16 milliseconds on Gi0/1. *Mar 3 14:53:28.473: %PM-4-ERR_DISABLE: arp-inspection error detected on Gi0/1, putting Gi0/1 in err-disable state *Mar 3 14:53:29.513: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down *Mar 3 14:53:30.553: %LINK-3-UPDOWN: Interface GigabitEthernet0/1, changed state to down En regardant un peux les valeurs par défaut, je constate que CISCO fixe ip arp inspection limit rate à 15 pps. Je ne sais pas comment définir cette valeur à part de faire au pifomètre ou d'utiliser ip arp inspection limit none sur Gi0/1... Si quelqu'un peut m'expliquer la méthode je suis preneur 🙂 Je ne connais pas de méthode officielle mais je tenterai un doublement de valeur jusqu'à que le défaut ne revienne plus. Ou alors plus fin, tu captures le trafic pour te faire une idée du seuil atteint mais bon, comme tous les seuils, ça va forcément devenir faux au bout d'un moment... Bonne journée Merci --- Liste de diffusion du FRnOG https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F&data=02%7C01%7C%7Cc4625a445bd64bc1ef3008d8008087ab%7C84df9e7fe9f640afb435%7C1%7C0%7C637259899310184386&sdata=V3fmq%2FhXshiALZ6phOVljy81cqWZeJapXnKv4%2B14Vcw%3D&reserved=0 -- Jérôme BERTHIER --- Liste de diffusion du FRnOG https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.frnog.org%2F&data=02%7C01%7C%7Cc4625a445bd64bc1ef3008d8008087ab%7C84df9e7fe9f640afb435%7C1%7C0%7C637259899310184386&sdata=V3fmq%2FhXshiALZ6phOVljy81cqWZeJapXnKv4%2B14Vcw%3D&reserved=0 --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Une tribune pour vous inviter à suivre un site intéressant…
Le 22/08/2020 à 17:22, Jérôme Nicolle a écrit : Plop, Datacenter Magazine vient de publier une ébauche de retour d'expérience que j'ai commencé à travailler en début d'été. Vous pouvez lire le texte là : https://datacenter-magazine.fr/tribune-la-cyber-bombe-a-retardement-pourrait-etre-pire-que-la-crise-sanitaire/ Je vous invites à parcourir le site, leurs publications passées, il y a plein de choses intéressantes dedans. @+ Bonjour, "Mais sincèrement, s’était-on déjà ‘vraiment’ posé la question de ce qu’une crise sanitaire telle que décrite dans des films comme “Contagion” (2011) ou “28 days later” (2002) pourrait avoir comme conséquence sur nos systèmes d’information ?" Pas de zombies en mode furie qui courent aussi vite qu'Usain Bolt mais il y avait eu une vague invitation à y réfléchir avec l'aventure H1N1 en 2009. On trouve des restes de recommandations de l'époque : https://travail-emploi.gouv.fr/IMG/pdf/DP_PCA_ASIEM_Journalistes.pdf http://www.ariege.cci.fr/files/cci09/prevenir_les_difficultes/kitgrippeAentreprise.pdf Même si tu as l'infra et les licences VPN, tu n'as pas forcément les terminaux, les casques... et surtout pas les habitudes chez tous les utilisateurs. Oui, le SaaS, ça a une limite aussi. Je pense que certains DSI ont peut être regretté de ne pas avoir gardé sur un peu de sur-capacité "on premise" (en défendant les coûts associés)... C'est un peu comme quand tu comptes uniquement sur des masques ou des médicaments fabriqués en Asie... A la fin, il reste les IT heroes d'un jour que l'on oubliera aussi vite que les soignants... A+ -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper, JTAC et EX4300 sont dans un bateau
Salut, Le 02/11/2020 à 14:14, Maxime De Berraly a écrit : est ce que cette liste est uniquement "bug report driven"? Clairement, je pense que c'est ça. Il suffit de voir les aller-retour de recommandations qu'ils font parfois. Mon impression est qu'ils statuent sur un niveau d'emmerdement minimum (ce qui explique la position conservatrice dans les branches choisies). En même temps, quand on cherche la stabilité, c'est ce qu'il faut. :) Bon courage -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Fortinet augmentation tarif
Le 05/07/2022 à 18:55, David Ponzone a écrit : Aux partenaires Forti, Vous avez remarqué l’augmentation tarifaire de fou sur les licences depuis 12 mois, surtout sur le FG201F ? J’essaie de savoir d’où vient ce délire, dur d’avoir des réponses. C’est peut-être le moment de chercher une alternative, parce que 40%, c’est pas de l’inflation. David --- Liste de diffusion du FRnOG http://www.frnog.org/ C'est marrant à chaque fois que je parle avec Fortinet, ils me racontent que y a pas de licences chez eux, que toutes les fonctionnalités du boîtier sont utilisables directement. 😁 En tout cas, l'augmentation monstrueuse est vraie chez d'autres constructeurs. Tu sais celui où tu dois payer pour débloquer une limite de débit ou avoir le droit de faire de l'IPSEC (alors que tout ceci est déjà embarqué sur le routeur...). Licence "pour le niveau de service OS qui t'intéresse" +70% sur un an Licence IPSEC +150% sur un an C'est absolument du racket y compris sur les maintenances. Ils rattrapent leur marge, c'est tout. Moins de matos vendus et délivrés, coûts de fabrication en hausse donc ils lissent le manque à gagner entre le hardware et licensing. Et au passage, je pense qu'ils se font peut être plaisir. Faudra pas qu'ils s'étonnent si leurs clients changent de stratégie... -- Jérôme Berthier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Recherche solution "PCAP -> IPFIX/NETFLOW"
Le 06/01/2023 à 17:54, sbu sbu a écrit : Bonjour, Je suis à la recherche d'une solution qui saurait prendre du PCAP en entrée (10 x TAP optique 10G mono et multi) et le convertir en Flow. pour l'envoyer vers un seul puits de stats. J'ai bien pensé à prendre des switch mais ceux que j'ai, ont besoin d'une licence pour le flow, que je n'ai pas, qui coûte un bras. Et je ne suis même pas certain de pouvoir récupérer le flux des Tap et le NetFlowiser. En gros l'idéal serait des Gigamon lite pour ceux qui connaissent, sans les fonctions des flux metadata et pour beaucoup mon cher. Pour info ce constructeur me propal plus de 200k€ sur 3 ans (achat + support de 2 boites)... (volume de data 10G en burste sur l'aggregation des 10 points de collecte) Si quelqu'un à déjà utilisé d'autre techno basique ou on intervient uniquement sur l'échantillonnage. Solution hardware, boîtier matriciel comme les Gigamon ou single ou même une solution software qui fonctionne, je suis preneur du retour d'expérience. cdt SBU --- Liste de diffusion du FRnOG http://www.frnog.org/ Bonjour, Il me semble que nProbe et son évolution cento font ça chez ntop : https://www.ntop.org/products/netflow/nprobe/ https://www.ntop.org/products/netflow/nprobe-cento/ Bonne journée -- Jérôme Berthier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] http SD* et cisco CVE-2023-20198
Le 19/10/2023 à 08:13, jehan procaccia INT a écrit : Je m'interroge sur l'usage des interfaces [web|API|SD*] prônées par les constructeurs n'est-ce pas une exposition supplementaires majeure ? Ces outils (chez cisco DNA/Catalyst-center, SD-Acces/Wan ...) utilisent-ils le service http/https ? cf le CVE en cours qui semble faire de serieux degats : https://www.it-connect.fr/cyberattaque-plus-de-34-000-equipements-cisco-pirates-avec-cette-nouvelle-faille-zero-day/ https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z https://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/ --- Liste de diffusion du FRnOG http://www.frnog.org/ Bonjour, Je pense qu'il ne faut pas mélanger. Cette faille concerne la WebUI de management des équipements IOS-XE. Elle est sensée ne pas être exposée n'importe comment (et même désactivée vu son peu d'utilité). Sur SD-WAN, l'onboarding est fait de l'équipement (cEdge, vEdge) vers l'orchestrateur vBond (Validator) puis un contrôleur vSmart et le vManager sont découverts et le device s'y connecte. A mon avis, s'il y a connexion entrante, elle est ensuite limitée aux contrôleurs (DTLS/OMP) et managers (SSH/NETCONF) validés et enrôlés par certificat. ça se passe sur des ports dédiés. Toutefois, ce mécanisme reste faillible puisque là le point d'exposition est côté vBond Orchestrator (Validator exposé complètement pour recevoir l'onboarding et faire l'aiguillage) ou vSmart/vManage. Ils ont déjà eu leurs lots de failles critiques. Pour SD-Access, à mon sens, c'est plus classique. DNA Center va venir découvrir les équipements en SNMP, SSH. Il y a sûrement aussi du ZTP possible (pas vérifié). Bref, tout logiciel reste faillible donc quand tu exposes des points de découverte centralisée, ça peut forcément mal se passer. -- Jérôme Berthier --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE
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/
Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE
Le 13/01/2024 à 16:32, Jérôme Berthier via frnog a écrit : 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é ?? OK je pense avoir trouvé pour ce point. Après avoir personnalisé le portail en activant l'authentification par voucher, un menu apparaît pour gérer les comptes. C'est très rudimentaire. -- Jérôme Berthier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] UniFi - pilotage bornes légères UAP-AC-LITE
Le 14/01/2024 à 11:22, Paul Rolland (ポール・ロラン) a écrit : 5) y a des gateway qui intègrent UniFi Console qui permet d'instancier UniFi Network Server ou de joindre le cloud UI Oui. Ca peut d'ailleurs te permettre de recuperer une fonction "routeur" (et donc la partie DHCP). Dans ta liste de materiel, tu as liste un switch et les AP, mais pas de routeur... je suppose que tu prends celui qui vient avec l'acces Internet ? oui j'ai pas parlé de la partie routeur car par défaut, le gestionnaire pensait utiliser sa livebox. Je lui ai exposé les limites de ça. Je pense qu'il a capté pourquoi ce serait utile de cloisonner un peu les usages. IMHO, il te faut, pour etre bien: - un switch PoE, qui te fera l'alim de tes bornes. Et si il est Unifi, tu le geres avec le reste dans ta console, genre le Lite 16PoE, qui te fait 16 ports, dont 8 avec PoE+, ce qui couvre tes 5 APs - une console on-site, qui te fera la brique "controleur", le DHCP, ... OK grâce à vos différents retours, on a levé mes doutes sur l’enrôlement des bornes. Y a pas vraiment de contrôleur, c'est plutôt un manager. Chose plutôt pas mal, on peut remonter cette console locale dans le cloud UI, ce qui donne une vue distante de l'installation. ;) On est rendu entre 6 et 8 APs selon les positionnements finaux (contraintes de pose). Elles sont POE standard, pas besoin de plus. Par contre, me faut un switch qui peut gérer quelques vlans. On va donc effectivement ajouter une passerelle intermédiaire derrière sa box. Au delà de la segmentation et adressage clients, je suppose que ça assure aussi la traçabilité des sessions IP ? et que ça remonte les logs dans la console ? Pour la partie hotspot, c'est simpliste mais ça fait le job. Si en plus la passerelle fait l'accounting IP, ce sera parfait en terme de traçabilité. Merci à tous pour les différents retours -- Jérôme Berthier --- Liste de diffusion du FRnOG http://www.frnog.org/
