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 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=345618&seqNum=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=345618&seqNum=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/
