The StackPath WAF is designed to prevent malicious traffic from reaching your origin and prevent compromises with your app/website. When the WAF is doing its job, it's completely normal to see a variety of Security Events on your WAF Dashboard. Even though the StackPath WAF is highly accurate and highly automated, it is always possible for legitimate traffic to be blocked. This guide will show StackPath WAF customers how to troubleshoot legitimate user traffic that has been blocked from your website or app.
Not a StackPath Customer?
If you're not a StackPath customer but have been blocked by the StackPath WAF, you will need to contact the owner of the website you've been blocked from. The StackPath WAF is highly customizable and it is possible the site owner will need to adjust their WAF policies to allow your traffic.
Because StackPath customers are able to set and change their own custom configurations on the WAF, StackPath does not make changes to WAF Policies unless directly requested by the account owner of the website.
While Managing Your Website
If you or your developers receive one of the WAF's security screens while editing your website, the solution is usually very simple. First, check the CMS Policy in your WAF configuration. Enabling this policy for your CMS (Content Management System), like Wordpress, will force the WAF to ALLOW any successfully logged in admins for the duration of their session.
Don't see your CMS? Send your feedback to email@example.com. We'll be happy to consider adding it to the list!
If your CMS isn't present, or you don't have a CMS, StackPath allows you to whitelist individual IPs free of charge! Just go to the Firewall section from the Navigation bar, and add your IP or your developer's IP to the Allowed IPs list. This will permanently grant access through the WAF from the provided IP.
If you are a StackPath customer, and you have end-users reporting blocks from StackPath's WAF, these may have to be handled on a case-by-case basis, depending on the reasons for the block. You can usually follow this process:
- Get the Reference ID from the End-User, this will be displayed on almost all StackPath Security Pages
- Open the Site Configuration, select the Analytics option, and choose the WAF tab
- Search for your the Reference ID in the Event logs
- Check the Security Event(s)
From there, you will have to determine whether the user is displaying acceptable behavior to access your website, or if you would rather them stay blocked.
Example: Creating a Rule from a Security Event
So we have looked a security event to find something that is being blocked, but we want to allow it through, great - so what's next?
Checking the Event
Let's take an example event, shown below and work through how we might want to allow this request:
Here we see the key information about this block: (listed from Top to Bottom)
- Rule Name, Date and Action Taken
- HTTPS GET
- This tells us what domain the request was directed at, and what HTTP method. In this case, it was a GET request, over HTTPS, towards lmstest.stackpathsupport.com
- This tells us the specific path that was being requested, in this case, /wp-admin/bad-scripts.php
- Query String
- Tells us whether or not the request included a query string
- Client IP
- The IP from which the request originated
- The Country from which the request originated, determined by the IP Address and where it is registered
- User Agent
- The User-Agent that was passed on with the request. This gives us some useful information on the browser or crawler that was attempted to reach this URL
- Additional Information
- A few more pieces of information about the request including the Organization to whom the IP address belongs, the type of device, operating system, and client/browser type.
All of this information can be used in creating rules for the WAF that specifically allow or block requests. Let's create one!
Crafting the Custom Rule
In this example, let's say we know for certain that want requests from this specific Client IP to always be allowed to request the file in the event above.
Using the information from the security event, we want a rule that defines the following conditions:
- IF the URL is lmstest.stackpathsupport.com/wp-admin/bad-scripts.php
- AND the Client IP Equals 188.8.131.52
- THEN Allow the request
Let's take a look at how to achieve this in the StackPath portal:
- Navigate to the Custom Rules section and select Add WAF Rule
- Name the Rule, preferably something easy to remember
- Using the information from the Security event, add the conditions to the rule and select Save
Congratulations! This rule will now allow, any request from this IP to the file at lmstest.stackpathsupport.com/wp-admin/bad-sctripts.php.
This method of evaluating security events and creating rules as needed is at the core of the StackPath WAF workflow.
This is a very simple and straight forward rule, but each rule can have up to 5 conditions per-rule, and there are a whole host of things you can use to trigger and define these rules in order to tailor the WAF to your needs.
You can get a much more in-depth understanding of how WAF Rules work by checking out this article. (Link will open in a new tab)
Things to Keep in Mind
When looking to create custom rules, or even just looking into your Security Events, there are a few key questions to keep in mind:
- What type of action has the WAF Performed?
- Has the user made a lot of requests that were flagged?
Users with hundreds of requests that trigger a single rule are likely trying to spam your website and maybe considered malicious actors.
- What part of your website is the user trying to gain access to?
If the user is triggering a policy on a section of your website that they shouldn't access, don't let them through.
- Are there multiple users reporting problems?
If multiple users are reporting the same problem, it's a good idea to make changes to the WAF Policies to adjust the WAF's behavior to your desired Use-case
- Did I leave a rule too broad and create a possible attack vector?
Creating a rule to Allow traffic, as in the example above is a great tool. However, it is important to understand the implications of the rule. In the example above, we did not specify Method. Meaning the rule would allow both GET and POST requests to the path we defined. This may or may not be desirable behavior and additional conditions might need to be added to the rule to tighten it up. Remember - all of the information in a security event can be used in creating Custom WAF Rules.
Of course, if you have any questions about the StackPath WAF, Support is available 24/7 through ticket or live chat to help.