NETWORK SECURITY

Abstract:
Network security is a complicated subject, historically only tackled by well trained and experienced experts. However as more and more people become "wired" an increasing number of people need to understand the basics of security in a networked world in this document we discuss some of the network security issues in TCP/IP.
The Transmission control protocol/Internet protocol (TCP/IP) suite is a very widely used technique that is employed inter connect computing facilities in modern network environments TCP/IP is the "language" of the internet. Anything that can learn to "Speak TCP/IP" can play on the internet. However , there exist several security vulnerabilities in the TCP specification and additional weaknesses in a number of widely available implementations of TCP. These vulnerabilities may unable an intruder to "attack" TCP - based systems, enabling him or her to "hijack" a TCP connection are cause denial of service to legitimate users. We discuss some of the flaws present in the TCP implementation of many widely used operating system and provide recommendations to improve the security state of a TCP-based system. e.g., incorporation of a "Timer escape route" from every TCP state.
Keywords and phrases:
Network security, TCP, IP, Vulnerability analysis, state transitions
INTRODUCTION:
Internet working is an approach that allows dissimilar computers on dissimilar networks to communicate with one another in seamless fashions by hiding the details of the underlying network hardware. The most widely used form of internet working is provided by the transmission control protocol/Internet protocol (TCP/IP) suite.
There are some inherent security problems in the TCP/IP suite which makes the situation conducive to intruders. TCP sequence numbers prediction, IP address spoofing, misuse of IP's source routing principle, use of internet control message protocol (ICMP) messages denial of service, etc are some methods to exploit the networks vulnerabilities. Considering the fact that most important application programs such as simple mail transfer protocol(SMPP),Telnet-commands(rlogin,rsh,etc),file transfer protocol(FTP),etc. have TCP as their transport layer, security flaws in TCP can prove to be very hazardous for the network.
The objectives of this paper are to identify and analyze the vulnerabilities of TCP/IP and to develop security enhancements to overcome those flaws. Our work is based on analyzing the state transition diagram of TCP and determining the security relevance of some of the “improperly-defined” transitions between different states in the state transition diagram of many widely used TCP code implementations.
BASICS OF TCP/IP:
NETWORKING WITH TCP/IP:
Network protocols employ a structured and layered approach, with each layer performing a separate function. This approach helps in developing individual layers without modifying other adjacent layers. Networking using the TCP/IP suite can be viewed as a combination of four layers. The layers are as below
The lowest layer the data link layer contains the network interface layer, connecting the system with the physical media.
The next layer is the internet layer or the network layer. It assists with the movement of packets in the network.
User processes interact with the network layer through the transport layer. The transmission control protocol is the most common transport layer used in modern networking environments. TCP provides reliable data transfer between different application processes over the network. TCP provides flow control and congestion control as well.
The Application layer handles the details of a particular application. This layer interacts with the user, gets data from the user, and sends the buffered data to the transport layer.
2.2 TRANSPORT LAYER
Among all of the transport layers, TCP is the most popular. Below, we examine the details of the header format of TCP along with the TCP state-transition diagram and TCP timers.
TCP HEADER
The size of the TCP header is 20 bytes, without counting its options, as we observe in figure. Each TCP segment contains the source and destination port number to identify the sending and receiving application programs, respectively. The sequence number is essential to maintain the bytes of data from the sender to the receiver in proper data. By communicating the sequence number and the corresponding acknowledgement number, the sender and the receiver can determine lost or retransmitted data in the connection. There are six flag bits in the TCP header, namely URG, ACK, PSH, RST, SYN and FIN. At any given time, one or more of these bits can be set.
TCP provides flow control by advertising the window size. The checksum covers TCP header and TCP data and assists in determining any error in transmission of TCP header or data. TCP’s urgent mode is a method for the sender to transmit emergency/urgent data. The urgent pointer is valid only if the URG flag is set in the header. It helps to locate the sequence number of the last byte of urgent data. There is an optional options field as well, taking care of vendor specific information.
TCP STATE TRANSITION DIAGRAM
Initiation, establishment, and termination of a connection is governed by the TCP state transition diagram, which consists of well-defined states and transition arcs between these states.
TCP TIMERS
The TCP state transition diagram is very closely associated with timers. There are various timers associated with connection establishment or termination, flow control, and retransmission of data.
A connection-establishment timer is set when the SYN packet is sent during the connection-establishment phase. If a response is not received with in 75 seconds (in most TCP implementations), the connection establishment is aborted.
A FINJWAIT_2 timer is set to 10 minutes when a connection moves from the FIN_WAIT_I state to the FIN_WAIT_2 state. If the connection does not receive a TCP packet with the FIN bit set with in the stipulated time, the timer expires and is set to 75 seconds. If no FIN packet arrives with in the time, the connection is dropped.
There is a TIME_WAIT timer, often called a 2 MSL (maximum segment lifetime) timer. It is set when a connection enters the TIME_WAIT state. When the timer expires, the kernel data blocks related to that particular connection are deleted, and the connection is terminated.
A keep-alive timer can be set which periodically checks whether the other end of the connection is still active. If the SO_KEEPALIVE socket option is set, and
If the TCP state is either ESTABLISHED or CLOSE_WAIT and the connection is idle, then probes are sent to the other end of the connection once every 2 hours. If the other end does not respond to a fixed number of these probes, the connection is terminated.
Additional TCP timers such as persist timer, delayed ACK timer, and retransmission timer are not relevant for our purposes here and, hence are not discussed.
VULNERABILITIES:
IP SPOOFING:
INSTANCES
The concept of attacks on TCP/IP such as TCP sequence number guessing was first brought to light by Morris. The computer Emergency Response Team (CERT) coordination center received reports of attacks in which intruders created packets with spoofed source IP addresses. These attacks exploit applications that use authentication based on IP address. Intruder activity in spoofing IP addresses can lead to unauthorized remote access to systems behind a filtering router firewall.
On Christmas Day, 1994, Kevin Mitnick broke into the computer of Tsutomo Shimomura, a computational physicist at the San Diego Super Computer center. Prior to this attack, Mitnick had found his way into the well, a small network used mainly by an electric group of about 11,000 computers users in san Francisco Bay. Mitnick had been reading electronic mail of the wells subscribers and using well accounts for remote attacks on computers across the internet. During the attack on Shimomura’s machine, two different intrusion mechanisms were employed. IP source address spoofing and TCP sequence number prediction were used to gain initial access to a diskless work station, being used mostly as an X terminal. After obtaining root access, Mitnick “hijacked” an existing connection to another system by means of a loadable kernel STREAMS module.
METHODOLOGY:
Let us assume that there are three hosts, host A, host B, and the intruder controlled host X. Let us assume that B grants A some special privileges, and thus A can get some actions performed by B. The goal of X is to get the same action done by B for itself. In order to achieve this goal, X has to perform two arithmetic operations: first establish a forged connection with B, and second, prevent A from informing B of any malfunction of the network authentication system. Host X has to spoof the IP address of A in order to make B believe that the packets from X are actually being sent by A.
Let us also assume that the hosts A and B communicate with one another by the following three way handshake mechanism of TCP/IP. The handshake method is depicted below
A􀃆B: SYN (seq no=M)
B􀃆A: SYN (Seq no=N),ACK (Ack no=M+1)
A􀃆B : ACK (Ack no=N+1)
Host X does the following to perform IP spoofing. First, it sends a SYN packet to host B with some random sequence number, posing as host A. Hos B responds to it by sending a SYN+ACK packet back to host A with an acknowledge number which is equal to one added to the original sequence number. At the same time, host B generates its own sequence number and sends it along with the acknowledge number. In order to complete the three way handshake, host X should send an Ack packet back to host B with an acknowledge number which is equal to one added to the sequence number sent by host B to host A. If we assume that the host X is not present in the same subnet as A or B so that it cannot sniff B’s packets, host X has to figure out B’s sequence number in order to create the TCP connection .
These steps are described
X􀃆 B: SYN (seq no=M),SRC=A
B􀃆 A: SYN (Seq no=N),ACK(ack no=M+1)
X􀃆 B: ACK (Ack no=N+!),SRC=A
At the same time, host X should take away the host A’s ability to respond to the packets of host B. To achieve this, X may either wait for host A to go down (for some reason), or block the protocol part of the operating system so that it does not respond to host B, for example by flooding B with incomplete connections.
THE ATTACK:
During the Christmas Day,1994 attack shimomura observed a sequence of packets that were generated to perform IP spoofing.Let us continue with the previous example with X as the intruder
controlled system and observe the actions performed by the intruder.
X sends a number of probe packets to B and A,trying to determine whether there exists any kind of trust relationship among hosts A and B. Commands such as showmount, RPCINFO and finger were utilized for this purpose.
X sends a number of TCP SYN packets i.e., packets containing the SYN flag set with some arbitrary initial sequence numbers to host A. however the source IP address of these packets have been forged, so that they appear to be coming from some host which does not exist in the network. Host A responds to these packets by sending corresponding SYN-ACK packets to the non-existent hosts. As there are no corresponding ACK packets to the packets sent by A, the three way hand-shake is never complete. The connection queue for port 513(login port) of A are filled up with connection setup requests. Thus the port willnot be able to generate RST packets in response to unexpected SYN-ACK packets.
X sends a number of connection request packets (SYN packets) to host B. when host B responds to them by sending corresponding SYN-ACIK packets to X, X sends RST packets to B. Thus the three-way handshake is not completed and TCP connections are never established between B and X. the purpose of this step is to determine the behavior of B’s TCP sequence number generator. The sequence numbers obtained from B for each new connection are analyzed by X. the periodicity of these numbers is determined and this data will be used X in the next step to generate and send a forged packet to B with a forged sequence number.
X creates a forged SYN packet with the source IP address same as that of host A. X sends this packet to B. B sends a corresponding SYN-ACK packet to A. However, A is ignoring all of the new packets coming to its loging port; it will not send any RST packet to B in response to the unexpected SYN-ACK packets from B.
X does not receive the SYN-ACK packet sent by B to A ( assuming X is present in a different subnet ). However , X is in a position to predict the sequence number present in B’s SYN-ACK packet. X generates and sends a forged ACK packet to B with the source host address same as that of A and an acknowledgement number corresponding to the sequence number in B’s SYN-ACK packet. B assumes that the three-way handshake is successfully performed. Hence, there is a one-way TCP connection established from X to B.
Host X is now in a position to commands to B. B will perform these commands, assuming that they are being sent by the trusted host A.
Problems with TCP state Transitions :
Let us take a closer look at Step2. The intruder- controlled host X is able to stall the loging-port of host A by sending a series of SYN packets but not sending ACK packets corresponding to the SYN-ACK packets from A to X. As we have observed before, TCP maintains a connection establishment timer. If a connection does not get established within a stipulated time ( typically 75 seconds), CP resets the connection. Thus, in our previous example, the server port will not be able to respond for duration of 75 seconds.
Extraneous State Transitions :
Consire a sequence of packets between hosts X and A. X sends a packet to A, with both SYN and FIN flags set. A responds by sending an ACK packet back to X, as illustrated below.
X 􀃆 A : SYN FIN ( Seq. no. = M)
A-􀃆X: ACK ( ack no. = M+ 1 )
Examining the state – transition diagram in the figure, we observer that A is initially in state LISTEN. When it receives the packets from X, starts processing the packets. It processes the SYN flag first, then transitions to the SYN_RCVD state. Then it processes FIN flag and performs a transition to the state CLOSE_WAIT. Had the previous state been ESTABLISHED, this transition to the CLOSE_WAIT state would have been a (normal) transition. However, a transition from SYN_RCVD state to the CLOSE_WAIT, state is not defined in the TCP specifications. This phenomenon occurs in several TCP implementations, such as those in the Operating systems SUNOS 4.1.3.SVR 4.and UL-TRIX 4.3. Thus, contrary to specifications, there exists in several TCP implementations a transition arc from the state SYN_RCVD to the state CLOSE_WAIT, as shown in fig.
Security Relevance
In our example attack scenario, the TCP connection is not yet fully established since the 3-way handshake is not completed; thus, the corresponding network application never got the connection from the kernel. However, host A’s TCP “machine” is in CLOSE_WAIT state and is expecting the application to send a close signal so that it can send a FIN packet to X and terminate the connection. This half-open connection does not send any message to help TCP perform any state transition. Thus, A’s TCP “machine” gets stuck in the CLOSE_WAIT state. If the keep-alive timer feature is enabled, TCP will be able to reset the connection and perform a transition to the CLOSED state after a period of usually two hours.
Intruder – controlled host X needs to perform the following steps to wedge A’s operating steps so that it cannot respond to unexpected SYN-ACKs from other hosts for as long as two hours.
• X sends a packet to host A with SYN and FIN flags set. A responds with an ACK packet. A changes its state from CLOSED/LISTEN to SYN_RCVD and then to CLOSE.WAIT.
• X does not send any more packet to A, thus preventing any TCP state-transition in A.
Thus , we observe that extraneous state-transitions exist in several implementations of TCP and these may lead to severe violations of the system.
Experiments and Results
Assume that there are two hosts, host A, host B, and the intruder-controlled host X. We will see what happens in IP spoofing attack and extraneous state transitions.
Stalling a port
• A ftp connection is initialized from the “intruder” machine X to A.
• The tcp device of X sends a SYN packet to A. A responds by sending a SYN-ACK packet, and performs a state-transition to the SYN-RCVD state.
• X does not send any other packet to A. A remains in the SYN_RCVD state until the connection – establishment timer expires,\.
The sequence of packets, as observed by the output of tcpdump[10] is as follows:
23:26:51.475103 X.32781 > A.ftp:
S 4188491776:4188449776(0) win 8760 (DF)
23:26:51.477716 A.ftp > X2.32781
S 1382592000:1382592000(0) ack4188491777 win 4096
We observe that port 32781 of X sends a SYN packet to the “ftp” port of A with an initial sequence number of 4188491776, initial window advertisement of 8760 at time 23:26:51.475103. A, in turn, responds back with a SYACK packet , with an initial number of 1382592000 and an acknowledgement number of 4188491777 at a time 23:26:51.477716.
However, X did not send any other packet and so A gets stuck in the SYN_RCVD state for around 75 seconds.
Spurious state transition
To generate the spurious state-transition from the SYN_RCVD state to the CLOSE_WAIT state, we employed the following steps:
• We start a ftp connection from X to A.
• In order to start the connection, X sends a SYN-FIN TCP packet t A.
• A responds back with an ACK packet.
• X does not send any other packet to A.
Using tcp dump, we observed the following sequence of packets in the network
21:41:05.177249 X.32780 > ftp:
SF 1550373888:1550373888(0) win 8760
21:41:05.177606 A.ftp>X.32780:.ack 1550373890 win
21:41:05. 177606 A .ftp> X. 32780: Aack 1550373890 win 4096
Had there been no spurious state- trantion from SYN_RCVD to the CLOSE_WAIT state in TCP implementations in the OS of A, the TCP “machine” of A would have waited in the SYN_RCVD state until the connection- establishment expired. However, netstat command in A gave us the following output.
Tcp 0 0 A.ftp X. 32780 CLOSE_WAIT
This clearly indicates that there exists a TCP connection between the “ftp” port of A and port 32780 of X, and the connection exists in the CLOSE_WAIT state. The connection remains in this state in A long after the peer host closed the connection on its side.
We obtain similar results with TCP implementation of ULTRIX 4.3OS as well.
Recommendations
There is no way easy to prevent IP spoofing. We may perform the following tasks to protect our systems from this sort of attack. First, we may configure the routers and the gateways in our networks such that they do not allow connections from outside with a source IP address the same as that of any of the systems within the local subnet. Also, they should not route packets from a host in the local subnet to the outside when the source IP address of the packet is something not present in the local subnet. Second, encrypt the packets before sending them to the network. Though this process requires extensive change in the present networking environment, it will ensure the integrity and authencity of data.
To prevent the spurious state-trantion from SYN_RCVD state to CLOSE_WAIT state, we should request the OS vendors to modify the relevant part of the source code in their TCP implementation. In other words, when the TCP”machine” is in SYN_RCVD state, it should neglect any FIN packets that it might receive from a peer host