Web Application Firewalls: Choosing the Right WAF for Server Security
Anita Batari

Web Application Firewalls: Choosing the Right WAF for Server Security

Web applications pose a significant security risk to servers, and having a web application firewall (WAF) in place is vital to keeping your servers and your business running smoothly.

The average web server faces thousands of attacks on a daily basis. There are a number of web application firewalls available to protect your server, and having the right security in place can mean the difference between just another “day at the office” and a dozen “sleepless nights” trying to maintain your servers’ uptime.

Let’s take a look at why having a WAF is so important, how it works, and the options you have to protect your server, from open source solutions to the WAF we’ve designed here at BitNinja.


Web application attacks are the biggest threat to server security

The main security challenge that you face as a webhost or sysadmin is the increasing number of web applications, plugins and other software running on your servers. Customers demand the latest platforms, CMS and server management tools, and you’ve got to provide these features to keep their business.

Attacks on servers have become more and more complex. Rather than targeting brute force or other “typical” methods of attack, hackers are now exploiting vulnerabilities in out-of-date and insecure plugins and web apps.

You can create a basic firewall with IPTables and manage bandwidth for IPs, but you’ll never be completely secure until you’ve locked down your web apps. In fact, a recent study found that 73% of all security exploits are directed against web applications.

With more than two-thirds of attacks directed towards web apps, it’s clear they pose the biggest threat to server security. And you can’t simply block these apps. You’ve got to allow access to keep your customers happy, and you’ve got to keep the bad guys out. The solution is to implement a web application firewall which selectively blocks exploits, and you’ve got a few options when choosing a WAF.


Choosing the right Web Application Firewall for your server

When you start looking for a WAF for your server, you’ll see a lot of open source options in the search results. This is a good place to start because open source projects provide a clear picture of what’s needed in a web application firewall, and how they work.

Perhaps the most well-known resource on WAF’s is the Open Web Application Security Project (OWASP), a worldwide non-profit organization dedicated to making software and server security “visible so that individuals and organizations are able to make informed decisions”.

On their Wiki, you can read about the top 10 web application security problems. The “OWASP Top 10” highlights the primary security concerns when creating or implementing a WAF on your server. These are the main attacks that a WAF is designed to stop, and the list also tells you a bit about how a WAF works to secure your server.


WAF Vulnerabilities: The OWASP Top 10

Here’s the latest "OWASP Top 10" 2017 list, including a brief description of the types of exploits a WAF is designed to stop:

  • Injection
    This covers any type of code that’s “injected” or inserted into the running code of one of your web applications through an exploit. Common examples are SQL injections, OS, XXE and LDAP injections. This is the top priority for any WAF.
  • Broken Authentication
    This exploit is when a hacker takes advantage of loopholes in security to steal passwords, tokens, session keys and otherwise compromise user authentication for web apps.
  • Sensitive Data Control
    Vulnerable APIs and databases are a big target for hackers to steal personal information including contact details and credit card numbers.
  • XML External Entities (XXE)
    This type of attack parses the XML input to a server and links to an external entity creating an opportunity to gain access to the server.
  • Broken Access Control
    When restricted areas aren’t properly configured, hackers gain access from less secure to more secure parts of your server.
  • Security Misconfiguration
    The name pretty much says it all. Any misconfiguration at any level of an application stack can compromise your entire server.
  • Cross-Site Scripting (XSS)
    XSS is a specific type of injection where malicious scripts are injected, usually referring to external resources, making a typical “healthy” website into a “danger zone” for users and server owners.
  • Insecure Deserialization
    Hackers will modify off-the-shelf tools to attack specific loopholes in application logic or to run a script injection when the application behavior changes before or after deserialization. It sounds complex, and it is. While this is a somewhat difficult attack, it is becoming increasingly more common.
  • Using Components with Known Vulnerabilities
    As a server admin or webhost you are more than likely familiar with running older web applications to keep customers happy and help ease the transition to new platforms. Even new web applications can have vulnerabilities which are discovered and not immediately patched.

    Quick Tip: Be sure to check the Common Vulnerabilities and Exposures (CVE) list to learn about vulnerabilities in web applications before you run them. However, trying to keep up with every vulnerability is like a game of cat and mouse. Protecting against vulnerabilities before they happen is a big part of why we created our own WAF.
  • Insufficient Logging & Monitoring
    Like security misconfiguration, not having sufficient logs on your server can leave you vulnerable. This can allow hackers to develop exploits over time which are not detected, slowly and surely they gain access to your server, and none of your activity logs show anything out of the ordinary.


ModSecurity – Open Source WAF based on OWASP

When it comes to open source web application firewalls, ModSecurity is at the top of list. In some ways, it’s the only open source WAF, because other open source solutions are targeted for specific frameworks, for example NAXSI which is just for NGINX, and WebKnight which is for Microsoft servers.

ModSecurity, which is an OWASP project, covers Apache, NGINX and Microsoft web servers and is highly based upon the Top 10 list and providing a base level of protection for every server. The primary drawbacks are that ModSecurity is command line only and is “help yourself” when it comes to support.

For DIY solutions, ModSecurity is a great place to start. If you’re willing to roll up your sleeves and do some hand-coding, it can provide reasonable protection. Things to look out for along the way are keeping up-to-date with the latest versions and making sure ModSecurity doesn’t interfere with applications as they are running, especially when you begin modifying the rules for your specific needs.


BitNinja’s WAF 2.0 – Why we built our own Web Application Firewall

A few years ago, after discovering numerous exploits on our own web servers, we decided it was time to fight back and create a Server Security Suite that provided the protection we needed, without any of the headaches typically associated with configuration. Believe us, we’ve had our share of sleepless nights too!

