SQL Injection

SQL injection is an attack in which malicious code is inserted into strings that are later passed to an instance of SQL Server for parsing and execution. Any procedure that constructs SQL statements should be reviewed for injection vulnerabilities because SQL Server will execute all syntactically valid queries that it receives. Even parameterized data can be manipulated by a skilled and determined attacker.

How SQL Injection Works

The primary form of SQL injection consists of the direct insertion of code into user-input variables that are concatenated with SQL commands and executed. A less direct attack injects malicious code into strings that are destined for storage in a table or as metadata. When the stored strings are subsequently concatenated into a dynamic SQL command, the malicious code is executed.

The injection process works by prematurely terminating a text string and appending a new command. Because the inserted command may have additional strings appended to it before it is executed, the malefactor terminates the injected string with a comment mark "--". Subsequent text is ignored at execution time.

The following script shows a simple SQL injection. The script builds an SQL query by concatenating hard-coded strings together with a string entered by the user:

C#

var Shipcity; ShipCity = Request.form ("ShipCity"); var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

user is prompted to enter the name of a city. If she enters Redmond, the query assembled by the script looks similar to the following:

SQL

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'

However, assume that the user enters the following

SQL

Redmond'; drop table OrdersTable--

In this case, the following query is assembled by the script:

SQL

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

The semicolon (;) denotes the end of one query and the start of another. The double hyphen (--) indicates that the rest of the current line is a comment and should be ignored. If the modified code is syntactically correct, it will be executed by the server. When SQL Server processes this statement, SQL Server will first select all records  OrdersTable which ShipCity are Redmond. Then, SQL Server will drop OrdersTable.

As long as injected SQL code is syntactically correct, tampering cannot be detected programmatically. Therefore, you must validate all user input and carefully review the code that executes constructed SQL commands in the server that you are using. Coding best practices are described in the following sections on this topic.

Validate All Input

Always validate user input by testing type, length, format, and range. When you are implementing precautions against malicious input, consider the architecture and deployment scenarios of your application. Remember that programs designed to run in a secure environment can be copied to a non-secure environment. The following suggestions should be considered best practices:

1) Make no assumptions about the size, type, or content of the data that is received by your application. For example, you should make the following evaluation:

* How will your application behave if an errant or malicious user enters a 10-megabyte MPEG file where your application expects a postal code?

* How will your application behave in a DROP TABLE the statement is embedded in a text field?

2) Test the size and data type of input and enforce appropriate limits. This can help prevent deliberate buffer overruns.

3) Test the content of string variables and accept only expected values. Reject entries that contain binary data, escape sequences, and comment characters. This can help prevent script injection and can protect against some buffer overrun exploits.

4) When you are working with XML documents, validate all data against its schema as it is entered.

5) Never build Transact-SQL statements directly from user input.

6) Use stored procedures to validate user input.

7) In multitiered environments, all data should be validated before admission to the trusted zone. Data that does not pass the validation process should be rejected and an error should be returned to the previous tier. 

8) Implement multiple layers of validation. Precautions you take against casually malicious users may be ineffective against determined attackers. A better practice is to validate input in the user interface and at all subsequent points where it crosses a trust boundary.

9) For example, data validation in a client-side application can prevent simple script injection. However, if the next tier assumes that its input has already been validated, any malicious user who can bypass a client can have unrestricted access to a system.

10) Never concatenate user input that is not validated. String concatenation is the primary point of entry for script injection. 

11) Do not accept the following strings in fields from which file names can be constructed: AUX, CLOCK$, COM1 through COM8, CON, CONFIG$, LPT1 through LPT8, NUL, and PRN.

When you can, reject input that contains the following characters.

Input character	Meaning in Transact-SQL
;	Query delimiter.
'	Character data string delimiter.
--	Single-line comment delimiter. Text following -- until the end of that line is not evaluated by the server.
/* ... */	Comment delimiters. Text between /* and */ is not evaluated by the server.
xp_	Used at the start of the name of catalog-extended stored procedures, such as xp_cmdshell.

Use Type-Safe SQL Parameters

The Parameters collection in SQL Server provides type checking and length validation. If you use the Parameters collection, input is treated as a literal value instead of as executable code. An additional benefit of using the Parameters collection is that you can enforce type and length checks. Values outside the range will trigger an exception. The following code fragment shows using the Parameters collection:

C#

SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin", conn); myCommand.SelectCommand.CommandType = CommandType.StoredProcedure; SqlParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11); parm.Value = Login.Text;

In this example, the @au_id the parameter is treated as a literal value instead of as executable code. This value is checked for type and length. If the value  @au_id does not comply with the specified type and length constraints, an exception will be thrown.

Use Parameterized Input with Stored Procedures

Stored procedures may be susceptible to SQL injection if they use unfiltered input. For example, the following code is vulnerable:

C#

SqlDataAdapter myCommand = new SqlDataAdapter("LoginStoredProcedure '" + Login.Text + "'", conn);

If you use stored procedures, you should use parameters as their input.

Use the Parameters Collection with Dynamic SQL

If you cannot use stored procedures, you can still use parameters, as shown in the following code example.

C#

SqlDataAdapter myCommand = new SqlDataAdapter( "SELECT au_lname, au_fname FROM Authors WHERE au_id = @au_id", conn); SQLParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id", SqlDbType.VarChar, 11); Parm.Value = Login.Text;

Filtering Input

Filtering input may also be helpful in protecting against SQL injection by removing escape characters. However, because of the large number of characters that may pose problems, this is not a reliable defense. The following example searches for the character string delimiter.

C#

private string SafeSqlLiteral(string inputSQL) { return inputSQL.Replace("'", "''"); }

LIKE Clauses

Note that if you are using a LIKE clause, wildcard characters still must be escaped:

C#

s = s.Replace("[", "[[]"); s = s.Replace("%", "[%]"); s = s.Replace("_", "[_]");

Reviewing Code for SQL Injection

You should review all codes that call EXECUTE, EXEC, or sp_executesql. You can use queries similar to the following to help you identify procedures that contain these statements. This query checks for 1, 2, 3, or 4 spaces after the words EXECUTE or EXEC.

SQL

SELECT object_Name(id) FROM syscomments WHERE UPPER(text) LIKE '%EXECUTE (%' OR UPPER(text) LIKE '%EXECUTE (%' OR UPPER(text) LIKE '%EXECUTE (%' OR UPPER(text) LIKE '%EXECUTE (%' OR UPPER(text) LIKE '%EXEC (%' OR UPPER(text) LIKE '%EXEC (%' OR UPPER(text) LIKE '%EXEC (%' OR UPPER(text) LIKE '%EXEC (%' OR UPPER(text) LIKE '%SP_EXECUTESQL%';

Wrapping Parameters with QUOTENAME() and REPLACE()

In each selected stored procedure, verify that all variables that are used in dynamic Transact-SQL are handled correctly. Data that comes from the input parameters of the stored procedure or that is read from a table should be wrapped in QUOTENAME() or REPLACE(). Remember that the value of @variable that is passed to QUOTENAME() is of sysname, and has a maximum length of 128 characters.

