January 29, 2004 at 4:32 pm
I would not worry too much about the master DB, since privileged procedures are already secured by checking explicitly for user access within the proc. So not much harm can be done by having execute access to public (atleast I have not come across any incidents) except these:
USE master
GO
REVOKE EXEC ON xp_execresultset FROM PUBLIC
REVOKE EXEC ON xp_printstatements FROM PUBLIC
REVOKE EXEC ON xp_displayparamstmt FROM PUBLIC
msdb on the other side is an open door, lock it down. I am dealing with few test / development DTS packages, jobs added by folks since every valid user in the server has rights to perform these actions. I would recommend the following to fix:
o Remove the guest account from msdb.
o Add explicitly users or applications that require access to DTS packages as users to the msdb database. DTS Packages and SQLAgent jobs should be added only by the DBA / Sysadmin.
o Revoke execute permissions on the following procedures:
USE msdb
GO
REVOKE EXEC ON sp_add_dtspackage FROM PUBLIC
REVOKE EXEC ON sp_add_job FROM PUBLIC
REVOKE EXEC ON sp_add_jobstep FROM PUBLIC
REVOKE EXEC ON sp_add_jobserver FROM PUBLIC
o These changes still permit the developers to view and execute 'their' jobs and packages.
o It is recommended that sensitive DTS packages be secured with owner and user passwords.
Regards.
January 30, 2004 at 7:51 am
I've written about this quite extensively in my practical for the GSEC:
http://www.giac.org/certified_professionals/practicals/gsec/3360.php
K. Brian Kelley
@kbriankelley
Viewing 2 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply