Our Firewall Analytics tool enables customers to quickly identify and investigate security threats using an intuitive interface. Until now, this tool had only been available to our Enterprise customers, who have been using it to get detailed insights into their traffic and better tailor their security configurations. Today, we are excited to make Firewall Analytics available to all paid plans and share details on several recent improvements we have made.

All paid plans are now able to take advantage of these capabilities, along with several important enhancements we’ve made to improve our customers’ workflow and productivity.

Previously, Enterprise customers could view 14 days of Firewall Analytics for their domains. Today we’re increasing that retention to 30 days, and again to 90 days in the coming months. Business and Professional plan zones will get 30 and 3 days of retention, respectively.

In addition to the extended retention, we are introducing adaptive sampling to guarantee that Firewall Analytics results are displayed in the Cloudflare Dashboard quickly and reliably, even when you are under a massive attack or otherwise receiving a large volume of requests.

Adaptive sampling works similar to Netflix: when your internet connection runs low on bandwidth, you receive a slightly downscaled version of the video stream you are watching. When your bandwidth recovers, Netflix then upscales back to the highest quality available.

Firewall Analytics does this sampling on each query, ensuring that customers see the best precision available in the UI given current load on the zone. When results are sampled, the sampling rate will be displayed as shown below:

As adoption of our expressive Firewall Rules engine has grown, one consistent ask we’ve heard from customers is for a more streamlined way to see all Firewall Events generated by a specific rule. Until today, if a malicious request matched multiple rules, only the last one to execute was shown in the Activity Log, requiring customers to click into the request to see if the rule they’re investigating was listed as an “Additional match”.

To streamline this process, we’ve changed how the Firewall Analytics UI interacts with the Activity Log. Customers can now filter by a specific rule (or any other criteria) and see a row for each event generated by that rule. This change also makes it easier to review all requests that would have been blocked by a rule by creating it in Log mode first before changing it to Block.

When our customers write rules to block undesired, automated traffic they want to make sure they’re not blocking or challenging desired traffic, e.g., humans wanting to make a purchase should be allowed but not bots scraping pricing.

To help customers determine what percent of CAPTCHA challenges returned to users may have been unnecessary, i.e., false positives, we are now showing the Challenge Solve Rate (CSR) for each rule. If you’re seeing rates higher than expected, e.g., for your Bot Management rules, you may want to relax the rule criteria. If the rate you see is 0% indicating that no CAPTCHAs are being solved, you may want to change the rule to Block outright rather than challenge.

Hovering over the CSR rate will reveal the number of CAPTCHAs issued vs. solved:

Business and Enterprise customers can now export a set of 500 events from the Activity Log. The data exported are those events that remain after any selected filters have been applied.

Sometimes the columns shown in the Activity Log do not contain the details you want to see to analyze the threat. When this happens, you can now click “Edit Columns” to select the fields you want to see. For example, a customer diagnosing a Bot related issue may want to also view the User-Agent and the source country whereas a customer investigating a DDoS attack may want to see IP addresses, ASNs, Path, and other attributes. You can now customize what you’d like to see as shown below.

We would love to hear your feedback and suggestions, so feel free to reach out to us via our Community forums or through your Customer Success team.

If you’d like to receive more updates like this one directly to your inbox, please subscribe to our Blog!

A new zero-day vulnerability was discovered for vBulletin, a proprietary Internet forum software. By exploiting this vulnerability, bad actors could potentially gain privileged access and control to the host servers on which this software runs, through Remote Code Execution (RCE).

At Cloudflare, we use three key indicators to understand the severity of a vulnerability 1) how many customers on Cloudflare are running the affected software 2) the Common Vulnerability Scoring System (CVSS) score, and 3) the OWASP Top 10, an open-source security framework.

We assess this vulnerability to be very significant as it has a CVSS score of 9.8/10 and affects 7 out of the 10 key risk areas of the OWASP 2017 Top 10.

Remote Code Execution is considered a type of injection, which provides the capability to potentially launch a catastrophic attack. Through RCE an attacker can gain privileged access to the host server that might be running the unpatched and vulnerable version of this software. With elevated privileges the attacker could perform malicious activities including discovery of additional vulnerabilities in the system, checks for misconfigured file permissions on configuration files and even delete logs to wipe out the possibility of audit trails to their activities.

We also have often observed attackers exploit RCE vulnerabilities to deploy malware on the host, make it part of a DDoS Botnet attack or exfiltrate valuable data stored in the system.

At Cloudflare, we continuously strive to improve the security posture of our customers by quickly and seamlessly mitigating vulnerabilities of this nature. Protection against common RCE attacks is a standard feature of Cloudflare's Managed Rulesets. To provide coverage for this specific vulnerability, we have deployed a new rule within our Cloudflare Specials Rulesets (ruleId: 100166). Customers who have our Managed Rulesets and Cloudflare Specials enabled will be immediately protected against this vulnerability.

To check whether you have this protection enabled, please login, navigate to the Firewall tab and under the Managed Rulesets tab you will find the toggle to enable the WAF Managed Rulesets. See below:

Next, confirm that you have the Cloudflare Specials Rulesets enabled, by checking in the Managed Rulesets card as shown below:

Our customers who use our free services or those who don't have Cloudflare's Managed Rulesets turned on, can also protect themselves by deploying a patch on their own. The vBulletin team have released a security patch, the details of which can be found here.

Cloudflare’s Firewall is built on a network that continuously learns from our vast network spanning over 190 countries. In Q2’19 Cloudflare blocked an average of 44 billion cyber threats each day. Learn more about our simple, easy to use and powerful Cloudflare Firewall and protect your business today.

We have done away with those pesky modals, providing a much smoother user experience. To review more detailed information about an event, you simply click anywhere on the event list row.

In the expanded view, you are provided with all the information you may need to identify or diagnose issues with your Firewall or find more details about a potential threat to your application.

Cloudflare has several Firewall features to give customers granular control of their security. With this control comes some complexity when debugging why a request was stopped by the Firewall. To help clarify what happened, we have provided an “Additional matches” count at the bottom for events triggered by multiple services or rules for the same request. Clicking the number expands a list showing each rule and service along with the corresponding action.

This is one of my favourite parts of our new Firewall Event Log. Many of our customers have expressed their frustration with the difficulty of pinpointing specific events. This is where our new search capabilities come into their own. Customers can now filter and freeform search for any field that is visible in a Firewall Event!

Let’s say you want to find all the requests originating from a specific ISP or country where your Firewall Rules issued a JavaScript challenge. There are two different ways to do this in the UI.

Firstly, when in the detail view, you can create an include or exclude filter for that field value.

Secondly, you can create a freeform filter using the “+ Add Filter” button at the top, or edit one of the already filtered fields:

As illustrated above, with our WAF Managed Rules enabled in log only, we can see all the rules which would have triggered if this was a legitimate attack. This allows you to confirm that your configuration is working as expected.

In our old Firewall Event Log, to find an event, users had to traverse through many pages to find Events from a specific date. The last major change we have added is the capability to select a time window to view events between two points in time over the last 2 weeks. In the time selection window, Free and Pro customers can choose a 24 hour time window and our Business customers can view up to 72 hours.

We need your help! Please feel free to leave any feedback on our Community forums, or open a Support ticket with any problems you find. Your feedback is critical to our product improvement process, and we look forward to hearing from you.

We have reorganised our features into meaningful pages: Events, Firewall Rules, Managed Rules, Tools, and Settings. Our customers will see an Overview tab, which contains our new Firewall Analytics, detailed below.

All the features you know and love are still available, and can be found in one of the four new tabs. Here is a breakdown of their new locations.

If the new sub navigation has not appeared, you may need to re-login to the dashboard or clear your browser’s cookies.

Insights into security events are critical for monitoring the health of your web applications. Furthermore, distinguishing between actual threats from false positives is essential for maintaining an optimal security configuration. Today, we are very pleased to announce our new Firewall Analytics which will help our Enterprise customers get detailed insights into firewall events, helping them to tailor their security configurations more effectively

Our new Firewall Analytics now enables our Enterprise customers to:

• visualise and analyse Firewall Events in one place to better understand their threat landscape

• identify, mitigate, and review attacks more effectively

After speaking with many of our customers, we learned a lot about their processes to identify and analyse attacks and the kinds of insights they needed to improve these processes. We then translated these learnings into useful features and charts that would help answer some of the most common questions such as ‘What kinds of security events occurred in a certain time frame?’ and ‘What caused a spike in a certain type of security event?’.  

Firewall Analytics and Firewall Configuration can be found together in the Firewall tab. A tight feedback loop between Firewall configuration and the resulting events allow for rapid iteration, ideal for security-focused teams.

To best demonstrate the power of Firewall Analytics, here’s a workflow that would answer a popular question our customers ask: “Why did I have a spike in threats?”. In the screenshot below, we can see a set of activity which triggered a number of ‘Blocks’ events:

To minimize the possibility of polluting our TopN statistics with event types other than ‘Block’ and get the most accurate diagnostic information, we will need to filter down to just ‘Block’ actions.

Now that only Block events are displayed, checking the Service Breakdowns will help us to identify which of our Firewall features was triggered.

From the Events breakdown, we can see that the Block events were triggered by a Country Block configured within Access Rules. Digging deeper and looking at our TopN breakdowns, we start to get a much more granular understanding of which Networks, IPs, User-Agents, Paths etc, were targeted.

Looking at our TopN breakdowns, we start to get a much more granular understanding of which Networks, IPs, User-Agents, Paths etc, were targeted.

From here, we can see that there are two specific IP addresses which were targeting my application to “/”.

To get the most detailed information, we can drill down further in the refreshed Firewall Event log, now controlled inline.

Whilst these TopNs and filters are great for clearly identifiable threats, they can also help identify false positives. Using the power of Cloudflare’s filters, it is possible to add a user-defined filter, which can be a RayID, User-Agent or IP address.

This is just one example of how the new Firewall Analytics can help expedite the process of identifying and mitigating threats. Firewall Analytics is now live for all Enterprise customers. Let us know your feedback by reaching out to your Enterprise Account Team.

Firewall Rules are one of the best security features we released this year and have been an overwhelming success. Customers have been using Firewall Rules to solve interesting security related use cases; for example, advanced hotlink protection, restricting access to embargoed content (e.g. productId=1234), locking down sensitive API endpoints, and more.

One of the biggest pieces of feedback from the Cloudflare community, Twitter, and via customer support, has been around the order in which rules are actioned. By default, Firewall Rules have a default precedence, based on the actions set on the rule:

If two or more rules match a request, but have different actions, the above precedence will take effect. However, what happens if you've got a bad actor who needs to be blocked from your API, and you have other specific allow or challenge rules already created for their originating ASN or a perhaps one of your URLs? Once a Firewall Rule is matched, it will not continue processing other rule, unless you are using the Log action. Without a method of overriding the default precedence, you cannot easily achieve what's needed.

Today, we’re launching the ability for customers to change the ordering of their rules. The team at Cloudflare had a very long discussion about whether priority was the right solution, i.e. using an arbitrary number between 1 and 2,147,483,647 (int32) or whether customers should have a sequential list, and be able to drag and drop rules similarly to how Page Rules operates today.

After testing potential solutions with our users and learning about the wide range of use cases it was clear that we needed to offer customers the ability to choose.

In the Firewall Rules user interface, you should now have an additional button on the top right, shown here:

For customers managing a large number of rules, or predominantly using the API or Terraform for configuration, priority numbering is a great solution. Within Firewall Rules, as explained above, the default precedence is the final “conflict resolver”, providing a very useful way of grouping rules.

For example, one of the engineers behind Firewall Rules uses Priority to organise their rules into specific groups, e.g.

5000-9999 - Trusted IP addresses
10000-19999 - Blocking Rules for Bad Crawlers
20000-29999 - Blocking Rules for Abusive/Spam Users

Priority is an optional field on Rules and is available as an additional control to override the default precedence mentioned above. As this is the case, Cloudflare do not apply any default priority numbers on rules, and will be left blank.

Ordering is intuitive, being literally a drag and drop placement of rules in order of execution. See below for a quick demo of how straightforward the controls are:

There is currently a 200 rule limit with this method, so upon creating your 201st rule, you will be switched to Priority Numbering, automatically.

For more information on how Ordering and Priority Number operates, please visit our Firewall Rules documentation, found here.

Threat landscapes change every second. As attackers evolve, becoming more dynamic and devious, vulnerabilities materialize faster than engineers can patch their applications. Part of Cloudflare’s mission is to keep you and your applications safe. Today, Cloudflare is launching a new feature, giving customers what they have been requesting - fine-grained control over their incoming requests.

Cloudflare already offers a number of powerful firewall tools such as IP rules, CIDR rules, ASN rules, country rules, HTTP user-agent blocking, Zone Lockdown (for these URIs only allow traffic from those IPs), and our comprehensive managed rules within our WAF (Web Application Firewall). But sometimes, you need to combine the power of these to fully mitigate an attack, and to express a block rule that breaks the boundaries of the existing tools, to be able to “block traffic to this URI when the request comes from that IP and the user-agent matches one of these”.

© Stefano Kocka : Source Wikipedia

Common themes arose when we spoke to customers about their needs and also reviewed feature requests that our customer support team had seen, and we categorised the top pieces of feedback and feature requests into three core needs:

1. More flexibility to create a firewall rule that matches more than just a single attribute, like an IP address and User-Agent

2. Flexibility to not only exactly match an attribute, but also partially match it, through using a string or a pattern, for example User-Agent: *Firefox*

3. Complete self-service control through the UI and Cloudflare’s public API, even for the most complex firewall rules

The team worked together to investigate what a fresh approach to our firewall would look like, with one overarching mission being front and center: build a Swiss Army knife of firewalls for our customers. Our key objectives were to:

1. Provide a tool to give customers flexible and granular control of their traffic

2. Maintain a smooth and intuitive user-experience, something we thrive on delivering

3. Ensure it is accessible and usable by all of our customers, regardless of user skill or business size

Cloudflare’s new capability, Firewall Rules, provides customers the ability to control requests, in a flexible and intuitive way, inspired by the widely known Wireshark®  language. Configuration of rules can be done through not only our Dashboard and API, but also through Terraform (link here).

The Firewall Rules engine can be thought of as 2 components:

• Matching: define a filter that runs globally and precisely matches your traffic

• Action: declare the action Cloudflare should apply when the filter is matched

Simply put, when the filter matches, apply the action.

Cloudflare Firewall Rules gives customers access to properties of the HTTP request, including referer, user-agent, cookies, Cloudflare Threat Score (IP reputation score), and more.

All of the supported headers can be matched by many operators, including, a partial match (contains), complete string or integer match (equals), and for our Business and Enterprise customers, pattern matching (matches). Yes, you read that right, we now offer pattern matching using Regular Expressions, directly through the Dashboard and API!

The great thing about Firewall Rules is the flexibility for Cloudflare to field options; for example, Cloudflare’s Threat Intelligence, which drives our Security Level functionally on the Dashboard, will be an available field for customers. One of the most important fields Cloudflare is introducing is our cf.client.bot field, which verifies known good bots via reverse DNS. In our initial release, we provide customers access to the general classification of “Known Good Bots”. Details on the list of these bots can be found here. Cloudflare has historically allowlisted Google on behalf of our customers, and utilised Web Application Firewall rules, which are only available to Pro customers and above, to block spoofed crawlers. With Firewall Rules, all customers now have access to these protections. As Cloudflare has removed the allowlisting capability, it is important that customers include simply cf.client.bot in an Allowed rule, to avoid inadvertently blocking good crawlers which could affect your SEO and monitoring.

All of the standard Cloudflare actions such as JavaScript Challenge, Challenge and Block are available.

There is one new addition to the standard mitigation list, which is the allow action, which provides a customer the ability to create Rule to say “if this criteria is matched, stop processing further rules”.

Sure, here’s four cool examples that we see being used today. Advanced or nested rules are not supported in the Visual Rule Builder today. These are noted below each rule.                                                                                                            

Example 1 - Challenge all countries except GBSupported: Visual Builder, Expression EditorThis can be done using our IP Firewall but would require 150+ rules!

(ip.geoip.country ne "GB")

Example 2 - Advanced Hotlink ProtectionSupported: Visual Builder, Expression EditorCloudflare’s built-in hotlink protection can be restrictive for some customers as it does not provide abilities to bypass certain paths. This also can sometimes catch legitimate crawlers.

(http.request.method eq "GET" and http.referer ne ".example.com" and not http.user_agent matches "(googlebot|facebook)" and http.request.uri.path eq "/content/")

Example 3 - Blocking Clients with a Threat Score greater than 10 or Clients originating from an abusive network by AS Number, to my Login pageSupported: Expression EditorOne of the great things about Firewall Rules is that we have provided you access to cf.threat_score, which is what powers the Security Level within the dashboard today.

(http.request.uri.path eq "/login" and (cf.threat_score < 10 or ip.geoip.asnum eq 12345))

Example 4 - Zone Lockdown-like-Use case utilising Regular Expression, IP address CIDRs, Country Code and AS Numbers to protect authentication endpoints via both Wordpress website, and an API.Supported: Expression EditorZone Lockdown is a great tool; however, it is limited for some critical use cases. Here’s something quite crazy to demonstrate the flexibility:

((http.host eq "api.example.com" and http.request.uri.path eq "/api/v2/auth") or (http.host matches "^(www|store|blog)\.example.com" and http.request.uri.path contains "wp-login.php") or ip.geoip.country in {"CN" "TH" "US" "ID" "KR" "MY" "IT" "SG" "GB"} or ip.geoip.asnum in {12345 54321 11111}) and not ip.src in {11.22.33.0/24}
111

This is an awesome addition to the Firewall, as it provides our customers a way to choose between running a Positive Security policy (allow specific requests and deny everything else) or a Negative Security policy (block specific requests and allow everything else).

Cloudflare default for Firewall Rules is an implicit allow all. The great thing about this method of working is being able to block just the bad stuff. Whilst this is a very effective and efficient way of running a firewall, it causes a number of challenges. By letting all traffic through, your security operations have to be reactive when issues arise.

What the security industry has been pushing is a concept of "Zero Trust". Just as it sounds, Zero Trust means you trust nothing, and everything that comes through has to have some kind of justification. To create a "Zero Trust" security policy, you have to reverse the way your firewall default policy works, i.e. changing the last action from allow to block - aka. a positive security policy. Before today, this was not possible; however with Firewall Rules, now you can.

One of the biggest concerns about giving customers power, is delivering that power safely and effectively. The product design and UI engineering team worked through multiple iterations to create a powerful but approachable rule builder and editor. The team spent a number of months working through a number of iterations to create solid rule builder and a rule editor solution without cluttering or complicating the UI.

Pete Thomas, our Lead Designer on the new Firewall UI took us back to basics running paper prototyping sessions to test and discover how rules are built and managed.

Below is a photo of myself and Matthew Bullock, one of our London Solutions Engineers, going through the testing process.

Through the design process, we wanted to focus on why customers would need Firewall Rules. The results were simple, create proactive defensive rules, to secure an application, and reactive rules, to protect applications that were being attacked.

Within the Visual Rule Builder, we have provided customers an intuitive way to create Firewall Rules, whilst not restricting access to the core functionality. The future roadmap delivers more flexible grouping through the Visual Builder. However, we do have an option for more complex requirements or nested Firewall Rules. These can be created within the Rule Editor, which is based on our Wireshark®-inspired language that allows you to take expressions created in Wireshark and create Firewall Rules. David Kitchen, the Engineering Manager responsible for developing Firewall Rules will be writing a blog in the coming weeks detailing why we chose a Wireshark®-inspired DSL for our filter expressions. For a list of supported fields, head over to our documentation.  

A year ago, Cloudflare released Rate Limiting, and it is proving to be a hugely effective tool for customers to protect their web applications and APIs from all sorts of attacks, from “low and slow” DDoS attacks, through to bot-based attacks, such as credential stuffing and content scraping. We’re pleased about the success our customers are seeing with Rate Limiting and are excited to announce additional capabilities to give our customers further control.

There are times when you clearly know that traffic is malicious. In cases like this, our existing Block action is proving effective for our customers. But there are times when it is not the best option, and causes a negative user experience. Rather than risk a false negative, customers often want to challenge a client to ensure they are who they represent themselves to be, which is in most situations, human not a bot.

Firstly, to help customers more accurately identify the traffic, we are adding Cloudflare JavaScript Challenge, and Google reCAPTCHA (Challenge) mitigation actions to the UI and API for Pro and Business plans. The existing Block and Simulate actions still exist. As a reminder, to test any rule, deploying in Simulate means that you will not be charged for any requests. This is a great way to test your new rules to make sure they have been configured correctly.

Secondly, we’re making Rate Limiting more dynamically scalable. A new feature has been added which allows Rate Limiting to count on Origin Response Headers for Business and Enterprise customers. The way this feature works is by matching attributes which are returned by the Origin to Cloudflare.

One of the things that really drives our innovation is solving the real problems we hear from customers every day. With that, we wanted to provide some real world examples of these new capabilities in action.

Each of the use cases have Basic and Advanced implementation options. After some testing, we found that tiering rate limits is an extremely effective solution against repeat offenders.

Credential Stuffing Protection for Login Pages and APIs. The best way to build applications is to utilise the standardized Status Codes. For example, if I fail to authenticate against an endpoint or a website, I should receive a “401” or “403”. Generally speaking a user to a website will often get their password wrong three times before selecting the “I forgot my password” option. Most Credential Stuff bots will try thousands of times cycling through many usernames and password combinations to see what works.

Here are some example rate limits which you can configure to protect your application from credential stuffing.

Basic:Cloudflare offers a “Protect My Login” feature out the box. Enter the URL for your login page and Cloudflare will create a rule such that clients that attempt to log in more than 5 times in 5 minutes will be blocked for 15 minutes.

With the new Challenge capabilities of Rate Limiting, you can customize the response parameters for log in to more closely match the behavior pattern for bots you see on your site through a custom-built rule.

Logging in four times in one minute is hard - I type fast, but couldn’t even do this. If I’m seeing this pattern in my logs, it is likely a bot. I can now create a Rate Limiting rule based on the following criteria:

With this new rule, if someone tries to log in four times within a minute, they will be thrown a challenge. My regular human users will likely never hit it, but if they do - the challenge insures they can still access the site.

Advanced: And sometimes bots are just super persistent in their attacks. We can tier rules together to tackle repeat offenders. For example, instead of creating just a single rule, we can create a series of rules which can be tiered to protect against persistent threats:

With this type of tiering, any genuine users that are just having a hard time remembering their login details whilst also being extremely fast typers will not be fully blocked. Instead, they will first be given out automated JavaScript challenge followed by a traditional CAPTCHA if they hit the next limit. This is a much more user-friendly approach while still securing your login endpoints.

Our IP Firewall is a powerful feature to block problematic IP addresses from accessing your app. Particularly this is related to repeated abuse, or based on IP Reputation or Threat Intelligence feeds that are integrated at the origin level.

While the IP firewall is powerful, maintaining and managing a list of IP addresses which are currently being blocked can be cumbersome. It becomes more complicated if you want to allow blocked IP addresses to “age out” if bad behavior stops after a period of time. This often requires authoring and managing a script and multiple API calls to Cloudflare.

The new Rate Limiting Origin Headers feature makes this all so much easier. You can now configure your origin to respond with a Header to trigger a Rate-Limit. To make this happen, we need to generate a Header at the Origin, which is then added to the response to Cloudflare. As we are matching on a static header, we can set a severity level based on the content of the Header. For example, if it was a repeat offender, you could respond with High as the Header value, which could Block for a longer period.

Create a Rate Limiting rule based on the following criteria:

Once that Rate-Limit has been created, Cloudflare’s Rate-Limiting will then kick-in immediately when that Header is received.

Enumeration attacks are proving to be increasingly popular and pesky to mitigate. With enumeration attacks, attackers identify an expensive operation in your app and hammer at it to tie up resources and slow or crash your app. For example, an app that offers the ability to look up a user profile requires a database lookup to validate whether the user exists. In an enumeration attack, attackers will send a random set of characters to that endpoint in quick succession, causing the database to ground to a halt.

Rate Limiting to the rescue!

One of our customers was hit with a huge enumeration attack on their platform earlier this year, where the aggressors were trying to do exactly what we described above, in an attempt to overload their database platform. Their Rate Limiting configuration blocked over 100,000,000 bad requests during the 6-hour attack.

When a query is sent to the app, and the user is not found, the app serves a 404 (page not found). A very basic approach is to set a rate limit for 404s. If a user crosses a threshold of 404’s in a period of time, set the app to challenge the user to prove themselves to be a real person.

To catch repeat offenders, you can tier the tier Rate Limits:

With this type of tiered defense in place, it means that you can “caution” an offender with a JavaScript challenge or Challenge (Google Captcha), and then “block” them if they continue.

Increasingly, content owners are wrestling with content scraping - malicious bots copying copyrighted images or assets and redistributing or reusing them. For example, we work with an eCommerce store that uses copyrighted images and their images are appearing elsewhere on the web without their consent. Rate Limiting can help!

In their app, each page displays 4 copyrighted images, 1 which is actual size, and 3 which are thumbnails. By looking at logs and user patterns, they determined that most users, at a stretch, would never view more than 10–15 products in a minute, which would equate to 40–60 loads from the images store.

They chose to tier their Rate Limiting rules to prevent end users from getting unnecessarily blocked when they were browsing heavily. To block malicious attempts at content scraping can be quite simple, however it does require some forward planning. Placing the rate limit on the right URL is key to insure you are placing the rule on exactly what you are trying to protect and not the broader content. Here’s an example set of rate limits this customer set to protect their images:

As we can see here, rules 1 and 2 are counting based on the number of requests to each endpoint. Rule 3 is counting based on all hits to the image store, and if it gets above 75 requests, the user will be blocked for 4 hours. Finally, to avoid any enumeration or bots guessing image names and numbers, we are counting on 404 and 403s and challenging if we see unusual spikes.

We want to ensure you have the rules you need to secure your app. To do that, we are increasing the number of available rules for Pro and Business, for no additional charge.

• Pro plans increase from 3 to 10 rules

• Business plans increase from 3 to 15 rules

As always, Cloudflare only charges for good traffic - requests that are allowed through Rate Limiting, not blocked. For more information click here.

The Rate-Limiting feature can be enabled within the Firewall tab on the Dashboard, or by visiting: cloudflare.com/a/firewall

The answer to that is absolutely yes, awareness is at an all-time high. Awareness, however, does not always result in positive action. The fallacy which is often assumed is "surely, if I keep my software up to date with all the patches, that's more than enough to keep me safe?". It's true, keeping software up to date does defend against known vulnerabilities, but it's a very reactive stance. The more important part is protecting against the unknown.

Something every engineer will agree on is that security is hard, and maintaining systems is even harder. Patching or upgrading systems can lead to unforeseen outages or unexpected behaviour due to other fixes which may be applied. This, in most cases, can cause huge delays in the deployment of patches or upgrades, due to requiring either regression testing or deployment in a staging environment. Whilst processes are followed, and tests are done, systems are sat vulnerable, ready to be exploited if they are exposed to the internet.

Looking at the wider landscape, an increase in security research has created a surge of CVEs (Common Vulnerability and Exposures) being announced. This compounded by GDPR, NIST and other new data protection legislation, businesses are now forced to pay much more attention to security vulnerabilities that potentially could affect their software, and ultimately put them on the forever growing list of victims of data breaches.

Dissecting the Equifax tragedy, in testimony from the CEO, he mentions that the reason for the breach was that there was one single person within the organisation who was responsible for communicating the availability of the patch for Apache Struts, the software at the heart of the breach. The crucial lesson learned from Equifax is that we are all human, and that mistakes can happen, however having multiple people responsible for communicating and notifying teams about threats is crucial. In this case, the mistake almost destroyed one of the largest credit agencies in the world.

How could attacks and breaches like Equifax be avoided? First is about understanding how these attacks happen. There are some key attacks which are often the source of data exfiltration through vulnerable software.

• Remote Code Execution (RCE) - which is what was used in the Equifax Breach

• SQL Injection (SQLi), which is delivering an SQL statement hidden in a payload, accessing a backend database powering a website.

The Struts vulnerability, CVE-2017-5638, which is protected by rule 100054 in Cloudflare Specials, was quite simple. In a payload targeted at the web-server, a specific command could be executed which can be seen in the example below:

"(#context.setMemberAccess(#dm))))."
"(#cmd='touch /tmp/hacked')."
"(#iswin=(@java.lang.System@getProperty('os.name').toLowerCase().contains('win')))."
"(#cmds=(#iswin?{'cmd.exe','/c',#cmd}:{'/bin/bash','-c',#cmd}))."
"(#p=new java.lang.ProcessBuilder(#cmds))."

More critically however, further to this CVE, Apache Struts also announced another vulnerability earlier this year (CVE-2017-9805), which works by delivering a payload against the REST plugin combined with the Xstream handler, which provides an XML ingest capability. By delivering an specially crafted XML payload, a shell command can be embedded, and will be executed.

<next class="java.lang.ProcessBuilder">
   <command>
      "touch /tmp/hacked".
   </command>
   <redirectErrorStream>false</redirectErrorStream>
</next>

And the result from the test:

root@struts-demo:~$ ls /tmp
hacked
root@struts-demo:~$

In the last week, we have seen over 180,000 hits on our WAF rules protecting against Apache Struts across the Cloudflare network.

SQL Injection (SQLi) is an attempt to inject nefarious queries into a GET or POST dynamic variable, which is used to query a database. Cloudflare, on a day to day basis will see over 2.3m SQLi attempts on our network. Most commonly, we see SQLi attacks against Wordpress sites, as it is one of the biggest web applications used on Cloudflare today. Wordpress is used by some of the world's giants, like Sony Music, all the way down to "mom & pop" businesses. The challenge with being the leader in the space, is you then become a hot target. Looking at the CVE list as we near the close of 2017, there have been 41 vulnerabilities found in multiple versions of Wordpress which would force people to upgrade to the latest versions. To protect our customers, and buy them time to upgrade, Cloudflare works with a number of vendors to address vulnerabilities and then virtual-patching using our WAF to prevent these vulnerabilities being exploited.

The way a SQL injection works is by "breaking out" or malforming a query when a web application is needing data from a database. As an example, a Forgotten Password page has a single email input field, which will be used to validate whether the username exists, and if so, sends the user a “Forgotten Password” link. Below is a straightforward SQL query example, which could be used in a web application:

SELECT user, password FROM users WHERE user = 'john@smith';

Which results in:

+------------+------------------------------+
|    user   |           password           |
+------------+------------------------------+
| john@smith | $2y$10$h9XJRX.EBnGFrWQlnt... |
+------------+------------------------------+

Without the right query validation, an attacker could escape out of this query, and carry out some extremely malicious queries. For example, if an attacker was looking to takeover another user’s account, and an attacker found that the query validation was inadequate, he could escape the query, and UPDATE the username, which is an email address in this instance, to his own. This can simply be done by entering the query string below into the email input field, instead of an email address.

dontcare@bla.com’;UPDATE users SET user = ‘mr@robot’ WHERE user = ‘john@smith’;

Due to the lack of validation, the query which the web application sends to the database will be:

SELECT user, password FROM users WHERE user = 'dontcare@bla.com’;UPDATE users SET user = ‘mr@robot’ WHERE user = ‘john@smith’;

Now this has been updated, the attacker can now request a password reset using his own email address, gaining him access to the victim’s account.

+----------+------------------------------+
|  user   |           password           |
+----------+------------------------------+
| mr@robot | $2y$10$h9XJRX.EBnGFrWQlnt... |
+----------+------------------------------+

Many SQLi attacks are often on fields which are not often considered high risk, like an authentication form for example. To put the seriousness of SQLi attacks in perspective, in the last week, we have seen over 2.4 million matches.

The Cloudflare WAF is built to not only protect customers against SQLi and RCE based attacks, but also add protection against Cross Site Scripting (XSS) and a number of other known attacks. On an average week, just on our Cloudflare Specials WAF ruleset, we see over 138 million matches.

The next important part is communication and awareness; understanding what you have installed, what versions you are running, and most importantly, what announcements your vendor is making. Generally, most notifications are received via email, and are usually quite cumbersome to digest, regardless of their complexity, it is crucial to try and understand them.

And, finally, the last line of defense is to have protection in front of your application, which is where Cloudflare can help. At Cloudflare, Security is very core to our values, and was one of the foundation pillars we were founded upon. Even to this day, we are known as one of the most cost effective ways of being able to shore up your Web Applications with just our Pro Plan@$20/mo.