Re: iSeries vs IIS web site

[Henrik Rützou <hr@xxxxxxxxxxxx>]

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.