On 04/05/02 6:40, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> DMZ is short for "demilitarized zone" ... a term adopted for enterprise > network infrastructures from the military use of the term. > > If you're writing an application for public access on the Internet, > you'll find that the net is not a very friendly place ... there's lots > of attackers out there. One of the common architectures is to separate > your environment into tiers -- for example: > > Database -- Firewall2 -- AppServer -- Firewall1 -- Internet > > so that, even if someone can punch through Firewall1 and corrupt your > app server, they (hopefully) cannot also penetrate Firewall2 and corrupt > your database. The traditional term for the servers between Firewall1 > and Firewall2 is the DMZ. > I heard about the concept, but never came upon the terminology (DMZ) :) Just one question, if one breaks fw1 and corrupts AppServer, then one can make whatever he wants to the database through the AppServer host itself. The fw2 must accept requests directly to the db from the appserver, right? What's the point of fw2? Just filter more ports than the ones filtered on fw1? In terms of the web app, issuing a "DELETE * FROM some_table" ordinary jdbc statement with the right parameters could access the database with no problems in the way! I think I am I missing something here? I thought that firewalls only served to present the wanted ports (HTTP, FTP, etc) to users outside the network/host and weren't that intelligent (actually I thought that was the whole point -> a fw should have the minimum software installed for its purpose so that if it gets broken, then the attacker has less changes of doing much harm). > Some folks go further and separate the web server (that responds to HTTP > requests, but often still contains the JSP pages and servlets of a > Struts-based front controller) and the app server (that performs your > business logic, and contains EJBs or the equivalent) into separate tiers > as well, which is where the term "three tier architecture" came from. This last example makes more sense to me. If one has access to the webserver itself and even if wants to emulate some kind of abnormal behaviour (in the limit, implement a whole new web app that runs on that server - it may need some time though), then at least the business logic rules will apply and prevent some kind of attack. In this case the database is protected. To access it, then there should be another security flaw besides the ports/services that are allowed to run between the appserver and webserver. Another possiblity is appserver business logic provide "services" to the web server that could lead to a security problem or inconsistent state. Regards, Pedro Salgado --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
