TCP\IP: A Mammoth Description

TCP\IP or Transmission Control Protocol \ Internet Protocol is a stack or collection of various protocols. A protocol is basically the commands or instructions using which two computers within a local network or the Internet can exchange data or information and resources.

Transmission Control Protocol \ Internet Protocol or the TCP\IP was developed around the time of the ARPAnet. It is also known as the Protocol Suite. It consists of various protocols but as the TCP (Transmission Control Protocol) and the IP (Internet Protocol) are the most, well known of the suite of protocols, the entire family or suite is called the TCP\IP suite.

The TCP\ IP Suite is a stacked suite with various layers stacked on each other, each layer looking after one aspect of the data transfer. Data is transferred from one layer to the other. The Entire TCP\ IP suite can be broken down into the below layers-:

Layer Name Protocol

Link Layer (Hardware, Ethernet) ARP, RARP, PPP, Ether
Network Layer(The Invisible Layer) IP, ICMP
Transport Layer UDP, TCP
Application Layer(The Visible Layer) The Actual running Applications like-: FTP client, Browser Physical Layer (Not part of TCP \IP) Physical Data Cables, Telephone wires

Data travels from the Link Layer down to the Physical Layer at the source and at the destination it travels from the Physical Layer to the Link Layer. We will later discuss what each layer and each protocol does.

The TCP\IP suite not only helps to transfer data but also has to correct various problems that might occur during the data transfer. There are basically two types of most common errors that might occur during the process of data transfer. They are-:

Data Corruption -: In this kind of error, the data reaches the destination after getting corrupted.
Data Loss -: In this kind of error, the entire collection of packets which constitute the data to be transferred does not reach the destination.

TCP\IP expects such errors to take place and has certain features which prevent, such error which might occur.

Checksums-: A checksum is a value (Normally, a 16 Bit Value) that is formed by summing up the Binary Data in the used program for a given data block. The program being used is responsible for the calculation of the Checksum value. The data being sent by the program sends this calculated checksum value, along with the data packets to the destination. When the program running at the destination receives the data packets, it re-calculates the Checksum value. If the Checksum value calculated by the Destination program matches with the Checksum Value attached to the Data Packets by the Source Program match, then the data transfer is said to be valid and error free. Checksum is calculated by adding up all the octets in a datagram.

Packet Sequencing-: All data being transferred on the net is broken down into packets at the source and joined together at the destination. The data is broken down into packets in a particular sequence at the source. This means that, for example, the first byte has the first sequence number and the second byte the second sequence number and so on. These packets are free to travel independently on the net, so sometimes, when the data packets reach the destination they arrive, out of sequence, which means that the packet which had the first sequence number attached to it does not reach the destination first. Sequencing defines the order in which the hosts receive the data packets or messages. The application or the layer running at the destination automatically builds up the data from the sequence number in each packet. The source system breaks the data to be transferred into smaller packets and assigns each packet a unique sequence number. When the destination gets the packets, it's starts rearranging the packets by reading the sequence numbers of each packet to make the data received usable.

For example, say you want to transfer a 18000 octet file. Not all networks can handle the entire 18000 octet packets at a time. So the huge file is broken down into smaller say 300 octet packets. Each packet has been assigned a unique sequence number. Now when the packets reach the destination the packets are put back together to get the usable data. Now during the transportation process, as the packets can move independently on the net, it is possible that the packet 5 will arrive at the destination before packet 4 arrives. In such a situation, the sequence numbers are used by the destination to rearrange the data packets in such a way that even if Data packet 5 arrived earlier, Packet 4 will always precede Packet 5.

A data can easily be corrupted while it is being transferred from the source to the destination. Now if a error control service is running then if it detects data corruption, then it asks the source to re-send the packets of data. Thus only non corrupted data reaches the destination. An error control service detects and controls the same two types of errors-:

1.) Data Loss
2.) Data Corruption

The Checksum values are used to detect if the data has been modified or corrupted during the transfer from source to destination or any corruption in the communication channel which may have caused data loss. Data Corruption is detected by the Checksum Values and by performing Cyclic Redundancy Checks(CRC 's). CRC 's too like the Checksums are integer values but require intensely advanced calculation and hence are rarely used.

There is yet another way of detecting data corruption-: Handshaking.

This feature ensures demands that both the source and destination must transmit and receive acknowledgement messages, that confirm transfer of uncorrupted data. Such acknowledgement messages are known as ACK messages.

Let's take an example of a typical scenario of data transfer between two systems. Source Sends MSG1 to Destination. It will not send MSG2 to Destination unless and until it gets the MSG ACK and destination will not send more requests for data or the next request message (MSG2) unless it gets the ACK from Source confirming that the MSG1 ACK was received by it. If the source does not get a ACK message from the destination, then something which is called a timed-out occurs and the source will re send the data to destination.

So this means that if A sends a data packet to B and B checksums the data packet and finds the data corrupted, then it can simply delete for a time out to take place. Once the time out takes place, A will re send the data packet to B. But this kind of system of deleting corrupt data is not used as it is inefficient and time consuming.

Instead of deleting the corrupt data and waiting for a time out to take place, the destination (B) sends a not acknowledged or NACK message to source(A). When A gets the NACK message, instead of waiting for a time out to take place, it straightaway resends the data packet.

An ACK message of 1000 would mean that all data up to 1000 octets has been received till now.

TCP/ IP is a layered suite of protocols. All layers are equally important and with the absence of even a single layer, data transfer would not have been possible. Each TCP/ IP layer contributes to the entire process of data transfer. An excellent example, is when you send an email. For sending mail there is a separate protocol, the SMTP protocol which belongs to the Application layer. The SMTP Application protocol like all other application layer protocols assumes that there is a reliable connection existing between the two computers. For the SMTP application protocol to do what it is designed for, i.e. to send mail, it requires the existence of all other Layers as well. The Physical Layer i.e. cables and wires is required to transport the data physically. The Transmission Control Protocol or the TCP protocol which belongs to the Transport Layer is needed to keep track of the number of packets sent and for error correction. It is this protocol that makes sure that the data reaches the other end. The TCP protocol is called by the Application Protocol to ensure error free communication between the source and destination. For the TCP layer to do its work properly i.e. to ensure that the data packets reach the destination, it requires the existence of the Internet Protocol or IP. The IP protocol contains the Checksum and Source and Destination IP address.

You may wonder why do we need different protocols like TCP and IP and why not bundle them into the same Application protocol.? The TCP protocol contains commands or functions which are needed by various application protocols like FTP, SMTP and also HTTP. The TCP protocol also calls on the IP protocol, which in turn contains commands or functions which some application protocols require while others don’t. So rather than bundling the entire TCP and IP protocol set into specific application protocols, it is better to have different protocols which are called whenever required.

The Link Layer which is the Hardware or Ethernet layer is also needed for transportation of the data packets. The PPP or the Point to Point Protocol belongs to this layer. Before we go on let's get accustomed with certain TCP\IP terms. Most people get confused between datagrams and packets and think that they are one and the same thing . You see, a datagram is a unit of data which is used by various protocols and a packet is a physical object or thing which moves on a physical medium like a wire. There is a remarkable difference between a Packet and a Datagram, but it is beyond the scope of this book. To make things easier I will use only the term datagram (Actually this is the official term.)while discussing various protocols.

Two different main protocols are involved in transporting packets from source to destination.

1.) The Transmission Control Protocol or the TCP Protocol
2.) The Internet Protocol or the IP protocol.

Besides these two main protocols, the Physical Layer and the Ethernet Layer are also indispensable to data transfer.

THE TRANSPORT LAYER

The TCP protocol

The Transmission Control Protocol is responsible for breaking up the data into smaller datagrams and putting the datagrams back to form usable data at the destination. It also resends the lost datagrams to destination where the received datagrams are reassembled in the right order. The TCP protocol does the bulk of work but without the IP protocol, it cannot transfer data.

Let's take an example to make things more clearer. Let's say your Internet Protocol Address or IP address is xxx.xxx.xxx.xxx or simply x and the destination's IP is yyy.yyy.yyy.yyy or simply y. Now As soon as the three-way connection is established between x and y, x knows the destination IP address and also the Port to which it is connected to. Both x and y are in different networks which can handle different sized packets. So in order to send datagrams which are in receivable size, x must know what is the maximum datagram size which y can handle. This too is determined by both x and y during connection time.

So once x knows the maximum size of the datagram which y can handle, it breaks down the data into smaller chunks or datagrams. Each datagram has it's own TCP header which too is put by TCP.A TCP Header contains a lot of information, but the most important of it is the Source and Destination IP and Port numbers and yes also the sequence number.

**************
HACKING TRUTH: Learn more about Ports, IP's, Sockets in the Net Tools Manual
**************
The source which is your computer(x) now knows what the IP Addresses and Port Numbers of the Destination and Source computers are. It now calculates the Checksum value by adding up all the octets of the datagram and puts the final checksum value to the TCP Header. The different octets and not the datagrams are then numbered. An octet would be a smaller broken down form of the entire data. TCP then puts all this information into the TCP header of each datagram. A TCP Header of a datagram would finally look like -:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| The Actual Data form the next 500 octets |
| |

There are certain new fields in the TCP header which you may not know off. Let's see what these new fields signify. The Windows field specifies the octets of new data which is ready to be processed. You see not all computers connected to the Internet run at the same speed and to ensure that a faster system does not send datagrams to a slow system at a rate which is faster than it can handle, we use the Window field. As the computer receives data , the space in the Window field gets decreased indicating that the receiver has received the data. When it reaches zero the sender stops sending further packets. Once the receiver finishes processing the received data, it increases the Window field, which in turn indicates that the receiver has processed the earlier sent data and is ready to receive more chunks of data.

The Urgent Field tells the remote computer to stop processing the last octet and instead receive the new octet. This is normally not commonly used.

