This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Network security consists of the provisions made in an underlying computer network infrastructure, policies adopted by the network administrator to protect the network and the network-accessible resources from unauthorized access, and consistent and continuous monitoring and measurement of its effectiveness combined together.
Network security starts from authenticating any user with a username and a password. Once authenticated, a statefull firewall enforces access policies such as what services are allowed to be accessed by the network users. Though effective to prevent unauthorized access, this component fails to check potentially harmful content such as computer worms being transmitted over the network. An Intrusion Prevention System (IPS) helps to detect and inhibit the action of such malware. An Anomaly-Based Intrusion Detection System monitors network traffic for suspicious content, unexpected traffic and other anomalies to protect the network e.g. from denial of service attacks or an employee accessing files at strange times. Communication between two hosts using the network could be encrypted to maintain privacy. Individual events occurring on the network could be tracked for audit purposes and for a later high level analysis.
1.2 THREATS AND ATTACKS
Attacks can be based on system software or data. System software based attacks include:
Automated or user-initiated network-aware attacks (viruses, worms, Trojan horses, peer-to-peer) which targets files and data often causing loss of machine control, productivity and time.
Malicious system misuse which targets shared resources and protected data.
Unmonitored software installation - unknown, untested or unstable programs installed along with intended items that interfere with supported applications leading to unreliable systems and loss of productivity data Integrity, Confidentiality and Availability based attack target.
Data loss from any resource with electronic data storage.
1.3 DDoS Attack Description
DDoS attacks attempt to exhaust the victim's resources. These resources can be network bandwidth, computing power, or operating system data structures. To launch a DDoS attack, malicious users first build a network of computers that they will use to produce the volume of traffic needed to deny services to computer users. To create this attack network, attackers discover vulnerable sites or hosts on the network. Vulnerable hosts are usually those that are either running no antivirus software or out-of-date antivirus software, or those that have not been properly patched. Vulnerable hosts are then exploited by attackers who use their vulnerability to gain access to these hosts. The next step for the intruder is to install new programs (known as attack tools) on the compromised hosts of the attack network. The hosts that are running these attack tools are known as zombies, and they can carry out any attack under the control of the attacker. Many zombies together form what we call an army.
1.4 Typical DDoS Attacks
In a typical DDoS attack, as shown in figure 1.1 the army of the attacker consists of master zombies and slave zombies. The hosts of both categories are compromised machines that have arisen during the scanning process and are infected by malicious code. The attacker coordinates and orders master zombies and they, in turn, coordinate and trigger slave zombies. More specifically, the attacker sends an attack command to master zombies and activates all attack processes on those machines, which are in hibernation, waiting for the appropriate command to wake up and start attacking. Then, master zombies, through those processes, send attack commands to slave zombies, ordering them to mount a DDoS attack against the victim. In that way, the agent machines (slave zombies) begin to send a large volume of packets to the victim, flooding its system with useless load and exhausting its resources.
Figure 1.4 DDoS Attack
In cases of DDoS attacks, spoofed source IP addresses are used in the packets of the attack traffic. An attacker prefers to use such counterfeit source IP addresses for two major reasons: first, the attackers want to hide the identity of the zombies so that the victim cannot trace the attack back to them. The second reason concerns the performance of the attack. The attackers want to discourage any attempt of the victim to filter out the malicious traffic.
1.5 DRDoS Attacks
Unlike typical DDoS attacks, in DRDoS attacks, shown in figure 1.5 as the army of the attacker consists of master zombies, slave zombies, and reflectors. The scenario of this type of attack is the same as that of typical DDoS attacks up to a specific stage. The attackers have control over master zombies, which, in turn, have control over slave zombies. The difference in this type of attack is that slave zombies are led by master zombies to send a stream of packets with the victim's IP address as the source IP address to other uninfected machines (known as reflectors), exhorting these machines to connect with the victim. Then the reflectors send the victim a greater volume of traffic, as a reply to its exhortation for the opening of a new connection, because they believe that the victim was the host that asked for it. Therefore, in DRDoS attacks, the attack is mounted by non-compromised machines, which mount the attack without being aware of the action.
Figure 1.5 DRDoS Attacks
Comparing the two scenarios of DDoS attacks, we should note that a DRDoS attack is more detrimental than a typical DDoS attack. This is because a DRDoS attack has more machines to share the attack, and hence the attack is more distributed. A second reason is that a DRDoS attack creates a greater volume of traffic because of its more distributed nature.
1.6 OVERVIEW OF BOTNETS
Distributed Denial of Service (DDoS) attacks pose a critical threat to the Internet. Botnets perform the DDoS attack which is controlled by a bot master. Motivated by huge financial rewards, such as renting out their botnets for attacks or collecting sensitive information for malicious purposes, hackers are encouraged to organize botnets to commit these crimes. In order to sustain their botnets, botmasters take advantage of various anti forensic techniques to disguise their traces, such as memory encryption, fresh code pushing for Resurrection, peertopeer implementation technology or flash crowd mimicking. Flash crowds are unexpected, but legitimate, dramatic surges of access to a server, such as breaking news. One powerful strategy for attackers is to simulate the traffic patterns of flash crowds. This is referred to as a flash crowd attack. There are a number of reports on the size and organization of botnets.
Bots are caught by honey pots and analyzed thoroughly via inverse engineering techniques. Another methodology is the calculation of flow correlation coefficient by Shui Yu. The flow correlation coefficient is calculated based upon (1) network flow, (2) flow strength, (3) flow finger print.
1.7 ATTACK DETECTION TECHNIQUES
Human behavior based approach
There are three defenses against flash-crowd attacks which differentiate humans from bots based on the uniqueness of human behavior with regard to a) request dynamics, by learning several chosen features of human interaction dynamics, and detecting bots that exhibit higher aggressiveness in one or more of these features, b) request semantics, by learning transitional probabilities of user requests, and detecting bots that generate valid but low-probability sequences, and c) ability to process visual cues, by embedding into server replies human-invisible objects, which cannot be detected by automated analysis, and flagging users that visit them as bots.
Honey pot based approach
A honey pot is a program, machine, or system put on a network as bait for attackers. The idea is to deceive the attacker by making the honeypot seem like a legitimate system. Honeypots are typically virtual machines that emulate real machines by feigning running services and open ports, services which one might find on a typical machine on a network. These running services are meant to attract the attention of attackers so that they spend valuable time and resources will be used to try to exploit the machine while the attacker is being monitored and recorded by the honeypot.
ORGANISATION OF THE REPORT
The rest of the report is organized as follows. In Chapter 2, survey on various papers and articles related to the project work is discussed. In Chapter 3, proposed design with block diagram, implementation ideas and simulation results of completed modules are presented. In Chapter 4 project conclusion along with future work and directions are given.
2.1 A Survey of Bots Used for Distributed Denial of Service Attacks
Discrimination of DDoS attacks from flash crowds, remains an open problem to date. Distributed Denial of Service (DDoS) attacks pose a critical threat to the Internet. A recent survey of the 70 largest Internet operators in the world demonstrated that DDoS attacks have increased dramatically in recent years. Moreover, individual attacks are becoming stronger and more sophisticated. Motivated by huge financial rewards, such as renting out their botnets for attacks or collecting sensitive information for malicious purposes, hackers are encouraged to organize botnets to commit these crimes. Furthermore, in order to sustain their botnets, botmasters take advantage of various antiforensic techniques to disguise their traces, such as code obfuscation, memory encryption, fresh code pushing for resurrection, peer-to-peer implementation technology, or flash crowd mimicking.
Global Internet threats are undergoing a profound transformation from attacks designed solely to disable infrastructure to those that also target people and organizations. This alarming new class of attacks directly impacts the day-to- day lives of millions of people and endangers businesses and governments around the world. For example, computer users are assailed with spyware that snoops on confidential information, spam that floods email packets, and phishing scams that steal identities. At the center of many of these attacks is a large pool of compromised computers located in homes, schools, businesses, and governments around the world. Attackers use these zombies as anonymous proxies to hide their real identities and amplify their attacks. Bot software enables an operator to remotely control each system and group them together to form what is commonly referred to as a zombie army or botnet.
One core problem for botnet attackers is how to get bots onto victim computers. Because very few users would actually agree to have their computers used to conduct packet floods, attackers surreptitiously install their malicious software. This process of getting malicious software on victim's hosts has evolved significantly over time. One change that happened a few years ago is the shift from a single propagation vector, that might have required a manual installation process by the attacker, to multiple automated propagation vectors.
A popular form of DDoS today are application-level floods, aka "flash-crowd attacks" that target application resources. Their name originates from a legitimate phenomenon, known as a "flash crowd," where many users simultaneously access a server because of some popular event. Attackers mimic this by deploying a large, distributed bot network and generating legitimate application requests that overwhelm the victim. Flash-crowd attacks are extremely challenging because they request legitimate and business-critical content. Thus their traffic appears legitimate-like, which makes defenses that detect and filter malicious traffic ineffective against flashcrowd attacks. Further, attack bots can send at a low-rate or infrequently, leading to failure of techniques that monitor each client's rate and blacklist aggressive clients. The usage of many bots that send at a low rate is the main strategy adopted by today's attackers to bring down a service application.
We have proposed three defenses against flash-crowd attacks which differentiate humans from bots based on the uniqueness of human behavior with regard to
choice of content to access and
ability to ignore invisible content. Our tests show that the proposed defenses significantly raise the bar for a successful, sustained attack.
2.2 Collaborative detection and filtering of shrewDDoS attacks using spectral analysis
In this survey, our main contributions are twofold. First, we provide a detailed study of the challenges posed by the DoS and DDoS attack problem and their root causes. Second, we provide a thorough analysis of the strengths and weaknesses of state-of art DoS and DDoS defense mechanisms, and highlight opportunities for an integrated solution to solve the DDoS attack problem. DoS attacks generally achieve their goal by sending large volumes of packets that occupy a significant proportion of the available bandwidth. Hence, DoS attacks are also called bandwidth attacks. The aim of a bandwidth attack is to consume critical resources in a network service. Possible target resources may include CPU capacity in a server, stack space in network protocol software, or Internet link capacity. By exhausting these critical resources, the attacker can prevent legitimate users from accessing the service.
These attacks are stealthy, periodic, pulsing, and low-rate in attack volume, very different from the flooding type of attacks. They are launched with high narrow spikes in very low frequency, periodically. Thus, shrew attacks may endanger the victim systems for a long time without being detected. In other words, such attacks may reduce the quality of services unnoticeably. Our defense method calls for collaborative detection and filtering (CDF) of shrew DDoS attacks. We detect shrew attack flows hidden in legitimate TCP/UDP streams by spectral analysis against pre-stored template of average attack spectral characteristics. This novel scheme is suitable for either software or hardware implementation. The CDF scheme is implemented with the NS-2 network simulator using real-life Internet background traffic mixed with attack datasets used by established research groups. Our simulated results show high detection accuracy by merging alerts from cooperative routers. Both theoretical modeling and simulation experimental results are reported here. The experiments achieved up to 95% successful detection of network anomalies along with a low 10% false positive alarms. The scheme cuts off malicious flows containing shrew attacks using a newly developed packet-filtering scheme. Our filtering scheme retained 99% of legitimate TCP flows, compared with only 20% TCP flows retained by using the Drop Tail algorithm.
A crucial feature of bandwidth attacks is that their strength lies in the volume rather than the content of the attack traffic. This has two major implications:
(1) Attackers can send a variety of packets. The attack traffic can be made arbitrarily similar to legitimate traffic, which greatly complicates defense.
(2) The volume of traffic must be large enough to consume the target's resources. The attacker usually has to control more than one computer to generate the attack traffic. Bandwidth attacks are therefore commonly DDoS attacks.
This makes the Internet extremely robust in comparison to traditional telephone networks. However, it makes traceability of packets extremely difficult. IP packets are forwarded based on their destination address, rather than a predefined path. Many factors, such as delay on a link, can contribute to the changeability of the path a packet is traveling. Hence, the set of IP addresses that appear at a given interface of a router can be highly variable. If a router receives a packet from a source that has not been seen before, then the router has no way of knowing whether this is a spoofed packet, or a legitimate packet that is following a new route as a result of congestion or failure elsewhere in the network. While this flexibility helps make the Internet robust, it also makes IP address authentication difficult.
A "botnet" consists of a network of compromised computers controlled by an attacker ("botmaster"). Recently botnets have become the root cause of many Internet attacks. To be well prepared for future attacks, it is not enough to study how to detect and defend against the botnets that have appeared in the past. More importantly, we should study advanced botnet designs that could be developed by botmasters in the near future. In this paper, we present the design of an advanced hybrid peerto- peer botnet. Compared with current botnets, the proposed botnet is harder to be shut down, monitored, and hijacked. It provides robust network connectivity, individualized encryption and control traffic dispersion, limited botnet exposure by each bot, and easy monitoring and recovery by its botmaster. Possible defenses against this advanced botnet are suggested. Bots in the botnet connect directly to some special hosts (called "command-and-control" servers, or "C&C" servers). These C&C servers receive commands from their botmaster and forward them to the other bots in the network.
2.3 Botz4Sale: Surviving Organized DDoS Attacks That Mimic Flash Crowds
Now a days denial of service attacks are mounted by professionals using Botnets of tens of thousands of compromised machines. To circumvent detection, attackers are increasingly moving away from bandwidth ï¬‚oods to attacks that mimic the Web browsing behavior of a large number of clients, and target expensive higher-layer resources such as CPU, database and disk bandwidth. The resulting attacks are hard to defend against using standard techniques, as the malicious requests differ from the legitimate ones in intent but not in content. We present the design and implementation of Kill-Bots, a kernel extension to protect Web servers against DDoS attacks that masquerade as ï¬‚ash crowds. Kill-Bots provides authentication using graphical tests but is different from other systems that use graphical tests. First, Kill-Bots uses an intermediate stage to identify the IP addresses that ignore the test, and persistently bombard the server with requests despite repeated failures at solving the tests. These machines are bots because their intent is to congest the server. Once these machines are identiï¬ed, Kill-Bots blocks their requests, turns the graphical tests off, and allows access to legitimate users who are unable or unwilling to solve graphical tests. Second, Kill-Bots sends a test and checks the client's answer without allowing unauthenticated clients access to sockets, TCBs, and worker processes. Thus, it protects the authentication mechanism from being DDoSed. Third, KillBots combines authentication with admission control. As a result, it improves performance, regardless of whether the server overload is caused by DDoS or a true Flash Crowd.
Dos attacks are increasingly mounted by professionals in exchange for money or material benefits. Botnets of thousands of compromised machines are rented by the hour on IRC and used to DDoS online businesses to extort money or obtain commercial advantages. The DDoS business is thriving; increasingly aggressive worms can infect up to 30,000 new machines per day. These zombies/bots are then used for DDoS and other attacks . Recently, a Massachusetts
businessman paid members of the computer underground to launch organized, crippling DDoS attacks against three of his competitors. The attackers used Botnets of more than 10,000 machines. When the simple SYN flood failed, they launched an HTTP flood, pulling large image files from the victim server in overwhelming numbers. At its peak, the onslaught allegedly kept the victim company offline for two weeks. In another instance, attackers ran a massive number of queries through the victim's search engine, bringing the server down. To circumvent detection, attackers are increasingly moving away from pure bandwidth floods to stealthy DDoS attacks that masquerade as flash crowds. They profile the victim server and mimic legitimate Web browsing behavior of a large number of clients. These attacks target higher layer server resources like sockets, disk bandwidth, database bandwidth and worker processes. We call such DDoS attacks CyberSlam, after the first FBI case involving DdoS-forhire. The MyDoom worm, many DDoS extortion attacks, and recent DDoS-for-hire attacks are all instances of CyberSlam. Countering CyberSlam is a challenge because the requests originating from the zombies are indistinguishable from the requests generated by legitimate users. The malicious requests differ from the legitimate ones in intent but not in content. The malicious requests arrive from a large number of geographically distributed machines; thus they cannot be filtered on the IP prefix. Also, many sites do not use passwords or login information, and even when they do, passwords could be easily stolen from the hard disk of a compromised machine. Further, checking the site-specific password requires establishing a connection and allowing unauthenticated clients to access socket buffers, TCBs, and worker processes, making it easy to mount an attack on the authentication mechanism itself. Defending against CyberSlam using computational puzzles,
which require the client to perform heavy computation before accessing the site, is not effective because computing power is usually abundant in a Botnet. Finally, in contrast to bandwidth attacks, it is difficult to detect big resource consumers when the attack targets higher-layer bottlenecks such as CPU, database, and disk because commodity operating systems do not support fine-grained resource monitoring. Further, an attacker can resort to mutating attacks which cycle between different bottlenecks
The Internet literature contains a large body of research on denial of service solutions. The vast majority assume that the destination can distinguish between malicious and legitimate traffic by performing simple checks on the content of packets, their headers, or their arrival rates. Yet, attackers are increasingly disguising their traffic by mimicking legitimate users access patterns, which allows them to defy traditional filters. This paper focuses on protecting Web servers from DDoS attacks that masquerade as Flash Crowds. Underlying our solution is the assumption that most online services value human surfers much more than automated accesses. We present a novel design that uses CAPTCHAs to distinguish the IP addresses of the attack machines from those of legitimate clients. In contrast to prior work on CAPTCHAs, our system allows legitimate users to access the attacked server even if they are unable or unwilling to solve graphical tests. We implemented our design in the Linux kernel and evaluated.
2.4 Modeling Human Behavior for Defense against Flash-Crowd Attacks
Flash-crowd attacks are the most vicious form of distributed denial of service (DDoS). They flood the victim with service requests generated from numerous bots. Attack requests are identical in content to those generated by legitimate, human users, and bots send at a low rate to appear non-aggressive these features defeat many existing DDoS defenses. We propose defenses against flash-crowd attacks via human behavior modeling, which differentiate DDoS bots from human users. Current approaches to human-vs-bot differentiation, such as graphical puzzles, are insufficient and annoying to humans, whereas our defenses are highly transparent. We model three aspects of human behavior: a) request dynamics, by learning several chosen features of human interaction dynamics, and detecting bots that exhibit higher aggressiveness in one or more of these features, b) request semantics, by learning transitional probabilities of user requests, and detecting bots that generate valid but low-probability sequences, and c) ability to process visual cues, by embedding into server replies human-invisible objects, which cannot be detected by automated analysis, and flagging users that visit them as bots. We evaluate our defenses' performance on a series of web traffic logs, interlaced with synthetically generated attacks, and conclude that they raise the bar for a successful, sustained attack to botnets whose size is larger than the size observed in 1-5% of DDoS attacks today.
In "flash-crowd attacks" the target application resources. Their name originates from a legitimate phenomenon, known as a "flash crowd," where many users simultaneously access a server because of some popular event. Attackers mimic this by deploying a large, distributed bot network and generating legitimate application requests that overwhelm the victim. Flash-crowd attacks are extremely challenging because they request legitimate and business-critical content. Thus their traffic appears legitimate-like, which makes defenses that detect and filter malicious traffic ineffective against flashcrowd attacks. Further, attack bots can send at a low-rate or infrequently, leading to failure of techniques that monitor each client's rate and blacklist aggressive clients. The usage of many bots that send at a low rate is the main strategy adopted by today's attackers to bring down a service application. This research was supported in part by the National Science Foundation under contract number 0430228. Views expressed in this paper are those of the authors and do not necessarily reflect views of the NSF.
Our Scope is not to detect all bots but only those that may participate in flash-crowd attacks. Traditional DDoS attacks that flood a victim with junk traffic can be handled by existing defenses. Bots involved in legitimate activities (e.g., search bots) and in non-DDoS malicious activities (e.g., spamming) will likely be missed by our approaches. We play the attacker's need to generate a steady, high-rate flow of service requests to deny service, against his need to use stealthy bots to avoid detection. Our models detect all but the stealthiest of bots. This forces an attacker to either face detection and replace detected bots with new ones, or to increase stealth. Both these strategies increase the minimum botnet size needed for a successful, sustained attack. We show that the required size, when our defenses are active, is higher than the one observed in 95- 99% of DDoS attacks today
We illustrate our deception techniques in the by showing a modified homepage of Amazon.com with revealed deception. We use red colors and red dots to indicate where the deception objects lie. Without revealing, the new page is visually identical to the original one We have proposed three defenses against flash-crowd attacks which differentiate humans from bots based on the uniqueness of human behavior with regard to
choice of content to access
ability to ignore invisible
content. Our tests show that the proposed defenses significantly raise the bar for a successful, sustained attack. Botnets observed in 95-99% attacks today would be discovered and their traffic filtered by our techniques. We plan to investigate a combination of our approaches in the future, hoping to achieve synergistic effect and further improve performance. We also plan to implement our techniques in the Apache Web server and test them in two environments (1) with synthetic legitimate and attack traffic to evaluate the server's overhead, (2) with human users to investigate likelihood of false positives.
2.5 Survey of Network-Based Defense Mechanisms Countering the DoS and DdoS Problems:
This article presents a survey of denial of service attacks and the methods that have been proposed for defense against these attacks. In this survey, we analyze the design decisions in the Internet that have created the potential for denial of service attacks. We review the state-of-art mechanisms for defending against denial of service attacks, compare the strengths and weaknesses of each proposal, and discuss potential countermeasures against each defense mechanism. We conclude by highlighting opportunities for an integrated solution to solve the problem of distributed denial of service attacks. The Internet was originally designed for openness and scalability. The infrastructure is certainly working as envisioned by that yardstick. However, the price of this success has been poor security. For example, the Internet Protocol (IP) was designed to support ease of attachment of hosts to networks, and provides little support for verifying the contents of IP packet header fields [Clark 1988]. This makes it possible to fake the source address of packets, and hence difficult to identify the source of traffic. Moreover, there is no inherent support in the IP layer to check whether a source is authorized to access a service. Packets are delivered to their destination, and the server at the destination must decide whether to accept and service these packets.
The original aim of the Internet was to provide an open and scalable network among research and educational communities [Lipson 2002]. In this environment, security issues were less of a concern. The occurrence of the Morris Worm [Rochlis and Eichin 1989] in 1988 marked the first major computer security incident on the Internet. However, at that time, the world was not so dependent on the Internet as it is now. Unfortunately, with the rapid growth of the Internet over the past decade, the number of attacks on the Internet has also increased rapidly. According to CERT, the number of reported Internet security incidents has jumped from six in 1988 to 82,094 in 2002, and to 137,529 in 2003 [CERT 2006]. Due to the excessive number of security incidents, CERT has decided not to publish the number of incidents reported since 2004. The growth in the number of incidents reported between 1998 to 2003, the Computer Security Institute (CSI) and the FBI released a survey on the prevalence and character of computer crime based on the responses from 700 security analysts and Chief Security Officers (CSO) from mid-to-large firms in the U.S. [Gordon et al. 2005]. Table I lists the percentage of the participants who were targeted by a DoS attack between 1999 and 2005.We can see that a considerable proportion of respondents have suffered from DoS attacks.
While there has been considerable research effort into defenses against DDoS attacks, there has been only limited progress in solving the DDoS problem. Most approaches focus on detecting and filtering attack traffic near the target of the attack. The main limitation of this general approach is that the computational and network resources available to the attacker can readily exceed that of the target. This is because attackers have been able to increase their attack power by gaining control of large numbers of zombie computers. Given the large number of traffic sources at their disposal, attackers no longer need to hide the identity of the "zombies" using spoofing. This means that the "zombies" can engage in more complex transactions such as authentication requests or Web queries, which are difficult to differentiate from legitimate traffic. In order to respond to this growth in attack power, defenders need a more scalable approach to defense. In this section, we highlight opportunities for a more integrated solution to defense against DDoS attacks, which could enable the target to marshal additional resources to assist in defending against large-scale attacks. Before we examine the needs of an integrated approach to large-scale attacks, let us first examine how smaller scale attacks can be handled at the target. Consider how the difficulty of defending against an attack varies with the number of attack sources and whether those sources use IP address spoofing to hide their true source address. In the simplest case of a single attack source using its true identity, the attack source can easily be identified at the target based on the volume of traffic that it sends. High-volume ACM Computing Surveys, sources can be rate-limited, or discarded if they do not respond to flow control requests. In the case of a single source using multiple source addresses, the attack sources cannot be reliably determined based on the volume of traffic that they send, since the traffic volume is split between multiple spoofed source addresses from the target's point of view. Defense at the target relies on trying to filter attack traffic from normal traffic based on some anomalous feature of the attack traffic. The case of multiple attack sources, each using multiple source addresses, also relies on filtering at the target. However, as the attack power grows by using multiple sources, the computational requirements of filtering can become a burden at the target. In practice, many attacks now involve multiple sources using their true source identities. In this case, each attacker can establish valid TCP connections and generate legal requests of the target. This makes filtering at the target a more challenging problem, due to the difficulty in identifying legal, but malicious, requests. A complementary approach to blocking attack traffic is to limit the rate at which sources can generate requests. If a target service is designed for use by a person, then it may be reasonable to filter all traffic that is generated by an automated source, for example, an attack "zombie." When an unfamiliar source uses a service for the first time, then it must first complete an admission challenge that requires human judgment, such as reading a character string that has been presented as an image [Morein et al. 2003]. This denies access to automated sources, which would be unable to complete the challenge. Such challenges can be reissued to a source if that source starts to generate a large number of requests, that is, the person has been replaced by an automated source. A variant on this approach has been proposed for target services that are intended for use by automated sources, for example, DNS servers. In this case, the admission challenge takes the form of a computational puzzle, which is designed to be easy to set and verify, but hard to solve, for example, a constraint satisfaction problem [Kandula et al. 2005]. In this case, any additional requests from a source are blocked until the initial challenge has been solved. However, this form of puzzle-based challenge requires compatible client software at the source, which may limit the deployment of this approach. Similarly, admission challenges that require human judgment can create more work for legitimate users, and may not achieve user acceptance. Furthermore, both types of challenge still require some computational resources at the target, which can become a bottleneck during an attack. All of the above defense techniques place the burden of defense on the target of the attack. In contrast, the attacker has the potential to increase their attack power by infecting more "zombie" computers. A possible approach to redress this imbalance is to provide an integrated defense solution that enables filtering and admission challenges to be implemented in a distributed manner throughout the network on behalf of the target. The defense measures can then propagate back into the network from the target towards the sources when attacks occur. Under normal conditions, no filtering or admission challenges are required. When an attack begins, these defense measures are first implemented centrally at the target. If the attack persists or worsens, then the target could propagate a distress signal upstream to its Internet Service Provider (ISP), who could deploy proxy defenses at the ingress points to the ISP's network on behalf of the target.. Furthermore, both the number of Internet users and the users' bandwidth have kept increasing dramatically. Unfortunately, the average security knowledge for current Internet users is decreasing while attacks are becoming more and more sophisticated [Lipson 2002]. As a result, the attack power is expanding rapidly. On the other hand, although the security community works very hard to patch the vulnerabilities, defense effects are limited due to the lack of central control of the Internet.
3.1 EXISTING SYSTEM
Distributed Denial of Service (DDoS) attack is a critical threat to the Internet, and botnets are usually the engines behind them. Sophisticated botmasters attempt to disable detectors by mimicking the traffic patterns of flash crowds. This poses a critical challenge to those who defend against DDoS attacks. In our deep study of the size and organization of current botnets, we found that the current attack flows are usually more similar to each other compared to the flows of flash crowds. Based on this, we proposed a discrimination algorithm using the flow correlation coefficient as a similarity metric among suspicious flows.
DDoS attacks attempt to exhaust the victim's resources. These resources can be network bandwidth, computing power, or operating system data structures. To launch a DDoS attack, malicious users first build a network of computers that they will use to produce the volume of traffic needed to deny services to computer users. To create this attack network, attackers discover vulnerable sites or hosts on the network.. The next step for the intruder is to install new programs (known as attack tools) on the compromised hosts of the attack network. The hosts that are running these attack tools are known as zombies, and they can carry out any attack under the control of the attacker. Many zombies together form what we call an army.
The attacker coordinates and orders master zombies and they, in turn, coordinate and trigger slave zombies. More specifically, the attacker sends an attack command to master zombies and activates all attack processes on those machines, which are in hibernation, waiting for the appropriate command to wake up and start attacking. Then, master zombies, through those processes, send attack commands to slave zombies, ordering them to mount a DDoS attack against the victim. In that way, the agent machines (slave zombies) begin to send a large volume of packets to the victim, flooding its system with useless load and exhausting its resources.
3.2 PROPOSED SYSTEM
To overcome the short comings of the previous discrimination methods we used distance based routing and an IP traceback mechanism for discriminating the attack flows from normal request flows. The anomaly-based detection metric typically models the normal network (traffic) behavior and deploys it to compare differences with incoming network behavior. Anomaly-based detection has many limitations. DDoS attack traffic which is different from real surging accessing in a short period of time. However, attackers can adopt a multiple attack package generation function in one attack to easily fool the proposed detection algorithm. To some extent these measures can be used to evaluate the quality of anomaly detection methods and build the appropriate anomaly detection models even though it is very difficult to build an adaptive model that can dynamically adjust to different sequence lengths (or time windows) based on run-time information.
IP trace back is the ability to find the source of an IP packet without relying on the source IP field in the packet, which is often spoofed. We combine our DDoS attacks detection metric with IP trace back algorithm and filtering technology together to form an effective collaborative defense mechanism against network security threats in Internet. Trace back algorithm calculates distances based on variations of its local traffic and the forward traffic from its immediate upstream routers; we set LAN of router include the victim. If the distance based on its local traffic is more than the specific detection threshold, the proposed detection system detects an attack in its LAN; this means that the detected attack is an internal attack. If the distances based on the forward traffic from its immediate upstream routers and are both more than the specific detection threshold, the proposed detection system has detected attacks in routers and , then on and the proposed trace back algorithm calculates distances based on variations of their local traffic and the forward traffic from their immediate upstream routers, and will find that there are no attacks in LAN and; therefore, on routers, and ,the proposed algorithm calculates continually information distances based on variations of their local traffic and the forward traffic from their immediate upstream routers, then can find there is an attack (zombie) in LAN so the router will stop forwarding the traffic from the zombie immediately.
We design the related algorithms according to our previous modeling and analysis. There are two algorithms in the proposed trace back suite, the local flow monitoring algorithm and the IP trace back algorithm. The local flow monitoring algorithm is running at the non attack period, accumulating information from normal network flows, and progressing the mean and the standard variation of flows. The progressing suspends when a DDoS attack is ongoing. Once a DDoS attack has been confirmed by any of the existing DDoS detection algorithms, then the victim starts the IP trace back algorithm. The IP trace back algorithm is installed at routers. It is initiated by the victim, and at the upstream routers, it is triggered by the IP traceback requests from the victim or the downstream routers which are on the attack path. The proposed algorithms are independent from the current routing software, they can work as independent modules at routers.
We propose a novel mechanism for IP trace back using information theoretical parameters, and there is no packet marking in the proposed strategy; we, therefore, can avoid the inherited shortcomings of the packet marking mechanisms. We categorize packets that are passing through a router into flows, which are defined by the upstream router where a packet came from, and the destination address of the packet. During non attack periods, routers are required to observe and record entropy variations of local flows. In this paper, we use flow entropy variation or entropy variation interchangeably.
Once a DDoS attack has been identified, the victim initiates the following pushback process to identify the locations of zombies: the victim first identifies which of its upstream routers are in the attack tree based on the flow entropy variations it has accumulated, and then submits requests to the related immediate upstream routers. The upstream routers identify where the attack flows came from based on their local entropy variations that they have monitored. Once the immediate upstream routers have identified the attack flows, they will forward the requests to their immediate upstream routers, respectively, to identify the attacker sources further; this procedure is repeated in a parallel and distributed fashion until it reaches the attack source(s) or the discrimination limit between attack flows and legitimate flows is satisfied.
A Complete specification of hardware and software requirements is essential for the success of software development .This software has been developed with very powerful and high performance multi-user computing system. It is applicable in the areas where much processing speed is required
4.1 HARDWARE REQUIREMENTS
Processor : Pentium IV 2.4 GHz
Hard Disk : 80 GB
RAM : 512 MB
4.2 SOFTWARE REQUIREMENTS
Operating System : Windows XP and above
Front End : J2EE
Back End : MySQL
Java is a new computer programming language developed by Sun Microsystems. Java has a good chance to be the first really successful new computer language in several decades. Advanced programmers like it because it has a clean, well-designed definition. Business likes it because it dominates an important new application, Web programming.
Java has several important features:
A Java program runs exactly the same way on all computers. Most other languages allow small differences in interpretation of the standards.
It is not just the source that is portable. A Java program is a stream of bytes that can be run on any machine. An interpreter program is built into Web browsers, though it can run separately. Java programs can be distributed through the Web to any client computer.
Java applets are safe. The interpreter program does not allow Java code loaded from the network to access local disk files, other machines on the local network, or local databases. The code can display information on the screen and communicate back to the server from which it was loaded.
A group at Sun reluctantly invented Java when they decided that existing computer languages could not solve the problem of distributing applications over the network. C++ inherited many unsafe practices from the old C language. Basic was too static and constrained to support the development of large applications and libraries. Today, every major vendor supports Java. Netscape incorporates Java support in every version of its Browser and Server products. Oracle will support Java on the Client, the Web Server, and the Database Server. IBM looks to Java to solve the problems caused by its heterogeneous product line.
The Java programming language and environment is designed to solve a number of problems in modern programming practice. It has many interesting features that make it an ideal language for software development. It is a high-level language that can be characterized by all of the following buzzwords:
Sun describes Java as
Java is simple.
What it means by simple is being small and familiar. Sun designed Java as closely to C++ as possible in order to make the system more comprehensible, but removed many rarely used, poorly understood, confusing features of C++. These primarily include operator overloading, multiple inheritance, and extensive automatic coercions. The most important simplification is that Java does not use pointers and implements automatic garbage collection so that we don't need to worry about dangling pointers, invalid pointer references, and memory leaks and memory management.
Java is object-oriented.
This means that the programmer can focus on the data in his application and the interface to it. In Java, everything must be done via method invocation for a Java object. We must view our whole application as an object; an object of a particular class.
Java is distributed.
Java is designed to support applications on networks. Java supports various levels of network connectivity through classes in java. net. For instance, the URL class provides a very simple interface to networking. If we want more control over the downloading data than is through simpler URL methods, we would use a URLConnection object which is returned by a URL URL.openConnection () method. Also, you can do your own networking with the Socket and ServerSocket classes.
Java is robust.
Java is designed for writing highly reliable or robust software. Java puts a lot of emphasis on early checking for possible problems, later dynamic (runtime) checking, and eliminating situations that are error prone. The removal of pointers eliminates the possibility of overwriting memory and corrupting data.
Java is secure.
Java is intended to be used in networked environments. Toward that end, Java implements several security mechanisms to protect us against malicious code that might try to invade your file system. Java provides a firewall between a networked application and our computer.
Java is architecture-neutral.
Java program are compiled to an architecture neutral byte-code format. The primary advantage of this approach is that it allows a Java application to run on any system that implements the Java Virtual Machine. This is useful not only for the networks but also for single system software distribution. With the multiple flavors of Windows 95 and Windows NT on the PC, and the new PowerPC Macintosh, it is becoming increasing difficult to produce software that runs on all platforms.
Java is portable.
The portability actually comes from architecture-neutrality. But Java goes even further by explicitly specifying the size of each of the primitive data types to eliminate implementation-dependence. The Java system itself is quite portable. The Java compiler is written in Java, while the Java run-time system is written in ANSI C with a clean portability boundary.
Java is interpreted.
The Java compiler generates byte-codes. The Java interpreter executes the translated bytecodes directly on system that implements the Java Virtual Machine. Java's linking phase is only a process of loading classes into the environment.
Java is high-performance.
Compared to those high-level, fully interpreted scripting languages, Java is high-performance. If the just-in-time compilers are used, Sun claims that the performance of byte-codes converted to machine code are nearly as good as native C or C++. Java, however, was designed to perform well on very low-power CPUs.
Java is multithreaded.
Java provides support for multiple threads of execution that can handle different tasks with a Thread class in the java.lang Package. The thread class supports methods to start a thread, run a thread, stop a thread, and check on the status of a thread. This makes programming in Java with threads much easier than programming in the conventional single-threaded C and C++ style.
Java is dynamic.
Java language was designed to adapt to an evolving environment. It is a more dynamic language than C or C++. Java loads in classes, as they are needed, even from across a network. This makes an upgrade to software much easier and effectively. With the compiler, first we translate a program into an intermediate language called Java byte codes ---the platform-independent codes interpreted by the interpreted on the Java platform. The interpreter parses and runs each Java byte code instruction on the computer. Compilation happen s just once; interpretation occurs each time the program is executed.
Java byte codes can be thought as the machine code instructions for the Java Virtual Machine (JVM). Every Java interpreter, whether it's a development tool or a web browser that can run applets, is an implementation of the Java Virtual Machine.
The Java Platform
A platform is the hardware or software environment in which a program runs. Most Platforms can be described as a combination of the operating system and hardware. The Java platform differs from most other platforms in that it's software -only platform that runs on top of other hardware-based platforms.
The Java platform has two components:
The Java Virtual Machine (JVM).
The Java Application Programming Interfaces (Java API).
The JVM has been explained above. It's the base for the Java platform and is ported onto various hardware-based platforms.
The Java API is a large collection of ready-made software components that provide many useful capabilities, such as graphical user interface (GUI). The Java API is grouped into libraries of related classes and interfaces; these libraries are known as packages.
Native code is code that after you compile it, the compiled code runs on a specific hardware platform. As a platform-independent environment, the Java platform can be bit slower than native code. However, smart compilers, well-tuned interpreters, and just-in-time byte code compilers can bring performance close to that of native code without threatening portability.
Overview of the Swing
The Swing package is part of Java Foundation Classes (JFC) in the Java platform. The JFC encompasses a group of features to help people build GUIs; Swing provides all the components from buttons to split panes and tables.
The Swing package was first available as an add-on to JDK 1.1. Prior to the introduction of the Swing package, the Abstract Window Toolkit (AWT) components provided all the UI components in the JDK1.0 and 1.1 platforms. Although the Java2 Platform still supports the AWT components, we strongly encourage using Swing components instead. You can identify Swing components because their names start with J. The AWT button class, for example, is named Button, whereas the Swing button class is named JButton. In addition, the AWT components are in the java.awt package, whereas the swing components are in the javax.swing package.
As a rule, programs should not use "heavyweight" AWT components alongside Swing components. Heavyweight components include all the ready-to-use AWT components, such as Menu and Scroll Pane, and all components that inherit from the AWT canvas and Panel classes. When Swing components (and all other "lightweight" components) overlap with heavyweight components, the heavyweight component is always painted on top.
Swing Features and Concepts:
It introduces Swing's features and explains all the concepts we need to be able to use Swing components effectively.
Swing Components and the Containment Hierarchy:
Swing provides many standard GUI components such as buttons, lists, menus and text areas, which we combine to create our program's GUI. It also includes containers such as windows and tool bars.
Containers use layout managers to determine the size and position of the components they contain. Borders affect the layout of Swing GUIs by making Swing components larger. We can also use invisible components to affect layout.
Event handling is how programs respond to external events, such as the user pressing a mouse button. Swing programs perform all their painting and event handling in the event-dispatching thread.
Painting means drawing the components on-screen. Although it's easy to customize a component's painting, most programs don't do anything more complicated than customizing a component's border.
Threads and Swing:
If we do something to a visible component that might depend on or affect its state, then we need to do it from the event-dispatching thread. This isn't an issue for many simple programs, which generally refer to components only in event -handling code. However, other programs need to use they invoke Later method to execute component-related calls in the event-dispatching thread.
MySQL, the most popular Open Source SQL database management system, is developed, distributed, and supported by Oracle Corporation.
The MySQL Web site (http://www.mysql.com/) provides the latest information about MySQL software.
MySQL is a database management system.
A database is a structured collection of data. It may be anything from a simple shopping list to a picture gallery or the vast amounts of information in a corporate network. To add, access, and process data stored in a computer database, you need a database management system such as MySQL Server. Since computers are very good at handling large amounts of data, database management systems play a central role in computing, as standalone utilities, or as parts of other applications.
MySQL is a relational database management system.
A relational database stores data in separate tables rather than putting all the data in one big storeroom. This adds speed and flexibility. The SQL part of "MySQL" stands for "Structured Query Language." SQL is the most common standardized language used to access databases and is defined by the ANSI/ISO SQL Standard. The SQL standard has been evolving since 1986 and several versions exist. In this manual, "SQL-92" refers to the standard released in 1992, "SQL:1999" refers to the standard released in 1999, and "SQL:2003" refers to the current version of the standard. We use the phrase "the SQL standard" to mean the current version of the SQL Standard at any time.
MySQL software is Open Source.
Open Source means that it is possible for anyone to use and modify the software. Anybody can download the MySQL software from the Internet and use it without paying anything. If you wish, you may study the source code and change it to suit your needs. The MySQL software uses the GPL (GNU General Public License), to define what you may and may not do with the software in different situations. If you feel uncomfortable with the GPL or need to embed MySQL code into a commercial application, you can buy a commercially licensed version from us. See the MySQL Licensing Overview for more information (http://www.mysql.com/company/legal/licensing/).
The MySQL Database Server is very fast, reliable, and easy to use.
MySQL Server was originally developed to handle large databases much faster than existing solutions and has been successfully used in highly demanding production environments for several years. Although under constant development, MySQL Server today offers a rich and useful set of functions. Its connectivity, speed, and security make MySQL Server highly suited for accessing databases on the Internet.
MySQL Server works in client/server or embedded systems.
The MySQL Database Software is a client/server system that consists of a multi-threaded SQL server that supports different backends, several different client programs and libraries, administrative tools, and a wide range of application programming interfaces (APIs).
We also provide MySQL Server as an embedded multi-threaded library that you can link into your application to get a smaller, faster, easier-to-manage standalone product.
A large amount of contributed MySQL software is available.
It is very likely that your favorite application or language supports the MySQL Database Server.
The official way to pronounce "MySQL" is "My Ess Que Ell" (not "my sequel"), but we do not mind if you pronounce it as "my sequel" or in some other localized way
5.2.1 FEATURES OF MYSQL:
This section describes some of the important characteristics of the MySQL Database Software. See also SectionÂ 1.4, "MySQL Development History". In most respects, the roadmap applies to all versions of MySQL. For information about features as they are introduced into MySQL on a series-specific basis, see the "In a Nutshell" section of the appropriate Manual:
MySQL 5.0: MySQL 5.0 in a Nutshell
MySQL 5.1: MySQL 5.1 in a Nutshell
MySQL 5.5: MySQL 5.5 in a Nutshell
5.2.2 INTERNALS AND PORTABILITY:
Written in C and C++.
Tested with a broad range of different compilers.
Works on many different platforms. See SectionÂ 2.1.1, "Operating Systems On Which MySQL Is Known To Run".
For portability, uses CMake in MySQL 5.5 and up. Previous series use GNU Automake, Autoconf, and Libtool.
Tested with Purify (a commercial memory leakage detector) as well as with Valgrind, a GPL tool (http://developer.kde.org/~sewardj/).
Uses multi-layered server design with independent modules.
Designed to be fully multi-threaded using kernel threads, to easily use multiple CPUs if they are available.
Provides transactional and no transactional storage engines.
Uses very fast B-tree disk tables (MyISAM) with index compression.
Designed to make it relatively easy to add other storage engines. This is useful if you want to provide an SQL interface for an in-house database.
Uses a very fast thread-based memory allocation system.
Executes very fast joins using an optimized nested-loop join.
Implements in-memory hash tables, which are used as temporary tables.
Implements SQL functions using a highly optimized class library that should be as fast as possible. Usually there is no memory allocation at all after query initialization.
Provides the server as a separate program for use in a client/server networked environment, and as a library that can be embedded (linked) into standalone applications. Such applications can be used in isolation or in environments where no network is available.
5.2.3 DATA TYPES:
Many data types: signed/unsigned integers 1, 2, 3, 4, and 8 bytes long, FLOAT, DOUBLE, CHAR, VARCHAR, BINARY, VARBINARY, TEXT, BLOB, DATE, TIME, DATETIME, TIMESTAMP, YEAR, SET, ENUM, and OpenGIS spatial types. See ChapterÂ 10, Data Types.
Fixed-length and variable-length string types.
5.2.4 STATEMENTS AND FUNCTIONS:
Support for LEFT OUTER JOIN and RIGHT OUTER JOIN with both standard SQL and ODBC syntax.
Support for aliases on tables and columns as required by standard SQL.
Support for DELETE, INSERT, REPLACE, and UPDATE to return the number of rows that were changed (affected), or to return the number of rows matched instead by setting a flag when connecting to the server.
Support for MySQL-specific SHOW statements that retrieve information about databases, storage engines, tables, and indexes. MySQL 5.0 adds support for the INFORMATION_SCHEMA database, implemented according to standard SQL.
An EXPLAIN statement to show how the optimizer resolves a query.
Independence of function names from table or column names. For example, ABS is a valid column name. The only restriction is that for a function call, no spaces are permitted between the function name and the "(" that follows it. See SectionÂ 8.3, "Reserved Words".
You can refer to tables from different databases in the same statement.
A privilege and password system that is very flexible and secure, and that enables host-based verification.
Password security by encryption of all password traffic when you connect to a server.
5.2.6 SCALABILITY AND LIMITS:
Support for large databases. We use MySQL Server with databases that contain 50 million records. We also know of users who use MySQL Server with 200,000 tables and about 5,000,000,000 rows.
Support for up to 64 indexes per table (32 before MySQL 4.1.2). Each index may consist of 1 to 16 columns or parts of columns. The maximum index width is 1000 bytes (767 for Inno DB); before MySQL 4.1.2, the limit is 500 bytes. An index may use a prefix of a column for CHAR, VARCHAR, BLOB, or TEXT column types.