Can anyone provide a list of “Best Practices” or recommended commands to secure from command line users…???

150 pts.
Tags:
AS/400 commands
AS/400 security
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

Answer Wiki

Thanks. We'll let you know when a new response is added.

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

Discuss This Question: 4  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Tpinky
    You can also look at this website on IBM System i Security Guide... http://www.redbooks.ibm.com/abstracts/sg246668.html
    4,165 pointsBadges:
    report
  • Iseriesvet
    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.
    20 pointsBadges:
    report
  • WoodEngineer
    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.
    6,765 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following