The TCP protocol is a reliable protocol, which means that we have a guarantee that the data will arrive at the destination properly and without any errors. It ensures that the data being received by the receiving end is arranged in the same correct order in which it was sent.

The TCP Protocol relies on a virtual circuit between the client and the host. The circuit is opened via a 3 part process known as the three part handshake. It supports full duplex transportation of data which means that it provides a path for two way data transfer. Hence using the TCP protocol, a computer can send and receive datagrams at the same time.

Some common flags of TCP are-:

RST [RESET]- Resets the connection.
PSH [PUSH] - Tells receiver to pass all queued data to the application running.
FIN [FINISH] - Closes connection following the 4 step process.
SYN Flag - means that the machine sending this flag wants to establish a three way handshake i.e. a TCP connection. The receiver of a SYN flag usually responds with an ACK message.

So now we are in a position to represent a three way TCP Handshake:

A <---SYN---> B
A <---SYN/ACK? B
A <---ACK---> B

A sends a SYN flag to B saying " I want to establish a TCP connection", B responds to the SYN with the ACK to the SYN flag. A again responds to the ACK sent by B with another ACK.

Read RFC 793 for further in depth details about the TCP protocol.

The User Datagram Protocol or the UDP Protocol

The User Data protocol or the UDP is yet another protocol which is a member of the Transport Layer. TCP is the standard protocol used by all systems for communications. TCP is used to break down the data to be transported into smaller datagrams, before they (the datagrams) are sent across a network. Thus we can say that TCP is used where more than a single or multiple datagrams are involved.

Sometimes, the data to be transported is able to fit into a single datagram. We do not need to break the data into smaller datagrams as the size of the data is pretty small. The perfect example of such data is the DNS system. To send out the query for a particular domain name, a single datagram is more than enough. Also the IP that is returned by the Domain Name Server does not require more than one datagram for transportation. So in such cases instead of making use of the complex TCP protocol, applications fall back to the UDP protocol.

The UDP protocol works almost the way TCP works. But the only differences being that TCP breaks the data to be transferred into smaller chunks, does sequencing by inserting a sequence number in the header and no error control. Thus we can conclude by saying that the UDP protocol is an unreliable protocol with no way to confirm that the data has reached the destination.

The UDP protocol does insert a USP header to the single datagram it is transporting. The UDP header contains the Source and Destination IP Addresses and Port Numbers and also the Checksum value. The UDP header is comparatively smaller than the TCP Header.

It is used by those applications where small chunks of data are involved. It offers services to the User's Network Applications like NFS(Network File Sharing) and SNMP.

Read RFC 768 for further in depth details about the UDP protocol.

THE NETWORK LAYER

The IP Protocol

Both the TCP and the UDP protocols, after inserting the headers to the datagram(s) given to them pass them to the Internet Protocol or the IP Protocol. The main job of the IP protocol is to find a way of transporting the datagrams to the destination receiver. It does not do any kind of error checking.

The IP protocol too adds it's own IP Header to each datagram. The IP header contains the source and destination IP addresses, the protocol number and yet another checksum. The IP header of a particular datagram looks like-:

The Source and destination IP addresses and needed so that…well it is obvious isn't it? The Protocol number is added so that the IP protocol knows to which Transport Protocol the datagram has to be passed. You see various Transport Protocols are used like for example TCP or UDP. So this protocol number is inserted to tell IP the protocol to which the datagram has to be passed.

It too inserts it's own Checksum value which is different from the Checksum Value inserted by the Transport Protocols. This Checksum has to be inserted as without it the Internet Protocol will not be able to verify if the Header has been damaged in the transfer process and hence the datagram might reach a wrong destination. The Time to Live field specifies a value which is decreased each time the datagram passes through a network. Remember Tracert?

The Internet Protocol Header contains other fields as well, but they are quite advanced and cannot be included in a manual which gives an introduction to the TCP\IP protocol. To learn more about the IP protocol read RFC 791.

The Internet Control Message Protocol or the ICMP

The ICMP protocol allows hosts to transfer information on errors that might have occurred during the data transfer between two hosts. It is basically used to display error messages about errors that might occur during the data transfer. The ICMP is a very simple protocol without any headers. It is most commonly used to diagnose Network Problems. The famous utility PING is a part of the ICMP protocol. ICMP requests do not require the user or application to mention any port number as all ICMP requests are answered by the Network Software itself. The ICMP protocol too handles only a single datagram. That's why we say in PING only a single datagram is sent to the remote computer. This protocol can remote many network problems like Host Down, Congested Network etc

Read RFC 792 for further in depth details about the ICMP protocol.

The Link Layer

Almost all networks use Ethernet. Each machine in a network has it's own IP address and it's Ether Address. The Ether Address of a computer is different than it's IP address. An Ether Address is a 42 bit address while the IP address is only a 32 bit address. A Network must know which computer to deliver the datagram to. Right? For this the Ether Header is used.

The Ether Header is a 14 octet header that contains the Source and Destination Ethernet address, and a type code. Ether too calculates it's own Checksum value. The Type code relates to the protocol families to be used within the Network. The Ether Layer passes the datagram to the protocol specified by this field after inserting the Ether Header. There is simply no connection between the Ethernet Address and the IP address of a machine. Each machine needs to have a Ethernet to IP address translation table on its hard disk.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet destination address (first 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet dest (last 16 bits) |Ethernet source (first 16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet source address (last 32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP header, then TCP header, then your data |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Address Resolution Protocol or ARP

Data before being transmitted across the Internet or across a local network is broken down into smaller Packets which are suitable for transfer over the net. These packets have the Source and Destination IP's but for the transfer to take place the suitable Hardware Addresses or the MAC addresses must also be known. That is where ARP comes in.

To get the Hardware MAC addresses, ARP or Address Resolution Protocol sends a request message. The Router replies with the Hardware Address. It is similar to the DNS and it too has a cache. This cache can be a bit vulnerable as a Hacker could forge a connection from a remote machine claiming to be one of the cached locations. So we can conclude that ARP translates IP's into Ethernet Addresses. One thing to remember about ARP is that it only translates outgoing packets.

There is also something called the RARP which is an abbreviation for Reverse Address Resolution Protocol, which like the name says does exactly reverse of what ARP does.

There is simply no algorithm to get the Ethernet Address from the IP Address. To carry out such translations, each computer has a file which has a table with rows for each computer and two columns for their corresponding IP address and Ethernet Address. The File is somewhat like the following-:

Internet Protocol Address Ethernet Address Computer Name xxx.xy.yy.yx 08-00-39-00-2F-C3

Say there are a system in a Network (A) and an unidentified system (B) contacts it. Now A only knows the IP address of B. Now A will first try to identify whether B is the same network so that it can directly communicate via Ethernet. So it will first check the IP to MAC address translation table which it has. If it finds the IP in the table then well and good and A will establish a connection with B via Ethernet.

On the Other hand if A does not find any match for the specific IP, it will send out a request in the form of a 'Broadcast'. All computers within the Network will receive this broadcast and will search their own IP to MAC translation table and will reply with the necessary MAC address. A basic difference between an Ip address and MAC address is that an IP is the form xxx.xxx.xxx.xxx and a MAC address is in the form xx:xx:xx:xx:xx:xx and one is 32 bit while the other is 40 bit.

Read RFC 826 for further in depth details about the ARP protocol.

Application Layer

Till now you have learnt how data is broken down into smaller chunks, and transferred to the destination, where the chunks are rearranged. But there is yet another aspect to a successful data transfer process, which we have not discussed yet: The Application Protocols and the Application Layer itself. A host which receives datagrams has many applications or services (daemons) running which are ready to establish a TCP connection and accept a message. Datagrams travelling on the Internet must know which application they have to establish connection with, which application they have to send the message to. A typical web server will have the FTP daemon, the HTTP daemon, the POP daemon, and the SMTP daemon running.Wouldn't the datagrams get confused as to which daemon to send the message to.

For the datagrams to know which computer to send the message to, we have IP addresses. The datagram knows what daemon or application to send the message to by the Port Number attached to the IP address of the Destination. A TCP address is actually fully described by 4 numbers; The IP address of the Source and Destination and the TCP Port Numbers of each end to which data is to be sent. These numbers are found in the TCP Header.

To make it simpler to understand I have included an excerpt from the Net Tools Chapter:

What is all the hype about socket programming? What exactly are sockets?

TCP\IP or Transmission Control Protocol\ Internet Protocol is the language or the protocol used by computers to communicate with each other over the Internet. Say a computer whose IP address is 99.99.99.99 wants to communicate with another machine whose IP address is 98.98.98.98 then would will happen?

The machine whose IP is 99.99.99.99 sends a packet addressed to another machine whose IP is 98.98.98.98. When 98.98.98.98 receives the packet then it verifies that it got the message by sending a signal back to 99.99.99.99.But say the person who is using 99.99.99.99 wants to have simultaneously more than one connections to 98.98.98.98.....then what will happen? Say 99.99.99.99 wants to connect to the FTP daemon and download a file by FTP and at the same time it wants to connect to 98.98.98.98's website i.e. The HTTP daemon. Then 98.98.98.98. will have 2 connects with 99.99.99.99 simultaneously. Now how can 98.98.98.98.distinguish between the two connections...how does 98.98.98.98. know which is for the FTP daemon and which for the HTTP daemon? If there was no way to distinguish between the two connections then they would both get mixed up and there would be a lot of chaos with the message meant for the HTTP daemon going to the FTP daemon. To avoid such confusion we have ports. At each port a particular service or daemon is running by default. So now that the 99.99.99.99 computers knows which port to connect to, to download a FTP file and which port to connect to, to download the web page, it will communicate with the 98.98.98.98 machine using what is known as the socket pair which is acombination of an IP address and a Port. So in the above case the message which is meant for the FTP daemon will be addressed to 98.98.98.98 : 21 (Notice the colon and the default FTP port suceeding it.). So that the receiving machine i.e. 98.98.98.98 will know for which service this message is meant for and to which port it should be directed to.

