Proxy Access Control

IP Allowlist

You can significantly strengthen your HTTP Proxy access by using allowlisting -- one of our most effective features.

Every VGS proxy route configuration can be set to allow communication only from trusted Internet Protocol (IP) addresses. When you precisely specify which IPs can connect to your enterprise configuration, you dramatically improve your security posture against unauthorized scanning and other malicious traffic.

Such undesired behavior can even result in a costly Denial-of-Service (DoS) condition or attack. In fact, unwanted traffic alone can incur a significant cost. Your backend systems can also suffer, even if you have proper authentication or other protective measures in place.

Your best option is simply to let us deal with it. We can verify that a request is invalid by its source IP. Then we can easily reject the request, and you can avoid any negative business impact that might otherwise have occurred.

Our IP allowlisting is perfectly tailored for Outbound (forward proxy) configurations. When IP Allowlisting is used, we have yet to see any Outbound communications from unknown or untrusted sources.

For more information, please read.

If you think that your configuration cannot leverage IP allowlisting, please let us know, and we will do our best to make it happen!

If you have any questions or need any help, please contact our support team at [email protected].

Rate Limiting

It is important to reduce the amount of invalid, fraudulent, and malicious traffic on your site, which can increase your load and lead to unexpected charges. Rate limiting is a method of controlling the amount of network traffic sent or received by a network interface controller.

Rate limiting can be used to mitigate scanning, DoS attacks, web scraping, brute-force attacks, and remote login password guessing. Such unwanted behavior may increase on holidays or during big events such as Black Friday sales. Sometimes, even large sites like Stripe have been knocked offline.

For computer network defense, a balance must often be struck. Rules should be tight enough to prevent an attacker from successfully achieving their goal. However, rules should also be loose enough to prevent an attacker from easily inflicting a denial-of-service condition on a target service. Precise limits may be based on the level of data sensitivity. You can also apply rate limiting to multi-factor and out-of-band authentication.

A web application firewall, or WAF, can be leveraged for rate limiting. For more information, please see our section entitled Web Application Firewall.

For verification, ensure that your code and documentation enforce rate limiting. Test your rules on a regular basis. For each of these processes, automated tools can help.

At VGS, in order to ensure the quality of service to all customers and help prevent runaway scripts from depleting customer quotas, we have rate limiting both in our sandbox and live environment. Limits are set depending on the service type (Inbound/Outbound) and the environment type (Sandbox/Live).

Inbound traffic is limited by unique IP, per vault (rpm = requests per minute). If the rate limit is X rpm and the number of IPs N, the max rpm would be X*N for that inbound route (X = 200 rpm for SANDBOX, X = 5,000 rpm for LIVE, and N = number of IP unique addresses).

• Sandbox - 200 rpm

• Live - 5,000 rpm

Outbound traffic is limited per vault, a rate limit of X rpm is the limit per vault (X = 200 rpm for SANDBOX, and X = 5,000 rpm for LIVE).

• Sandbox - 200 rpm

• Live - 5,000 rpm

If you’ve reached your limit, all subsequent requests will be interrupted with status code 429, and they will be reset after a minute.

If you have any questions, comments, or need to increase your limit, please contact us at [email protected].

Mutual TLS (mTLS) Certificates

Data in transit should be encrypted with Hypertext Transfer Protocol Secure (HTTPS) or Transport Layer Security (TLS) to help prevent attackers from reading your network traffic, or even manipulating your data with a man-in-the-middle attack. Mutual (or two-way) authentication (mTLS) is an optional, but highly recommended feature in verification schemes that transmit sensitive data, in order to ensure data security.

mTLS can defend against many adversarial attacks that may result in significant negative consequences. To mitigate against supply chain or other attacks where routing to your backend has been altered, or where you want additional security for incoming connections, VGS recommends securing your host with mTLS functionality to ensure that VGS servers only communicate directly with your backend infrastructure.

mTLS can be accomplished with usernames, passwords, and public key certificates. Customers can upload a TLS certificate, along with their private key, to establish a trusted connection with third-party services like Visa or Mastercard. A TLS Certificate identifies the server and the company associated with the server. The private key is used to encrypt your data over the TLS connection and prevents your data from being read or modified in transit.

All of your mTLS certificates for VGS inbound and outbound proxies may be found on your Dashboard in Vault Settings. They include a certificate’s cert description, proxy type, access credentials, cert signer, and expiration date.

More information on uploading, adding, and deleting TLS Certificates and private keys can be found here.

Please note: VGS offers mTLS as an advanced feature. There is no charge for mTLS during your free trial. However, after your organization is activated, you will be billed monthly for each new TLS connection.

Web Application Firewall

