Xen users - Nov 2007 - [SECURITY] preventing Hwaddr spoofing on bridge

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Is there a way to prevent hwaddr/mac address spoofing between DomU''s?


So in a way ''binding'' a mac-address on boot time with a
virtual
interface? (with something like ebtables/arptables/etc?)



Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHRkLWYH1+F2Rqwn0RCn91AJsEbAidtIyvnGvW2fKrqbHQd6mXYwCfZ9dK
9vAlXrAarwWGUObhGWB+V8E=ns5s
-----END PGP SIGNATURE-----

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

On Fri, Nov 23, 2007 at 04:02:46AM +0100, Stefan de Konink
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Is there a way to prevent hwaddr/mac address spoofing between
DomU''s?
> 
> 
> So in a way ''binding'' a mac-address on boot time with a
virtual
> interface? (with something like ebtables/arptables/etc?)

As far as I understand, 
you can solve your task with ebtables you have mentioned.


Why do you refuse to use it?
> 
> 
> 
> Stefan
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.7 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHRkLWYH1+F2Rqwn0RCn91AJsEbAidtIyvnGvW2fKrqbHQd6mXYwCfZ9dK
> 9vAlXrAarwWGUObhGWB+V8E> =ns5s
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
-- 
WBR, i.m.chubin


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

On Sat, Nov 24, 2007 at 05:12:25PM +0200, Igor Chubin
wrote:
> On Fri, Nov 23, 2007 at 04:02:46AM +0100, Stefan de Konink wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> > 
> > Is there a way to prevent hwaddr/mac address spoofing between
DomU''s?
> > 
> > 
> > So in a way ''binding'' a mac-address on boot time
with a virtual
> > interface? (with something like ebtables/arptables/etc?)
> 
> 
> As far as I understand, 
> you can solve your task with ebtables you have mentioned.
> 
Additional note.

You can modify vif-bridge script
to automagically add ebtables root
when domain U is started (and itc interfaces are created).



-- 
WBR, i.m.chubin


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

On Sat, Nov 24, 2007 at 05:17:09PM +0200, Igor Chubin
wrote:
> On Sat, Nov 24, 2007 at 05:12:25PM +0200, Igor Chubin wrote:
> > On Fri, Nov 23, 2007 at 04:02:46AM +0100, Stefan de Konink wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA512
> > > 
> > > Is there a way to prevent hwaddr/mac address spoofing between
DomU''s?
> > > 
> > > 
> > > So in a way ''binding'' a mac-address on boot
time with a virtual
> > > interface? (with something like ebtables/arptables/etc?)
> > 
> > 
> > As far as I understand, 
> > you can solve your task with ebtables you have mentioned.
> > 
> 
Additional note.

You can modify vif-bridge script
to automagically add ebtables rule
when domain U is started (and its interfaces are created).



Excuse me the typos.

-- 
WBR, i.m.chubin


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

On Fri, Nov 23, 2007 at 04:02:46AM +0100, Stefan de Konink
wrote:
> Is there a way to prevent hwaddr/mac address spoofing between
DomU''s?
I use ebtables alone to do this.  I have the list of MAC addresses
and IP addresses for each domU in a database, and from that I build
an ebtables ruleset.  ARP replies from a MAC that does not
correspond with its assigned IPs are dropped and logged.

Cheers,
Andy


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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Igor Chubin schreef:
> On Fri, Nov 23, 2007 at 04:02:46AM +0100, Stefan de Konink wrote:
> Is there a way to prevent hwaddr/mac address spoofing between
DomU''s?
> 
> 
> So in a way ''binding'' a mac-address on boot time with a
virtual
> interface? (with something like ebtables/arptables/etc?)
> 
> 
>> As far as I understand, 
>> you can solve your task with ebtables you have mentioned.
> 
> 
>> Why do you refuse to use it?
I don''t refuse to use it... I can break out of it with my current
configuration.


Could you post a rule set that binds an VIF to the known Xen MAC behind it?



Andy Smith schreef:
> On Fri, Nov 23, 2007 at 04:02:46AM +0100, Stefan de Konink wrote:
>> Is there a way to prevent hwaddr/mac address spoofing between
DomU''s?
>
> I use ebtables alone to do this.  I have the list of MAC addresses
> and IP addresses for each domU in a database, and from that I build
> an ebtables ruleset.  ARP replies from a MAC that does not
> correspond with its assigned IPs are dropped and logged.

It is *not* the IP addy that borks. It is a duplicate mac address in the
bridge. So I ''virtually'' take over a MAC address belonging to
someone
else on the bridge. Binding an IP address to a MAC address is too simple.


Full example:
Host 1 has mac


Host 2 knows about mac Host 1
Host 2 brings his interface down
Host 2 changes his mac to the mac of host 1
Host 2 brings his interface up. [breaks traffic to Host 1]

Now imagine Host 2 knows about all the macaddresses on the bridge and
does this in a loop...



Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHSNBNYH1+F2Rqwn0RCnfBAKCFMdugDMDloHF3szzZ2duK6lvbowCfcd+N
IO80TF1ua6pOn/diJ/atacw=tTO0
-----END PGP SIGNATURE-----

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

Hi Stefan,

