Web Application Firewall (WAF)

The Web Application Firewall settings can be found under the NETWORKING > FIREWALL tab as shown below.

On this page you will find two configuration tables as follows:

Firewall Access Control List (ACL)

The Firewall ACL is similar to those you may be familiar with on most firewall appliances or even software firewalls such as iptables. It allows you to configure ALLOW and DENY rules grouped on the destination IP, which is the cloud IP you publish your config/pack on.

Step one is to create a group based on that destination IP. First determine if the pack you have published uses an IPv4 or IPv6 address. Then click the ADD button on the toolbar as shown below to create your first group.

Create the group with the correct destination IP of your config/pack. Then give it a name for your own reference. We suggest using the same name as your config/pack.

Once you have created a group, expand it by clicking the black arrow icon at the left of the row, as shown below.

Once the row is clicked, it will reveal another table where you can begin adding your rules. Here you create the individual rules to allow or deny traffic.

NOTE: It is important to note that you do not need to block traffic to ports that you have not published. For example, if you have published a web application on port 80 and 443, you do not need to use the Firewall Access Control List to block all of the remaining ports. They are blocked by default. You use this to further enhance protection. For example, to block ICMP traffic to your cloud IP entirely (which is allowed by default).

Adding your first entry

To add your first entry, click the ADD button on the toolbar. That will open a dialog window as shown below.

In this dialog you are presented with a number of configuration options as follows:

Enabled: This toggles whether the rule will be active or not. Generally when creating a rule you wish for it to be active. This is here as a convenience should you wish to temporarily remove a rule or deactivate it later without having to remove it entirely.

Action: This determines what action is taken on the firewall. Allow will let traffic through and will override a deny rule. Deny will block traffic. It does NOT override an allow rule since Deny rules are processed last.

Source IP Operation: This defaults to ALL, which means all source/origin IP addresses will be affected. The other options are “Equal” or “Does Not Equal”. If you choose either of these two options, you will be presented with text boxes to enter a Source IP Low and a Source IP High. These are simply starting and ending IP addresses. If, for example, you only want to allow or deny one IP, you would enter the same IP in both boxes indicating that the starting and ending range is the same.

Protocol: This defaults to ALL, which means all protocols. You can narrow the rule down to a specific protocol as well, including TCP, UDP and ICMP. If you choose TCP or UDP you will be given options to choose a source or destination port number. If you choose ICMP, you will be given the options to choose the ICMP Message Type and the ICMP Message Code. Hint: Ping (ICMP echo) is Type 8. Message code would be set to All.

Here are some example rule configurations:

To deny ICMP to your cloud IP from all IP addresses:

To deny all traffic from a specific IP address:

To deny all traffic to TCP port 3306 from all source IP addresses:

NOTE: Within a minute or two after creating an ACL entry, it will take effect. As a result, if you are creating a grouping of allow rules to override a Deny All rule, we highly recommend creating all of your Allow rules before creating your Deny All rule. If you create your Deny All rule first, then all traffic will be blocked until you complete the Allow rules.

Once you have created your first entry, you will see that it populates into the table, as shown below in our example.

To make a change to any of your entries, click on the row in the table once so it is highlighted. Then click on the EDIT button on the toolbar. This will open the same dialog you used during the create process. Now you can make modifications as needed and save your changes.

To delete an entry, simply click on it once in the table and then select the DELETE button from the toolbar. It will be removed and the platform will update in 2 minutes or less.

Web Application Firewall (WAF)

The WAF allows you to create policies to inspect traffic all the way up to layer 7. You can block URLs or directories, look for credit card numbers escaping your network, block SQL Injection attempts and more.

To begin, you need to create a WAF Profile. To do that, click the ADD button on the toolbar in the table as shown below:

Give your profile a name that describes the functionality you are going to deploy. We do not suggest naming it the same as your config/pack because WAF profiles can be applied to multiple configs. Don’t worry, it is easy to change the name later.

Once you’ve created your profile, you’ll see it in the table below. Double-click it, or select it once and choose EDIT from the toolbar. This will open up a new window as shown below:

As you can see, there are numerous options available. To engage an option, you simply check the BLOCK checkbox beside the name. But before you do so, you may wish to click the MORE link beside the profile items you’re interested in to configure the advanced settings. Some items will work out-of-the-box without much configuration to offer basic protection. Some require advanced configuration.

Example: Buffer Overflow advanced settings:

For Buffer Overflow, there are very few settings, and they are configured by default. So this rule generally requires little modification to begin protecting your web application.

Other items, like SQL Injection, may require a little more configuration to ensure it works properly with your application. For many, exceptions are generally required and we highly recommend testing before engaging these features in production.

Once you have finished implementing a profile, unlike the Firewall ACL, it needs to be connected to your config/pack before it will begin providing protection. To do that, click on the CONFIGURATION BUILDER tab and choose your config/pack from the left hand side. This should open it up to the main configuration page which shows the three icons at the top (firewall, load balancing, acceleration) as shown below.

Click on the Firewall button as shown above to open up the configuration dialog as follows:

To attach the profile you created, click the ADD button on the toolbar. This will open a window as follows:

In this window you can now choose the Profile you previously created from the drop-down menu. You can also assign a name and choose what traffic you wish to apply this to. To apply it to all traffic, simply select the checkbox to “Apply this profile to all traffic”. To apply it to specific traffic, click the ADD button below the expression box to create your own custom rules. For example, maybe you would want it to only filter traffic to the directory “/crm”.

You may create multiple expressions to filter traffic selectively as desired.

Once complete, click the save button. This activates the policy and you will return to the first window showing the policy and the priority. You may add multiple policies to enable multiple WAF Profiles created in the firewall tab, and to selectively apply them to different portions of your web application.

Search our Knowledge Base

About Total Uptime Technologies

Total Uptime Technologies, LLC is a privately held provider of Cloud solutions designed to help organizations achieve high availability in a demanding online world. Our multi-datacenter, multi-country Cloud platform easily delivers on our uptime promise because it has been engineered from the ground up to be fast, flexible and resilient.

While other organizations were busy renaming their legacy solutions as “Cloud” and dressing them up to take advantage of the latest hype, Total Uptime Technologies was engineering a true Cloud Platform that was multi-datacenter at its core. In our mind, Cloud meant resilient, and resilient meant that we had to design an application that could span infrastructure at different datacenters in different geographies – continents apart. Only then would we be content with calling it “Cloud”.