Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
ICMP
The Internet Control Message Protocol (ICMP) provides a mechanism to report errors and request information. The configuration parameters discussed here are managed in the IP driver.
Broadcasts
ICMP broadcasts are, at times, troublesome. A significant number of replies to a ICMP broadcast from all systems on a network could cause significant network performance degradation. An attacker might use ICMP broadcast requests to initiate a denial of service attack. It is best to disable the ability to respond to ICMP broadcasts. Internal ICMP rules prevent broadcast storms by governing when error messages should not be generated. The Solaris OE has several ICMP broadcast parameters, as described in the following sections.
Echo Request Broadcast
An echo request is a common network diagnostic created with the ping command. Echo requests can be sent to broadcast addresses. All systems configured to respond to broadcasted echo requests will send an echo reply. That can be a large number of packets. Even more devastating is the ability to increase the payload size of the packet. The receiving system will return all of the data contained in the payload. Extremely large payloads will be fragmented across several packets, thus further increasing network traffic. Use the following ndd command to disable response to echo request broadcasts:
# ndd -set /dev/ip ip_respond_to_echo_broadcast 0
Add this command to the system startup scripts. It is also included in the init script described in "Sample System nddconfig init Script" on page 26."
Echo Request Multicast
IPv6 does not have broadcast packets. It uses multicast packets instead. This is equivalent to the IPv4 broadcast echo request. All the same attacks apply. A Solaris 8 or 9 OE system can be instructed to ignore echo request multicasts with the following ndd command:
# ndd -set /dev/ip6 ip6_respond_to_echo_multicast 0
Add this command to the system start-up scripts. It is also included in the init script described in "Sample System nddconfig init Script" on page 26."
Timestamp Request Broadcast
Timestamp requests are often used to synchronize clocks between two systems. Individual timestamp requests are normal, but there is no need for a system to respond to a broadcasted request. Although these timestamp requests can be used to set a system's clock, they are not related to the Network Time Protocol (NTP). To synchronize system clock's throughout an enterprise, the recommended mechanism is NTP. Use the ndd command to disable responses to timestamp broadcasts.
# ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0
Add this command to the system start-up scripts. It is also included in the init script described in "Sample System nddconfig init Script" on page 26."
Address Mask Broadcast
An address mask request is used to determine the netmask for a network. It can be sent by diskless systems, such as printers or X-terminals, while booting. This type of request is typically broadcast. These requests are ignored by default and that configuration can be verified with the following ndd command:
# ndd /dev/ip ip_respond_to_address_mask_broadcast 0
This setting is also included in the init script described in "Sample System nddconfig init Script" on page 26."
Redirect Errors
Redirect errors are used by a router to inform a host sending data to forward the packets to a different router. Both routers involved in the redirection must be connected to the same subnet. The sending host will then install a new host routing entry in the routing table for the destination host. Unlike ARP entries, these will not time out and be deleted. Most systems check the redirect message for errors and potential problems prior to modifying the routing table.
Receiving Redirect Errors
An attacker might forge redirect errors to install bogus routes. This could initiate a denial of service attack if the newly specified router is not a router at all. There are rules governing valid redirect errors, all of which can be spoofed easily. Use this ndd command to ignore IPv4 ICMP redirect errors:
# ndd -set /dev/ip ip_ignore_redirect 1
Similarly, for IPv6, the system can be instructed to ignore redirects with this command:
# ndd -set /dev/ip ip6_ignore_redirect 1
Most environments with a single default router for each subnet will not need to accept redirects. Add this command to the system start-up scripts. It is also included in the init script described in "Sample System nddconfig init Script" on page 26."
Sending Redirect Errors
Only routers need to send redirect errors, not hosts or multihomed systems. Disable the sending of IPv4 redirect errors with this ndd command:
# ndd -set /dev/ip ip_send_redirects 0
Similarly, for IPv6, it is also possible to disable the generation of redirect errors with this ndd command:
# ndd -set /dev/ip ip6_send_redirects 0
Add this command to the system start-up scripts. It is also included in the init script described in "Sample System nddconfig init Script" on page 26".
Timestamp Requests
As mentioned previously, ICMP timestamp broadcasts are unnecessary in most environments. The Solaris OE software has the ability to disable unicast timestamp request responses. Disabling this setting prevents the system from responding to timestamp requests. Some UNIX_ systems using the rdate command will no longer be able to retrieve the time remotely. The Solaris OE rdate command uses the TCP time service provided by inetd and is not affected by remote systems that do not respond to ICMP timestamp requests. The following ndd command disables a Solaris OE systems from responding to unicast timestamp requests:
# ndd -set /dev/ip ip_respond_to_timestamp 0
Add this command to the system start-up scripts. It is also included in the init script described in "Sample System nddconfig init Script" on page 26".
The Solaris 2.6, 7, 8, and 9 OE releases include a better method for time synchronization across multiple systems using the Network Time Protocol (NTP) system. Refer to the xntpd man page for additional details.