My wife and I live in the middle of the Adirondack Park, a six million acre state park in upstate New York (think "about the size of Massachusetts"). This area houses a year round population of just over 130,000 people. As you might imagine, with that population density, security is not a big issue. Recently, there was a burglary in the town where my office is located. Someone walked into the back door of a shop and helped themselves to money in the cash register and then slipped back out without being seen. This got me to thinking about security on the System i and how a similar situation might easily exist at many shops where doors are left open.
In the "old" days, the only door you had to be concerned about was the computer terminal. These terminal were placed in public places and protected by user profiles and passwords. In order for someone to sneak in, they'd have to be pretty bold and they'd have to know a profile/password pair. Today, the user profile/password continues to be a primary locking mechanism for your system. That said, this continues to be your first line of defense.
Keeping your user profile list current is probably one of the most important tasks you can do. Some critical things to remember include enforcing periodic and regular password changes, deactivating and even deleting old profiles for people who are no longer employed there and only providing the level of access permissions that a profile needs. That's pretty simplistic, but remember that you're handing out keys to the doors of your system. You want to limit the number of keys in circulation, and you don't want everyone to have a master key. Also, you need to make sure that there are no default passwords active on your system, including passwords for well-known third-party software packages. The system will watch the doors for you, but if there is no control over the keys, what's the use?
Assuming that you have your keys under control, then you need to also take a look at all of the doors that are on a modern System i server these days. The days of only needing to control terminals is long gone. Today, you need to be concerned about the FTP door, the Telnet door, the Remote Execution door, the ODBC door, the SQL door, the iSeries Access door and on and on.
For some of these doors, you can easily control access by removing the door altogether. If your shop does not use FTP on a regular basis, then don't leave the FTP door in place. On most systems that I work on, I find the FTP server up and running by default. It is a simple matter to turn it off with the command: ENDTCPSVR *FTP, and to use the Change FTP Attributes (CHGFTPA) command to set the AUTOSTART parameter to *NO so that it doesn't restart with every IPL. If you occasionally use FTP, you can start and stop it as needed using the STRTCPSVR and ENDTCPSVR commands. With this approach, you not only lock the FTP door, you remove it from your system. If the door isn't there, it can't be opened.
Other servers can be handled this way too. These include the Trivial FTP server, the TCP/IP DDM server and the Remote Execution server to name a few. If your system has these servers active, each one represents another door that can be used to access your system. If you're not using these server functions, then remove the doors.
The easy way to check on these is to go to the operating system Configure TCP/IP menu (CFGTCP) and run option #20. Check each of the displayed server functions and see how the AUTOSTART parameter is set. If you don't have any applications using these servers, then remove these doors to your system. The fewer doors that are on your system the tighter your security will be.
This covers only some of the doors into your system. Next time around, I'll address some of the doors that are a little more difficult to keep locked.
If you have specific questions about this topic, email me at email@example.com. All email messages will be answered.
About the author: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.
This was first published in October 2006