On 04/05/02 6:40, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:fw2 allows only specified server(s) to required specified port(s) which is different from app server port. This same concept can be used for both external users (external DMZ) and internal users (internal DMZ). If you use proxy for internal DMZ then all internet traffic is isolated in external DMZ segment. This is a standard J2EE infrastructure.
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?
This is why all user inputs needed to be filtered and validated. All http injections, sql injections and command injections can be greatly reduces using tomcat security (ref: oreilly book of tomcat definitive guide). This is also a reason why Struts is so popular because it also has application firewall.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!
If you use Linux iptable then you can have each server firewall. So, fw1 (that can be load balance) is like the building security guard that accepts requests and give responses. external DMZ is like the building main floor that fw1 directs valid requests to and receives responses. fw2 (that can be load balance) is like the floor security guard that handles only requests from specified office (server) in specified floor (network segment such as internal DMZ. Private network can only communicate with internal DMZ). The server firewall (using Linux iptable) is a security guard in front of each office that make sure only valid request(s) related to the application handled by the office can get through. Application using Struts has application firewall that make sure all valid user inputs are in its own form and uses its own form to process the valid request.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).
Struts chain of request/response framework will enable much finer detail authorization of corporate resources.
BaTien DBGROUPS
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]
.
