14 octet MACs and security

From: Luigi (vertesi_at_gmail.com)
Date: 08/10/05

  • Next message: Moe Trin: "Re: Traceroute not displaying getway IP address within Hops"
    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


  • Next message: Moe Trin: "Re: Traceroute not displaying getway IP address within Hops"