Security Archives | Radware Blog

main

How to Prevent Real-Time API Abuse

April 18, 2019 — by Radware — 0

The widespread adoption of mobile and IoT devices, and increased use of cloud systems are driving a major change in modern application architecture. Application Programming Interfaces (APIs) have emerged as the bridge to facilitate communication between different application architectures. However, with the widespread deployment of APIs, automated attacks on poorly protected APIs are mounting. Personally Identifiable Information (PII), payment card details, and business-critical services are at risk due to automated attacks on APIs.

API. application programming interface, cybersecurity, technology

So what are key API vulnerabilities, and how can you protect against API abuse?

Authentication Flaws

Many APIs only check authentication status, but not if the request is coming from a genuine user. Attackers exploit such flaws through various ways (including session hijacking and account aggregation) to imitate genuine API calls. Attackers also target APIs by reverse-engineering mobile apps to discover how it calls the API. If API keys are embedded into the app, this can result in an API breach. API keys should not be used alone for user authentication.

Lack of Robust Encryption

Many APIs lack robust encryptions between API client and API server. Attackers exploit such vulnerabilities through man-in-the-middle attacks. Attackers also intercept unencrypted or poorly protected API transactions between API client and API server to steal sensitive information or alter transaction data.

What’s more, the ubiquitous use of mobile devices, cloud systems, and microservice design patterns have further complicated API security as now multiple gateways are involved to facilitate interoperability among diverse web applications. The encryption of data flowing through all these channels is paramount.

Business Logic Vulnerability

APIs are vulnerable to business logic abuse. Attackers make repeated and large-scale API calls on an application server or slow POST requests that result in denial of service. A DDoS attack on an API can result in massive disruption on a front-end web application.

Poor Endpoint Security

Most IoT devices and micro-service tools are programmed to communicate with their server through API channels. These devices authenticate themselves on API servers using client certificates. Hackers attempt to get control over an API from the IoT endpoint and if they succeed, they can easily re-sequence API order that can result in a data breach.

How You Can Prevent API Abuse

A bot management solution that defends APIs against automated attacks and ensures that only genuine users have the ability to access APIs is paramount. When evaluating such a solution, consider whether it offers
broad attack detection and coverage, comprehensive reporting and analytics, and flexible deployment options.

Other steps you can (and should) take include:

Monitor and manage API calls coming from automated scripts (bots)
Drop primitive authentication
Implement measures to prevent API access by sophisticated human-like bots
Robust encryption is a must-have
Deploy token-based rate limiting equipped with features to limit API access based on the number of IPs, sessions, and tokens
Implement robust security on endpoints

Read “Radware’s 2018 Web Application Security Report” to learn more.

Download Now

Bot Managers Are a Cash-Back Program For Your Company

April 17, 2019 — by Ben Zilberman — 0

In my previous blog, I briefly discussed what bot managers are and why they are needed. Today, we will conduct a short ROI exercise (perhaps the toughest task in information security!).

To recap: Bots generate a little over half of today’s internet traffic. Roughly half of that half (i.e. a quarter, for rusty ones like myself…) is generated by bad bots, a.k.a. automated programs targeting applications with the intent to steal information or disrupt service. Over the years, they have gotten so sophisticated, they can easily mimic human behavior, perform allegedly uncorrelated violation actions and essentially fool most of application security solutions out there.

These bots affect each and every arm of your business. If you are in the e-commerce or travel industries, no need to tell you that… if you aren’t, go to your next C-level executive meeting and look for those who scratch their heads the most. Why? Because they can’t understand where the money goes, and why the predicted performance didn’t materialize as expected.

Let’s go talk to these C-Suite executives, shall we?

Chief Revenue Officer

Imagine you are selling product online–whether that’s tickets, hotel rooms or even 30-pound dog food bags–and this is your principal channel for revenue generation. Now, imagine that bots act as faux buyers, and hold the inventory “hostage” so genuine customers can not access them.

Sure, you can elapse the process every 10 minutes, but as this is an automated program, it will re-initiate the process in a split second. And what about CAPTCHA? Don’t assume CAPTCHA will weed out all bots; some bots activate after a human has solved it. How would you know when you are communicating with a bot or a human? (Hint: you’d know if you had a bot management solution).

Wondering why the movie hall is empty half the time even though it’s a hot release? Does everybody go to the theater across the street? No. Bots are to blame. And they cause direct, immediate and painful revenue loss.

Chief Marketing Officer

Digital marketing tools, end-to-end automation of the customer journey, lead generation, and content syndication are great tools that help CMOs measure ROI and plan budgets. But what if the analysis they provide are false? What if half the clicks you are paying for are fictitious, and you were subject to a click-fraud campaign by bots? What if a competitor uses a bot to scrape data of registrants out of your landing pages? Unfortunately, bots often skew the analysis and can lead you to make wrong decisions that result in poor performance. Without bot management, you’re wasting money in vain.

Chief Operations Officer/Chief Information Officer

Does your team complain that your network resources are in the “red zone,” close to maximum performance, but your customer base isn’t growing at the same pace?

Blame bots.

Obviously some bots are “good,” like automated services that help accelerate and streamline your business, analyze data quickly and help you to make better decisions. However, bad bots (26% of the total traffic you are processing) put a load on your infrastructure and make your IT staff cry for more capacity. So you invest $200-500K in bigger firewalls, ADCs, and broader internet pipes, and upgrade your servers.

Next thing you know, a large DDoS attack from IoT botnets knocks everything down. If only you had invested $50k upfront to filter out the bad traffic from the get-go… That could’ve translated to $300k cash back!

Chief Information Security Officer

Every hour, a new security vendor knocks on your door with another solution for a 0.0001% probability what-if scenario… your budget is all over the place, spent on multiple protections and a complex architecture trying to take an actionable snapshot of what’s going on at every moment. At the end of the day, your task is to protect your company’s information assets. And there are so many ways to get a hold of those precious secrets!

Bad bots are your enemy. They can scrape content, files, pricing, and intellectual property from your website. They can take over user accounts by cracking their passwords or launch a credential stuffing attack (and then retrieve their payment info). And they can take down service with DDoS attacks and hold up inventory, as I previously mentioned.

You can absolutely reduce these risks significantly if you could distinguish human versus bot traffic (remember, sophisticated bots today can mimic human behavior and bypass all sorts of challenges, not only CAPTCA), and more than that, which bot is legitimate and which is malicious.

Bot management equals less risk, better posture, stable business, no budget increases or unexpected expenses. Cash back!

Chief Financial Officer

Your management peers could have made better investments, but now you have to clean up their mess. This can include paying legal fees and compensation to customers whose data was compromised, paying regulatory fines for coming up short in compliance, shelling out for a crisis management consultant firm, and absorbing costs associated with inventory hold up and downed service.

If you only had a bot management solution in place… so much cash back.

The Bottom Line

Run–do not walk–to your CEO and request a much-needed bot management solution. Not only does s/he have nothing to lose, s/he has a lot to gain.

* This week, Radware integrates bot management service with its cloud WAF for a complete, fully managed, application security suite.

Read “Radware’s 2018 Web Application Security Report” to learn more.

Download Now

Here’s How You Can Better Mitigate a Cyberattack

April 16, 2019 — by Daniel Smith — 0

Where does the attack landscape lead us into 2020? No one knows for sure, but strong indicators help Radware build logic chains to better forecast where the state of network security is heading in the future. Last year alone, the initial attributable cost of cyberattacks increased by 52% and 93% of those surveyed in our 2018-2019 Global Application and Network Security report experienced a cyberattack over the previous 12 months.

Let’s face it, today you stand a better chance of mitigating an attack if you understand your risks and the threats you may suffer due to your exposure. Once you begin to understand your enemies’ tactics, techniques, and procedures (TTPs), you can then begin to understand your enemies’ intentions and ability to disrupt your network. This is a good thing. Once you understand the basics, you can then begin to forecast attacks, allowing operators time to prepare to identify and mitigate malicious activity.

Preparing for the next generation of cyber attacks has become the new norm and requires organizations to stay ahead of the threat landscape. Radware’s Hackers Almanac is designed to help do exactly that by generating awareness about current TTPs used by cyber criminals. In the Hackers Almanac, we cover two main topics: Groups and Tools.

Clear and Present Dangers

