Re: [SLUG] hosts.allow/deny by MAC instead of IP

From: Mike Branda (mike@wackyworld.tv)
Date: Fri Nov 19 2004 - 10:08:53 EST


On Thu, 2004-11-18 at 01:39, Scotty Logan wrote:
> iptables has a mac address matching model, so something like the
> following should work:
>
> iptables -A INPUT -m state --state NEW -m mac --mac-addresss
> aa:bb:cc:dd:ee:ff -m tcp -p tcp --dport 22 -j ACCEPT

I used something similar to this that I found before your post with the
exception of the packet state.

> There are two problems with filtering by MAC address. MAC addresses
> are trivially spoofed - the following works on many (most?) NICs under
> Linux
>
> ifconfig ethN hw ether aa:bb:cc:dd:ee:ff
>

Yeah, I know. But when trying to remote login from RR at home DHCP
kills me because I have to leave all of a particular South Eastern IP
Block open to account for DHCP renew address changes. For example
44.0.0.0 cause the last 2 renews after power outages changed the second
digit (44.x.0.0). Not to mention if it rolls to one of the 4 other RR
blocks I've seen. So the thought was if I could do it by MAC, 1.) I
wouldn't have to leave millions of addresses open to get a rise out of
the sshd and 2.) when I travel, It wouldn't matter the IP I was logging
in from if it was MAC based. 1 MAC vs. all those IP's. My major
concern is that I've already moved ssh to a non standard port which has
kept me under the radar of the recent ssh scan attempts but somebody can
still portscan me. If they are not in the proper IP block on top of it,
sshd doesn't respond.

> MAC addresses are only used within ethernet broadcast domains, so
> they're not visible on the other side of gateways.

Sure enough, this is the kicker. Since the packet goes:
application-->tcp-->IP-->MAC and the next router strips the mac and I'm
assuming adds it's own, the final stop never sees my originating MAC
address.

Oh well.... back to brainstorming.

Mike Branda Jr.

-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 17:42:51 EDT