VGS + WAF = ❤

The long, complex history of HTTP provides fertile ground for HTTP desync attacks, and there remain no guardrails for application security flaws. Website compromise and data breaches are still common, leading to the loss of revenue and customer trust, as well as lawsuits and even the extinction of many businesses. Therefore, it is essential that web app owners up their security game and invest in a Web Application Firewall (WAF).

Traditional firewalls sit at the network or transport layer of the OSI model, between trusted and untrusted networks. But today, you can deploy a WAF at the highest layer (the application layer), where it sits right in front of your users and data. Both types of firewalls handle access control and network defense, but in unique positions with unique tools and strategies. Working together, they offer your enterprise greater defense-in-depth.

WAFs protect your enterprise against a wide range of attacks that specifically target web apps, including remote code execution, insufficient authentication, exploits, SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), directory traversal, file inclusion, HTTP floods, malicious scanning, and more. Many of these attacks are detailed in the Open Web Application Security Project’s Top 10 Web Application Security Risks.

There are three different types of WAFs: network, host, and cloud. Network and host-based devices are typically located on-premises, while a cloud model is a SaaS solution. There are both commercial and non-commercial WAFs. One open-source WAF, ModSecurity, is a part of OWASP and has its own rule configuration language called “SecRules.” Commercial WAFs vary significantly in price depending on interface, options, requirements, etc. Typical costs are based on the number of rules you configure and the number of HTTP requests you receive. All things considered, we believe that most VGS customers would be best served with a cloud-based WAF.

How does a WAF work?

A WAF intercepts and inspects inbound web requests (HTTP/HTTPS) to detect and prevent malicious traffic from reaching your web apps. WAFs are powerful and can dig deep into network packets to evaluate what is inside the payload. They can parse data, identify malicious signatures, and evaluate suspicious behavior. All of this is necessary to recognize and stop sophisticated network attacks.

A web request must adhere to your security rules, often called policies, or it does not get permission to touch your web app. As with traditional firewalls, WAFs can make decisions based on “positive” or “negative” logic. Positive security policies, such as an allowlist, typically run first and may allow only a certain type of inbound request or from a certain location (or both). Negative security policies, which usually run second, can block an inbound request that matches a malicious signature (e.g., SQL injection) or an attempted denial-of-service.

Each strategy has its strengths and weaknesses, and it is often necessary to leverage both. However, you are highly encouraged to create allowlists because they are designed to deny everything except that which is specifically allowed. They also consume fewer resources than a blacklist and go a long way toward preventing zero-day exploits.

WAF Configuration

A WAF has three components:

1. Conditions: the characteristics of an inbound web request used for decision-making, such as source IP address, hostname, geography, time, or type of attack (e.g., XSS).

2. Rules: with boolean logic, you tell your WAF what to do, including whether to stop the request or simply alert on specific behavior.

3. Web access control list (ACL): “A B C” stands for allow, block, or count (the latter is used for rate-based rules, in which you allow a maximum number of requests matching specific criteria, and then block the rest).

WAF rule sets can quickly become long and complicated. There are many sketchy IP addresses out there and thousands of malicious signatures to consider. The attack space is constantly growing, and hackers have the incentive to innovate. With rate-based defenses, it can be difficult to stop offensive behavior without creating your own denial-of-service in the process.

In spite of these challenges, help is never too far away. Some WAF providers offer pre-built templates to get you started. The open-source ModSecurity WAF Core Rule Set covers many popular web apps and common threats, and offers a high level of security for Apache web servers. One of the strengths of a WAF is the ability to modify policies quickly; for example, in the event of a DDoS attack, rate limiting can be set to slow the barrage.

Finally, WAFs have a transparent mode and a proxy mode. In the first case, a WAF sends web requests directly to the web application. In the latter, a WAF provides additional protection to the server by acting as an intermediary hop -- which can increase security, but unfortunately also increase latency.

Testing & Remediation

Due to the size, speed, and complexity of today’s networks, security can be hard to achieve and is always a moving target. You must continually test your WAF configuration. Vulnerability scanners and penetration testing can find software coding errors and discover unknown vulnerabilities.

Many web apps can be quite unique, with their own intrinsic vulnerabilities and exploits. Furthermore, enterprises often have numerous web apps to protect.

Positive rules are highly restrictive, but can be a challenge to create and maintain. Negative rules are often complex and voluminous, result in a high number of false positives, and still have trouble identifying every malicious web request.

Hackers engage in numerous strategies to bypass WAFs. Here are some examples:

1. Pre-processor exploitation: deceiving a WAF into skipping input validation

2. Impedance mismatch: a WAF interprets input differently than the backend

