Deploy WAAS In-Line for Hosts
Table of Contents
Expand all | Collapse all
-
- Getting started
- System Requirements
- Cluster Context
-
- Prisma Cloud Container Images
- Kubernetes
- Deploy the Prisma Cloud Console on Amazon ECS
- Console on Fargate
- Onebox
- Alibaba Cloud Container Service for Kubernetes (ACK)
- Azure Container Service (ACS) with Kubernetes
- Azure Kubernetes Service (AKS)
- Amazon Elastic Kubernetes Service (EKS)
- IBM Kubernetes Service (IKS)
- OpenShift v4
-
- Defender Types
- Manage your Defenders
- Redeploy Defenders
- Uninstall Defenders
-
- Deploy Orchestrator Defenders on Amazon ECS
- Automatically Install Container Defender in a Cluster
- Deploy Prisma Cloud Defender from the GCP Marketplace
- Deploy Defenders as DaemonSets
- VMware Tanzu Application Service (TAS) Defender
- Deploy Defender on Google Kubernetes Engine (GKE)
- Google Kubernetes Engine (GKE) Autopilot
- Deploy Defender on OpenShift v4
-
- Agentless Scanning Modes
-
- Onboard AWS Accounts for Agentless Scanning
- Onboard Azure Accounts for Agentless Scanning
- Configure Agentless Scanning for Azure
- Onboard GCP Accounts for Agentless Scanning
- Configure Agentless Scanning for GCP
- Onboard Oracle Cloud Infrastructure (OCI) Accounts for Agentless Scanning
- Configure Agentless Scanning for Oracle Cloud Infrastructure (OCI)
- Agentless Scanning Results
-
- Rule ordering and pattern matching
- Backup and restore
- Custom feeds
- Configuring Prisma Cloud proxy settings
- Prisma Cloud Compute certificates
- Configure scanning
- User certificate validity period
- Enable HTTP access to Console
- Set different paths for Defender and Console (with DaemonSets)
- Authenticate to Console with Certificates
- Configure custom certs from a predefined directory
- Customize terminal output
- Collections
- Tags
- Logon settings
- Reconfigure Prisma Cloud
- Subject Alternative Names
- WildFire Settings
- Log Scrubbing
- Clustered-DB
- Permissions by feature
-
- Logging into Prisma Cloud
- Integrating with an IdP
- Integrate with Active Directory
- Integrate with OpenLDAP
- Integrate Prisma Cloud with Open ID Connect
- Integrate with Okta via SAML 2.0 federation
- Integrate Google G Suite via SAML 2.0 federation
- Integrate with Azure Active Directory via SAML 2.0 federation
- Integrate with PingFederate via SAML 2.0 federation
- Integrate with Windows Server 2016 & 2012r2 Active Directory Federation Services (ADFS) via SAML 2.0 federation
- Integrate Prisma Cloud with GitHub
- Integrate Prisma Cloud with OpenShift
- Non-default UPN suffixes
- Compute user roles
- Assign roles
-
- Prisma Cloud Vulnerability Feed
- Scanning Procedure
- Vulnerability Management Policies
- Vulnerability Scan Reports
- Scan Images for Custom Vulnerabilities
- Base images
- Vulnerability Explorer
- CVSS scoring
- CVE Viewer
-
- Configure Registry Scans
- Scan images in Alibaba Cloud Container Registry
- Scan images in Amazon Elastic Container Registry (ECR)
- Scan images in Azure Container Registry (ACR)
- Scan images in Docker Registry v2 (including Docker Hub)
- Scan Images in GitLab Container Registry
- Scan images in Google Artifact Registry
- Scan images in Google Container Registry (GCR)
- Scan images in Harbor Registry
- Scan images in IBM Cloud Container Registry
- Scan Images in JFrog Artifactory Docker Registry
- Scan Images in Sonatype Nexus Registry
- Scan images in OpenShift integrated Docker registry
- Scan Images in CoreOS Quay Registry
- Trigger registry scans with Webhooks
- Configure VM image scanning
- Configure code repository scanning
- Malware scanning
- Windows container image scanning
- Serverless Functions Scanning
- VMware Tanzu Blobstore Scanning
- Scan App-Embedded workloads
- Troubleshoot Vulnerability Detection
-
- Compliance Explorer
- Enforce compliance checks
- CIS Benchmarks
- Prisma Cloud Labs compliance checks
- Serverless functions compliance checks
- Windows compliance checks
- DISA STIG compliance checks
- Custom compliance checks
- Trusted images
- Host scanning
- VM image scanning
- App-Embedded scanning
- Detect secrets
- OSS license management
-
- Alert mechanism
- AWS Security Hub
- Cortex XDR alerts
- Cortex XSOAR alerts
- Email alerts
- Google Cloud Pub/Sub
- Google Cloud Security Command Center
- IBM Cloud Security Advisor
- JIRA Alerts
- PagerDuty alerts
- ServiceNow alerts for Security Incident Response
- ServiceNow alerts for Vulnerability Response
- Slack Alerts
- Splunk Alerts
- Webhook alerts
- API
Deploy WAAS In-Line for Hosts
To deploy WAAS to protect a host running a non-containerized web application, create a new rule, specify the host(s) where the application runs, define protected HTTP endpoints, and select protections.
Create a WAAS In-Line rule for Hosts
- Open Console, and go toDefend > WAAS > {Container|Host} > In-Line.
- SelectAdd rule.
- Enter aRule Name
- EnterNotes(Optional) for describing the rule.
- SelectOperating system.
- If necessary, adjust theProxy timeoutThe maximum duration in seconds for reading the entire request, including the body. A 500 error response is returned if a request is not read within the timeout period. For applications dealing with large files, adjusting the proxy timeout is necessary.
- Choose the ruleScopeby specifying the resource collection(s) to which it applies.Collections define a combination of hosts to which WAAS should attach itself to protect the web application:Applying a rule to all hosts/images using a wild card (*) is invalid and a waste of resources. WAAS only needs to be applied to hosts that run applications that transmit and receive HTTP/HTTPS traffic.
- (Optional) EnableAPI endpoint discoveryWhen enabled, the Defender inspects the API traffic to and from the protected API. Defender reports a list of the endpoints and their resource path inCompute > Monitor > WAAS > API discovery.
- (Optional) EnableAutomatically detect portsfor an endpoint to deploy WAAS protection on ports identified in the unprotected web apps report inMonitor > WAAS > Unprotected web appsfor each of the workloads in the rule scope.As an additional measure, you can specify additional ports by specifying them in the protected HTTP endpoints within each app to also include the ports that may not have been detected automatically.By enabling bothAutomatically detect portsandAPI endpoint discovery, you can monitor your API endpoints and ports without having to add an application and without configuring any policies.Automatically detect portsis not available for Windows Operating System.
- Savethe rule.
Add an App (policy) to the rule
- Select a WAAS rule to add an App in.
- SelectAdd app.
- In theApp Definitiontab, enter anApp ID.The combination ofRule nameandApp IDmust be unique across In-Line and Out-Of-Band WAAS policies for Containers, Hosts, and App-Embedded.If you have a Swagger or OpenAPI file, clickImport, and select the file to load.If you do not have a Swagger or OpenAPI file, manually define each endpoint by specifying the host, port, and path.
- InEndpoint Setup, clickAdd Endpoint.Specify endpoint in your web application that should be protected. Each defined application can have multiple protected endpoints.
- EnterHTTP host(optional, wildcards supported).HTTP hostnames are specified in the form of [hostname]:[external port].The external port is defined as the TCP port on the host, listening for inbound HTTP traffic. If the value of the external port is "80" for non-TLS endpoints or "443" for TLS endpoints it can be omitted. Examples: "*.example.site", "docs.example.site", "www.example.site:8080", etc.
- EnterApp portsas the internal port your app listens on.(You can skip to enter App ports, if you selectedAutomatically detect portswhile creating the rule).WhenAutomatically detect portsis selected, any ports specified in a protected endpoint definition will be appended to the list of protected ports. Specify the TCP port listening for inbound HTTP traffic.If your application usesTLSorgRPC, you must specify a port number.
- EnterBase path(optional, wildcards supported):Base path for WAAS to match when applying protections.Examples: "/admin", "/" (root path only), "/*", /v2/api", etc.
- EnterWAAS port (only required for Windows, App-Embedded or when using "Remote host" option)as the external port WAAS listens on. The external port is the TCP port for the App-Embedded Defender to listen on for inbound HTTP traffic.Protecting Linux-based hosts does not require specifying a since WAAS listens on the same port as the protected application. Because Windows has its own internal traffic routing mechanisms, WAAS and the protected application cannot use the same . Consequently, when protecting Windows-based hosts the should be set to the port end-users send requests to, and the should be set to adifferentport on which the protected application will listen and to which WAAS will forward traffic.
- If your application uses TLS, setTLStoOn.You can select the TLS protocol (1.0, 1.1, 1.2, and 1.3 for WAAS In-Line, and 1.0, 1.1, and 1.2 for WAAS Out-Of-Band) to protect the API endpoint and enter the TLS certificate in PEM format.Limitations
- TLS connections using extended_master_secret(23) in the negotiation are not supported as part of this feature.
- DHKE is not supported due to a lack of information required to generate the encryption key.
- Out-of-Band does not support HTTP/2 protocol.
- TLS inspection for Out-of-Band WAAS is not supported on earlier versions of Console and Defender.
- If your application uses HTTP/2, setHTTP/2toOn.WAAS must be able to decrypt and inspect HTTPS traffic to function properly.
- If your application uses gRPC, setgRPCtoOn.
- You can selectResponse headersto add or override HTTP response headers in responses sent from the protected application.
- SelectCreate response header.
- To facilitate inspection, after creating all endpoints, clickView TLS settingsin the endpoint setup menu.WAAS TLS settings:
- Certificate- Copy and paste your server’s certificate and private key into the certificate input box (e.g., cat server-cert.pem server-key > certs.pem).
- Minimum TLS version- A minimum version of TLS can be enforced by WAAS In-Line to prevent downgrading attacks (the default value is TLS 1.2).
- HSTS- The HTTP Strict-Transport-Security (HSTS) response header lets web servers tell browsers to use HTTPS only, not HTTP. When enabled, WAAS would add the HSTS response header to all HTTPS server responses (if it is not already present) with the preconfigured directives - max-age, includeSubDomains, and preload.
- max-age=<expire-time> - Time, in seconds, that the browser should remember that a site is only to be accessed using HTTPS.
- includeSubDomains (optional) - If selected, HSTS protection applies to all the site’s subdomains as well.
- If you application requires API protection, for each path define the allowed methods and the parameters.
- Continue toApp Firewallsettings, select the protections to enable and assign them with WAAS Actions.
- Configure the DoS protection thresholds.
- Continue toAccess Controltab and select access controls to enable.
- Select the bot protections you want to enable.
- Select the required Custom rules.
- Proceed to Advanced settings for more WAAS controls.
- SelectSave.
- TheRule Overviewpage shows all the WAAS rules created.Select a rule to display theRule Resources, and for each application a list of protected endpoints and the protections enabled for each endpoint are displayed.
- Test protected endpoint using the following sanity tests.
- Go toMonitor > Events, click onWAAS for containers/hosts/App-Embedded, and observe the events generated.For more information, see the WAAS analytics help page