In TCP\IP or over the Internet all communication is done using the Socket pair i.e. the combination of the
IP address and the port.

*****************
HACKING TRUTH: Learn More about Ports, IP addresses and Sockets by reading the Net Tools Chapter.
*****************
The Application Layers basically consists of the Applications running on your computer and the Applications running on the host to which you are connected. Say you are viewing the Hotmail Site, then the application layer comprises of the Web Browser running on your computer and the HTTP daemon running at Hotmail's server and the Application Protocol being used to communicate is HyperText Transfer Protocol.

As soon as a TCP connection is established the Applications running on Each end decide the language or protocol to be used to communicate and send datagrams.

IP Spoofing Torn Apart

IP spoofing is the most exciting topic you will hear wannabe hackers talking about. It is also a subject about which no one knows much. Before we continue I would like to tell you that IP Spoofing is quite difficult to understand and a lot of people have trouble understanding how it is done. The other downside it has is the fact that it can almost not be done using a Windows system and a system administrator can easily protect his system from IP spoofing

So what is IP Spoofing? IP Spoofing is a trick played on servers to fool the target computer into thinking that it is receiving data from a source other than you. This in turn basically means to send data to a remote host so that it believes that the data is coming from a computer whose IP address is something other than yours. Let's take an example to make it clear:

Your IP is : 203.45.98.01 (REAL)
IP of Victim computer is: 202.14.12.1 (VICTIM)
IP you want data to be sent from: 173.23.45.89 (FAKE)

Normally sitting on the computer whose IP is REAL, the datagrams you send to VICTIM will appear to have come from REAL. Now consider a situation in which you want to send a datagram to VICTIM and make him believe that it came from a computer whose IP is FAKE. This is when you perform IP Spoofing.

The Main problem with IP Spoofing is that even if you are able to send a spoofed datagram to the remote host, the remote host will reply not to your real IP but to the Fake IP you made your datagram seem to have come from. Getting confused? Read the following example to clear up your mind.

Taking the same IP's as in the last example, consider the following scenario. Now, if REAL connects to VICTIM, after the standard three way handshake has taken place, and VICTIM sends an ACK message to REAL. Now if you spoof you IP, to say FAKE, then VICTIM will try to establish a TCP connection and will send an ACK message to FAKE. Now lets assume that FAKE is alive, then as it had not requested the ACK message (sent by VICTIM to FAKE) it will reply with a NACK message which would basically end the connection and no further communication between FAKE and VICTIM would take place. Now if FAKE doesn't exist then the ACK message sent by VICTIM will not get any reply and in the end the connection times out.

Due to this FAKE and REAL IP reasons, when a person is trying to perform an IP Spoof, he does not get any response from the remote host and has no clue whether he has been successful or not. If he has made any progress or not. You are as good as blind, with no medium through which you could get feedback.IP Spoofing can be successful only if the computer with the FAKE IP does not reply to the victim and not interrupt the spoofed connection. Take the example of a telephone conversation, you can call up a person' x ' and pretend to be ' y ' as long as ' y ' does not interrupt the conversation and give the game away.

So why would you need to perform IP Spoofing-:

1.) To Pretend that you are some other computer whose IP address is amongst the trusted list of computers on the victim's disk. This way you are exploit the 'r' services and gain access to the network as you are then believed to be from a trusted source.
2.) To Disguise or Mask your IP address so that the victim does not know who you really are and where the data is coming from.

If you ever read the alt.2600 or the alt.hacking newsgroup, you would probably find many postings like "I have Win98, how do I Spoof my IP" or even " I do not know TCP/IP. tell me how to perform IP spoofing". You see the very fact that they are posting such questions and expect to learn how to spoof their IP without even knowing a bit about TCP\IP, confirms the fact that they would not be able to perform IP Spoofing. No I am not saying that asking questions is bad, but you see not knowing something is not so bad, but not knowing something and showing ignorance towards learning it is really, really bad.

You see IP spoofing is a very complex and difficult to perform subject. You need to hog entire TCP/IP and Networking Protocols manuals and need to be able to write C programs which will help you in the Spoofing process. It is amazing how people even think that they can spoof their IP without even knowing what TCP/IP stands for.

You see all packets travelling across the Internet have headers which contain the source and destination IP addresses and port numbers, so that the packet knows where to go and the destination knows where the packet has come from and where to respond. Now the process of Spoofing means to change the source IP address contains by the Header of the packet, in turn fooling the receiver of the Packets into believing that the packet came from somewhere else, which is a fake IP. Now let's again look at the IP Header of a datagram.

Now basically to perform IP spoofing we need to be able to change the value of the field, Source Address. Now to this you need to be able to guess sequence numbers which is quite a sophisticated process and I will try to explain it as clearly as possible. Before we go on, you need to understand the fact the IP spoofing is not the entire process, it is just a stepping stop in the entire process of fooling the remote host and establishing a trust relationship with the remote host.

So how do these trust relationships take place? Well all of you are encountered with some form of authentication process or the other. Now the Username-Password pair is the most commonly used form of authentication, with which we are very much familiar. Now what happens in the Username-Password form of authentication is that the remote host to which the client is connected to challenges the client by asking the User to type in the Username and Password. So in this form of authentication, the User needs to intervened and the remote host challenges the user to enter the Username and Password which act as a from of authentication.

Now other than the Password-Username form of authentication there is yet another form of authentication most users do not know of. This is the Client IP. In this form of authentication, what happens is that the remote host gets or find out the IP address of the client and compares it with a predefined list of IP's. If the IP of the client who is trying to establish a connection with the remote host is found in the list of IP's maintained by the host, then it allows the client access to the shell 'without a password' as the identity of the client has already been authenticated.

Such kind of rust relationships are common in Unix Systems which have certain 'R services' like rsh , rlogin , rcp which have certain security problems and should be avoided. Despite the threat involved most ISP's in India still keep the ports of the R services open to be exploited by Hackers. You normally establish a Rlogin trust relationship by using the Unix command,

$>rlogin IP address

**************
HACKING TRUTH: Well there is definitely a cooler way of establishing a trust relationship with a remote host, using Telnet. The default port numbers at which the R services run are 512, 513,514
**************

So how do I spoof my IP? Well in short, to spoof your IP, you need to be able to predict sequence numbers, this will clearer after reading then next few paragraphs.

To understand Sequence Numbers you need to go back to, how the TCP protocol works. You already know that TCP is a reliable protocol and has certain in-built features which have the ability to rearrange, re-send lost, duplicated or out of sequence data. To make sure that the destination is able to rearrange the datagrams in the correct order, TCP inserts two sequence numbers into each TCP datagram. One Sequence number tells the receiving computer where a particular datagram belongs while the second sequence number says how much data has been received by the sender. Anyway, let's move on, TCP also relies on ACK and NACK messages to ensure that all datagrams have reached the destination error free.Now we need to reanalyze the TCP Header to understand certain other aspects of sequence numbers and the ACK Number.

You see the TCP Header contains a Sequence Number which actually represents the sequence number of the first byte of that particular TCP segment. A sequence number is a 32 Bit number which is attached to all bytes (data) being exchanged across a Network. The ACK Number Field in the TCP header, actually contains the value of the sequence number which it expects to be the next. Not only that, it also does what it was meant to do, acknowledge data received. Confused? Read it again till you get the hang of it.

When a connection is established, the initial sequence number or ISN is initialized to 1. This ISN number is then incremented by 128,000 every second. There is a certain patter according to which the sequence numbers increment or change which makes then easy to predict.

To successfully perform IP spoofing or in order to predict Sequence Numbers, you need to be running a form of UNIX, as Windows does not provide the users with access to really advanced system stuff.Without a form of Unix IP Spoofing is almost impossible to do.

This text is not the ultimate guide to IP Spoofing and was aimed at only giving you a general outline of the whole process. Sequence number Prediction is really, really sophisticated and difficult to understand, but not impossible to do. However a system administrator can easily save his systems from IP spoofing and this actually makes it quite useless, nonetheless truly exciting. If You really want to learn IP Spoofing I suggest you read IP Spoofing Demystified by daemon9/route/infinity which was a part of Issue 48 of PHRACK magazine, File 14 of 18. Go to the Archive Section of their site, http://www.phrack.com and click on Issue 48.

This brings me to the other purpose people use IP Spoofing, IP Masking. Now to something as simple as mask or hide your IP you do not need to go through the complex procedure of guessing sequence numbers and performing IP Spoofing. There are proxy servers to do that for you. Read the Net Tools chapter for further details.

Port Scanning in Networking Terms

Earlier we learnt what a Port scan is why it is considered to be such a important tool of getting information about the remote host, which in turn can be used to exploit any vulnerabilities and break into the system. We all know how a manual Port Scan works. You launch Telnet and manually Telnet to each Port jotting down information that you think is important. In a manual Port Scan, when you telnet to a port of a remote host, a full three way handshake takes place, which means that a complete TCP connection opens.

The earliest and the oldest version of Port Scanners used the same technique. They connected to each port and established a full three way handshake for a complete TCP connection. The downside of such port scanners was the fact that as a full TCP connection was being established, the system administrator could easily detect that someone is trying to port scan his systems to find a vulnerability. However such port scanning methods also had a bright side, as an actual TCP connection was being established, the port scanning software did not have to build a Fake Internet Protocol Packet. (This IP Packet is used to scan the remote systems.) Such TCP scanners too relied on the three-way TCP handshake to detect if a port is open or not. The Basic process of detecting whether a port is open or not has been described below:

