OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: Bogon IPs traffic only seen by netflow, confined within a VLAN only

Valdis.Kletnieksvt.edu
Date: Sun Apr 09 2006 - 23:29:09 CDT


On Sat, 08 Apr 2006 18:17:53 CDT, Stef said:
> 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 ...).

You might want to see if you can get a packet capture of this odd traffic
from a spanning port, and take a *careful* look at the packet and ask yourself
"what if the packet is missing a byte or several at the front, or has some
noise bytes added"? Take some of the headers, and try shifting everything
a byte or two in either direction, and see if it makes sense.

The usual cause for this is a busticated NIC - in years gone by, similar
things were caused by "jabbering" transceivers that would start transmitting
their packet sooner than the spec allowed, resulting in the first few bytes
being dropped, or noise bytes being added...

There's an outside chance that there's a packet-crafting program with an
off-by-one error, but I've seen this caused more often by broken hardware.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQFEOd8VcC3lWbTT17ARAmRVAJ9q0ESVY/s6VHNyFppZX+Ea2SWzBwCdEGh9
9s6bSy9AIhg1YkYYKLD03e8=
=lLW1
-----END PGP SIGNATURE-----