|
Close but not exactly the correct description. typically it is one router, not two. just the router has three interfaces. outside connects to public IP line. inside connects to your internal network and DMZ interface connects to a separate subnet where any servers that have to receive requests from eh "untrusted outside" world. (yes it can be done with two separate firewalls). Now, one router is no less secure than the other router (or interface). It is just a system of walls to filter out untrusted traffic. This is really the inaccurate statement "> The internal router might only allow access to the inside from one particular IP address - that of the webservice machine." Allowing access from that singular IP address allows you no security. The reason is, if someone compromises the DMZ, they are attacking from the compromised server. Well, you are trusting that server to get in your internal network, so you have no protection. The internal router (or interface) only allows the IP of that server AND blocks all ports except those that are necessary to get through. You do not let all port access. So, as an example, if it was an email server in your DMZ, the internal router would ONLY let DNS, SMTP and POP ports to connect. Any other ports would be refused. This way, even if the email server is compromised, the only way they can get into your internal network is via trusted protocols that the application should have security measures also implemented on. ----- Original Message ----- From: <rob@xxxxxxxxx> To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx> Sent: Monday, August 04, 2003 2:53 PM Subject: RE: iSeries vs. Unix vs. SQL Server vs. Oracle &Security/Data separation??? > I think the experts suggest this because of the DMZ concept. > DMZ = DeMilitarized Zone. Taken from that strip of no man's land between > North and South Korea in which the militaries of both sides do not enter > because of the uneasy truce there. > > In the DMZ concept you have, in order: > The Outside > Your external router > A webservice > Your internal, more secure, router > Your backend data > The theory being that if the Cisco Kid screws up something on the external > router and an outsider performs a Denial Of Service attack, or some such > thing, then your backend data is not affected. > The internal router might only allow access to the inside from one > particular IP address - that of the webservice machine. Our current > webservice is Domino running on an iSeries. > > Rob Berendt > -- > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > Benjamin Franklin > > > > > > McIntyre Don <dnmcin@xxxxxxxxx> > Sent by: midrange-l-bounces@xxxxxxxxxxxx > 08/04/2003 01:35 PM > Please respond to Midrange Systems Technical Discussion > > To: Midrange Systems Technical Discussion > <midrange-l@xxxxxxxxxxxx> > cc: > Fax to: > Subject: RE: iSeries vs. Unix vs. SQL Server vs. Oracle & > Security/Data separation??? > > > I like the idea of running all applications & data on > one iSeries. And I also know that the iSeries is up > to the task. > > But what frustrates me on this subject is that the > experts at IBM & others also advise Data separation > which is to separate the Web or deployment Server > (Java Application server i.e. WebSphere Application > Server) from the data residing on the iSeries. The > (experts) advise installing Websphere on one > machine,whether it is a Microsoft box or another > iSeries (they don't necessarily push iSeries for > this), then access the data on the secure iSeries box. > > Can't Websphere & data reside on one box with the > proper security setup? If so, then this is what > should be advised. > > Therefore all my preaching to peers & upper management > to use a single iSeries is thrown out with this > suggestion. > > Don McIntyre > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing > list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.