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 
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. 
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 
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..

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.

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.. :)

/mark




"Paul D. Robertson" <[EMAIL PROTECTED]>
06/04/00 07:22 AM

 
        To:     [EMAIL PROTECTED]
        cc:     [EMAIL PROTECTED], "Stephen P. Berry" <[EMAIL PROTECTED]>
        Subject:        Re: OS response to probes


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

> I guess find this whole discussion fascinating but yet still in its
> infancy regarding OS or system fingerprinting fascinating since it 
appears
> that no one is attempting to do system identification at the MAC level,
> since most devices (i.e a SunBox, a router, a NT box) have a MAC address
> which is usually bound to its Network interface, but also one has the
> ability to read the MAC assigned to the particular machine or operating
> system most of it is passed in packet.

MAC addresses don't pass routers, so from a remote detection standpoint,
it's not "interesting."  Also, these days fewer and fewer NIC vendors are
out there, so looking at the MAC address' vendor component isn't as useful
as it once was.  Finally, setting a different vendor code is trivial.  If
there are Ethernet layer fingerprinting techniques, I'd find that
interesting, but MAC addresses themselves aren't that interesting.

> Some of the early anomalous system identification script that have been
> cobbled together and passed around the Internet actually do this and 
also
> build a database if it detects a new system it does not know about.  I
> have no idea where those people went.

It's pretty easy to watch for ARP advertisements and requests and build a
table.  Most commercial sniffer packages will do this.  It's not that
difficult to do even with the output from tcpdump and some perl.

> The real opportunity here is develop a HoneyPot that one has the ability
> to emulate any operating system regardless of the particular operating
> system and box it is installed on.  ManTrap from Recourse Technologies 
is

Why is this a big oppertunity?  For the ammount of code necessary, why not
just build tcprelay and udprelay for the target OS, plonk one down that
relays everything to a monitor box, then do detection there?  That way you
don't have to play catch-up each time a stack changes.

> OK, Anybody out want to a form a company and beat CounterPane Systems 
and
> Recourse Technologies to the punch ???

Not a compelling enough business model for me.  "We're going to do all
this stack emulation work" is pretty expensive versus someone just running
VMWare with each of about 6 guest OS' taking turns at answering the
packets.

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