14 octet MACs and security

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

Luigi wrote:

> 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.

MAC addresses can be spoofed.

Of course they can - but that's not my only line of defense. WEP can
be cracked, too, with such alarming ease that it's not worth even
having.

Besides, that is not the point. What's with the long MAC address, and
could this be what's causing my clients to lose their connection?

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

Luigi wrote:
>
> 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?

The thing with 14 octets is the whole Ethernet packet
header. Lets pick the it into components:

00:05:5d:81:04:46:
00:02:2d:ba:96:98:
08:00

The first 6 octets are the receiving station MAC address,
the second 6 octets are sending station MAC address,
the last 2 octets are the payload type: 0x0800 = IP.

HTH

--

Tauno Voipio
tauno voipio (at) iki fi

On 9 Aug 2005 17:21:09 -0700, Luigi <(E-Mail Removed)> wrote:
> 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...
(snip)
>
> ################
>
> 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.

Are you running open system with a dhcp server, just because WEP can be
cracked (with a good deal of effort)? It probably is useful for limiting
anyone other than crackers from hammering your system, like your clueless
neighbor who cannot figure out why they cannot print to their JetDirect.
You certainly should NOT do dhcp if running open system.

I have not had any unauthorized access to my wireless, just doing WEP,
MAC limits, and nonstandard netmask on my WAP. But my WAP is in my
basement, so someone would have to be in my yard or driveway to sense it.

On Tue, 09 Aug 2005 17:21:09 -0700, 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.
>
> One of my lines of defense is a mac address filter in my iptables
> NAT-ing firewall.
>
<snip: wheel spinning>
> ################
>
> 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
>
How do you know your neighbor isn't doing this deliberately. By not using
encyrption, I would argue you are inviting people in, "please, use my
network." I am not a lawyer, but that is my take on this situation:

Case 1: An encrypted will require a hack to get through, therefore
illegal.

Case 2: An open network is just that, open. Anyone may access because
your dhcp gives them an address which is an invitation in my book.

Your "many lines of defense" appears to start with a big handicap. Just
use WPA-PSK. Your neighbors "Windows" will see this as protected network
and will not be able to connect to it.

Here's a clue:
http://www.tomsnetworking.com/Sections-article118.php

And some good recent advice found on slashdot:
http://hardware.slashdot.org/comment...4&cid=13250526

--
Ripley: And you let him in.
http://us.imdb.com/title/tt0078748/quotes

Okay, Okay, I'll break down and add authentication to the wireless ...
And many thanks to Tauno for explaining the MAC for me. The
accompanying problem is that I have 2 WAPs at opposite ends of the
house... If I give them the same SSID and the same WPA requirements,
will it seem transparent to the users?

Incidentallly, I use DHCP for this 14 machine house because I'm away
from home most of the year, and my father is JUST clueless enough to
reinstall Windows every few months when something goes wrong... but
would have a hard time re-setting manual IP settings every time. So
machines are assigned static IPs via DHCP, unless they are unknown MACs
or hostnames in which case they get a specific range of unprivelaged
IPs that are on an alert list to email me their activity.

This is all beside the point however, because I'm still left with my
original problem of clients getting kicked from their net
connections... Perhaps the list can help me here?

Clients get IPs just fine, but after an irregular period of time, they
lose their connection, and are unable to renew their IPs. I checked
and changed my DHCPD lease time, but that seems to have no bearing on
it. I suspect that it is to do with the amount of data transferred. I
can find no evidence of the kickings or DHCP renew requests in
logfiles. I even tried tcpdump and saw no renew requests. So far as
DHCPD knows, these connections are timing out. In fact, there is no
evidence of the kickings or subsequent requests ANYWHERE on the server
(that I can see).

This complete lack of data transmission makes me suspect the switch,
though it seems odd for a switch to lock out a connection after a
certain amount of activity. Am I nuts? What else should I be checking
here?

Thanks!

On 11 Aug 2005 11:24:04 -0700, Luigi <(E-Mail Removed)> wrote:
(snip)
> This is all beside the point however, because I'm still left with my
> original problem of clients getting kicked from their net
> connections... Perhaps the list can help me here?
>
> Clients get IPs just fine, but after an irregular period of time, they
> lose their connection, and are unable to renew their IPs. I checked
> and changed my DHCPD lease time, but that seems to have no bearing on
> it. I suspect that it is to do with the amount of data transferred. I
> can find no evidence of the kickings or DHCP renew requests in
> logfiles. I even tried tcpdump and saw no renew requests. So far as
> DHCPD knows, these connections are timing out. In fact, there is no
> evidence of the kickings or subsequent requests ANYWHERE on the server
> (that I can see).
>
> This complete lack of data transmission makes me suspect the switch,
> though it seems odd for a switch to lock out a connection after a
> certain amount of activity. Am I nuts? What else should I be checking
> here?

What specific nics and modules are used to wire the WAPs? I have had
trouble with Dlink DFE-530TX+ nics using 8139too, sometimes going into a
frenzy (flickering LED's) with heavy packet loss. At one point this made
me think that my Linksys WAP11 was incompatible with my Linksys EFSP42
switch/printserver. My solution was to use -A 10baseT-FD,10baseT-HD
switch for mii-tool. Older 8139too module versions might not have
mii-tool support.

I also had a wireless router whose switch ports refused to autonegotiate
speed with any laptop 10/100 PC card nic (16-bit or cardbus) unless the
nic was slowed. Desktop PCI cards were no problem.

Maybe slowing the speed is not a real solution (my wireless is only 11
mbps anyway). But it might help isolate the cause if related to speed
autonegotiation (which may appear to be a flood, even though no data is
being passed).

I never knew that sort of incomratibility existed! Here is my setup

3c59x (via rhine) -> D Link DI604 router

DI604 has a Linksys BEFW114 Wi-b router attached, and a Linksys EZXS88W
switch

EZXS88W has a Linksys WAP54G acesspoint.

All of the routers have dhcp and routing disabled, and nothing in the
WAN port, so they act like switches.

An odd thing that I noticed; only some of the machines are affected by
the kickings... the worst are two windows xp boxes attached to the
BEFW114 and the EZXS88W , respectively. The common point is in the
front switch, the DI604 ... but some of my other clients are fine! My
Mac laptop for instance, has downloaded plenty through both wireless
points, and has yet to be kicked.

I will try a system wide switch reset today. The question is, if it
works, how do I keep this from becoming a chronic problem?

Thanks

C