WebShield infrastructure is hosted in the Pan-Net Cloud and all components are containerized. We largely follow principles of Continuous Integration and Continuous Deployment
and Infrastructure as a Code which helps us easy provisioning, migrations and potentially distaster recovery. WebShield components run in multiple Data centers within European Union.
WebShield Instances run as orchestrated Docker containers with autoscaling capability. This helps us to provision every WebShield Instance rapidly and with ease.
Containers are updated in rolling restart way to avoid service downtimes during upgrade procedures and reconfigurations.
WebShield Instances run as Kubernetes Pods surrounded by a large set of additional Kubernetes objects needed for reliable, scalable and autohealing operation.
Infrastructure is supported by additional microservices which monitor and coordinate provisioning process of individual WebShield Instances.
Microservices run as decoupled single-purpose entites - their failure does not affect any other microservice and are autohealed when problem is detected.
WebShield issues TLS certificates by default for every WebShield Instance. We are using LetsEncrypt as the Certificate Authority.
The whole TLS certificate lifecycle from initial issuance to automated certificate renewal is managed by Pan-Net. Certificates issued for your application are valid for 90 days
and renewal procedure start 30 days before certificate expiration.
It means that all WebShield TLS certificates are renewed approximately every 2 months which minimizes impact of most of PKI related attacks.
To enable Pan-Net manage TLS certificates for your domain, you have to create a "magic" _acme-challenge record in your DNS zone.
This record has to be present in the DNS zone file throughout the whole lifetime of your WebShield Instance to enable us not only issue the certificate but also renew it.
"Magic" _acme-challenge records allow Pan-Net to prove to the Certificate Authority that we are allowed to manage certificates for your FQDN.
This delegation applies ONLY for the individual FQDN defined within the "magic" record.
Communication between the browser and WebShield Instance is ALWAYS encrypted also when backend applications run HTTP only.
Due to the complexity of the infrastructure and multiple components forwarding the packets from browser to the WebShield Instance we ensure that
HTTPS session is terminated on the WebShield Kubernetes Pod directly by using "SSL Passthrough" on all balancing components on the way.
This approach avoids intercepting the traffic even within Pan-Net internal network.
After inspecting the traffic by WebShield we forward the traffic to the backend application using the protocol defined by the customer when requesting the Instance.
Web Application Firewall
WebShield acts as a full proxy which inspects all the traffic towards the protected application covering
OWASP TOP 10
Every newly provisioned WebShield Instance is delivered with Blocking Mode deactivated, i.e. WebShield Instance still inspects and logs the traffic,
however does not block it. It is done this way to enable customer carefully observe impact of the activated WebShield Instance and added rulesets.
Activating Blocking Mode automatically deploys default ruleset "Essential" which is safe for all application. Additional rulesets can be selected based on the customer's preference.
There are hundreds of rules grouped to multiple ruleset groups.
Blocking Mode as well as rulesets can be reconfigured anytime without any impact on service availability due to rolling updates of the WebShield Instance.
Rulesets can be tightened by configuring Ruleset Strictness, potentially resulting in more false positives.
The whole process of configuring and testing the rulesets can be supported by WebShield team as part of the Premium Plan. Premium Plan also provides an option to get custom and application-specific rules on-demand.
Customer side hardening and optimization
We natively provide encryption from the client's browser to the WebShield Instance. We strongly recommend that your application natively runs HTTPS to ensure
encryption also for the second part of the channel, i.e. from the WebShield Instance to your backend application.
We recommend to apply firewalling rules in front of your application to allow only AS1902
IP ranges to reach your backend.
We recommend to apply standard OS-level and application level hardening, e.g. to serving your application content only when reached via FQDN (not via server IP address).
In case you need any support, do not hesitate to contact us at firstname.lastname@example.org.
We do not store payment details within the WebShield infrastructure and the whole payment processing is managed by the partner certified as a PCI Level 1 Service Provider.