A Web Application Firewall (WAF) is a firewall meant for HTTP applications to prevent cyberattacks such as cookie-poisoning, cross-site forgery, cross-site scripting, SQL injection, and file inclusion. There are both commercial WAFs and open-source WAFs.
Commercial WAFs are expensive and not always affordable. Open-source WAFs exist to create accessibility to WAF technology to people and businesses that cannot afford commercial WAFs. What’s more, they are highly flexible and customizable, allowing developers to modify the code to fit their projects.
The most widely used open-source WAFs are ModSecurity, IronBee, NAXSI, WebKnight, Shadow Daemon, Lua-resty-WAF, and Vulture.
Open-source WAF however, comes with several downsides. We explore them below:
1. Distributed attacks on everyone using the open-source WAF
WAFs using open-source code and frameworks are susceptible to distributed vulnerabilities. Since many systems tend to use the same framework, hundreds of thousands of applications are exposed to any new vulnerability. Once these vulnerabilities are discovered, organizations get into a race to create a patch before attackers can attack them. This means that open-source WAFs cannot be relied on to block real-time threats.
2. Can easily be bypassed
Most open-source WAFs use software with vulnerabilities that can easily be exploited. Open-source WAFs have fail open and fail close events when there is too much traffic. During a fail open, a WAF only does monitoring and hence lets all traffic through including potentially malicious traffic. In a fail close, all traffic is blocked. A DDoS or DoS attack could break through the WAF, preventing complete access to the application. There are numerous other ways hackers abuse and bypass rules on open-source WAFs. These include faking sources of requests, sending custom requests using mixed-case to bypass either uppercase or lowercase rules, and many others. In the case of modified attacks, a proper WAF using advanced detection techniques is preferred.
3. Lack of clear and user-friendly interfaces and WAF documentation
Open-source WAFs do not have clear and user-friendly interfaces, making it difficult to read data related to traffic and vulnerabilities. In cases where there is a visual representation of data logs, it usually is not very sleek or all that readable.
Commercial WAFs tend to have more friendly, usable, and intuitive interfaces. Some of the reasons for this is that most developers contributing to open-source WAF projects prioritize functionality over “beauty,” and think that user-friendly user interfaces can always be built later on.
Open-source WAFs also suffer from a lack of clear documentation, if there is any documentation at all. This is because they do not have a contractual responsibility to offer this. What they provide instead are general guides that likely skip over specific use cases.
4. False positives and negatives
When open-source WAFs are inspecting traffic, they assess packets of data against a host of predefined patterns to determine their legitimacy. Open-source WAFs often might result in false positives and negatives due to a mix up of these predefined patterns. A false negative happens when a malicious request is not detected correctly, and hence no defense against it is launched. On the other hand, a false positive occurs when there are legitimate requests, but they are detected and marked as malicious and consequently blocked.
5. No protection against zero-day exploits
A zero-day attack is an attack that is only known to the attacker and completely new to a cybersecurity expert. It, therefore, takes time for a cybersecurity professional to build a patch to defend against a zero-day vulnerability. In the meantime, an attacker can take that opportunity to exploit a system. Most open-source WAFs cannot protect against these types of attacks.
For a WAF to stay up to date with intrusive zero-day attacks, it requires that developers exhaustively update system rules frequently, which is just not feasible.
6. Replay attacks
Open-source WAFs also struggle to prevent replay attacks. Replay attacks happen when a valid data packet is delayed or repeated by a malicious program. While there are ways to prevent and mitigate replay attacks, open-source WAF is not the ideal way. This is because it can only detect attacks targeted at isolated web requests, rendering open-source WAFs impotent and vulnerable in the case of attacks on multiple requests.
7. DDoS difficulties
Open-source WAF setups also struggle to deal with DDoS attacks. This is a serious concern considering the rising number of successful DDoS attacks. DDoS attackers do not even require a lot of technical knowledge to implement attacks on vulnerable open-source WAF networks. This means that DDOS attacks are likely to be more prevalent in the coming years if open-source WAF frameworks are not strengthened.
8. Configuration issues and costs
Open-source WAFs typically need to be configured right from the on-start. In some instances, they even need more work compared to standard firewalls. Knowledge of both the open-source WAF and the application it is being deployed on is required, for optimum protection. If you do not have this kind of security expertise in-house, you have to outsource it, and it is not cheap. Professionals doing this kind of work don’t come cheap, considering the assets they are protecting. You wouldn’t want an amateur to fumble around and make your cybersecurity frameworks a mess. (Read more on the advantages of fully managed WAFs).
9. Maintenance issues
Maintenance of open-source WAF networks is very labor-intensive. This is because of the malleability of web applications; hence they are constantly changing and needing maintenance. Updates occur frequently, and users often require new features. Not to mention the fast-evolving computing landscape. Developers are also very creative and are constantly experimenting with new ideas, trends, and technologies. This means that applications change on a daily basis. If your WAF deployment is part of the overall organization’s security framework, your cybersecurity team cannot design and implement features in isolation. They also need to involve all other organization departments such that everything else is working in tandem with the WAF.
10. Performance issues
Open-source WAFs come in different shapes and sizes, each having different performance capabilities. Some WAFs allow you to integrate them into the hosting application of your web server. For example, you have to integrate ModSecurity to the Apache, IIS, and Nginx web servers.
In some instances, you could put an application behind a WAF that checks all traffic into and out of the application. In case the WAF operates in a less active role of monitoring without interference on the traffic, it could result in problems such as sufficient latency and performance impact on the server’s ability to service concurrent requests.
You might also find that you require more hardware or web servers to maintain the ability of a server to respond to a similar number of requests. Depending on the application’s architecture, you can respond to this by using tools that can cache static content that doesn’t need inspecting by a WAF.
This takes us back to the downsides of complexity in configuration and maintenance and overhead costs.
Conclusion
Open-source WAFs are highly flexible and customizable, and they make WAF technology accessible for organizations that cannot afford commercial WAFs. However, we cannot ignore that open-source WAFS also comes with many downsides. In the age of constant cyber threats that we are in, having an effective WAF is extremely important.Open-source WAFs can be difficult to configure and maintain, and they are faced with numerous computing issues. They can also not address challenges such as DDoS attacks, replay attacks, and zero-day attacks. As a result, they are unfit for robust cybersecurity.Acknowledging these downsides opens up avenues to strengthen existing open-source WAFs and create more sophisticated WAF solutions for modern security frameworks. Check out fully managed WAF at cloubric.com!