Download IP Spoofing and DoS Attacks: Understanding SYN, UDP, and ICMP Attacks and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity!
ECE4112 Internetwork Security
Denial of Service and
Group Number: _________
Member Names: ___________________ _______________________
Date Assigned:
Date Due:
Last Edited:
Lab Authored by Paul Obame and Thomas Losier (Group 16)
Please read the entire lab and any extra materials carefully before starting. Be sure to
start early enough so that you will have time to complete the lab. Answer ALL questions
and be sure you turn in ALL materials listed in the Turn-in Checklist ON or BEFORE
the Date Due.
Goal: This lab will introduce you to socket programming and familiarize you with
Denial of service attacks or DoS. After successfully completing this lab you should be
able to understand, analyze, develop, and edit raw socket programs and become familiar
with some DoS techniques hackers use to attack your network.
Summary:
DoS Suite:
SYN attack send as many SYN packets as you can to one IP address, the host IP address
is spoofed to be random
UDP flood same as above
ICMP reset attack: Find fortuple and reset a TCP connection.
DDoS attack: Put all IP addresses into a file and send ICMP ping request to all those
machines and they all reply to one machine.
Requirements:
Background and Theory: Dos attacks are possible because when the
Internet was initially developed it was designed for scalability and easy connectivity. The
Internet was not designed to support authentication schemes. This lack of authentication
at the network layer is what allows IP spoofing. IP spoofing refers to creating an IP
packet containing fake information (see figure 1). IP source address spoofing occurs
when an IP packet is generated using a different source IP address than the actual address
that is assigned to the source computer. IP spoofing is accomplished using socket
programming and a raw socket. A raw socket is a computer networking term used to
describe a socket that allows access to the packet headers. Raw socket programming
allows users to create their own packet headers. Hackers use this ability to spoof IP
addresses as part of their DoS attack.
Figure 1: IP Packet Diagram ( www.h3c.com )
Without an integrity check for each IP packet, attackers can spoof any field of an IP
packet and inject it into the Internet. Routers generally do not have packet-tracing
functions because keeping all previous connection records would require huge amounts
storage and is not feasible. Therefore, once an IP packet is received by the victim, there is
no way to authenticate whether the packet actually comes from where it claims to be
coming from.
A DoS attack is a malicious attempt to occupy all resources of a system blocking
legitimate users from accessing it. Most often this is accomplished through flooding the
target with information so that it will overload and drop legitimate requests. It can also be
accomplished by destroying the foundation of network communication by sending
intentionally flawed or malicious messages.
There are two general types of DoS attacks. The first type tries to crash a system by
sending one or more carefully crafted packets that exploit a software vulnerability in the
target system. An example of this is the “ping-of-death” attack. It uses an ICMP packet
that splits into multiple data-grams when it reaches the target system, to freeze and shut
down (We will be using a similar less destructive attack called the ICMP Reset attack).
The other type of attack is a flood attack where large amounts of traffic are send to
occupy all a systems resources. During this type of attack packet loss or dropped packets
occur when a processing queue’s capacity is filled. Once it is filled it starts to drop
packets allowing it to process the requests that currently fill the buffer. When a packet is
lost legitimate traffic backs off its sending rate according a back off algorithm. Hackers
however, do not back off this allows them to continue flooding the system and
completely starve out all legitimate traffic. The first type of attack is usually avoidable by
keeping all the components of the system patched and up to date. The other type of attack
is not as easy to prevent. Any computer that is connected to the internet can be vulnerable
to this type of attack.
A variation of the second type of DoS attack is a distributed denial of service or DDoS
attack. This attack uses multiple sources to flood a system making the DDoS attack more
powerful and harder to defend.
attacker sends SYN packets with spoofed source IP addresses to a server. The server
must store the connection information into memory and wait for the confirmation from
the client. While the re-quest is waiting to be confirmed the connection information will
remain in memory. Because the packets are spoofed connections, the server will not
receive any packets back ant will hold the connection info until timeout. As the requests
accumulate the memory fills. Once the memory buffer is full no new request can be
processed and the services of the system are disabled.
Figure 3:TCP Packet Diagram ( www.h3c.com )
UDP Flood Attack (DoS)
Figure 4: UDP Packet Diagram ( www.h3c.com )
The UDP flood attack works in much the same way as the TCP attack mentioned above.
It does not however rely on filling up a stored memory buffer. The UDP attack works by
trying to consume all available bandwidth or by sending information so fast the router
can not process it fast enough and the routers receive buffer fills and overflows.
ICMP Reset Attack (DoS)
Figure 5: ICMP Packet Diagram ( www.cisco.com )
ICMP protocol is considered a core protocol of the TCP/IP protocol suite, and its
implementation is mandatory in all devices that participate in computer networks based
on IP technology. ICMP is employed for a variety of functions. However in this lab we
will be interested in only one of them: the use of ICMP for fault isolation.
There are two types of ICMP error messages Soft and Hard errors. Soft errors are
supposed to be temporary error conditions that will likely get solved in the near future
(like if a link were to go down). Hard errors are ones that are not suspected to be fixed
over time (like if the segments are too large and the do not fragment bit is set). No matter
how many times you send the segment it will never reach its destination.
For TCP when an error condition is notified by means of an ICMP Hard error message, it
will abort the current connection because it is assuming that this error will not be fixed
over time and it doesn’t make sense to re-transmit the segment. Similar to the above
mentioned IP spoofing, there are no validation checks performed on received ICMP error
messages. The IETF mandates that the entire IP header plus the first eight bytes of the IP
payload (the transport protocol header) must be included in the ICMP error message. All
a hacker must do to disrupt any TCP communication is sniff out (or bruit force guess) the
four-tuple and it will be considered a legitimate packet.
ICMP Ping request (DDoS)
The DDoS attack implemented is the “smurf ” attack. It is ICMP flood where attackers
use ICMP echo request packets directed to IP broadcast addresses from remote locations
to generate denial of service attacks. There are three components involved in these
attacks: the attacker, the interme-diary, and the victim. First, the attacker sends one ICMP
echo request packet to the network broadcast address and the request is forwarded to all
the hosts within the intermediary network. Second, all of the hosts within the interme-
diary network send the ICMP echo replies to flood the victim.
disabling the IP-directed broad-cast service at the intermediary network.
Section 1: TCP SYN Attack (DoS)
T
Section 2: UDP Flood Attack (DoS)
Q8.10: Can you see any difference in the TCP packets? (Hint: Look at the sequence
number)
Q8.11: Compare and contrast the relative effectiveness of the three attacks
including a comparison of the first attack before and after the defense against the
first attack was deployed.
For future labs, you may not want the SYN cookies enabled. Disable SYN cookies by
doing:
# echo -n 0 > /proc/sys/net/ipv4/tcp_syncookies
Edit the /etc/sysctl.conf file and remove the following line:
# Enable TCP SYN Cookie Protection
net.ipv4.tcp_syncookies = 1
You must restart your network for the change to take effect. The command to restart the
network is the following:
/# /etc/rc.d/init.d/network restart
References:
[1] A CM Computing Surveys, Vol. 39, No. 1, Article 3, Publication date: April 2007
[2] http://mixter.warrior2k.com
[3] Computer Networking, A Top Down Approach, 4th^ edition, Copyright Pearson
Education Inc. 2008
[4]http://www4.informatik.uni-erlangen.de/Projects/JX/Projects/TCP/tcpstate.html
[5]http://www.h3c.com/portal/Products___Solutions/Technology/QoS/QoS/
200701/195599_57_0.htm
[6] http://www.cisco.com/warp/public/105/pmtud_ipfrag.html
Appendix A: Socket Programming tutorial
A brief programming tutorial in C for raw sockets by Mixter for the BlackCode Magazine http://mixter.void.ru or http://mixter.warrior2k.com
- Raw sockets
- The protocols IP, ICMP, TCP and UDP
- Building and injecting datagrams
- Basic transport layer operations In this tutorial, you'll learn the basics of using raw sockets in C, to insert any IP protocol based datagram into the network traffic. This is useful,for example, to build raw socket scanners like nmap, to spoof or to perform operations that need to send out raw sockets. Basically, you can send any packet at any time, whereas using the interface functions for your systems IP-stack (connect, write, bind, etc.) you have no direct control over the packets. This theoretically enables you to simulate the behavior of your OS's IP stack, and also to send stateless traffic (datagrams that don't belong to a valid connection). For this tutorial, all you need is a minimal knowledge of socket programming in C (see http://www.ecst.csuchico.edu/~beej/ guide/net/). I. Raw sockets The basic concept of low level sockets is to send a single packet at one time, with all the protocol headers filled in by the program (instead of the kernel). Unix provides two kinds of sockets that permit direct access to the network. One is SOCK_PACKET, which receives and sends data on the device link layer. This means, the NIC specific header is included in the data that will be written or read. For most networks, this is the ethernet header. Of course, all subsequent protocol headers will also be included in the data. The socket type we'll be using, however, is SOCK_RAW, which includes the IP headers and all subsequent protocol headers and data. The (simplified) link layer model looks like this: Physical layer -> Device layer (Ethernet protocol) -> Network layer (IP) -> Transport layer (TCP, UDP, ICMP) -> Session layer (application specific data) Now to some practical stuff. A standard command to create a datagram socket is: socket (PF_INET, SOCK_RAW, IPPROTO_UDP); From the moment that it is created, you can send any IP packets over it, and receive any IP packets that the host received after that socket was created if you read() from it. Note that even though the socket is an interface to the IP header, it is transport layer specific. That means, for listening to TCP, UDP and ICMP traffic, you have to create 3 separate raw sockets, using IPPROTO_TCP, IPPROTO_UDP and IPPROTO_ICMP (the protocol numbers are 0 or 6 for tcp, 17 for udp and 1 for icmp). With this knowledge, we can, for example, already create a small sniffer, that dumps out the contents of all tcp packets we receive. (Headers, etc. are missing, this is just an example. As you see, we are skipping the IP and TCP headers which are contained in the packet, and print out the payload, the data of the session/application layer, only). int fd = socket (PF_INET, SOCK_RAW, IPPROTO_TCP); char buffer[8192]; /* single packets are usually not bigger than 8192 bytes */ while (read (fd, buffer, 8192) > 0) printf ("Caught tcp packet: %s\n", buffer+sizeof(struct iphdr)+sizeof(struct tcphdr)); II. The protocols IP, ICMP, TCP and UDP
struct icmpheader { unsigned char icmp_type; unsigned char icmp_code; unsigned short int icmp_cksum; /* The following data structures are ICMP type specific / unsigned short int icmp_id; unsigned short int icmp_seq; }; / total icmp header length: 8 bytes (=64 bits) / icmp_type: the message type, for example 0 - echo reply, 8 - echo request, 3 - destination unreachable. look in for all the types. icmp_code: this is significant when sending an error message (unreach), and specifies the kind of error. again, consult the include file for more. icmp_cksum: the checksum for the icmp header + data. same as the IP checksum. Note: The next 32 bits in an icmp packet can be used in many different ways. This depends on the icmp type and code. the most commonly seen structure, an ID and sequence number, is used in echo requests and replies, hence we only use this one, but keep in mind that the header is actually more complex. icmp_id: used in echo request/reply messages, to identify the request icmp_seq: identifies the sequence of echo messages, if more than one is sent. The User Datagram Protocol is a transport protocol for sessions that need to exchange data. Both transport protocols, UDP and TCP provide 65535 different source and destination ports. The destination port is used to connect to a specific service on that port. Unlike TCP, UDP is not reliable, since it doesn't use sequence numbers and stateful connections. This means UDP datagrams can be spoofed, and might not be reliable (e.g. they can be lost unnoticed), since they are not acknowledged using replies and sequence numbers. struct udpheader { unsigned short int uh_sport; unsigned short int uh_dport; unsigned short int uh_len; unsigned short int uh_check; }; / total udp header length: 8 bytes (=64 bits) / uh_sport: The source port that a client bind()s to, and the contacted server will reply back to in order to direct his responses to the client. uh_dport: The destination port that a specific server can be contacted on. uh_len: The length of udp header and payload data in bytes. uh_check: The checksum of header and data, see IP checksum. The Transmission Control Protocol is the mostly used transport protocol that provides mechanisms to establish a reliable connection with some basic authentication, using connection states and sequence numbers. (See IV. Basic transport layer operations.) struct tcpheader { unsigned short int th_sport; unsigned short int th_dport; unsigned int th_seq; unsigned int th_ack; unsigned char th_x2:4, th_off:4; unsigned char th_flags; unsigned short int th_win; unsigned short int th_sum; unsigned short int th_urp; }; / total tcp header length: 20 bytes (=160 bits) */ th_sport: The source port, which has the same function as in UDP.
th_dport: The destination port, which has the same function as in UDP. th_seq: The sequence number is used to enumerate the TCP segments. The data in a TCP connection can be contained in any amount of segments (=single tcp datagrams), which will be put in order and acknowledged. For example, if you send 3 segments, each containing 32 bytes of data, the first sequence would be (N+)1, the second one (N+)33 and the third one (N+)65. "N+" because the initial sequence is random. th_ack: Every packet that is sent and a valid part of a connection is acknowledged with an empty TCP segment with the ACK flag set (see below), and the th_ack field containing the previous the_seq number. th_x2: This is unused and contains binary zeroes. th_off: The segment offset specifies the length of the TCP header in 32bit/4byte blocks. Without tcp header options, the value is 5. th_flags: This field consists of six binary flags. Using bsd headers, they can be combined like this: th_flags = FLAG1 | FLAG2 | FLAG3... TH_URG: Urgent. Segment will be routed faster, used for termination of a connection or to stop processes (using telnet protocol). TH_ACK: Acknowledgement. Used to acknowledge data and in the second and third stage of a TCP connection initiation (see IV.). TH_PSH: Push. The systems IP stack will not buffer the segment and forward it to the application immediately (mostly used with telnet). TH_RST: Reset. Tells the peer that the connection has been terminated. TH_SYN: Synchronization. A segment with the SYN flag set indicates that client wants to initiate a new connection to the destination port. TH_FIN: Final. The connection should be closed, the peer is supposed to answer with one last segment with the FIN flag set as well. th_win: Window. The amount of bytes that can be sent before the data should be acknowledged with an ACK before sending more segments. th_sum: The checksum of pseudo header, tcp header and payload. The pseudo is a structure containing IP source and destination address, 1 byte set to zero, the protocol (1 byte with a decimal value of 6), and 2 bytes (unsigned short) containing the total length of the tcp segment. th_urp: Urgent pointer. Only used if the urgent flag is set, else zero. It points to the end of the payload data that should be sent with priority. III. Building and injecting datagrams Now, by putting together the knowledge about the protocol header structures with some basic C functions, it is easy to construct and send any datagram(s). We will demonstrate this with a small sample program that constantly sends out SYN requests to one host (Syn flooder). #define __USE_BSD /* use bsd'ish ip header / #include / these headers are for a Linux system, but / #include / the names on other systems are easy to guess.. / #include #define __FAVOR_BSD / use bsd'ish tcp header / #include #include #define P 25 / lets flood the sendmail port / unsigned short / this function generates header checksums */ csum (unsigned short *buf, int nwords) { unsigned long sum; for (sum = 0; nwords > 0; nwords--) sum += *buf++; sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); return ~sum;
if (setsockopt (s, IPPROTO_IP, IP_HDRINCL, val, sizeof (one)) < 0) printf ("Warning: Cannot set HDRINCL!\n"); } while (1) { if (sendto (s, /* our socket / datagram, / the buffer containing headers and data / iph->ip_len, / total length of our datagram / 0, / routing flags, normally always 0 */ (struct sockaddr ) &sin, / socket addr, just like in / sizeof (sin)) < 0) / a normal send() */ printf ("error\n"); else printf ("."); } return 0; } IV. Basic transport layer operations To make use of raw packets, knowledge of the basic IP stack operations is essential. I'll try to give a brief introduction into the most important operations in the IP stack. To learn more about the behavior of the protocols, one option is to exame the source for your systems IP stack, which, in Linux, is located in the directory /usr/src/linux/net/ipv4/. The most important protocol, of course, is TCP, on which I will focus on. Connection initiation: to contact an udp or tcp server listening on port 1234, the client calls a connect() with the sockaddr structure containing destination address and port. If the client did not bind() to a source port, the systems IP stack will select one it'll bind to. By connect()ing, the host sends a datagram containing the following information: IP src: client address, IP dest: servers address, TCP/UDP src: clients source port, TCP/UDP dest: port 1234. If a client is located on port 1234 on the destination host, it will reply back with a datagram containing: IP src: server IP dst: client srcport: server port dstport: clients source port. If there is no server located on the host, an ICMP type unreach message is created, subcode "Connection refused". The client will then terminate. If the destination host is down, either a router will create a different ICMP unreach message, or the client gets no reply and the connection times out. TCP initiation ("3-way handshake") and connection: The client will do a connection initiation, with the tcp SYN flag set, an arbitrary sequence number, and no acknowledgement number. The server acknowledges the SYN by sending a packet with SYN and ACK set, another random sequence number and the acknowledgement number the original sequence. Finally, the client replies back with a tcp datagram with the ACK flag set, and the server's ack sequence incremented by one. Once the connection is established, each tcp segment will be sent with no flags (PSH and URG are optional), the sequence number for each packet incremented by the size of the previous tcp segment. After the amount of data specified as "window size" has been transferred, the peer sending data will wait for an acknowledgement, a tcp segment with the ACK flag set and the ack sequence number the one of the last data packet that could be received in order. That way, if any segments get lost, they will not be acknowledged and can be retransmitted. To end a connection, both server and client send a tcp packet with correct sequence numbers and the FIN flag set, and if the connection ever de-synchronizes (aborted, desynchronized, bad sequence numbers, etc.) the peer that notices the error will send a RST packet with correct seq numbers to terminate the connection.