@variable	Recommended wrapper
Name of a securable	QUOTENAME(@variable)
String of ≤128 characters	QUOTENAME(@variable, '''')
String of > 128 characters	REPLACE(@variable,'''', '''''')

When you use this technique, a SET statement can be revised as follows:

SQL

-- Before: SET @temp = N'SELECT * FROM authors WHERE au_lname =''' + @au_lname + N''''; -- After: SET @temp = N'SELECT * FROM authors WHERE au_lname = ''' + REPLACE(@au_lname,'''','''''') + N'''';

Injection Enabled by Data Truncation

Any dynamic Transact-SQL that is assigned to a variable will be truncated if it is larger than the buffer allocated for that variable. An attacker who is able to force statement truncation bypassing unexpectedly long strings to a stored procedure can manipulate the result. For example, the stored procedure that is created by the following script is vulnerable to injection enabled by truncation.

SQL

CREATE PROCEDURE sp_MySetPassword @loginname sysname, @old sysname, @new sysname AS -- Declare variable. -- Note that the buffer here is only 200 characters long. DECLARE @command varchar(200) -- Construct the dynamic Transact-SQL. -- In the following statement, we need a total of 154 characters -- to set the password of 'sa'. -- 26 for UPDATE statement, 16 for WHERE clause, 4 for 'sa', and 2 for -- quotation marks surrounded by QUOTENAME(@loginname): -- 200 - 26 - 16 - 4 - 2 = 154. -- But because @new is declared as a sysname, this variable can only hold -- 128 characters. -- We can overcome this by passing some single quotation marks in @new. SET @command= 'update Users set password=' + QUOTENAME(@new, '''') + ' where username=' + QUOTENAME(@loginname, '''') + ' AND password = ' + QUOTENAME(@old, '''') -- Execute the command. EXEC (@command) GO

By bypassing 154 characters into a 128-character buffer, an attacker can set a new password for a without knowing the old password.

SQL

EXEC sp_MySetPassword 'sa', 'dummy', '123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012'''''''''''''''''''''''''''''''''''''''''''''''''''

For this reason, you should use a large buffer for a command variable or directly execute the dynamic Transact-SQL inside the EXECUTE statement.

Truncation When QUOTENAME(@variable, '''') and REPLACE() Are Used

Strings that are returned by QUOTENAME() and REPLACE() will be silently truncated if they exceed the space that is allocated. The stored procedure that is created in the following example shows what can happen.

SQL

CREATE PROCEDURE sp_MySetPassword @loginname sysname, @old sysname, @new sysname AS -- Declare variables. DECLARE @login sysname DECLARE @newpassword sysname DECLARE @oldpassword sysname DECLARE @command varchar(2000) -- In the following statements, the data stored in temp variables -- will be truncated because the buffer size of @login, @oldpassword, -- and @newpassword is only 128 characters, but QUOTENAME() can return -- up to 258 characters. SET @login = QUOTENAME(@loginname, '''') SET @oldpassword = QUOTENAME(@old, '''') SET @newpassword = QUOTENAME(@new, '''') -- Construct the dynamic Transact-SQL. -- If @new contains 128 characters, then @newpassword will be '123... n -- where n is the 127th character. -- Because the string returned by QUOTENAME() will be truncated, -- it can be made to look like the following statement: -- UPDATE Users SET password ='1234. . .[127] WHERE username=' -- other stuff here

SET @command = 'UPDATE Users set password = ' + @newpassword + ' where username =' + @login + ' AND password = ' + @oldpassword; -- Execute the command. EXEC (@command); GO

Therefore, the following statement will set the passwords of all users to the value that was passed in the previous code

SQL

EXEC sp_MyProc '--', 'dummy', '12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678'

You can force string truncation by exceeding the allocated buffer space when you use REPLACE(). The stored procedure that is created in the following example shows what can happen.

SQL

CREATE PROCEDURE sp_MySetPassword @loginname sysname, @old sysname, @new sysname AS -- Declare variables. DECLARE @login sysname DECLARE @newpassword sysname DECLARE @oldpassword sysname DECLARE @command varchar(2000) -- In the following statements, data will be truncated because -- the buffers allocated for @login, @oldpassword and @newpassword -- can hold only 128 characters, but QUOTENAME() can return -- up to 258 characters. SET @login = REPLACE(@loginname, '''', '''''') SET @oldpassword = REPLACE(@old, '''', '''''') SET @newpassword = REPLACE(@new, '''', '''''') -- Construct the dynamic Transact-SQL. -- If @new contains 128 characters, @newpassword will be '123...n -- where n is the 127th character. -- Because the string returned by QUOTENAME() will be truncated, it -- can be made to look like the following statement: -- UPDATE Users SET password='1234...[127] WHERE username=' -- other stuff here SET @command= 'update Users set password = ''' + @newpassword + ''' where username=''' + @login + ''' AND password = ''' + @oldpassword + ''''; -- Execute the command. EXEC (@command); GO

As with QUOTENAME(), string truncation by REPLACE() can be avoided by declaring temporary variables that are large enough for all cases. When possible, you should call QUOTENAME() or REPLACE() directly inside the dynamic Transact-SQL. Otherwise, you can calculate the required buffer size as follows. For @outbuffer = QUOTENAME(@input), the size of @outbuffer should be 2*(len(@input)+1). When you use REPLACE() and doubling quotation marks, as in the previous example, a buffer of 2*len(@input) is enough.

The following calculation covers all cases:

SQL

WHILE LEN(@find_string) > 0, required buffer size = ROUND(LEN(@input)/LEN(@find_string),0) * LEN(@new_string) + (LEN(@input) % LEN(@find_string))

Truncation When QUOTENAME(@variable, ']') Is Used

Truncation can occur when the name of a SQL Server securable is passed to statements that use the form QUOTENAME(@variable, ']'). The following example shows this.

SQL

CREATE PROCEDURE sp_MyProc

@schemaname sysname, @tablename sysname, AS -- Declare a variable as sysname. The variable will be 128 characters. -- But @objectname actually must allow for 2*258+1 characters. DECLARE @objectname sysname SET @objectname = QUOTENAME(@schemaname)+'.'+ QUOTENAME(@tablename) -- Do some operations. GO

When you are concatenating values of type sysname, you should use temporary variables large enough to hold the maximum 128 characters per value. If possible, call QUOTENAME() directly inside the dynamic Transact-SQL. Otherwise, you can calculate the required buffer size as explained in the previous section.

Zero-day exploit Attack

Zero-day Attack?

Zero-day meaning and definition

"Zero-day" is a broad term that describes recently discovered security vulnerabilities that hackers can use to attack systems. The term "zero-day" refers to the fact that the vendor or developer has only just learned of the flaw – which means they have “zero days” to fix it. A zero-day attack takes place when hackers exploit the flaw before developers have a chance to address it.

Zero-day is sometimes written as 0-day. The words vulnerability, exploit, and attack are typically used alongside zero-day, and it’s helpful to understand the difference:

• A zero-day vulnerability is a software vulnerability discovered by attackers before the vendor has become aware of it. Because the vendors are unaware, no patch exists for zero-day vulnerabilities, making attacks likely to succeed.
• A zero-day exploit is a method hackers use to attack systems with a previously unidentified vulnerability.
• A zero-day attack is the use of a zero-day exploit to cause damage to or steal data from a system affected by a vulnerability.

zero-day attacks and how do zero-day attacks work?

Software often has security vulnerabilities that hackers can exploit to cause havoc. Software developers are always looking out for vulnerabilities to "patch" – that is, develop a solution that they release in a new update.

However, sometimes hackers or malicious actors spot the vulnerability before the software developers do. While the vulnerability is still open, attackers can write and implement a code to take advantage of it. This is known as exploit code.

The exploit code may lead to the software users being victimized – for example, through identity theft or other forms of cybercrime. Once attackers identify a zero-day vulnerability, they need a way of reaching the vulnerable system. They often do this through a socially engineered email – i.e., an email or other message that is supposedly from a known or legitimate correspondent but is actually from an attacker. The message tries to convince a user to perform an action like opening a file or visiting a malicious website. Doing so downloads the attacker’s malware, which infiltrates the user’s files and steals confidential data.

When a vulnerability becomes known, the developers try to patch it to stop the attack. However, security vulnerabilities are often not discovered straight away. It can sometimes take days, weeks, or even months before developers identify the vulnerability that led to the attack. And even once a zero-day patch is released, not all users are quick to implement it. In recent years, hackers have been faster at exploiting vulnerabilities soon after discovery.

Exploits can be sold on the dark web for large sums of money. Once an exploit is discovered and patched, it’s no longer referred to as a zero-day threat.

Zero-day attacks are especially dangerous because the only people who know about them are the attackers themselves. Once they have infiltrated a network, criminals can either attack immediately or sit and wait for the most advantageous time to do so.

Who carries out zero-day attacks?

Malicious actors who carry out zero-day attacks fall into different categories, depending on their motivation. For example:

• Cybercriminals – hackers whose motivation is usually financial gain
• Hacktivists – hackers motivated by a political or social cause who want the attacks to be visible to draw attention to their cause
• Corporate espionage – hackers who spy on companies to gain information about them
• Cyberwarfare – countries or political actors spying on or attacking another country's cyberinfrastructure

Who are the targets for zero-day exploits?

A zero-day hack can exploit vulnerabilities in a variety of systems, including:

• Operating systems
• Web browsers
• Office applications
• Open-source components
• Hardware and firmware
• Internet of Things (IoT)

As a result, there is a broad range of potential victims:

• For individuals who use a vulnerable system, such as a browser or operating system Hackers can use security vulnerabilities to compromise devices and build large botnets
• Individuals with access to valuable business data, such as intellectual property
• Hardware devices, firmware, and the Internet of Things
• Large businesses and organizations
• Government agencies
• Political targets and/or national security threats

It's helpful to think in terms of targeted versus non-targeted zero-day attacks:

• Targeted zero-day attacks are carried out against potentially valuable targets – such as large organizations, government agencies, or high-profile individuals.
• Non-targeted zero-day attacks are typically waged against users of vulnerable systems, such as an operating system or browser.

Even when attackers are not targeting specific individuals, large numbers of people can still be affected by zero-day attacks, usually as collateral damage. Non-targeted attacks aim to capture as many users as possible, meaning that the average user’s data could be affected.

How to identify zero-day attacks

Because zero-day vulnerabilities can take multiple forms – such as missing data encryption, missing authorizations, broken algorithms, bugs, problems with password security, and so on – they can be challenging to detect. Due to the nature of these types of vulnerabilities, detailed information about zero-day exploits is available only after the exploit is identified.

Organizations that are attacked by a zero-day exploit might see unexpected traffic or suspicious scanning activity originating from a client or service. Some of the zero-day detection techniques include:

• Using existing databases of malware and how they behave as a reference. Although these databases are updated very quickly and can be useful as a reference point, by definition, zero-day exploits are new and unknown. So there’s a limit to how much an existing database can tell you.
• Alternatively, some techniques look for zero-day malware characteristics based on how they interact with the target system. Rather than examining the code of incoming files, this technique looks at the interactions they have with existing software and tries to determine if they result from malicious actions.
• Increasingly, machine learning is used to detect data from previously recorded exploits to establish a baseline for safe system behavior based on data of past and current interactions with the system. The more data which is available, the more reliable detection becomes

Examples of zero-day attacks

Some recent examples of zero-day attacks include:

2021: Chrome zero-day vulnerability

In 2021, Google's Chrome suffered a series of zero-day threats, causing chrome to issue updates. The vulnerability stemmed from a bug in the V8 JavaScript engine used in the web browser.

2020: Zoom

A vulnerability was found in the popular video conferencing platform This zero-day attack example involved hackers accessing a user’s PC remotely if they were running an older version of Windows. If the target was an administrator, the hacker could completely take over their machine and access all their files.

2020: Apple iOS

Apple’s iOS is often described as the most secure of the major smartphone platforms. However, in 2020, it fell victim to at least two sets of iOS zero-day vulnerabilities, including a zero-day bug that allowed attackers to compromise iPhones remotely.

2019: Microsoft Windows, Eastern Europe

This attack focused on local escalation privileges, a vulnerable part of Microsoft Windows, and targeted government institutions in Eastern Europe. The zero-day exploit abused a local privilege vulnerability in Microsoft Windows to run arbitrary code and install applications and view and change the data on compromised applications. Once the attack was identified and reported to the Microsoft Security Response Center, a patch was developed and rolled out.

2017: Microsoft Word

This zero-day exploit compromised personal bank accounts. Victims were people who unwittingly opened a malicious Word document. The document displayed a "load remote content" prompt, showing users a pop-up window that requested external access from another program. When victims clicked "yes," the document installed malware on their device, which was able to capture banking log-in credentials.

Stuxnet

One of the most famous examples of a zero-day attack was Stuxnet. First discovered in 2010 but with roots that spread back to 2005, this malicious computer worm affected manufacturing computers running programmable logic controller (PLC) software. The primary target was Iran's uranium enrichment plants to disrupt the country's nuclear program. The worm infected the PLCs through vulnerabilities in Siemens Step7 software, causing the PLCs to carry out unexpected commands on assembly-line machinery. The story of Stuxnet was subsequently made into a documentary called zero-days.

How to protect yourself against zero-day attacks

For zero-day protection and to keep your computer and data safe, it’s essential for both individuals and organizations to follow cyber security best practices. This includes:

Keep all software and operating systems up to date. This is because the vendors include security patches to cover newly identified vulnerabilities in new releases. Keeping up to date ensures you are more secure.

Use only essential applications. The more software you have, the more potential vulnerabilities you have. You can reduce the risk to your network by using only the applications you need.

Use a firewall. A  firewall plays an essential role in protecting your system against zero-day threats. You can ensure maximum protection by configuring it to allow only necessary transactions.

Within organizations, educate users. Many zero-day attacks capitalize on human error. Teaching employees and users good safety and security habits will help keep them safe online and protect organizations from zero-day exploits and other digital threats.

Use a comprehensive antivirus software solution. Kaspersky's total security helps to keep your devices secure by blocking known and unknown threats.

Denial of service attack (DoS)

Denial-of-Service (DoS) attack

 The attack meant to shut down a machine or network, making it inaccessible to its intended users. DoS attacks accomplish this by flooding the target with traffic or sending it information that triggers a crash.

In both instances, the DoS attack deprives legitimate users (i.e. employees, members, or account holders) of the service or resource they expected

Victims of DoS attacks often target web servers of high-profile organizations such as banking, commerce, and media companies, or government and trade organizations. Though DoS attacks do not typically result in the theft or loss of significant information or other assets, they can cost the victim a great deal of time and money to handle.

There are two general methods of DoS attacks: flooding services or crashing services. Flood attacks occur when the system receives too much traffic for the server to buffer, causing them to slow down and eventually stop. Popular flood attacks include:

ICMP flood – leverages misconfigured network devices by sending spoofed packets that ping every computer on the targeted network, instead of just one specific machine. The network is then triggered to amplify the traffic. This attack is also known as the smurf attack or ping of death

SYN flood – sends a request to connect to a server, but never completes the handshake. Continues until all open ports are saturated with requests and none are available for legitimate users to connect to

Other DoS attacks simply exploit vulnerabilities that cause the target system or service to crash. In these attacks, input is sent that takes advantage of bugs in the target that subsequently crash or severely destabilize the system so that it can’t be accessed or used.

s traffic. To achieve the necessary scale, DDoS is often performed by botnets that can co-opt millions of infected machines to unwittingly participate in the attack, even though they are not the target of the attack itself. Instead, the attacker leverages the massive number of infected machines to flood the remote target with traffic and cause a DoS. 

Though the DDoS attack is a type of Do attach, it is significantly more popular in its use due to the features that differentiate and strengthen it from other types of DoS attacks:

The attacking party can execute an attack of disruptive scale as a result of the large network of infected computers—effectively a zombie army—under their command 

The (often worldwide) distribution of attacking systems makes it very difficult to detect where the actual attacking party is located 

* It is difficult for the target server to recognize the traffic as illegitimate and reject it as an entry because of the seemingly random distribution of attacking systems 

* DDoS attacks are much more difficult to shut down than other DoS attacks due to the number of machines that must be shut down, as opposed to just one

* DDoS attacks often target specific organizations (enterprise or public) for personal or political reasons, or to extort payment from the target in return for stopping the DDoS attack. The damages of a DDoS attack are typically in time and money lost from the resulting downtime and lost productivity.

Examples of DDoS attacks are abundant. In January 2012, hacktivist cyber group Anonymous conducted an attack on multiple major supporters of the Stop Online Piracy Act (SOPA). In dissent of SOPA, Anonymous executed DDoS attacks that disabled the websites of the US Justice Department, the Federal Bureau of Investigations (FBI), the White House, the Motion Picture Association of America (MPAA), the Recording Industry Association of America (RIAA), Universal Music Group, and Broadcast Music, Inc (BMI). To facilitate the attack, Anonymous built its botnet using an unconventional model that allowed users wishing to support the organization to offer their computers as a bot for the attacks. Users who wanted to volunteer support could join the Anonymous botnet by clicking links that the organization posted on various locations online, such as Twitter.

The DDoS attack is also leveraged as a weapon of cyber warfare. For example, in 2008 during the South Ossetia war, Georgian government websites were crippled by what is expected to be Russian criminal gangs under the auspices of the Russian security services. The attack was made just prior to Russia’s initial attacks on Georgian soil.

There are a number of DDoS mitigation techniques that organizations can implement to minimize the possibility of an attack. Network security infrastructure should include DDoS detection tools that can identify and block both exploits and tools that attackers use to launch an attack. Additionally, network administrators can create profiles to observe and control specific floods of traffic (i.e. SYN floods, UDP, and ICMP floods). Through looking at all traffic in aggregate, thresholds can be set to monitor and cut behaviors that indicate a possible DDoS attack

A DDoS attack occurs when multiple systems orchestrate a synchronized DoS attack on a single target. The essential difference is that instead of being attacked from one location, the target is attacked from many locations at once. The distribution of hosts that defines a DDoS provide the attacker multiple advantages

* He can leverage the greater volume of machines to execute a seriously disruptive attack

* The location of the attack is difficult to detect due to the random distribution of attacking systems (often worldwide)

* It is more difficult to shut down multiple machines than one

* The true attacking party is very difficult to identify, as they are disguised behind many (mostly compromised) systems

Modern security technologies have developed mechanisms to defend against most forms of DoS attacks, but due to the unique characteristics of DDoS, it is still regarded as an elevated threat and is of higher concern to organizations that fear being targeted by such an attack.