Can anyone provide a list of “Best Practices” or recommended commands to secure from command line users…???
For Security and auditing purposes we need to secure potential harmful commands frok the few profiles which have command line access. I'm looking for a base list of commands or recommended best practices or a starting point / list. All insight is welcome
Software/Hardware used:
Software/Hardware used:
ASKED:
October 1, 2008 5:16 PM
UPDATED:
August 10, 2010 5:45 AM
Answer Wiki:
You have to think in a menu and remove the command line, at the beginning everybody will complain but it is the only way to close the security. A submit job could be a break in the security, all DLT* commands, also the remove, strsql strseu strdfu strsda could cause problems, the list is huge.
Hello,
For a starter, I would secure Delete and Clear commands such as,
DLTLIB
DLTLICPGM
DLTJOBQ
DLTMNU
DLTAUTHLR
DLTAUTL
DLTCTLD
DLTDSTL
DLTDFUPGM
CLRLIB
CLRPOOL
From a command line you can type in GO CMDDLT or GO CMDCLR, etc... and see all the different commands or just hit F4 and see the different type of commands you can choose from. You want to make sure they cannot delete or change system values, backups (Unless they are a system admin or operator). It really all depends on their job responsibility to what a person should have access to.
Gambitt7,
You might also want to restrict some people from using the STRDFU, STRSQL commands as well as CRTPF, CRTLIB unless they are programmers that as part of their job need this access.
If you do not restrict object level access to the production files, then the users can use the built in tools like STRDFU and STRSQL to manually change the data and then tracking changes to the production database is very limited and certainly frowned upon by your companies internal and external auditors.
You also do not want users creating libraries and files because if unchecked the users will manage to fill up the disk space quicker than anything. Another CLR not mentioned above is the CLRPFM (clear physical file)
Good luck
Lovemyi
==========================================================
There is no "best practices" set of commands to restrict. If best practices have been followed, then there is no need to restrict any commands -- the users won't have existence authority to any files, so you don't care if they can execute DLTF for example since there would be no files they had authority to delete anyway. In currently supported releases, a command line won't let them do any harm regardless of command if their authorities are appropriate.
Best practice is to apply object authority to give individual users and/or group users only the level of authority that they need and no more.
Tom
To see all answers submitted to the Answer Wiki: View Answer History.
You can also look at this website on IBM System i Security Guide…
http://www.redbooks.ibm.com/abstracts/sg246668.html
Maybe the question is what do your users with command line access (excluding administrators) need access too? The common thing I have done is to remove command line access, but provide a menu that will perform the items that they need to perform. There may even be things that can be filled in for the user when prompting the command, to restrict the access even further. I have also written some basic programs that perform functions with adopted authority, so the user doesn’t need a high level of security to perform these functions.
Please also remember that if you install Iseries Navigator, many things can be done from there – but it is quite easy to limit what the users can do in this utility. However, if you don’t limit them there the back door is wide open. I can even execute CL commands (or their equivalents) from the DB function in Iseries Navigator, so having appropriate object level security is still important.
According to IBM, the best practice is to secure the data. Once the data is secure you do not need to worry about the commands. Its probably also easier to secure the data than the commands because you know your data files and libraries. Keeping up with IBM’s commands and exit points could consume a lot of your time.
The group profile feature is a handy to secure data efficiently. When users are hired or fired, just delete the group profile reference from the user’s profile and you are covered.
One way to answer this is to create a simple user profile with no authority but with command-line access. Then run this command:
DSPOBJD OBJ(*ALL/*ALL) OBJTYPE(*CMD) OUTPUT(*OUTFILE) OUTFILE(QTEMP/CMD)Use RUNQRY or SQL to create a list of names that begin with STR*, END*, CFG*, CLR*, CPY*, RMV*, RST*, SAV*, ADD*, CRT*, CHG* and WRK*. You probably should include DSP*, HLD*, RLS*, GRT*, RVK*, EDT*, OVR*, PRT*, RCL* and RNM*. Other than those, you probably should review the rest on an individual basis to see if you want them included. You need to look at all of the others because you can’t afford to skip commands such as CALL which obviously trumps almost all of the others.
Then feed the list into a CL program that grants *EXCLUDE authority for each individual on the list.
Note that you need to run this against *ALL commands in *ALL libraries, not just QSYS. Commands from 3rd-party products or utilities shouldn’t be missed nor home-grown commands.
If that seems excessive, be aware that a command that seems as harmless as ADDMSGD can lead directly to total control of your system. Many commands can be as powerful as ADDMSGD. (Long-time AS/400 developers can recall when IBM finally changed QCPFMSG to restrict users from changing it. The same vulnerability exists in every other message file that might be found anywhere on your system.)
Tom