Database scanning credential requirements

The credential requirements detailed on this page apply to both vulnerability and policy scans.

Credentials provide InsightVM with the necessary access to scan an asset. Several types of authentication are supported for vulnerability and policy scanning, including authentication for databases such as Microsoft SQL Server (MSSQL), DB2, MySQL, and Oracle.

You add credentials for databases the same way you create shared credentials for authenticated scans. You'll need to add two sets of credentials: one for the database itself and one for the asset host.

For example, if you have Oracle installed on a Linux machine, you'll need to provide the credentials to log in to the Linux machine as well as credentials for the database. If you are scanning a SQL server, you'll need to specify the CIFS/SMB credentials that are needed to connect to the Windows asset.

Requirements for MSSQL credentials

Rapid7 recommends using Windows authentication to run authenticated scans on MSSQL databases.

If you intend to use Windows authentication, your user account must have read permissions for the following tables (permissions are grouped according to MSSQL version):

 
1
{
2
	"Microsoft_SQL_Server_2008_R2": {
3
		"dbo.sysproxylogin",
4
		"sys.server_principals",
5
		"sys.databases",
6
		"sys.symmetric_keys",
7
		"sys.sql_logins",
8
		"sys.configurations",
9
		"sts.configurations",
10
		"sys.asymmetric_keys",
11
		"master.sys.server_permissions",
12
		"sys.assemblies",
13
		"msdb.dbo.sysproxylogin",
14
	},
15
	"Microsoft_SQL_Server_2008_R2_Database_Engine": {
16
		"sys.symmetric_keys",
17
		"sys.sysusers",
18
		"sys.sql_logins",
19
		"sys.configurations",
20
		"sys.asymmetric_keys",
21
		"sts.configurations",
22
		"dbo.sysproxylogin",
23
		"master.sys.server_permissions",
24
		"sys.assemblies",
25
		"sys.server_principals",
26
		"sys.databases"
27
	},
28
	"Microsoft_SQL_Server_2012": {
29
		"dbo.sysproxylogin",
30
		"sys.server_principals",
31
		"sys.sysusers",
32
		"sys.server_audit_specification_details",
33
		"sys.databases",
34
		"sys.symmetric_keys",
35
		"sys.sql_logins",
36
		"sys.configurations",
37
		"sys.asymmetric_keys",
38
		"master.sys.server_permissions",
39
		"sys.assemblies",
40
		"msdb.dbo.sysproxylogin",
41
		"sys.database_principals",
42
	},
43
	"Microsoft_SQL_Server_2014": {
44
		"dbo.sysproxylogin",
45
		"sys.server_principals",
46
		"sys.sysusers",
47
		"sys.asymmetric_keys",
48
		"sys.server_audit_specification_details",
49
		"sys.databases",
50
		"sys.symmetric_keys",
51
		"sys.sql_logins",
52
		"sys.configurations",
53
		"master.sys.server_permissions",
54
		"sys.assemblies",
55
		"msdb.dbo.sysproxylogin",
56
		"sys.database_principals",
57
	},
58
	"Microsoft_SQL_Server_2016": {
59
		"dbo.sysproxylogin",
60
		"sys.dm_exec_connections",
61
		"sys.server_principals",
62
		"sys.sysusers",
63
		"sys.server_audit_specification_details",
64
		"sys.databases",
65
		"sys.symmetric_keys",
66
		"sys.sql_logins",
67
		"sys.configurations",
68
		"sys.asymmetric_keys",
69
		"master.sys.server_permissions",
70
		"sys.assemblies",
71
		"msdb.dbo.sysproxylogin",
72
		"sys.database_principals",
73
	},
74
	"Microsoft_SQL_Server_2017": {
75
		"dbo.sysproxylogin",
76
		"sys.dm_exec_connections",
77
		"sys.server_principals",
78
		"sys.sysusers",
79
		"sys.server_audit_specification_details",
80
		"sys.databases",
81
		"sys.symmetric_keys",
82
		"sys.sql_logins",
83
		"sys.configurations",
84
		"sys.asymmetric_keys",
85
		"master.sys.server_permissions",
86
		"sys.assemblies",
87
		"msdb.dbo.sysproxylogin",
88
		"sys.database_principals",
89
	},
90
	"Microsoft_SQL_Server_2019": {
91
		"dbo.sysproxylogin",
92
		"sys.dm_exec_connections",
93
		"sys.server_principals",
94
		"sys.sysusers",
95
		"sys.server_audit_specification_details",
96
		"sys.databases",
97
		"sys.symmetric_keys",
98
		"sys.sql_logins",
99
		"sys.configurations",
100
		"sys.asymmetric_keys",
101
		"master.sys.server_permissions",
102
		"sys.assemblies",
103
		"msdb.dbo.sysproxylogin",
104
		"sys.database_principals",
105
	}
106
}

