by Our company is obsessed with IT security, so even though that’s not really my area, every other week I hear something new about the subject, whether I like it or not. However, sometimes interesting thing happen, when I learn about something I’ve been using for years, but only now realized that it actually has a name. I’m talking about Web Application Firewalls.
Brief intro to firewall types
In my simplified picture of the world the word “firewall” always meant one thing: something that allows or rejects traffic from or to certain ports and IP addresses. Even though thinking so is not a mistake, this picture is far from being complete.
Network firewalls do exactly that. They sit on the edge of a network and decide the fate of a traffic coming through it. They can be hardware based or software, stateless or smart enough to understand that TCP ACK frame not following TCP SYN doesn’t make sense and therefore should be dropped. This firewalls don’t know about who and why is sending these packets, and, in fact, don’t really care.
There’s another type of firewalls, which does know more: application firewalls. Those serve particular application or type of applications and because of that these firewalls can know how the app works, what makes sense for it and what doesn’t. Having this knowledge, application firewalls can provide the safety level that regular firewalls can only dream of.
There’s also special kind of application firewalls called web application firewall, which, you guessed it, knows awfully a lot about HTTP, web, and how to keep it safe.
Web Application Firewalls (WAF)
Here’s how I accidentally used WAF before even knowing what that is. A while ago I build a small containerized app for monitoring our CI. Three containers were responsible for collecting, storing and displaying the data and one more – nginx container – for being a HTTP router for it.
However, there was one more nginx – the one responsible for blocking incoming traffic from places other than our office. The one, I could easily shut down in case of emergency without shutting down the app itself. That last nginx, believe it or not, behave exactly like simplified WAF would do.
Apart from GeoIP filtering, WAFs can do much smarter things. Quoting OWASP’s ModSecurity Core Rule Set, here’s what kinds of attacks self respecting WAF should prevent from:
- SQL injections
- Cross Site Scripting
- Local File Inclusion
- Remote File Inclusion
- Remote Code Execution
- PHP Code Injection
- HTTProxy
- Shellshock
- Session Fixation
- Scanner Detection
- Metadata/Error Leackage
- and, of cause, GeoIP Blocking
That’s really a lot! There’re free WAF solutions and probably the most popular one seems to be ModSecurity. It supports IIS/Apache/Nginx and the whole set of rules from above. In addition to that, big cloud providers offer their own WAFs. For instance, both AWS and Azure provide WAFs as a service. For some reason, however, I couldn’t find anything for Google Cloud.
Conclusion
The biggest takeaway for me was that WAFs provide huge piece of important functionality, which we actually used to implement ourselves, and that’s for free. The last part surprises me the most. As last several years security was and still is a hot topic, I’d expect everything to cost at least a lot.
On the other hand, there’s a commercial version of ModSecurity, and cloud solutions cost something by default, so maybe the balance in the universe is still in place.
