[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] [SECURITY] preventing Hwaddr spoofing on bridge



RafaÅ Kupka wrote:

Hi,

This is great stuff, thanks a lot I was looking to spend some time on ebtables to solve these spoofing issues, I will try it and let you know if I find any problems I use aoe and even though it use mac filtering on its own I still believe Xen had some security issues un dealt with. Your correspondance seems to indicate its the case.

Best Regards,

On Sun, Nov 25, 2007 at 07:50:23AM +0000, Andy Smith wrote:
On Sun, Nov 25, 2007 at 02:53:04AM +0100, Stefan de Konink wrote:
Hi,

I see your point.  I hadn't thought of that problem before.  I have
done some preliminary testing with ebtables and the following seems
to work:

ebtables -t nat -A PREROUTING -i some-vif -s ! aa:00:00:6a:38:0c --log-level 
debug --log-prefix 'SPOOF:' -j DROP
So, I think this may be what is required.  I will keep the rule in
place for my test domains for a while just to check that it doesn't
get triggered incorrectly.

Can you still find a way to break it after using this method?

You can still impersonate other domUs IP addresses. Rooted domUs may
send spoofed arp replies with MAC address that belong to them.

It's especially easy when you shut down some domain for management --
other one can steal its IP address. With both domUs live attack is
harder but still possible (race with arp-reply delivery).

My solution:

Always put mac and IPs in config file like this:
vif = [ 'ip=192.168.1.2 192.168.1.3, script=vif-bridge,
          bridge=xen-br0,
          vifname=domainname.0,
          mac=00:16:3e:00:00:02',
       ]

Execute this as you setup Xen bridges (I call it from
/etc/network/interfaces, Debian way):
---
# repeat for each bridge
# chain-placeholder for rules on bridge xen-br0
/sbin/ebtables -N xen-br0
/sbin/ebtables -A xen-br0 --log-level notice --log-prefix "xen-br0" --log-ip 
--log-arp -j DROP

# jump to per-bridge chains
/sbin/ebtables -A INPUT --logical-in xen-br0 -j xen-br0
/sbin/ebtables -A FORWARD --logical-in xen-br0 -j xen-br0
# repeat: end

# drop all bridged packets by default
/sbin/ebtables -P INPUT DROP
/sbin/ebtables -P FORWARD DROP ---

At next -- modify /etc/xen/vif-bridge:
---
# after bridge= ....
mac=${mac:-}
mac=$(xenstore_read_default "$XENBUS_PATH/mac" "$mac")
ip=${ip:-}
ip=$(xenstore_read_default "$XENBUS_PATH/ip" "$ip")

# Add locking to ebtables
# Workaround for some kernel bug? Maybe unnecessary.
function ebtables()
{
        dotlockfile -p /etc/network/run/ebtables.lock
        /sbin/ebtables "$@"
        dotlockfile -u /etc/network/run/ebtables.lock
}

function add_vif_to_ebtables()
{
ebtables -N "$vif"
ebtables -I "$bridge" 1 -i "$vif" -j "$vif"
local addr
for addr in $ip
do
        ebtables -A "$vif" -p IPv4 -s "$mac" --ip-source "$addr" -j ACCEPT
        ebtables -A "$vif" -p ARP -s "$mac" --arp-mac-src "$mac" --arp-ip-src 
"$addr" -j ACCEPT
done
ebtables -A "$vif" --log-level notice --log-prefix "$vif" --log-ip --log-arp -j 
DROP
}

function del_vif_from_ebtables()
{
ebtables -D "$bridge" -i "$vif" -j "$vif"
ebtables -F "$vif"
ebtables -X "$vif"
}
---
add add_vif_to_ebtables and del_vif_from_ebtables to "case "$command" in" statement like this:

case "$command" in
    online)
        setup_bridge_port "$vif"
        add_vif_to_ebtables
        add_to_bridge "$bridge" "$vif"
        ;;

    offline)
        do_without_error brctl delif "$bridge" "$vif"
        del_vif_from_ebtables
        do_without_error ifconfig "$vif" down
        ;;
esac

That rules only allow IPv4 protocol and strictly bound IP with domain's
MAC address.

Can you still find a way to break it after using this method?

Regards,
Kupson


--
Steven Dugway


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.