From the beginning, we knew that a web application firewall was going to be a vital component in our security suite, and we’ve been testing it in beta on our own servers. These are real production servers getting real traffic every day. We wanted to be sure our WAF was going to work, and not get in the way of any web apps.

1. Industry Standards and Compatibility

We built our BitNinja WAF 2.0 on the backbone of ModSecurity. It’s the industry standard and compatible across a wide range of platforms. Using ModSecurity as the base for our platform ensures that our WAF is always up-to-date with the latest best practices according to OWASP and the worldwide security community.

2. Less Configuration, More Protection

While ModSecurity provides adequate protection for web servers, we wanted to go a step further and create a WAF that would protect against vulnerabilities before they were discovered.

The command line interface also presents a big roadblock for using ModSecurity “out of the box”. Of course, we’re developers and we write our own code, but we don’t want to spend hours in a terminal window making routine changes to our WAF. With BitNinja WAF 2.0 our goal was to create a WAF that was easy to use and didn’t require constant configuration. We wanted to be able to make changes with a few clicks.

3. Easy-to-Use Dashboard

Here’s a screenshot of the BitNinja WAF 2.0 dashboard in action. You can enable/disable the firewall or activate/deactivate a pattern or ruleset for all your servers, all in one place:

4. Pre-defined rulesets for low false positives

One of the primary challenges as you add layers of security to ModSecurity is preventing the WAF from blocking web apps. Often you’ll implement one rule to protect an app, only to find that it blocks access to another app.

We’ve developed and continually refine a default rule set for all the websites hosted on your server. This ruleset is rigorously tested to ensure the lowest false positive rates, and constantly updated with safe rules that protect your server while allowing access to all your web apps.

For those who want a greater level of control, we also give you the option to change the rules one-by-one or manage them by categories.

5. Domain-based WAF controls to keep users happy

The primary goal for any webhost or server admin is to keep their customers and users happy. We know that every website has its own specific needs, and there are often individual requests from users and site owners.

To make day-today life easier, we created a built-in option in our WAF that allows you add custom patterns and rulesets for each domain. You can also disable the WAF entirely for only a subdomain if necessary. This is a great way to keep your customers satisfied and still provide great protection.

6. Lock-down feature for emergency situations

When disaster strikes, it helps to be prepared. Our BitNinja WAF 2.0 includes a handy lock-down feature that immediately disables POST requests (registrations, logins, posting, etc) and converts the site to read-only mode. This restricted mode leaves the site available for visitors, while preventing further hacking attempts as the situation is mitigated. It’s a win-win situation that allows you to calmly address sudden increases in attacks from botnets and other distributed types of attacks.

7. Log-only or Active Protection

We wanted to provide a way to monitor activity without blocking it. Sometimes, you need to troubleshoot the configuration of a web app, and you need to rule out the possibility of the WAF interfering.

In Log-only mode, you can see all the logged (but not blocked) incidents using the Dashboard. In this case, connections are not interrupted by the WAF. This allows you to monitor any incidents and manually block the IPs if you find positive hits, as well as implement web apps with complex configuration before turning the switch to the firewall “on”.

To keep your other sites and servers protected while you monitor traffic or install an app, you can choose between Log-only mode and Active Protection by server and even by domain.


WAF 2.0 is completely integrated with the BitNinja Security Suite

Here at BitNinja, we take a holistic approach to cyber security. Different types of attacks require different types of defense for a server. It’s like the security at a castle vs. an airport. With a castle, you put all your defenses in one place, leaving you vulnerable to multiple attacks. However, in the case of an airport, you have multiple checkpoints for defense protecting you by closing all the security loopholes.

In addition to our WAF 2.0, BitNinja’s Security Suite includes 8 other security modules: IP Reputation, Port Honeypot, Web Honeypot, DoS Detection, Log Analysis, Malware Detection, Outbound WAF and Protection for HTTPS. Each of these modules work together to provide multiple points of defense for your servers against a wide range of attacks, from hackers, botnets and whatever’s next on the horizon.


Why Choose BitNinja WAF 2.0 for your server?

Like you, we also faced the challenge of keeping our servers secure and our customers and users happy. We built our WAF based on our own experience. We wanted something with the flexibility of open source, the power of industry standard protection, and honestly, something as easy-to-use as a smartphone. We think we’ve achieved it, and we’d love for you to check it out and let us know what you think.

Try our WAF 2.0 and the BitNinja Server Security Suite without any obligation. Sign up for our 7-day free trial and start enjoying full-stack protection on your server today.

Share your ideas with us about this article

Previous posts

Shared hosting provider with 7,000 customers had 0 infections over the past 7 days
Our Hungarian web hosting partner, web-server.hu had ZERO website infections – since enabling BitNinja’s new WAF 2.0 module. We caught up with the lead sysadmin to talk to him about his experience with BitNinja. What has been your experience with BitNinja overall? “Before we began using  BitNinja, we had to fight daily battles with hackers. Infected Wordpress, Joomla, Drupal and other accounts were the most commonly affected platforms. Because of the continuous battle with infections and DoS attacks, we hardly had any time left for servers and for development. Since we started using...
MongoDB vs. Elasticsearch
What is MongoDB? MongoDB is an open-source NoSQL database that uses a document-oriented data model. This type of model is built on an architecture of collections and documents instead of using tables and rows like MySQL. Documents are built from key-value pairs which are the basic units of MongoDB. These documents may also be part of different collections - like tables - in a relational the database. Being a NoSQL database MongoDB uses dynamic schemas for documents and as a result, they may be structurally different. This database also uses BSON (Binary JSON) – which is...