TCPIP command line question

[Jorge Cocomess]

Hi,

Currently, with some users that has more than standard VMS privs and know their way around VMS. I am trying to maintain a trouble free environment or just get a handle by keeping non VMS system personel from playing with the TCPIP, such as adding to routes, etc. I am currently running VMS 7.3-2 and I would like to know how I can make it more difficult for a non system personel to access TCPIP protocol? I'd at least a long command string before they can access the TCPIP prompt.

Is there anything I can do since the previous System Manager created these simple access privs for all these people and thought them way too much before he left the company??

Please help!!

Jorge

[Heinz W Genhart · Accepted solution]

Hi Jorge

You could simple set a ACL to the TCPIP Control Programms, like TCPIP$UCP or TCPIP$IFCONFIG (all TCPIP exe files in Sys$system). With the acl you can arrange, that only user System and other well selected users can execute those programms.

Regards

Heinz

[Ian Miller.]

ACLs will work unless the lUsers in question have BYPASS priv. You can ensure use of BYPASS to access something is recorded in the VMS audit log (to be used as evidence in the witchhunt that takes place after a major outage).

Managing privs is a people problem not a really a technical problem. Can you find some excuse for reviewing (downgrading) their privs?

[Jorge Cocomess]

As of now, I would look into the ACL option. I will also set an audit log on their user's account for audit trail, this should be good enough reason to down grade their privs.

Does any know how I can set the ACL parameter on the TCIP services?

Thanks much!

Jorge

[Ian Miller.]

first add a id to use in the ACLs
$ MCR AUTHORIZE ADD/ID TCPIP_MANAGE

then add the ACL e.g.
$ set security/acl=((id=tcpip_manage,access=r+e),(id=[*,*],access=none)) sys$system:tcpip$ucp.exe

Add also to TCPIP$IFCONFIG.EXE and TCPIP$SYSCONFIG.EXE

Grant the identifier to appropriate people

$ MCR AUTHORIZE GRANT/ID TCPIP_MANAGE SYSTEM
$ MCR AUTHORIZE GRANT/ID TCPIP_MANAGE trusteduser

etc

ensure use of BYPASS gets recorded
$ SET AUDIT/AUDIT/ENABLE=(ACCESS=EXECUTE+BYPASS)

[Jan van den Ende]

Jorge, Ian,

I am not convinced that monitoring of BYPASS is enough.
I would suggest that any mention of BYPASS in Ian's solutions entails SYSPRV as well.

Just my EUR 0.02

Proost.

Have one on me.

jpe

[Jan van den Ende]

Sorry, just an afterthought (that is, after hitting Submit).

This may or may not apply:
What are the group-UICs of the potentially malignant users?
Should they be within MAXSYSGROUP, consider changing their UICs, or, if they are not as low as 1, maybe lower MAXSYSGROUP sufficiently.

Proost.

Have one on me.

jpe

[Ian Miller.]

Jan, yes parhaps this would be better
$ SET AUDIT/AUDIT/ENABLE=(ACCESS=EXECUTE+SUCCESS+BYPASS+SYSPRV+GRPPRV)

essentially this is about collecting enough evidence to be allowed to remove privileges from some people.

[Wim Van den Wyngaert]

But if they are clever they might copy an unprotected exe to the system (e.g. downloaded from the internet or from another VMS system).

Or they can stop audit and restart it after they are finished.

Or simply create a new version instead of modifiying the config file.

Also tcpip$etc:syscconfigtab.dat should be protected (config of tcp params). Never understood why it has its own place (instead of in tcpip$configuration).

Wim

[Ian Miller.]

a audit ACL on tcpip$etc:syscconfigtab.dat would be appropriate (along with the usual ones on OPERATOR.LOG etc). Stopping and starting auditing is recorded.

[Jorge Cocomess]

Good morning!

As of now, you guys are going way over my head with all these good ideas. Without making any mistakes or ???, I am auditing their login so that I can have enough evidence to remove their privileges. Worst of all, these folks are within the IS dept but never been a systems, systems person.

Please don't get me wrong, but these ideas are great and please keep it coming.

Have a great day!

Jorge