Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
RE: Bogon IPs traffic only seen by netflow, confined within a VLANonly
From: AJ Cochenour (ajcmytcpip.net)
Date: Tue Apr 11 2006 - 08:00:43 CDT
Assuming CatOS on the C4506:
1. Issue the following to locate port if host may be directly connected:
'sh cam dynamic | include <Questionable Source MAC --
2. If operating within distributedswitch network issue the following
(assuming Cisco/Foundry topology):
'l2trace <Switch MAC -- FF-FF-FF-FF-FF-FF> <Questionable Source MAC
-- FF-FF-FF-FF-FF-FF>' to reveal L2 path to device(s) in question.
If using IOS on C4506 issue the following to locate port if host may ne
'sh mac-address-table | include <Questionable Source MAC --
In the absence of recent CatOS/IOS firmware to support the commands
provided TCL scripting would be a viable alernative. Happy hunting
> 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.vandersmagtbbned.nl]
> Sent: Monday, April 10, 2006 2:12 AM
> To: stefmitgmail.com
> Cc: incidentslists.securityfocus.com
> Subject: Re: Bogon IPs traffic only seen by netflow, confined within a
> 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..
> 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
> 188.8.131.52/24 network (e..g 184.108.40.206, 220.127.116.11, 18.104.22.168, 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?