3. Rule-set bypassing: sending payloads undetectable by a WAF

Once security vulnerabilities become known, it is critical to fix them, and the sooner, the better. For some hard-to-kill bugs, it may be necessary to apply virtual patches or immediate but temporary fixes.

For any modern enterprise, a WAF plays a vital role in a cloud-based defense-in-depth security strategy. Not only does it protect against malicious web traffic and hedge against web app vulnerabilities, but it also helps to fulfill information security guidelines and compliance requirements such as PCI DSS and SOC2. And as a bonus, filtering out all of that junk traffic can reduce costs and improve your customer user experience.

WAF Placement

One of the most important configuration questions you will face is whether to place your WAF in front of VGS or behind. Whichever placement you choose, there will be benefits, drawbacks, and tradeoffs. Fortunately, the VGS proxy protocol is both secure and flexible, allowing you to tailor your architecture in a way that best suits your needs.

A good way to approach this question is to consider exactly how you want your clients to interact with your backend. You know your enterprise and web apps best, and only you can fine-tune all of the options to their ideal state. That said, in the end, a major determinant will be which type of WAF you choose: network, host, or cloud-based.

VGS First

Network- and host-based WAFs are on-premises, co-located with your backend. In this scenario, your WAF is your primary ingress, and you are already familiar with its role in protecting your backend services. Therefore, we recommend that you maintain this architecture, as you can easily route your traffic through the VGS proxy first.

By putting VGS first, you take advantage of numerous VGS security features. This includes our default capability to rate-limit traffic, which significantly helps to minimize the harmful effects of a denial-of-service and is typically a feature for which WAF providers add a surcharge. Furthermore, VGS provides other types of traffic restrictions, such as IP allowlisting, in which only specific, pre-authorized source IP addresses have the right to access your backend.

WAF First

Now let’s consider a cloud- or SaaS-based WAF. In this scenario, your WAF is the edge ingress, has initial access to the unredacted web requests, and restricts traffic before it routes to VGS. Thus, VGS sits behind your WAF but in front of your backend. This architecture has some significant design advantages -- as well as some important caveats.

First, VGS customers should take advantage of our IP allowlisting feature. Depending on your cloud WAF implementation, the request routing to VGS may be known, or it could be hidden. This could happen, for example, when the route is configured with a DNS CNAME (and even if you do not use a CNAME, your vault DNS is not expected to be a secret). Thus, allowlisting is an important part of securing your APIs, as specifying your WAF egress IPs helps to ensure that your WAF is not easily bypassed. Most WAF providers provide easy access to their egress IPs (e.g., Cloudflare: https://www.cloudflare.com/ips/).

Second, placing your WAF first is a smart choice for VGS clients because VGS currently does not have the capacity of a global content delivery network (CDN). SSL termination points that are physically closer to the end user dramatically improve connection speeds. A global CDN can improve user experience via faster initial connections and SSL handshakes that normally require multiple back-and-forth requests and response messages, which can lead to significant latency.

Third, if your WAF sits in front of VGS, your WAF must process the web requests first and perform the rate limiting. The simple reason is that VGS cannot determine the original source of the requests. Therefore, you should inform VGS so that we can disable this vault feature. This is necessary to avoid a VGS rate limit against the WAF (which would include the traffic of all your clients combined).

Fourth, when your WAF is in front of VGS, your WAF vendor is now within your compliance scope. Because the WAF must perform SSL termination, your WAF provider will see the sensitive contents of your web requests before VGS has had a chance to alias them. However, there are many great cloud-based WAF providers with strong compliance certifications, so make sure you choose one aligned with your organization’s compliance goals.

Better Visibility = Increased Security

Whichever configuration you choose, the goal is the same: better visibility into your web requests and increased security for your enterprise.

If you have an on-prem WAF (and VGS processes your web requests first), VGS will provide you with an accurate source IP in the X-Real-IP request header. Please ensure that your on-prem WAF or other ingress does not replace this field with a VGS egress IP. Additionally, VGS provides the X-Forward-For in the header, but this must be used with caution, as an attacker can append new, incorrect values to this field.

If your WAF sits in front of VGS and proxies web requests through VGS, please note that VGS appends the X-Real-IP from your upstream WAF. You can configure your WAF to inject an alternate header, such as X-Forward-For. However, you should only do so if your WAF is capable of ignoring user-supplied values; remember that an attacker may try to hide their origin by specifying an incorrect or fake value in this field. An alternative, if the WAF provides the capability, is to use a new and unique header.

When used in tandem, VGS + WAF integration offers numerous potential advantages for your enterprise. Remember that security is a journey, not a destination, and there is always more to do. If you have any questions, please ask!