How WebShield works

Pan-Net WebShield is a cloud-based Web Application Firewall acting as a filtering element between your application and potential attackers. The traffic is routed to the WebShield by a simple DNS change on customer's side.

WebShield inspects the traffic coming to your application and automatically drops all traffic with malicious patterns based on customer's configuration. Pan-Net engineers take care of keeping the WebShield ruleset up to date and effective.

Technical Details section provides more information about WebShield architecture.

3 easy steps to onboard

  1. Log in and request your WebShield Instance.
  2. Let Pan-Net manage your TLS certificates by a simple DNS change on your side.
  3. Point your application FQDN to your unique WebShield Instance FQDN.

Portal will notify you throughout the whole provisioning process.

WebShield Instance provisioning walkthrough in 5 minutes

Frequently Asked Questions

What is the WebShield Instance?
WebShield Instance is the atomic object provisioned by the customer and represents the service as such. Behind the curtains it consists of multiple autoscalable microservices and WAF rulesets, all tighted together as one unit.

What is the WebShield Instance FQDN?
Each WebShield Instance is spawned with its own unique FQDN (e.g. to which you will point (CNAME) your primary application FQDN.

Are there any prerequisites to provision WebShield?
There are no prerequisites. Your web application can be hosted anywhere on Internet and we implicitly assume you can manage DNS records of the onboarded application. It is recommended to lower DNS TTL of your primary application FQDN as much as possible prior WebShield privisioning to experience swift onboarding.

How do I verify the status of the WebShield provisioning process?
Portal provides you visual and textual guidance regarding actual status of the provisioning and deprovisioing process and informs about the next steps and actions needed to take.

What is the BM (Blocking Mode) and why my Instance is not blocking any malicious traffic?
Each new WebShield Instances is spawned with deactivated Blocking Mode (BM). It is done this way not to break application availability prior testing suitable rulesets. Once new WebShield Instance is deployed, activate BM within the Portal and also select the rulesets based on your preference and type of your application.

How can I test the Blocking Mode?
To test the WebShield Blocking Mode functionality you can request: "https://YOUR-APPLICATION-FQDN/webshieldtest" URL from your browser. It is needed to activate Blocking Mode on your Instance first.

How can I update my existing WebShield Instance?
The update is possible directly from the Instances page of the Portal. You can activate or deactivate Blocking Mode and select rulesets to be applied anytime. The update is applied within approximately 2 minutes after submitting the change.

How is Rate limiting protecting me?
Rate limiting is configured per WebShield Instance by the user and is active in both states of the Blocking Mode. Rate limiting regulates permitted HTTP requests per second per source IP address. On top of it WebShield infrastructure uses global DDoS protection mechanisms for large-scale attacks.

What if my application (or Load balancer in front) changes IP address or FQDN?
In this case you have to provision a new WebShield Instance. You can run in parallel the new and the old Instance and point your application FQDN to the new WebShield Instance based on your preference.

Who maintains the WebShield rulesets?
WebShield ruleset is being maintained by Pan-Net security experts. Any additional and ad-hoc rulesets or customer issues can be requested via

What if my application FQDN uses multiple CNAME levels?
WebShield infrastructure will proxy requests to the first value resolved from your primary application FQDN defined when requesting WebShield Instance (either first level CNAME or the IP address of your backend directly).

What if my application is hosted on multiple IPs (DNS balancing usecase)?
WebShield proxies requests to a single target. It can be a single IP address, single A record or single CNAME record. In case your application is listening on multiple IP addresses, WebShield will detect it and use just one of the backend IPs permanently. To avoid this behaviour, please deploy Load balancer in front or apply DNS balancing for your backend, i.e. CNAME your primary application FQDN to the secondary FQDN doing the DNS balancing.

Which port is the WebShield Instance listening on?
WebShield Instance is listening on 443/tcp using HTTPS only.

What if my backend application is HTTP only?
Protected application can be hosted on any port and both HTTP and HTTPS protocols are supported. WebShield can direct traffic to any backend port where your application is listening to. However customer facing WebShield Instance's port will always be 443/tcp.

My FQDN is the same as the DNS zone name itself. Is this supported usecase?
Yes it is. Instead of CNAME you will be asked to ALIAS your application FQDN to the WebShield Instance FQDN.

My WebShield Instance is not blocking any traffic.
Please check DNS TTL values of your application FQDN. Higher values might cause longer propagation of applied changes. Check also if Blocking Mode is activated for your WebShield Instance.

Should I expect downtime of my application when onboarding to WebShield?
In principle, no. However, some DNS providers do not allow to modify DNS record types of customer's records without first deleting the original records.

How to fix Wordpress application not acting as expected behind the WebShield?
Please review WP_SITEURL in your wp-config.php and consider using plugin.

How the payment process works?
DT Pan-Net never stores payment card details. The whole payment processing is managed by a trusted PCI Level 1 Service Provider. Each WebShield Instance can be paid by a different payment card. In case you want to use different payment card for already existing WebShield Instances you can apply global update in Account section. All subsequent recurring payments will use a new card from that time onwards.

How can I get invoices for paid subscription?
In the Account & Payment section in the WebShield Portal you can find a link to redirect to the Payment Management Portal. Billing History there provides a link to download all billing receipts as well as invoices.
Tips & Tricks

  • Microservices responsible for updating the WebShield Instance are triggered every 1-2 minutes and apply all changes as defined in the Portal in a given time. Repetitive changes of the Instance settings (Blocking Mode activation/deactivation & ruleset changes) do not cause any risk and change is applied only when the updating microservice runs.
  • You can anytime revert your application DNS record back to your original backend IP address or CNAME record and let your users bypass the WebShield Instance immediately. This action does not deprovision WebShield Instance and DNS records can be changed back and forth.
  • Keep TTL of your application DNS record and magic _acme-challenge DNS record as low as possible to avoid unexpected behavior.
  • For DNS servers using CAA (Certification Authority Authorization) please allow CA to issue certificates for your parent zone by creating appropriate CAA record.
  • Technical Details

    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.

    TLS certificates
    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.

    End-to-end encryption
    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 vulnerabilities.
    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

    Secure payments
    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.