1.) You send a TCP Packet containing the SYN flag to remote host.
2.) Now the remote host checks whether the port is open or not. If the port is open then it replies with a
TCP packet containing both an ACK message confirming that the port is open and a SYN flag. On the other hand if the port is closed then the remote host sends the RST flag which resets the connection, in short closes the connection.
3.) This third phase is optional and involves the sending of an ACK message by the client.

As TCP Scanners were detectable, programmers around the world developed a new kind of port scanner, the SYN Scanner, which did not establish a complete TCP connection. These kinds of port scanners remain undetectable by only sending the first single TCP Packet containing the SYN flag and establishing a half TCP Connection. T understand the working of a SYN or Half SYN Port Scanner simply read its 4 step working-:

1. SYN Port Scanner sends the first TCP packet containing the SYN flag to the remote host.2. The remote system replies with, either a SYN plus ACK or a RST.3. When the SYN Port scanner receives one of the above responses, it knows whether the respective port is open or not and whether a daemon is ready listening for connections.

The SYN Port Scanners were undetectable by most normal system port scan detectors, however newer post scan detectors like netstat and also some firewalls can filter out such scans. Another downside to such scanning is that the method in which the scanner makes the IP packet varies from system to system.

UDP Scanning

It is yet another port scanning technique which can be used to scan a UDP port to see if it is listening. To detect an open UDP port, simply send a single UDP Packet to the port. If it is listening, you will get the response, if it is not, then ICMP takes over and displays the error message, " Destination Port Unreachable".

FIN Port Scanners

FIN Port Scanners are my favorite type of port scanners. They send a single packet containg the FIN flag. If the remote host returns a RST flag then the port is closed, if no RST flag is returned, then it is open and listening.

Some port scanners also use the technique of sending a ACK packet and if the Time To Live or ttl of the returning packets is lower than the RST packets received (earlier), or if the windows size is greater than zero, then the port is probably open and listening.

The Following is the code of a supposedly Stealth Port Scanner which appeared in the Phrack Magazine.

/*
* scantcp.c
*
* version 1.32
*
* Scans for listening TCP ports by sending packets to them and waiting for
* replies. Relys upon the TCP specs and some TCP implementation bugs found
* when viewing tcpdump logs.
*
* As always, portions recycled (eventually, with some stops) from n00k.c
* (Wow, that little piece of code I wrote long ago still serves as the base
* interface for newer tools)
*
* Technique:
* 1. Active scanning: not supported - why bother.
*
* 2. Half-open scanning:
* a. send SYN
* b. if reply is SYN|ACK send RST, port is listening
* c. if reply is RST, port is not listening
*
* 3. Stealth scanning: (works on nearly all systems tested)
* a. sends FIN
* b. if RST is returned, not listening.
* c. otherwise, port is probably listening.
*
* (This bug in many TCP implementations is not limited to FIN only; in fact
* many other flag combinations will have similar effects. FIN alone was
* selected because always returns a plain RST when not listening, and the
* code here was fit to handle RSTs already so it took me like 2 minutes
* to add this scanning method)
*
* 4. Stealth scanning: (may not work on all systems)
* a. sends ACK
* b. waits for RST
* c. if TTL is low or window is not 0, port is probably listening.
*
* (stealth scanning was created after I watched some tcpdump logs with
* these symptoms. The low-TTL implementation bug is currently believed
* to appear on Linux only, the non-zero window on ACK seems to exists on
* all BSDs.)
*
* CHANGES:
* --------
* 0. (v1.0)
* - First code, worked but was put aside since I didn't have time nor
* need to continue developing it.
* 1. (v1.1)
* - BASE CODE MOSTLY REWRITTEN (the old code wasn't that maintainable)
* - Added code to actually enforce the usecond-delay without usleep()
* (replies might be lost if usleep()ing)
* 2. (v1.2)
* - Added another stealth scanning method (FIN).
* Tested and passed on:
* AIX 3
* AIX 4
* IRIX 5.3
* SunOS 4.1.3
* System V 4.0
* Linux
* FreeBSD
* Solaris
*
* Tested and failed on:
* Cisco router with services on ( IOS 11.0)
*
* 3. (v1.21)
* - Code commented since I intend on abandoning this for a while.
*
* 4. (v1.3)
* - Resending for ports that weren't replied for.
* (took some modifications in the internal structures. this also
* makes it possible to use non-linear port ranges
* (say 1-1024 and 6000))
*
* 5. (v1.31)
* - Flood detection - will slow up the sending rate if not replies are
* recieved for STCP_THRESHOLD consecutive sends. Saves alot of resends
* on easily-flooded networks.
*
* 6. (v1.32)
* - Multiple port ranges support.
* The format is: <start-end>|<num>[,<start-end>|<num>,...]
*
* Examples: 20-26,113
* 20-100,113-150,6000,6660-6669
*
* PLANNED: (when I have time for this)
* ------------------------------------
* (v2.x) - Multiple flag combination selections, smart algorithm to point
* out uncommon replies and cross-check them with another flag
*
*/

#define RESOLVE_QUIET

#include <stdio.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/ip_tcp.h>
#include <sys/time.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <signal.h>
#include <errno.h>
#include "resolve.c"
#include "tcppkt03.c"

#define STCP_VERSION "1.32"
#define STCP_PORT 1234 /* Our local port. */
#define STCP_SENDS 3
#define STCP_THRESHOLD 8
#define STCP_SLOWFACTOR 10

/* GENERAL ROUTINES ------------------------------------------- */

void banner(void)
{
printf("\nscantcp\n");
printf("version %s\n",STCP_VERSION);
}
void usage(const char *progname)
{
printf("\nusage: \n");
printf("%s <method> <source> <dest> <ports> <udelay> <delay> [sf]\n\n",progname);
printf("\t<method> : 0: half-open scanning (type 0, SYN)\n");
printf("\t 1: stealth scanning (type 1, FIN)\n");
printf("\t 2: stealth scanning (type 2, ACK)\n");
printf("\t<source> : source address (this host)\n");
printf("\t<dest> : target to scan\n");
printf("\t<ports> : ports/and or ranges to scan - eg: 21-30,113,6000\n");
printf("\t<udelay> : microseconds to wait between TCP sends\n");
printf("\t<delay> : seconds to wait for TCP replies\n");
printf("\t[sf] : slow-factor in case sends are dectected to be too fast\n\n");
}
/* OPTION PARSING etc ---------------------------------------- */
unsigned char *dest_name;
unsigned char *spoof_name;
struct sockaddr_in destaddr;
unsigned long dest_addr;
unsigned long spoof_addr;
unsigned long usecdelay;
unsigned waitdelay;

int slowfactor = STCP_SLOWFACTOR;

struct portrec /* the port-data structure */
{
unsigned n;
int state;
unsigned char ttl;
unsigned short int window;
unsigned long int seq;
char sends;

} *ports;

char *portstr;

unsigned char scanflags;

int done;

int rawsock; /* socket descriptors */
int tcpsock;

int lastidx = 0; /* last sent index */
int maxports; /* total number of ports */

void timeout(int signum) /* timeout handler */
{ /* this is actually the data */
int someopen = 0; /* analyzer function. werd. */
unsigned lastsent;
int checklowttl = 0;

struct portrec *p;

printf("* SCANNING IS OVER\n\n");
fflush(stdout);

done = 1;

for (lastsent = 0;lastsent<maxports;lastsent++)
{
p = ports+lastsent;
if (p->state == -1)
if (p->ttl > 64)
{
checklowttl = 1;
break;
}
}
/* the above loop checks whether there's need to report low-ttl packets */

for (lastsent = 0;lastsent<maxports;lastsent++)
{
p = ports+lastsent;

destaddr.sin_port = htons(p->n);

tcpip_send(rawsock,&destaddr,
spoof_addr,destaddr.sin_addr.s_addr,
STCP_PORT,ntohs(destaddr.sin_port),
TH_RST,
p->seq++, 0,
512,
NULL,
0);
} /* just RST -everything- sent */
/* this inclued packets a reply */
/* (even RST) was recieved for */

for (lastsent = 0;lastsent<maxports;lastsent++)
{ /* here is the data analyzer */
p = ports+lastsent;
switch (scanflags)
{
case TH_SYN:
switch(p->state)
{
case -1: break;
case 1 : printf("# port %d is listening.\n",p->n);
someopen++;
break;
case 2 : printf("# port %d maybe listening (unknown response).\n",
p->n);
someopen++;
break;
default: printf("# port %d needs to be rescanned.\n",p->n);
}
break;
case TH_ACK:
switch (p->state)
{
case -1:
if (((p->ttl < 65) && checklowttl) || (p->window >0))
{
printf("# port %d maybe listening",p->n);
if (p->ttl < 65) printf(" (low ttl)");
if (p->window >0) printf(" (big window)");
printf(".\n");
someopen++;
}
break;
case 1:
case 2:
printf("# port %d has an unexpected response.\n",
p->n);
break;
default:
printf("# port %d needs to be rescanned.\n",p->n);
}
break;
case TH_FIN:
switch (p->state)
{
case -1:
break;
case 0 :
printf("# port %d maybe open.\n",p->n);
someopen++;
break;
default:
printf("# port %d has an unexpected response.\n",p->n);
}
}
}

printf("-----------------------------------------------\n");
printf("# total ports open or maybe open: %d\n\n",someopen);
free(ports);

exit(0); /* heh. */

}
int resolve_one(const char *name, unsigned long *addr, const char *desc)
{
struct sockaddr_in tempaddr;
if (resolve(name, &tempaddr,0) == -1) {
printf("error: can't resolve the %s.\n",desc);
return -1;
}

*addr = tempaddr.sin_addr.s_addr;
return 0;
}

void give_info(void)
{
printf("# response address : %s (%s)\n",spoof_name,inet_ntoa(spoof_addr));
printf("# target address : %s (%s)\n",dest_name,inet_ntoa(dest_addr));
printf("# ports : %s\n",portstr);
printf("# (total number of ports) : %d\n",maxports);
printf("# delay between sends : %lu microseconds\n",usecdelay);
printf("# delay : %u seconds\n",waitdelay);
printf("# flood dectection threshold : %d unanswered sends\n",STCP_THRESHOLD);
printf("# slow factor : %d\n",slowfactor);
printf("# max sends per port : %d\n\n",STCP_SENDS);
}
int parse_args(int argc, char *argv[])
{

if (strrchr(argv[0],'/') != NULL)
argv[0] = strrchr(argv[0],'/') + 1;

if (argc < 7) {
printf("%s: not enough arguments\n",argv[0]);
return -1;
}

switch (atoi(argv[1]))
{
case 0 : scanflags = TH_SYN;
break;
case 1 : scanflags = TH_FIN;
break;
case 2 : scanflags = TH_ACK;
break;
default : printf("%s: unknown scanning method\n",argv[0]);
return -1;
}

spoof_name = argv[2];
dest_name = argv[3];

portstr = argv[4];

usecdelay = atol(argv[5]);
waitdelay = atoi(argv[6]);

if (argc > 7) slowfactor = atoi(argv[7]);
if ((usecdelay == 0) && (slowfactor > 0))
{
printf("%s: adjusting microsecond-delay to 1usec.\n");
usecdelay++;
}
return 0;
}
/* MAIN ------------------------------------------------------ */

int build_ports(char *str) /* build the initial port-database */
{
int i;
int n;
struct portrec *p;
int sport;

char *s;

s = str;
maxports = 0;
n = 0;

while (*s != '\0')
{
switch (*s)
{
case '0':
case '1':
case '2':
case '3':
case '4':
case '5':
case '6':
case '7':
case '8':
case '9':
n *= 10;
n += (*s - '0');
break;
case '-':
if (n == 0) return -1;
sport = n;
n = 0;
break;
case ',':
if (n == 0) return -1;
if (sport != 0)
{
if (sport >= n) return -1;
maxports += n-sport;
sport = 0;
} else
maxports++;
n = 0;
break;
}
s++;
}
if (n == 0) return -1;
if (sport != 0)
{
if (sport >= n) return -1;
maxports += n-sport;
sport = 0;
}
else
maxports++;
maxports+=2;
if ((ports = (struct portrec *)malloc((maxports)*sizeof(struct portrec))) == NULL)
{
fprintf(stderr,"\nerror: not enough memory for port database\n\n");
exit(1);
}
s = str;
maxports = 0;
n = 0;

while (*s != '\0') {
switch (*s)
{
case '0':
case '1':
case '2':
case '3':
case '4':
case '5':
case '6':
case '7':
case '8':
case '9':
n *= 10;
n += (*s - '0');
break;
case '-':
if (n == 0) return -1;
sport = n;
n = 0;
break;
case ',':
if (n == 0) return -1;
if (sport != 0)
{
if (sport >= n) return -1;
while (sport <= n)
{
for (i=0;i<maxports;i++)
if ((ports+i)->n == sport) break;

if (i < maxports-1 )
printf("notice: duplicate port - %d\n",sport);
else
{
(ports+maxports)->n = sport;
maxports++;
}
sport++;
}
sport = 0;
} else
{
for (i=0;i<maxports;i++)
if ((ports+i)->n == n) break;

if (i < maxports-1 )
printf("notice: duplicate port - %d\n",n);
else
{
(ports+maxports)->n = n;
maxports++;
}
}
n = 0;
break;
}
s++;
}
if (n == 0) return -1;
if (sport != 0)
{
if (sport >= n) return -1;
while (sport <= n)
{
for (i=0;i<maxports;i++)
if ((ports+i)->n == sport) break;
if (i < maxports-1 )
printf("notice: duplicate port - %d\n",sport);
else
{
(ports+maxports)->n = sport;
maxports++;
}
sport++;
}
sport = 0;
} else
{
for (i=0;i<maxports;i++)
if ((ports+i)->n == n) break;
if (i < maxports-1 )
printf("notice: duplicate port - %d\n",n);
else
{
(ports+maxports)->n = n;
maxports++;
}
}
printf("\n");
for (i=0;i<maxports;i++)
{
p = ports+i;
p->state = 0;
p->sends = 0;
}
return 0;
}

struct portrec *portbynum(int num)
{
int i = 0;
while ( ((ports+i)->n != num) && (i<maxports) ) i++;
if ( i == maxports ) return NULL;
return (ports+i);
}

struct portrec *nextport(char save)
{
struct portrec *p = ports;
int doneports = 0;
int oldlastidx = lastidx;

while (doneports != maxports)
{
p = ports+lastidx;
if ((p->state != 0) || (p->sends == STCP_SENDS))
{
doneports++;
lastidx++;
lastidx %= maxports;
}
else
break; }
if (save)
lastidx = oldlastidx;
else
lastidx = (lastidx + 1) % maxports;
if (doneports == maxports) return NULL;
return p;
}
inline unsigned long usecdiff(struct timeval *a, struct timeval *b)
{
unsigned long s;
s = b->tv_sec - a->tv_sec;
s *= 1000000;
s += b->tv_usec - a->tv_usec;
return s; /* return the stupid microsecond diff */
}
void main(int argc, char *argv[])
{
int lastsent = 0;
char buf[3000];

struct iphdr *ip = (struct iphdr *)(buf);
struct tcphdr *tcp = (struct tcphdr *)(buf+sizeof(struct iphdr));

struct sockaddr_in from;
int fromlen;
struct portrec *readport;
fd_set rset, wset;
struct timeval waitsend, now, del;
unsigned long udiff;
int sendthreshold = 0;

banner();
if (parse_args(argc,argv))
{
usage(argv[0]);
return;
}
if (resolve_one(dest_name,
&dest_addr,
"destination host")) exit(1);
destaddr.sin_addr.s_addr = dest_addr;
destaddr.sin_family = AF_INET;
if (resolve_one(spoof_name,
&spoof_addr,
"source host")) exit(1);
if ( build_ports(portstr) == -1)
{
printf("\n%s: bad port string\n",argv[0]);
usage(argv[0]);
return;
}

give_info();
if ((tcpsock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP)) == -1)
{
printf("\nerror: couldn't get TCP raw socket\n\n");
exit(1);
}
if ((rawsock = socket(AF_INET, SOCK_RAW, IPPROTO_RAW)) == -1)
{
printf("\nerror: couldn't get raw socket\n\n");
exit(1);
}
/* well, let's get to it. */
done = 0;

printf("* BEGINNING SCAN\n");
fflush(stdout);
gettimeofday(&waitsend,NULL);

while (!done)
{ if (nextport(1) == NULL)
{
alarm(0); /* no more sends, now we just */
signal(SIGALRM,timeout); /* to wait <waitdelay> seconds */
alarm(waitdelay); /* before resetting and giving */
} /* results. */

FD_ZERO(&rset);
FD_SET(tcpsock,&rset);
gettimeofday(&now,NULL);
udiff = usecdiff(&waitsend,&now);

/* here comes the multiple choice select().
* well, there are 3 states:
* 1. already sent all the packets.
* 2. didn't send all the packets, but it's not time for another send
* 3. didn't send all the packets and it is time for another send.
*/
if (nextport(1) != NULL)
if (udiff > usecdelay)
{
FD_ZERO(&wset);
FD_SET(rawsock,&wset);
select(FD_SETSIZE,&rset,&wset,NULL,NULL);
} else
{
del.tv_sec = 0;
del.tv_usec = usecdelay;
select(FD_SETSIZE,&rset,NULL,NULL,&del);
}
else
select(FD_SETSIZE,&rset,NULL,NULL,NULL);
if (FD_ISSET(tcpsock,&rset)) /* process the reply */
{
fromlen = sizeof(from);
recvfrom(tcpsock,&buf,3000,0,
(struct sockaddr *)&from,&fromlen);
if (from.sin_addr.s_addr == destaddr.sin_addr.s_addr)
if (ntohs(tcp->th_dport) == STCP_PORT)
{
printf("* got reply");

readport = portbynum(ntohs(tcp->th_sport));

if (readport == NULL)
printf(" -- bad port");
else
{
sendthreshold = 0;
if (!readport->state)
{
readport->ttl = ip->ttl;
readport->window = tcp->th_win;

if (tcp->th_flags & TH_RST)
{
readport->state = -1;
printf(" (RST)");
if (readport->ttl < 65) printf(" (short ttl)");
if (readport->window > 0) printf(" (big window)");
}
else
if (tcp->th_flags & (TH_ACK | TH_SYN))
{
readport->state = 1;
printf(" (SYN+ACK)");
tcpip_send(rawsock,&destaddr,
spoof_addr,destaddr.sin_addr.s_addr,
STCP_PORT,readport->n,
TH_RST,
readport->seq++, 0,
512,
NULL,
0);
}
else
{
readport->state = 2;
printf(" (UNEXPECTED)");
tcpip_send(rawsock,&destaddr,
spoof_addr,destaddr.sin_addr.s_addr,
STCP_PORT,readport->n,
TH_RST,
readport->seq++, 0,
512,
NULL,
0);
}
}
else
printf(" (duplicate)");
}
printf("\n");
fflush(stdout);
}
}
if (nextport(1) != NULL)
if (FD_ISSET(rawsock,&wset)) /* process the sends */
{
readport = nextport(0);
destaddr.sin_port = htons(readport->n);
printf("* sending to port %d ",ntohs(destaddr.sin_port));

readport->seq = lrand48();
readport->sends++;
tcpip_send(rawsock,&destaddr,
spoof_addr,destaddr.sin_addr.s_addr,
STCP_PORT,ntohs(destaddr.sin_port),
scanflags,
readport->seq++, lrand48(),
512,
NULL,
0);
gettimeofday(&waitsend,NULL);
FD_ZERO(&wset);
printf("\n");
if ((++sendthreshold > STCP_THRESHOLD) && (slowfactor))
{
printf("\n\n -- THRESHOLD CROSSED - SLOWING UP SENDS\n\n");
usecdelay *= slowfactor;
sendthreshold = 0;
}
}
}
}
/*
* tcp_pkt.c
* routines for creating TCP packets, and sending them into sockets.
* (version 0.3)
* BUGFIX: - it seems like the TCP pseudo header checksum was
* acting up in serveral cases.
* ADDED : - HEXDUMP macro.
* - packet dump handling
*/
/* remove inlines for smaller size but lower speed */

