At the end of 2021, a severe vulnerability in the Java logging library Log4j shook the software industry while other industries — for example, the financial sector — are still dealing with the aftermath. The incident as well as and reminded us how paramount cybersecurity is. In order to mitigate the vulnerability quickly, the open source community came together to provide a number of solutions.
The Log4Shell vulnerability is not the first vulnerability of its kind and most certainly won't be the last. So, how can you protect your applications against future security issues? Here are two ways of mitigating injection vulnerabilities in widely used libraries, such as Log4Shell:
- Patch or update the affected tool in all applications where it has been used
- Use a reverse proxy to block malicious requests when entering the network
The reality of attackers continuously using software vulnerabilities to compromise systems has created the demand for a remediation mechanism that does not require you to rewrite your entire application.
In widely deployed libraries, tracking down every use is a lot of work. Let’s explore how a reverse proxy can help you protect against attacks and why implementing one should be part of your security best practices.
Intercept and stop attacks at the entrance
Malicious attacks are typically carried out by manipulating requests directed to your web server(s). So, it makes sense to implement a tool capable of detecting and blocking such requests at the very entrance and before the client request reaches the web server. This is where a reverse proxy comes in handy.
At its core, a reverse proxy is a piece of software that sits between the client and the server, receiving user requests and forwarding these requests to the appropriate server. However, most reverse proxies come with an additional set of features. When implementing security best practices there are a number of features and functions that are particularly valuable.
Backend server IP protection Located at the entrance of your application, a reverse proxy intercepts user requests directed to your web servers. In other words, your reverse proxy is the only server visible to the internet and protects your backend web servers, their identity, and characteristics, implementing an extra layer of security, and making it difficult for attackers to access those backend servers.
Request content validation A reverse proxy can be configured to filter all requests based on a database of filter signatures. Reverse proxies allow you to filter and firewall, and protect a specific part of your system that you already know is vulnerable. In case your web server does not allow you to express and implement detailed rules and ACLs, you can also implement this process at the reverse proxy level.
Request filtering is implemented via white and/or black lists. A white list contains the set of valid requests and blocks potential attacks by allowing only known requests to reach your backend servers. A black list, on the other hand, contains known malicious requests.
Response content validation Server responses can also be validated through the reverse proxy before sending those responses back to the client. Response content validation blocks known server responses containing information that the client should not see, for example, specific types of errors. This function can also be configured to stop sensitive information like tokens, credentials, etc. from reaching the client.
Application resiliency Even if an attack does happen, by implementing rate limiting and load balancing (two of the key features that came with a reverse proxy), you ensure that the said attack does not bring down your entire infrastructure.
Logging Reverse proxies centralize logging and monitoring. Requests and responses can be logged for later analysis giving you full visibility over the implementation of the filtering rules and ACLs, making sure that valid requests are not being blocked.
Some points of caution
Using your reverse proxy as a security layer does take some planning, though. A reverse proxy essentially acts as a middleman between your backend server and the client. For a reverse proxy to be used as a security layer, it needs to have WAF capabilities. Implementing, configuring, and maintaining a piece of software like a reverse proxy can involve some tedious tasks. After implementing a reverse proxy, you need to stay on top of certain tasks to ensure your reverse proxy works effectively, offering the best possible level of protection.
- Creating and maintaining white and black lists is time-consuming and complex, but it is paramount that those lists are always up to date in order to avoid blocking valid requests that will inevitably impact user experience.
- A combination of white and black lists offers a good level of protection against incoming malicious requests. However, you need to keep in mind that a black list will not be able to block all possible attacks. Variations of known attacks will have to be logged in the database as well.
- Although a reverse proxy can do an excellent job protecting applications against malicious requests, it will not be able to protect your system against application logic issues — e.g. vulnerabilities in session maintenance. Improper configuration and vulnerabilities in the reverse proxy itself also require caution.
Conclusion
Reverse proxies can be a powerful tool protecting you against known attacks that are based on manipulating requests directed to your web servers. A reverse proxy also acts as your only visible web server, concealing your backend servers from the internet, and keeping them protected. Yes it does take planning and some maintenance to get the most out of your reverse proxy, but don’t all good things come with a bit of extra work?
Most commonly, reverse proxies do not come with all their security capabilities pre-configured. Using a reverse proxy to enhance your application security can be a complex and time-consuming task. The benefits of implementing one as a part of your security best practices, however, by far outweigh the possible drawbacks.
References and further reading
This is a companion discussion topic for the original entry at https://traefik.io/blog/improve-application-security-using-a-reverse-proxy/