- Posted by: Paddy Murphy
- Posted on: July 03 2003 09:26 EDT
A few years ago, when I first started working with J2EE and general web architectures, the "rule of thumb" was that is is best to minimise the amount of functionality that was placed on servers in the DMZ (De-militarized Zone).
Consequently, it was normal and recommended to place J2EE (EJB etc) logic behind the DMZ, and even the Servlet/JSP container behind the DMZ if possible - thus resulting in the web servers alone being in the DMZ.
However, nowadays, there seems to be a shift away from this, and in fact I have seen a number of recommended architectures that include not only the JSP/Servlets, but also EJB container within the DMZ (accessing a database via the second firewall. Oracle for example, seems to be quite ok with placing the OC4J in the DMZ.
1) Are my observations correct?
2) What has changed over the last few years that makes it ok nowadays to place such functionality in the semi-insecure DMZ zone?
All help greatly appreciated.
- Is it ok to put J2EE Application Server in DMZ or not? by Paul Strack on July 04 2003 08:25 EDT
Personally, I have always thought that people who advocate putting your app server behind you DMZ were being too paranoid. Provided that your external firewall chokes off access to every port other than 80 and 443, there should not be a way for attackers to access your J2EE server.
The only argument against this is if there are flaws in your firewall structure that let people inside. But if there are, I think the attacker is likeliest to attack your OS before trying to hack your app server.
My guess for why attitudes are changing is that the technologies are more mature. Now that both app servers and firewalls have been around a while, organizations are likelier to trust that there are not unexpected holes in the infrastructure. That makes them more willing to trade better performance for a slightly less secure architecture.