Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Special pages
Niidae Wiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Denial-of-service attack
(section)
Page
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Defense techniques== {{Main|DDoS mitigation}} Defensive responses to denial-of-service attacks typically involve the use of a combination of attack detection, traffic classification and response tools, aiming to block traffic the tools identify as illegitimate and allow traffic that they identify as legitimate.<ref>{{Cite journal | last1 = Loukas | first1 = G. | last2 = Oke | first2 = G. | doi = 10.1093/comjnl/bxp078 | title = Protection Against Denial of Service Attacks: A Survey | journal = [[The Computer Journal|Comput. J.]] | volume = 53 | issue = 7 | pages = 1020β1037 | date = September 2010| url = http://staffweb.cms.gre.ac.uk/~lg47/publications/LoukasOke-DoSSurveyComputerJournal.pdf | access-date = 2015-12-02 | archive-url = https://web.archive.org/web/20120324115835/http://staffweb.cms.gre.ac.uk/~lg47/publications/LoukasOke-DoSSurveyComputerJournal.pdf | archive-date = 2012-03-24 | url-status = dead }}</ref> A list of response tools include the following. ===Upstream filtering=== All traffic destined to the victim is diverted to pass through a ''cleaning center'' or a ''scrubbing center'' via various methods such as: changing the victim IP address in the DNS system, tunneling methods (GRE/VRF, MPLS, SDN),<ref>{{cite web |url=https://archive.nanog.org/meetings/nanog23/presentations/afek.ppt |title=MPLS-Based Synchronous Traffic Shunt (NANOG28) |work=Riverhead Networks, Cisco, Colt Telecom |publisher=NANOG28 |date=2003-01-03 |archive-url=https://web.archive.org/web/20210515102444/https://archive.nanog.org/meetings/nanog23/presentations/afek.ppt |archive-date=2021-05-15 |access-date=2003-01-10 |url-status=dead }}</ref> proxies, digital cross connects, or even direct circuits. The cleaning center separates ''bad'' traffic (DDoS and also other common internet attacks) and only passes good legitimate traffic to the victim server.<ref>{{cite web |url=https://archive.nanog.org/meetings/nanog23/presentations/afek.ppt |title=Diversion and Sieving Techniques to Defeat DDoS attacks |work=Cisco, Riverhead Networks |publisher=NANOG23 |date=2001-10-23 |archive-url=https://web.archive.org/web/20210515102444/https://archive.nanog.org/meetings/nanog23/presentations/afek.ppt |archive-date=2021-05-15 |access-date=2001-10-30 |url-status=dead }}</ref> The victim needs central connectivity to the Internet to use this kind of service unless they happen to be located within the same facility as the cleaning center. DDoS attacks can overwhelm any type of hardware firewall, and passing malicious traffic through large and mature networks becomes more and more effective and economically sustainable against DDoS.<ref>{{cite web|url=https://research.sprintlabs.com/publications/uploads/RR04-ATL-013177.pdf |title=DDoS Mitigation via Regional Cleaning Centers (Jan 2004) |work=SprintLabs.com |publisher=Sprint ATL Research |archive-url=https://web.archive.org/web/20080921012859/http://research.sprintlabs.com/publications/uploads/RR04-ATL-013177.pdf |archive-date=2008-09-21 |access-date=2011-12-02 |url-status=dead}}</ref> ===Application front end hardware=== Application front-end hardware is intelligent hardware placed on the network before traffic reaches the servers. It can be used on networks in conjunction with routers and [[Network switch|switches]] and as part of [[bandwidth management]]. Application front-end hardware analyzes data packets as they enter the network, and identifies and drops dangerous or suspicious flows. ===Application level key completion indicators=== Approaches to detection of DDoS attacks against cloud-based applications may be based on an application layer analysis, indicating whether incoming bulk traffic is legitimate.<ref>{{cite book |last1=Alqahtani |first1=S. |last2=Gamble |first2=R. F. |title=2015 48th Hawaii International Conference on System Sciences |chapter=DDoS Attacks in Service Clouds |date=1 January 2015 |pages=5331β5340 |doi=10.1109/HICSS.2015.627 |isbn=978-1-4799-7367-5 |s2cid=32238160}}</ref> These approaches mainly rely on an identified path of value inside the application and monitor the progress of requests on this path, through markers called ''key completion indicators''.<ref>{{cite news|last=Kousiouris|first=George|title=KEY COMPLETION INDICATORS:minimizing the effect of DoS attacks on elastic Cloud-based applications based on application-level markov chain checkpoints |newspaper=CLOSER Conference|date=2014|pages=622β628 |doi=10.5220/0004963006220628|isbn=978-989-758-019-2 }}</ref> In essence, these techniques are statistical methods of assessing the behavior of incoming requests to detect if something unusual or abnormal is going on. An analogy is to a brick-and-mortar department store where customers spend, on average, a known percentage of their time on different activities such as picking up items and examining them, putting them back, filling a basket, waiting to pay, paying, and leaving. If a mob of customers arrived in the store and spent all their time picking up items and putting them back, but never made any purchases, this could be flagged as unusual behavior. ===Blackholing and sinkholing=== With [[blackhole routing]], all the traffic to the attacked DNS or IP address is sent to a ''black hole'' (null interface or a non-existent server). To be more efficient and avoid affecting network connectivity, it can be managed by the ISP.<ref>{{cite journal |last1=Patrikakis |first1=C. |last2=Masikos |first2=M. |last3=Zouraraki |first3=O. |title=Distributed Denial of Service Attacks |journal=The Internet Protocol Journal |volume=7 |issue=4 |pages=13β35 |date=December 2004 |url=http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-4/dos_attacks.html |access-date=2010-01-13 |archive-date=2015-12-27 |archive-url=https://web.archive.org/web/20151227060036/http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-4/dos_attacks.html |url-status=dead }}</ref> A [[DNS sinkhole]] routes traffic to a valid IP address which analyzes traffic and rejects bad packets. Sinkholing may not be efficient for severe attacks. ===IPS based prevention=== [[Intrusion prevention system]]s (IPS) are effective if the attacks have signatures associated with them. However, the trend among attacks is to have legitimate content but bad intent. Intrusion-prevention systems that work on content recognition cannot block behavior-based DoS attacks.<ref name=":0" /> An [[Application-specific integrated circuit|ASIC]] based IPS may detect and block denial-of-service attacks because they have the [[Bandwidth (computing)|processing power]] and the granularity to analyze the attacks and act like a [[circuit breaker]] in an automated way.<ref name=":0" /> ===DDS based defense=== More focused on the problem than IPS, a DoS defense system (DDS) can block connection-based DoS attacks and those with legitimate content but bad intent. A DDS can also address both protocol attacks (such as teardrop and ping of death) and rate-based attacks (such as ICMP floods and SYN floods). DDS has a purpose-built system that can easily identify and obstruct denial of service attacks at a greater speed than a software-based system.<ref>{{Cite web|last=Popeskic|first=Valter|title=How to prevent or stop DoS attacks?|date=16 October 2012|url=https://howdoesinternetwork.com/2012/prevent-stop-dos-attacks}}</ref> ===Firewalls=== In the case of a simple attack, a [[Firewall (computing)|firewall]] can be adjusted to deny all incoming traffic from the attackers, based on protocols, ports, or the originating IP addresses. More complex attacks will however be hard to block with simple rules: for example, if there is an ongoing attack on port 80 (web service), it is not possible to drop all incoming traffic on this port because doing so will prevent the server from receiving and serving legitimate traffic.<ref>{{cite web|url=http://www.computerworld.com/s/article/94014/How_to_defend_against_DDoS_attacks|first=Paul|last=Froutan|title=How to defend against DDoS attacks|work=[[Computerworld]]|date=June 24, 2004|access-date=May 15, 2010|archive-date=2 July 2014|archive-url=https://web.archive.org/web/20140702140309/http://www.computerworld.com/s/article/94014/How_to_defend_against_DDoS_attacks|url-status=dead}}</ref> Additionally, firewalls may be too deep in the network hierarchy, with routers being adversely affected before the traffic gets to the firewall. Also, many security tools still do not support IPv6 or may not be configured properly, so the firewalls may be bypassed during the attacks.<ref>{{Cite news|url=https://www.computerweekly.com/news/252445613/Cyber-security-vulnerability-concerns-skyrocket|title=Cyber security vulnerability concerns skyrocket|work=ComputerWeekly.com|access-date=2018-08-13|language=en-GB}}</ref> ===Routers=== Similar to switches, routers have some [[rate limiting|rate-limiting]] and [[access control list|ACL]] capabilities. They, too, are manually set. Most routers can be easily overwhelmed under a DoS attack. Nokia SR-OS using FP4 or FP5 processors offers DDoS protection.<ref>{{cite web |url=https://www.nokia.com/networks/technologies/fp-network-processor-technology/ |title=FP Network Processor Technology |access-date=2024-06-15}}</ref> Nokia SR-OS also uses big data analytics-based Nokia Deepfield Defender for DDoS protection.<ref>[https://www.nokia.com/networks/ip-networks/deepfield/defender/ Nokia Deepfield Defender]</ref> [[Cisco IOS]] has optional features that can reduce the impact of flooding.<ref>{{cite web |url=http://mehmet.suzen.googlepages.com/qos_ios_dos_suzen2005.pdf |title=Some IoS tips for Internet Service (Providers) |first=Mehmet |last=Suzen |archive-url=https://web.archive.org/web/20080910202908/http://mehmet.suzen.googlepages.com/qos_ios_dos_suzen2005.pdf |archive-date=2008-09-10 }}</ref> ===Switches=== Most switches have some rate-limiting and [[access control list|ACL]] capability. Some switches provide automatic or system-wide [[rate limiting]], [[traffic shaping]], [[delayed binding]] ([[TCP splicing]]), [[deep packet inspection]] and [[bogon filtering]] (bogus IP filtering) to detect and remediate DoS attacks through automatic rate filtering and WAN Link failover and balancing. These schemes will work as long as the DoS attacks can be prevented by using them. For example, SYN flood can be prevented using delayed binding or TCP splicing. Similarly, content-based DoS may be prevented using deep packet inspection. Attacks using [[Martian packet]]s can be prevented using bogon filtering. Automatic rate filtering can work as long as set rate thresholds have been set correctly. WAN-link failover will work as long as both links have a DoS prevention mechanism.<ref name=":0" />
Summary:
Please note that all contributions to Niidae Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Encyclopedia:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Search
Search
Editing
Denial-of-service attack
(section)
Add topic