Combining the below from Nicolai with setting up the port in promiscuous mode
and running a Network Sniffer tool would give you enough data to track it down,
I would think.
-
Jean-Raymond Xavier Pierre
Scientific Computing and Computing Services
Stanford Linear Accelerator Center
-----Original Message-----
From: Nicolai van der Smagt [mailto:nicolai.vandersmagt@bbned.nl]
Sent: Monday, April 10, 2006 2:12 AM
To: stefmit@gmail.com
Cc: incidents@lists.securityfocus.com
Subject: Re: Bogon IPs traffic only seen by netflow, confined within a VLANonly
Stef,
Why don't you just span the entire VLAN to a machine capable of running
tcpdump, use tcpdump -e to find the hardware address of the station(s) sending
the traffic, and look up that address in the CAM table of your switch? Would be
quicker than spanning 1 port at a time..
Kr,
Nicolai van der Smagt
-----
I have a question, that - in case someone has seen this somewhere - may save us
a lot of work: our netflow tool has been reporting lots of traffic (100s of
MB/day) between some bogon IPs: 0.10.94.27 to a few IPs in the 37.245.0.0/24
network (e..g 37.245.0.64, 37.245.0.18, 37.245.0.14, etc.). The report comes
exclusively for one VLAN, from a
4506 switch. The IP protocols being reported are not among the well known ones
(TCP, UDP, ICMP, etc.), but rather #140 (for the majority of traffic) and #63
(and some other ones). We have tried to reach (ICMP echo, nmap, etc.) those IPs
from various stations from the same VLAN, with no success. Monitoring a few
ports (span to a probe), at random, have not revealed any ARP traffic for those
IPs, either, thus
- at this stage - being unable to determine who is responsible for that
traffic. The default gateway for all the systems on that VLAN does not see any
of this traffic, either - and neither any other systems form that point on,
upstream, al the way to the internal interface of the firewall, which makes us
think that somehow that odd traffic is really confined to that specific VLAN
(thus - probably - some sort of spoofing, combined with systems aware of each
other's MAC, thus no need to hit the gateway ...).
The next step is to write a script on the switch itself (TCL -
probably) or on an external probe, so that we could span/monitor one port at a
time, and go through all the ports on all blades from that
4506 (4 modules * 48 ports), until the probe hooked up t the destination port
will report the traffic we are looking for (as netflow data reports this
traffic going on continuously - so it must exist at all times), from one of the
ports. Another simpler approach (but unfeasible, unfortunately, in our
scenario, due to the need for machines to be up 3 shifts/day) would be to shut
down one system at a time, and watch netflow when it stops reporting this junk.
So ... short of doing one of the above - has anybody seen this before?
Do you have an idea of how else we could trace down the perpetrator?
