Introducing Application Shielding
Overview
Application Shielding is an opt-in product feature for all Webscale customers that allows a controlled isolation of the application servers in a customer’s cloud account from Internet traffic. We developed this feature in response to requests from a handful of Webscale customers who wanted to configure their application servers so that all traffic reaching their application is from the Webscale proxy servers. Application Shielding makes it possible to eliminate direct HTTP/HTTPS traffic to the application servers from the Internet unless they are explicitly allowed by firewall settings or whitelists. It forces all other traffic to be routed through the Webscale proxies, better insulating the application from malicious attacks.
Background
Webscale’s application shielding implementation utilizes the underlying cloud provider capabilities to filter the traffic hitting the application servers. It is a fully integrated solution that assimilates the differences in cloud providers. It presents a simple, unified control to end-users that makes it easier for them to enable this extra layer of protection for their servers.
While we intend the control of this feature to be simple, we expect any user attempting to enable or disable Application Shielding for their applications to have a basic understanding of networking and firewall concepts. This feature is currently only supported for the AWS and the Google Cloud providers, so to make use of this security feature, the application servers must be hosted in one of those two cloud provider accounts.
Using server blueprints, the Webscale Application Shield leverages Google Cloud firewalls or AWS security groups, depending on the cloud provider you use.
Firewalls and Security Groups
Firewalls in Google Cloud and security groups in AWS are fundamental networking resources in the cloud provider account that make the Application Shielding feature possible. Both firewalls and security groups provide a way for users to configure and control access to their application servers.Application Server Blueprints
Webscale orchestrates any auto-scaling of application servers as dictated by the demands placed on the application by Internet traffic. A fundamental aspect of this auto-scaling is what we refer to as server blueprints. Server blueprints allow a Webscale customer to specify the precise configuration used to create additional application servers when needed.
Prior to the release of the Application Shielding feature, server blueprints allowed users to specify only the server image (operating system and software), server placement (cloud provider region/zone), and the instance type (machine capabilities). This feature release enhances these capabilities to include additional cloud provider resources in the server blueprints, including things like network/VPC, subnet for both Google Cloud and AWS, network tags (Google Cloud only), and security groups (AWS only). These new features make it possible for a user to create server blueprints with networking attributes that allow access control to any servers created by the Webscale auto-scaling solution.
AWS Security Groups
AWS security groups allow users to create a set of ingress and egress rules to control traffic to servers that are associated with the security group. Security groups determine how traffic flows to and from servers in the network and all subnets of the network. Each AWS VPC (network) is associated with a security group. For more about AWS security groups, please see the AWS Security Group Rules Reference guide.
The Application Shielding feature manipulates the ingress rules on a user identified security group by adding/removing IP addresses or address blocks to put access rules into effect. Any rules added by the Webscale Application Shield to this security group are annotated with a specific description string: webscale-app-shielding-<n>, where n is an integer that grows with every new rule added by the system. When Application Shielding is disabled, all the ingress rules with such a description are removed by the system automatically.
Things to note:
- The security group that you configure for use with Application Shielding must already exist in the cloud provider account and the Webscale Application Shield must have access to modify the rules in the group.
- It is the responsibility of the user to make sure that the security group rules actually impact traffic to the application servers. To do this, ensure that you create the server blueprints as described above.
- Any rules that exist in the security group that include the description substring
webscale-app-shielding-<n>are subject to deletion by the Webscale product. Therefore, rules that you don’t want to be edited by the Webscale Application Shield must not include such a description.
Google Cloud Firewalls
Google Cloud firewalls provide the capability of allowing/restricting access to the application servers hosted in the Google Cloud account. Google Cloud firewalls are always associated with a network, and the firewall specification allows a user to specify which servers in the network are covered by the firewall rules. Accomplish this by setting a target property on the firewall. One way to specify these targets is by the creation of network tags (arbitrary strings). When servers in the network are created with the same tags, the firewall rules apply to them. For more about Google Cloud Firewalls, please see the Google Cloud Firewall rules overview.
The Application Shielding feature requires that a firewall is identified and selected by the user to shield application servers running in the Google Cloud infrastructure. The user must set the priority of this designated firewall lower than any other firewalls that are applied independently of Application Shielding. Webscale Application Shielding manipulates the specific firewall identified for Application Shielding and updates the rules as needed.
Things to note:
- For Application Shielding to work as expected, the user must not manually edit the firewall designated for Application Shielding. Any changes are liable to be overwritten by the Application Shield.
- The user has the responsibility to ensure the firewall defines its targets appropriately, so the application servers to be protected are indeed covered by the rules in the firewall.
Further reading
- Configuring Application Shielding
- Web Controls
- How to Block Countries from Accessing Your Site
- Editing the Allowlist
- Editing the Blocklist
Have questions not answered here? Please Contact Support to get more help.
Feedback
Was this page helpful?
Glad to hear it! Have any more feedback? Please share it here.
Sorry to hear that. Have any more feedback? Please share it here.