[TriLUG] spoofing mac addresses

[Aaron S. Joyner]

paul wrote:

>Thanks for the insight! I understood the part about the nic
>having/*needing* one mac address, but I hadn't thought of trying to put
>the nic into promiscuous mode and trying to add hardware addresses that
>way. Theoretically, with a card that supports monitor mode (these are
>Intel e100 and e1000), -promisc with ifconfig would set the card into
>promisc mode, though how to tell it to answer to multiple hw addresses
>is still a mystery. But not for long methinks.
>
>Thanks.
>
>Paul
>
>  
>
The kicker here isn't getting it to respond to multiple MACs, or even 
redirect MACs as Ryan suggested, but to *associate* a particular MAC 
address with a particular address.  You'd need some way, at the kernel 
level, to tell the OS that if a packet has a certain source address to 
send it with a certain Ethernet header.  When you're composing 
individual packets and stuffing them in at the driver layer (how various 
arp poisoning attacks like Ryan describe do their dirty work), it's not 
so difficult to do.  But you want to make a more large-scale 
modification to the way the OS is determining what MAC address to use 
when sending out packets.  I did some cursory googling around to find a 
way to accomplish this task, but to no avail.  I think this would be 
neat functionality to see in iptables or the iproute2 tools (or some 
derivative) in the future, but presently I just don't think Linux is 
capable of doing what you have in mind, in a wholesale manner.

Hmm... perhaps if you ran multiple VMWare instances, and assigned each 
VMWare instance one of the IPs in question, VMWare would handle the 
associations for you -- but you're talking monstrous overhead.  That 
suggestion is really only meant to be humorous.  :)

This all begs the question, why are you trying to do this?  It seems as 
if either a) you're trying to bend the rules being imposed on you at a 
network layer (fine by me, but perhaps we can help you come up w/ a 
better way) or b) you're thinking about the problem with some ill 
conceived assumptions.  Perhaps a more thorough explanation would 
provide more outside-the-box ideas.

Aaron S. Joyner