Pedro Salgado wrote:

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.


That depends on what fw2 accepts as validity of the origin of a proposed transaction. Obviously, one of the rules is to accept only transactions from the "AppServer" IP address, but that's not sufficient since IP spoofing might be employed. Therefore, other measures are also typically utilized.

The fw2 must accept requests directly to the db from the appserver, right?


That's not actually common ... what usually happens is that you're interacting with some sort of objects on the "Database" node. In fact, this is the classic design pattern for EJBs :-).

 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!



Nope ... the fw2 and database machines typically use much more rigorous tests over whether such things are allowed.

I think I am I missing something here?


Yep ... firewalls are only one piece of the puzzle.

 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).



Even if that is all your firewall does, it prevents a class of attacks (enough to make them worthwhile even if you do nothing else). But your overall security architecture definitely needs to do more than just port filtering and that sort of thing.

That's the sort of thing that J2EE app servers are designed to deal with. You don't need all the security features for a departmental intranet app with 10 users, but when you need it ... you DEFINITELY need it.

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



Craig


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to