Kevin,

Basically, your "microsoft" people are correct. Although a System i
can be as secure as any other system, from the security paranoia point
of view it is best to let a "bastion" server handle all of the direct
connection to the internet. This is just in case a direct attack on
the web server infrastructure succeeds.
Fortunately, you can have the best of all worlds by placing a simple
apache reverse proxy in the DMZ, and tunneling all of the http traffic
through the reverse proxy to your system i. This way, the system i
serves the web site, but an expendable box is connected to the web.

However, no infrastructure setup will protect you from application errors.
Take a look at the OWASP top ten web application security flaws. 9 out
of 10 are relevant to the system i.

http://www.owasp.org

OWASP is the best single source of web application vulnerabilities,
both generic and language specific. If your web site will contain Java
or PHP, then you will find at OWASP a lot of good advice.

In my book, at www.venera.com, I have some examples of iseries web
application errors and flaws, like unvalidated input, undeclared
global variables, and sql injection.

Regards,
Shalom Carmel
----------------------
www.venera.com




 The question that I have is, 1) Do any of you have a set up similar to
this?  2) Is this scenario "secure enough"?  I know that it is not
necessarily the "recommended" approach but it gives flexibility in it's
setup for taking down certain sites and not others etc.



 Another question is there a web site or place where there are reported
system I web hacks or breaches through the web?  This has become a large
topic in our shop and something that looks like it could become a holy
war between system I and Microsoft servers.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.