In the Groups section, we cover APTs, Organized Crime, Extortionist, DDoS’ers, Political and Patriotic Hackers, as well as Malicious insiders. In the Tools section, we cover Ransomware variants, exploit kits, Trojans and Botnets, as well as consumer tools and other persistent threats that can be expected on an annual basis.

While these threats constitute a clear and present danger to most if not all networks, knowledge is power and the first step to securing your network starts with surveying and auditing. Ensure that your system is up to date and adequately patched. The second step is getting in front of the problem by studying cyber criminals, the way they operate and how they launch their attacks. By understanding your network and its limitations and how hackers launch attacks, your organization can better prepare for attack vectors commonly leveraged by different threats targeting your network

There is no need to fight every battle at the end of the day when you can learn from those around you. Before securing your network, make sure to conduct an audit of your organization’s system and understand its vulnerabilities/weaknesses. Then, leverage this almanac to study the threats posed against your organization.

Download “Hackers Almanac” to learn more.

Download Now

Can You Crack the Hack?

April 11, 2019 — by Daniel Smith — 0

Let’s play a game. Below are clues describing a specific type of cyberattack; can you guess what it is?

This cyberattack is an automated bot-based attack
It uses automation tools such as cURL and PhantomJS
It leverages breached usernames and passwords
Its primary goal is to hijack accounts to access sensitive data, but denial of service is another consequence
The financial services industry has been the primary target

Struggling? We understand, it’s tricky! Here are two more clues:

Hackers will often route login requests through proxy servers to avoid blacklisting their IP addresses
It is a subset of Brute Force attacks, but different from credential cracking

And the Answer Is….

Credential stuffing! If you didn’t guess correctly, don’t worry. You certainly aren’t alone. At this year’s RSA Conference, Radware invited attendees to participate in a #HackerChallenge. Participants were given clues and asked to diagnose threats. While most were able to surmise two other cyber threats, credential stuffing stumped the majority.

Understandably so. For one, events are happening at a breakneck pace. In the last few months alone, there have been several high-profile attacks leveraging different password attacks, from credential stuffing to credential spraying. It’s entirely possible that people are conflating the terms and thus the attack vectors. Likewise, they may also confuse credential stuffing with credential cracking.

Stuffing vs. Cracking vs. Spraying

As we’ve previously written, credential stuffing is a subset of brute force attacks but is different from credential cracking. Credential stuffing campaigns do not involve the process of brute forcing password combinations. Rather, they leverage leaked username and passwords in an automated fashion against numerous websites to take over users’ accounts due to credential reuse.

Conversely, credential cracking attacks are an automated web attack wherein criminals attempt to crack users’ passwords or PIN numbers by processing through all possible combines of characters in sequence. These attacks are only possible when applications do not have a lockout policy for failed login attempts. Software for this attack will attempt to crack the user’s password by mutating or brute forcing values until the attacker is successfully authenticated.

As for credential (or password) spraying, this technique involves using a limited set of company-specific passwords in attempted logins for known usernames. When conducting these types of attacks, advanced cybercriminals will typically scan your infrastructure for external facing apps and network services such as webmail, SSO and VPN gateways. Usually, these interfaces have strict timeout features. Actors will use password spraying vs. brute force attacks to avoid being timed out and possibly alerting admins.

So What Can You Do?

A dedicated bot management solution that is tightly integrated into your Web Application Firewall (WAF) is critical. Device fingerprinting, CAPTCHA, IP rate-based detection, in-session detection and terminations JavaScript challenge is also important.

In addition to these steps, network operators should apply two-factor authentication where eligible and monitor dump credentials for potential leaks or threats.

Read “Radware’s 2018 Web Application Security Report” to learn more.

Download Now

Anatomy of a Cloud-Native Data Breach

April 10, 2019 — by Radware — 0

Migrating computing resources to cloud environments opens up new attack surfaces previously unknown in the world of premise-based data centers. As a result, cloud-native data breaches frequently have different characteristics and follow a different progression than physical data breaches. Here is a real-life example of a cloud-native data breach, how it evolved and how it possibly could have been avoided.

Target Profile: A Social Media/Mobile App Company

The company is a photo-sharing social media application, with over 20 million users. It stores over 1PB of user data within Amazon Web Services (AWS), and in 2018, it was the victim of a massive data breach that exposed nearly 20 million user records. This is how it happened.

Step 1: Compromising a legitimate user. Frequently, the first step in a data breach is that an attacker compromises the credentials of a legitimate user. In this incident, an attacker used a spear-phishing attack to obtain an administrative user’s credentials to the company’s environment.

Step 2: Fortifying access. After compromising a legitimate user, a hacker frequently takes steps to fortify access to the environment, independent of the compromised user. In this case, the attacker connected to the company’s cloud environment through an IP address registered in a foreign country and created API access keys with full administrative access.

Step 3: Reconnaissance. Once inside, an attacker then needs to map out what permissions are granted and what actions this role allows.

Step 4: Exploitation. Once the available permissions in the account have been determined, the attacker can proceed to exploit them. Among other activities, the attacker duplicated the master user database and exposed it to the outside world with public permissions.

Step 5: Exfiltration. Finally, with customer information at hand, the attacker copied the data outside of the network, gaining access to over 20 million user records that contained personal user information.

Lessons Learned

Your Permissions Equal Your Threat Surface: Leveraging public cloud environments means that resources that used to be hosted inside your organization’s perimeter are now outside where they are no longer under the control of system administrators and can be accessed from anywhere in the world. Workload security, therefore, is defined by the people who can access those workloads and the permissions they have. In effect, your permissions equal your attack surface.

Excessive Permissions Are the No. 1 Threat: Cloud environments make it very easy to spin up new resources and grant wide-ranging permissions but very difficult to keep track of who has them. Such excessive permissions are frequently mischaracterized as misconfigurations but are actually the result of permission misuse or abuse. Therefore, protecting against those excessive permissions becomes the No. 1 priority for securing publicly hosted cloud workloads.

Cloud Attacks Follow Typical Progression: Although each data breach incident may develop differently, a cloud-native attack breach frequently follows a typical progression of a legitimate user account compromise, account reconnaissance, privilege escalation, resource exploitation and data exfiltration.

What Could Have Been Done Differently?

Protect Your Access Credentials: Your next data breach is a password away. Securing your cloud account credentials — as much as possible — is critical to ensuring that they don’t fall into the wrong hands.

Limit Permissions: Frequently, cloud user accounts are granted many permissions that they don’t need or never use. Exploiting the gap between granted permissions and used permissions is a common move by hackers. In the aforementioned example, the attacker used the accounts’ permissions to create new administrative-access API keys, spin up new databases, reset the database master password and expose it to the outside world. Limiting permissions to only what the user needs helps ensure that, even if the account is compromised, the damage an attacker can do is limited.

Alert of Suspicious Activities: Since cloud-native data breaches frequently have a common progression, there are certain account activities — such as port scanning, invoking previously used APIs and granting public permissions — which can be identified. Alerting against such malicious behavior indicators (MBIs) can help prevent a data breach before it occurs.

Automate Response Procedures: Finally, once malicious activity has been identified, fast response is paramount. Automating response mechanisms can help block malicious activity the moment it is detected and stop the breach from reaching its end goal.

Read “The Trust Factor: Cybersecurity’s Role in Sustaining Business Momentum” to learn more.

Download Now

Out of the Shadows, Into the Network

April 9, 2019 — by Radware — 0

Network security is a priority for every carrier worldwide. Investments in human resources and technology solutions to combat attacks are a significant part of carriers’ network operating budgets.

The goal is to protect their networks by staying a few steps ahead of hackers. Currently, carriers may be confident that their network security solution is detecting and mitigating DDoS attacks.

All the reports generated by the solution show the number and severity of attacks as well as how they were thwarted. Unfortunately, we know it’s a false sense of well-being because dirty traffic in the form of sophisticated application attacks is getting through security filters. No major outages or data breaches have been attributed to application attacks yet, so why should carriers care?

Maintaining a Sunny Reputation

The impact of application attacks on carriers and their customers takes many forms:

Service degradation
Network outages
Data exposure
Consumption of bandwidth resources
Consumption of system resources

A large segment of carriers’ high-value customers have zero tolerance for service interruption. There is a direct correlation between service outages and user churn.