On Sun, Nov 25, 2007 at 02:30:54AM +0100, Stefan de Konink
wrote:
> Andy Smith schreef:
> > On Fri, Nov 23, 2007 at 04:02:46AM +0100, Stefan de Konink wrote:
> >> Is there a way to prevent hwaddr/mac address spoofing between
DomU''s?
> >
> > I use ebtables alone to do this.  I have the list of MAC addresses
> > and IP addresses for each domU in a database, and from that I build
> > an ebtables ruleset.  ARP replies from a MAC that does not
> > correspond with its assigned IPs are dropped and logged.
> 
> 
> It is *not* the IP addy that borks. It is a duplicate mac address in the
> bridge. So I ''virtually'' take over a MAC address
belonging to someone
> else on the bridge. Binding an IP address to a MAC address is too simple.
I hard code all MAC addresses in the domain config file and when I
last tested any attempt to change the vif''s MAC address after that
results in no connectivity.  Is it still possible?

If so I don''t imagine it will be hard to tie MAC address to
interfaces with ebtables.

Cheers,
Andy


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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Andy,

Andy Smith schreef:
> On Sun, Nov 25, 2007 at 02:30:54AM +0100, Stefan de Konink wrote:
>> Andy Smith schreef:
>>> On Fri, Nov 23, 2007 at 04:02:46AM +0100, Stefan de Konink wrote:
>>>> Is there a way to prevent hwaddr/mac address spoofing between
DomU''s?
>>> I use ebtables alone to do this.  I have the list of MAC addresses
>>> and IP addresses for each domU in a database, and from that I build
>>> an ebtables ruleset.  ARP replies from a MAC that does not
>>> correspond with its assigned IPs are dropped and logged.
>>
>> It is *not* the IP addy that borks. It is a duplicate mac address in
the
>> bridge. So I ''virtually'' take over a MAC address
belonging to someone
>> else on the bridge. Binding an IP address to a MAC address is too
simple.
> 
> I hard code all MAC addresses in the domain config file and when I
> last tested any attempt to change the vif''s MAC address after that
> results in no connectivity.  Is it still possible?
Just do a xm console host2, then your host2 will be connected...
(basically simulates a ''script'' running)

> If so I don''t imagine it will be hard to tie MAC address to
> interfaces with ebtables.
I wonder *where* the bridge gets noticed about ''some interface has this
new hwaddr now''. I need to know which ruleset (FORWARD, INPUT, BROUTER,
OUTPUT, PREROUTING, etc.) I should limit for I *guess* an ARP packet.



Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHSNWAYH1+F2Rqwn0RCoFuAKCN90ALE8HN4dLEmHzR+k4tZKgh3gCeNhqi
xgbVAto/YjrpDN4P0T8fDfo=fWMW
-----END PGP SIGNATURE-----

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

Hi Stefan,

On Sun, Nov 25, 2007 at 02:53:04AM +0100, Stefan de Konink
wrote:
> Hi Andy,
> 
> Andy Smith schreef:
> > On Sun, Nov 25, 2007 at 02:30:54AM +0100, Stefan de Konink wrote:
> >> It is *not* the IP addy that borks. It is a duplicate mac address
in the
> >> bridge. So I ''virtually'' take over a MAC address
belonging to someone
> >> else on the bridge. Binding an IP address to a MAC address is too
simple.
> > 
> > I hard code all MAC addresses in the domain config file and when I
> > last tested any attempt to change the vif''s MAC address after
that
> > results in no connectivity.  Is it still possible?
> 
> Just do a xm console host2, then your host2 will be connected...
> (basically simulates a ''script'' running)
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

In this example I have a domU on some-vif with MAC address
aa:00:00:6a:38:0c.  I then log into console and issue:

# ifdown eth0
# ifconfig eth0 hw ether 00:16:4e:14:ae:10
# ifup eth0

00:16:4e:14:ae:10 is a MAC address of another domU on the same
bridge.

I then see in dom0''s syslog:

Nov 25 07:28:03 kwak kernel: SPOOF: IN=some-vif OUT= MAC source =
00:16:4e:14:ae:10 MAC dest = 33:33:00:00:00:16 proto = 0x86dd
Nov 25 07:28:04 kwak kernel: SPOOF: IN=some-vif OUT= MAC source =
00:16:4e:14:ae:10 MAC dest = 33:33:ff:14:ae:10 proto = 0x86dd

I receive no kernel message in domU about duplicate MAC addresses,
as I have previously when attempting this.  The bridge does not see
the MAC address shift from one port to another.  Connectivity to the
victim domU does not die as it had previously.

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?

Cheers,
Andy


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

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@lists.xensource.com
http://lists.xensource.com/xen-users

Hi,

On Tue, Nov 27, 2007 at 03:21:14PM +0100, Rafał Kupka
wrote:
> On Sun, Nov 25, 2007 at 07:50:23AM +0000, Andy Smith wrote:
> > 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
> > 
> > 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.
Yes I already addressed that in my earlier reply in this thread.
The previous one was specifically about spoofing MAC address, which
I had not considered until Stefan brought it up.

Cheers,
Andy


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

On Wed, 28 Nov 2007, Andy Smith wrote:
> On Tue, Nov 27, 2007 at 03:21:14PM +0100, Rafał Kupka wrote:
> > On Sun, Nov 25, 2007 at 07:50:23AM +0000, Andy Smith wrote:
> > > 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
> > >
> > > 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.
>
> Yes I already addressed that in my earlier reply in this thread.
> The previous one was specifically about spoofing MAC address, which
> I had not considered until Stefan brought it up.

I still need to verify the rules when I have a quiet moment. The problem
with DROP rules is always they need to be in a seperate chain... or
sequence will matter.



Stefan


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

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@lists.xensource.com
http://lists.xensource.com/xen-users