I wanted to follow up my previous blog and dig deeper into database server parameters. Today, there are a number of highly sensitive parameters within each DBMS that, depending on their value, can leave the databases or database servers vulnerable to various types of malicious activity. Some key parameters for SQL Server and Oracle are outlined below. Also included are explanations of why these parameters are sensitive, and why an organization might want to standardize on a particular value.
· xp_cmdshell = 0 (Disabled) –this is an extended stored procedure that allows you to execute a command line OS command from within the database (e.g. using T-SQL). This can be a serious security risk, because someone could potentially corrupt your system or escalate their privileges to sysadmin or box administrator. This was enabled by default in SQL Server 2000. Microsoft changed the default to “disabled” in SQL Server 2005.
· OLE Automation Procedures = 0 (Disabled) – These system stored procedures allow the use of COM objects (http://www.microsoft.com/technet/scriptcenter/guide/sas_vbs_wcmr.mspx?mfr=true) within T-SQL (i.e. someone can open a computers File System and open, process, read, and write files). This can also be used to access & manipulate OS objects from inside the database, which could pose a threat or crash the server. This is now disabled by default.
· remote admin connections= 0 –The setting of this parameter determines whether or not the SYSADMIN server role can use the Dedicated Administrator Connection (DAC) to access SQL Server remotely. Organizations concerned that the SYSADMIN server role has been compromised should leave this parameter disabled.
· C2 audit mode= 1 –Enabling this parameter will configure the server to record both failed and successful attempts to access statements and objects. This information can help you profile system activity and track possible security policy violations. Note: this parameter is often disabled for performance reasons.
- remote_os_authent = FALSE— When using OS authentication (remote or local), authentication occurs at the OS level and then the user connects to the database. When connecting to the database the user does not have to supply a password and Oracle maps the database user to the OS user based on user name. Allowing remote OS authentication (setting parameter value to TRUE) exposes a database to great security risk. The risk is that someone can connect to the network with a user name that maps to a DBA, and gain entry with no authentication being done on the database server.
· 07_dictionary_accessibility = FALSE — Setting this parameter to FALSE ensures that users with the ANY privilege are restricted from SYS schema objects (data dictionary objects). These users will still have access to all other schema objects. Setting this parameter to FALSE prevents users with the “drop any table” role from maliciously dropping parts of the data dictionary. For Oracle 8 the default is TRUE and for Oracle 9 and up the default is FALSE
· audit_sys_operations = TRUE – Organizations that need to audit users with SYSDBA or SYSOPER privileges will need to enable this parameter. When set to TRUE, all actions by SYSDBA and SYSOPER users are logged in the operating system file. Note: setting this parameter to TRUE can cause a significant performance hit on the database server. The default value is FALSE.
- remote_login_passwordfile= NONE — Password files allow you to store passwords outside of the database which in turn are used for authenticating administrators (SYSDBA and SYSOPER). The remote_login_passwordfile parameter controls if and how the password file will be used by remote administrators. The parameter value can either be NONE, EXCLUSIVE, or SHARED. NONE restricts the use of the password file; EXCLUSIVE ensures that the password file can be used by only one database; SHARED allows the password file to be used by multiple databases. The security risk of enabling this parameter (SHARED or EXCLUSIVE) is that passwords are vulnerable to theft. Organizations that want to protect against this should set this parameter to NONE.
· audit_trail= NONE – the audit_trail parameter turns auditing on or off. Default is NONE which disables auditing. In most cases you probably want to make sure it stays NONE, as this can incur massive amounts of logging and slow things down. If auditing is desired, there are many possible parameter settings: OS– Oracle writes the audit records to an operating system audit trail; DB – Oracle directs the audit trail to the SYS.AUD$ table; DB,extended – similar to the db setting, but adds two extra columns, SQLBIND and SQLTEXT, to the SYS.AUD$ table; XML – writes audit records to the OS audit trail in XML format; XML,extended – similar to the XML setting, but it includes SQLTEXT and SQLBIND values.
· os_authent_prefix (default is OPS$) — The os_authent_prefix parameter defines a prefix that an Oracle database will append to the front of every operating system username. Oracle will then compare the prefixed OS username with the database username when a user attempts to connect. The provided SQL Server Security Standards Template can be easily used to identify OS authentication prefixes that do not comply vis-à-vis the standard.