Application attacks put carriers’ reputations at risk. For customers, a small slowdown in services may not be a big deal initially. But as the number and severity of application attacks increase, clogged pipes and slow services are not going to be acceptable. Carriers sell services based on speed and reliability. Bad press about service outages and data compromises has long-lasting negative effects. Then add the compounding power of social networking to quickly spread the word about service issues, and you have a recipe for reputation disaster.

Always Under Attack

It’s safe for carriers to assume that their networks are always under attack. DDoS attack volume is escalating as hackers develop new and more technologically sophisticated ways to target carriers and their customers In 2018, attack campaigns were primarily composed of multiple attacks vectors, according to the Radware 2018–2019 Global Application & Network Security Report.

The report finds that “a bigger picture is likely to emerge about the need to deploy security solutions that not only adapt to changing attack vectors to mitigate evolving threats but also maintain service availability at the same time.”

Attack vectors include:

SYN Flood
UDP Flood
DNS Flood
HTTP Application Flood
SSL Flood
Burst Attacks
Bot Attacks

Attackers prefer to keep a target busy by launching one or a few attacks at a time rather than firing the entire arsenal all at once. Carriers may be successful at blocking four or five attack vectors, but it only takes one failure for the damage to be done.

Read “Creating a Secure Climate for your Customers” today.

Download Now

Are Connected Cows a Hacker’s Dream?

April 3, 2019 — by Mike O'Malley — 0

Humans aren’t the only ones consumed with connected devices these days. Cows have joined our ranks.

Believe it or not, farmers are increasingly relying on IoT devices to keep their cattle connected. No, not so that they can moo-nitor (see what I did there?) Instagram, but to improve efficiency and productivity. For example, in the case of dairy farms, robots feed, milk and monitor cows’ health, collecting data along the way that help farmers adjust techniques and processes to increase milk production, and thereby profitability.

The implications are massive. As the Financial Times pointed out, “Creating a system where a cow’s birth, life, produce and death are not only controlled but entirely predictable could have a dramatic impact on the efficiency of the dairy industry.”

From Dairy Farm to Data Center

So, how do connected cows factor into cybersecurity? By the simple fact that the IoT devices tasked with milking, feeding and monitoring them are turning dairy farms into data centers – which has major security implications. Because let’s face it, farmers know cows, not cybersecurity.

Indeed, the data collected are stored in data centers and/or a cloud environment, which opens farmers up to potentially costly cyberattacks. Think about it: The average U.S. dairy farm is a $1 million operation, and the average cow produces $4,000 in revenue per year. That’s a lot at stake—roughly $19,000 per week, given the average dairy farm’s herd—if a farm is struck by a ransomware attack.

It would literally be better for an individual farm to pay a weekly $2,850 ransom to keep the IoT network up. And if hackers were sophisticated enough to launch an industry-wide attack, the dairy industry would be better off paying $46 million per week in ransom rather than lose revenue.

5G Cows

Admittedly, connected cows aren’t new; IoT devices have been assisting farmers for several years now. And it’s a booming business. Per the FT, “Investment in precision ‘agtech’ systems reached $3.2bn globally in 2016 (including $363m in farm management and sensor technology)…and is set to grow further as dairy farms become a test bed for the wider IoT strategy of big technology companies.”

But what is new is the rollout of 5G networks, which promise faster speeds, low latency and increased flexibility—seemingly ideal for managing IoT devices. But, as we’ve previously discussed, with new benefits come new risks. As network architectures evolve to support 5G, security vulnerabilities will abound if cybersecurity isn’t prioritized and integrated into a 5G deployment from the get-go.

In the new world of 5G, cyberattacks can become much more potent, as a single hacker can easily multiply into an army through botnet deployment. Indeed, 5G opens the door to a complex world of interconnected devices that hackers will be able to exploit via a single point of access in a cloud application to quickly expand an attack radius to other connected devices and applications. Just imagine the impact of a botnet deployment on the dairy industry.

I don’t know about you, but I like my milk and cheeses. Here’s to hoping dairy farmers turn to the experts to properly manage their security before the industry is hit with devastating cyberattacks.

Read “Creating a Secure Climate for your Customers” today.

Download Now

What is a Zero-Day Attack?

April 2, 2019 — by Radware — 0

