Re: mac addr lookups?

[Terje Elde <delta () mail-me com>]

On Tue, 16 Feb 1999, //Stany wrote:

> Hi, Delta.  Long time, no see.

Yeah, too long time :(

> I remember suggesting exactly the same thing to Fyodor in the days of 2.0
> Beta 15 or so (I am sure others suggested the same before me too). He
> said that he have toyed with the idea but decided against it, as it was
> too easy to mislead the scanner by changing the MAC address.

With all due respect to Fyodor, I agree with him in many ways in that it
might not be the best of scanning ideas, i just don't like the reason for
his disaproval of the idea.

"Keep the data from the user because it might be fake"?

This sounds like a Mac philosopy. Personally I think the user should be
given access to the data, and then let him decide to belive it or not.

> In fact it /is/ rather trivial to change your MAC address on a number of
> systems.  For example on Sun SPARCs (sun4m and sun4c.  Have not had a
> chance to play with sun4u) MAC address is directly tied to the PROM.
> According to Sun NVRAM/HOSTID FAQ, (available at
> <http://www.squirrel.com/sun-nvram-hostid.faq.html>) the MAC address of a
> Sun system is stored in the PROM, and as a result, every physical network
> interface has the same MAC address.  Why am I bringing this up?  The catch
> is that the PROM is programmable, and in theory any MAC address can be
> programmed in (will the system afterwards correctly report what kind of
> hardware it is is a completely different question ;-) if you bother to
> read a bit.  In another life I had to recover a SS5 that has a PROM dead,
> and as a result of me toying with it, the MAC address of it became
> 8:0:20:c0:ff:ee   Although traditionally only the first 3 values are used
> to identify the manufacturer of the network device, nothing was preventing
> me to change them completely.

It's even easier under linux, you can change it with only a few ioctl's.
There's even a tool at rootshell to do it (only works until reboot tho).

So don't get me wrong here, I know it's easy to change, I just thing it
should be up to the user to decide what to do with the knowlende, it being
misleading or not.

> Additionally it is rather trivial to change the MAC address on different
> platforms.  Linux tulip driver for a long while had the ability to 
> programm the NIC to report back whatever MAC address you want.  In fact
> Corel NetWinder had this ability with older kernels (Corel people have
> patched the kernel source, after I have published it, to prevent abuse, as
> they could get in legal problems for using identifier not assigned to
> them) and some instructions on doing this are available at

ALL linux NIC's can get their MAC's changed... I think...

I fact, it's so easy that I once made a script that randomly changed my
MAC at bootup. Was REALLY fun to use on a network with DHCP and a 5 day
lease:)

> So why am I mentioning all this?  Because potentially using MAC addresses
> is not accurate, as it is trivial to change your MAC address if you want
> to, so this detection will only work on the networks with highly
> unsophisticated people.  Additionally adding such a database of MAC
> addresses has potential to result in code bloat, which is not a good thing
> either.  At most MAC detection can complement OS detection, figuring that
> a computer running a NIC with MAC address starting with 0:10:57 (Corel
> NetWinder) should not be runing SunOS 4.1, or a system with MAC address
> starting with 8:0:20 (Sun SPARC) should not run Be OS. 

I think the REALLY fun thing is when you put it the other way around. If
you find a linux box with 0:0:6d (Cray) then you can be sure (I don't
think linux has been ported to any Cray's) that the owner of the box knows
how to change his MAC and have bothered to do so.

It's true that a newbie could do it, but still, I think user of nmap
should be given the option to take this data into account when he's trying
to figure out stuff.

> However I think that it might be worthwhile for NMAP to record the MAC
> address in event of scanning a local subnet, as this will allow the
> administrator to diff the logs and see if the hardware have physically
> changed over time (Asset management implemented backwards, anyone? ;-).

Another usefull possability. It'll also be able to tell you who's using
such fun apps as I once did. Can be a REAL help when debugging DHCP setups
:)

> I have to note that I never did an extensive research in the area of MAC
> address changes, and the two examples above are just what I could remember
> off the top of my head ;-)

Same is true in my case...


Friendly greetings,
Terje Elde

-------------
NOTE:
My mail have been thrown from one system to another lately,
I might not have replied to all mails, if not, please let me know.