OS/400 Virus?
Q: Can OS/400 itself be infected by a virus?
A: A virus that could do damage throughout OS/400 would have to be written specifically for OS/400. Can that be done? Yes. But you can take many configuration options to protect yourself from having programs that would do this type of damage restored to your system.
The Integrated File System (IFS) is a different story. Files in the IFS can be infected with common viruses, but this is nothing new. Documents in shared folders have long been virus "carriers." For more details about viruses and OS/400, see the white paper I wrote with IBM's Patrick Botz, "Virus Got You Down?"
What Are SSL and VPN?
Q: What is the difference between Secure Sockets Layer (SSL) and Virtual Private Networks (VPNs), and when would I use one rather than the other?
A: SSL enables a TCP/IP application such as FTP to transmit data between the client and server in an encrypted form. A VPN is another way to have data flow from point A to point B in an encrypted form.
The difference between the two is where they are implemented in the IP stack. VPNs are implemented low in the IP stack. Once the connection from point A to point B is established, it doesn't matter what application runs over the connection. Everything that flows between points A and B is encrypted. SSL must be implemented by the application itself. In other words, SSL is implemented much higher in the IP stack; in fact, it is implemented at the IP application layer. That means that each IP application, such as FTP or TELNET, that is going to use SSL has to be "SSL-enabled." You can install and run an SSL-enabled FTP server, which will then communicate to some SSL-enabled FTP client. Everything that flows between that FTP client and server is encrypted. Telnet may be enabled on the same systems as the SSL-enabled FTP client and server. But even though they reside on the same systems and possibly run over the same communication lines, unless the Telnet server and client are also SSL-enabled, the Telnet session will send data in clear text, not encrypted. To use SSL, it must be enabled by the server, and that server must communicate to an SSL-enabled client. VPNs, on the other hand, are application-agnostic. VPNs, once the session is established, do not care what application uses the session; everything using that session will be encrypted.
When to use one technology rather than the other is one of those "it depends" questions. I often see a VPN where a leased line was once used. VPNs are good when you must establish a connection between two distinct points, such as between a corporation and one of its subsidiaries, and you need to have more than one type of application flowing over this connection. I often see SSL, such as SSL-enabled FTP, used when one type of data or a specific file is being transmitted--for example, between a retailer and a credit card company.
Most of the TCP/IP servers on OS/400 as well as the iSeries Access for Windows servers are SSL-enabled. The FTP client on OS/400 was SSL-enabled in V5R2. OS/400 also provides support for VPN connections, and iSeries Navigator provides a wizard to help you configure them.
Encryption on OS/400
Q: What is available to do encryption on OS/400? Or do I have to implement my own algorithm?
A: First, coming up with your own encryption algorithm is not a good idea. Industry-standard encryption schemes are always a much more secure solution. These algorithms have come under tremendous scrutiny, and they've withstood the test of time. When placed under scrutiny, "user-derived" encryption schemes are usually broken very quickly.
You have two hardware options for encryption on OS/400. One is the 2058 hardware crypto accelerator card. This hardware card is not intended for general encryption use. Rather, is it intended for use in conjunction with a Web server that requires heavy use of HTTPs and is HTTP-secure. This is where the Web page is served using an SSL session. In other words, the data between the Web server and the browser is encrypted. The slowest part of using SSL is not in the encryption of the data flowing across the session. The slowest part of SSL is the establishment of the actual SSL session. This card significantly speeds up this process.
The 4758 e-Business Cryptographic Coprocessor can be used as a general-purpose crypto card. You can use it to encrypt/decrypt data and generate and store encryption keys. This sophisticated card was originally designed to be used in mainframes to provide secure encryption implementation for banks. While APIs are provided to interface with this card, using those interfaces and managing the card itself is not trivial. The APIs are complex and using them can be difficult, especially if you are unfamiliar with encryption concepts and terminology.
You can find more information about both of these cards on the IBM Information Center Web site. Choose the Security category and then Cryptographic hardware.
If you are running V5R2, you have the option of using a software solution. Encryption support has been provided via PTFs SI10060 (APIs) and SI10105 (header files). These PTFs provide support for the MD5, SHA-1, SHA-256, SHA-384, and SHA-512 hash algorithms as well as the DES, Triple DES, and AES encryption algorithms. APIs providing MAC generation and pseudo random-number generation are also provided with these PTFs. These APIs provide a much more simple and straightforward encryption option than the hardware encryption options.
Delete User Profiles That Aren't Being Used
Q: I have written a tool that looks at a user profile's last sign-on date and deletes the profile if the user has not signed on in the last 90 days. However, it looks like this value does not always get updated, and I have deleted some profiles that are used for FTP transmissions. Help!
A: The profile's last sign-on date is only updated when the user actually signs on to the system through the sign-on screen. Even though you must provide a user profile name and password to use FTP, the sign-on date is not updated. However, the profile's last-used date is updated in this case. I suggest that you modify your tool to look at the user's last-used date rather than the last sign-on date. This should give you a more accurate picture of the profiles that have not be "used" in the last 90 days.
Avoid Default Passwords
Q: How do I get rid of default passwords? This seems like an issue I am fighting constantly.
A: It sounds like you already know about the OS/400 command Analyze Default Passwords (ANZDFTPWD). This tool produces a report of all profiles that have default passwords. In addition, when running the report, you can choose to set the profile's status to *DISABLED and/or set the profile's password to *EXPIRED so that it will have to be changed the next time the user signs on. But I gather that you would like to prevent them from happening in the first place.
The best way to prevent default passwords is to change the default value for the PASSWORD parameter on the Create User Profile (CRTUSRPRF) command. I recommend that you set this value to *NONE. Before changing this parameter on their systems, many of our clients had problems with profiles being created for users who never actually needed the profile. The profile would exist with a default password until the profile was flagged as not being used for the last 60 or 90 days, and then it was deleted. The profile is still created but without a password. This requires that all users--or their manager--call the Help Desk or system administrator to have a password assigned to the profile so the user can sign on. This step has been a trivial issue to our clients compared with the exposures that profiles with default passwords presented them.
When running ANZDFTPWD, you may notice profiles associated with a vendor package. In many cases, the profiles do not even need a password. In the cases where a password is required, I have yet to see a vendor package that requires the password to be the same as the profile name. Before changing the password to *NONE or to a different value, I encourage you to call the vendor to find out its requirements. If a password is required, I have seen cases where you also have to change the password in a configuration file in the vendor application.
Carol Woodbury is co-founder of SkyView Partners, a firm specializing in security consulting, services, and the OS/400 security assessment software SkyView Risk Assessor for OS/400. Carol has over 13 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Look for Carol's second book, Experts' Guide to OS/400 Security, to be released in the first half of 2004. Carol can be reached at
LATEST COMMENTS
MC Press Online