Strict Destination Multihoming:
Strict destination multihoming prevents packet spoofing on nonforwarding multihomed systems. A Solaris system with IP forwarding disabled and strict destination multihoming enabled will ignore packets sent to an interface from which it did not arrive. This prevents attackers from creating packets destined for networks
only connected to a multihomed server that does not forward packets.
The system is aware of which interface on which a packet arrives. 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 Operating Environment. It is disabled by default. Use the following ndd command to enable it:
Add this command to the init scripts.
# ndd -set /dev/ip ip_forwarding 0
# ndd -set /dev/ip ip_strict_dst_multihoming 1
Forwarding Directed Broadcasts:
A directed broadcast is a unicast datagram from a system on a remote network addressed 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 may 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. The source address in the forged packet is set to a target. The result is that the target and intermediate routing machine which forwards the directed broadcasts suffered from network congestion.
One recommended action is to disable directed broadcast forwarding at all routers. Attackers may also send directed broadcasts to probe the network and determine which systems have exploitable vulnerabilities.
Routing:
The process of routing involves examining a table of route information and making a decision about which interface to send datagrams. 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 may need to be updated from time to time. There are several routing information protocols that are used to propagate routing information.
The Solaris Operating Environ ment uses the in.routed and in.rdisc daemons to dynamically manage routing information. in.routed understands the Routing Information Protocol (RIP), version 1. in.rdisc implements ICMP Router Discovery. When a Solaris system is configured to forward packets as a router (IP forwarding enabled), these daemons advertise routing information to clients and
# ndd -set /dev/ip ip_forward_directed_broadcasts 0
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.
There are several problems with dynamic routing that attackers can use to create denial of service attacks or to 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. Most network administrators have a story about dynamic routing gone awry. 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
which now functions as a router.
The attacker sends forged routing information packets to a router claiming a lower hop count 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 system uses system daemons to dynamically manage routing information. Static routing can be used to prevent malicious remote routing changes.
The Solaris Operating Environment defines a default route by creating a file named /etc/defaultrouter containing the IP address of the router for local subnet. Other static route can be defined using the “route” command. See the man page on “route” for more information. Static routing works in environments with a single router to other networks.
Networks with redundant routers need to use dynamic routing so that systems can switch to a working router should one fail. Solaris systems functioning as network routers should continue to use dynamic routing.
ICMP:
The Internet Control Message Protocol (ICMP) provides a mechanism to report errors and request information. The configuration parameters discussed here are managed in IP driver.
Broadcasts:
ICMP broadcasts are always troublesome. There are rules that prevent “broadcast storms” by governing when ICMP error messages should not be generated. However, a significant number of replies to a ICMP broadcast from all systems on a network could cause significant network performance degradation. An attacker may use broadcast ICMP requests to create a denial of service attack. It is best to disable
the ability to respond to ICMP broadcasts. Solaris software has three 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. Disable responding to echo request broadcasts with this ndd command:
# ndd -set /dev/ip ip_forward_src_routed 0
# ndd -set /dev/ip ip_respond_to_echo_broadcast 0
TCP:
The Transmission Control Protocol (TCP) provides connection-based, reliable data transport. It uses a lower protocol, IP, to manage delivery of datagrams. TCP handles connection management and has rovisions for reliable delivery of data. The network configuration options described here are managed in the Solaris TCP driver.
SYN Flood Attacks:
The 1996, Issue 48 of the electronic journal Phrack contained an article, titled Project Neptune, describing a network denial of service attack against TCP called “SYN flooding”. This attack makes a system respond ery slowly to incoming network connections or not at all. A web site may appear to be down because it annot establish connections for incoming browser requests.
The Phrack paper also contained source code to a program to generate SYN floods against remote systems.
Soon after publication, several large ISPs and web sites were victims of these types of network attacks.
Attackers launched attacks from their dial-up modem connections to the Internet that brought down sites with much faster connections to the network. Often it was difficult to trace the attack back to the source. Outbound and current connections were unaffected.
The Transmission Control Protocol (TCP) is part of the TCP/IP network protocol suite and is connection-oriented. Prior to exchanging data using TCP, two systems must create a connection. onnection establishment is a three step process in TCP, often called the “three-way handshake”. During this handshake, destination port information is exchanged and the two systems synchronize sequence numbers. (The “SYN” name refers to this synchronization step.)
The handshake works in the following manner:
1. A client sends a TCP segment to a server with the SYN flag set in the header and an initial sequence number (ISN) and port number.
2. The server returns a segment to the client with the SYN flag set, an acknowledgement (or ACK flag), the original ISN + 1, and its own ISN
3. The client sends a segment with the ACK flag set and the server’s ISN + 1. A connection is now established and data can be exchanged.
The ISNs are used to provide reliability to the TCP protocol. The sequence numbers are incremented and sent with each outgoing packet. This allows the remote system to put packets in the proper order. If a packet is missing from the sequence, it can be detected and retransmitted.
The SYN flood attack takes advantage of a weakness in TCP. When a server receives the first SYN segment, it sends a SYN/ACK segment to the client address listed in the SYN segment. However, if that client is unreachable, the server will resend the SYN/ACK segment until a time limit is reached. (ICMP errors returned by the IP layer are ignored by the TCP layer.) If an attacking host sends many SYN segments for unreachable hosts, the server spends much time and system resources attempting to establish connections. Eventually, the server will reach its limit. Incoming connections still in the handshake phase are part of the backlog queue for the specified port.
These queues are typically small. Once the queue is full, no further incoming SYN segments can be processed. Either the system will no longer respond for that port or the initial response becomes very sluggish. Systems with many network services could exhaust system memory because of the high number of
uncompleted connections in the backlog queues.
In response to this attack, the Solaris 2.5.1 kernel TCP connection queue was changed and patches were issued. Previously, the size of the connection queue defined the size of the backlog queue. Now, there are two queues. There is still a queue for established connections. The new queue is for unestablished connections where the handshake process is incomplete. SYN flood attacks affect this queue.
When an attack occurs and the unestablished connection queue fills, an algorithm drops the oldest SYN segments first and allows the legitimate connections to complete. Patch 103582-11 (and up) adds this new queue system to Solaris 2.5.1 release. Solaris 2.6 and 7 releases already have it. When a system is under attack, the following message will appear in the logs:
This indicates that the system is handling the attack as designed.
The sizes of the new queues are adjustable. Busy web servers may need to increase the size of the unestablished connection queue. The default size of the queue is 1024. Use the following ndd command to increase it to 4096:
Any time a kernel queue is increased in size, there must be adequate system memory to handle the increase.
Mar 8 19:24:01 example unix: WARNING: High TCP connect timeout rate! System (port 80) may be under a SYN flood attack!
# ndd -set /dev/tcp tcp_conn_req_max_q0 4096
Connection Exhaustion Attacks:
While SYN flood attacks work on the principle of attacking the TCP three-way handshake, connection exhaustion attacks work on established connections. These attacks are not common because the connections can be traced back to the source in most cases, unlike SYN flood attacks. Most operating systems have a limit on the number of established connections that can be maintained whether set by kernel parameter or available physical memory.
Once this limit is reached, no new connections can be established. The active connections must be completed and closed before new connections can be established. For most web servers, this limit is never reached due the fact that HTTP connections are typically short-lived. An attacker can open many connections to a server and hold them open for long periods of time, effectively pushing the server closer to its connection limit.
A web server will close connections that have completed and accept new connections. An attacker who continually and quickly requests new connections will eventually hold all of the available connections. Normal users of the web server will receive messages indicating that the web server is not responding. This another denial of service attack.
Some defense against this type attack can be provided by tuning kernel and application parameters. This is not a complete solution since it is basically a battle of resources. Whoever has the most resources (systems, memory, etc.) will most likely win. An attacker can spread the connection attacks out to multiple systems to
increase the total connection requests. However, some application and kernel adjustments can be made to reduce the effectiveness of such attacks.
Most web servers have a parameter that sets the connection timeout value. For example, Apache 1.3.9 has a value named “Timeout” that sets the maximum time connection can be established. Once this time limit is reached, the server closes the connection. Setting this value to a lower value shortens the timeout period, and long-time connections are closed more quickly. Additionally, Solaris versions 2.5.1 (with at least patch 103582-11), 2.6, and 7 have a common parameter to adjust the maximum number of established network connections. The default value is 128.
Use the following ndd command to increase it to 1024:
Be aware that increasing the number of established connections will increase the amount of memory needed to process all connections. Server performance may suffer. Additional system memory may be required.
Decreasing the connection time and increasing the maximum number of established connections should be sufficient to ride out most connection exhaustion attacks. It may still be possible to create an effective denial of service even with the changes. However, the attacker must devote significant resources to be effective.
# ndd -set /dev/tcp tcp_conn_req_max_q 1024
IP Spoofing Attacks:
Predictable ISNs make it possible for attackers to compromise systems. The TCP three-way handshake discussed previously involves two systems synchronizing sequence numbers prior to data exchange. For each new connection most systems use ISNs that are fixed, predictable increments of a counter. An attacker uses this knowledge to create a three-way handshake using a predicted ISN to establish a connection and execute a command.
This is a sophisticated attack that involves exploiting a trust relationship between two systems. Typically, a remote shell command (rsh) is attempted due to the trust configuration of a .rhosts file. An interesting thing to note is that this attack is carried out with the attacker unable to see the packets returned from the target host.
This is due to the fact that the attacker is not on the same local network and the packets will be destined for the spoofed host. For this example, assume host A trusts host B. An attacker on host C (on a different network) wants to execute a command on host A. The first step in this attack is to disable host B. This can be done using the SYN flood attack described earlier.
The attacker then establishes a TCP connection (or several connections to judge network delays) to the target host to sample the ISN used. This will be used to predict the next ISN.
The attacker uses the following steps in the TCP three-way handshake:
1. The attacker creates a TCP segment with the SYN flag set and an arbitrary ISN.
The source address is set to trusted host, and it is sent to the target system.
2. The target system returns a segment to the trusted system with the SYN and ACK flags set, the attacker
ISN + 1, and its own ISN. The attacker cannot see this packet.
3. The attacker waits a period of time to allow the SYN/ACK segment to be sent and then sends a
segment with the ACK flag set and the predicted ISN + 1.
If the attacker predicts the target’s ISN accurately, then the remote shell daemon (in.rshd) will believe it has a valid connection to the trusted host. The attacker can now execute a command on the remote system.
RFC 1498 defines a better method for generating initial sequence numbers to prevent IP spoofing attacks. Using the procedure defined in the RFC, each connection has a unique and seemingly random ISN. A system using this technique is now a very difficult target for an attacker attempting to predict the ISN.
There are several settings available on Solaris systems: the predictable method (0), an improved method with random increment value
(1). and the RFC 1948 method
(2). The default method for all revisions of Solaris is 1. Solaris 2.6 and 7 releases have all of these methods. The Solaris 2.5.1 release only has methods 0 and 1. Solaris 2.6 and 7 releases should be modified to use method 2. To do this, edit the /etc/default/inetinit file and change the following line:
to
Reboot the system after this change. Unfortunately, Solaris 2.5.1 software does not offer the RFC 1948 method, and there are no plans to backport it.
Strict destination multihoming prevents packet spoofing on nonforwarding multihomed systems. A Solaris system with IP forwarding disabled and strict destination multihoming enabled will ignore packets sent to an interface from which it did not arrive. This prevents attackers from creating packets destined for networks
only connected to a multihomed server that does not forward packets.
The system is aware of which interface on which a packet arrives. 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 Operating Environment. It is disabled by default. Use the following ndd command to enable it:
Add this command to the init scripts.
# ndd -set /dev/ip ip_forwarding 0
# ndd -set /dev/ip ip_strict_dst_multihoming 1
Forwarding Directed Broadcasts:
A directed broadcast is a unicast datagram from a system on a remote network addressed 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 may 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. The source address in the forged packet is set to a target. The result is that the target and intermediate routing machine which forwards the directed broadcasts suffered from network congestion.
One recommended action is to disable directed broadcast forwarding at all routers. Attackers may also send directed broadcasts to probe the network and determine which systems have exploitable vulnerabilities.
Routing:
The process of routing involves examining a table of route information and making a decision about which interface to send datagrams. 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 may need to be updated from time to time. There are several routing information protocols that are used to propagate routing information.
The Solaris Operating Environ ment uses the in.routed and in.rdisc daemons to dynamically manage routing information. in.routed understands the Routing Information Protocol (RIP), version 1. in.rdisc implements ICMP Router Discovery. When a Solaris system is configured to forward packets as a router (IP forwarding enabled), these daemons advertise routing information to clients and
# ndd -set /dev/ip ip_forward_directed_broadcasts 0
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.
There are several problems with dynamic routing that attackers can use to create denial of service attacks or to 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. Most network administrators have a story about dynamic routing gone awry. 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
which now functions as a router.
The attacker sends forged routing information packets to a router claiming a lower hop count 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 system uses system daemons to dynamically manage routing information. Static routing can be used to prevent malicious remote routing changes.
The Solaris Operating Environment defines a default route by creating a file named /etc/defaultrouter containing the IP address of the router for local subnet. Other static route can be defined using the “route” command. See the man page on “route” for more information. Static routing works in environments with a single router to other networks.
Networks with redundant routers need to use dynamic routing so that systems can switch to a working router should one fail. Solaris systems functioning as network routers should continue to use dynamic routing.
ICMP:
The Internet Control Message Protocol (ICMP) provides a mechanism to report errors and request information. The configuration parameters discussed here are managed in IP driver.
Broadcasts:
ICMP broadcasts are always troublesome. There are rules that prevent “broadcast storms” by governing when ICMP error messages should not be generated. However, a significant number of replies to a ICMP broadcast from all systems on a network could cause significant network performance degradation. An attacker may use broadcast ICMP requests to create a denial of service attack. It is best to disable
the ability to respond to ICMP broadcasts. Solaris software has three 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. Disable responding to echo request broadcasts with this ndd command:
# ndd -set /dev/ip ip_forward_src_routed 0
# ndd -set /dev/ip ip_respond_to_echo_broadcast 0
TCP:
The Transmission Control Protocol (TCP) provides connection-based, reliable data transport. It uses a lower protocol, IP, to manage delivery of datagrams. TCP handles connection management and has rovisions for reliable delivery of data. The network configuration options described here are managed in the Solaris TCP driver.
SYN Flood Attacks:
The 1996, Issue 48 of the electronic journal Phrack contained an article, titled Project Neptune, describing a network denial of service attack against TCP called “SYN flooding”. This attack makes a system respond ery slowly to incoming network connections or not at all. A web site may appear to be down because it annot establish connections for incoming browser requests.
The Phrack paper also contained source code to a program to generate SYN floods against remote systems.
Soon after publication, several large ISPs and web sites were victims of these types of network attacks.
Attackers launched attacks from their dial-up modem connections to the Internet that brought down sites with much faster connections to the network. Often it was difficult to trace the attack back to the source. Outbound and current connections were unaffected.
The Transmission Control Protocol (TCP) is part of the TCP/IP network protocol suite and is connection-oriented. Prior to exchanging data using TCP, two systems must create a connection. onnection establishment is a three step process in TCP, often called the “three-way handshake”. During this handshake, destination port information is exchanged and the two systems synchronize sequence numbers. (The “SYN” name refers to this synchronization step.)
The handshake works in the following manner:
1. A client sends a TCP segment to a server with the SYN flag set in the header and an initial sequence number (ISN) and port number.
2. The server returns a segment to the client with the SYN flag set, an acknowledgement (or ACK flag), the original ISN + 1, and its own ISN
3. The client sends a segment with the ACK flag set and the server’s ISN + 1. A connection is now established and data can be exchanged.
The ISNs are used to provide reliability to the TCP protocol. The sequence numbers are incremented and sent with each outgoing packet. This allows the remote system to put packets in the proper order. If a packet is missing from the sequence, it can be detected and retransmitted.
The SYN flood attack takes advantage of a weakness in TCP. When a server receives the first SYN segment, it sends a SYN/ACK segment to the client address listed in the SYN segment. However, if that client is unreachable, the server will resend the SYN/ACK segment until a time limit is reached. (ICMP errors returned by the IP layer are ignored by the TCP layer.) If an attacking host sends many SYN segments for unreachable hosts, the server spends much time and system resources attempting to establish connections. Eventually, the server will reach its limit. Incoming connections still in the handshake phase are part of the backlog queue for the specified port.
These queues are typically small. Once the queue is full, no further incoming SYN segments can be processed. Either the system will no longer respond for that port or the initial response becomes very sluggish. Systems with many network services could exhaust system memory because of the high number of
uncompleted connections in the backlog queues.
In response to this attack, the Solaris 2.5.1 kernel TCP connection queue was changed and patches were issued. Previously, the size of the connection queue defined the size of the backlog queue. Now, there are two queues. There is still a queue for established connections. The new queue is for unestablished connections where the handshake process is incomplete. SYN flood attacks affect this queue.
When an attack occurs and the unestablished connection queue fills, an algorithm drops the oldest SYN segments first and allows the legitimate connections to complete. Patch 103582-11 (and up) adds this new queue system to Solaris 2.5.1 release. Solaris 2.6 and 7 releases already have it. When a system is under attack, the following message will appear in the logs:
This indicates that the system is handling the attack as designed.
The sizes of the new queues are adjustable. Busy web servers may need to increase the size of the unestablished connection queue. The default size of the queue is 1024. Use the following ndd command to increase it to 4096:
Any time a kernel queue is increased in size, there must be adequate system memory to handle the increase.
Mar 8 19:24:01 example unix: WARNING: High TCP connect timeout rate! System (port 80) may be under a SYN flood attack!
# ndd -set /dev/tcp tcp_conn_req_max_q0 4096
Connection Exhaustion Attacks:
While SYN flood attacks work on the principle of attacking the TCP three-way handshake, connection exhaustion attacks work on established connections. These attacks are not common because the connections can be traced back to the source in most cases, unlike SYN flood attacks. Most operating systems have a limit on the number of established connections that can be maintained whether set by kernel parameter or available physical memory.
Once this limit is reached, no new connections can be established. The active connections must be completed and closed before new connections can be established. For most web servers, this limit is never reached due the fact that HTTP connections are typically short-lived. An attacker can open many connections to a server and hold them open for long periods of time, effectively pushing the server closer to its connection limit.
A web server will close connections that have completed and accept new connections. An attacker who continually and quickly requests new connections will eventually hold all of the available connections. Normal users of the web server will receive messages indicating that the web server is not responding. This another denial of service attack.
Some defense against this type attack can be provided by tuning kernel and application parameters. This is not a complete solution since it is basically a battle of resources. Whoever has the most resources (systems, memory, etc.) will most likely win. An attacker can spread the connection attacks out to multiple systems to
increase the total connection requests. However, some application and kernel adjustments can be made to reduce the effectiveness of such attacks.
Most web servers have a parameter that sets the connection timeout value. For example, Apache 1.3.9 has a value named “Timeout” that sets the maximum time connection can be established. Once this time limit is reached, the server closes the connection. Setting this value to a lower value shortens the timeout period, and long-time connections are closed more quickly. Additionally, Solaris versions 2.5.1 (with at least patch 103582-11), 2.6, and 7 have a common parameter to adjust the maximum number of established network connections. The default value is 128.
Use the following ndd command to increase it to 1024:
Be aware that increasing the number of established connections will increase the amount of memory needed to process all connections. Server performance may suffer. Additional system memory may be required.
Decreasing the connection time and increasing the maximum number of established connections should be sufficient to ride out most connection exhaustion attacks. It may still be possible to create an effective denial of service even with the changes. However, the attacker must devote significant resources to be effective.
# ndd -set /dev/tcp tcp_conn_req_max_q 1024
IP Spoofing Attacks:
Predictable ISNs make it possible for attackers to compromise systems. The TCP three-way handshake discussed previously involves two systems synchronizing sequence numbers prior to data exchange. For each new connection most systems use ISNs that are fixed, predictable increments of a counter. An attacker uses this knowledge to create a three-way handshake using a predicted ISN to establish a connection and execute a command.
This is a sophisticated attack that involves exploiting a trust relationship between two systems. Typically, a remote shell command (rsh) is attempted due to the trust configuration of a .rhosts file. An interesting thing to note is that this attack is carried out with the attacker unable to see the packets returned from the target host.
This is due to the fact that the attacker is not on the same local network and the packets will be destined for the spoofed host. For this example, assume host A trusts host B. An attacker on host C (on a different network) wants to execute a command on host A. The first step in this attack is to disable host B. This can be done using the SYN flood attack described earlier.
The attacker then establishes a TCP connection (or several connections to judge network delays) to the target host to sample the ISN used. This will be used to predict the next ISN.
The attacker uses the following steps in the TCP three-way handshake:
1. The attacker creates a TCP segment with the SYN flag set and an arbitrary ISN.
The source address is set to trusted host, and it is sent to the target system.
2. The target system returns a segment to the trusted system with the SYN and ACK flags set, the attacker
ISN + 1, and its own ISN. The attacker cannot see this packet.
3. The attacker waits a period of time to allow the SYN/ACK segment to be sent and then sends a
segment with the ACK flag set and the predicted ISN + 1.
If the attacker predicts the target’s ISN accurately, then the remote shell daemon (in.rshd) will believe it has a valid connection to the trusted host. The attacker can now execute a command on the remote system.
RFC 1498 defines a better method for generating initial sequence numbers to prevent IP spoofing attacks. Using the procedure defined in the RFC, each connection has a unique and seemingly random ISN. A system using this technique is now a very difficult target for an attacker attempting to predict the ISN.
There are several settings available on Solaris systems: the predictable method (0), an improved method with random increment value
(1). and the RFC 1948 method
(2). The default method for all revisions of Solaris is 1. Solaris 2.6 and 7 releases have all of these methods. The Solaris 2.5.1 release only has methods 0 and 1. Solaris 2.6 and 7 releases should be modified to use method 2. To do this, edit the /etc/default/inetinit file and change the following line:
to
Reboot the system after this change. Unfortunately, Solaris 2.5.1 software does not offer the RFC 1948 method, and there are no plans to backport it.
0 comments:
Post a Comment