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'inter
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 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 spa
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
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
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 ve
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 paquet
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
Tu peux pas activer netflow sur ce bouzin ?
Le 29 juil. 2015 à 19:08, jehan procaccia INT 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 fai
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 "apre
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
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é
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 a
écrit :
> J'ai finit par mettre une ACL qui filtre tout 192.168 .0.0/24
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??
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 !?
rap
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 a
> écrit :
>
> Le 24/07/2015 15:32, Nicolas Strina a écrit :
On 24 juil. 2015, at 14:04, Clement Cavadore wrote:
Re,
On Fri, 2015-07-2
Le 24/07/2015 15:32, Nicolas Strina a écrit :
On 24 juil. 2015, at 14:04, Clement Cavadore 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://albanianwizar
> On 24 juil. 2015, at 14:04, Clement Cavadore 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-tcpdum
Ou plus en amont si possible…
Le 24 juil. 2015 à 15:04, Clement Cavadore 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://albania
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 vra
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
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. 20
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-
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 a
écrit :
> Le 23/07/2015 10:42, Clement Cavad
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 l
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
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 t
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
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
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 ann
29 matches
Mail list logo
