RE: iSeries vs. Unix vs. SQL Server vs. Oracle &Security/Datasep aration???

The problem some might have with the single port from a single ip address 
versus the serial connection is the likelihood of a router fix 
accidentally opening up everything.  It's happened, but I'd live with that 
versus the reduced speed of a serial connection.

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 





Chris Bipes <chris.bipes@xxxxxxxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
08/06/2003 10:25 AM
Please respond to Midrange Systems Technical Discussion
 
        To:     "'Midrange Systems Technical Discussion'" 
<midrange-l@xxxxxxxxxxxx>
        cc: 
        Fax to: 
        Subject:        RE: iSeries vs. Unix vs. SQL Server vs. Oracle 
&Security/Data sep      aration???


Scott I could not agree more.  But what is the difference between the 
serial
connection and only one TCP port open through a fire wall to a custom 
socket
server?  This would be a communication program just like your serial
connection.  RPG programs tend not to allow full access to a system 
because
someone did not handle the bad data requests.  If the fire wall only 
allowed
your webserver(s) IP addresses to connect, it would be the same as a 
serial
connection.  Heck you can have one multi-connected socket program 
listening
at one port, or several single connection programs each connected to one 
web
server at different ports.  I personally like to keep a persistent
connection with the web server, have one socket server listen for new
connections and spawn off to a PJ.  Then I can have multiple web servers
connected, single threaded, using one port.  If someone hacks IIS, since
that is the crap we have, they have very little access to our AS400.  They
can perform DOS attacks from our own web server, but the others are 
running
in their own job and not affected, unless they loose there persistent
connection and try to re-connect.  If the AS400 sees one of these jobs
chewing up CPU, well we get paged.

I would love to put a second iSeries in the DMZ just for web serving, but 
it
does not make financial sense at this time.

Chris

-----Original Message-----
From: Scott Klement


> For clients with absolute security requirements, I recommend a public
> webserver (FreeBSD is a nice choice) in the DMZ talking to an
> application server on an iSeries also in the DMZ talking to a second
> iSeries behind the DMZ.  All communication between the iSeries boxes is
> through distributed data queues using SNA.
>
> No TCP/IP traffic between the two machines.  Makes hackers crazy <grin>.

That's a great idea...

Another alternative would be to have the FreeBSD machine talk to the
iSeries via a null-modem cable on a serial port.  This would be
significantly more secure than SNA, since once a hacker managed to
compromise machines in the DMZ, he could only access a single program on
the iSeries (the one that's reading the serial port).

With a full SNA connection, the hacker could potentially use SNA or APPC
or raw ethernet packets to get to your "safe" system.   Granted, there
aren't many hackers with familiarity with SNA, but it would only take one,
and I'll always take physical security over "security by obscurity."

Of course, a serial connection is significantly slower than a network
connection, so you'd have to plan the application so that only relatively
small amounts of data need to be transferred over the serial link... but
it seems to me that the large data is things like images, java applets,
etc which don't really need to be on the "Safe" machine.
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.