ebtables and anti-spoofing rules not working 100%?

ebtables and anti-spoofing rules not working 100%?

[Tomasz Chmielewski]

I have a kvm host and two kvm guests running on it.


kvm1 is assigned 1.2.3.4 IP with 11:22:33:44:55:66 MAC; uses vmtab107i0 bridged tap interface.

kvm2 is assigned 1.2.3.22 IP with AA:BB:CC:DD:EE:FF MAC.



To prevent spoofing, I created these ebtables rules:

# create a chain for kvm1
ebtables -N vm107

# drop everything, unless it's accepted later
ebtables -P vm107 DROP

# guest communication with the gateway
ebtables -A INPUT -i vmtab107i0 -j vm107
ebtables -A OUTPUT -o vmtab107i0 -j vm107

# guest communication with the world
ebtables -A FORWARD -o vmtab107i0 -j vm107

# allow 1st IP with this MAC
ebtables -A vm107 -p IPv4 -s 11:22:33:44:55:66 --ip-src 1.2.3.4 -j ACCEPT 
ebtables -A vm107 -p IPv4 -d 11:22:33:44:55:66 --ip-dst 1.2.3.4 -j ACCEPT 

# allow broadcast traffic
ebtables -A vm107 -p IPv4 --ip-dst 1.2.3.64 -j ACCEPT 

# log everything else
ebtables -A vm107 --log-level debug --log-prefix "unexpected vm107 traffic: " --log-ip --log-arp -j CONTINUE 


And it works - if kvm1 changes IP address, it's not able to communicate and "unexpected" traffic is logged.


However, when I change MAC and IP on kvm1 to match this on kvm2:

ifconfig eth0 hw ether AA:BB:CC:DD:EE:FF
ifconfig eth0 1.2.3.22

and then arping the gateway from kvm1:

arping 1.2.3.1

kvm2 "looses" its connectivity.


I see these packets logged, so they should be dropped as well (policy is set to DROP). However, it doesn't seem to be the case.

Why do these packets get through?

What anti-spoofing rules I need to have to prevent some kvm guests pretending to be other kvm guests (or, even pretending to be "gateways")?


-- 
Tomasz Chmielewski
http://wpkg.org

Re: ebtables and anti-spoofing rules not working 100%?

[Pascal Hambourg]

Hello,

Tomasz Chmielewski a écrit :
> I have a kvm host and two kvm guests running on it.
> 
> kvm1 is assigned 1.2.3.4 IP with 11:22:33:44:55:66 MAC; uses vmtab107i0 bridged tap interface.
> kvm2 is assigned 1.2.3.22 IP with AA:BB:CC:DD:EE:FF MAC.
> 
> To prevent spoofing, I created these ebtables rules:
> 
> # create a chain for kvm1
> ebtables -N vm107
> 
> # drop everything, unless it's accepted later
> ebtables -P vm107 DROP
> 
> # guest communication with the gateway
> ebtables -A INPUT -i vmtab107i0 -j vm107
> ebtables -A OUTPUT -o vmtab107i0 -j vm107

Do you need to prevent spoofing by the host itself ?

> # guest communication with the world
> ebtables -A FORWARD -o vmtab107i0 -j vm107
> 
> # allow 1st IP with this MAC
> ebtables -A vm107 -p IPv4 -s 11:22:33:44:55:66 --ip-src 1.2.3.4 -j ACCEPT 

I don't see how this rule would match anything in the OUTPUT chain.

> ebtables -A vm107 -p IPv4 -d 11:22:33:44:55:66 --ip-dst 1.2.3.4 -j ACCEPT 
> 
> # allow broadcast traffic
> ebtables -A vm107 -p IPv4 --ip-dst 1.2.3.64 -j ACCEPT 

Spoofing protection is about the source, not the destination, so these
two rules are pointless.

[...]
> What anti-spoofing rules I need to have to prevent some kvm guests
> pretending to be other kvm guests (or, even pretending to be "gateways")?

Just create rules called from INPUT and FORWARD which match the input
interface (bridge port) and the MAC and IP source address.

ebtables -A INPUT -i vmtab107i0 -j vm107
ebtables -A FORWARD -i vmtab107i0 -j vm107

ebtables -A vm107 -p IPv4 -s 11:22:33:44:55:66 --ip-src 1.2.3.4 \
  -j ACCEPT
ebtables -A vm107 -p ARP -s 11:22:33:44:55:66 \
  --arp-mac-src 11:22:33:44:55:66 --arp-ip-src 1.2.3.4 -j ACCEPT

Re: ebtables and anti-spoofing rules not working 100%?

[Tomasz Chmielewski]

On 29.08.2010 17:28, Pascal Hambourg wrote:

>> # guest communication with the gateway
>> ebtables -A INPUT -i vmtab107i0 -j vm107
>> ebtables -A OUTPUT -o vmtab107i0 -j vm107
>
> Do you need to prevent spoofing by the host itself ?

Host is "trusted", so it doesn't need any additional measures.
Guests, on the other hand, are to be "untrusted".


>> What anti-spoofing rules I need to have to prevent some kvm guests
>> pretending to be other kvm guests (or, even pretending to be "gateways")?
>
> Just create rules called from INPUT and FORWARD which match the input
> interface (bridge port) and the MAC and IP source address.
>
> ebtables -A INPUT -i vmtab107i0 -j vm107
> ebtables -A FORWARD -i vmtab107i0 -j vm107
>
> ebtables -A vm107 -p IPv4 -s 11:22:33:44:55:66 --ip-src 1.2.3.4 \
>    -j ACCEPT
> ebtables -A vm107 -p ARP -s 11:22:33:44:55:66 \
>    --arp-mac-src 11:22:33:44:55:66 --arp-ip-src 1.2.3.4 -j ACCEPT

With these rules, I'm not able to communicate (i.e. ping) with other 
hosts in the same subnet, except the gateway (although this was the same 
with my previous rules, I think).


Also, if I do this on the "rogue" guest (with MAC, IP belonging to the 
"other" guest):

ifconfig eth0 hw ether AA:BB:CC:DD:EE:FF
ifconfig eth0 1.2.3.22


any communication to the "other" still breaks (from external hosts). So, 
no improvement.


-- 
Tomasz Chmielewski
http://wpkg.org

Re: ebtables and anti-spoofing rules not working 100%?

[Jonathan Tripathy]

On 29/08/10 17:46, Tomasz Chmielewski wrote:
> On 29.08.2010 17:28, Pascal Hambourg wrote:
>
>>> # guest communication with the gateway
>>> ebtables -A INPUT -i vmtab107i0 -j vm107
>>> ebtables -A OUTPUT -o vmtab107i0 -j vm107
>>
>> Do you need to prevent spoofing by the host itself ?
>
> Host is "trusted", so it doesn't need any additional measures.
> Guests, on the other hand, are to be "untrusted".
>
>
>>> What anti-spoofing rules I need to have to prevent some kvm guests
>>> pretending to be other kvm guests (or, even pretending to be 
>>> "gateways")?
>>
>> Just create rules called from INPUT and FORWARD which match the input
>> interface (bridge port) and the MAC and IP source address.
>>
>> ebtables -A INPUT -i vmtab107i0 -j vm107
>> ebtables -A FORWARD -i vmtab107i0 -j vm107
>>
>> ebtables -A vm107 -p IPv4 -s 11:22:33:44:55:66 --ip-src 1.2.3.4 \
>>    -j ACCEPT
>> ebtables -A vm107 -p ARP -s 11:22:33:44:55:66 \
>>    --arp-mac-src 11:22:33:44:55:66 --arp-ip-src 1.2.3.4 -j ACCEPT
>
> With these rules, I'm not able to communicate (i.e. ping) with other 
> hosts in the same subnet, except the gateway (although this was the 
> same with my previous rules, I think).
>
>
> Also, if I do this on the "rogue" guest (with MAC, IP belonging to the 
> "other" guest):
>
> ifconfig eth0 hw ether AA:BB:CC:DD:EE:FF
> ifconfig eth0 1.2.3.22
>
>
> any communication to the "other" still breaks (from external hosts). 
> So, no improvement.
>
>
Why do you need to use the INPUT chain with ebtables in a VM 
environment? In my ebtables setup, I have INPUT to drop everything, 
except stuff from/to the loopback interface (lo)

Cheers

Re: ebtables and anti-spoofing rules not working 100%?

[Tomasz Chmielewski]

On 29.08.2010 19:25, Jonathan Tripathy wrote:

>> Also, if I do this on the "rogue" guest (with MAC, IP belonging to the
>> "other" guest):
>>
>> ifconfig eth0 hw ether AA:BB:CC:DD:EE:FF
>> ifconfig eth0 1.2.3.22
>>
>>
>> any communication to the "other" still breaks (from external hosts).
>> So, no improvement.
>>
>>
> Why do you need to use the INPUT chain with ebtables in a VM
> environment? In my ebtables setup, I have INPUT to drop everything,
> except stuff from/to the loopback interface (lo)

I can use anything, as long as it "pins" given MAC/IP addresses to a VM 
guest - and that any "rogue" guest is not able to disrupt traffic to 
other VM guests (or, worse, the gateway) - i.e. by changing its own 
IP/MAC to something else, possibly addresses used by other guests / gateway.


-- 
Tomasz Chmielewski
http://wpkg.org

Re: ebtables and anti-spoofing rules not working 100%?

[Jonathan Tripathy]

On 29/08/10 18:34, Tomasz Chmielewski wrote:
> On 29.08.2010 19:25, Jonathan Tripathy wrote:
>
>>> Also, if I do this on the "rogue" guest (with MAC, IP belonging to the
>>> "other" guest):
>>>
>>> ifconfig eth0 hw ether AA:BB:CC:DD:EE:FF
>>> ifconfig eth0 1.2.3.22
>>>
>>>
>>> any communication to the "other" still breaks (from external hosts).
>>> So, no improvement.
>>>
>>>
>> Why do you need to use the INPUT chain with ebtables in a VM
>> environment? In my ebtables setup, I have INPUT to drop everything,
>> except stuff from/to the loopback interface (lo)
>
> I can use anything, as long as it "pins" given MAC/IP addresses to a 
> VM guest - and that any "rogue" guest is not able to disrupt traffic 
> to other VM guests (or, worse, the gateway) - i.e. by changing its own 
> IP/MAC to something else, possibly addresses used by other guests / 
> gateway.
>
>
Yes, but the INPUT chain is only relevant for traffic destined for the 
host itself. Does the host actually do anything in your case, or is it 
just a bridging device?

Re: ebtables and anti-spoofing rules not working 100%?

[Tomasz Chmielewski]

On 29.08.2010 20:23, Jonathan Tripathy wrote:

>> I can use anything, as long as it "pins" given MAC/IP addresses to a
>> VM guest - and that any "rogue" guest is not able to disrupt traffic
>> to other VM guests (or, worse, the gateway) - i.e. by changing its own
>> IP/MAC to something else, possibly addresses used by other guests /
>> gateway.
>>
>>
> Yes, but the INPUT chain is only relevant for traffic destined for the
> host itself. Does the host actually do anything in your case, or is it
> just a bridging device?

Not sure I understand your question correctly, or if we refer to the 
same thing if we use "host".


The "host system" is a bridge and gateway, and runs VM guests (KVM).


As guests are fully virtualized systems, they are technically free to 
change their IP and MAC address (users have root access). This means 
they can be a danger to other virtual guests, or generally network 
infrastructure, if they change their IP or MAC addresses to something 
different they should have.

Therefore, I would like to prevent it, but so far, my tries with 
iptables or ebtables were not really successful.


-- 
Tomasz Chmielewski
http://wpkg.org

Re: ebtables and anti-spoofing rules not working 100%?

[Pascal Hambourg]

Tomasz Chmielewski a écrit :
> On 29.08.2010 17:28, Pascal Hambourg wrote:
> 
>>> # guest communication with the gateway
>>> ebtables -A INPUT -i vmtab107i0 -j vm107
>>> ebtables -A OUTPUT -o vmtab107i0 -j vm107
>> Do you need to prevent spoofing by the host itself ?
> 
> Host is "trusted", so it doesn't need any additional measures.
> Guests, on the other hand, are to be "untrusted".

Then filtering in OUTPUT is unnecessary.

>>> What anti-spoofing rules I need to have to prevent some kvm guests
>>> pretending to be other kvm guests (or, even pretending to be "gateways")?
>>
>> Just create rules called from INPUT and FORWARD which match the input
>> interface (bridge port) and the MAC and IP source address.
>>
>> ebtables -A INPUT -i vmtab107i0 -j vm107
>> ebtables -A FORWARD -i vmtab107i0 -j vm107
>>
>> ebtables -A vm107 -p IPv4 -s 11:22:33:44:55:66 --ip-src 1.2.3.4 \
>>    -j ACCEPT
>> ebtables -A vm107 -p ARP -s 11:22:33:44:55:66 \
>>    --arp-mac-src 11:22:33:44:55:66 --arp-ip-src 1.2.3.4 -j ACCEPT
> 
> With these rules, I'm not able to communicate (i.e. ping) with other 
> hosts in the same subnet, except the gateway (although this was the same 
> with my previous rules, I think).

Of course these rules are just a part of the ruleset. Did you do the
same for all other bridge ports and hosts in the subnet ?

Re: ebtables and anti-spoofing rules not working 100%?

[Tomasz Chmielewski]

On 30.08.2010 20:14, Pascal Hambourg wrote:

>> With these rules, I'm not able to communicate (i.e. ping) with other
>> hosts in the same subnet, except the gateway (although this was the same
>> with my previous rules, I think).
>
> Of course these rules are just a part of the ruleset. Did you do the
> same for all other bridge ports and hosts in the subnet ?

No, I did not.

So even if it's blocked on one bridge, rogue MAC/IP can still "get 
outside" and interfere with other bridges/guests?



-- 
Tomasz Chmielewski
http://wpkg.org

Re: ebtables and anti-spoofing rules not working 100%?

[Pascal Hambourg]

Tomasz Chmielewski a écrit :
> On 30.08.2010 20:14, Pascal Hambourg wrote:
> 
>>> With these rules, I'm not able to communicate (i.e. ping) with other
>>> hosts in the same subnet, except the gateway (although this was the same
>>> with my previous rules, I think).

I am not very experienced with ebtables, so maybe I missed something. I
quickly tested these rules with two hosts and they seemed to work as
expected.

>> Of course these rules are just a part of the ruleset. Did you do the
>> same for all other bridge ports and hosts in the subnet ?
> 
> No, I did not.

Communication is two-way. The rules I suggested accept only one way. The
other way depends on the rest of the rules.

> So even if it's blocked on one bridge, rogue MAC/IP can still "get 
> outside" and interfere with other bridges/guests?

That would imply that the host is connected to multiple bridges. Of
course each bridge is independent.