Your INNER WAF

I wanted to cover some WAF topics I haven’t seen covered much. Most WAF vendors talk about the security their product provides in terms of blocking attacks. I would like to delve into these WAF Blockings as well as mention some ideas for alternative uses for your WAF through it’s interactions with web clients.

Web Application Firewalls are interesting bits of technology. Depending on the product and deployment method you chose, they can transparently protect your web infrastructure using various protections by generating blocks when threats are identified. Depending on the product, they can Vulcan mind meld with your Apache instance, live as another F5 device in your network, take over a slotin your XBeam, or live life as a network appliance inside your datacenters.

This intelligent device COULD interact with the client in additional ways outside generating BLOCKs. For example: developers could leverage a WAF to provide additional protections, send notices to connect clients under specific conditions, or even prompt a client for confirmation before performing a specific function if certain criteria are met. After all the BLOCK a WAF generates doesn’t have to be a BLOCK at all, at least not in the context of traditional firewalls or even active-response IPS devices.

If WAF interaction with the client is a concern because you’re trying to keep your WAF invisible to the bad guys, you should know that that’s not a realistic expectation.

WAF’s block threats to your web applications identified through various security methods, but what does that mean?

There are a few options, largely dependent on the vendor and deployment method (transparent bridge, proxy, router, offline sniffing): TCP Reset, Request/Response DROP, out of band Reset via 3rd party. There’s no hard-fast requirement to only use a TCP Reset that’s sent to client and server, like IPS or active-response causing the TCP session/connection to be terminated, but this is controlled by deployment method.
The DROP method is like a virtual trapdoor inside the WAF where malicious traffic falls into a dark pit, never to be seen again.

Some WAF products can send a web coded response back to the web user inside their active session indicating their request could not be completed, some WAF can be configured to quarantine an IP Address or terminate a web session, in addition to dropping the client request or server response. The use of WAF generated error pages to interrupt and/or stop the web session alongside Request/Response dropping is more graceful than TCP Reset. Depending on your environment, TCP Resetting could create unexpected results on your web servers and typically this requires your WAF to be operating in Proxy mode.

In traditional transparent WAF deployments, these BLOCKs generated by a WAF are typically nothing more than a standard error page or a redirect to a logout sequence coded within the web application being protected.  Some WAF’s allow you to customize the page, insert scripting, and push it seamlessly to the end-user inside the existing SSL session. Alternatively, the client could be redirected to a destination within the protected application to log out their session, collect additional information, or open a support ticket (although the last one of those I saw, was more for looks than functionality).

If the WAF can generate web pages in response to client interactions inside an existing SSL session, the client would be interacting with the WAF. The Imperva Application Defence Center (ADC) has an interesting web fraud paper on enabling clients to interact with what I would describe as a security control panel, to help with CRSF/XRSF attacks and web fraud. I have played around with this a little and found some interesting uses – sorry saving that info for my next contracting gig!

The idea of using policies to trigger BLOCKs takes on a new meaning, if the WAF can be leveraged to a generate unique or controlled web pages when a specific policy is triggered or even redirect a user to a specific function inside an application if certain criteria are met, before continuing on inside an application. Don’t get me wrong, TCP Resets are good too – but this path offers much more robust options for a company from multiple perspectives.

Now the WAF can be used to not only BLOCK pure security-centric threats but also control the application behavior and client interaction if something fraudulent, abusive, or irregular is detected. For example you could leverage the behavior deviation capabilities of your WAF (profile violations) and construct a temporary input validation error handling process inside your WAF while your coders developed the handling inside the application. This would be a straight forward use of the acquired knowledge of the WAF, a simple error page containing the prohibited characters, and a method for the client to have a “do over” on the prior page.

Once again, the WAF is providing additional capabilities that an IDS/IPS cannot!

Top 4 WAF Protections

The traditional network security approach to securing your web servers and database servers is more than likely going to get you in trouble some day. Think about it. Network Security preaches deny everything and permit only what you need. Great, open up port 443 and send encrypted traffic to your web server. KaBOOM gotcha!

Think about your Web Application Firewall and the reasons for your investment in web application security.
Regardless of the technology you have selected, here are four protections your WAF investment needs to be providing:

#1 Enforce decryptable web communications.
This might seem counter-intuitive but first and foremost, if your WAF can’t see it – then the WAF can’t intelligently PROTECT your assets! You need to disable any encryption not supportedby your WAF. It’s a long-standing double-edge sword securing web communications but still being able to inspect the communications. No more pre-shared or temporary key SSL sessions, sorry Diffe-Hellman, most WAF’s only support pure RSA. In addition, this is a good time to make sure your servers negotiate at a respectable bit length.

#2 Enable Correlation.
Attack signatures are great, but correlation is better. If your WAF doesn’t offer some form of correlation of multiple signatures and security events before triggering an alert, you might consider picking one up that does. Web Intelligence is a good product, but it’s not an F5, Breach, or Imperva WAF, and that difference could cost you.

#3 Serve & Protect, becomes Learn & Protect.
The best offense is a good defense. If your WAF knows what the application it’s protecting looks like or even better, how it behaves, then the application’s very own structure, coding, and URL/parameter make-up becomes it’s shield against malicious attacks. You don’t need to wait for a signature to protect your web application from new SQL Injection or XSS or Fuzzing attacks, if the WAF is stopping anything that doesn’t conform to expected behavior!

#4 Assess THEN Customize.
When you build a new house, you might expect to have certain things done specific to your requirements before you ever set foot inside the house but you’ve at least looked at the blueprints and seen sketches of the final product. For a WAF guarding a Web Application, custom rules really should be the last thing you do, and ideally AFTER you validate existing protections aren’t enough through penetration testing or code scanning. The major WAF vendors support the inclusion of vulnerability assessments in their products for custom policy creation.

Obviously enabling any of these are subject to your risk exposure / tolerance, but I wouldn’t advocate running for any length of time without these protections regardless of the organization or the other protections you may in place to guard your web applications.

Consider what every online entity is up against, there is more money to be made hacking your protected assets by nefarious (hopefully external) sources than you have resources or funding – short of government entities. If that wasn’t bad enough there are newly coded applications and updates released every minute than there are security fixes going in. If you’re not fully leveraging what you have and not securing as you go, then your company is leaving something undone for the bad guys to come along and exploit.

How is your WAF being used? Is it being used? Need help getting more out of your WAF?

WAFing it up

I should disclose up front that I derive my living today supporting WAF technologies for a large corporation, and so it will come as no surprise that I have a few opinions on the use of WAF technology and in general how to go about protecting web applications.

Purists.
If you’re a purist and feel adamantly for or against Web Application Firewalls, I would urge you to consider the roots of defense-in-depth – just like the spoon in The Matrix, there is no silver bullet. OWASP’s concepts are as close as we’ll ever get to that silver bullet.

Secure Coding won’t get you out of every vulnerability and neither will a WAF, if for no other reason than the sheer complexity of the equipment needed to stand up web-enabled services introduces too many interdependencies to think every coder, developer, and vendor got everything right and there will never be a problem. — If you disagree with that, put down the Vendor Kool-Aid now before it’s too late.

Positive / Negative Security Models
Good grief.  Techie speak if ever there was any. Reminds me of the James Garner movie Tank, where little Billy is exposed to negative feedback in order to arrest his “bad” behavior. In my house, that’s called a spanking and you get one when it’s appropriate. My kids know what a spanking is and so does anyone reading this thread. Without googling, name two WAF products based on each of these Security Models: Positive & Negative — It’s okay, I’ll wait for you.

And we’re back…
On the topic of Security Models, I tend to think it takes a combination of protective technologies to provide any actual risk/threat  mitigation. I would personally like to see developers take advantage of a WAF’s ability to see how an application behaves. Moste developers don’t think of in terms of which web page does what, instead they’re working with APIs and objects. This is unfortunate because the rest of the world sees these applications as URL’s. The WAF can be that bridge to the developers. A WAF could in theory help the developer ensure that a specific sequence of events happens before a transaction is processed or prompt the client before transactions occur in specific instances to avoid CRSF.

To bring things back around to my original point. I do agree that the more complex a web application is and the more servers required to make a service available online, the more vulnerable and difficult to secure that application or service will be. I’m not sure who’s law that is but I’m sure one exists, complexity breeds more complexity.

No surprise there, if you are protecting a complex asset then it will be high maintenance – I said to put down the Kool-Aid, it’s for you own good – nothing is free!

Network Zoning – Be the Zone

A while back I started a series on Network Zoning and like most procrastinating, over-achievers: I got side-tracked (is that a self-induced form of ADD?) ! I have had the pleasure of interacting with a number of folks on the zoning topic, and so I wanted to take a moment to tack on an additional concept that doesn’t always get much attention but is very relevant in your network zoning design.

PERSPECTIVE and the impact of perspective.

Perspective in Network Zoning is a little like determine the perspective of an email without knowing the sender. If you’ve ever sent a witty email to someone who didn’t share your sense of humor, you’ve been impacted by perspective. Please be careful not to confuse perspective with context. Perspective deals with a vantage point, while a context is the surrounding details.

When zoning, the perspective of the actual components, users, and threats dictates a given device’s zoning requirements. Theoretically perspective actually defines the security posture.

Did that hurt? Just a little?

The configuration for each of these devices in this illustration is relative to their location in the network. Their perspective determines their configuration. Obvious right? Please keep in mind, the External Firewall or Internal Firewall could easily be a router with ACL’s

Consider that the External Firewall in this illustration sees untrusted incoming traffic and passes only traffic based on rules for the more-trusted networks.

This “trusted” traffic of the External Firewall is actually UNTRUSTED TRAFFIC for the Internal Firewall! After all this is the UNTRUSTED interface on the Internal Firewall.

The Internal firewall can be configured with the same blocking rules of the External Firewall in addition to new rules that are applicable to protecting the Internal Networks.

The addition or the difference in security configuration for internal or external firewalls will be controlled in-part due to perspective because you could obviously implement the same overall security policy on both firewalls but the expectation for what threats exist where will be based on perspective.

In the same light, your zones will have traffic or usage patterns and requirements relative to their placement in the network. External DNS servers will be configured and protected differently than Internal DNS servers. Network resources talking across zones will work differently than talking inside a zone. Your security practices and configuration will change accordingly. The configuration for a given zone will be driven by perspective – requirements will map out differently based on the perspective of users, threats, and policies.

Perspective will show up within the logs as well. When you review the logs on your devices, you will react differently to external threats to your internal servers logged on the actual internal server versus the External Firewall.

When you build out your network zone, be sure to keep perspective in mind. You may choose to overlap policies as a defense in depth practice, but please take care to define your zoning appropriately.

What’s your perspective?
Drop me a line and let me know!

Network Zoning – In the Zone

Traditional network security featured two or three zones, whether they were thought of in terms of zones or not may depend on the organization. Certainly everyone is failure with DMZ; however, modern approaches to network security don’t stop at the perimeter. This is where these new zones come in.

In the early days of network security, the consensus was: place a firewall at the external touch-points of your network with two or more network interfaces. If you ran any public services, locate them inside something called a DMZ or screened-network and restrict access to/from those devices for internal systems. 

This should sound familiar, welcome to Network Zoning. The post-modern era of network security takes this DMZ approach and marries it with the principle of trust/privacy, so that the internal network can be carved up into segments providing increased security, compartmentalization, and privacy for users, services, servers, customers, etc.

In the earlier posts I referenced the idea of grouping like-functions of an internal network by vlan and/or IP subnet. This segmenting, grouping, partitioning, or zoning works just like the DMZ approach of traditional network security with the exception that the rules for access will be different and the “firewall” is internal. Here comes the tricky part.

Implementing the segmentation part can get complicated. I recommend vlans and different IP Address ranges as a general architectural practice, but it is possible with modern technology to insert transparent firewalls (let firewalls be firewalls) to facilitate rapid firewalling of network segments without having to implement vlans and IP Addresses.

These zones form boundaries inside the network, if you implement traditional firewalls they represent layer 3 boundaries and if you implement transparent firewalls they represent layer 2 boundaries. The outside boundaries should be thought of as untrusted, DMZ-like boundaries should be untrusted or semi-trusted, and depending on the user community the internal boundaries may be trusted.

These boundaries isolate trusted, untrusted, and semi-trusted devices and services from one-another and form what is referred to as a trust boundary. Trust boundaries can then be used to form privacy boundaries, where decisions are made segment trust implied within these various segments.

Getting back to the zoning concept, one design might feature an external firewall or set of firewalls (if redundancy is preferred) that provide the first barrier between the Internet and Internal users. Assuming the organization provides DNS, Email, Web, or other publicly available services, this firewall will provide an external DMZ as well. This will create one untrusted zone and one semi-trusted zone that will interface with an internal firewall/router acting as a semi-trusted barrier (zone) where the actual trusted zone(s) live.

The firewalls in this diagram can be routers, switch routers, firewalls, or a combination. The key is selecting hardware/software that will support the particular environment and needs of the organization. Firewalls come in all flavors, colors, and sizes these days and many do more than just filtering of packets, including deep packet inspection, IDS/IPS, load balancing, malware scanning, and web content filtering. Most routers on the market today can provide packet filtering / inspection in addition to traditional routing functions with minimal performance implications.

This specific architecture addresses minimal internal and external security from a zoning perspective needed to produce a trust barrier where internal systems should be protected from external (untrusted) systems. If the Internal Servers segment is firewalled from the Corporate LAN segment in this diagram, then four (4) security zones will form a privacy boundary in addition to the trust boundary where servers are isolated from users and outsiders are isolated from insiders.