Hi all,
Link protection is a new feature we are planning to introduce to
Solaris and we would like to solicit your feedback on it.
Please see attached document for details.
thanks
eric
Introduction
------------
Link protection is a new mechanism being introduced to Solaris to protect
a host or network against hostile or mishaving elements within the
network.
By default, without special administrative policies, a user with superuser
privileges in Solaris or an owner of a virtual machine with a dedicated
stack/NIC can generate a packet of any shape and size to the network.
This can potentially be dangerous especially in an environment where each
individual host/VM cannot be trusted.
Currently, to protect against potentially harmful packets, one may use
the protection built into the switch hardware or deploy a software
mechanism such as a firewall. The issue with using the switch level
protection is that switch capabilities may vary and protection may only
be available on mid-range to high-end switches. In regards to using a
firewall, while the setup may not be difficult, it does require some
level of involvement from the administator such as understanding of the
rules syntax and maintenance of configuration files.
The motivation for this project is to introduce a built-in OS-level link
protection mechanism that is simple to configure, is extensible, and has
minimal impact on performance.
Proposed changes
----------------
We will introduce a new link property 'protection'. This property may
have no values (the default) or one or more of the following:
macnospoof MAC address anti-spoof. Outbound packet's source mac
address must match the link's configured mac address.
Non-matching packets will be dropped.
ipnospoof IP address anti-spoof. The ipnospoof list is a manually
configured ACL (discussed below). Outbound IP or ARP
packets may pass through only if there is a match for
their source IP address or sender protocol address
(for ARP) on this list.
whitelist Packets may pass through only if its type is on the
whitelist (discussed below).
The dladm command to enable all three types of protection is:
dladm set-linkprop -p protection=macnospoof,ipnospoof,whitelist <link>
To disable the protection:
dladm reset-linkprop -p protection <link>
ACLs (access control lists) are used in conjunction with the ipnospoof
and whitelist protection types. To manage ACLs, the following
subcommands will be added to dladm:
dladm add-acl -l <link> -a <attribute>,...,<attribute> <acl>
dladm remove-acl -l <link> -a <attribute>,...,<attribute> <acl>
dladm show-acl -l <link>
For this phase of the project, ACLs are built-in and custom ACLs are not
supported. This is why the create-acl and destroy-acl subcommands are
absent.
Here are the built-in ACLs for each link:
ACL name Protection Default values Possible values
------------------------------------------------------------------------
ipnospoof ipnospoof empty. All outbound Any IPv4 or IPv6
IP or ARP packets are address
dropped.
whitelist-in whitelist ipv4, ipv6, arp Any subset of
Any inbound packet ipv4, ipv6, arp
not matching one of
these protocols is
dropped.
whitelist-out whitelist ipv4, ipv6, arp Any subset of
Any outbound packet ipv4, ipv6, arp
not matching one of
these protocols is
dropped.
------------------------------------------------------------------------
ACLs may be modified at any time but they only take effect if the
corresponding protection type is set.
Below are some examples on how to use the *-acl subcommands:
# dladm add-acl -l vnic0 -a 10.0.0.1,10.0.0.2,10.0.0.3 ipnospoof
# dladm remove-acl -l vnic0 -a ipv6 whitelist-in
# dladm show-acl -l vnic0
ACL ATTR POSSIBLE
ipnospoof 10.0.0.1, 10.0.0.2, ipv4 or ipv6 address
10.0.0.3
whitelist-in ipv4, arp ipv4, ipv6, arp
whitelist-out ipv4, ipv6, arp ipv4, ipv6, arp
Other considerations
--------------------
There are two reasons for not supporting custom ACLs.
One of which is ease of use. For instance, to enable whitelist protection,
the user would just need to set the 'protection' link property to
'whitelist'; and if further customization is needed, one additional
add-acl or remove-acl command would suffice. Supporting custom ACLs would
require at least two more commands. One to create the ACL and another to
associate a protection type with the new ACL.
The other reason is related to the implementation of ACLs. Built-in ACLs
can be represented internally as link properties. The advantage of this
is that ACLs can benefit from the persistence and "reload-on-attach"
aspect of link properties; There is no need to add yet another
'dladm init-*' command to /lib/svc/method/net-physical and reinvent the
infrastructure for persistence.
The advantage of supporting custom ACLs is that the user would be able
to reuse the same ACL across multiple links. While we agree that this is
useful, the limitation of not being able to apply a predefined
configuration (be it link properties, flows, ACLs) across multiple links
is a general issue. We feel that it is best addressed by a higher level,
general solution, which is out-of-scope of this project.
Future work
-----------
Link protection is not meant to be a replacement for a full-fledged
firewall. Its target users are administrators who need basic protection
for the virtual environments they manage. The features discussed above
satisfy these requirements.
Here are some additional features planned:
-IP anti-spoof for DHCP assigned addresses
The filtering mechanism will need to become stateful to support this.
This is left out for the time being to reduce implementation complexity.
-Blacklist support and additional protocols for whitelist
Whitelists should be sufficient for most purposes but we do not object
to supporting blacklists as well if there are use cases.
-Protection for attacks that may require deeper packet inspection
Examples of such attacks are SYN flood, DHCP flood, DNS pollution.
_______________________________________________
networking-discuss mailing list
[email protected]
