× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



"That should be true, but do you really think all i shops run properly
configured systems?"

and do you really think all DMZ, firewalls and other complicated stuff adds
to the transparency in stopping loopholes ?

IMHO - The more complexibility you add - the harder it is to see the holes !

On Tue, Apr 12, 2011 at 11:14 PM, John Jones <chianime@xxxxxxxxx> wrote:

Are you implying that it must not be possible because you've never heard of
it? Keep in mind we're not only talking about the i's OS-level security
capabilities, we're also talking about potential vulnerabilities in Apache
and in the web app being served.

On Tue, Apr 12, 2011 at 1:57 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

John,

the problem is that while lots of MS IIS systems has been hacked through
their
webservers, I, at least, has never heard of an IBM i being succesfully
hacked and
there is a lot of IBM i's that runs Apache just behind a Firewall.

Of couse sequrity has to be configured properly, so it has to be in a
multi
box
environment.




On Tue, Apr 12, 2011 at 8:17 PM, John Jones <chianime@xxxxxxxxx> wrote:

"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.




--
Regards,
Henrik Rützou
http://powerEXT.com <http://powerext.com/> <http://powerext.com/>
> --
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.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.