You
can encounter many forms of WAF installations, such as server plugins, filters,
or even customized WAFs for a certain application. Also, there are different
types of WAFs that we can distinguish in the following three categories:
1.
Appliance-based Web application firewalls
2.
Cloud and hybrid Web application firewalls
3.
Code integrated Web application firewalls
The first category, Appliance-based WAFs,
has to do with physical WAFs that the server manager installs physically to the
server. It is placed in front of each web infrastructure of the server, and has
the great advantage to not have the need of connecting to a remote server for
the WAF services. It is fast, reliable, and on your facilities, so you can deal
with problems that it may face on your own. Many times, this may be a negative
aspect, because you will need specialized staff all the time in your
facilities, in case of an emergency problem. Because of the physical structure
of this type, appliance based WAFs have to deal with all the traffic and
protocol requirements that your server may have, so the time of installation
has to be set up for any possible case, or else it may face problems in the
future.
The next category, that has many
differences from the first one, is cloud-based WAFs, and as the name implies,
they are firewalls that are based on the cloud. Most of the time they are
installed in a remote server of the cloud WAF provider, or they can be shared
between the company’s and cloud provider’s servers. In the case of complete
cloud
Finally, we have Code Integrated
solutions, which is only software based, and most of the time, makes changes to
the web application code, or sits to the server. As you can understand, the
thing that has no need for hardware makes it cheaper, easier to fix, and easier
to update. You still need specialized stuff in your company, but if the WAF is
well built, it can make things so easy that even the usual IT staff can handle
it.
Web
Servers and WAF Placement
Web servers
are basically the host of web applications and WAFs that we are talking about
in this course. It consists of specialized hardware and software that manages
the communication between the client
and the server, with a variety of protocols,
like HTTP and FTP. Web servers are used most of the time to serve web pages,
and on the hardware side of things, it is pretty similar to a computer that
stores the files required for the webpage’s structure, and serves them to the
client. The software side manages the communication and access control of the
file system, with many different
implementations.
In the situation of a WAF placement on the web
server we have the appliance based that as you can imagine is a separate hardware
piece, that sits in front of every other hardware on the web server. All the
traffic has to first pass and get filtered by the WAF, so everything is
connected to it. In the cloud based systems, we may have both hardware
and remote cloud service, but the difference is in the remote solution, where
the traffic first passes through the remote cloud server, it gets filtered and
then it gets redirected to our web server. Finally, we have the code inte-
grated solutions that as we said is software that sits in front of all the
other software in the web server, filters all the traffic and allows it to the
other web applications or blocks it.
There are also two security models that a WAF can
follow in developing its security policies, which is positive or negative. In
the positive security policy, WAF allows the traffic that has come to be good
to pass through, and blocks all the other traffic. In the negative model, the
WAF allows all the traffic to pass and only tries to block the known to be bad
traffic. Many times, WAF use both of these models, but things get complicated,
so most of them
select one of the two.
WAF
Operating Modes
Aside from the security models,
we have the operating modes of a WAF. A WAF can operate differently, according
to the use we want it for. Each
of them has its positive and negative aspects and it is a seri- ous part to
consider
when selecting a WAF for your
company. The most famous operating modes are:
Reverse proxy: As we said in the beginning of the module,
a WAF can be used as a reverse proxy, because
it sits in front of the server and filters all the incoming traffic,
which is the opposite from a proxy. Many times, the negative in a reverse
proxy is the latency that may occur, but this problem tends to be fixed in
newer solu- tions. In this mode, WAF has its own IP address, and all traffic
goes through this address.
Transparent proxy: This proxy has the same conditions as the reverse proxy, with the change that it does not have an IP address. This is because
it sits behind another firewall,
and it does not need any networking changes in the server side.
Layer 2 bridge:
In this mode,
the WAF is again sitting behind
the firewall and acts like a layer 2 switch (more about it here: https://en.wikipedia.org/wiki/LAN_switching). It is a mode with high performance, and no
server side changes.
Network Monitor
mode: In this mode, the WAF sits outside
the web server (like the cloud based ones), which sniffs and monitors all the traffic
that heads to the web server. In this situation, the WAF is blocking
un- wanted traffic,
by sending TCP resets to interrupt it.
WAF Filter Rules
• WAFs have some
preset rules out of the box, and of course, they get up- dated many times.
These rules are known bad so that when a request is done to the server, WAF is
comparing it with these rules. If a request matches one of the preset rules,
the request is blocked, because it is faced as malicious. Also, in most of the
enterprise WAF solutions, these rules are hidden, and no one can access or see
them. This is happening because developers believe that if these rules are
hidden, users won’t know them and neither will attackers, so it protects users
from easy bypass techniques. Of course, these rules can be bypassed many ways
that we will examine in later modules. Some common modifications to bypass
filter rules can be shown in Im- age 3. On the other hand, open source WAFs
have their rules open, which is an open call for everyone to find by- pass
methods easily, and add them to in the filter rules, which is a proven security
model of the open source community.
WAF Fingerprinting
The first thing we
need to know before starting bypassing WAFs is if there is at all a WAF in
the target, and how this WAF works.
For these reasons, we perform
WAF fingerprinting techniques, which can be separated in two different approaches
of fingerprinting. One is passive, where we try to find signs of WAF in the
HTTP responses of the web server. Many times, WAFs are leaving HTTP headers or
other interesting info about their existence, which we can find and examine, to
be able to verify it. The downside of this, is that many times WAFs give false
HTTP headers and info, or no info at all, so this technique can be faulty, or not
useful at all. The other approach is active fingerprinting. In this approach,
we examine the WAF’s behavior. Here we actively examine the web servers’
responses. Many WAFs, for example, are changing its response depending on the
way a URI is requested due to the filter rules we saw earlier. If we give two
different URIs and the one has successfully returned the re- quested material,
and the other not, then we know that a WAF is presented, and we can do some
research for this filter to be able to completely fingerprint the WAF. where we
will filter all the HTTP Requests. If we see an HTTP request where a cookie has
been added by the WAF, we will distinguish the ns_af, which in this situation
unveils that the web application firewall is a Citrix Netscaler.
Another
way of manually fingerprinting a target WAF is by examining Header alterations
that a WAF may imple- ment. Some WAF products like the Netscaler again, allow
the header to be rewritten and they can also make the web server to produce different
HTTP responses from the common ones. This many times can confuse the attacker or
automated tools that we may use.
Continuing, another interesting method is by examining the server responses. This is usually done
with two ways:
1. WAFs identifying themselves inside the response
2. WAFs replying with specific response codes
For the first one, many times WAFs respond with messages from them into the HTML code, which can be easily identifiable. For the second one, many times we can face strange response codes, like 999, that may or may not be ac- companied by a message, which repels us from attacking the system. You can see a good example from the Web-Knight WAF, responding with a 999 code.
Further
known methods for WAF fingerprint, are:
Drop Action – Sending
a FIN/RST packet from the server or client to terminate a connection (technically could also be an
IDS/IPS)
Pre
Built-In Rules – Each WAF has
different negative security signatures
Side-Channel Attacks – Many WAFs can be recognized
by the response time in a server request (Timing behaviour)