Denial of Service (DoS) attack with UDP Flood



Denial of Service (DoS) attack with UDP Flood

Li Xiaoming Valon Sejdini Hasan Chowdhury

School of Computer Science School of Computer Science School of Computer Science

University of Windsor University of Windsor University of Windsor

Windsor, Ontario, Canada Windsor, Ontario, Canada Windsor, Ontario, Canada

li12364@uwindsor.ca sejdini@uwindsor.ca chowd1j@uwindsor.ca

Abstract

Computer and Network infrastructure has become hacker panicked domain that has increased geometrically over the years with the geometric integration and expansion of the integrated computer network of the globe. Every software component participating in the service of integrated global network ranging from PDA to Super Computer, as well as, home network to internet are subject to hacking threat. One Hand, every moment, hackers are discovering new ways and techniques to carry an attack; on the other hand victims are getting exhausted to face such attacks.

Like many of the categories and techniques of attack, Denial of Service (DoS) attacks has become a problem domain for the security, network, and other computer professionals, as well as the service providers and users of different computerized and network systems.

Denial of Service (DoS) attack is coordinated attacks performed by hackers to disable a particular computer service through manipulation of techniques those are used to provide the services. Some of the techniques used by hackers are branded as SYN Flooding, UDP flooding, stack overflow, etc.

In order to fulfill the requirement of the project, we will present the methodologies, tools, equipments and the lab-setup as well as the simulation result of a DoS attack using UDP flooding. We will also describe DoS attack models, scope, techniques, available tools to execute such an attack and the packet format and contents that we have found during the test using the packet sniffer software ‘Wireshark’. The countermeasures to face such attack are also presented in this paper.

Introduction

A Denial of Service (DoS) attack is an attack for preventing legitimate users from using a specific resource such as web services, network or a host. The hacker intentionally blocks the availability of the resource to its authorized users.

DoS attack using UDP flooding is a technique that executes the attack using the UDP packets. During the year 1998-2000 security specialist discovered “DoS attack with UDP flooding” vulnerabilities in many of the Systems including Microsoft products. Vulnerabilities were discovered in ACE/Server in its port 5000 against Fraggle attack. Cisco has also discovered vulnerabilities of its IOS software in routers against diagnostic port where attacker used two ports namely diagnostics ports and chargen port as attacking media to attack using UDP flooding.

Although DoS attack are not new, there is still a significant risk exists of such attack as the new technique of DoS attack are being invented by the hackers. This paper discusses existing taxonomies for understanding different DoS attacks, techniques and tools, and countermeasures. This paper discusses the setup and installation techniques of DoS attacking, monitoring and detection tools and techniques, setup of a test bed for simulation of a DoS attack using UDP flooding and the findings of the simulated test. In the following sections we describe classes of DoS attack architectures, categorization for DoS attacks, software characteristics for DoS attacking tools and DoS attack detection tools, the testbed setup, test result and classification of different DoS countermeasures. Finally we conclude and referenced in last two sections.

Motivation of DoS Attack and its Simulation

The motivation for DoS attacks is not to break into a system but to make the target system deny the legitimate user giving service. This will typically happen through one of the following ways:

• Crashing the target host system.

• Disabling communication between systems.

• Make the network or the system down or have it operate at a lower speed to reduce productivity.

• Freeze the system, so that there is no automatic reboot and lead to disruption of production.

The motivation of simulation of the DoS attack is:

• To generate a real attack based on testbed setup in a laboratory environment

• Observation of effect of the simulated attack

• Observation of ability and effect of a countermeasuring tool (IDS) to detect such attack.

DoS Attack Classes

The main classes of DoS attacks are

(i) Bandwidth Depletion attack

(ii) Resource Depletion attack

(i) The Bandwidth Depletion attack floods a victim network and thereby prevents authorized traffic from reaching and getting the service of the targeted victim.

1. Flood Attack