Zero-day attacks are the latest, never-before-seen generation of attacks. They are not volumetric or detectable from a known application signature. Security systems and experts must react instantly to solve the new issues, that is, they have zero days to react. Advanced application-level attacks typically fit into this category.

Two Distinct Phases

Probe and Learn: Hackers assess network defenses and probe for vulnerabilities, looking for different weaknesses and identifying the type of attacks that will potentially be effective. It’s like an archer who picks the best arrows to put in his quiver before battle. For example, a hacker may determine that a combination of encrypted attacks, attacks from a rotating IP address source, new low and slow attacks and headless browser attacks will be most effective.

Optimize, Morph and Attack: Hackers launch the attack and then vary the attack vectors (or arrows from the quiver). In this case, hackers often understand that legacy DDoS mitigators need manual intervention to troubleshoot and mitigate a zero-day attack. So they attack the weakness of the legacy mitigator (multiple manual troubleshooting cycles to stop an attack) in addition to attacking the application vulnerabilities.

Who Are the Attackers?

Richard Clarke, former special cybersecurity advisor to the U.S. president, devised an acronym — C.H.E.W. — to categorize and explain the origin of cyberattacks (that specifically target carriers and enterprises):

Cybercrime — the notion that someone is going to attack you with the primary motive being financial gain from the endeavor.
Hacktivism — attacks motivated by ideological differences. The primary focus of these attacks is not financial gain but rather persuading or dissuading certain actions or “voices.”
Espionage — straightforward motive of gaining information on another organization in pursuit of political, financial, capitalistic, market share or some other form of leverage.
War (Cyber) — the notion of a nation-state or transnational threat to an adversary’s centers of power via a cyberattack. Attacks could focus on nonmilitary critical infrastructure.

The attackers can range from a tech-savvy teenager to a highly organized group that taps into huge server farms in places like Russia and Ukraine to facilitate attacks.

The types of hackers are as varied that the methods they employ and include APTs (advanced persistent threats) agents, corporate spies, cybercriminals, cyberwarriors, hacktivists, rogue hackers, spammers and malware spreaders.

Read “Radware’s 2018 Web Application Security Report” to learn more.

Download Now

Is It Legal to Evaluate a DDoS Mitigation Service?

March 27, 2019 — by Dileep Mishra — 2

A couple of months ago, I was on a call with a company that was in the process of evaluating DDoS mitigation services to protect its data centers. This company runs mission critical applications and were looking for comprehensive coverage from various types of attacks, including volumetric, low and slow, encrypted floods, and application-layer attacks.

During the discussion, our team asked a series of technical questions related to their ISP links, types of applications, physical connectivity, and more. And we provided an attack demo using our sandbox lab in Mahwah.

Everything was moving along just fine until the customer asked us for a Proof of Concept (PoC), what most would consider a natural next step in the vendor evaluation process.

About That Proof of Concept…

How would you do a DDoS POC? You rack and stack the DDoS mitigation appliance (or enable the service if it is cloud based), set up some type of management IP address, configure the protection policies, and off you go!

Well, when we spoke to this company, they said they would be happy to do all of that–at their disaster recovery data center located within a large carrier facility on the east coast. This sent my antenna up and I immediately asked a couple of questions that would turn out to be extremely important for all of us: Do you have attack tools to launch DDoS attacks? Do you take the responsibility to run the attacks? Well, the customer answered “yes” to both.

Being a trained SE, I then asked why they needed to run the PoC in their lab and if there was a way we could demonstrate that our DDoS mitigation appliance can mitigate a wide range of attacks using our PoC script. As it turned out, the prospect was evaluating other vendors and, to compare apples to apples (thereby giving all vendors a fair chance), were already conducting a PoC in their data center with their appliance.

We shipped the PoC unit quickly and the prospect, true to their word, got the unit racked and stacked, cabled up ready to go. We configured the device then gave them the green light to launch attacks. And then the prospect told us to launch the attacks; that they didn’t have any attack tools.

A Bad Idea

Well, most of us in this industry do have DDoS testing tools, so what’s the big deal? As vendors who provide cybersecurity solutions, we shouldn’t have any problems launching attacks over the Internet to test out a DDoS mitigation service…right?

WRONG! Here’s why that’s a bad idea:

Launching attacks over the Internet is ILLEGAL. You need written permission from the entity being attacked to launch a DDoS attack. You can try your luck if you want, but this is akin to running a red light. You may get away with it, but if you are caught the repercussions are damaging and expensive.
Your ISP might block your IP address. Many ISPs have DDoS defenses within their infrastructure and if they see someone launching a malicious attack, they might block your access. Good luck sorting that one out with your ISP!
Your attacks may not reach the desired testing destination. Well, even if your ISP doesn’t block you and the FBI doesn’t come knocking, there might be one or more DDoS mitigation devices between you and the customer data center where the destination IP being tested resides. These devices could very well mitigate the attack you launch preventing you from doing the testing.

Those are three big reasons why doing DDoS testing in a production data center is, simply put, a bad idea. Especially if you don’t have a legal, easy way to generate attacks.

A Better Way

So what are the alternatives? How should you do DDoS testing?

With DDoS testing, the focus should be on evaluating the mitigation features – e.g. can the service detect attacks quickly, can it mitigate immediately, can it adapt to attacks that are morphing, can it report accurately on the attack it is seeing, and what is being mitigated, how accurate is the mitigation (what about false positives). If you run a DDoS PoC in a production environment, you will spend most of your resources and time on testing the connectivity and spinning the wheels on operational aspects (e.g. LAN cabling, console cabling, change control procedures, paperwork, etc.). This is not what you want to test; you want to test DDoS mitigation! It’s like trying to test how fast a sports car can go on a very busy street. You will end up testing the brakes, but you won’t get very far with any speed testing.
Test things out in your lab. Even better, let the vendor test it in their lab for you. This will let both parties focus on the security features rather than get caught up with the headaches of logistics involved with shipping, change control, physical cabling, connectivity, routing etc.
It is perfectly legal to use test tools like Kali Linux, Backtrack etc. within a lab environment. Launch attacks to your heart’s content, morph the attacks, see how the DDoS service responds.
If you don’t have the time or expertise to launch attacks yourself, hire a DDoS testing service. Companies like activereach, Redwolf security or MazeBolt security do this for a living, and they can help you test the DDoS mitigation service with a wide array of customized attacks. This will cost you some money, but if you are serious about the deployment, you will be doing yourself a favor and saving future work.
Finally, evaluate multiple vendors in parallel. You can never do this in a production data center. However, in a lab you can keep the attacks and the victim applications constant, while just swapping in the DDoS mitigation service. This will give you an apples-to-apples comparison of the actual capabilities of each vendor and will also shorten your evaluation cycle.

Read “The Trust Factor: Cybersecurity’s Role in Sustaining Business Momentum” to learn more.

Download Now

DDoS Protection Requires Looking Both Ways

March 26, 2019 — by Eyal Arazi — 0

Service availability is a key component of the user experience. Customers expect services to be constantly available and fast-responding, and any downtime can result in disappointed users, abandoned shopping carts, and lost customers.

Consequently, DDoS attacks are increasing in complexity, size and duration. Radware’s 2018 Global Application and Network Security Report found that over the course of a year, sophisticated DDoS attacks, such as burst attacks, increased by 15%, HTTPS floods grew by 20%, and over 64% of customers were hit by application-layer (L7) DDoS attacks.

Some Attacks are a Two-Way Street

As DDoS attacks become more complex, organizations require more elaborate protections to mitigate such attacks. However, in order to guarantee complete protection, many types of attacks – particularly the more sophisticated ones – require visibility into both inbound and outbound channels.

Some examples of such attacks include:

Out of State Protocol Attacks: Some DDoS attacks exploit weaknesses in protocol communication processes, such as TCP’s three-way handshake sequence, to create ‘out-of-state’ connection requests, thereby drawing-out connection requests in order to exhaust server resources. While some attacks of this type, such as a SYN flood, can be stopped by examining the inbound channel only, others require visibility into the outbound channel, as well.

An example of this is an ACK flood, whereby attackers continuously send forged TCP ACK packets towards the victim host. The target host then tries to associate the ACK reply to an existing TCP connection, and if none such exists, it will drop the packet. However, this process consumes server resources, and large numbers of such requests can deplete system resources. In order to correctly identify and mitigate such attacks, defenses need visibility to both inbound SYN and outbound SYN/ACK replies, so that they can verify whether the ACK packet is associated with any legitimate connection request.

Reflection/Amplification Attacks: Such attacks exploit asymmetric responses between the connection requests and replies of certain protocols or applications. Again, some types of such attacks require visibility into both the inbound and outbound traffic channels.

An example of such attack is a large-file outbound pipe saturation attack. In such attacks, the attackers identify a very large file on the target network, and send a connection request to fetch it. The connection request itself can be only a few bytes in size, but the ensuing reply could be extremely large. Large amounts of such requests can clog-up the outbound pipe.

Another example are memcached amplification attacks. Although such attacks are most frequently used to overwhelm a third-party target via reflection, they can also be used to saturate the outbound channel of the targeted network.

Scanning Attacks: Large-scale network scanning attempts are not just a security risk, but also frequently bear the hallmark of a DDoS attack, flooding the network with malicious traffic. Such scan attempts are based on sending large numbers of connection requests to host ports, and seeing which ports answer back (thereby indicating that they are open). However, this also leads to high volumes of error responses by closed ports. Mitigation of such attacks requires visibility into return traffic in order to identify the error response rate relative to actual traffic, in order for defenses to conclude that an attack is taking place.

Server Cracking: Similar to scanning attacks, server cracking attacks involve sending large amounts of requests in order to brute-force system passwords. Similarly, this leads to a high error reply rate, which requires visibility into both the inbound and outbound channels in order to identify the attack.

Stateful Application-Layer DDoS Attacks: Certain types of application-layer (L7) DDoS attacks exploit known protocol weaknesses or order to create large amounts of spoofed requests which exhaust server resources. Mitigating such attacks requires state-aware bi-directional visibility in order to identify attack patterns, so that the relevant attack signature can be applied to block it. Examples of such attacks are low-and-slow and application-layer (L7) SYN floods, which draw-out HTTP and TCP connections in order to continuously consume server resources.

Two-Way Attacks Require Bi-Directional Defenses

As online service availability becomes ever-more important, hackers are coming up with more sophisticated attacks than ever in order to overwhelm defenses. Many such attack vectors – frequently the more sophisticated and potent ones – either target or take advantages of the outbound communication channel.

Therefore, in order for organizations to fully protect themselves, they must deploy protections that allow bi-directional inspection of traffic in order to identify and neutralize such threats.

Read “The Trust Factor: Cybersecurity’s Role in Sustaining Business Momentum” to learn more.

Download Now

Older Posts

main

Authentication Flaws

Lack of Robust Encryption

Business Logic Vulnerability

Poor Endpoint Security

How You Can Prevent API Abuse

Read “Radware’s 2018 Web Application Security Report” to learn more.

Share this:

Chief Revenue Officer

Chief Marketing Officer

Chief Operations Officer/Chief Information Officer

Chief Information Security Officer

Chief Financial Officer

The Bottom Line

Read “Radware’s 2018 Web Application Security Report” to learn more.

Share this:

Clear and Present Dangers

Download “Hackers Almanac” to learn more.

Share this:

And the Answer Is….

Stuffing vs. Cracking vs. Spraying

So What Can You Do?

Read “Radware’s 2018 Web Application Security Report” to learn more.

Share this:

Target Profile: A Social Media/Mobile App Company

Lessons Learned

What Could Have Been Done Differently?

Read “The Trust Factor: Cybersecurity’s Role in Sustaining Business Momentum” to learn more.

Share this:

Maintaining a Sunny Reputation

Always Under Attack

Read “Creating a Secure Climate for your Customers” today.

Share this:

From Dairy Farm to Data Center

5G Cows

Read “Creating a Secure Climate for your Customers” today.

Share this:

Two Distinct Phases

Who Are the Attackers?

Read “Radware’s 2018 Web Application Security Report” to learn more.

Share this:

About That Proof of Concept…

A Bad Idea

A Better Way

Read “The Trust Factor: Cybersecurity’s Role in Sustaining Business Momentum” to learn more.

Share this:

Some Attacks are a Two-Way Street

Two-Way Attacks Require Bi-Directional Defenses

Read “The Trust Factor: Cybersecurity’s Role in Sustaining Business Momentum” to learn more.

Share this: