Fronting WebSphere - Is a DMZ zone a war zone?
Brownrob 2700006G6F Visits (6405)
Hello again, and welcome to my blog entry on the subject of "Fronting WebSphere" with bundled Proxy and Load Balancer products like IBM HTTP Server (IHS webserver), WebSphere Plug-in proxy load balancer module for webservers, Edge Caching Proxy and Edge Load Balancer. The subject for this blog entry is the first of a series to cover some basic concepts related to using proxy and load balancing to front WebSphere Application Server (WAS) JVMs.
During the Vietnam war there was a politically designated neutral zone between North and South Vietnam called the DMZ zone. DMZ was acronym for DeMilitarized Zone or DeMarcation Zone. Modern day Korea has a DMZ zone between North and South Korea. As Wikipedia puts it:
"A demilitarized zone, DMZ or DZ is an area in which treaties or agreements between nations, military powers or contending groups forbid military installations, activities or personnel. A DMZ often lies along an established frontier or boundary between two or more military powers or alliances."
In IT terminology DMZ is acronym for same verbiage but, quoting Wikipedia again under DMZ (computing):
"In computer security, a DMZ or demilitarized zone (sometimes referred to as a perimeter network) is a physical or logical subnetwork that contains and exposes an organization's external-facing services to an untrusted network, usually a larger network such as the Internet. The purpose of a DMZ is to add an additional layer of security to an organization's local area network (LAN); an external network node can access only what is exposed in the DMZ, while the rest of the organization's network is firewalled."
Often a company's DMZ zone is the first subnet where the company's WAN provider link ends and connects to the company's ethernet. A telco T1 or T3 WAN line might end in a CSU/DSU unit which is a form of high speed modem which has an ethernet output (albeit that may be an old method in light of today's technology). Therefore depending on a Company's IT structure and WAN topology they may have a single DMZ zone or a DMZ zone at every physical branch office.
WAS appservers support an HTTP(S) connection. Sometimes customers ask why they need to use a proxy front if they can connect directly over http. The answer is that WAS appservers are based on Java JVM. JVMs are not secure enough to reside in a DMZ zone subnet. So even if you only have one appserver you still need a securable proxy in the DMZ to front it by the time you get to production. However do not wait until then to test the app with a proxy front. As transparent as we would like a proxy to be, application behavior can change or be affected by a proxy. The connection from proxy to app may include extra headers. Proxies are more picky about response headers and their values than a browser would be. Proxies might add response headers that are missing in the response from app/appserver. So comparing a client direct connect to an appserver and then via a proxy is more of an apples and oranges comparison so, don't sign off on an app if it has not been tested with a proxy front. If you expect high availability the app should be tested in a clustered environment. Keep in mind that WAS server types like Proxy Server and ODR server are also based on JVM and so their profiles are also not secure for DMZ.
So what is this leading up to? Be sure to look for my next blog for a brief history about why webservers running the WAS Plug-in proxy load balancer module are the most common form of proxy load balancer front for WAS JVM (HINT - webservers are DMZ securable). In that blog I will also cover what's good and not so good about static PLG load balancing and why Intelligent Management enablement of PLG (dynamic load balancing) is our answer to the limitations of static PLG load balancing. So when I refer to DMZ in my next blogs you now have a basic conceptual understanding of what a DMZ zone is, right? Kind regards.