Create a proxy

Threat Protection by Mastercard (formerly known as Baffin Bay Threat Protection) is designed to automatically detect and mitigate threats targeting your Internet-facing assets. This includes various Denial Of Service attacks, including volumetric DDoS, as well as application level attacks, and other malicious bad actors.

The Threat Protection service can be deployed in several different configurations, depending on your infrastructure and specific security needs. A single IP address located in your data center or cloud provider can be protected in proxy mode (HTTP Proxy or L4 Proxy) via our API.

The Threat Protection Proxy service (L4 or HTTP Proxy) is designed to protect a site, API, or any Internet-facing asset (single IP address / CNAME), located in your data center or cloud provider, against incoming threats.

Common prerequisites

For both Layer 4 and HTTP proxy configurations, you will need:

• IP/CNAME: The destination IP(s) address/CNAME of the asset to be protected. These are the IP addresses that the Threat Protection proxy will route clean traffic to.
• Port: The destination port(s) of the asset to be protected.
• Frontend IP (v4 and/or v6): Internet facing IP address for the proxy where all traffic for the asset will flow through.
• Frontend Port: Internet facing port for the proxy where all traffic for the asset will flow through.

Install Layer 4 Proxy

Layer 4 proxies protects your asset against Network DDoS attacks and malicious known bad actor Source IPs in our Threat Intel Feed.

Prerequisites

Before you begin setting up you Layer 4 proxy, you will need:

• Read our Layer 4 Proxy guide for a deeper understanding of how it works and set up manually through our portal
• Delivery method: If multiple asset IPs are provided, how should the proxy decide which IP to forward the next request to? See details in the API spec.
• Supported protocols: TCP (default), UDP or both.
• PROXY protocol required: Determine if the proxy should provide the client IP and port details using the PROXY protocol [1].

Recipe

1. Check available frontend IPs via GET /api/v1/traffic-mgmt/accounts/:tenantId/ips and choose an available IP address to front your asset.
   1. Note that an IP can be re-used for multiple proxies as long as the port you want to use is not assigned to another proxy.
   2. To check that a port is currently in use, you can get all existing traffic configurations via GET /api/v2/traffic-mgmt/traffic-configs and check the port against every TC with the same front-end IP address you intend to use in data[i]->attributes->frontend.
2. Create a proxy via POST /api/v2/traffic-mgmt/traffic-configs.
3. Update your DNS records to point all A records for your asset to the chosen Frontend IP of the proxy.
4. Update your assets firewall to only allow traffic originating from Threat Protection IP ranges.

Install HTTP Proxy (Layer 7)

HTTP Proxies decrypt and re-encrypt data, inspect clear-text payload, and apply application level protection.

Prerequisites

Before you begin setting up you Layer 7 proxy, you will need:

• Read our HTTP Proxy guide for a deeper understanding of how it works and set up manually through our portal
• Front-end TLS Certificate handling: Determine if you would like to provide your own TLS certificate chain (including the private key) or to let Threat Protection handle provisioning and updating the front-end TLS certificate (via Let's Encrypt). This is the certificate that will be sent to the client (a browser for example if this is a website) and you must decide whether you want a specific certificate chain to be presented. Here is a table comparing both approaches to help you decide which one works best for your use case:

	Bring Your Own Certificate	Threat Protection Certifcate (Let's Encrypt)
Certificate chain	Fully controlled by you and uploaded to Threat Protection. Ideal for situations where trust needs to be based on a root CA or chain of certificates	Threat Protection certificate chain which is not customizable by you. Ideal for situations where any chain will do as long as the browser is able to trust it
Certificate private key	Must be shared with Threat Protection	No private keys are shared - Threat Protection provisioned certificate keys are securely stored and never revealed to anyone
Certificate renewal	Managed by you	Auto-renewed every 30 days - fully managed by Threat Protection

• WAF Logging vs Blocking mode: When a proxy is in blocking mode, any requests deemed to be malicious will be actively blocked from reaching your backend. However, in logging mode, requests deemed to be malicious will only be logged without being blocked.
• WAF Paranoia level: Proxy paranoias are from levels 1-4 with the lower levels (1, 2) being more permissive and higher levels (3, 4) much more restrictive. For more details see the OWASP Core Rule Set Paranoia Levels documentation.
• Rate Limiting: Determine if rate limiting should be applied and what thresholds should be used. Currently the rates will apply globally to all paths so try to estimate thresholds by thinking about pages with highest traffic.
  • Consider the impact of enabling rate limiting if you have clients that share the same source IP (for example a government office or school).
• Geo Fencing: Your proxy can be configured to block traffic from certain contries or alternatively to only allow traffic from certain countries. By default, traffic from all countries is allowed.

(Option 1) Recipe: Provide your own TLS certificate

1. Upload your TLS certificate chain (public certificate, intermediate certificate, and private key) via GET /api/v2/traffic-mgmt/certificates/pem
   1. Keep track of the returned certificate ID id in the response payload
2. Check available frontend IPs via GET /api/v1/traffic-mgmt/accounts/:tenantId/ips and choose an available IP address to front your asset.
   1. Select IP(s) for the proxy front-end. Note that an IP can be re-used for multiple proxies as long as the port you want to use is not assigned to another proxy.
   2. To check that a port is currently in use, you can get all existing traffic configurations via GET /api/v2/traffic-mgmt/traffic-configs and check the port against every TC with the same front-end IP address you intend to use in data[i]->attributes->frontend.
3. Create a proxy via POST /api/v2/traffic-mgmt/traffic-configs with the certificate ID id and selected IP address.
4. Update your DNS records to point all A records for your asset to the chosen Frontend IP of the proxy.
5. Update your assets firewall to only allow traffic originating from Threat Protection IP ranges.

Figure 1: Sequence flow to create proxy when using your own TLS certificate

(Option 2) Recipe: Use a Threat Protection provisioned Let's Encrypt TLS certificate

1. Check available frontend IPs via GET /api/v1/traffic-mgmt/accounts/:tenantId/ips and choose an available IP address to front your asset.
   1. Note that an IP can be re-used for multiple proxies as long as the port you want to use is not assigned to another proxy.
   2. To check that a port is currently in use, you can get all existing traffic configurations via GET /api/v2/traffic-mgmt/traffic-configs and check the port against every TC with the same front-end IP address you intend to use in data[i]->attributes->frontend.
2. Create a proxy via POST /api/v2/traffic-mgmt/traffic-configs with the certificate ID id and selected IP address with front-end port 80. This is necessary for the automated Let's Encrypt challenge that will take place behind the scenes for provisioning the TLS certificate.
   1. Keep track of the returned traffic configuration ID id
3. Update your DNS records to point all A records for your asset to the chosen Frontend IP of the proxy.
4. Trigger Let's Encrypt certificate creation via POST /api/v2/traffic-mgmt/certificates/lets-encrypt
   1. Keep track of the returned certificate ID id in the response payload
5. Update the proxy via PUT /api/v2/traffic-mgmt/traffic-configs/{traffic-config-id} with the certificate ID id and front-end port 443 (or whichever port you prefer). This will allow your proxy to complete the Let's Encrypt challenge and within a few seconds to a minute your proxy should be serving traffic to your asset over TLS.
6. Update your assets firewall to only allow traffic originating from Threat Protection IP ranges.

Figure 2: Sequence flow to create proxy when using the auto-provisioned Let's Encrypt TLS certificate