Re: 14 octet MACs and security

• Previous message: hakim: "dhclient DHCPREQUEST in logs"
• In reply to: Luigi: "14 octet MACs and security"
• Next in thread: Tauno Voipio: "Re: 14 octet MACs and security"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Wed, 10 Aug 2005 18:28:51 GMT

Luigi wrote:
> Hello all -
>
> I gave up on WEP for my home wireless network a long time ago.
> Instead, I have my gentoo router implement some strict policies on
> which hosts can access the network, on both the wired and unwired
> network.

Maybe you should un-giveup on WEP and see if you can let the router
reject some things for you without crapping up your system...
>
> One of my lines of defense is a mac address filter in my iptables
> NAT-ing firewall.
>
> #####
>
> iptables -t mangle -N maccheck
>
> # if a request comes in from eth0, check its MAC by jumping to the
> maccheck table
> iptables -t mangle -I PREROUTING -i eth0 -p tcp -j maccheck
>
> # create the maccheck table of allowed MACs
> allowed_mac="iptables -t mangle -A maccheck -m mac -j RETURN
> --mac-source "
>
> # if any of these match the current MAC, we return from this table
> without
> # doing anything
>
> $allowed_mac 00:12:12:12:12:12
> $allowed_mac 00:ab:ab:ab:ab:ab
>
> # otherwise, give any disallowed MAC address the mark 1 and log it
> iptables -t mangle -A maccheck -j MARK --set-mark 1 2>1 >> /dev/null
> iptables -t mangle -A maccheck -j LOG --log-prefix="set mark 1: " 2>1
>
>>>/dev/null
>
> #"
> iptables -t mangle -A maccheck -j RETURN >> /dev/null
>
> # force marked requests to the local webserver's
> # port 81 no matter what their intended destination, and deny all other
> tcp
> # requests

Sure looks like you will never get a hit on port 81, given that you
unconditionally REJECT the packet first. Am I misreading something?
>
> iptables -t nat -A PREROUTING -m mark --mark 1 -p tcp -j REJECT
> iptables -t nat -A PREROUTING -m mark --mark 1 -p tcp
> --destination-port 80 -j DNAT --to-destination=10.0.0.1:81
>
>
> ################
>
> Lately my clients have had trouble with an inability to renew their IPs
> (though getting the ip in the first place is fine). After checking
> dhcpd (it was fine), I started poking through logs, and found what
> looks like a network flood due to denied requests.
>
> from the output of dmesg:

May I suggest that use of log-level will let you put all the iptables
messages in a different and better place?
>
> set mark 1: IN=eth0 OUT= MAC=00:05:5d:81:04:46:00:02:2d:ba:96:98:08:00
> SRC=10.0.0.245 DST=192.168.0.107 LEN=48 TOS=0x00 PREC=0x00 TTL=128
> ID=10480 DF PROTO=TCP SPT=1760 DPT=9100 WINDOW=16384 RES=0x00 SYN
> URGP=0
>
> This is repeated many many times. I suspect it's one of my neighbors
> accidentally hopping onto my LAN via WiFi. Poor sucker gets an
> unprivelaged IP, and tries to access something that's local to his
> network, but which is obviously out of his subnet. Then he hammers it
> (and therefore, me) to death.

Don't bet on accidentally, and wouldn't using WEP prevent this?
>
> I'm happy my filter is working so well, but this brings up a few
> questions for me.
>
> 1) What's with his MAC adddress?
> 00:05:5d:81:04:46:00:02:2d:ba:96:98:08:00 is 14 octets... I have no
> idea what that means. I recognize the first 6 as belonging to my
> firewall's internal adapter, but what's up with the next 8?

You know how IPv6 is longer than IPv4? Don't you know about MACv6? Okay,
I'm kidding, I actually have no idea what's up. Does any of that look
like part of one of your MAC addresses? I'm thinking someone trying to
spoof your MAC address and botching the job.
>
> 2) Could this flood of unauthorized conn attempts be what's keeping my
> clients from refreshing their dhcp?

Anything is possible, my guess is no.
>
> 3) Unfortunately, just because I deny him access to anything doesn't
> mean that he isn't using my resources! If this is indeed what is
> causing a problem, what can I do to stop it? My wifi points don't have
> MAC filtering, and denying him DHCP entirely doesn't get rid of his
> connection attempts, either.
>
> Any thoughts?

- move your log files
- try to block the packets before they get into you network at all
   using WEP or whatever.
- MAC authentication isn't very strong
- unless you have a boatload of system which change often, ditch
   DHCP and use fixed IP addresses.

>
> Thanks!

Always glad to criticise ;-)

-- 
bill davidsen
   SBC/Prodigy Yorktown Heights NY data center
   http://newsgroups.news.prodigy.com

• Previous message: hakim: "dhclient DHCPREQUEST in logs"
• In reply to: Luigi: "14 octet MACs and security"
• Next in thread: Tauno Voipio: "Re: 14 octet MACs and security"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]