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


  • Subject: RE: Setting up FTP to AS/400 for the first time
  • From: "Gary R. Patterson" <midrange-l@xxxxxxxxxxxxx>
  • Date: Fri, 29 Sep 2000 15:29:09 -0500
  • Importance: Normal

Some food for thought:

I don't like to expose a production machine directly to the Internet,
period.  Why risk it?  Even if your scheme appears bulletproof today,
someone could come up with a new exploit at any time.  I say set up or use a
dedicated ftp server, either in your network's DMZ (if you MUST manage the
server yourself) or on a server managed by an outside ISP.

Once you have set up a server that is not inside your private network, you
can just open up anonymous ftp (for download).  You have already taken pains
to make sure that you are not distributing complete applications, etc.  You
could set up a common user ID or dedicated user IDs for your clients if you
want the maintenance hassle.

This is the same model used by the largest providers of online support.
Look at Microsoft, Novell, Compaq, maybe even IBM, now. They (mostly) don't
restrict who can download the fixes, they just place them on public servers,
and lock down who can publish new information to the server.

In your current scheme all it takes is a sniffer along the route and a
hacker can get the FTP user ID and password that you give to your clients,
and access all of the files in the directory anyway.

When uploading to the public server, use a private or secure connection (you
want to avoid sending your upload user ID and password in the clear,
especially over a public network).

As additional protection for your clients, digitally sign files that you
distribute so that clients can verify that they really came from you, and
are unaltered.

Gary R. Patterson
NexSource, Inc.

980 N Michigan Ave, Suite 1400
Chicago, IL 60611
(312) 214-3526

640 W. Main St.
Louisville, KY 40202
(502) 581-0106

Information technology services for business
http://www.nexsource.com



-----Original Message-----
From: owner-midrange-l@midrange.com
[mailto:owner-midrange-l@midrange.com]On Behalf Of jcrowley@ifasys.com
Sent: Friday, September 29, 2000 10:53 AM
To: MIDRANGE-L@midrange.com
Subject: Setting up FTP to AS/400 for the first time




I work for a smallish software company. We are currently using four comm
lines
for client support and to send software updates via SNADS. The competition
for
these four lines is getting hot, so we're looking at alternatives before
going
out and setting up more lines.

We believe we can provide our software updates via FTP, but we don't want to
implement anything until we're fairly sure our security mechanism will work.
Can
someone tell me where the holes are in our scheme?

I have set up an FTP user profile that has no special authority, no
password, an
initial program of *SIGNOFF, and a library list that contains only one
library.
The only objects that definitely will be placed in this library are save
files
intended to be available to our clients. (The save files contain program
and/or
file updates or additions. They would never contain a complete program or
file
library. They would also never contain any implementation procedures or
documentation.)

I have created an FTP logon exit program and a file that contains a very
small
list of valid user profiles for FTP. The exit program compares the incoming
profile with the list in the file and either accepts or rejects the logon.
If
the logon is accepted, the user profile is changed to the single FTP user
profile described above.

I have a second exit program that looks at incoming FTP requests. All
requests
are rejected except for the ability to establish a connection, list the
current
library and get a file from that library. We will log all FTP requests from
within these exit programs, but I'm still working on that piece.

We do not have all libraries on our system designated as public *EXCLUDE,
and I
know that it's recommended. To date, we have secured our system from the
outside
by using our firewall to pretty much shut down anything incoming and keeping
some servers (like FTP) turned off. We know that improving our security for
an
internet world is in our immediate future, but we would like to plan it
thoroughly to minimize work disruption. Will the plan being considered for
FTP
be fairly secure if we haven't taken this step yet?

What other things should we look at to close any holes into our system that
might occur with this setup? More importantly, are there any security risks
for
our clients in this? I can't see that there is any risk for them, but
perhaps
I'm missing something major.
Thanks for your help!

Janet Elam Crowley
Systems Analyst
IFA Systems






+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.