|
Andrei, S.A. Centea wrote: > In our environment, any ordinary user can access from > his NT 4.0 station all AS/400 files via Network > Neighborhood - AS/400 - file structure system. > > This is a serious security gap for me, as it happens > even for the weakest user. > > We are on OS/400 4.3 and CA 3.2.0. > > Does anybody know how can I disable this access? Your network has just pointed out the shortcomings of traditional AS/400 Security designs. Too many AS/400 applications rely on menu systems to secure access to the data, but Network Neighborhood doesn't know about your Menu system and will never learn to respect it. For the complete version of this answer I'll be speaking to the Chicago AS/400 user group http://www.omniuser.org/ this coming Tuesday evening on this very topic, so if you are in the Chicago area stop by and say Hi! Now for the abbreviated version... This is a well known problem, and there are a couple of solutions. The first (and least desirable) is to use the authorization list QPWFSERVER to disable *PUBLIC's ability to see the AS/400's QSYS.LIB via Network Neighborhood. But frankly this approach is full of problems. The first is that it only "hides" access through Network Neighborhood, and doesn't protect you from FTP, Remote Command, ODBC and other SQL accesses. If someone can see Libraries and files through Network Neighborhood, they will certainly be able to see them through all of the other data access methods that the AS/400 supports. Worse still, if the user has *CHANGE or *ALL rights to the files, they can really do damage. Another problem is that QPWFSERVER can completely disable other useful functions such as Netserver printing etc. I published a technical tip in News/400 in December on this topic, and in April got blasted by a reader who implemented QPWFSERVER and found that it diabled all of her shared printers. Yikes! Another approach is to modify your user's authority to the underlying AS/400 objects. Many would argue that this is best way to fix the problem, and they would be right if you actually had the time and the resources to re-examine your applications to use resource security. This approach is made even more difficult if you're security nightmare was inflicted on you by your application vendor... because they problably don't know how to fix their own system, and will re-inflict their scheme on you with each new release. The third solution is to use OS/400 exit points to regulate network data requests. We have a product called PowerLock that was built specifically around this approach. By posting programs at the exit points you can regulate who will have access via all of the different servers and reject requests that compromise your AS/400 data. If you want to know more about PowerLock, you can visit our web site at www.400security.com But in any case, if you're in Sara Lee's Chicago office, do come by the Omni User Group's meeting this Tuesday night. It won't be a product pitch, but it will be highly informative. jte -- John Earl johnearl@toolnet.com PowerTech Toolworks 206-575-0711 PowerLock Network Security www.toolnet.com The 400 School www.400school.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 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.