RE: iSeries vs. Unix vs. SQL Server vs. Oracle & Security/Data separation???

["Nathan M. Andelin" <nandelin@xxxxxxxxxxxxxxxxxxx>]

I occasionally hear of companies who won't run the OS/400 HTTP Server for
"security purposes", sometimes explaining that they have a policy against
connecting their AS/400 directly to the Internet.

They use that reasoning to generate workarounds (sometimes elaborate ones),
which sometimes actually lead to less secure, more vulnerable, less
reliable, more difficult to administer, and poorly performing interfaces.

Some developers feel that by creating their own communication protocols,
filters, and message translators, using IIS scripts, and Windows executables
to interface with OS/400 resources is more secure.  I generally don't agree
with this.

Running the OS/400 HTTP Server is NOT connecting the AS/400 directly to the
Internet.  Generally, a series of standard routers and firewalls separating
an iSeries from a public IP address offers better filters, translators, and
other services than programs we might create with VB scripts and Windows
executables.

Firewalls offer a fairly broad range of services.  I'd encourage developers
to learn more about them.  They are more advanced than most developers know.

Creating our own socket clients and servers, and using our own message
protocols, generally does not improve upon the security of the standard
servers and protocols that come with the box.

Consider the idea of a socket server restarting itself whenever it receives
a message it doesn't understand.  Would anyone ever write an HTTP server
that way?  Firewalls validate communication protocols.  Applications
validate messages.  Having the custom written socket server validate
messages doesn't sound like a great idea to me.

Consider the idea of dividing an application between two boxes for
performance reasons.  What is the slowest form of interprocess communication
known in the computer industry?  Using a socket over a LAN would rank near
the top.

Consider the idea of using ODBC or JDBC interfaces to connect a Windows or
Linux application server with an OS/400 database server.  These interfaces
are inherently difficult to secure and perform relatively poorly.

Using native iSeries languages and interfaces one can access a database and
generate an HTML stream and return it to a client in about the same number
of CPU cycles it takes for one of the OS/400 database servers to generate an
ODBC structured stream and return it to an IIS application - which then runs
through an IIS interface to finally generate the HTML.

Consider the extra knowledge and technical skills required to support
multiple platforms.  Consider the extra coordination to support development
across multiple platforms.  Consider the administration of security across
multiple platforms.  Consider the extra software and maintenance required to
support multiple platforms.

Nathan M. Andelin
www.relational-data.com


> > Is the W2K server a weak link in the chain of servers separating your
> AS/400
> > from the Internet?  What if the W2K server were compromized?  Would
> > replacing the W2K server with an additional firewall offer more secure
> > separation?
>
> If the Win2K server is compromised, only that si compromised.  No one is
on
> the hardware where the data resides. There should be a firewall SEPARATING
> the Win2K box and the AS/400.  Not sure what you mean by replacing it with
a
> firewall.
>
> > Is that any more secure than opening only one port from a firewall to
the
> > OS/400 HTTP Server?
>
> Extremely.  With HTTP, you have to accept all incoming requests, no matter
> hwo they are formatted and hope the HTTP server filters out illformatted
> requests.  With it goign to an application of custom design, you can
filter
> out illegal requests and do proper data validation.
>
> Plus, if the HTTP server on Windows gets compromised, your data is still
> safe.
>
> > Is a proprietary protocol any more secure than the HTTP protocol?
>
> If you code it correctly.
>
> > I think so too.  But I'm not sure that its any more secure than
connecting
> > to the OS/400 HTTP Server from a firewall.
>
> I don't think a lot of you understand how firewalls work. No one "conencts
> from a firewall". Teh firewall is nothing more than a port filter.  The
> reason it is more secure is that the webserver has to accept requests from
> everyone and the type of requests sent to it are infinite.  That makes it
> less secure.  If it gets compromised, all they compromise is a box runnign
> an itnerface.  To get to your servr with data, they have to get past the
> next firewall and into the next box that has your data,  If your firewall
is
> configured properly, the only port they can go through is what you opened
> for your application to listen too.  so then they have to attack and try
to
> figure out a security whole in that application.  Sicne you knwo
> specifically what type of data to expect, since only one box and one type
of
> requests ahppen, it is easier to fieter out obviuosly bad requests.
>
> > Since a URL on the W2K server maps to the PC program, it seems to me
that
> > identifying the PC program is irrelevant.  The URL is known.
>
> I don't think you understand hwo this works.  Soemone goes to a URL on the
> webserver.  an application or ASP script or soemthing takes the parameters
> and formats them and remotely calls the program on the AS/400 and the
AS/400
> returns the data and the webserver takes the data, puts it into a webpage
> how ever they design it and returns the webpage to the user.  They don't
see
> the call to the AS/400.  There is no HTTP conenction between the webserver
> and the AS/400.
>
> >
> > By using a "session" component on the AS/400, an HTTP request may have
> > essentially no format too.  Same principle.  Don't disclose the program
> > interface to the end user.
>
> He isn't.  The user interacts with an HTML form.  The applciation
interface
> to the AS/400 is behind that.
>
> > Sounds like a buffer overflow would be an effective denial of service
> > attack, as well as a way of overloading the AS/400 - disrupting other
> AS/400
> > workload.
>
> But they have to get past the webserver first.  THEN they have to get past
> the firewall and the OS/400/application security.
> >
> > I'd just like to dispell the idea that front-ending an AS/400 with an
W2K
> > IIS server offers any advantage, particularly where security is
concerned.
>
> It isn't front ending it with IIS that is the advantage.  Front ending it
> with a separate piece of hardware IS the advantage.  No if ands or buts
> about it.  You are trying to "dispel" when you don't even seem to know how
> some of the process works.