RE: [Security400] Authority annoyances, continued...

["Jim Langston" <jlangston@xxxxxxxxxxx>]

Yes, true.  That is also why I had FTP shut down on my
AS/400, along with all the other TCP/IP servers (HTTP,
etc...) although Telnet access was still available, this
box wasn't' on the internet.

If I had needed to keep the FTP server running I would of
written the FTP exit program.

Didn't have STRSQL on that box, not did it have Java.

ODBC as far as I know was open though (not sure what the
AS/400 side of that was).

But you are right, all of those are security holes.

Regards,

Jim Langston
Programmer/Analyst
Cels Enterprises, Inc.

-----Original Message-----
From: security400-admin@midrange.com
[mailto:security400-admin@midrange.com]On Behalf Of Buck Calabro
Sent: Wednesday, August 22, 2001 6:16 AM
To: security400@midrange.com
Subject: RE: [Security400] Authority annoyances, continued...


>ODBC, Client Access and Ops Nav.
 [allowing access to a file when UPDDTA is secured]
>On my old system I got around it simply
>not using Client Access, we didn't even have it licensed.

Wait 'til some genius opens command-line FTP, does a GET of a file with
packed data makes a change to the text of a record and then PUTs it back.
Boy is THAT fun to debug.  The point is not that there's a problem with
Client Access; it's any access other than your code.  Some possibilities
that exist on every AS/400:

File Transfer Support - QY2FTML
SQL - STRQMQRY, ODBC/JDBC, embedded in ReXX
FTP
DDM file
AS/400 Java toolkit
HTTP server/Net.Data
<SNIP>