IP
The Internet Protocol (IP) is the lower level protocol that provides bulk data transport. It is connectionless and makes no provisions for reliable delivery. The configuration parameters discussed in this article are controlled by the Solaris OE IP driver.
IP Forwarding
IP forwarding is the process of routing packets between network interfaces on one system. A packet arriving on one network interface and addressed to a host on a different network is forwarded to the appropriate interface. Routers handle a majority of this work, but a computer with multiple network interfaces can do this as well.
A Solaris OE system with more than one configured network interface forwards IP datagrams between network interfaces. It functions as a router. This is the default Solaris OE behavior.
Systems with multiple interfaces can be configured to function as multihomed servers. A multihomed system has several network interfaces, each with a separate IP address. It is not intended to route or forward packets but processes network requests from multiple, directly attached networks. A large NFS server can serve clients on several networks. The server response is faster and the throughput is greater when the NFS server is directly attached to each network of clients it serves.
Systems that allow packet forwarding are targets for attackers as they provide access to other systems and networks. Some of these systems are not normally accessible through routers. Multihomed servers can be attached to private, non-routed networks. If IP forwarding is enabled on a multihomed server, the private network is publicly reachable. Internal firewalls that limit access can be bypassed by forwarding packets through a multihomed server that is directly attached to the protected internal network.
Packet forwarding can easily be disabled on a Solaris OE system. Simply creating a file named /etc/notrouter will disable IPv4 IP forwarding at boot time. IP forwarding can also be switched on or off while the system is operating, using the ndd command. Use this command to disable IP forwarding for IPv4:
# ndd -set /dev/ip ip_forwarding 0
Similarly, the following command will disable forwarding of IPv6 packets:
# ndd -set /dev/ip6 ip6_forwarding 0
An attacker might compromise a system to enable packet forwarding; thereby, gaining access to normally inaccessible systems. This is another reason to make sure all servers are secure.
Since the release of the Solaris 8 OE there is an additional capability to enable IPv4 forwarding on an interface-by-interface basis. This provides greater flexibility in determining which interfaces will forward packets for the purposes of creating IP-in-IP tunnels. The following ndd commands will enable IPv4 IP forwarding on the hme1 and hme2 interfaces while disabling it on hme0:
# ndd -set /dev/ip hme0:ip_forwarding 0 # ndd -set /dev/ip hme1:ip_forwarding 1 # ndd -set /dev/ip hme2:ip_forwarding 1
Strict Destination Multihoming
Strict destination multihoming prevents packet spoofing on non-routing multihomed systems. A Solaris OE system with IP forwarding disabled and strict destination multihoming enabled will ignore packets coming into an interface that has addresses belonging to a network that is connected only to a different interface. This prevents attackers from creating packets destined for networks connected only to a multihomed server that does not forward packets. The system is aware of which interface the packet arrives on and if a packet appears to be from a network attached to another interface, the packet is dropped.
This feature can be enabled on the Solaris OE. It is disabled by default. Use the following ndd command to enable it for IPv4:
# ndd -set /dev/ip ip_strict_dst_multihoming 1
Similarly, for IPv6, strict destination multihoming can also be enabled through the following command:
# ndd -set /dev/ip ip6_strict_dst_multihoming 1
Add this command to the system startup scripts. Or alternatively, install the init script described in "Sample System nddconfig init Script" on page 26."
Forwarding Directed Broadcasts
A directed broadcast is a unicast datagram from a system on a remote network addressed to all systems on another network. Once the datagram reaches the router connected to the intended network, the datagram is forwarded to all systems as a data-link layer broadcast.
Directed broadcasts can be problematic due to the amount of network traffic generated by broadcasts and the ability to send a packet to all systems on a network. An attacker might take advantage of forwarded directed broadcasts to attack and probe systems. CERT Advisory CA-98.01 describes a denial of service attack called the smurf attack after its exploit program. It involves forged ICMP echo request packets sent to broadcast addresses. In this forged packet, the source address will be defined as a victim system or router. The result is that the victim and intermediate routing systems that forwarded the forged packet will suffer from network congestion. One recommended action is to disable directed broadcast forwarding at all routers. Attackers might also send directed broadcasts to probe the network and determine which systems have exploitable vulnerabilities.
When IP forwarding is enabled on a Solaris OE system, directed broadcasts will be forwarded by default.
Disable it by using the following ndd command:
# ndd -set /dev/ip ip_forward_directed_broadcasts 0
Add this command to the system startup scripts. Or alternatively, install the init script described in "Sample System nddconfig init Script" on page 26.
Routing
The process of routing involves examining a table of route information and making a decision about which interface to send datagrams based on the destination IP address. The routing table is the central point of information for each network host to determine where to send packets. Even a simple desktop system must determine whether the destination is on the local subnet (a direct route) or is reachable through a local router (an indirect route).
The routing table is periodically updated. Several routing information protocols exist to propagate routing information between systems and routers. The Solaris OE includes the in.routed and in.rdisc daemons to dynamically manage routing information. The in.routed daemon implements Routing Information Protocol (RIP), while the in.rdisc daemon implements ICMP Router Discovery. When a Solaris OE system is configured to forward packets as a router (IP forwarding enabled), by default these daemons advertise routing information to clients and other routers and listen to other routers for information. As new information is received, these daemons update the routing table. This method of managing routing information is known as dynamic routing.
NOTE
With the release of Solaris 9 OE (12/02) and RIPv2 compliance, a new MD5 authentication mechanism for RIP is supported in Solaris. For more information on how to use this new capability, refer to the rdisc and in.routed man pages. This new capability is based on RFC 2082 and provides more robust security capabilities then RIPv1. However, even with this authentication mechanism, the RIP packets are vulnerable to some attacks. Refer to Internet-Draft "RIPv2 authentication flaws."
There are several problems with dynamic routing that attackers can use to initiate denial of service attacks or view packet data from inaccessible systems. First, routing information can be forged. Routing information is typically sent via broadcast or multicast packets. An attacker can generate routing information packets claiming to be from a router and send them out to hosts or routers. These packets can direct hosts to send packets to a system that is not a router or to a busy router that cannot handle the increase in traffic. Misconfigured routers generate their own denial of service problems. A more sophisticated attack involves directing packets through a multihomed system to examine the packet data as it flows across this system that now functions as a router. The attacker sends forged routing information packets to a router claiming a lower hop count metric to a destination network that the attacker cannot access. The target router then routes packets through the compromised system allowing the attacker to examine the traffic.
By default, a Solaris OE system uses system daemons to dynamically manage routing information. Static routing can be used to prevent malicious remote routing changes. The Solaris OE defines a default route during startup based on the IP address of the router for the local subnet contained in /etc/defaultrouter. Define other static routes by using the route command. See the route man page for additional information. Static routing works in environments with a single router on each subnet. Networks with redundant routers may need to use dynamic routing so that systems can switch routers should one fail. A Solaris OE system functioning as a network router should continue to use dynamic routing.
Forwarding Source-Routed Packets
A source-routed packet specifies a routing path to follow. Normally, routing decisions are handled by routers. They maintain information on available routes and dynamically update them as new route information is received. Source-routed packets define their own paths and bypass routing decisions made by routers.
There is little need for source routing in most networks. Properly configured routers make better routing decisions. Source-routed packets are frequently an indication of nefarious activity. An attacker might attempt to use source-routed packets to bypass specific routers or internal firewalls or try to avoid a known network intrusion detection system by routing packets around it. Source-routed packets are rare. Silently dropping them should affect few, if any, legitimate applications.
When IP forwarding is enabled on a Solaris OE system, source-routed packets will be forwarded by default. It can be disabled for IPv4 with this ndd command:
# ndd -set /dev/ip ip_forward_src_routed 0
Similarly, for IPv6, source-routed packets can be disabled through the use of this ndd command:
# ndd -set /dev/ip6 ip6_forward_src_routed 0
Add this command to the system startup scripts. Or alternatively, install the init script described in "Sample System nddconfig init Script" on page 26.