Under #2 below couldn't I "... alter the permissions of the web server by altering it's config..." as you describe in #1 as a way to attack the data and provide the web server with access to the database a second server? Both would require knowing the credentials needed to access the database.
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On Behalf Of John Jones
Sent: Tuesday, April 12, 2011 2:18 PM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] iSeries vs IIS web site
"What is an "outer" DMZ?"
(Internet) -- (Outer Firewall) -- outer DMZ with web servers -- (Inner
Firewall) -- inner DMZ with app & DB servers -- (Innermost Firewall) -- user network segment.
The purpose of the inner DMZ is to disallow unauthorized internal users direct access to the app & database servers. It keeps the marketing guys who should only access data through the app interface, for instance, from querying the (accounting) (payroll) (medical info) data directly. It also handily prevents the trojan downloaded by your CFO's niece onto the corporate laptop from finding & shipping data to unfriendlies.
"I believe that centralized architecture tends to be more secure because it's less complex, and easier to manage, particularly under IBM i."
Under some circumstances the simpler a design is the more secure. However, that isn't always the case. HTTP is simpler to deploy & manage than HTTPS but few, if any, would argue it was more secure. In a lot of places, the use of HTTPS introduces SSL offload engines to an environment so that SSL processing is moved from the web servers to an appliance. Those complicate the environment even more but they are used to make the app more secure, not less.
Closer to home, consider an app framework where there is a web server with backend database. The web server runs code that uses encrypted & authenticated access to the database. The encryption & authentication methods are compiled into the app; no source is viewable or extractable so the means by which the web server gets at the data is for all practical intents secure.
Also consider that web servers like Apache & IIS are not perfect software.
Flaws exist and there's an exploit window between the time a flaw is uncovered & the release and subsequent application of a patch. If you look at Apache's history you'll see that some bugs take many months to be fixed.
And on the i IBM will take even longer each patch has to be rolled into a PTF & subjected to IBM's own testing.
If I, with my mad haxxor skillz, can uncover & exploit a flaw I might gain access to the underlying server (probably by running shell commands within the web server or by running a shell directly). Most likely not as Administrator/root/QSECOFR but as the user running the web server.
Now take two scenarios:
1. Consolidated environment: I am free to exploit the authority of the profile the web server is running on. Depending on your app & database design and the precautions that have been implemented, that profile may already have sufficient authority to read/alter the data. If not, perhaps I can alter the permissions of the web server by altering it's config and then attack the data that way. The point is that I have a legitimate chance at gaining access to the data. Beyond that if I can get a shell I can explore the network that the system is in and look for other (potentially
unpatched/vulnerable) systems to exploit.
2. Segregated environment: I am still free to exploit the authority of the profile the web server is running on. However, I have no means of accessing the data as it is not on the machine. My only access is via the app that I cannot decompile. Also, because the only servers in the network segment are web servers I cannot get at the data from other applications.
Maybe I can figure out how to exploit the app but that risk exists in both scenarios. Ultimately my attack surface has been greatly reduced.
This doesn't even consider misconfiguration of the web server or bad authority implementations for the app. Those kinds of problems that increase the attack surface are even worse in consolidated environments.
And those kinds of problems are unfortunately somewhat common in our community. There's still a misconception that the i is automatically more secure. Windows & i both need proper configuration & administration as well as secure coding practices to minimize exposures.
On Tue, Apr 12, 2011 at 11:37 AM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:
From: John Jones
I'll point out that there is legit concern if the i-based solution
were
to
keep database, apps, and web services on a single LPAR.
I think that's a common misconception. I believe that centralized
architecture tends to be more secure because it's less complex, and
easier to manage, particularly under IBM i.
By definition the database server would be in the outer DMZ as that's
where the web servers have to reside to be visible to the outside world.
What is an "outer" DMZ? It appears to me that the only reason for a
DMZ is to isolate and hide a private network from a public one. If
that's the case, why not just use routers to define your DMZ, rather
than using a Web server to define it? I suspect that the idea of
placing web servers in one network, and database servers in another
caught on simply because Microsoft was promoting it, not because it
was actually more secure.
Unfortunately, distributed architecture is so ubiquitous that people
naturally fall in line with these unfounded notions about security.
-Nathan
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To
post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.
--
John Jones, CISSP
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list To post a message email: WEB400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/web400.
midrange.com
