Your security policies must be designed to protect your system from computer viruses and malicious programs.
Recent trends in computer usage have increased the likelihood that your system has programs from untrusted sources or programs that perform unknown functions:
v A personal computer (PC) user sometimes obtains programs from other PC users. If the PC is attached to your system, that program can affect your server.
v Users who connect to networks can also obtain dangerous programs, from bulletin boards, for example. v Hackers have become more creative, active, and renowned. They often publish their methods and their
results. This recognition can lead to imitation by normally law-abiding programmers.
A computer virus is a program that can perform other operations that can take up system resources or destroy data. Additionally, the virus can change other programs to include a copy of itself. The other programs are then said to be infected by the virus. The newly infected programs will continue to spread the virus and its negative effects.
The architecture of the server provides some protection from the infectious characteristics of viruses. A server security administrator needs to be more concerned about programs that perform unauthorized functions. There are many ways that someone with ill intentions might set up harmful programs to run on your system. The topics provide tips for preventing programs from performing unauthorized functions.
Tip: Object authority is always your first line of defense. If you do not have a good plan for protecting your objects, your system is defenseless. This information discusses ways that an authorized user might try to take advantage of loopholes in your object authority scheme.
A computer that has a virus infection has a program that can change other programs. The object-based architecture of this system makes it more difficult for a mischief-maker to produce and spread this type of virus than it is with other computer architectures. On this system, you use specific commands and instructions to work on each type of object. You cannot use a file instruction, which is what most virus-creators do, to change an operable program object. Nor can you easily create a program that changes another program object. To do this requires considerable time, effort, and expertise, as it requires access to tools and documentation that are not generally available.
However, as new server functions become available to participate in the open-systems environment, some of the object-based protection functions of servers no longer apply. For example, with the integrated file system, users can directly manipulate some objects in directories, such as stream files.
Also, although server architecture makes it difficult for a virus to spread among server programs, its architecture does not prevent the system from being a virus-carrier. As a file server, the server can store programs that many PC users share. Any one of these programs might contain a virus that the server does not detect. To prevent this type of virus from infecting the PCs that are attached to your server, you must use PC virus-scan software. Several functions exist on the server to prevent someone from using a low-level language with pointer capability to alter an operable object program:
v If your system runs at security level 40 or higher, the integrity protection includes protections against changing program objects. For example, you cannot successfully run a program that contains blocked (protected) machine instructions.
v The program validation value is also intended to protect you when you restore a program that was saved, and potentially changed, on another system. The Security level 40 topic in Security reference describes the integrity protection functions for security level 40 and higher, including program validation values.
Note: The program validation value is not foolproof, and it is not a replacement for vigilance in
evaluating programs that are restored to your system. Since hackers and other malicious users are able to quickly catch up with advances in technology, the only effective security policies are those that are constantly updated.
Several tools are also available to help you detect the introduction of an altered program into your system:
v You can use the Check Object Integrity (CHKOBJITG) command to scan objects that meet your search values to ensure that those objects have not been altered. This is similar to a virus-scan function. You can also use the CHKOBJITG command to request that a scan be done of the integrated file system objects. If a user has an application or business partner that scans for viruses using the integrated file system's scan related exit programs, this will trigger a scan for viruses.
v You can use the security auditing function to monitor programs that are changed or restored. The *PGMFAIL, *SAVRST, and *SECURITY values for the authority level system value provide audit records that can help you detect attempts to introduce a virus-type program into your system. The Auditing security on System i and Layout of audit journal entries topics in Security reference provide more information about audit values and the audit journal entries.
v You can use the force create (FRCCRT) parameter of the Change Program (CHGPGM) command to re-create any program that has been restored to your system. The system uses the program template to
re-create the program. If the program object has been changed after it was compiled, the system re-creates the changed object and replaces it. If the program template contains blocked (protected) instructions, the system will not re-create the program successfully.
v You can use the QFRCCVNRST (force conversion on restore) system value to re-create any program as it restored to your system. The system uses the program template to re-create the program.
QFRCCVNRST provides several choices on which programs to re-create.
v You can use the QVFYOBJRST (verify objects on restore) system value to prevent the restore of programs that do not have a digital signature or do not have a valid digital signature. When a digital signature is not valid, it means the program has been changed since it was signed by its developer. APIs exist that allow you to sign your own programs, save files, and stream files
Related information: Security level 40
Auditing security on System i Layout of audit journal entries