Le 30/07/2015 10:13, David Ponzone a écrit :
Tu parles de son système ?
Mais il est root dessus, il fait ce qu’il veut.
effectivement , J'ai enfin localisé grâce aux netflows et graphs cacti
en # de paquets le source du tcp syn flood que je subissais.
cela aura été fastidieux du fait de l'intermittence et de la faible
durée du flood à chaque occurences
une machine ouverte en ssh a été usurpée (brute force du password root,
un fail2ban aurait été une bonne prévention locale ... )
téléchargement par le "pirate" d'un binaire depuis un site chinois,
binaire qui génère le synflood,
j'y ai bien retrouvé la chaine de caratere (string sur le binaire)
192.168.1.101 (source des paquets forgés) dedans
bref une brèche classique et simple, mais qui m'aura pris pas mal de
temps pour remonter à la source ,
.
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
oui, j'ai meme trouvé encore plus simple avec hping , option -a ou --spoof !
Maintenant, tu y es presque.
Tu a pas l’adresse MAC source des paquets dans Netflow ? Je me souviens plus.
je n'ai pas réussi a l'avoir dans mon netflow, mais cela semble
paramétrable dans le "flow record" avec un "match" qui va bien , cf:
http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/white_paper_c11-652021.html#_Toc287071073
je regrette qu'il n'y ait pas d'outils plus adéquate (que des graphes
visuels) pour localiser ce genre d'attaque sur les équipements actifs .
depuis j'ai mis en place sur mon coeur de reseau (6500) une policy qui
devrait rate limiter ce genre de flux, mais malheureusement je n'arrive
pas a matcher le flux ,
la policy ne police jamais rien, les compteurs sont tj a zero meme quand
il y a eu un tcp syn flood en cours depuis 192.168.1.101 :-(
6509E#show policy-map interface gigabitEthernet 2/12
GigabitEthernet2/12
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 0000 bps,*drop rate 0000 bps*
Match: access-group 123
Class-map: identify-80-syn-traffic (match-all)
0 packets, 0 bytes
5 minute offered rate 0000 bps,*drop rate 0000 bps*
Match: access-group 125
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
0 packets, 0 bytes
5 minute rate 0 bps
peut-etre que j'ai regardé trop tard, au dela des 5mn l'intervalle "5
minute offered rate" ?
J'ai essayer 2 class-map qui devraient matcher des paquets source en
192.168.1.101, et l'autre qui match a destination du port 80 avec le
flag syn :
6509E#show class-map identify-80-syn-traffic
Class Map match-all identify-80-syn-traffic (id 39)
Match access-group 125
6509E#show access-lists 125
Extended IP access list 125
10 permit tcp any any eq www syn
6509E#show access-lists 123
Extended IP access list 123
10 permit ip 192.168.1.0 0.0.0.255 any
manifestement, n'y l'un , n'y l'autre ne match :-(
Si certains d'entre vous utilise ce genre de policy (rate limite) avec
succes, je suis preneur d'info .
au dela du cas d'ecole, je pense que je vais dropper tout RFC1918 qui
n'a pas lieu d’être, cela aura été une bonne leçon .
Merci .
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
