Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
Encore une fois, je ne sais pas si c’est ta phrase qui est mal tournée, mais ce n’est pas parce que tu n’as pas de route vers un subnet que tu ne vas pas recevoir de paquets venant de ce subnet. Les routes définissent par où tu vas envoyer tes paquets vers cette IP (et donc tes réponses). Pour empêcher des paquets qui ont 192.168.1.101 comme source, il faut mettre un: ip access-list standard anti-mechants deny 10.0.0.0 0.255.255.255 deny 192.168.0.0 0.0.255.255 deny 172.16.0.0 0.15.255.255 permit any (http://www.cisco.com/c/en/us/support/docs/ip/access-lists/43920-iacl.html) et tu appliques ceci sur TOUTES tes interfaces INGRESS, donc toutes les interfaces sur lesquelles sont connectés des équipements que tu ne maitrises pas: -internet -clients -machines d’étudiants fous sous Windows ou geeks sous Linux D’ailleurs, sur les interfaces INGRESS internes (clients/utilisateurs) tu peux même être encore plus restrictif en autorisant seulement tes propres IP. Sur les INGRESS externes, tu peux en plus interdire tes propres IP. Désolé si je répète un truc déjà fait, mais j’ai eu un doute en te lisant. Le 29 juil. 2015 à 23:43, jehan procaccia IMT jehan.procac...@tem-tsp.eu a écrit : comment des paquets (forgés probablement) avec une src en 192.168.1.101 peuvent t-il aboutir sur mon coeur de reseau alors que je n'ai pas de gateway ni de route pour ce reseau 192.168.1.0/24 !? cela m’intéresse . --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
Tu parles de son système ? Mais il est root dessus, il fait ce qu’il veut. C’est quoi une gateway par défaut: c’est juste une IP vers laquelle la couche IP sait qu’elle doit envoyer le paquet, à défaut d’avoir une route plus spécifique. Elle cherche donc son adresse MAC pour la mettre en adresse destination du paquet ethernet dans lequel elle encapsule le paquet IP. Tu imagines donc bien que ce n’est pas très difficile à modifier. Sous Linux, c’est même encore plus trivial et ça peut être causé par un conf mal faite: ifconfig eth0 157.159.1.X netmask 255.255.255.0 ifconfig eth1 192.168.1.101 netmask 255.255.255.0 route add default gw 157.159.1.1 ping -s 192.168.1.101 157.159.1.1 Et ton 6500 va recevoir des paquets venant de 192.168.1.101 vers 157.159.1.1 au niveau IP. Au niveau Eth, adresse MAC de Eth0 comme source et adresse MAC de 157.159.1.1 comme destination. Donc en gros, si tu as un geek avec une 2ème IP sur son Linux (sur une 2ème carte réseau ou la même), qui lui sert à autre chose, et qu’il a une application qui devrait utiliser cette 2ème IP mal configurée, on peut tout imaginer. Sans parler de ceux qui expérimentent dans le cadre des cours. C’est pour ça que des PC étudiants doivent être considérés comme une zone à risques, et donc être filtrés drastiquement :) Maintenant, tu y es presque. Tu a pas l’adresse MAC source des paquets dans Netflow ? Je me souviens plus. Il doit y avoir un moyen de les collecter en tout cas. Une fois que tu as l’adresse MAC, tu regardes si la même adresse MAC est connue pour une autre IP (publique cette fois) et tu as ton méchant. Le 30 juil. 2015 à 09:52, jehan procaccia INT jehan.procac...@int-evry.fr a écrit : Le 30/07/2015 08:41, David Ponzone a écrit : Encore une fois, je ne sais pas si c’est ta phrase qui est mal tournée, mais ce n’est pas parce que tu n’as pas de route vers un subnet que tu ne vas pas recevoir de paquets venant de ce subnet. Les routes définissent par où tu vas envoyer tes paquets vers cette IP (et donc tes réponses). OK, je me met à la place du pirate, comment depuis mon client linux par exemple, sur mon réseau public 157.159.1.0/24 qui a une gateway en 157.159.1.1 sur une interface vlan correspondant a ce reseau sur le 6500, je peux configurer sur ce vlan + subnet ip public (donc a une gateway qui repond en 157.159.1.1 ) une adresse 192.168.1.101 !?, le systeme va me jeter !? le subnet IP ne correspond pas a ma gateway , bref comment le pirate arrive a joindre ma gateway publique du 6500 avec un subnet IP qui ne match pas ce que dessert le vlan . Pour empêcher des paquets qui ont 192.168.1.101 comme source, il faut mettre un: ip access-list standard anti-mechants deny 10.0.0.0 0.255.255.255 deny 192.168.0.0 0.0.255.255 deny 172.16.0.0 0.15.255.255 permit any Oui, je sais bien que c'est la bonne solution Mon objectif immédiat n'est pas de droper ce trafic, mais de l'identifier, je veux trouver la source, si je le drop je n'aurais plus de traces . (http://www.cisco.com/c/en/us/support/docs/ip/access-lists/43920-iacl.html) et tu appliques ceci sur TOUTES tes interfaces INGRESS, donc toutes les interfaces sur lesquelles sont connectés des équipements que tu ne maitrises pas: -internet -clients -machines d’étudiants fous sous Windows ou geeks sous Linux D’ailleurs, sur les interfaces INGRESS internes (clients/utilisateurs) tu peux même être encore plus restrictif en autorisant seulement tes propres IP. Sur les INGRESS externes, tu peux en plus interdire tes propres IP. Encore plus drastique , mais effectivement plus sure , je vais y réfléchir . Désolé si je répète un truc déjà fait, mais j’ai eu un doute en te lisant. pas de problèmes, moi même j'y perd mon latin . Merci . Le 29 juil. 2015 à 23:43, jehan procaccia IMT jehan.procac...@tem-tsp.eu a écrit : comment des paquets (forgés probablement) avec une src en 192.168.1.101 peuvent t-il aboutir sur mon coeur de reseau alors que je n'ai pas de gateway ni de route pour ce reseau 192.168.1.0/24 !? cela m’intéresse . --- 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] Deni de service en src 192.168.1 sur Cisco ASR / 6500
Oui mais en sachant pas s’il peut activer le mirroring sur son châssis, je me demandais si on pouvait les collecter avec netflow. Le 30 juil. 2015 à 10:19, Jérôme BERTHIER j...@laposte.net a écrit : 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/ --- 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 08:41, David Ponzone a écrit : Encore une fois, je ne sais pas si c’est ta phrase qui est mal tournée, mais ce n’est pas parce que tu n’as pas de route vers un subnet que tu ne vas pas recevoir de paquets venant de ce subnet. Les routes définissent par où tu vas envoyer tes paquets vers cette IP (et donc tes réponses). OK, je me met à la place du pirate, comment depuis mon client linux par exemple, sur mon réseau public 157.159.1.0/24 qui a une gateway en 157.159.1.1 sur une interface vlan correspondant a ce reseau sur le 6500, je peux configurer sur ce vlan + subnet ip public (donc a une gateway qui repond en 157.159.1.1 ) une adresse 192.168.1.101 !?, le systeme va me jeter !? le subnet IP ne correspond pas a ma gateway , bref comment le pirate arrive a joindre ma gateway publique du 6500 avec un subnet IP qui ne match pas ce que dessert le vlan . Pour empêcher des paquets qui ont 192.168.1.101 comme source, il faut mettre un: ip access-list standard anti-mechants deny 10.0.0.0 0.255.255.255 deny 192.168.0.0 0.0.255.255 deny 172.16.0.0 0.15.255.255 permit any Oui, je sais bien que c'est la bonne solution Mon objectif immédiat n'est pas de droper ce trafic, mais de l'identifier, je veux trouver la source, si je le drop je n'aurais plus de traces . (http://www.cisco.com/c/en/us/support/docs/ip/access-lists/43920-iacl.html) et tu appliques ceci sur TOUTES tes interfaces INGRESS, donc toutes les interfaces sur lesquelles sont connectés des équipements que tu ne maitrises pas: -internet -clients -machines d’étudiants fous sous Windows ou geeks sous Linux D’ailleurs, sur les interfaces INGRESS internes (clients/utilisateurs) tu peux même être encore plus restrictif en autorisant seulement tes propres IP. Sur les INGRESS externes, tu peux en plus interdire tes propres IP. Encore plus drastique , mais effectivement plus sure , je vais y réfléchir . Désolé si je répète un truc déjà fait, mais j’ai eu un doute en te lisant. pas de problèmes, moi même j'y perd mon latin . Merci . Le 29 juil. 2015 à 23:43, jehan procaccia IMT jehan.procac...@tem-tsp.eu a écrit : comment des paquets (forgés probablement) avec une src en 192.168.1.101 peuvent t-il aboutir sur mon coeur de reseau alors que je n'ai pas de gateway ni de route pour ce reseau 192.168.1.0/24 !? cela m’intéresse . --- 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-30 at 09:52 +0200, jehan procaccia INT wrote: Le 30/07/2015 08:41, David Ponzone a écrit : Encore une fois, je ne sais pas si c’est ta phrase qui est mal tournée, mais ce n’est pas parce que tu n’as pas de route vers un subnet que tu ne vas pas recevoir de paquets venant de ce subnet. Les routes définissent par où tu vas envoyer tes paquets vers cette IP (et donc tes réponses). OK, je me met à la place du pirate, comment depuis mon client linux par exemple, sur mon réseau public 157.159.1.0/24 qui a une gateway en 157.159.1.1 sur une interface vlan correspondant a ce reseau sur le 6500, je peux configurer sur ce vlan + subnet ip public (donc a une gateway qui repond en 157.159.1.1 ) une adresse 192.168.1.101 !?, le systeme va me jeter !? le subnet IP ne correspond pas a ma gateway , bref comment le pirate arrive a joindre ma gateway publique du 6500 avec un subnet IP qui ne match pas ce que dessert le vlan . Il suffit de forger le paquet ! Le pirate forge un paquet IP avec comme IP source 192.168.1.101, l'envoie en L2 jusqu'a la MAC de ton routeur qui porte 157.159.1.1, lequel va accepter la trame (car adressée à sa MAC), puis regarder l'IP destinataire pour faire la décision de routage. C'est pour cela qu'on te conseille de mettre un filtre ingress sur 157.159.1.0/24 sur l'interface qui n'est censée recevoir que du traffic en provenance de ce subnet. Si tu veux, je peux te lancer un paquet ayant comme IP source l'adresse IP de www.int-evry.fr hein, s'il n'y a pas de filtres côté source (justement celui qu'on te conseille de poser), ni côté destination, le paquet arrivera à sa destination. -- 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
Le 28/07/2015 15:05, Dominique Rousseau a écrit : Le Tue, Jul 28, 2015 at 02:58:45PM +0200, jehan procaccia INT [jehan.procac...@int-evry.fr] a écrit: c'est ce que je capture en faisant un port mirroring (session monitor en termes cisco) sur l'interface que je suspectais donc pas vraiment apres mon 6500 , mais plutôt dedans . Si c'est sur l'interface de sortie, vers ton ASR, c'est du apres. OK, c'est effectivement APRES, donc la MAC capturée doit correspondre a l'adresse MAC de mon interface de sortie normalement, ici le Giga 2/21 (la G2/16 etant la destination du port mirroring où se trouve mon PC/TCPDUMP) 6509E-B007#show monitor Session 1 - Type : Local Session Source Ports : Both : Gi2/21 Destination Ports : Gi2/16 6509E-B007#show interface g 2/21 | include line | address GigabitEthernet2/21 is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is 001f.6ca4.b194 (bia 001f.6ca4.b194) or, voici le rappel de type de capture du synflood : 11:56:50.943052 *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 121, id 13137, offset 0, flags [DF], proto TCP (6), length 48) 192.168.1.101.4007 119.28.3.29.80: Flags [S], cksum 0x7576 (correct), seq 2748456345, win 65535, options [mss 1460,nop,nop,sackOK], length 0 la mac 10:bd:18:e4:80:80 n'est pas celle de l'interface g 2/21 (001f.6ca4.b194) mais celle de de la giga 2/22 (reseau downlink vers clients ) 6509E-B007#show interfaces gigabitEthernet 2/22 GigabitEthernet2/22 is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is *10bd.18e4.8080* (bia 10bd.18e4.8080) Helas, comme plein d'interfaces sur mon 6500 ont aussi la MAC *10bd.18e4.8080 *je ne suis pas avancé pour identifier l'interface source du syn flood . Ceci s'explique apparement d'apres la judicieuse remarque de David Ponzone Le 28/07/2015 14:55, David Ponzone a écrit : C’est étrange en effet, mais lis ça, ca explique peut-être le truc: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/41263-catmac-41263.html effectivement à la lecture de cette doc il semble normal qu'il y a la meme MAC sur +sieurs Interfaces et on ne peut pas y faire grand chose :-( As a result, you cannot have a unique MAC address per interface. This is a hardware limitation of the Supervisor Engine II and will not be fixed in a future software release. je suis en Sup2T , je ne sais pas si cette limitation Sup engine II correspond ... mais je constate bien ce pb . Bref, il n'est vraiment pas évident de pister un flux sur ces équipements, il faudrait presque pouvoir éteindre une a une les interfaces au moment du flood, mais avec +128 interfaces et des flood sporadiques qui ne durent que qq minutes, ce n'est vraiment pas facile . avec 2 cartes 48 ports 1G et 1 carte 16 * 10G cela ne va pas etre facile de faire du port mirroring sur chaque port ! [...] avez vous une idée pour identifier l'interface source de mon 6500 qui génère ce trafic. Vu le nombre de ports que tu indiques, il y'en a où ton 6500 fait du switching, et d'autres où il route, je suppose. Si tu te limites aux ports qui font du routage, ça te donne quoi ? Ils routent quasiment tous, j'ai un uplink vers l'ASR puis operateurs, et un downlink vers un reseau client, le reste c'est mon LAN de campus avec une dizaine de batiments en Fibre et et une dizaine de switch directement raccordés en 1G et 10G dans le datacenter qui font usage d'interfaces switchport cuivre mais toutes ratachées a des interfaces vlan qui routent . plus théoriquement, je m'interroge toujours sur la source du flood ?! comment des paquets (forgés probablement) avec une src en 192.168.1.101 peuvent t-il aboutir sur mon coeur de reseau alors que je n'ai pas de gateway ni de route pour ce reseau 192.168.1.0/24 !? peut-être qu'une réponse a cette question m'aiguillera sur une piste plus prometteuse . 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
Tu peux pas activer netflow sur ce bouzin ? Le 29 juil. 2015 à 19:08, jehan procaccia INT jehan.procac...@int-evry.fr a écrit : Le 28/07/2015 15:05, Dominique Rousseau a écrit : Le Tue, Jul 28, 2015 at 02:58:45PM +0200, jehan procaccia INT [jehan.procac...@int-evry.fr] a écrit: c'est ce que je capture en faisant un port mirroring (session monitor en termes cisco) sur l'interface que je suspectais donc pas vraiment apres mon 6500 , mais plutôt dedans . Si c'est sur l'interface de sortie, vers ton ASR, c'est du apres. OK, c'est effectivement APRES, donc la MAC capturée doit correspondre a l'adresse MAC de mon interface de sortie normalement, ici le Giga 2/21 (la G2/16 etant la destination du port mirroring où se trouve mon PC/TCPDUMP) 6509E-B007#show monitor Session 1 - Type : Local Session Source Ports : Both : Gi2/21 Destination Ports : Gi2/16 6509E-B007#show interface g 2/21 | include line | address GigabitEthernet2/21 is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is 001f.6ca4.b194 (bia 001f.6ca4.b194) or, voici le rappel de type de capture du synflood : 11:56:50.943052 *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 121, id 13137, offset 0, flags [DF], proto TCP (6), length 48) 192.168.1.101.4007 119.28.3.29.80: Flags [S], cksum 0x7576 (correct), seq 2748456345, win 65535, options [mss 1460,nop,nop,sackOK], length 0 la mac 10:bd:18:e4:80:80 n'est pas celle de l'interface g 2/21 (001f.6ca4.b194) mais celle de de la giga 2/22 (reseau downlink vers clients ) 6509E-B007#show interfaces gigabitEthernet 2/22 GigabitEthernet2/22 is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is *10bd.18e4.8080* (bia 10bd.18e4.8080) Helas, comme plein d'interfaces sur mon 6500 ont aussi la MAC *10bd.18e4.8080 *je ne suis pas avancé pour identifier l'interface source du syn flood . Ceci s'explique apparement d'apres la judicieuse remarque de David Ponzone Le 28/07/2015 14:55, David Ponzone a écrit : C’est étrange en effet, mais lis ça, ca explique peut-être le truc: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/41263-catmac-41263.html effectivement à la lecture de cette doc il semble normal qu'il y a la meme MAC sur +sieurs Interfaces et on ne peut pas y faire grand chose :-( As a result, you cannot have a unique MAC address per interface. This is a hardware limitation of the Supervisor Engine II and will not be fixed in a future software release. je suis en Sup2T , je ne sais pas si cette limitation Sup engine II correspond ... mais je constate bien ce pb . Bref, il n'est vraiment pas évident de pister un flux sur ces équipements, il faudrait presque pouvoir éteindre une a une les interfaces au moment du flood, mais avec +128 interfaces et des flood sporadiques qui ne durent que qq minutes, ce n'est vraiment pas facile . avec 2 cartes 48 ports 1G et 1 carte 16 * 10G cela ne va pas etre facile de faire du port mirroring sur chaque port ! [...] avez vous une idée pour identifier l'interface source de mon 6500 qui génère ce trafic. Vu le nombre de ports que tu indiques, il y'en a où ton 6500 fait du switching, et d'autres où il route, je suppose. Si tu te limites aux ports qui font du routage, ça te donne quoi ? Ils routent quasiment tous, j'ai un uplink vers l'ASR puis operateurs, et un downlink vers un reseau client, le reste c'est mon LAN de campus avec une dizaine de batiments en Fibre et et une dizaine de switch directement raccordés en 1G et 10G dans le datacenter qui font usage d'interfaces switchport cuivre mais toutes ratachées a des interfaces vlan qui routent . plus théoriquement, je m'interroge toujours sur la source du flood ?! comment des paquets (forgés probablement) avec une src en 192.168.1.101 peuvent t-il aboutir sur mon coeur de reseau alors que je n'ai pas de gateway ni de route pour ce reseau 192.168.1.0/24 !? peut-être qu'une réponse a cette question m'aiguillera sur une piste plus prometteuse . Merci . --- 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
J'ai finit par mettre une ACL qui filtre tout 192.168 .0.0/24 malheureusement cela passe toujours ! :-( et pour cause, je pensais avoir identifié l'interface source sur mon 6500 , or je m’aperçois que l'adresse MAC identifié comme source du pb est affectée a plusieurs interfaces du 6500 !? rappel de type de capture du synflood : 11:56:50.943052 *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 121, id 13137, offset 0, flags [DF], proto TCP (6), length 48) *192.168.1.101*.4007 119.28.3.29.80: Flags [S], cksum 0x7576 (correct), seq 2748456345, win 65535, options [mss 1460,nop,nop,sackOK], length 0 La MAC est donc *10:bd:18:e4:80:80 *6509E-B007#show interfaces gigabitEthernet 2/19 GigabitEthernet2/19 is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is *10bd.18e4.8080* (bia 10bd.18e4.8080) GigabitEthernet2/20 is down, line protocol is down (notconnect) Hardware is C6k 1000Mb 802.3, address is *10bd.18e4.8080* (bia 10bd.18e4.8080) 6509E-B007#show interfaces gigabitEthernet 2/22 GigabitEthernet2/22 is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is *10bd.18e4.8080 *(bia 10bd.18e4.8080) * *je pensais avoir indetifié la source sur gigabitEthernet 2/22 , mais g 2/19, g2/20 etc ... ont aussi 10bd.18e4.8080*?? *je crois que j'ai trop la tête dans le guidon sur cette affaire ... j'ai oublié une évidence ? ce sont des MAC adresse d'interface cisco virtuelle ? vlan ? j'ai du HSRP , peut-etre un effet de bord ? bref avez vous une piste pour retrouver l'interface source de ce trafic !? Merci .* *Le 24/07/2015 16:30, David Ponzone a écrit : Mais filtre tout le rfc1918 ( sauf le légitime) en entrée du 6500! David Ponzone Le 24 juil. 2015 à 16:25, jehan procaccia INT jehan.procac...@int-evry.fr mailto:jehan.procac...@int-evry.fr a écrit : Le 24/07/2015 15:32, Nicolas Strina a écrit : On 24 juil. 2015, at 14:04, Clement Cavadoreclem...@cavadore.net wrote: Re, On Fri, 2015-07-24 at 14:58 +0200, jehan procaccia INT wrote: apres analyse pcap du trafic incriminé, extrait : des milliers de paquets avec le Flag S (Sync) cf : (...) http://albanianwizard.org/how-to-read-tcpdump-output-tcpdump-advanced-use.albanianwizard montre qu'il s'agit vraisemblablement d'un SynFlood attack je me lance alors dans l'espoir d'intercepter ça avec les outils cisco http://www.sans.org/security-resources/idfaq/syn_flood.php http://ccie-or-null.net/tag/cisco-tcp-intercept/ http://www.ciscopress.com/articles/article.asp?p=345618seqNum=3 Helas, sur mon 6500E pas de commande ip tcp intercept :-( ! ça sort d'où cette commande ? n'est pas disponible par défaut ? Probablement disponible sur une autre plateforme que les 6k5. Non, mais plus sérieusement, tu devrais poser sur ton ASR une ACL ingress sur l'interface vers ton réseau interne, n'autorisant que les subnets IP qu'elle est supposée recevoir, à savoir les réseaux publics passant par ce routeur. Et du coup, tu peux te passer de ton ACL egress. Sinon voir avec ton upstream ? Ca me parait une bonne solution si tu as des soucis aussi important et aussi longtemps .. Le transitaire doit aussi assurer la “sécurité” des clients dans une moindre mesure .. Le probleme est que je suis l'upstream ! voici un aperçu ASCII du schema reseau: Source Synflood = Autonomous system (au sens politique/domain de vlans) Etudiants (4500) *= Mon Core 6509E = Mon ASR =* MAN-Evry = Renater = Internet j'aimerai bien intercepter le Synflood au plus tot (amont) sur mon 6509E . je suis surpris que le 6500 (le couteau suisse cisco ) ne gere pas le /ip tcp intercept/ tel que définit ici et là : http://www.sans.org/security-resources/idfaq/syn_flood.php http://ccie-or-null.net/tag/cisco-tcp-intercept/ http://www.ciscopress.com/articles/article.asp?p=345618seqNum=3 sinon, peut-etre une autre commande ? y-a-t-il un correspondant Cisco dans la salle ? 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
Le Tue, Jul 28, 2015 at 12:14:46PM +0200, jehan procaccia INT [jehan.procac...@int-evry.fr] a écrit: J'ai finit par mettre une ACL qui filtre tout 192.168 .0.0/24 malheureusement cela passe toujours ! :-( et pour cause, je pensais avoir identifié l'interface source sur mon 6500 , or je m???aperçois que l'adresse MAC identifié comme source du pb est affectée a plusieurs interfaces du 6500 !? rappel de type de capture du synflood : 11:56:50.943052 *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 121, id 13137, offset 0, flags [DF], proto TCP (6), length 48) *192.168.1.101*.4007 119.28.3.29.80: Flags [S], cksum 0x7576 (correct), seq 2748456345, win 65535, options [mss 1460,nop,nop,sackOK], length 0 La MAC est donc *10:bd:18:e4:80:80 Mais ça, c'est (si j'ai bien compris) ce que tu captures *APRES* ton 6500, qui doit effectuer du routage, et c'est donc son adresse MAC que tu vois. [...] *je crois que j'ai trop la tête dans le guidon sur cette affaire ... j'ai oublié une évidence ? ce sont des MAC adresse d'interface cisco virtuelle ? vlan ? j'ai du HSRP , peut-etre un effet de bord ? bref avez vous une piste pour retrouver l'interface source de ce trafic !? Ce qu'il faudrait, c'est réussir à identifier la source *AVANT* le 6500. As-tu moyen de placer de quoi faire un tcpdump sur les entrées de ton 6500 ? -- 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/
Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
Le Tue, Jul 28, 2015 at 02:58:45PM +0200, jehan procaccia INT [jehan.procac...@int-evry.fr] a écrit: Le 28/07/2015 14:30, Dominique Rousseau a écrit : [...] La MAC est donc *10:bd:18:e4:80:80 Mais ça, c'est (si j'ai bien compris) ce que tu captures *APRES* ton 6500, qui doit effectuer du routage, et c'est donc son adresse MAC que tu vois. [...] c'est ce que je capture en faisant un port mirroring (session monitor en termes cisco) sur l'interface que je suspectais donc pas vraiment apres mon 6500 , mais plutôt dedans . Si c'est sur l'interface de sortie, vers ton ASR, c'est du apres. Ce qu'il faudrait, c'est réussir à identifier la source *AVANT* le 6500. oui, c'est bien ce que je recherche As-tu moyen de placer de quoi faire un tcpdump sur les entrées de ton 6500 ? avec 2 cartes 48 ports 1G et 1 carte 16 * 10G cela ne va pas etre facile de faire du port mirroring sur chaque port ! [...] avez vous une idée pour identifier l'interface source de mon 6500 qui génère ce trafic. Vu le nombre de ports que tu indiques, il y'en a où ton 6500 fait du switching, et d'autres où il route, je suppose. Si tu te limites aux ports qui font du routage, ça te donne quoi ? -- 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/
Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
C’est étrange en effet, mais lis ça, ca explique peut-être le truc: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/41263-catmac-41263.html Le 28 juil. 2015 à 12:14, jehan procaccia INT jehan.procac...@int-evry.fr a écrit : J'ai finit par mettre une ACL qui filtre tout 192.168 .0.0/24 malheureusement cela passe toujours ! :-( et pour cause, je pensais avoir identifié l'interface source sur mon 6500 , or je m’aperçois que l'adresse MAC identifié comme source du pb est affectée a plusieurs interfaces du 6500 !? rappel de type de capture du synflood : 11:56:50.943052 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 121, id 13137, offset 0, flags [DF], proto TCP (6), length 48) 192.168.1.101.4007 119.28.3.29.80: Flags [S], cksum 0x7576 (correct), seq 2748456345, win 65535, options [mss 1460,nop,nop,sackOK], length 0 La MAC est donc 10:bd:18:e4:80:80 6509E-B007#show interfaces gigabitEthernet 2/19 GigabitEthernet2/19 is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is 10bd.18e4.8080 (bia 10bd.18e4.8080) GigabitEthernet2/20 is down, line protocol is down (notconnect) Hardware is C6k 1000Mb 802.3, address is 10bd.18e4.8080 (bia 10bd.18e4.8080) 6509E-B007#show interfaces gigabitEthernet 2/22 GigabitEthernet2/22 is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is 10bd.18e4.8080 (bia 10bd.18e4.8080) je pensais avoir indetifié la source sur gigabitEthernet 2/22 , mais g 2/19, g2/20 etc ... ont aussi 10bd.18e4.8080 ?? je crois que j'ai trop la tête dans le guidon sur cette affaire ... j'ai oublié une évidence ? ce sont des MAC adresse d'interface cisco virtuelle ? vlan ? j'ai du HSRP , peut-etre un effet de bord ? bref avez vous une piste pour retrouver l'interface source de ce trafic !? Merci . Le 24/07/2015 16:30, David Ponzone a écrit : Mais filtre tout le rfc1918 ( sauf le légitime) en entrée du 6500! David Ponzone Le 24 juil. 2015 à 16:25, jehan procaccia INT jehan.procac...@int-evry.fr a écrit : Le 24/07/2015 15:32, Nicolas Strina a écrit : On 24 juil. 2015, at 14:04, Clement Cavadore clem...@cavadore.net wrote: Re, On Fri, 2015-07-24 at 14:58 +0200, jehan procaccia INT wrote: apres analyse pcap du trafic incriminé, extrait : des milliers de paquets avec le Flag S (Sync) cf : (...) http://albanianwizard.org/how-to-read-tcpdump-output-tcpdump-advanced-use.albanianwizard montre qu'il s'agit vraisemblablement d'un SynFlood attack je me lance alors dans l'espoir d'intercepter ça avec les outils cisco http://www.sans.org/security-resources/idfaq/syn_flood.php http://ccie-or-null.net/tag/cisco-tcp-intercept/ http://www.ciscopress.com/articles/article.asp?p=345618seqNum=3 Helas, sur mon 6500E pas de commande ip tcp intercept :-( ! ça sort d'où cette commande ? n'est pas disponible par défaut ? Probablement disponible sur une autre plateforme que les 6k5. Non, mais plus sérieusement, tu devrais poser sur ton ASR une ACL ingress sur l'interface vers ton réseau interne, n'autorisant que les subnets IP qu'elle est supposée recevoir, à savoir les réseaux publics passant par ce routeur. Et du coup, tu peux te passer de ton ACL egress. Sinon voir avec ton upstream ? Ca me parait une bonne solution si tu as des soucis aussi important et aussi longtemps .. Le transitaire doit aussi assurer la “sécurité” des clients dans une moindre mesure .. Le probleme est que je suis l'upstream ! voici un aperçu ASCII du schema reseau: Source Synflood = Autonomous system (au sens politique/domain de vlans) Etudiants (4500) = Mon Core 6509E = Mon ASR = MAN-Evry = Renater = Internet j'aimerai bien intercepter le Synflood au plus tot (amont) sur mon 6509E . je suis surpris que le 6500 (le couteau suisse cisco ) ne gere pas le ip tcp intercept tel que définit ici et là : http://www.sans.org/security-resources/idfaq/syn_flood.php http://ccie-or-null.net/tag/cisco-tcp-intercept/ http://www.ciscopress.com/articles/article.asp?p=345618seqNum=3 sinon, peut-etre une autre commande ? y-a-t-il un correspondant Cisco dans la salle ? 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
Le 28/07/2015 14:30, Dominique Rousseau a écrit : Le Tue, Jul 28, 2015 at 12:14:46PM +0200, jehan procaccia INT [jehan.procac...@int-evry.fr] a écrit: J'ai finit par mettre une ACL qui filtre tout 192.168.0.0/16 malheureusement cela passe toujours ! :-( et pour cause, je pensais avoir identifié l'interface source sur mon 6500 , or je m???aperçois que l'adresse MAC identifié comme source du pb est affectée a plusieurs interfaces du 6500 !? rappel de type de capture du synflood : 11:56:50.943052 *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 121, id 13137, offset 0, flags [DF], proto TCP (6), length 48) *192.168.1.101*.4007 119.28.3.29.80: Flags [S], cksum 0x7576 (correct), seq 2748456345, win 65535, options [mss 1460,nop,nop,sackOK], length 0 La MAC est donc *10:bd:18:e4:80:80 Mais ça, c'est (si j'ai bien compris) ce que tu captures *APRES* ton 6500, qui doit effectuer du routage, et c'est donc son adresse MAC que tu vois. [...] c'est ce que je capture en faisant un port mirroring (session monitor en termes cisco) sur l'interface que je suspectais donc pas vraiment apres mon 6500 , mais plutôt dedans . Ce qu'il faudrait, c'est réussir à identifier la source *AVANT* le 6500. oui, c'est bien ce que je recherche As-tu moyen de placer de quoi faire un tcpdump sur les entrées de ton 6500 ? avec 2 cartes 48 ports 1G et 1 carte 16 * 10G cela ne va pas etre facile de faire du port mirroring sur chaque port ! ce qui me perturbe fortement, c'est pourquoi des interfaces du 6500 ont la meme adresse MAC !? GigabitEthernet*2/19* is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is *10bd.18e4.8080* (bia 10bd.18e4.8080) GigabitEthernet*2/22 *is up, line protocol is up (connected) Hardware is C6k 1000Mb 802.3, address is *10bd.18e4.8080* (bia 10bd.18e4.8080) au dela d'une ACL en IN sur l'interface suspectée 6509E-B007#show access-lists 122 Extended IP access list 122 10 deny ip 192.168.1.0 0.0.0.255 any log-input 30 permit ip any any (413 matches) interface GigabitEthernet2/22 ip access-group 122 in j'ai monté ensuite un rate-limit afin de voir plus finement si je peux matcher et controler ce trafic sur cette interface 6509E-B007#show policy-map police-192-168-1-traffic Policy Map police-192-168-1-traffic Class identify-192-168-1-traffic police flow mask src-only 32000 10 conform-action transmit exceed-action drop 6509E-B007#show class-map identify-192-168-1-traffic Class Map match-all identify-192-168-1-traffic (id 37) Match access-group 123 6509E-B007#show access-lists 123 Extended IP access list 123 10 permit ip 192.168.1.0 0.0.0.255 any Helas, cela ne match rien, meme a un momment ou j'ai vu les effets de bord du synflood sur l'ACL 112 de mon ASR qui n'arrivent plus a Loger quand cela se produit 6509E-B007#show policy-map interface gigabitEthernet 2/22 GigabitEthernet2/22 Service-policy input: police-192-168-1-traffic *Class-map: identify-192-168-1-traffic (match-all)** ** 0 packets, 0 bytes* 5 minute offered rate bps, drop rate bps Match: access-group 123 Class-map: class-default (match-any) 581 packets, 83110 bytes 5 minute offered rate bps, drop rate bps Match: any 581 packets, 83110 bytes 5 minute rate 0 bps avez vous une idée pour identifier l'interface source de mon 6500 qui génère ce trafic. la difficulté est qu'il y a des burst de synflood qui ne durent que qq minites de façon aleatoire toutes les 3 ou 4H = pas facile de suivre le flux 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
Le 23/07/2015 18:40, David Ponzone a écrit : 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. j'avais pourtant déjà mis du uRPF et des access-group en IN et OUT sur le Edge (ASR) interface GigabitEthernet0/0/2 * ip access-group SPOOFING-IN in** ** ip access-group 112 out* ip flow ingress (j'ai aussi un netflow collector via nfsen ...) ip flow egress * ip verify unicast reverse-path** * asr1-evry#show access-lists SPOOFING-IN (je deny en IN des IP de mon network qui seraient spoofées depuis l'exterieur !) Standard IP access list SPOOFING-IN 20 deny X.Y.0.0, wildcard bits 0.0.255.255 30 permit any (2658219251 matches) asr1-evry#show access-lists 112 (ACL en out qui m'a permis de detecter le pb par effet de bord ...) Extended IP access list 112 10 deny ip 192.168.1.0 0.0.0.255 any log-input (44452922 matches) = mon pb du moment 20 deny ip 192.168.0.0 0.0.255.255 any log (4847 matches) = il faut que j'ajoute les autres subnet RFC1918 40 permit ip any any (1058619881 matches) mais effectivement je ne filtre pas les RFC1918 sur le Core (6500) il va falloir que je vérifie comment améliorer ces filtrages . Concernant la charge d'un ASR pour 50Kps qui sature a cause des ACL en mode LOG , je pense probablement que c'est cet aspect LOG qui sature et non le forward de 50Kps sur une telle bête de course d'ailleurs les messages sur la console indiquent bien ça: 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 je serait bien tenté de retirer l'option LOG de mon ACL outgress, mais inversement, sans ça je n'aurai pas été alerté de la présence de trafics illégitimes . un vrais IDS sur le LAN serait peut-etre plus approprié, mais mettre une boites noires a sur un LAN comprenant plusieurs dizaine d'interfaces 10G et Centaines 1G me parait budgétairement inabordable . On avait bien un carte FWSM (firewall module) dans le 6500E , mais elle est deprecated ... je vais m'orienter vers une application des traditionnels filtres in/outgress sur mon Core 6500E http://www.cisco.com/c/en/us/support/docs/ip/access-lists/43920-iacl.html http://www.techrepublic.com/article/prevent-ip-spoofing-with-the-cisco-ios/ https://www.revelify.com/ingress-and-egress-filtering-with-acls/ Merci pour les conseils . --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
apres analyse pcap du trafic incriminé, extrait : ... 03:17:16.861782 IP 192.168.1.101.pwgpsi 113.10.190.164.http: Flags [S], seq 223483717, win 65535, options [mss 1460,nop,nop,sackOK], length 0 03:17:16.861790 IP 192.168.1.101.3403 113.10.190.164.http: Flags [S], seq 2632565066, win 65535, options [mss 1460,nop,nop,sackOK], length 0 03:17:16.861796 IP 192.168.1.101.3403 113.10.190.164.http: Flags [S], seq 3264797709, win 65535, options [mss 1460,nop,nop,sackOK], length 0 03:17:16.861803 IP 192.168.1.101.3403 113.10.190.164.http: Flags [S], seq 3264797709, win 65535, options [mss 1460,nop,nop,sackOK], length 0 03:17:16.861810 IP 192.168.1.101.3403 113.10.190.164.http: Flags [S], seq 3264797709, win 65535, options [mss 1460,nop,nop,sackOK], length 0 03:17:16.861817 IP 192.168.1.101.3403 113.10.190.164.http: Flags [S], seq 2632565066, win 65535, options [mss 1460,nop,nop,sackOK], length 0 03:17:16.861824 IP 192.168.1.101.dssiapi 113.10.190.164.http: Flags [S], seq 3682841697, win 65535, options [mss 1460,nop,nop,sackOK], length 0 03:17:16.861831 IP 192.168.1.101.remote-winsock 113.10.190.164.http: Flags [S], seq 3359203881, win 65535, options [mss 1460,nop,nop,sackOK], length 0 03:17:16.861838 IP 192.168.1.101.remote-winsock 113.10.190.164.http: Flags [S], seq 3359203881, win 65535, options [mss 1460,nop,nop,sackOK], length 0 03:17:16.861844 IP 192.168.1.101.remote-winsock 113.10.190.164.http: Flags [S], seq 2971501483, win 65535, options [mss 1460,nop,nop,sackOK], length 0 03:17:16.861852 IP 192.168.1.101.remote-winsock 113.10.190.164.http: Flags [S], seq 2971501483, win 65535, options [mss 1460,nop,nop,sackOK], length 0 03:17:16.861858 IP 192.168.1.101.ati-ip-to-ncpe 113.10.190.164.http: Flags [S], seq 2500809523, win 65535, options [mss 1460,nop,nop,sackOK], length 0 03:17:16.861865 IP 192.168.1.101.ati-ip-to-ncpe 113.10.190.164.http: Flags [S], seq 2657654922, win 65535, options [mss 1460,nop,nop,sackOK], length 0 03:17:16.861872 IP 192.168.1.101.ati-ip-to-ncpe 113.10.190.164.http: Flags [S], seq 2661998392, win 65535, options [mss 1460,nop,nop,sackOK], length 0 03:17:16.861879 IP 192.168.1.101.mqe-agent 113.10.190.164.http: Flags [S], seq 1759456840, win 65535, options [mss 1460,nop,nop,sackOK], length 0 03:17:16.861885 IP 192.168.1.101.iee-qfx 113.10.190.164.http: Flags [S], seq 3559881937, win 65535, options [mss 1460,nop,nop,sackOK], length 0 ... des milliers de paquets avec le Flag S (Sync) cf : http://albanianwizard.org/how-to-read-tcpdump-output-tcpdump-advanced-use.albanianwizard montre qu'il s'agit vraisemblablement d'un SynFlood attack je me lance alors dans l'espoir d'intercepter ça avec les outils cisco http://www.sans.org/security-resources/idfaq/syn_flood.php http://ccie-or-null.net/tag/cisco-tcp-intercept/ http://www.ciscopress.com/articles/article.asp?p=345618seqNum=3 Helas, sur mon 6500E pas de commande *ip tcp intercept :-( ! */6509E(config)#ip tcp intercept// // ^// //% Invalid input detected at '^' marker./* *ça sort d'où cette commande ? n'est pas disponible par défaut ?* *Merci . * *Le 24/07/2015 12:24, David Ponzone a écrit : Si tu commençais par ajouter dans SPOOFING-IN un deny sur tout ce qui est RFC1918 et autres saloperies qui n’a rien à faire là. Mais idéalement, il faut mettre ça en ingress de ton réseau. A ce moment là, les logs, ça devient inutile (ou un luxe que tu ne peux plus te permettre). Le 24 juil. 2015 à 11:30, jehan procaccia INT jehan.procac...@int-evry.fr mailto:jehan.procac...@int-evry.fr a écrit : Le 23/07/2015 18:40, David Ponzone a écrit : 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. j'avais pourtant déjà mis du uRPF et des access-group en IN et OUT sur le Edge (ASR) interface GigabitEthernet0/0/2 * ip access-group SPOOFING-IN in** ** ip access-group 112 out* ip flow ingress (j'ai aussi un netflow collector via nfsen ...) ip flow egress * ip verify unicast reverse-path** * asr1-evry#show access-lists SPOOFING-IN (je deny en IN des IP de mon network qui seraient spoofées depuis l'exterieur !) Standard IP access list SPOOFING-IN 20 deny X.Y.0.0, wildcard bits 0.0.255.255 30 permit any (2658219251 matches) asr1-evry#show access-lists 112 (ACL en out qui m'a permis de detecter le pb par effet de bord ...) Extended IP access list 112 10 deny ip 192.168.1.0 0.0.0.255 any log-input (44452922 matches) = mon pb du moment 20 deny ip 192.168.0.0 0.0.255.255 any log (4847 matches) = il faut que j'ajoute les autres subnet RFC1918 40 permit ip any any (1058619881 matches) mais effectivement je ne filtre pas les RFC1918 sur le Core (6500) il va falloir que je vérifie comment améliorer ces filtrages . Concernant la charge d'un ASR pour 50Kps qui sature a cause des ACL en mode LOG
Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
Re, On Fri, 2015-07-24 at 14:58 +0200, jehan procaccia INT wrote: apres analyse pcap du trafic incriminé, extrait : des milliers de paquets avec le Flag S (Sync) cf : (...) http://albanianwizard.org/how-to-read-tcpdump-output-tcpdump-advanced-use.albanianwizard montre qu'il s'agit vraisemblablement d'un SynFlood attack je me lance alors dans l'espoir d'intercepter ça avec les outils cisco http://www.sans.org/security-resources/idfaq/syn_flood.php http://ccie-or-null.net/tag/cisco-tcp-intercept/ http://www.ciscopress.com/articles/article.asp?p=345618seqNum=3 Helas, sur mon 6500E pas de commande ip tcp intercept :-( ! ça sort d'où cette commande ? n'est pas disponible par défaut ? Probablement disponible sur une autre plateforme que les 6k5. Non, mais plus sérieusement, tu devrais poser sur ton ASR une ACL ingress sur l'interface vers ton réseau interne, n'autorisant que les subnets IP qu'elle est supposée recevoir, à savoir les réseaux publics passant par ce routeur. Et du coup, tu peux te passer de ton ACL egress. -- 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
Si tu commençais par ajouter dans SPOOFING-IN un deny sur tout ce qui est RFC1918 et autres saloperies qui n’a rien à faire là. Mais idéalement, il faut mettre ça en ingress de ton réseau. A ce moment là, les logs, ça devient inutile (ou un luxe que tu ne peux plus te permettre). Le 24 juil. 2015 à 11:30, jehan procaccia INT jehan.procac...@int-evry.fr a écrit : Le 23/07/2015 18:40, David Ponzone a écrit : 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. j'avais pourtant déjà mis du uRPF et des access-group en IN et OUT sur le Edge (ASR) interface GigabitEthernet0/0/2 ip access-group SPOOFING-IN in ip access-group 112 out ip flow ingress (j'ai aussi un netflow collector via nfsen ...) ip flow egress ip verify unicast reverse-path asr1-evry#show access-lists SPOOFING-IN (je deny en IN des IP de mon network qui seraient spoofées depuis l'exterieur !) Standard IP access list SPOOFING-IN 20 deny X.Y.0.0, wildcard bits 0.0.255.255 30 permit any (2658219251 matches) asr1-evry#show access-lists 112 (ACL en out qui m'a permis de detecter le pb par effet de bord ...) Extended IP access list 112 10 deny ip 192.168.1.0 0.0.0.255 any log-input (44452922 matches) = mon pb du moment 20 deny ip 192.168.0.0 0.0.255.255 any log (4847 matches) = il faut que j'ajoute les autres subnet RFC1918 40 permit ip any any (1058619881 matches) mais effectivement je ne filtre pas les RFC1918 sur le Core (6500) il va falloir que je vérifie comment améliorer ces filtrages . Concernant la charge d'un ASR pour 50Kps qui sature a cause des ACL en mode LOG , je pense probablement que c'est cet aspect LOG qui sature et non le forward de 50Kps sur une telle bête de course d'ailleurs les messages sur la console indiquent bien ça: 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 je serait bien tenté de retirer l'option LOG de mon ACL outgress, mais inversement, sans ça je n'aurai pas été alerté de la présence de trafics illégitimes . un vrais IDS sur le LAN serait peut-etre plus approprié, mais mettre une boites noires a sur un LAN comprenant plusieurs dizaine d'interfaces 10G et Centaines 1G me parait budgétairement inabordable . On avait bien un carte FWSM (firewall module) dans le 6500E , mais elle est deprecated ... je vais m'orienter vers une application des traditionnels filtres in/outgress sur mon Core 6500E http://www.cisco.com/c/en/us/support/docs/ip/access-lists/43920-iacl.html http://www.techrepublic.com/article/prevent-ip-spoofing-with-the-cisco-ios/ https://www.revelify.com/ingress-and-egress-filtering-with-acls/ Merci pour les conseils . --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Deni de service en src 192.168.1 sur Cisco ASR / 6500
Mais filtre tout le rfc1918 ( sauf le légitime) en entrée du 6500! David Ponzone Le 24 juil. 2015 à 16:25, jehan procaccia INT jehan.procac...@int-evry.fr a écrit : Le 24/07/2015 15:32, Nicolas Strina a écrit : On 24 juil. 2015, at 14:04, Clement Cavadore clem...@cavadore.net wrote: Re, On Fri, 2015-07-24 at 14:58 +0200, jehan procaccia INT wrote: apres analyse pcap du trafic incriminé, extrait : des milliers de paquets avec le Flag S (Sync) cf : (...) http://albanianwizard.org/how-to-read-tcpdump-output-tcpdump-advanced-use.albanianwizard montre qu'il s'agit vraisemblablement d'un SynFlood attack je me lance alors dans l'espoir d'intercepter ça avec les outils cisco http://www.sans.org/security-resources/idfaq/syn_flood.php http://ccie-or-null.net/tag/cisco-tcp-intercept/ http://www.ciscopress.com/articles/article.asp?p=345618seqNum=3 Helas, sur mon 6500E pas de commande ip tcp intercept :-( ! ça sort d'où cette commande ? n'est pas disponible par défaut ? Probablement disponible sur une autre plateforme que les 6k5. Non, mais plus sérieusement, tu devrais poser sur ton ASR une ACL ingress sur l'interface vers ton réseau interne, n'autorisant que les subnets IP qu'elle est supposée recevoir, à savoir les réseaux publics passant par ce routeur. Et du coup, tu peux te passer de ton ACL egress. Sinon voir avec ton upstream ? Ca me parait une bonne solution si tu as des soucis aussi important et aussi longtemps .. Le transitaire doit aussi assurer la “sécurité” des clients dans une moindre mesure .. Le probleme est que je suis l'upstream ! voici un aperçu ASCII du schema reseau: Source Synflood = Autonomous system (au sens politique/domain de vlans) Etudiants (4500) = Mon Core 6509E = Mon ASR = MAN-Evry = Renater = Internet j'aimerai bien intercepter le Synflood au plus tot (amont) sur mon 6509E . je suis surpris que le 6500 (le couteau suisse cisco ) ne gere pas le ip tcp intercept tel que définit ici et là : http://www.sans.org/security-resources/idfaq/syn_flood.php http://ccie-or-null.net/tag/cisco-tcp-intercept/ http://www.ciscopress.com/articles/article.asp?p=345618seqNum=3 sinon, peut-etre une autre commande ? y-a-t-il un correspondant Cisco dans la salle ? 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
Le 24/07/2015 15:32, Nicolas Strina a écrit : On 24 juil. 2015, at 14:04, Clement Cavadore clem...@cavadore.net wrote: Re, On Fri, 2015-07-24 at 14:58 +0200, jehan procaccia INT wrote: apres analyse pcap du trafic incriminé, extrait : des milliers de paquets avec le Flag S (Sync) cf : (...) http://albanianwizard.org/how-to-read-tcpdump-output-tcpdump-advanced-use.albanianwizard montre qu'il s'agit vraisemblablement d'un SynFlood attack je me lance alors dans l'espoir d'intercepter ça avec les outils cisco http://www.sans.org/security-resources/idfaq/syn_flood.php http://ccie-or-null.net/tag/cisco-tcp-intercept/ http://www.ciscopress.com/articles/article.asp?p=345618seqNum=3 Helas, sur mon 6500E pas de commande ip tcp intercept :-( ! ça sort d'où cette commande ? n'est pas disponible par défaut ? Probablement disponible sur une autre plateforme que les 6k5. Non, mais plus sérieusement, tu devrais poser sur ton ASR une ACL ingress sur l'interface vers ton réseau interne, n'autorisant que les subnets IP qu'elle est supposée recevoir, à savoir les réseaux publics passant par ce routeur. Et du coup, tu peux te passer de ton ACL egress. Sinon voir avec ton upstream ? Ca me parait une bonne solution si tu as des soucis aussi important et aussi longtemps .. Le transitaire doit aussi assurer la “sécurité” des clients dans une moindre mesure .. Le probleme est que je suis l'upstream ! voici un aperçu ASCII du schema reseau: Source Synflood = Autonomous system (au sens politique/domain de vlans) Etudiants (4500) *= Mon Core 6509E = Mon ASR =* MAN-Evry = Renater = Internet j'aimerai bien intercepter le Synflood au plus tot (amont) sur mon 6509E . je suis surpris que le 6500 (le couteau suisse cisco ) ne gere pas le /ip tcp intercept/ tel que définit ici et là : http://www.sans.org/security-resources/idfaq/syn_flood.php http://ccie-or-null.net/tag/cisco-tcp-intercept/ http://www.ciscopress.com/articles/article.asp?p=345618seqNum=3 sinon, peut-etre une autre commande ? y-a-t-il un correspondant Cisco dans la salle ? 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
On 24 juil. 2015, at 14:04, Clement Cavadore clem...@cavadore.net wrote: Re, On Fri, 2015-07-24 at 14:58 +0200, jehan procaccia INT wrote: apres analyse pcap du trafic incriminé, extrait : des milliers de paquets avec le Flag S (Sync) cf : (...) http://albanianwizard.org/how-to-read-tcpdump-output-tcpdump-advanced-use.albanianwizard montre qu'il s'agit vraisemblablement d'un SynFlood attack je me lance alors dans l'espoir d'intercepter ça avec les outils cisco http://www.sans.org/security-resources/idfaq/syn_flood.php http://ccie-or-null.net/tag/cisco-tcp-intercept/ http://www.ciscopress.com/articles/article.asp?p=345618seqNum=3 Helas, sur mon 6500E pas de commande ip tcp intercept :-( ! ça sort d'où cette commande ? n'est pas disponible par défaut ? Probablement disponible sur une autre plateforme que les 6k5. Non, mais plus sérieusement, tu devrais poser sur ton ASR une ACL ingress sur l'interface vers ton réseau interne, n'autorisant que les subnets IP qu'elle est supposée recevoir, à savoir les réseaux publics passant par ce routeur. Et du coup, tu peux te passer de ton ACL egress. Sinon voir avec ton upstream ? Ca me parait une bonne solution si tu as des soucis aussi important et aussi longtemps .. Le transitaire doit aussi assurer la “sécurité” des clients dans une moindre mesure .. -- Clément Cavadore --- 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
Ou plus en amont si possible… Le 24 juil. 2015 à 15:04, Clement Cavadore clem...@cavadore.net a écrit : Re, On Fri, 2015-07-24 at 14:58 +0200, jehan procaccia INT wrote: apres analyse pcap du trafic incriminé, extrait : des milliers de paquets avec le Flag S (Sync) cf : (...) http://albanianwizard.org/how-to-read-tcpdump-output-tcpdump-advanced-use.albanianwizard montre qu'il s'agit vraisemblablement d'un SynFlood attack je me lance alors dans l'espoir d'intercepter ça avec les outils cisco http://www.sans.org/security-resources/idfaq/syn_flood.php http://ccie-or-null.net/tag/cisco-tcp-intercept/ http://www.ciscopress.com/articles/article.asp?p=345618seqNum=3 Helas, sur mon 6500E pas de commande ip tcp intercept :-( ! ça sort d'où cette commande ? n'est pas disponible par défaut ? Probablement disponible sur une autre plateforme que les 6k5. Non, mais plus sérieusement, tu devrais poser sur ton ASR une ACL ingress sur l'interface vers ton réseau interne, n'autorisant que les subnets IP qu'elle est supposée recevoir, à savoir les réseaux publics passant par ce routeur. Et du coup, tu peux te passer de ton ACL egress. -- 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 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] 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] [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 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/
