A Little bit of history...

In July 480 B.C., the great Persian army conquered the Greek city-states on its way south, and soon all of northern Greece would be surrendered. In order for the small Spartan army to successfully resist, it needed a narrow space to which the large Persian army could only send small contingents. Such a place existed: it was the pass of Thermopylae; there the Spartans steadfastly defended the strait on an equal footing as the days passed and Xerxes despaired. But then the Persians, with the help of a traitor, discovered a narrow road leading through the mountain to the other side of Thermopylae, thus trapping the Greeks from their rear.

Some 2,400 years later, in the early 1930s, France, the winner of the so-called Great War, fearful of the threat posed by the growing uprising of National Socialism on its northern border, would give impetus to the construction of the Maginot Line: a series of static defensive fortifications on the border with Germany and Italy. When, in May 1940, Nazi Germany decided to invade France, it would do so with its main force through the forested area of the Ardennes in Belgium, which had been considered by the French to be impassable to armored forces, thus managing to reach the rear of the Allied army.

It has not been rare in history, that a situation or supposedly advantageous element turns out to be ineffective either due to unusual or unexpected scenarios, and that therefore have not been controlled (in risk management, it is known as the "black swan" theory) or simply due to bad implementations or as a result of compromise solutions.

What does a WAF do?

In order to protect publicly exposed websites, web applications or APIs from attacks, most companies choose to deploy a Web Application Firewall (WAF), so that any attempt at attack is blocked before it materializes.

The main functionality of WAFs is the filtering, monitoring and transformation (decoding and sanitization) of HTTP traffic, operating at layer 7 of the OSI model, unlike a traditional network firewall that operates at layers 3 and 4 since it is only capable of inspecting IP packets of the TCP/UDP protocols in order to filter by IP address, port and protocol.

This HTTP traffic processed in the WAF is inspected using a set of rules or policies to detect a particular type of attack such as those identified in the OWASP Top 10 or CWE Top 25: Cross-Site-Scripting (XSS), SQL injection, Insecure De-Serialization, Cross-Site Request Forgery (CSRF), Unvalidated Redirects and Forwards and many more.

Among the recommendations and good practices of the industry, Payment Card Industry (PCI) Data Security Standard stands out, which in its requirement 6.6 indicates us:

For public web applications, continuously address new threats and vulnerabilities and ensure that these applications are protected against known attacks using one of the following methods: …

  • Installation of an automatic technical solution that detects and prevents web attacks (e.g. web application firewall) in front of public web applications in order to control traffic continuously".

At present, a WAF can be deployed at several levels according to its typology:

  • Appliance or on-site WAF device: hardware physically interposed between the connections of a local network; typically the WAF functionality is added within a new generation network firewall:

01

  • Software/Application or WAF module: typically installed and executed as an additional module to the application's web server (e.g. ModSecurity for Apache, WebKnight for IIS) or on a dedicated server on the local network acting as a reverse proxy (e.g. NAXSI module of the NGINX proxy)

2-1

  • As a cloud service (cloud WAF): WAF functionality offered by a cloud service provider under a PaaS or SaaS model where the user is solely responsible for its configuration.

diagrams-04-1

The adoption of cloud solutions is clearly on the rise in recent years to the detriment of other solutions, motivated by the great advantages it offers:

  • Delegated responsibility for the maintenance and management of physical infrastructure
  • Less effort in configuration.
  • High flexibility and scalability.
  • Payment according to use.
  • Requirements and controls of norms and standards delegated to the supplier (e.g. PCI DSS, ISO 27003, NIST, etc.)
  • Deployed globally at an international level
  • Provide additional functionality such as preventing traffic originating from bots/spiders/crawlers, detecting and mitigating distributed denial of service (DDoS) attacks, geolocation rule enforcement, etc.

There are many providers that offer some kind of more or less complex WAF service in the cloud, some of the best known are Cloudflare, Akamai, F5, Amazon Web Services, Microsoft Azure, etc.

The Issue with Cloud WAF

When we proceed to add a WAF cloud to our environment, we usually follow these general steps:

  1. In order to redirect the traffic from the client's browser to the new WAF cloud, we proceed to make a change in our DNS records, so that our domain is resolved to the WAF cloud service.
  2. In the WAF cloud itself, we configure the rules for re-routing the connection to our servers, once all the traffic has been filtered and sanitized.
  3. Of course, any SSL/TLS encryption tunnel must either have a termination in the WAF cloud, or this tunnel must be intercepted so that traffic can be inspected by the cloud.
    Note: the fact that the WAF service provider must have access to the traffic in clear, may mean that it is subject to compliance with laws, standards or regulations such as PCI DSS (applicable to the storage, processing or transmission of card data) or others applicable as the case may be.

In general, with these steps we would already have a WAF deployed at the front of the website, web application or API; however, this is not always true: if access is not made by DNS resolution of the domain, anyone who knew the original IP could attack it without their traffic being intercepted and sanctioned by the WAF:

diagrams-02-1

The problem usually arises when, after a previous publicly exposed environment, we perform the steps mentioned above and leave access to the original IP unrestricted.

Firstly, a hypothetical attacker would try to identify the presence of a WAF that could alert and prevent his intrusion attempts; to do so, identification tools as common as the following are usually used:

  • NMAP, perhaps the most common and widely used connection and server discovery tool (https://nmap.org)
    #> nmap -p80,443 --script http-waf-detect,http-waf-fingerprint mycompany.com
  • WAFW00F, specific tool for WAF discovery (https://github.com/EnableSecurity/wafw00f)
    #> wafw00f https://mycompany.com

When the identification of the WAF is positive, is when the potential attacker will try to identify which is the original IP of our server before devoting efforts in much more complex techniques of evasion.

For the enumeration of server IPs after the WAF, it is very common for the attacker to employ tools such as the following:

Once the attacker has identified the original IPs in our environment, these will become the main attack vector as they are less protected.

For all these reasons, in order to limit the exposure of these weak points of the environment, it is essential to carry out some kind of protection or strict limitation of access to the original IPs only from the services of the Cloud WAF, via firewalling rules that limit the IPs or domains of incoming connections.

Conclusion and general recommendations

  • We should always deploy a WAF either on the host itself, at the network level or in the cloud over any publicly exposed application.
  • In the case of contracting a WAF in the cloud, it is essential to limit access to the original IPs to only those connections originating in the WAF service itself, by means of strict firewalling rules.
  • The WAF must be carefully configured with the appropriate rules in mind:
    • The language used.
    • Protocols, methods and expected codifications.
    • Own characteristics and known vulnerabilities of the WAF and web server of the application deployed.
    • SSL/TLS encryption supported by all elements involved in the connection.
    • Mistrust of HTTP headers and any parameter sent by the client.
Column Header Text Column Header Text Column Header Text

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Discover More

Advantio_Blog_DNS_Diagram_V1 Image caption goes here. This is HTML text.

Ero Rodriguez

Written by

I am the Senior Security Consultant in Advantio. I have more than 10 years of experience working mainly in the Spanish market. My information security background includes system administration, consultancy, risk advisory services for technology, compliance and legal, design and development of documental frameworks, among others.

CISM, CISA, CRISC, PCI QSA, QSA (P2PE), ISO 22301 LA, ITIL F