Protecting Your AS/400
Note that this document only describes protecting your AS/400 information in
regards to Webulator/400. Other software such as Telnet and FTP pose
additional concerns which are not addressed here.
familiar to AS/400 system administrators and is very strong (it can be
configured to meet the requirements for C2 security, as defined by
the United States Department of Defense).
For OS/400 authority to be effective, your system's security level
(system value QSECURITY) should be
set to at least 30. Webulator/400 has been developed and tested at
security level 40.
The server jobs (daemon and request processors) run under
the configured server user profile. The server
user profile should have the following authorities:
*USE to the
WEBULATOR/WBLDAEMON program and to the
QSYS/QSYSNOMAX job queue.
The server user profile must be registered in the system directory in
order to access Document Library Services (DLS) folders and documents.
Webulator/400 Access Control
While OS/400 authority is very strong, it is inflexible because it is based
on the user profile of the person starting the server and on the server user
profile. The server user profile either has access to an object or not.
Access control takes into account information about the person requesting the
information, such as the workstation they are using and the user name and
password they enter.
You can find more information about access control in
access control example
and a detailed
description of how limit sections are evaluated.
Ways Of Controlling Access
Webulator/400 allows access to be restricted in two ways, which may be used
separately or combined. For greatest security, both should be used together.
- Host filtering
Allows restriction of access to information based on the IP address or
domain name of the machine (host) requesting the information.
- User authentication
Allows restriction of access to information based on a user ID and
password the user enters.
Evaluating Webulator/400 access involves a two step process:
Host filtering will be checked first. If host filtering is not
configured or allows access, the server goes on to the next step. If host
filtering does not allow access, the server will forbid access.
User authentication is checked. If user authentication is not configured or
allows access, then access is granted. If user authentication does not allow
access, the server will forbid access.
Further Information About Protecting Your AS/400
The following topics are related to protecting your AS/400: