Re: [FRnOG] [MISC] DSP 59
Le 23/07/2015 21:15, Clement Cavadore a écrit : On Thu, 2015-07-23 at 21:13 +0200, David Ponzone wrote: Woman ? Je kif! C'est quoi comme protocole ? Un truc incompréhensible, aux instabilités et réactions aléatoires chroniques :-)) Je dirais plutôt un MUST pour ton réseau local. A installer dans ton cœur de réseau pour contrebalancer le maleware ambiant. Fred --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] RFC 7608: IPv6 Prefix Length Recommendation for Forwarding
http://www.bortzmeyer.org/7608.html Auteur(s) du RFC: M. Boucadair (France Telecom), A. Petrescu (CEA, LIST), F. Baker (Cisco Systems) Comme IPv4, IPv6 route les paquets en fonction d'un préfixe d'adresses, préfixe qui a une longueur comprise entre 0 (tout l'Internet) et 128 bits (une seule machine). Ce très court RFC a juste pour but de rappeler cette règle : la longueur d'un préfixe est quelconque, les mises en œuvres de IPv6, logicielles ou matérielles, ne doivent pas imposer ou favoriser une longueur de préfixe particulière (même pas 64, souvent considéré, à tort, comme spécial). Le routage se fait exclusivement sur le plus long préfixe, quelle que soit sa longueur. Il est normal qu'IPv6 et IPv4 fassent pareil, ce sont après tout deux versions du même protocole. IPv4 utilisait autrefois http://www.bortzmeyer.org/fini-les-classes.html un système différent mais, depuis CIDR, il suit les mêmes règles qu'IPv6 : le routage se fait sur la base d'un préfixe d'adresses de longueur quelconque. C'est le préfixe le plus long qui est choisi. Ainsi, pour prendre un exemple IPv4, si la destination est 203.0.113.51 et qu'il existe deux routes possibles, une vers le préfixe 203.0.113.0/26 (longueur 26 bits) et l'autre vers le préfixe 203.0.0.0/18, c'est la première, la plus spécifique (le préfixe le plus long) qui gagne. En IPv6, si on veut envoyer un paquet à 2001:db8:440:fe::25a:9ff et qu'il existe deux routes possibles, 2001:db8:440:fe::/80 (longueur 80 bits) et 2001:db8:440::/48, c'est la première qui est choisie. Le routage sur la base du préfixe le plus long, un concept fondamental d'IP, c'est juste ça. (Le terme de CIDR, introduit par le RFC 1380 et décrit dans le RFC 4632, terme très spécifique à IPv4 et aujourd'hui dépassé techniquement depuis l'abandon de l'ancien système des classes, n'est pas utilisé pour IPv6.) Mais pas mal de gens qui ne connaissent pas bien IPv6 ont des idées fausses à ce sujet et croient, par exemple, que les préfixes de longueur 64 bits ont un rôle particulier pour le routage, voire que les préfixes comme le /80 donné en exemple plus haut sont illégaux. Le RFC 4291, qui normalise l'adressage IPv6, dit bien (dans sa section 2.5) que n'importe quelle longueur de préfixe (« arbitrary bit-length ») est possible. Mais c'est vrai que la confusion peut venir du rôle particulier de certaines longueurs, notamment 64, dans d'autres utilisations que le routage. Ainsi, le RFC 7421 note que les préfixes plus longs que 64 bits ont des problèmes pour certaines utilisations, comme le SLAAC. Mais il s'agit là de questions liées à l'adressage : cela ne devrait pas affecter le routage, si on veut que les changements futurs de l'adressage n'empêchent pas les routeurs de fonctionner (deux exemples de changement d'adressage : au début d'IPv6, il était envisagé que ce soit /80 plutôt que /64 qui soit la longueur de préfixe « de référence » et, autre exemple, la recommendation pour les liens point à point a varié de /64 à /127, cf. RFC 6164). Donc, pour résumer, l'adressage est une chose (et les recommendations du RFC 7421, indiquant les avantages à utiliser du /64 pour un lien local, continuent à s'appliquer), le routage en est une autre : le routage IPv6 *doit* suivre l'algorithme du préfixe le plus long, et ne doit pas avoir de longueurs de préfixes privilégiées ou spéciales. Cette exigence est formalisée dans la section 2 de notre RFC : * Les routeurs IPv6 doivent suivre les règles de la section 5.1 du RFC 4632. * La transmission d'un paquet doit se faire sur la base du préfixe le plus long et toutes les longueurs sont également acceptables, même 128, même des valeurs qui ne sont pas un multiple de 8. Ces règles s'appliquent au code des routeurs : l'administrateur d'un routeur donné peut toujours avoir sa propre politique (par exemple, en BGP, ne pas accepter de préfixes plus longs que 48 bits) mais cela ne doit pas se retrouver dans le logiciel, autrement, les futures évolutions seraient sérieusement compliquées. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Corrélation de log/Event Log MGMT
Et Nagios Log Server ? Le 23 juil. 2015 à 12:17, Vincent Mercier vmerc...@gmail.com a écrit : Bonjour, Pour avoir déjà mis en place des infrastructures Splunk et ELK, les solutions ne sont pas du tout comparable. A mon sens, les solutions à base de ElasticSearch (Fluentd, Logstash, ...) avec une interface Kibana doivent être utilisé pour permettre/simplifier la consultation de log sur une interface web pour des équipes techniques. = Idéal pour des logs techniques qui ne nécessitent pas de gestion de droit d'accès, ni d'alerting ou de reporting Splunk est utilisé dans les entreprises en tant que solution d'exploitation de plateforme, de sécurité ou de Business Intelligence (BI), il est utilisé par les équipes techniques et les équipes métier. = Idéal pour être utilisé à l'échelle d'une entreprise : authentification centralisé, gestion de droit d'accès, plateforme mixte (Windows/Linux), multi-site, ... Quelques points sur ELK : - Pas de gestion de l'authentification dans Kibana (à faire avec un reverse proxy) - Changement complet du fonctionnement de Kibana entre la version 3 et la version 4 (l'interface web stateless (AngularJS) devient un serveur web/proxy à part entière!) - Debug de l'agent logstash forwarder franchement galère - Cluster Elasticsearch à configurer/entretenir - Pas de mécanisme de purge des données par défaut (les surprises arrivent après quelques mois d'utilisation...) - Choix à faire entre Logstash et Fluentd Quelques points sur Splunk : - Solution déployable par role (agent de collect, proxy, serveur de stockage, interface front) = Idéale pour des infrastructures avec des zones de sécurité (DMZ, interco, backend, ...) - Agent de collect réellement disponible pour Windows/Linux - Licence au volume de log collecté par jour (500 Mo gratuit) = ~$5.000 pour 1 Go de log par jour Les bonnes questions à se poser pour se type de projet : - Quels sont les tableaux de bord dont j'ai besoin ? - Est ce qu'il y a des données métiers ? - Qui va accéder aux données ? Est ce que j'ai besoin de limiter l'accès aux données ? - Quelle est la rétention des données souhaitées (ne pas oublier la granularité) ? - Est ce qu'il y a des contraintes au niveau de l'infrastructure réseau (zones de sécurité, multi-site, ...) ? On Wed, Jul 22, 2015 at 10:54 AM, Phil Regnauld regna...@x0.dk wrote: Guillaume Rose (guillaume.rose) writes: Étrangement, personne ne parle de Splunk ($$$). +1 pour ELK. Fluentd + Kibana. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
On Thu, 2015-07-23 at 18:32 +0200, jehan procaccia INT wrote: (...) où j'ai enfin un match entre l'adresse IP et une @MAC . = j'esperais trouver ça bcp plus facilement avec un 6509E#show arp | incl 192.168.1.101 mais curieusement, cela ne donne jamais rien , Normal, l'ARP est dans le cas ou le cisco fait du L3 sur ledit vlan. Vu que tu n'as pas de 192.168.1.x dans ton réseau, tu ne risques pas d'avoir d'ARP sur cette IP. meme #show mac address-table | incl 10:bd:18:e4:80:80 ne donne rien !? Essaye plutôt avec la MAC sous ce format: 10bd.18e4.8080 -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
Il serait peut-être temps de mettre des ACL ingress pour filtrer tout ce qui n’a rien à faire là (RFC1918, etc…), ou mieux: n’autoriser que ce qui doit arriver par l’interface en question si possible. Le 23 juil. 2015 à 18:32, jehan procaccia INT jehan.procac...@int-evry.fr a écrit : Le 23/07/2015 10:42, Clement Cavadore a écrit : 5) comment remonter et identifier la source du pb, probablement un PC/portable mal configuré infecté et qui se crois sur une livebox ou autre subnet home office !? Essaye de choper l'adresse MAC via ton port mirroring, et remonte le réseau L2 jusqu'à trouver le port de switch auquel cette MAC est rattachée ? Merci pour vos réponses je comprend mieux maintenant comment ce trafic peut-etre etre routé malgres mes efforts pour le dropper ! apres avoir remonté la source jusqu'a mon coeur de reseau (6500) grace au port miroring sur ASR (SPAN) cf http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/116212-configure-asr-00.html nouveau port miroring sur 6500 , cf http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41.html#anc45 j'ai du encore luter avec tcpdump car l'interface en question est un trunk et il a fallu jouer avec la prise en charge des vlan dans le filtre: # tcpdump -nnv -e udp or (vlan and (udp or tcp) and src net 192.168.0.0/22) -i em2 -w capture-g2-21-6509-2015-07-23-17H00-192.168.cap # tcpdump -nnve -r capture-g2-21-6509-2015-07-23-17H00-192.168.cap j'ai capturé donc ce genre de trame 17:17:12.612962 *10:bd:18:e4:80:80* 00:07:7d:33:9f:00, ethertype 802.1Q (0x8100), length 66: vlan 8, p 0, ethertype IPv4, (tos 0x0, ttl 116, id 11394, offset 0, flags [DF], proto TCP (6), length 48) *192.168.1.101*.3751 104.37.247.30.80: Flags [S], cksum 0x3f63 (correct), seq 2737270860, win 65535, options [mss 1460,nop,nop,sackOK], length 0 où j'ai enfin un match entre l'adresse IP et une @MAC . = j'esperais trouver ça bcp plus facilement avec un 6509E#show arp | incl 192.168.1.101 mais curieusement, cela ne donne jamais rien , meme #show mac address-table | incl 10:bd:18:e4:80:80 ne donne rien !? heureusement qu'il y a tcpdump a coté des équipements cisco ... Maintenant , il faut que je poursuive vers l'interface source de cette MAC , évidement c'est un downlink qui sort de mon LAN , derrière lequel je pas la main, je vais poursuivre avec l’enquête avec les admins de cette interco . Je reste quand meme surpris qu'un flood de paquets arrive a mettre a genoux un ASR1002 :-( ! on vois sur le graph en nombre de paquets ci-dessous les 2 periodes blanches ou mon routeur ne repondais quasiment plus (en tout cas au moins plus au requetes snmp sources de ce graph) ASR1002 - Unicast Packets - Gi0/0/2 Merci pour vos conseils . jehan . --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] DSP 59
Merci pour ce doc, ça fait peur…. Le 22 juil. 2015 à 08:41, Raphaël Jacquot sxp...@sxpert.org a écrit : On 07/21/2015 11:10 PM, David Ponzone wrote: Tous, quelqu’un sait s’il y a une DSP sur le 59, capable de faire du hertzien (plutôt Wimax, donc cheap) ? Je trouve rien pour le moment. Merci David d'apres http://www.arcep.fr/fileadmin/reprise/dossiers/blr/wimax/tableaux-cartes-wimax-050510.pdf il faut que tu ailles voir Altitude Wireless (groupe iliad) --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] DSP 59
D'autant que les données sont périmées. En Basse Normandie il y a eu déjà plusieurs pylônes decomissionnes ces dernières années. Dans l'Orne au plus fort du déploiement il n'y a eu que 500 sites raccordes et aujourd'hui ils doivent être quelques dizaine au plus toujours raccordé en woman Le 23 juil. 2015 à 19:00, David Ponzone david.ponz...@gmail.com a écrit : Merci pour ce doc, ça fait peur…. Le 22 juil. 2015 à 08:41, Raphaël Jacquot sxp...@sxpert.org a écrit : On 07/21/2015 11:10 PM, David Ponzone wrote: Tous, quelqu’un sait s’il y a une DSP sur le 59, capable de faire du hertzien (plutôt Wimax, donc cheap) ? Je trouve rien pour le moment. Merci David d'apres http://www.arcep.fr/fileadmin/reprise/dossiers/blr/wimax/tableaux-cartes-wimax-050510.pdf il faut que tu ailles voir Altitude Wireless (groupe iliad) --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] DSP 59
Woman ? Je kif! C'est quoi comme protocole ? :) David Ponzone Le 23 juil. 2015 à 21:08, Sebastien Lesimple slesim...@laposte.net a écrit : D'autant que les données sont périmées. En Basse Normandie il y a eu déjà plusieurs pylônes decomissionnes ces dernières années. Dans l'Orne au plus fort du déploiement il n'y a eu que 500 sites raccordes et aujourd'hui ils doivent être quelques dizaine au plus toujours raccordé en woman Le 23 juil. 2015 à 19:00, David Ponzone david.ponz...@gmail.com a écrit : Merci pour ce doc, ça fait peur…. Le 22 juil. 2015 à 08:41, Raphaël Jacquot sxp...@sxpert.org a écrit : On 07/21/2015 11:10 PM, David Ponzone wrote: Tous, quelqu’un sait s’il y a une DSP sur le 59, capable de faire du hertzien (plutôt Wimax, donc cheap) ? Je trouve rien pour le moment. Merci David d'apres http://www.arcep.fr/fileadmin/reprise/dossiers/blr/wimax/tableaux-cartes-wimax-050510.pdf il faut que tu ailles voir Altitude Wireless (groupe iliad) --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] DSP 59
On Thu, 2015-07-23 at 21:13 +0200, David Ponzone wrote: Woman ? Je kif! C'est quoi comme protocole ? Un truc incompréhensible, aux instabilités et réactions aléatoires chroniques :-)) (désolé on n'est pas encore vendredi, mais c'est tout comme... :p) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] DSP 59
N'empêche quand on voit le nombre sites déployé vs l'obligation de 2008... Je suis assez rêveur... --- 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 : 5) comment remonter et identifier la source du pb, probablement un PC/portable mal configuré infecté et qui se crois sur une livebox ou autre subnet home office !? Essaye de choper l'adresse MAC via ton port mirroring, et remonte le réseau L2 jusqu'à trouver le port de switch auquel cette MAC est rattachée ? Merci pour vos réponses je comprend mieux maintenant comment ce trafic peut-etre etre routé malgres mes efforts pour le dropper ! apres avoir remonté la source jusqu'a mon coeur de reseau (6500) grace au port miroring sur ASR (SPAN) cf http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/116212-configure-asr-00.html nouveau port miroring sur 6500 , cf http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/10570-41.html#anc45 j'ai du encore luter avec tcpdump car l'interface en question est un trunk et il a fallu jouer avec la prise en charge des vlan dans le filtre: # tcpdump -nnv -e udp or (vlan and (udp or tcp) and src net 192.168.0.0/22) -i em2 -w capture-g2-21-6509-2015-07-23-17H00-192.168.cap # tcpdump -nnve -r capture-g2-21-6509-2015-07-23-17H00-192.168.cap j'ai capturé donc ce genre de trame 17:17:12.612962 *10:bd:18:e4:80:80* 00:07:7d:33:9f:00, ethertype 802.1Q (0x8100), length 66: vlan 8, p 0, ethertype IPv4, (tos 0x0, ttl 116, id 11394, offset 0, flags [DF], proto TCP (6), length 48) *192.168.1.101*.3751 104.37.247.30.80: Flags [S], cksum 0x3f63 (correct), seq 2737270860, win 65535, options [mss 1460,nop,nop,sackOK], length 0 où j'ai enfin un match entre l'adresse IP et une @MAC . = j'esperais trouver ça bcp plus facilement avec un 6509E#show arp | incl 192.168.1.101 mais curieusement, cela ne donne jamais rien , meme #show mac address-table | incl 10:bd:18:e4:80:80 ne donne rien !? heureusement qu'il y a tcpdump a coté des équipements cisco ... Maintenant , il faut que je poursuive vers l'interface source de cette MAC , évidement c'est un downlink qui sort de mon LAN , derrière lequel je pas la main, je vais poursuivre avec l’enquête avec les admins de cette interco . Je reste quand meme surpris qu'un flood de paquets arrive a mettre a genoux un ASR1002 :-( ! on vois sur le graph en nombre de paquets ci-dessous les 2 periodes blanches ou mon routeur ne repondais quasiment plus (en tout cas au moins plus au requetes snmp sources de ce graph) ASR1002 - Unicast Packets - Gi0/0/2 Merci pour vos conseils . jehan . --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Du matos à liquider
Bonjour François, Auriez-vous une photo des armoires pour voir à peu près le matériel qui est à reprendre ? Bien cordialement, Harold Sauvage 0678109109 N.I.S.C - Mail original - De: Francois A. n...@heimdall.net À: frnog-...@frnog.org Envoyé: Mercredi 22 Juillet 2015 23:02:15 Objet: [FRnOG] [BIZ] Du matos à liquider Bonsoir à tous pour diverses raisons, je me sépare de quasi tout mon matériel serveurs et réseaux. J'ai l'équivalent de deux baies complètes (ptete un poil plus) de serveurs, switchs, fw, carcasse. Il y a de tout en terme de puissance (du P3 - sisi - au xeon 54xx), 1U, 2U, 4U, du Cisco, du Netapp ... Je fournis également un stock de composant divers (Ram, DD en 21/2 ou 31/2 SATA/SAS/SCSI beaucoup avec chassis HP, CPU, ..., plateaux 19, ...) Même un quart de baie dispo (en sus) Bref un joli stock. Vu la quantité et la diversité, je n'ai pas trop envie de passer du temps à faire à la pièce (voire la pièce détachée) donc je cède le lot d'un coup. Je peux livrer en IdF si on s'arrange. Vu le paquet, comptez dans les 4000€. Pour info, un broker qui aurait le temps de détailler s'en sortirait à bien plus au tarif occase (surtout vu toutes les pièces détachées dispo en plus). Bref, à voir en privé au besoin. Possibilité de lettre de session sur demande. Bonne soirée à tous. -- *Francois Aichelbaum* CTO Fondateur http://www.heimdall.net/ 06.87.96.06.79 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- 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] Corrélation de log/Event Log MGMT
Bonjour, Pour avoir déjà mis en place des infrastructures Splunk et ELK, les solutions ne sont pas du tout comparable. A mon sens, les solutions à base de ElasticSearch (Fluentd, Logstash, ...) avec une interface Kibana doivent être utilisé pour permettre/simplifier la consultation de log sur une interface web pour des équipes techniques. = Idéal pour des logs techniques qui ne nécessitent pas de gestion de droit d'accès, ni d'alerting ou de reporting Splunk est utilisé dans les entreprises en tant que solution d'exploitation de plateforme, de sécurité ou de Business Intelligence (BI), il est utilisé par les équipes techniques et les équipes métier. = Idéal pour être utilisé à l'échelle d'une entreprise : authentification centralisé, gestion de droit d'accès, plateforme mixte (Windows/Linux), multi-site, ... Quelques points sur ELK : - Pas de gestion de l'authentification dans Kibana (à faire avec un reverse proxy) - Changement complet du fonctionnement de Kibana entre la version 3 et la version 4 (l'interface web stateless (AngularJS) devient un serveur web/proxy à part entière!) - Debug de l'agent logstash forwarder franchement galère - Cluster Elasticsearch à configurer/entretenir - Pas de mécanisme de purge des données par défaut (les surprises arrivent après quelques mois d'utilisation...) - Choix à faire entre Logstash et Fluentd Quelques points sur Splunk : - Solution déployable par role (agent de collect, proxy, serveur de stockage, interface front) = Idéale pour des infrastructures avec des zones de sécurité (DMZ, interco, backend, ...) - Agent de collect réellement disponible pour Windows/Linux - Licence au volume de log collecté par jour (500 Mo gratuit) = ~$5.000 pour 1 Go de log par jour Les bonnes questions à se poser pour se type de projet : - Quels sont les tableaux de bord dont j'ai besoin ? - Est ce qu'il y a des données métiers ? - Qui va accéder aux données ? Est ce que j'ai besoin de limiter l'accès aux données ? - Quelle est la rétention des données souhaitées (ne pas oublier la granularité) ? - Est ce qu'il y a des contraintes au niveau de l'infrastructure réseau (zones de sécurité, multi-site, ...) ? On Wed, Jul 22, 2015 at 10:54 AM, Phil Regnauld regna...@x0.dk wrote: Guillaume Rose (guillaume.rose) writes: Étrangement, personne ne parle de Splunk ($$$). +1 pour ELK. Fluentd + Kibana. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- 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 Thu, Jul 23, 2015 at 10:17:48AM +0200, jehan procaccia INT [jehan.procac...@int-evry.fr] a écrit: [...] 2) j'ai en plus sur l'ASR une route statique qui renvoit 192.168.0.0 vers Null0 (trou noir) ip route 192.168.0.0 255.255.0.0 Null0 comment se fait-il qu'en plus de 1) j'ai encore ces paquets ayant pour src 192.168.1.101 renvoyés vers mon interface de sortie opérateur (ici g0/0/2) ? Parceque tes paquets ont pour source 192.168.1.101, pas comme destination. Ta route vers Null0 n'est donc pas du tout évalué. [...] 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 Idem, c'est l'ip *source*. Ta table de routage ne sert que fonction de la destination. [...] 5) comment remonter et identifier la source du pb, probablement un PC/portable mal configuré infecté et qui se crois sur une livebox ou autre subnet home office !? Oui, il faut comme tu as commencé à le faire, remonter d'équipement en équipement pour retrouver l'adresse MAC correspondante et le port de switch. -- Dominique Rousseau Neuronnexion, Prestataire Internet Intranet 21 rue Frédéric Petit - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
bonjour, je constate sur mon routeur Edge (type ASR 1002) de campus, un trafic illégitime (je suppose), par intermittence qui sature les performances du routeur (et/ou switch coeur de LAN en amont) et a pour fâcheux effet de bord de ralentir tous les trafics du campus . voici le genre de message que je reçois par centaines en qq secondes sur la console de l'ASR quand cela se produit: Jul 22 10:19:43 157.159.8.3 1852677: Jul 22 06:47:33.609: %IOSXE-3-PLATFORM: F0: cpp_cp: QFP:0.0 Thread:025 TS:00025904738204986240 %PKTLOG-3-PKTLOG_IPC_SEND_FAILED: IPv4 ACL log Tail Drop Jul 22 10:19:43 157.159.8.3 1852678: Jul 22 06:47:33.611: %FMANFP-6-IPACCESSLOGP: F0: fman_fp_image: list 112 denied tcp 192.168.1.101(1897) - 198.148.92.247(80), 1 packet Jul 22 10:19:43 157.159.8.3 1852679: Jul 22 06:47:33.611: %FMANFP-6-IPACCESSLOGP: F0: fman_fp_image: list 112 denied tcp 192.168.1.101(1836) - 198.148.92.247(80), 1 packet ... j'ai en effet une ACL en sortie de site qui interdit tout trafic RFC 1918 (ici précisément 192.168.0.0 0.0.255.255) vers any asr1-evry#show *access-lists 112* Extended IP access list 112 10 deny ip 192.168.0.0 0.0.255.255 any log (201942501 matches) 20 permit ip any any (3326764632 matches) interface GigabitEthernet0/0/2 ip *access-group 112 out* faute d'outils de capture de trafic intrinsec aux équipements réseaux :-( j'ai pu quand même mirrorer mon interface vers une autre et analyser a coup de tcpdump le trafic à la recherche de cette IP src 192.168.1.101 cf bon exemple de méthode sur ASR : http://www.cisco.com/c/en/us/support/docs/routers/asr-1000-series-aggregation-services-routers/116212-configure-asr-00.html ainsi j'ai retrouvé l'adresse MAC correpondante à l'IP 192.168.1.101 et grâce a cette MAC pu remonter au 6500 coeur de reseau du LAN en amont de cet ASR bref maintenant je pense avoir isoler le switch où la source aboutit. Questions : 1) je croyais que les @IP RFC1918 étaient par défaut non routées sur les équipements réseau !? je me trompe ? 2) j'ai en plus sur l'ASR une route statique qui renvoit 192.168.0.0 vers Null0 (trou noir) ip route 192.168.0.0 255.255.0.0 Null0 comment se fait-il qu'en plus de 1) j'ai encore ces paquets ayant pour src 192.168.1.101 renvoyés vers mon interface de sortie opérateur (ici g0/0/2) ? 3) avez vous une autre méthode (que mon ACL 112 et route statique vers Null0) pour droper ce trafic ? 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 seul un vlan dispose d'un subnet en 192.168*.0*.0/24 (!= 192.168*.1 *) 6509E#show ip route 192.168.0.0 Routing entry for 192.168.0.0/24, 2 known subnets Attached (2 connections) Variably subnetted with 2 masks Redistributing via ospf 1 C192.168.0.0/24 is directly connected, Vlan901 L192.168.0.2/32 is directly connected, Vlan901 5) comment remonter et identifier la source du pb, probablement un PC/portable mal configuré infecté et qui se crois sur une livebox ou autre subnet home office !? Merci . --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
Bonjour Jehan, On Thu, 2015-07-23 at 10:17 +0200, jehan procaccia INT wrote: Questions : 1) je croyais que les @IP RFC1918 étaient par défaut non routées sur les équipements réseau !? je me trompe ? En effet, tu te trompes: Elles sont totalement routables. Elles ne *devraient* pas être annoncées/routées sur Internet, c'est tout. Dans la pratique tu peux recevoir des annonces BGP ou du traffic en provenance d'IP RFC1918, pour peu que ce ne soit pas filtré par toi/tes upstreams. 2) j'ai en plus sur l'ASR une route statique qui renvoit 192.168.0.0 vers Null0 (trou noir) ip route 192.168.0.0 255.255.0.0 Null0 comment se fait-il qu'en plus de 1) j'ai encore ces paquets ayant pour src 192.168.1.101 renvoyés vers mon interface de sortie opérateur (ici g0/0/2) ? Ca par contre, c'est étrange. Es-tu sûr que la route statique est bien installée dans la FIB ? 3) avez vous une autre méthode (que mon ACL 112 et route statique vers Null0) pour droper ce trafic ? Une ACL en out sur l'équipement en face de ton Gi0/0/1 (j'imagine ?), le responsable du routage de ton RFC1918 ? Une ACL en in sur ta Gi0/0/2 n'autorisant que le(s) subnets qu'elles connait/est censée recevoir ? 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. seul un vlan dispose d'un subnet en 192.168*.0*.0/24 (!= 192.168*.1 *) 6509E#show ip route 192.168.0.0 Routing entry for 192.168.0.0/24, 2 known subnets Attached (2 connections) Variably subnetted with 2 masks Redistributing via ospf 1 C192.168.0.0/24 is directly connected, Vlan901 L192.168.0.2/32 is directly connected, Vlan901 5) comment remonter et identifier la source du pb, probablement un PC/portable mal configuré infecté et qui se crois sur une livebox ou autre subnet home office !? Essaye de choper l'adresse MAC via ton port mirroring, et remonte le réseau L2 jusqu'à trouver le port de switch auquel cette MAC est rattachée ? -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
On Thu, 2015-07-23 at 10:42 +0200, Clement Cavadore wrote: 2) j'ai en plus sur l'ASR une route statique qui renvoit 192.168.0.0 vers Null0 (trou noir) ip route 192.168.0.0 255.255.0.0 Null0 comment se fait-il qu'en plus de 1) j'ai encore ces paquets ayant pour src 192.168.1.101 renvoyés vers mon interface de sortie opérateur (ici g0/0/2) ? Ca par contre, c'est étrange. Es-tu sûr que la route statique est bien installée dans la FIB ? Mal réveillé. Café ! La nullroute ne concerne que les paquets à *destination* de 192.168.0.0/16, pas les paquets ayant une IP dans ce subnet en source. Donc ton paquet passe quand même :) -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
