14 octet MACs and security
From: Luigi (vertesi_at_gmail.com)
Date: 08/10/05
- Previous message: g_r_a_n_t__at_dodo.com.au: "Re: DHCP combined with MySQL"
- Next in thread: James Knott: "Re: 14 octet MACs and security"
- Reply: James Knott: "Re: 14 octet MACs and security"
- Reply: Bill Davidsen: "Re: 14 octet MACs and security"
- Reply: Tauno Voipio: "Re: 14 octet MACs and security"
- Reply: David Efflandt: "Re: 14 octet MACs and security"
- Reply: Douglas Mayne: "Re: 14 octet MACs and security"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 9 Aug 2005 17:21:09 -0700
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.
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
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:
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.
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?
2) Could this flood of unauthorized conn attempts be what's keeping my
clients from refreshing their dhcp?
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?
Thanks!
Cam
- Previous message: g_r_a_n_t__at_dodo.com.au: "Re: DHCP combined with MySQL"
- Next in thread: James Knott: "Re: 14 octet MACs and security"
- Reply: James Knott: "Re: 14 octet MACs and security"
- Reply: Bill Davidsen: "Re: 14 octet MACs and security"
- Reply: Tauno Voipio: "Re: 14 octet MACs and security"
- Reply: David Efflandt: "Re: 14 octet MACs and security"
- Reply: Douglas Mayne: "Re: 14 octet MACs and security"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|