Earlier this year, we posted a checklist for quarantined IBM i administrators. We highlighted critical items you will need to keep your IBM i servers running and protected when your admins are unavailable due to Covid-19 or working from home.
The original checklist detailed the first ten (1-10) critical quarantine protection items, such as additional VPN access, backup IBM i admins, setting up a remote system console, password resets, and backup changes.
It is time for a sequel. Here are 9 more items (11-19) to add to our quarantined IBM i administrator check list.
- Lock down your remote data downloads via exit points—When your users access your IBM i remotely, they can access all functions they can normally use inside your network. This means that users can use the following functions from a PC remotely connected to your network to download IBM i data, including:
- FTP
- JDBC
- ODBC
- OLE
- SQL
- IBM i Access client download functions
Remote data download has always been a critical security problem, even for internal network users. It becomes more critical when the number of remote users explode, you have expanded external access, and many users may be using off network BYOD machines to access i systems.
Exit points allow you to insert custom-written programs to monitor and control IBM i access. They have a big advantage in that many exit point operations can block or supersede operations performed under *ALLOBJ authority.
- Lock down PC processes that can execute remote commands on your i servers—While item #11 dealt with preventing data download, there are certain functions where PC users can execute commands directly on your IBM i servers. These functions include:
- The FTP RCMD sub-command
- Remote Execution (REXEC)
- Remote Command (RMTCMD)
When these services are not in use, you can shut them down by using the End TCP/IP Server (ENDTCPSVR) command for both the FTP and the REXEC servers. Ending the FTP service will also prevent RMTCMD commands from being processed.
- Use Virtual Desktops such as Citrix for BYOD users to access your IBM i servers—If you are having a large number of users remotely accessing your IBM i, it will be more secure to use a virtual desktop, rather than having them come in through a VPN connection. Like accessing a Web application, all the processing is done on the virtual desktop, not on the user machine. Which makes your IBM i safe from any spyware, viruses, or malware on your user’s BYOD machines.
- Review and delete excessive NetServer file shares—Windows PCs connecting network drives to NetServer file shares can infect the Integrated File System (IFS) with malware, viruses, spyware, and ransomware. Review your NetServer file shares. Delete duplicate shares, any test shares, and other shares that are no longer being used. Determine if users need read-write authority on the remaining shares. Reduce permissions to read-only for any shares that do not need update or create rights. Limit your exposure by limiting your NetServer file shares.
- Perform an audit on your user profiles, even if you do not have to—Pull out your old IBM i auditing reports and see if there are any unresolved audit points that should be addressed This includes all of your internal, external, and regulatory auditor reports. As much of a pain as auditing is, many findings relate directly to securing your IBM i systems. Fix those findings to better secure your system. If you’re looking for more security holes in your system, check out our blogs on SOX auditing on the IBM i and configuring IBM i password security and composition rules for compliance.
- Eliminate all default password users—If you are expanding IBM i access from outside your network, make sure you lock down all default passwords (where the password is the same as the user ID). This will help prevent hackers from more easily signing on the system. Instructions for changing default passwords using the Analyze Default Passwords (ANZDFTPWD) command, can be found in our blog post on the How to Avoid the 8 Common IBM i Password Security Mistakes, under password mistake #4.
- Stop giving hackers unlimited opportunities to sign on—Many IBM i servers are configured to provide excessive or unlimited sign-on hacking attempts. To close this hole, go to our How to Avoid the 8 Common IBM i Password Security Mistakes post and implement the fix shown under IBM i password mistake #2.
- Do not expose your IBM i directly to the Internet (yikes)—There are very few shops that do this, but some shops expose their IBM i directly to the Internet outside the firewall, with an external Internet address. If you are one of those rare shops, stop. Now. That is inherently dangerous. IBM i access should always be protected behind an IBM i-based firewall, such as iSecurity Firewall or a firewall and VPN from a major security vendor, such as Cisco.
- Evaluate professional software to shore up your IBM i servers during periods of high remote activity—Our quarantined admin checklist contains a lot of configurations that will take some time to implement in DIY mode. IBM i-based firewall products such as iSecurity Firewall can shore up many of the exposures shown here. Consider using a third-party product to help you tighten your iSecurity as you struggle with the challenges of providing even more outside access to your servers.
