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 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
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 ?
--
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
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
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
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
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
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 !?
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
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
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
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
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
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,
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
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.
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:
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 :
(...)
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 :
(...)
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 :
(...)
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
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
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
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
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
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
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
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
29 matches
Mail list logo
