[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] [SECURITY] preventing Hwaddr spoofing on bridge
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 -- Great software without the knowledge to run it is pretty useless. (Linux Gazette #1) _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |