Zones are particularly attractive in securing those two networking entities.
This is because zones are fundamental to the IaaS cloud service model.
This assures zones will never be a vector for common L2/L3 attacks.
Zones can use two different kind of protected networking resources:
net
Refers to either a physical NIC or a predefined virtual NIC (vnic).
The protection is given by the allowed-address and the configure-allowed-address parameters. This will automatically set ip-nospoof for the underlying link, but currently it will make it impossible to set the mac-nospoof (sort of bug or limitation).
anet
Automatically creates a vnic according to parameters.
Naturally, the underlying link (lower-link) can't be another vnic.
The protection is given by the link-protection parameter, but
its setting is somewhat automatic along the setting of allowed-address and the configure-allowed-address parameters. I say somewhat because they set the ip-nospoof. But it may be good to add the mac-nospoof.
Hence, at a minimum, no matter if net or anet is used, what's important is to set the allowed-address and configure-allowed-address parameters. But if using anet, then also set the link-protection to mac-nospoof.
For instance:
# zonecfg -z server-1b info net
net:
address not specified
allowed-address: 192.168.0.12/24
configure-allowed-address: true
physical: net2
defrouter not specified
But the protection technology isn't restricted to non-global zones (NGZ).
In fact, this networking protection technology is totally independent.
As such they can be used in global zones (GZ) as well.
