Re: iSeries vs IIS web site

Protecting your httpd.conf file is simple:

# Hide Apache Configuration Files
<Directory /conf>
order allow,deny
deny from all
</Directory>
No one can access this file from the outcomming
On Tue, Apr 12, 2011 at 11:44 PM, John Jones <chianime@xxxxxxxxx> wrote:

Yes, but as with most things in the security world it isn't an
all-or-nothing proposition. This is about finding the right balance. The
remove-complexity process would probably be a big failure if taken to the
extreme and a company went so far as to remove the complexity that their
outer firewall adds. Likewise, the cost & complexity of application
firewalls will be too much for smaller companies.

Segregation of what is exposed and what you want to protect makes sense.
Consider it part of defense in depth. The resources (time, money) you
devote to that segregation should be determined by your company's
tolerance
for risk.

My point is that we should not just assume the i is secure. Making it
acceptably secure takes time, effort, and skill. And in some cases vendor
cooperation if using a 3rd party app with a poor default security design.
Not all shops have the right combination of those resources.


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

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

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.

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

--
Regards,
Henrik Rützou
http://powerEXT.com <http://powerext.com/>