Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Incidents
[Top] [All Lists]

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

Subject: Re: Bogon IPs traffic only seen by netflow, confined within a VLAN only
Date: Mon, 10 Apr 2006 00:29:09 -0400
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: pgpELUF96Zq9t.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>