Application Hierarchy: Server Group, Service, Application
Fundamentals of On-Prem WAF - Part 3
In the first parts of our series, we discussed the basics of On-Prem WAF, and notably, we stated that the OSI 7-layer model is essential to understanding the concept of computer networking. The 7 layers are the physical layer, the Data link layer, the Network layer, the transport layer, the session layer, the presentation layer, and the application layer. We also looked at the SSL Certificates and Ciphers.
This article elaborates on the Application layer focusing on the different hierarchies within the Application layer. We would take a closer look at the rules and policies within this layer and how we implement this within your data center.
Rules and Policies
Every application comes with its rules (this is true for any aspect of life), and the same applies to web servers and computer networks. To effectively protect a web server, you need to check each client request against a set of rules. Rules define what is allowed and what's not.
Rules can be applied in order to:
block traffic (e.g., if someone tries to access http://www.aabb.com/a/b/c.asp AND send the parameter "bla" AND coming from source IP 126.96.36.199 - block the packet).
allow traffic (e.g., if someone tries to access http://www.aabb.com/a/b/c.asp AND send the parameter "bla" AND coming from source IP 188.8.131.52 - allow the packet).
The firewall also has some predefined rules about what it should do with each type of traffic:
drop all packets that don't match any rule (this is called "default deny").
If you have a web server behind your firewall, then you'll probably want to define rules that allow only certain IP addresses access to that server, so that only authorized clients can connect to your website.
Divide your needs - Server Group / Service / Application
For us to effectively protect the web server, firstly, we divide our data centers or data center needs into three levels:
- Server groups
However, a typical deployment of On-Premises WAF does not just protect one website.
If I have an Online-store website and also a News website, each would have different URLs, and therefore different security requirements, something that is allowed on one site may not be allowed on another.
This is the MAIN PURPOSE of applications, server groups, etc - just to divide the data center.
I can say - this policy is relevant only to my news site, so I must first define what the News site is, then "apply" the policy to that object I created in On-Premises WAF, that represents the News site.
Several things might represent the different websites I'm trying to protect:
- A group of URLs
When saying URLs - meaning anything after the first "/" (including that "/"). Anything before that is a HOSTNAME.
Divide By Server Group
This is the most basic level, and it's just used for the logical grouping of servers. For example, if I have an On-Premises WAF cluster with 10 servers and five websites to protect, but one of them is a news site that needs special security settings, I can create a server group just for this website (and its subdomains) and apply security settings to all the servers in this group.
To represent an IP or a collection of IPs, use a server group, everything under that server group will represent things that exist on those IPs.
But I may have several different servers there.
For instance - a web server and an oracle DB server - so the only thing we define at the level of the server group - in terms of security - are the "network security" policies. like firewall, and some general signatures.
Those can be applied to a whole server since they are relevant for everything.
It doesn't matter if the physical server has an Apache or oracle server installed - or both - I would still want to protect it against a "SYN Flood" or make sure connections on port 4545 can't get through, for example.
Divide By Service
A service contains multiple applications with the same functionality (for example, "news" or "online store"). If you have more than one website on a single server group, you can create separate services for each website and apply different security policies to each service - this way they won't interfere with each other. Also, if you have several instances of the same application running on different ports or IPs, you can create a separate service for each one.
Everything that's under a specific PORT is represented by a service, all things under that service will represent entities listening on that port (here we're either dealing with a web server, like Apache or IIS, or a database server - MSSQL, ORACLE, etc.)
If it's the same port - it's the same service, if you have one site on port 80 and another on 81, you can choose to put them on the same service or different ones, this is where most policies work.
Since we already know we are dealing with a specific service type, so I know which protocol I'll be seeing and I can apply most of the logic to that protocol.
However - this is still not all, I want to be protecting the actual logic of what the user DOES on the site - this is where the application comes in.
Divide By Applications
An application is an individual web page or resource which needs specific security settings applied to it.
A web application in On-Premises WAF is an object that represents a collection of URLs or pages it is the basis for the learning mechanism, there is no clear way to say what an application is but the idea is that a collection of pages representing one specific website or a large division in that site are an application.
We can distinguish applications based on hostname and/or URL prefix.
So I can send: www.a.com , www.b.com to be handled under different applications,
but I can also differentiate - www.a.com/mysite, www.a.com/othersite which simply means the context in which I work with some of my policies is different.
This way of managing security policy settings allows you to choose the most appropriate granularity. Many enterprises can even further reduce their security policy settings by cutting out service and application groupings. What I have described here is an on-premises WAF deployment; a cloud-based WAF deployment can be significantly more dynamic in its implementation, although the same principles apply and should be kept in mind when developing solutions for both types.