On Sun, 4 Jun 2000 [EMAIL PROTECTED] wrote:

> You know I was waiting for that response.  You are very correct, but why 
> was Network General so widely recognized and so widely used in the early 
> 80's and 90's.    Most of who have been around the block a few times have 

Widely used: Because they did 7-layer decode and you could use a
half-clued operations person to find problems that a fully-clued network
person used to be necessary for.

Widely recognized: Because they did a good implementation of something
that was necessary.

> realized it is pretty easy to cobble together perl scripts that parse 
> tcpdump or snort and populate a database chock full of interesting stuff. 
> What is interesting is that most of the commercial so called security 
> scanners have yet to incorporate this type of feature into their product.

Most of the commercial security scanners are designed to be run from
remote networks where layer 2 information won't go.  I'd guess that there
are more people in the remote scanning market than in the local scanning
market (in large organizations most places won't place the scanner on each
layer 2 network, though I suppose VLANs could change that eventually.)
 
> Very easy to accomplish but it turns out to be a maintenance nightmare of 
> sorts.  The vendor ships lots of interesting .mib and .obj files to those 

It depends on the environment.  In a managed environment it's not that
difficult to maintain, but if you've got the management in place already,
the value isn't so high.  In a hostile environement you don't get control
of false positives and it's easy to fool the tool.  I suppose most
organizations fall somewhere in the middle where finding a hard value is
still challenging.

Even in small office environments, finding what equipment is attached to a
new MAC address that pops up isn't trivial (if you're on shared media.)  I
doubt the payback of trying to track that down is worth it to most
organizations who don't see any direct and immediate value in doing so.

> corporations who produce Enterprise Network Management and Monitoring 
> tools, so leveraging that information and adding the attribute will 
> definitely increase of identifying a system or O/S with better accuracy..

Adding what attribute?  Nothing at the Ethernet layer provides OS-level
information, and outside of specialized hardware, gaining the real MAC
won't provide much value to most places.  It still doesn't provide OS
information, and to do a good job at passive detection and categorization
requires shared media for the machine doing so.  That's going to be
difficult in most switched environments until the switches start taking a
more active role.  At that point why not do authorization and
authentication at the port level and forget all the silly stuff?

> I addressed your point of playing catch-up in the previous statement, rely 
> on the vendor and then compare it to what has been identified before, and 
> then append the changes/additions to that particular category, so 
> therefore eliminating that issue.

Rely on *which* vendor (I'm sorry, it's not clear to me which part of
this you're latching on to)? The network chipset hardware vendor who's
working with a fixed-sized vendor field for MAC addresses?  The board
vendor who has to be sure to have more than a single source for components
if he's not the component manufacturer?  The OS vendor to do something
unique and identifying in the layer 2 portion of the stack?  The scanner
vendor to try to use active techniques (which will drop some hosts off the
network) or passive techniques (which require specific architectures?)

> Some organizations like CounterPane and Recourse are attempting to do 
> this, but have not acquired the "CLUE" factor in doing this in a very 
> fast, efficient and nonintrusive matter.. :)

I've spent a fair ammount of time recently looking at host and OS
detection, both local and remote.  My overwhelming conclusion is that the
only thing that can be counted on is that countermeasures are fairly easy
to design and place at strategic points on a network, and patch levels,
upgrades and new devices will be a serious problem.

Since I'm looking at rather serious long-term projects in this area, doing
the easy part is going to be on the front of my plate, but the hard part
seems to me to be the stuff that countless cases of Jolt are necessary
for, if not massive quantities of Guinness.  I know for sure that I'd be
happier working on the side of things to confuse such probes, catalogers
and detectors, since I can think of a fair number of ways to foil most
everything...

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
[EMAIL PROTECTED]      which may have no basis whatsoever in fact."

-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to