In this kind of attack, the network of the victims system is flooded with a large number of packets by the attacker to deplete the network bandwidth and thereby making the victim’s systems performance degradation or sometimes system crash. Due to saturation of the network bandwidth of the victim’s system, the legitimate users of the system are prevented from accessing the system.

[pic]

Fig 1: Schematic diagram for DOS attack

Flood attacks are being launched either with UDP or ICMP packets.

In a UDP Flood attack, numerous amounts of UDP packets are sent to either random or specified ports on the victim system. In order to determine the requested application, the victim system processes the incoming data. In case of absence of the requested application on the requested port, the victim system sends a “Destination unreachable” message to the sender (attacker). In order to hide the identity of the attacker, the attacker often spoofs the source IP address of the attacking packets. UDP flood attacks may also depletes the bandwidth of network around the victim’s system. Thereby, the systems around the victim are also impacted due to the UDP flooding attack.

2. The Fraggle Attack

This type of attack is usually used in UNIX and its family of OS platform, as well as, in network Routers and similar products. There are at least two service ports available (1) Echo (port #7 and (2) Chargen (port # 19) in this kind of OS or devices. Attacker sends UDP ECHO packets to the port that supports character generation (chargen port), with the return address spoofed to the victim’s echo service (echo port) creating an infinite loop.

The UDP ECHO packet (called as UDP Fraggle packet) targets the character generator (chargen port) of the systems reached by the broadcast address.

The chargen port generates a character and sends the same to the echo service (echo port) of the victim’s system. The victim’s system echo port then sends an echo packet back to the chargen port - the process repeats and generates a loop. Packet generation loop created in this fashion generates damaging traffic and cause severe damage in the system.

[pic]

Fig 3: Schematic diagram for Fraggle Attack

(ii) The Resource Depletion Attack is an attack that bind the resources of the target victim’s system (such as processor) making the victim unable to process valid requests for services.

Among the other flooding tools, UDP flooding is also used to deplete the resources of the victim system.

UDP Flooder (handy attacking tool)

UDP flooder is a handy attacking tool for Windows Platform. The tool can send a numerous number of UDP packets (chosen by attacker) at a selected speed from a host to another host. It uses a specific port to attack and also uses some imaginary source address.

[pic]

Fig 2: UDP flooder tool that is used for attack.

While testing with this tool, we have used three thread of the flooder and flooded the target computer with three different ports. And the result was two ways.

1. Tie-up the CPU that resulted to crash (shut-down of the victim system).

2. Reduced the network speed (communication between third computer and attacking host was very slow)

[pic]

Fig 4: Schematic diagram for UDP flood test bed.

Snort (the Sniffer and IDS)

Snort is free and open source software for network intrusion detection and prevention. It is capable of performing packet logging and real-time traffic analysis. We have used this to monitor the victim’s computer and detect if there is a flooding attack depending on the threshold value set in snort rule.

The laboratory setup

We have used three laptop, a workgroup hub, cat5e network cable to set the laboratory network. The role of the three computers were attacker, victim and the legitimate user. The attacker was armed with UDP flooder. Snort was installed and necessary snort rules were activated in the victim’s computer to monitor traffic volume and pattern and to detect the DoS attack.

While writing the snort rule we have setup a threshold value that is the indicating factor as an attack. When UDP flooding packet meeting the rule, reached snort (victim computer) was caught by snort. The snort rule was configured to generate an alert when the traffic flow reaches the threshold value. The setup information of the software and hardware, test procedure and test result is annexed with this report (Annexure: A).

[pic]

Fig 5: Schematic diagram of the Test bed network

The Test Method

Initially, ports were scanned on the victim’s computer to determine the available/ open port (ip: 10.0.0.8).

Some test packet were sent to the victim’s system and sniffed with Wireshark be configuring the snort rule particularly the parameter “content”.

We use the software ‘UDP flooder’ installed on hacker computer (ip 1.0.0.5), to send about 250 packets/second on port # 80 for about 60 seconds to hacker’s computer.

Snort was activated with IDS mode in the hacker’s computer with threshold count = 1000 and seconds 60 content: “UDP flood test”.

Following is the content of the rule file:

Code of Rule file: udp-flooding.RULES

# Copyright 2007 Project1-steven,valon,hasan

# DOS-UDP Flooding Attack RULE

alert udp $EXTERNAL_NET any -> $HOME_NET any (msg:"UDP_Flood Attack!!!!!"; content:"UDP Flood Test"; flow:stateless; threshold:type threshold, track by_dst, count 1000, seconds 60; classtype:attempted-dos; sid:1000001; rev:7;)

Test result

The IDS generates an alert (shown below). We have observed the CPU utilization and found that after beginning of attack and until it was crashed after 5 minutes, the CPU utilization was 100%. But before the attack begins the CPU utilization was only 2%. The natural result from the user’s request was denied when the victim system was crashed after 5 minutes of attack. The user response was slow during the first 5 minutes of attack.

Code of Alert file: alert.IDS

[**] [1:1000001:7] UDP_Flood Attack!!!!! [**]

[Classification: Attempted Denial of Service] [Priority: 2]

11/04-19:31:40.465554 10.0.0.5:1515 -> 10.0.0.8:80

UDP TTL:128 TOS:0x0 ID:35979 IpLen:20 DgmLen:45

Len: 17

Counter Measures

The core goal of the DoS defense is not to stop the DoS attacking packets, but to ensure that the legitimate users can continue to perform their normal work despite the presence of a DoS attack. Therefore, a good defense method must achieve that goal.

A good DoS defense method should target only true DoS attacks. Preventive methods should not have the effect of spoiling other forms of network traffic. Reactive methods should be activated only when a DoS attack is under way. False positives may cause indirect damage in many cases, but there are other undesirable methods of high false positive rates. For instance, when a reactive system detects and responds to a DoS attack, it can send a signal to the system administrator of the targeted system that it is taking action. In the case where most the signals proven to be false, then the system administrator will start to ignore them.

Some DoS counter measures concentrate on protecting you against the DoS. They try to ensure that your network and system will never suffer the DoS effect. Other counter measures concentrate on detecting attacks when they take place and by responding to them to reduce the DoS effect on your site.

The following counter measure mechanisms could help in defending the system, and one can build a more effective overall defense by combining several of them. Using a layered approach that combines several types of defenses, at several different locations, can be more flexible and harder for the hacker to completely bypass. These mechanisms include filtering, monitoring, port blocking and other adequate resources.

1. Filter ‘forged source addressed – spoofed IP’ packet with Network Ingress Filtering

In this type of filtering, the attacker’s packet with spoofed IP is caught and discarded at the first hand before reaching to another network.

[pic]

Fig 5: Ingress filtering

Algorithm of ingress filtering may be like this:

IF, the source address of the incoming packet in the router of the attacker destined to the network of the victim is within 192.176.10.0/24

THEN forward appropriate port

ELSE forward the packet to some other place as a ‘suspicious packet for action’ or discard it.

2. Disable the service port (port #7) and chargen port (port # 19) and filter the chargen and echo services – Fraggle attack.

• Fraggle attack exploited using the chargen or echo services. For most of the equipments and computers, these ports are usually not used for services. Therefore, it is recommended that these services (i.e. port#7 and port # 19) be disabled.

3. Disable and filter all unused UDP services

UDP flooding is done using specific or random ports of the victims system. Therefore, it is recommended that:

• All unused UDP services on hosts be disabled.

• Firewall is configured with all UDP ports less than 900 be blocked except some specific services, such as DNS (port 53).

4. Monitor your network.

In case, UDP services are accessible from external network, it is recommended that proper packet and flow monitoring is in place to learn which systems are using the UDP services and to monitor for any misuse by the external systems. Monitoring could be done using Snort, tcpdump, and netlog, etc. While monitoring with the Snort, suspicious packet may be detected using packet sniffer (we used wireshark) and filtered accordingly. Threshold for network flow may be fixed and alert is generated accordingly.

Conclusion

While doing the test, we could not make a real and practical setup due to lack of resources. However, we have obtained the desired outcome through the IDS (snort) that was expected for the test bed we set.

DoS attacks with UDP flooding are one of the many techniques hacker’s uses to make the attack. Such attacks are made to make the network and related services non-operational and thereby restricting the legitimate user from using the system.. In our paper we have presented the problems and the solution those are presently available and developed on the basis of the attack emerged at past. Future consequences of such kind of attack could be more critical and damaging to the technology and economy of the service providing system and organization.

As more amoral and not satisfied users of the Internet observe the success of DoS attacks, the chances for the frequency and severity of DoS attacks will increase. Until we find a reasonable defense against some type of DoS attacks, we can expect to see their occurrence, power, and gravity to increase. That is because of the network bandwidth, CPU speed, and number of available resources that can be hacked and compromised which all continue to increase, as does the advancement of hacking tools for compromising computers and using them to attack.

Therefore, it is a prime responsibility of the technologist, business man’s as well as the users of the computerized and networked system of the globe to invent effective solution to prevent such an attack at present and future.

References:

1. “Denial-of-Service attacks: Understanding

network vulnerabilities”,

2. Stephen Specht and Ruby Lee, “Distributed Denial of Service: Taxonomies of Networks, Attacks, Tools, and Countermeasures,” Princeton University, Department of Electrical Engineering Technical Report

3. “Winsort Configuration”,



4. “ Snort User Manual”,



5. “Snort From Wikipedia”,

(software)

6. “Snort and Winsnort”,





7. “WinDump Manual”,



8. Jelena Mirkovic, Sven Dietrich, David Dittrich,

Peter Reiher : “Internet Denial of Service: Attack and Defense Mechanisms”

Publisher: Prentice Hall PTR

9. Ryan Russell (Editor), Dan Kaminsky (Author), Rain Forest Puppy (Author), Joe Grand (Author), K2 (Author), David Ahmad (Author), Hal Flynn (Author), Ido Dubrawsky (Author), Steve W. Manzuik (Author), Ryan Permeh (Author) : “Hack Proofing Your Network (2nd edition)”

Annexure-A

Network setup:

We have 3 computers in our network, the hacker computer, IDS computer, and legitimate computer. A 5 port workgroup hub (10MB/S) with 3 cables connects three computers and make a local area network

1. Hacker computer

IP: 10.0.0.5

Subnet mask: 255.255.255.0

Network card:

2.\Device\NPF_{87BF08D7-392D-4D2B-8406-4C123BB567A0}(Broadcom NetXtreme Gigabit Ethernet Driver (Microsoft's Packet Scheduler) )

LAN: 100/1000 Mbps Fast Ethernet

2. IDS computer

IP: 10.0.0.8

Subnet mask: 255.255.255.0

Network card:

3.\Device\NPF_{88A867A3-0DF5-47E6-84A6-C37663DF457B} (SiS NIC SISNIC (Microsoft's Packet Scheduler))

LAN: 10/100 Mbps Fast Ethernet

3. Legitimate computer

IP: 10.0.0.2

Subnet mask: 255.255.255.0

Network card:

2.\Device\NPF_{F55030C1-CA2E-42D9-A73B-834595873C4D} (Realtek RTL8139 Family Fas

t Ethernet Adapter (Microsoft's Packet Scheduler) )

LAN: 100/1000 Mbps Fast Ethernet

IDS Computer Software configuration:

1. Snort configuration:

Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Steven>d:

D:\>cd d:\win-ids\snort\bin

D:\win-ids\snort\bin>snort -v -Afull -c test.conf -l D:\win-ids\snort\log -i 3

Running in IDS mode

--== Initializing Snort ==--

Initializing Output Plugins!

Var '_ADDRESS' redefined

Initializing Preprocessors!

Initializing Plug-ins!

Parsing Rules file test.conf

PortVar 'HTTP_PORTS' defined : [ 80]

PortVar 'SHELLCODE_PORTS' defined : [ 0:79 81:65535]

PortVar 'ORACLE_PORTS' defined : [ 1521]

Frag3 global config:

Max frags: 65536

Fragment memory cap: 4194304 bytes

Frag3 engine config:

Target-based policy: FIRST

Fragment timeout: 60 seconds

Fragment min_ttl: 1

Fragment ttl_limit: 5

Fragment Problems: 1

Stream5 global config:

Track TCP sessions: ACTIVE

Max TCP sessions: 8192

Memcap (for reassembly packet storage): 8388608

Track UDP sessions: INACTIVE

Track ICMP sessions: INACTIVE

Stream5 TCP Policy config:

Reassembly Policy: FIRST

Timeout: 30 seconds

Min ttl: 1

Options:

Static Flushpoint Sizes: YES

Reassembly Ports:

21 client (Footprint)

23 client (Footprint)

25 client (Footprint)

42 client (Footprint)

53 client (Footprint)

80 client (Footprint)

110 client (Footprint)

111 client (Footprint)

135 client (Footprint)

136 client (Footprint)

137 client (Footprint)

139 client (Footprint)

143 client (Footprint)

445 client (Footprint)

513 client (Footprint)

1433 client (Footprint)

1521 client (Footprint)

3306 client (Footprint)

HttpInspect Config:

GLOBAL CONFIG

Max Pipeline Requests: 0

Inspection Type: STATELESS

Detect Proxy Usage: NO

IIS Unicode Map Filename: ./unicode.map

IIS Unicode Map Codepage: 1252

DEFAULT SERVER CONFIG:

Server profile: All

Ports: 80 8080 8180

Flow Depth: 300

Max Chunk Length: 500000

Inspect Pipeline Requests: YES

URI Discovery Strict Mode: NO

Allow Proxy Usage: NO

Disable Alerting: NO

Oversize Dir Length: 500

Only inspect URI: NO

Ascii: YES alert: NO

Double Decoding: YES alert: YES

%U Encoding: YES alert: YES

Bare Byte: YES alert: YES

Base36: OFF

UTF 8: OFF

IIS Unicode: YES alert: YES

Multiple Slash: YES alert: NO

IIS Backslash: YES alert: NO

Directory Traversal: YES alert: NO

Web Root Traversal: YES alert: YES

Apache WhiteSpace: YES alert: NO

IIS Delimiter: YES alert: NO

IIS Unicode Map: GLOBAL IIS UNICODE MAP CONFIG

Non-RFC Compliant Characters: NONE

Whitespace Characters: 0x09 0x0b 0x0c 0x0d

rpc_decode arguments:

Ports to decode RPC on: 111 32771

alert_fragments: INACTIVE

alert_large_fragments: ACTIVE

alert_incomplete: ACTIVE

alert_multiple_requests: ACTIVE

Portscan Detection Config:

Detect Protocols: TCP UDP ICMP IP

Detect Scan Type: portscan portsweep decoy_portscan distributed_portscan

Sensitivity Level: Low

Memcap (in bytes): 10000000

Number of Nodes: 36900

Tagged Packet Limit: 256

Loading dynamic engine D:\win-ids\snort\lib\snort_dynamicengine\sf_engine.dll...

done

Loading all dynamic preprocessor libs from D:\win-ids\snort\lib\snort_dynamicpre

processor...

Loading dynamic preprocessor library D:\win-ids\snort\lib\snort_dynamicpreproc

essor\sf_dcerpc.dll... done

Loading dynamic preprocessor library D:\win-ids\snort\lib\snort_dynamicpreproc

essor\sf_dns.dll... done

Loading dynamic preprocessor library D:\win-ids\snort\lib\snort_dynamicpreproc

essor\sf_ftptelnet.dll... done

Loading dynamic preprocessor library D:\win-ids\snort\lib\snort_dynamicpreproc

essor\sf_smtp.dll... done

Loading dynamic preprocessor library D:\win-ids\snort\lib\snort_dynamicpreproc

essor\sf_ssh.dll... done

Finished Loading all dynamic preprocessor libs from D:\win-ids\snort\lib\snort

_dynamicpreprocessor

FTPTelnet Config:

GLOBAL CONFIG

Inspection Type: stateful

Check for Encrypted Traffic: YES alert: YES

Continue to check encrypted data: NO

TELNET CONFIG:

Ports: 23

Are You There Threshold: 200

Normalize: YES

Detect Anomalies: NO

FTP CONFIG:

FTP Server: default

Ports: 21

Check for Telnet Cmds: YES alert: YES

Identify open data channels: YES

FTP Client: default

Check for Bounce Attacks: YES alert: YES

Check for Telnet Cmds: YES alert: YES

Max Response Length: 256

SMTP Config:

Ports: 25

Inspection Type: Stateful

Normalize: EXPN RCPT VRFY

Ignore Data: No

Ignore TLS Data: No

Ignore SMTP Alerts: No

Max Command Line Length: Unlimited

Max Specific Command Line Length:

ETRN:500 EXPN:255 HELO:500 HELP:500 MAIL:260

RCPT:300 VRFY:255

Max Header Line Length: Unlimited

Max Response Line Length: Unlimited

X-Link2State Alert: Yes

Drop on X-Link2State Alert: No

Alert on commands: None

DCE/RPC Decoder config:

Autodetect ports ENABLED

SMB fragmentation ENABLED

DCE/RPC fragmentation ENABLED

Max Frag Size: 3000 bytes

Memcap: 100000 KB

Alert if memcap exceeded DISABLED

DNS config:

DNS Client rdata txt Overflow Alert: ACTIVE

Obsolete DNS RR Types Alert: INACTIVE

Experimental DNS RR Types Alert: INACTIVE

Ports: 53

+++++++++++++++++++++++++++++++++++++++++++++++++++

Initializing rule chains...

1 Snort rules read

1 detection rules

0 decoder rules

0 preprocessor rules

1 Option Chains linked into 1 Chain Headers

0 Dynamic rules

+++++++++++++++++++++++++++++++++++++++++++++++++++

+-------------------[Rule Port Counts]---------------------------------------

| tcp udp icmp ip

| src 0 0 0 0

| dst 0 0 0 0

| any 0 1 0 0

| nc 0 0 0 0

| s+d 0 0 0 0

+----------------------------------------------------------------------------

+-----------------------[thresholding-config]----------------------------------

| memory-cap : 1048576 bytes

+-----------------------[thresholding-global]----------------------------------

| none

+-----------------------[thresholding-local]-----------------------------------

| gen-id=1 sig-id=1000001 type=Threshold tracking=dst count=1000 seconds

=60

+-----------------------[suppression]------------------------------------------

| none

-------------------------------------------------------------------------------

Rule application order: activation->dynamic->pass->drop->alert->log

Log directory = D:\win-ids\snort\log

Verifying Preprocessor Configurations!

0 out of 512 flowbits in use.

Initializing Network Interface \Device\NPF_{88A867A3-0DF5-47E6-84A6-C37663DF457B

}

Decoding Ethernet on interface \Device\NPF_{88A867A3-0DF5-47E6-84A6-C37663DF457B

}

[ Port Based Pattern Matching Memory ]

+-[AC-BNFA Search Info Summary]------------------------------

| Instances : 5

| Patterns : 69

| Pattern Chars : 309

| Num States : 239

| Num Match States : 69

| Memory : 11.26Kbytes

| Patterns : 1.64K

| Match Lists : 1.50K

| Transitions : 7.69K

+-------------------------------------------------

[ Port and Service Based Pattern Matching Memory ]

+-[AC-BNFA Search Info Summary]------------------------------

| Instances : 5

| Patterns : 69

| Pattern Chars : 309

| Num States : 239

| Num Match States : 69

| Memory : 11.26Kbytes

| Patterns : 1.64K

| Match Lists : 1.50K

| Transitions : 7.69K

+-------------------------------------------------

--== Initialization Complete ==--

,,_ -*> Snort! ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download