#include <netinet/in.h>
#include <string.h>
#include <sys/types.h>
#include <netinet/ip.h>
#include <netinet/tcp.h>

#define IPHDRSIZE sizeof(struct iphdr)
#define TCPHDRSIZE sizeof(struct tcphdr)
#define PSEUDOHDRSIZE sizeof(struct pseudohdr)

/* ********** RIPPED CODE START ******************************** */
/* in_cksum --
* Checksum routine for Internet Protocol family headers (C Version)
*/
unsigned short in_cksum(addr, len)
u_short *addr;
int len;
{
register int nleft = len;
register u_short *w = addr;
register int sum = 0;
u_short answer = 0;
/*
* Our algorithm is simple, using a 32 bit accumulator (sum), we add
* sequential 16 bit words to it, and at the end, fold back all the
* carry bits from the top 16 bits into the lower 16 bits.
*/
while (nleft > 1) {
sum += *w++;
nleft -= 2;
}
/* mop up an odd byte, if necessary */
if (nleft == 1) {
*(u_char *)(&answer) = *(u_char *)w ;
sum += answer;
}
/* add back carry outs from top 16 bits to low 16 bits */
sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */
sum += (sum >> 16); /* add carry */
answer = ~sum; /* truncate to 16 bits */
return(answer);
}
/* ********** RIPPED CODE END ******************************** */
/*
* HEXDUMP()
* not too much to explain
*/
inline void HEXDUMP(unsigned len, unsigned char *data)
{
unsigned i;
for (i=0;i<len;i++) printf("%02X%c",*(data+i),((i+1)%16) ? ' ' : '\n');
}
/*
* tcpip_send()
* sends a totally customized datagram with TCP/IP headers.
*/
inline int tcpip_send(int socket,
struct sockaddr_in *address,
unsigned long s_addr,
unsigned long t_addr,
unsigned s_port,
unsigned t_port,
unsigned char tcpflags,
unsigned long seq,
unsigned long ack,
unsigned win,
char *datagram,
unsigned datasize)
{
struct pseudohdr {
unsigned long saddr;
unsigned long daddr;
char useless;
unsigned char protocol;
unsigned int tcplength;
};
unsigned char packet[2048];
struct iphdr *ip = (struct iphdr *)packet;
struct tcphdr *tcp = (struct tcphdr *)(packet+IPHDRSIZE);
struct pseudohdr *pseudo = (struct pseudohdr *)(packet+IPHDRSIZE-PSEUDOHDRSIZE);
unsigned char *data = (unsigned char *)(packet+IPHDRSIZE+TCPHDRSIZE);
/*
* The above casts will save us a lot of memcpy's later.
* The pseudo-header makes this way become easier than a union.
*/
memcpy(data,datagram,datasize);
memset(packet,0,TCPHDRSIZE+IPHDRSIZE);
/* The data is in place, all headers are zeroed. */

pseudo->saddr = s_addr;
pseudo->daddr = t_addr;
pseudo->protocol = IPPROTO_TCP;
pseudo->tcplength = htons(TCPHDRSIZE+datasize);
/* The TCP pseudo-header was created. */

tcp->th_sport = htons(s_port);
tcp->th_dport = htons(t_port);
tcp->th_off = 5; /* 20 bytes, (no options) */
tcp->th_flags = tcpflags;
tcp->th_seq = htonl(seq);
tcp->th_ack = htonl(ack);
tcp->th_win = htons(win); /* we don't need any bigger, I guess. */
/* The necessary TCP header fields are set. */

tcp->th_sum = in_cksum(pseudo,PSEUDOHDRSIZE+TCPHDRSIZE+datasize);

memset(packet,0,IPHDRSIZE);
/* The pseudo-header is wiped to clear the IP header fields */
ip->saddr = s_addr;
ip->daddr = t_addr;
ip->version = 4;
ip->ihl = 5;
ip->ttl = 255;
ip->id = random()%1996;
ip->protocol = IPPROTO_TCP; /* should be 6 */
ip->tot_len = htons(IPHDRSIZE + TCPHDRSIZE + datasize);
ip->check = in_cksum((char *)packet,IPHDRSIZE);
/* The IP header is intact. The packet is ready. */
#ifdef TCP_PKT_DEBUG
printf("Packet ready. Dump: \n");
#ifdef TCP_PKT_DEBUG_DATA
HEXDUMP(IPHDRSIZE+TCPHDRSIZE+datasize,packet);
#else
HEXDUMP(IPHDRSIZE+TCPHDRSIZE,packet);
#endif
printf("\n");
#endif
return sendto(socket, packet, IPHDRSIZE+TCPHDRSIZE+datasize, 0, (struct sockaddr *)address, sizeof(struct sockaddr));
/* And off into the raw socket it goes. */
}
/*
* resolve.c
* resolves an internet text address into (struct sockaddr_in).
*
* CHANGES: 1. added the RESOLVE_QUIET preprocessor conditions. Jan 1996
* 2. added resolve_rns() to always provide both name/ip. March 1996
*/
#include <sys/types.h>
#include <string.h>
#include <netdb.h>
#include <stdio.h>
#include <netinet/in.h>

int resolve( const char *name, struct sockaddr_in *addr, int port )
{
struct hostent *host;
/* clear everything in case I forget something */
bzero(addr,sizeof(struct sockaddr_in));
if (( host = gethostbyname(name) ) == NULL ) {
#ifndef RESOLVE_QUIET
fprintf(stderr,"unable to resolve host \"%s\" -- ",name);
perror("");
#endif
return -1;
}
addr->sin_family = host->h_addrtype;
memcpy((caddr_t)&addr->sin_addr,host->h_addr,host->h_length);
addr->sin_port = htons(port);
return 0;
}
int resolve_rns( char *name , unsigned long addr )
{ struct hostent *host;
unsigned long address;

address = addr;
host = gethostbyaddr((char *)&address,4,AF_INET);
if (!host) {
#ifndef RESOLVE_QUIET
fprintf(stderr,"unable to resolve host \"%s\" -- ",inet_ntoa(addr));
perror("");
#endif
return -1;
}
strcpy(name,host->h_name);
return 0;
}
unsigned long addr_to_ulong(struct sockaddr_in *addr)
{
return addr->sin_addr.s_addr;
}

DNS Torn Apart into Networking Terms.

DNS Spoofing is to DNS what IP spoofing is to IP Addresses. It simply means Spoofing the DNS concept. It depends on a hole in the DNS mechanism. The really good thing about it is the fact that unlike IP Spoofing, it works on almost all Operating systems. Before we go onto the Spoofing process, you need to know how DNS actually works. To make you understand better, I have included an excerpt from the Net Tools Chapter-:

DNS

A DNS is basically a resource for converting friendly Hostnames (like, hotmail.com)which humans can easily understand, into IP addresses which machines need to communicate to the host i.e. hotmail.com Now what basically happens in that when you type www.hotmail.com in the location bar of your browser, the browser needs to perform a lookup to find the machine readable IP address so that it can communicate with the host. This means that the browser cannot communicate with a host if it has the friendly hostname only. Without the IP address, no communication can take place. So for the lookup, the browser contacts the DNS server setup by normally by your ISP and through the resolver tries to look for the IP conversion of the hostname the user wants to contact. Such a request is called a resolution.

A DNS server is basically a server running DNS software. The server that the browser first looks for a translation is the Primary DNS server, if this primary server doesn't show any match then this server contacts another DNS server somewhere on the Internet (This becomes the Secondry DNS Server.)and looks for a match. If a match is found in the secondry server then the Primary server updates it's database so that it doesn't have to contact the Secondry server again for the same match. Each DNS server stores the hosts it has recently looked for in it's cache. Now if the Server has recently looked for a particular hostname, then it does not search for it again but just provides the browser with that information from it's cache. If the cache does not contain a particular entry, then the resolver for the desired entry by searching through the entire database.

New technologies are being introduced in the DNS sphere. Now take the case of amazon.com. It is a famous and large E-company with over a million users per day.(My rough estimate.) Such large organizations have multiple IP addresses for the same domain name. Today what happens is that the DNS server returns all IP Addresses and the browser chooses a random IP from it. But this new technology will allow the DNS server to return the IP of the server which has the least traffic, so as to enhance surfing. So you can see DNS does make sense.

Say your IP is X and you type in www.hotmail.com into your Browser location bar. So then what happens, how does the request go out? Where does it go out? Read on to learn how exactly DNS works.

After you have written the hostname(www.hotmail.com) into the browser location bar, the browser running at X (your machine) sends a resolution request to resolve the hostname www.hotmail.com into it's IP. This resolution request is sent to your ISP's DNS server. Now the DNS daemon or the WHOIS daemon by default runs on Port 53, so data is transferred from the random port (which was opened at your computer to carry out communication by your browser ) to Port 53 of your ISP's DNS server which is dns.isp.com So Our request travels somewhat like the below:

[X, which is your system's IP] [dns.isp.com]
X:1879 --->[?www.hotmail.com]------> xxx.xx.xx.xx:53

Remember that your IP is X and you have sent out a request to Port 53 of dns.isp.com whose IP is xxx.xx.xx.xx to resolve www.hotmail.com into its IP.

To Understand the above process, you need to read Socket's, Ports and IP's again. Refer to the Net Tools Chapter.

So now dns.isp.com goes through firstly its cache then through its entire database and if it finds a match then it responds with the respective IP else it sends the request to the Secondry DNS server which too is maintained by the same ISP.

[dns.isp.com] [dns2.isp.com]
xxx.xx.xx.xx:53 -------->[dns?www.hotmail.com]----> yyy.yy.yy.yy:53

Again dns2.sip.com searched through it's database and it's cache to find a match, then well and good, it will respond back to the Primary DNS server (dns.isp.com) else it will contact the main DNS server which has the authority and is supposed to handle all .com requests. Let's suppose that the main DNS server of the country is dns.main.com. So dns2.isp.com then sends a request to dns.main.com.

[dns2.isp.com] [dns.main.com]
yyy.yy.yy.yy:53 ------>[dns?www.hotmail.com]------> mmm.mm.mm.mm:53

Finally dns.main.com finds a match and responds back to the server that sent it the request.

[dns.main.com] [dns2.isp.com]
mmm.mm.mm.mm:53 ------->[www.hotmail.com == 144.56.78.09] ----> yyy.yy.yy.yy:53

The Secondry Name server then similarly responds to the Primary DNS server which had requested the information from it.

[dns2.main.com] [dns1.isp.com]
yyy.yy.yy.yy:53 ------->[www.hotmail.com == 144.56.78.09] ----> xxx.xx.xx.xx:53

And our browser finally receives the answer:

[dns1.isp.com] [X, us remember?]
xxx.xx.xx.xx:53------->[www.hotmail.com == 144.56.78.09] ----> x:1879

Now the above process was a description of a normal DNS request, now let's look at a reverse DNS request.

Now a Reverse DNS Lookup, is a process of getting the hostname by sending the IP to the concerned remote host. As soon as we write in the IP to be converted, DNS converts it into a format recognizable by the DNS service. For example, Hotmail.com gets changed to: 144.56.78.ca.us.com

[NOTE: The 144.56.78.ca.us.com has been made up by me and would definitely differ.]

The whole process of the request traveling from server to server would be the same while only the request would differ. Now that you know how a DNS request travels, let's learn how a DNS request packet look like.

The general format of a DNS request is as follows:

______________________________________________
| ID | flags |
|__________________ |__________________________ |
| numbers of questions | numbers of answer |
|____________________|_________________________|
| number of RR authority |number of supplementary RR |
|_____________________________________________|
| |
| QUESTION |
|_____________________________________________|
| |
| ANSWER |
| ____________________________________________ |
| |
| More additional values |
|_____________________________________________|

So what do the various fields stand for? Let's take then up one by one. Now the ID identifies that a new DNS Packet is starting. You see often a serve gets more than a single DNS request, and there has to be something to differentiate between the various DNS Packets. The ID Field does just that, differentiation.

The Flags area is a bit complicated with a number of parts, and many different values which describe the data contained by the DNS packet. That kind of information is beyond the scope of this text, but I would definitely give a general outline of what the Flags field contains. The Flag fields contains a number of parts, some are 4 bit and others are 3 bit. Some important parts are QR, AA, RD, RA and rcode. If QR is set to 0, then the DNS packet is a question else it is an answer. Similarly if AA is set to 1 then it means that the name server has an authoritative answer. RD and RA are concerned with recursion codes and the rcode flag specifies the error type whenever an error occurs. If it is set to 0 then it means no error took place. If it is set to 3 then it means a name error.

Now let's move on to the DNS Question part. This field is further sub divided into smaller parts, so I thought it would be better to not include the smaller sub categories in the main diagram of a DNS packet and instead show them in a separate illustration:

_________________________________________________
| Name Of The Question |
|________________________________________________ |
| Type of question | Type of query |
|_____________________ |__________________________ |

The question is structured something like the below-:
If the domain name is www.hotmail.com , then the question would be structured as:

[3|w|w|w|7|h|o|t|m|a|i|l|3c|o|m|0]

The same format is also followed for a domain name which has been converted by DNS into it's IP.

144.56.78.1.ca.us.com would be represented in the following form:

[3|1|4|4|2|5|6|2|7|8|1|1|2|c|a|2|u|s|3|c|o|m|0]

You can see that how long the above questions are, a new compression technique is currently being designed which will replace the current specification. Anyway moving on we come to the Type of Question field which is a sub category under the Name of Question field. This field can have a whooping 20 different values!!!. These values are worth knowing as they are the ones that we use when we do a nslookup (Unix command) on a remote host. The following is the complete list of values that can be used in the Type of Question field:

name value
A | 1 | IP Address ( resolving a name to an IP )
PTR | 12 | Pointer ( resolving an IP to a name )

Next we come to the Type of Query field. $$$$$$$

The next main field is the DNS Answer field. It too has various sub categories of fields. The answers stored in the DNS Answer Field are in a format commonly known as RR. The following is the format of a RR or a DNS Answer:
________________________________________________
| Name of Domain |
|_______________________________________________ |
| Type | Class |
|___________________ |___________________________ |
| TTL or Time To Live |
|_______________________________________________ |
| Resource Data Length | |
|____________________| |
| resource data |
|_______________________________________________ |

The Name Of Domain Field

The domain name is stored here in the same format it is stored in the domain question part. For Example, [3|w|w|w|7|h|o|t|m|a|i|l|3c|o|m|0]

The Type field:

Same as the Type field of the Question Part.

The Class Field

The class flag is set to various values according to the data, For the Internet, its value is set to 1.

TTL or Time to Live

This flag mentions the time life of the DNS cache in seconds.

Resource data length field specifies the length of the resource data, which means that if the resource data length is 4, then it means that the resource data is 4 bytes long. Resource Data field is where the IP is put. Various other values too are put but again they are out of scope of this manual.

All this geek stuff might have made you sick and might even have confused you a bit. Let's take an real life example and then see what the DNS Packet looks like. The following is the DNS query that is made by you when you type www.hotmail.com into the location bar of your browser:

ns.bibi.com:53 ---> [?www.heike.com] ----> ns.heike.com:53 (Phear Heike ;)

[X, which is your system's IP] [dns.isp.com]
X:1879 --->[?www.hotmail.com]------> xxx.xx.xx.xx:53

__________________________________________________________
| ID = 878 | QR = 0 opcode = 0 RD = 1 |
|___________________|______________________________________ |
| numbers of questions = htons(1) | numbers of answers = 0 |
|___________________________|______________________________ |
| number of RR authoritative = 0 | number of supplementary RR = 0 |
|__________________________ |_______________________________|
| name of the question = [3|w|w|w|7|h|o|t|m|a|I|l|3|c|o|m|0] |
|__________________________________________________________|
| type of question = htons(1) | type of query=htons(1) |
|_________________________|_________________________________|

Now when the DNS server, dns.isp.com responds to this packet, then it's structure is like the following:
__________________________________________________________
|ID = 878 | QR = 0 opcode = 0 RD = 1 |
|___________________|______________________________________ |
| numbers of questions = htons(1) | numbers of answers = 0 |
|___________________________|______________________________ |
| number of RR authoritative = 0 | number of supplementary RR = 0 |
|__________________________ |_______________________________|
| name of the question = [3|w|w|w|7|h|o|t|m|a|I|l|3|c|o|m|0] |
|__________________________________________________________|
| type of question = htons(1) | type of query=htons(1) |
|_________________________|_________________________________|
| name of the domain= [3|w|w|w|7|h|o|t|m|a|I|l|3|c|o|m|0] |
|__________________________________________________________ |
| type = htons(1) | class = htons(1) |
|__________________________________________________________|
| time to live = 999999 |
|__________________________________________________________|
| resource data length = htons(4) | resource data=inet_addr("61.73.90.9") |
|__________________________________________________________|

See the last field, the resource field, it tells us that Hotmail's IP is 61.73.90.9.

Well I do hope that clears all your doubts and makes everything clear. If not then I suggest you read the whole section again, and if still does not help, read it again, by then I am sure you will get the hang of it.

DOS Attacked!!!

DOS Attacks or Denial Of Services Attack have become very common amongst Hackers who use them as a path to fame and respect in the underground groups of the Internet. Denial of Service Attacks basically means denying valid Internet and Network users from using the services of the target network or server. It basically means, launching an attack which will temporarily make the services offered by the Network unusable by legitimate users.

DOS Attacks are of three different types-:

1.) Those that exploit vulnerabilities in the TCP/IP protocols suite.
2.) Those that exploit vulnerabilities in the Ipv4 implementation.
3.) There are also some brute force attacks which try to use up all resources of the target system and make the services unusable.

Before I go on with DOS attacks, let me explain some vulnerabilities in the TCP/IP suite itself. Some common vulnerabililities are Ping of Death, Teardrop, Syn attacks and Land Attacks.

Ping of Death

This vulnerability is quite well known and was earlier commonly used to hang remote systems (or even force them to reboot) so that no users can use its services. This exploit no longer works as almost all system administrators would have upgraded their systems making them safe from such attacks.

In this attack, the target system is pinged with a data packet that exceeds the maximum bytes allowed by TCP/IP, which is 65 536. This would have almost always caused the remote system to hang, reboot or crash.

Teardrop

The Teardrop attack exploits the vulnerability present in the reassembling of data packets. Like we all know, data before being sent through the Internet, is broken down into smaller datagrams (packets). These packets have an OFFSET field in their TCP header part. This Offset field specifies from which byte to which byte does that particular data packet carries data. Now in this attack, a series of data packets are sent to the target system with overlapping Offset field values. As a result, the target system is not able to reassemble the packets and is forced to crash, hang or reboot.

Say for example consider the following scenario-: (Note: _ _ _ = 1 Data Packet)

Normally a system receives data packets in the following form, with no overlapping Offset values.
_ _ _ _ _ _ _ _ _
(1 to 1500 bytes) (1501 to 3000 bytes) (3001 to 4500 bytes)

Now in a Teardrop attack, the data packets are sent to the target computer in the following format:

_ _ _ _ _ _ _ _ _
(1 to 1500 bytes) (1500 to 3000 bytes) (1001 to 3600 bytes)

When the target system receives something like the above, it simply cannot handle it and will crash or hang or reboot.

SYN Attack

The SYN attack exploits TCP/IP's three way handshake. In a normal three way handshake, what happens is that, the client sends a SYN packet to the host, the host replies to this packet with a SYN ACK packet. Then the client responds with a TCP ACK (Acknowledgement)

Now in a SYN attack too, several SYN packets are sent to the server but all these SYN packets have a bad source IP Address. When the target system receives these SYN Packets with Bad IP Addresses, it tries to respond to each one of them with a SYN ACK packet. Now the target system waits for a ACK message to come from the bad IP address. It queues up all these requests until it receives an ACK message. The requests are not removed unless an until, the remote target system gets an ACK message. Hence these requests take up or occupy valuable resources of the target machine.

To actually effect the target system, a large number of SYN bad IP packets have to be sent. As these packets have a Bad Source IP, they queue up, use up resources and memory or the target system and eventually crash, hang or reboot the system.

A Land attack is similar to a SYN attack, the only difference being that instead of a bad IP Address, the IP address of the target system is used.

Smurf Attacks

A Smurf attack is a sort of Brute Force DOS Attack, in which a huge number of Ping Requests are sent to a system (normally the router) in the Target Network, using Spoofed IP Addresses from within the target network. As and when the router gets a PING message, it will route it or echo it back, in turn flooding the Network with Packets, and jamming the traffic. If there are a large number of nodes, hosts etc in the Network, then it can easily clog the entire network and prevent any use of the services provided by it.

Read more about the Smurf Attacks at CERT: http://www.cert.org/advisories/CA-98.01.smurf.html

UDP Flooding

This kind of flooding is done against two target systems and can be used to stop the services offered by any of the two systems. Both of the target systems are connected to each other, one generating a series of characters for each packet received or in other words, requesting UDP character generating service while the other system, echoes all characters it receives. This creates an infinite non stopping loop between the two systems, making them useless for any data exchange or service provision.

Distributed DOS Attacks

DOS attacks are not new, in fact they have been around for a long time. However there has been a recent wave of Distributed Denial of Services attacks which pose a great threat to Security and are on the verge of overtaking Viruses/Trojans to become the deadliest threat to Internet Security.

Now you see, in almost all of the above TCP/IP vulnerabilities which are being exploited by hackers, there is a huge chance of the target's system administrator or the authorities tracing the attacks and getting hold of the attacker.

Now what is commonly being done is, a group of say 5 Hackers join and decide to bring a Fortune 500 company's server down. Now each one of them breaks into a smaller less protected network and takes over it. So now they have 5 networks and supposing there are around 20 systems in each network, it gives these Hackers, around 100 systems in all to attack from. So they sitting on there home computer, connect to the hacked less protected Network, install a Denial of Service Tool on these hacked networks and using these hacked systems in the various networks launch Attacks on the actual Fortune 500 Company. This makes the hackers less easy to detect and helps them to do what they wanted to do without getting caught. As they have full control over the smaller less protected network they can easily remove all traces before the authorities get there.

Not even a single system connected to the Internet is safe from such DDOS attacks. All platforms Including Unix, Windows NT are vulnerable to such attacks. Even MacOS has not been spared, as some of them are known to be used to conduct such DDOS attacks.

More Information on DOS Attacks

SMURF Attacks

Read the following excerpt from www.happyhacker.org written by Carolyn P Meinel & CERT on Smurf and MacOS Attacks:
Smurf attacks are probably the easiest distributed DOS attack to commit. In its simplest form, the attacker begins by using a commonly available program to scan the Internet to locate routers that that allow entry to broadcast pings. When he or she locates this kind of router, then next step is to forge ping packets with the origination address of the intended victim. This is done using packet manipulation tools such as those you can find at http://www.phrack.com and http://www.packetfactory.net. This type of attack can also use other Internet Control Message Protocol (ICMP) techniques.

To avoid arrest, the attacker will typically use a hacked computer to send out these forged ping packets. These packets are then sent to the network behind the vulnerable router. Each computer on this network echoes each attacking ping out to the victim designated in the ping's forged header. So if there are two hundred computers on this intermediary network, for every single ping of the attacking computer, they will send 200 pings out to the victim.

The defense against Smurf attacks is to contact an admin of the network being used as the intermediary for the attack. Smurf attacks also are stressful on the network that has been appropriated for the attack. So it is easy to get an admin's help. The quick fix is typically to deny broadcast pings at the intermediary network's border router, and be quite strict about what, if any, ICMP packets your border router allows. For more details on Smurf attacks, see the Computer Emergency Response Team's advisory at
http://www.cert.org/advisories/CA-98.01.smurf.html
and also http://www.quadrunner.com/~chuegen/smurf.txt

Asymmetric traffic from MacOS 9
MacOS 9 can be abused by an intruder to generate a large volume of traffic directed at a victim in response to a small amount of traffic produced by an intruder. This allows an intruder to use MacOS 9 as a "traffic amplifier," and flood victims with traffic. According to [3], an intruder can use this asymmetry to "amplify" traffic by a factor of approximately 37.5, thus enabling an intruder with limited bandwidth to flood a much larger connection. This is similar in effect and structure to a "smurf" attack, described in http://www.cert.org/advisories/CA-98.01.smurf.html
Unlike a smurf attack, however, it is not necessary to use a directed broadcast to achieve traffic amplification.
Apple has a fix which will prevent Mac OS from being used as an interpreter.
OT Tuner 1.0 switches off an option in Open Transport that would cause a Macintosh to respond to certain small network packets with a large Internet Control Message Protocol (ICMP) packet. This update prevents Macintosh computers from being the cause of certain types of Denial of Service (DOS) issues. The update is available from our software update server at http://asu.info.apple.com/swupdates.nsf/artnum/n11560 In addition, it will soon be available via the automatic update feature that is part of Mac OS 9. Remember the Denial of Service Tools that I mentioned? These tools are capable of using Networks to launch a large coordinated attack on the target Network by flooding it with packets. Well, the most common of them are trinoo (Also known as trin00) and tribe flood network or TFN.

Trinoo or trin00

Trinoo is used to launch a coordinated UDP flooding DOS attack on the target system from many different sources. The Trinoo software consists of two parts-: The servers or masters and the clients or daemons. Typically a Trinoo Network will have more clients than masters.

In a Denial of Service attack, carried out by using the trinoo network, the intruder connects to the master and instructs it to launch a DOS attack against the target system. This trinoo master then communicates with the daemons telling them to launch the attack on the specified system for a pre-defined amount of time.

You can find more information on Trinoo at: http://xforce.iss.net/alerts/advise40.php3.
Find more on UDP Flooding attacks at: http://www.cert.org/advisories/CA-96.01.UDP_service_denial.html
You can detect and remove Trinoo using the program found at: http://www.fbi.gov/nipc/trinoo.htm
An analysis of Trin00 can be found at: http://staff.washington.edu/dittrich/misc/trinoo.analysis

Tribe Flood Network or TFN

TFN, is almost very much like Trinoo, but has some additional features and thus can be called an advanced form of Trinoo. It can not only be used to launch a coordinated DOS attack from many sources, on more than a single target, it can also be used to carry out TCP SYN flooding, ICMP echo request flooding and also Smurf attacks.
For more information on TCP SYN Flooding and IP Spoofing attacks visit CERT at:
http://www.cert.org/advisories/CA-96.21.tcp_syn_flooding.html
Form More information on ICMP Broadcast attacks or Smurf DOS attacks visit:
http://www.cert.org/advisories/CA-98.01.smurf.html

When an intruder carries out a DOS attack using the TFN network, he instructs the client (master) to send instructions (to attack) to the TFN servers (daemons). These servers then launch a predefined type of attack on the target system or systems.

An attack carried out using the TFN Network is considered to be highly spohisticated and dangerous. TFN too can be detected using the same utility that detected and eradicated Trinoo.

Stacheldraht

Stacheldraht or barbed wire is a cross between trin00 and TFN. It combines features of both trin00 and TFN. The new feature in Stacheldraht is that it encrypts the instructions sent by the attacker to the master. A detailed text explaining the 'barbed wire' can be found at: http://staff.washington.edu/dittrich/misc/stacheldraht.analysis http://www.cert.org/reports/dsit_workshop.pdf

Tribal Floodnet 2K

This tool can be said to be the advanced version of TFN. The Tribal Floodnet 2K (TFN2K) launches coordinated denial-of-service attacks from many sources against one or more targets. This makes the instructions which belong to the TFN2K network difficult to detect and filter. It allows you to spoof the source of the Packets and can also carry out attacks using various protocols, like UDP, TCP and ICMP. It can also be used to remotely execute commands and also tries to fool the target system by sending decoy packets. It also tries to hang the target system by sending bad packets.

It is meant for both Unix and Windows NT Platforms and it's most extensively popular feature is that it can be used to send packets from a spoofed IP address. TFN2K too is based on the client server model. Find Related information at:
http://www.cert.org/advisories/CA-98-13-tcp-denial-of-service.html
http://www.cert.org/advisories/CA-97.28.Teardrop_Land.html

Mstream

Mstream, the newest of DDoS tools to be found being commonly used. Although its code still seems to be in the beta stage and it is believed to be a primitive form of the TFN and trin00 DOS attack tools, it makes efficient use of the attacked computers and can be used to damage the target system more efficiently.