On 04/05/02 6:40, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote: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.
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?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 :-).
Nope ... the fw2 and database machines typically use much more rigorous tests over whether such things are allowed.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?Yep ... firewalls are only one piece of the puzzle.
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.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).
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.
CraigSome 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]
