Re: Bogon IPs traffic only seen by netflow, confined within a VLAN only



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.

Attachment: pgprylupAlQl9.pgp
Description: PGP signature



Relevant Pages

  • expected behavior of PF_PACKET on NETIF_F_HW_VLAN_RX device?
    ... the complete packet with vlan tag included as the driver simply calls ... thing vlan tag included and sends this through the socket. ... The packet socket gets everything including the vlan tag as I'd ...
    (Linux-Kernel)
  • Re: [was] addition to ipfw (read vlans from bridge)..
    ... into the packet as well as the packet, then yes I like that idea, ... At the moment I plan the ipfw code to be unaware of vlan headers. ... What we need to do is make a convention so that vlan tags are always ...
    (freebsd-net)
  • Re: addition to ipfw..
    ... I would like to add something similar in the case where a vlan ... tag is also on the packet.. ... Then the vlan header is also held back so that the packet can be ... This allows me to filter packets that are traversing my bridge, ...
    (freebsd-net)
  • Re: addition to ipfw..
    ... I would like to add something similar in the case where a vlan ... tag is also on the packet.. ... Then the vlan header is also held back so that the packet can be ... The ipfw will be ignoring the vlan contents.. ...
    (freebsd-net)
  • Re: addition to ipfw..
    ... I would like to add something similar in the case where a vlan tag ... is also on the packet.. ... Then the vlan header is also held back so that the packet can be ... This allows me to filter packets that are traversing my bridge, ...
    (freebsd-net)