|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| News | Internet Protocol | Recommended Links | Recommended Papers | Reference | Network Utilities |
| Smurf attack | SYN Flooding | Packet generation tools | Traceroute | Humor | Etc |
|
|
In denial of service attacks prevent legitimate users from using the network or particular attacked server by consuming resources that make serving of legitimate requests slow or simply impossible. They can also crash the OS or application. The three common types are:
You can use a network monitor to reveal the type, and sometimes the origin, of overload attacks. If you have a list of machines and the low-level network address (i.e., Ethernet board-level address, not IP address) this may help you track the source of the problem if it is local to your network. Isolating your local subnet or network while finding the problem may also help. If you have logging on your firewall or router, you can quickly determine if the attack is coming from outside your network or inside - you cannot depend on the IP address in the packet being correct.
Unfortunately, there is little that you, as an end user or administrator, can do to help make the protocols and daemons more robust in the face of such attacks. The best you can hope to do, at present, is to limit their effect. Partitioning your local network into subnets of only a few dozen machines each is one good approach. That way, if one subnet gets flooded as part of an attack or accident, not all of your machines are disabled.
Another action you can take is to install IDS on the network (for example snort).
One partial help is if the service being attacked is spawned from the inetd with the nowait
option. inetd, by default, has a "throttle" built in. If too many requests are received in too short a time for any of the services
it monitors, it will start rejecting requests and syslog a message that the service is failing. This is done under the assumption
that some bug has been triggered to cause all the traffic. This has the side-effect of disabling your service as surely as if all
the requests were accepted for processing. However, it may prevent the server itself from failing, and it results in an audit record
showing when the problem occurred.
A server that is being flooded may not be able to respond to network requests in a timely manner. An attacker can take advantage of this behavior by writing a program that answers network requests in the server's place. For example, an attacker could flood an NIS server and then issue his own replies for NIS requests - specifically, requests for passwords.
Suppose an attacker writes a program that literally bombards an NIS server machine with thousands of echo requests every second directed to the echo service. The attacker simultaneously attempts to log into a privileged account on a workstation. The workstation would request the NIS passwd information from the real server, which would be unable to respond quickly because of the flood. The attacker's machine could then respond, masquerading as the server, and supply bogus information, such as a record with no password. Under normal circumstances, the real server would notice this false packet and repudiate it. However, if the server machine is so loaded that it never receives the packet, or fails to receive it in a timely fashion, it cannot respond. The client workstation would believe the false response to be correct and process the attacker's login attempt with the false passwd entry.
A similar type of attack is a broadcast storm. By careful crafting of network messages, you can create a special message that instructs every computer receiving the message to reply or retransmit it. The result is that the network becomes saturated and unusable. Broadcast storms rarely result from intentional attack; more often, they result from failing hardware or from software that is under development, buggy, or improperly installed.
Broadcasting incorrectly formatted messages can also bring a network of machines to a grinding halt. If each machine is configured to log the reception of bad messages to disk or console, they could broadcast so many messages that the clients can do nothing but process the errors and log them to disk or console.
Again, preparing ahead with a monitor and breaking your network into subnets will help you prevent and deal with this kind of
problem, although such planning will not eliminate the problem completely.
By analogy, consider what happens when your phone rings. You answer and say "hello" but no one responds. You wait a few seconds, then say "hello" again. You may do this one or two more times until you "time out" and hang up. However, during the time you are waiting for someone to answer your "hello" (and there may be no one there), the phone line is tied up and can process no other incoming calls.
There is little you can do in these situations. Modifications to the operating system sources could result in a tunable time-out, better logging of these problems, and a higher limit on the number of half-open connections allowed before new requests are rejected. However, these modifications are not simple to make.
Firewalls generally do not address this problem either. The best you can achieve is to reject connection attempts from unknown hosts and networks at the firewall. The only other alternative is to rethink the protocols involved, and perhaps set much higher limits on the existing implementations. However, any finite limit can be exceeded. Networks based on
From wikipedia:
|
|
A denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack) is an attempt to make a computer resource unavailable to its intended users. Although the means to, motives for, and targets of a DoS attack may vary, it generally consists of the concerted, malevolent efforts of a person or persons to prevent an Internet site or service from functioning efficiently or at all, temporarily or indefinitely.
Perpetrators of DoS attacks typically target sites or services hosted on high-profile web servers such as banks, credit card payment gateways, and even DNS root servers.
One common method of attack involves saturating the target (victim) machine with external communications requests, such that it cannot respond to legitimate traffic, or responds so slowly as to be rendered effectively unavailable. In general terms, DoS attacks are implemented by:
- forcing the targeted computer(s) to reset, or consume its resources so that it can no longer provide its intended service; or,
- obstructing the communication media between the intended users and the victim so that they can no longer communicate adequately.
Denial-of-service attacks are considered violations of the IAB's Internet proper use policy. They also commonly constitute violations of the laws of individual nations.
virtual circuits may provide a solution by bypassing the protocol problems completely.
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
... Network-based (D)DoS attacks boil down to a lot of unwanted traffic coming in, which uses up either the available bandwidth, CPU time, memory, or some combination of these. The idea is to filter out this unwanted traffic. This has to happen as close to the source as possible, since the available bandwidth typically goes down as the traffic gets closer to the destination. Filtering out traffic that has already succeeded in completely filling up the link to an ISP isn't extremely useful. This means in practical terms that the ISP has to configure a filter when a customer is under attack.
Filtering Possibilities
How do we filter? We filter either on the source address, on the service, or on the destination address. Filtering on the source address is the preferred way to get rid of unwanted traffic: it catches only traffic from the attacker. Unfortunately this approach can't be used very often. Attackers usually falsify or spoof the source address in attacking traffic, with the result that the attack seems to come from many different hosts throughout the net. Even when the source addresses are real, in a distributed attack there may be so many of them that it's impractical to configure a filter for all of them.
If you're lucky you may encounter an attacker who uses a single, inessential service for all attacking packets. For example, some early DDoS tools used a single UDP port for all attacking traffic. Smurf directed broadcast attacks by their nature only create ICMP echo reply packets. In these cases the attacking traffic can easily be filtered out by filtering a UDP or TCP port or by ICMP type. If the attack uses unpredictable ports or ports that can't be filtered because they are used for important services, it's not possible to filter on service type.
As a last resort, it's possible to filter out all traffic to the host or hosts under attack in order to protect the rest of the network. This is usually possible because most attacks are directed at a small number of hosts. If the attack is directed at the entire network, filtering on destination address isn't possible.
Installing the right type of filter will get rid of most attacks. Unfortunately this has to be done at a transit ISP, at least one hop closer to the core of the Internet, so the attacking traffic doesn't overload the customer connection. This is very inconvenient because it requires an ISP engineer to install the filter, which often takes a long time. I propose incorporating mechanisms so customers can do this themselves in the ISP network.
Destination Address Filtering
Let's start with filtering on destination address, which is the easiest to create. An ISP can give a customer the necessary tools to do this by creating a BGP community that routes traffic for the advertised address range to the null interface. The customer then announces
/32routes with this black hole community set, in addition to the regular address block announcements. All traffic for these/32s is then sent to the null interface. A/32is BGP-speak for a single IP address, and communities are labels which indicate that special treatment of some kind is desired. In this case, the special treatment is to throw away all traffic that has this IP address as its destination. An admittedly Cisoc-centric route map to accomplish this might look something like the following:! ip community-list 13 permit 65000:13 ! route-map customer-in permit 10 match community 13 set ip next-hop 13.13.13.13 !This route map will set the next hop address for all routes with the community
65000:13attached to it to13.13.13.13. (A community takes the shape of a 32 bit value written as two values separated by a colon, where the first value is often the Autonomous System number of the network that will act on the community.) This route map must be applied to the customer BGP session. This makes the router check for the community in all routing updates received from the customer and change the destination of the packets that match the route to the special13.13.13.13address. Then, on all routers in the network, the13.13.13.13address must be routed to the null interface and the packets will end up being discarded:! ip route 13.13.13.13 255.255.255.255 Null0 !In the real world you would use an address out of your own address block rather than the
13.13.13.13address.When this setup is in effect, all traffic directed to a black-holed address is immediately thrown away as soon as it enters the network. Unlike regular anti-DoS filters that are applied to customer interfaces, traffic is first transported through the ISP network to the router connecting the customer, only to be thrown out there. The main advantage is the customer can initiate filtering at any time without any need for cooperation from the ISP. (Obviously, customers shouldn't be allowed to announce addresses that aren't theirs with this black hole community, or they could black hole addresses belonging to others. Regular filters on customer BGP sessions should take care of this.)
Source Address Filtering with Unicast RPF
Since routing looks at the destination addresses, filtering on those is pretty simple. But, if we employ Cisco's unicast reverse path forwarding (uRPF) check, filtering on source addresses isn't that hard either. uRPF takes the source address of incoming packets and checks in the CEF table, a copy of the routing table used for high-speed packet forwarding, whether the interface the packet arrived on is the next hop interface for the source address. Packets that arrive on an interface the router wouldn't use to reach the source address are considered falsified and are dropped. This works very well for interfaces that connect to well-defined networks. It can also work for peers (over private connections or over an Internet exchange) but uRPF isn't very useful on links to ISPs that sell you transit service; they are supposed to deliver packets from all possible sources connected to the net. And uRPF can't be used with two ISPs: packets with a certain source address can come in over either ISP, while the router only considers one of them the valid source of these packets.
By enabling the uRPF feature and using the same community as in the previous example, we can now filter on source address:
! interface Serial0 ip verify unicast reverse-path !The community makes sure the address is routed to the null interface, and packets with the indicated source address are only allowed if they are received from the null interface. (Actually the uRPF feature has a special check for "null adjacencies", which are immediately dropped.) Since attacking traffic tends to come in over other interfaces, this should work very well as long as uRPF is enabled. There is also a "loose" uRPF that doesn't check where the packet came from; instead, it checks whether the source address is in the routing table. My router doesn't support this and I can't find the right command, so I'll leave implementing it as an exercise for the reader. This type of uRPF can be enabled for all interfaces because it doesn't break asymmetric routing (the problem with two ISPs), which makes it very useful here.
Unfortunately this kind of filtering on the source address can't be used in practice, since customers would be allowed to blac khole source addresses arbitrarily in an ISP network. This is way too dangerous to allow.
Using a Filter Box
So now we arrive at the solution I'm advocating: having a separate filter box in the network:
inet | +---+------+ +----------+ | ISP +--------+ Filter | | router 1 | | box | +--------+-+ +-+--------+ \ / \ / +-+------+-+ | ISP | | router 2 | +----+-----+ | | +----+-----+ | Customer | | router | +----------+Whenever a customer's address is under attack, the customer announces this address with a community similar to the one in the first example. Rather than changing the next hop address to an unreachable address, the next hop address is set to that of the filter box. All traffic to hosts under attack is routed through the filter box.
Any traffic surviving the filtering process is sent on its way to the customer. Essentially, the filter box cleanses traffic.
Advantages
- no NOC actions necessary
- no performance penalty on the production network
- no special hardware or protocols necessary
- customer has complete control
- customer can't mess with the production network
- customer can't mess with other customer's view of the attacking source addresses (well, only for boxes from other customers also under attack)
Disadvantages
- doesn't work with full scale source address spoofing
- extra hardware necessary
Since different routers in the ISP network need different views of the next hop address for the addresses under attack, (ISP router 1 needs to send traffic to the filter box, ISP router 2 to the customer) there should probably be route maps configured on iBGP sessions. This isn't particularly elegant, but I see no reason why it couldn't be done. If this is a problem, the traffic can be sent from the filter box to the customer over a tunnel.
On the filter box it shouldn't be a problem to use the BGP black holing + uRPF trick described above to filter on source addresses. Customers would have an extra BGP session to the filter box so they can tell it which source addresses to filter out. Since only traffic under attack is being rerouted over the filter box, this essentially creates a filter on the source/destination combinations. It is entirely possible to create the filters on the filter box in a different way. The filter box could be a host-based router on which filters can be set and removed using a web interface.
Stateful Firewalling
If it proves impossible to get rid of spoofed source addresses, there is a last resort -- stateful firewalling. The filter box would then monitor all (TCP) sessions and only allow traffic that belongs to a valid session or an IP address partaking in a valid session. Since it is nearly impossible to complete the TCP three-way handshake with a falsified source address, this will get rid of all excess traffic except TCP SYNs, and these can be rate limited to a level the host under attack can handle.
This solution won't be easy to implement; it will be hard to get the outgoing traffic that matches the incoming traffic that must be filtered flowing through the same box, which is necessary to do the stateful filtering. This problem could be solved by having different stateful firewalls work together. A customer firewall could monitor the outgoing traffic and instruct the ISP "filter box" firewall to allow traffic as soon as there is a valid three-way handshake.
(If you're interested in testing this approach, email me at [email protected] .)
Iljitsch van Beijnum has been working with BGP in ISP and end-user networks since 1996.
|
|
|
The following recommendations should be regarded as a guideline for improving protection against distributed Denial-of-Service (DoS) attacks. At the same time, it serves as a basis of discussion for concrete realisation of measures in the areas server operator, network agents, content providers and end-users. The reason is the observance in February of intensified DoS attacks on renowned Internet providers.Here, the attackers had created access to hundreds of computers in the Internet on which they installed the programs for the DoS attacks. From a separate computer, they synchronised these attack programs in such a manner that the effectiveness of the attack was appreciably increased through the large number of simultaneously attacking computers. This type of attack is designated as Distributed Denial-of-Service (DDoS).
The observed attacks were based on two main weak points. Firstly, the sender addresses of the "attacking" data packet had been forged (IP spoofing), and secondly, unauthorised programs were installed - before the attacks on selected large computers on a large number of further, inadequately protected Internet computers which, remote-controlled, were able to send data packets en masse. The particular feature of these DDoS attacks is that they were able for this reason to hit those who have otherwise protected themselves in an optimum manner against intruders from the Internet (for the recognition and treatment of attacks cf. appendix or http://www.bsi.de/literat/cebit99/angriff.htm). This means that computers on which not even the so-called basic protection measures have been implemented, are not only a danger for the operator concerned, but also for all other computers in the Internet. For this reason, the preparations for the attacks which became known recently were only possible through the fact that various safety "holes" which had been known for a long period had not been eliminated.
Effective measures against distributed Denial-of-Service Attacks must be taken at many points in the existing complex Internet structure in a concerted campaign. Server operators in the Internet which were the object of the stated attacks can resort to a number of meaningful measures without solving the DoS problem completely. Rather, different target groups (content providers, server providers, network agents and end-users) - each in his own sector - must act. Only jointly can the Internet be made safer with respect to the endangerment through DoS attacks, the execution of Denial-of-Service Attacks made more difficult and subsequent pursuit of the originators of these attacks alleviated.
By means of the recommendations for measures stated below, the following target groups are supported in their task of protecting the Internet against DoS attacks:
- End-users: operators of private and work computers which serve for retrieving information in the Internet, processing it and returning it to the network.
- Network agents: operators of the network infrastructure (e.g. network node computers, routers)
- Server operators: companies entrusted with the administration and configuration of servers. The servers offer services and information in the Internet ( WWW servers, DNS servers, MTAs, proxy servers ...).
- Content providers: producers of editorial content which, for example, are provided by server operators on the WWW servers.
|
|
|
Defending against distributed denial-of-service attacks with max-min fair server-centric router throttles
Yau, D.K.Y.; Lui, J.C.S.; Feng Liang; Yeung Yam
Networking, IEEE/ACM Transactions on
Volume 13, Issue 1, Feb. 2005 Page(s): 29 - 42
Digital Object Identifier 10.1109/TNET.2004.842221
Summary: Our work targets a network architecture and accompanying algorithms for countering distributed denial-of-service (DDoS) attacks directed at an Internet server. The basic mechanism is for a server under stress to install a router throttle at selected upstream routers. The throttle can be the leaky-bucket rate at which a router can forward packets destined for the server. Hence, before aggressive packets can converge to overwhelm the server, participating routers proactively regulate the contributing packet rates to more moderate levels, thus forestalling an impending attack. In allocating the server capacity among the routers, we propose a notion of level-k max-min fairness. We first present a control-theoretic model to evaluate algorithm convergence under a variety of system parameters. In addition, we present packet network simulation results using a realistic global network topology, and various models of good user and attacker distributions and behavior. Using a generator model of web requests parameterized by empirical data, we also evaluate the impact of throttling in protecting user access to a web server. First, for aggressive attackers, the throttle mechanism is highly effective in preferentially dropping attacker traffic over good user traffic. In particular, level-k max-min fairness gives better good-user protection than recursive pushback of max-min fair rate limits proposed in the literature. Second, throttling can regulate the experienced server load to below its design limit - in the presence of user dynamics - so that the server can remain operational during a DDoS attack. Lastly, we present implementation results of our prototype on a Pentium III/866 MHz machine. The results show that router throttling has low deployment overhead in time and memory.
Google matched content |
SANS Resources - Help Defeat Denial of Service Attacks Step-by-Step
CNET.com - News - E-commerce - German programmer talks about Web attacks
Cisco - Improving Security on Cisco Routers
http://www.cisco.com/warp/public/707/newsflash.html
http://www.cisco.com/warp/public/707/21.html
http://www.cisco.com/warp/public/707/22.html
Understanding The Smurf Attack Is Key To Fending It Off -IW January 18, 1999
smurf - Webopedia Definition and Links
A type of network security breach in which a network connected to the Internet is swamped with replies to ICMP echo (PING) requests. A smurf attacker sends PING requests to an Internet broadcast address. These are special addresses that broadcast all received messages to the hosts connected to the subnet. Each broadcast address can support up to 255 hosts, so a single PING request can be multiplied 255 times. The return address of the request itself is spoofed to be the address of the attacker's victim. All the hosts receiving the PING request reply to this victim's address instead of the real sender's address. A single attacker sending hundreds or thousands of these PING messages per second can fill the victim's T-1 (or even T-3) line with ping replies, bring the entire Internet service to its knees.
Overview This article provides provides in-depth information for Cisco routers
ROUTER SOFTWARE UPDATE - TRAFFIC SHAPINGCISCO ARCHITECTURE BACKGROUNDWHAT IS CA
DoS attack - Webopedia Definition and Links
IP spoofing - Webopedia Definition and Links
PING - Webopedia Definition and Links
Pearson - Internet Denial of Service Attack and Defense Mechanisms
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March, 12, 2019