If you choose not to use Windows authentication, you must use the System Administrator (SA) account.

Usage of SA account may be against some policy rules

While the SA account provides all the access you need to scan your MSSQL database, some policies may regard the usage of the SA account as a violation of policy rules. This is why we recommend using Windows authentication.

When configuring this credential in the Security Console, the following information is required for MSSQL databases:

  • Service - The service identifies the type of database you want to add credentials for. In this case, you need to set this option to “Microsoft SQL Server”.
  • Database - This is the name of the MSSQL database you’re using. The database field by default is set to master.
  • Domain - If you choose to use Windows authentication, you need to provide the Windows domain name.
  • Username - The name of the user's account which is used for authenticating to the database. Depending on your authentication option, this will either be your own user account with the necessary permissions, or the SA account.
  • Password - The password for the user's account which is used for authenticating to the database.

Requirements for PostgreSQL credentials

PostgreSQL credentials are the credentials used to access the database, not the credentials used to access the system hosting the database.

The credentials have the following fields:

  • Database - This field can be left blank and will default to “template1” or the value provided in the scan template. This needs to be any valid database to allow us to connect. “template1” is a database template available in all Postgres installations unless it has been explicitly removed.
  • Domain - This is unused and should not be present in the UI.
  • Username - The username for the database login.
  • Password - The user password.

Requirements for DB2 credentials

For DB2 databases, the following information is required:

  • Service - The service identifies the type of database you want to add credentials for. For DB2, set this option to "DB2".
  • Database - This is the name of the DB2 database you're using. The default database for DB2 is "DB2COPY1".
  • Domain - This field is optional and only applicable if Windows authentication is enabled. Leave this field blank if the database is not using Windows authentication.
  • Username - This is the username for the account that will be used for authenticating to the database. The default username is "db2admin" for Windows and "db2inst1" for Linux and AIX.
  • Password - This is the password for the account that will be used for authenticating to the database.

Requirements for MySQL credentials

For MySQL databases, the following information is required for authentication:

  • Database - This is the name of the MySQL database you're using.
  • User name - The user name for the account that will be used for authenticating to the database.
  • Password - The password for the account that will be used for authenticating to the database.
  • Permissions - InsightVM requires create and select permissions to the following tables:
 
1
information_schema.GLOBAL_VARIABLES 
2
information_schema.plugins 
3
mysql.user 
4
mysql.slave_master_info 
5
mysql.db

Requirements for Oracle credentials

For Oracle databases, the following information is required for authentication:

  • Service - The service identifies the type of database you want to add credentials for. In this case, you need to set this option to "Oracle" for authentication by SID or to "Oracle Service Name" to authenticate by Service Name.
  • SID - The SID represents the unique name for the database. The default SID is "orcl". If your Oracle environment has been set up to use multiple SIDs, choose the Oracle Net Listener Password option and enter your listener password to enumerate SIDs from your environment. For more information on configuring your Oracle Net Listener password, see Oracle’s help documentation.
    • If you want the scan to enumerate all the SIDS found, you need to specify the SIDs. Use the root credentials provided for the scan instead of the listener password for SID enumeration. The Oracle Listener password on Oracle 12c is not supported.
  • Service Name - The Service Name is an alias for the Oracle Database instance.
  • Username - The username for the account that will be used for authenticating to the database. You can use the sys as sysdba account, which is a default admin account that is created during installation.
  • Password - The password for the account that will be used for authenticating to the database.
  • Permissions - InsightVM requires access to the following tables:
 
1
DBA_USERS_WITH_DEFPWD, ALL_USERS, V$PARAMETER, DBA_PROFILES, DBA_USERS, DBA_TAB_PRIVS, DBA_SYS_PRIVS, DBA_ROLE_PRIVS, ALL_TABLES, DBA_PROXIES, DBA_STMT_AUDIT_OPTS, DBA_PRIV_AUDIT_OPTS, DBA_OBJ_AUDIT_OPTS, V$INSTANCE

Table Access Requirements

InsightVM requires access to the sys.registry$history table in order to determine the patch level of the database. If you’re scanning Oracle DB 12.1.0.2 or newer versions, the scanner needs access to the sys.dba_registry_sqlpatch table instead of sys.registry$history.

Creating a user account with limited access

While InsightVM will scan your database when configured to log in as a highly privileged role such as "sysdba," it is not recommended. You can create a user with more limited access by running the following commands:

 
1
CREATE USER nxpscan IDENTIFIED BY aStrongerPasswordThanThis;
2
GRANT create session TO nxpscan;
3
GRANT select ON sys.registry$history TO nxpscan;

After you create this account, you can configure a site to use your new Oracle credentials.

Policy scanning for Sybase

Policy scanning for Sybase is currently not available.