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



I agree with you.  There is probably no difference than if I used an AS400
for web services.  It is against our security policy to open the inside LAN
to the internet.  It must go thru the DMZ.  I could LPAR my AS400, but it
was/is cheaper to run IIS on W2K.  Especially when the company WEB developer
only know ASP.  I want to change that at some time and put a iSeries for WEB
serving.  I can use the same type of SOCKET client to connect to the
existing server running on our iSeries.  Gee then I can get rid of that
pesky ASCII to EBCDIC and back conversion.

Hey when is IBM going to offer an ASCII base AS400?  Make the WorkStation
controllers do the conversion to EBCDIC for legacy terminal support.

As for security, with the firewall between the DMZ and internal LAN and the
private socket client/server setup, I don't think it really matters what you
use for Web serving.  Granted IIS is the least secure of all web servers and
I would love to run APACHE either on a Unix/Linux/iSeries.  I just need to
justify the cost and train my web programmer.  I am challenging him to learn
Apache on the iSeries at this time for intranet development.

And Yes We did write our own multi-threaded socket server.

Chris

-----Original Message-----
From: Nathan M. Andelin

> We use W2K for web serving with a socket connection
> to our AS400 to process request for data.

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?

> We opened the one port from the DMZ to the internal LAN
> from the web severs to the AS400's only.

Is that any more secure than opening only one port from a firewall to the
OS/400 HTTP Server?

> The listening socket server on the AS400 looks at the first
> few bytes of the request, request identifier, and spawns off
> the correct program to handle the request.

Is a proprietary protocol any more secure than the HTTP protocol?

> The spawned off job is a PJ waiting for action.  Very FAST
> and not a whole lot of CPU on the AS400 side.

Wouldn't performance depend on the number of concurrent requests hitting the
server at the same time?  Or did you write your own multi threaded socket
server?

> I think it is very secure.

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.

> You would have to know what the PC program is
> and how to format the request to hack into the AS400.

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.

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.

> If you try a buffer attack on the AS400, well the server program
> is designed to shut down and re-submit itself via *PSSR.

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.

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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.