DbProtect 6.1 Installation Guide

Transcription

1 Last Modified June 1, 2010 Application Security, Inc APPSEC

2 Contents Chapter 1 - Introduction 3 Product, Guide, and Documentation Suite Overview 4 Intended Audience 6 DbProtect Components 8 Customer Support 15 Chapter 2 - Planning Your DbProtect Installation 16 Network Pre-Installation Considerations 17 DbProtect Installation Checklist 19 DbProtect Version Compatibility Matrix, and Determining the Current Version of Installed DbProtect Applications 20 Chapter 3 - Minimum System Requirements 24 DbProtect Suite - Minimum System Requirements 25 Scan Engines - Minimum System Requirements 33 Sensors - Minimum System Requirements 37 Chapter 4 - Licensing 80 Chapter 5 - Installing the DbProtect Components, Logging Into the DbProtect Console, and DbProtect Console Login Trouble- shooting 84 Installing the DbProtect Suite Components 85 Installing Scan Engines 128 Installing, Starting/Stopping, and Reconfiguring the Sensors 140 Logging Into the DbProtect Console (and DbProtect Console Login Troubleshooting) 196 Chapter 6 - Uninstalling the DbProtect Components 205 Uninstalling the DbProtect Suite Components 206 Uninstalling and Unregistering a Sensor 207 Uninstalling and Unregistering a Scan Engine 211 Chapter 7 - Installation Troubleshooting 213 Application Security, Inc. 1

3 Appendices 222 Appendix A: Installing/Uninstalling Sensors in a SQL Server Cluster 223 Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC 233 Appendix C: Modifying the Sensor Listener Port Number 235 Appendix D: Network Ports Used by DbProtect 236 Appendix E: Working with Oracle DDL Triggers (for Host-Based Sensors for Oracle Installed on *nix Platforms Only) 238 Appendix F: Modifying the "Log On As" User for the DbProtect Sensor and DbProtect Message Collector Services 241 Appendix G: DB2 Administrative Client Driver Installation 243 Appendix H: DbProtect Log Files 244 Appendix I: Using App DSN, the Repair ODBC Utility 250 Appendix J: Configuring Your Oracle Audit Trail in Order to Monitor Logins 252 Appendix K: Required Client Drivers for Audits 253 Appendix L: Required Audit Privileges 262 Appendix M: Auditing SQL Server (Using Windows Authentication) Against a Machine on a Different or Untrusted Domain 310 Appendix N: Troubleshooting the Java Run Time Environment (JRE) Security Settings on Internet Explorer 6 and Appendix O: Clearing Your Java Cache 315 Appendix P: Monitoring Multiple Instances on a DB2 Server 316 Appendix Q: Monitoring Oracle Databases in an Oracle Fail Safe Environment: Sensor and Cluster Configuration Steps 317 Appendix R: Configuring Your Host-Based Sensor (Installed on a *nix Platform) to Start Automatically Upon System Reboot 321 Appendix S: Remote-Deploying DbProtect Components on Windows in Your Enterprise 324 Appendix T: Creating Your Own Microsoft SQL Server AppDetective Database 337 Application Security, Inc. 2

4 Chapter 1 - Introduction This chapter explains what s in the DbProtect, the intended audience, and the components of DbProtect. What you will find in this chapter: Product, Guide, and Documentation Suite Overview Intended Audience DbProtect Components Customer Support. Application Security, Inc. 3

5 Product, Guide, and Documentation Suite Overview This section includes an overview, an explanation of conventions used, and a listing of other DbProtect guides available for customers. What you will find in this section: About DbProtect What you will find in this guide If you need more help. About DbProtect The Industry s Only Complete Database Security Solution A centrally-managed enterprise solution for comprehensive database security, DbProtect combines Discovery, vulnerability scanning, and real-time audit and threat management to help organizations reduce risk and enhance compliance. The integrated suite is comprised of the company s flagship solutions for database vulnerability management and real-time database audit and threat management which protect enterprise organizations around the world from all internal and external threats, while also ensuring that those organizations meet or exceed regulatory compliance requirements. Applying the proven security industry best practices of vulnerability management, structured risk mitigation, and real-time intrusion monitoring, coupled with extensive enterprise features (including fine-grained access controls, and centralized management and reporting), DbProtect delivers comprehensive security and auditing capabilities to complex, diverse enterprise database environments. Address Database Threats and Provide Protection with Proven Technology Tamper Evident Privileged Audit and Threat Management defends against misuse, fraud and abuse from internal and external users. Comprehensive Vulnerability Management identifies and reduces risk. Real-Time Monitoring and Intrusion Detection immediately identifies database attacks or misuse. Compensating Controls, including Patch Gap management, assists with prioritizing of database security patches and defending against attack. Improved Integration enables reporting on security patch progress, risk mitigation impact, and overall compliance status. Application Security, Inc. 4

6 Application Awareness provides critical insight into IT infrastructure enabling organizations to better understand their database inventory, and thereby mitigate compliance risk factors, as well as addressing database security needs. Industry-leading Knowledgebase utilizes the most comprehensive catalog of database-specific threats, many discovered by Team SHATTER, our own research and development team. Enhance Regulatory Compliance Efforts DbProtect enables enterprises to ground compliance efforts in the database applications that house regulated data be it material financial transactions, critical intellectual property, or sensitive personal information. The solution also supports forensic investigations and analysis. This approach to database security includes: Robust access and authentication controls Privileged and non-privileged user monitoring Vulnerability and threat management Suspicious audit and threat management with proactive real-time alerts Defined security policies to guide user activity. These security components collectively facilitate regulatory compliance and create active and intelligent protection mechanisms for databases. By grounding efforts in the databases where sensitive data spends the bulk of its existence, the suite helps customers comply with a variety of business and regulatory requirements including the PCI Data Security Standard, HIPAA, GLBA, California Security Breach Information Act (SB 1386), Sarbanes-Oxley Act, Basel II, ISO 27001/17799, DISA-STIG, FISMA, NIST , PIPEDA, Canada s Bill 198, and MITS. What you will find in this guide This guide consists of the following chapters: Chapter 2 - Planning Your DbProtect Installation Chapter 3 - Minimum System Requirements Chapter 4 - Licensing Chapter 5 - Installing the DbProtect Components, Logging Into the DbProtect Console, and DbProtect Console Login Troubleshooting Chapter 6 - Uninstalling the DbProtect Components Chapter 7 - Installation Troubleshooting Appendices. If you need more help You can contact Application Security, Inc. Customer Support any time by ing support@appsecinc.com, or by calling APPSEC or Application Security, Inc. 5

7 Intended Audience This guide intended for persons responsible for installing the core components of DbProtect (i.e., the Console, Scan Engines, and Sensors). Typically, those responsible for installing DbProtect have the following (sometimes overlapping) job roles: system administrators; for more information, see System administrators network administrators; for more information, see Network administrators database administrators; for more information, see Database administrators. System administrators Network administrators The system administrator maintains and operates a computer system and/or network. System administrators are often members of an Information Technology (IT) department. Their duties are wide-ranging, and vary from one organization to another. System administrators are usually charged with installing, supporting, and maintaining servers or other computer systems, and planning for and responding to service outages and other problems. Other duties may include scripting or light programming, project management for systems-related projects, supervising or training computer operators, and being the consultant for computer problems beyond the knowledge of technical support staff. The network administrator is a professional responsible for the maintenance of computer hardware and software that comprises a computer network. This normally includes the deployment, configuration, maintenance and monitoring of active network equipment. Network administration commonly includes activities and tasks such as network address assignment, assignment of routing protocols and routing table configuration, as well as configuration of authentication and authorization-directory services. A network administrator s duties often also include maintenance of network facilities in individual machines, such as drivers and settings of personal computers, as well as printers and so on. Network administration also sometimes entails maintenance of certain network servers, e.g., file servers, VPN gateways, intrusion detection systems, etc. Network specialists and analysts concentrate on the network design and security, particularly troubleshooting and/or debugging network-related problems. Their work can also include the maintenance of the network's authorization infrastructure, as well as network backup systems. In addition, the network administrator is responsible for the security of the network and for assigning IP addresses to the devices connected to the networks. Assigning IP addresses gives the subnet administrator some control over the professional who connects to the subnet. It also helps to ensure that the administrator knows each system that is connected and who personally is responsible for the system. When network administrators give a system an IP address, they also delegate certain security responsibilities to the system administrator. Application Security, Inc. 6

8 Database administrators A database administrator (DBA) is responsible for the environmental aspects of a database. In general, these include: Recoverability. Creating and testing dackups. Integrity. Verifying or helping to verify data integrity. Security. Defining and/or implementing access controls to the data. Availability. Ensuring maximum uptime. Performance. Ensuring maximum performance. Development and testing support. Helping programmers and engineers to efficiently utilize the database. The role of a DBA has changed according to the technology of database management systems (DBMSs), as well as the needs of the database owners. Application Security, Inc. 7

9 DbProtect Components This section provides a comprehensive overview of the DbProtect components. What you will find in this section: Conceptual diagram Console Scan Engines Sensors Networking, port, and firewall considerations Data Repository. Conceptual diagram The following conceptual diagram illustrates how the DbProtect components interact, and indicates which standard listen ports must be open in order for DbProtect to work. Application Security, Inc. 8

10 Console Scan Engines Sensors The Console is the web browser-based, graphical component of DbProtect that allows you to navigate to the various features of DbProtect: Audit and Threat Management and Vulnerability Management. For more information on navigating the Console and using DbProtect, see the DbProtect User s Guide. DbProtect s network-based, Vulnerability Management Scan Engines discover database applications within your infrastructure and assesses their security strength. Backed by a proven security methodology and extensive knowledge of applicationlevel vulnerabilities, DbProtect locates, examines, reports, and fixes security holes and misconfigurations. Scan Engines scan your databases for vulnerabilities, and allow you to perform Penetration (Pen) Tests and Audits against them. Target databases include: Oracle Oracle Application Server SQL Server Lotus Notes/Domino Sybase DB2 DB2 on the Mainframe MySQL. For more information on Scan Engine: minimum system requirements, see Scan Engines - Minimum System Requirements installation instructions, see Installing Scan Engines. Sensors monitor your database for a variety events, such as intrusion attempts or auditing of normal usage. There are two types of Sensors available: Host-based Sensors, which monitor SQL Server, Oracle, or DB2 databases on the host server Network-based Sensors, which monitor your Oracle, DB2 or Sybase databases on the network. Sensors fire Alerts when they detect a violation of rules, and a monitored event occurs. For more information on Alerts, see the DbProtect User s Guide. Application Security, Inc. 9

11 HOST-BASED SENSORS Host-based Sensors allow you to monitor the following databases on a host server: SQL Server on Windows Oracle on Solaris, AIX, HP-UX, Red Hat Enterprise Linux, and Windows DB2 on Solaris, AIX, Red Hat Enterprise Linux, and Windows. The table below lists all supported host-based database/os combinations, and links you to the installation steps. DB OS For minimum system requirements, see: For installation instructions, see: SQL SERVER WINDOWS Host-based Sensor for SQL Server (on Windows) - minimum system requirements Host-based Sensor for SQL Server (on Windows) - installation steps DB2 RED HAT ENTERPRISE LINUX Host-based Sensor for DB2 (on Red Hat Enterprise Linux) - minimum system requirements Host-based Sensor for DB2 (on Red Hat Enterprise Linux) - installation steps SOLARIS Host-based Sensor for DB2 (on Solaris) - minimum system requirements Host-based Sensor for DB2 (on Solaris) - installation steps AIX Host-based Sensor for DB2 (on AIX) - minimum system requirements Host-based Sensor for DB2 (on AIX) - installation steps WINDOWS Host-based Sensor for DB2 (on Windows) - minimum system requirements Host-based Sensor for DB2 (on Windows) - installation steps Application Security, Inc. 10

12 DB OS For minimum system requirements, see: For installation instructions, see: ORACLE SOLARIS Host-based Sensor for Oracle (on Solaris) - minimum system requirements Host-based Sensor for Oracle (on Solaris) - installation steps AIX HP-UX RED HAT ENTERPRISE LINUX WINDOWS Host-based Sensor for Oracle (on AIX) - minimum system requirements Host-based Sensor for Oracle (on HP-UX) - minimum system requirements Host-based Sensor for Oracle (on Red Hat Enterprise Linux) - minimum system requirements Host-based Sensor for Oracle (on Windows) - minimum system requirements Host-based Sensor for Oracle (on AIX) - installation steps Host-based Sensor for Oracle (on HP-UX) - installation steps Host-based Sensor for Oracle (on Red Hat Enterprise Linux) - installation steps Host-based Sensor for Oracle (on Windows) - installation steps NETWORK-BASED SENSORS Network-based Sensors allow you to monitor Windows-based Sybase, Oracle, and DB2 on the network. If you want to install a network-based Sensor, the table below lists supported databases, and links you to the installation steps. Note: Network-based Sensors only run on the Windows OS, but the databases they monitor do not need to be running on Windows. DB DB2 SYBASE ORACLE For minimum system requirements, see: Network-based Sensor for DB2 - minimum system requirements Network-based Sensor for Sybase - minimum system requirements Network-based Sensor for Oracle - minimum system requirements For installation instructions, see: Network-based Sensor for Sybase, Oracle, and DB2 - installation steps Application Security, Inc. 11

13 Networking, port, and firewall considerations This topic consists of the following sub-topics: Networking considerations Port considerations Firewall considerations. NETWORKING CONSIDERATIONS Network connectivity is required for the Console to communicate with the Scan Engines and Sensors, and, optionally, with SNMP and Syslog systems. You should install the Console on a machine connected to the network continuously, if you want to collect real-time data from the Scan Engines and Sensors. The following networking requirements apply specifically to network-based Sensors: Note: The network-based Sensor machine must be on the same Local Area Network (LAN) as the database machine(s) that it is monitoring, or otherwise have access to network traffic going to/coming from each database machine being monitored. You can accomplish this using a variety of methods, including a Switched Port Analyzer (SPAN) port on a Cisco switch, a mirror port, Network Tap, a Data Aggregator device, or re-direction using VLANs. Two network interface cards (NICs) are required, i.e., one for communication from the network-based Sensor to the Console, and one to capture database traffic. The network environment must be standard Ethernet (10MB, 100MB, or 1GB -- whatever standard Ethernet card the machine supports). Older drivers may not work. Other environments currently not supported: ATM, Token Ring, FDDI. Application Security, Inc. recommends you use two network interface cards: one for listening to database traffic, and one to communicate with the Console, if data volume is high. PORT CONSIDERATIONS Important port considerations follow: By default, the Console uses port to receive status messages from the Scan Engines. When a Sensor sends Alerts to the Console Message Collector component, the Message Collector receives these Alerts on port (by default). Scan Engines listen on port (by default) for commands from the Console. Sensors listen on port (by default) for commands from Console. DbProtect Analytics uses port to communicate with the DbProtect Console Application Security, Inc. 12

14 The DbProtect Console -- and every Scan Engine and Sensor -- requires its own dedicated port. Although Scan Engines and Sensors cannot share the same port with any other program, this does not mean each Scan Engine or Sensor requires a different port number on each separate host. For example, you can use the same port number for each Scan Engine or Sensor you install on each individual database host server or Scan Engine server. Or you can specify a different port number for each Scan Engine and Sensor on each host. However, if you are installing a Scan Engine, Sensor, or DbProtect Console on the same host server, you must specify distinct port numbers for each service. You can change the default port values during installation of the DbProtect Console, Scan Engine, or Sensors (on Windows). You can change a Sensor port number for Sensors installed on a *nix platform (or on Microsoft Windows); for more information, see Appendix C: Modifying the Sensor Listener Port Number. No other machines should be permitted to connect to the Sensors. Important: For more information on how the DbProtect components interact, and which default standard listen ports must be open in order for DbProtect to work, see the Conceptual diagram. You can also see Appendix D: Network Ports Used by DbProtect for additional, detailed DbProtect port information. FIREWALL CONSIDERATIONS Important firewall considerations follow: You must allow DbProtect traffic through firewalls. The Console is accessible via HTTPS on port (by default). The same service and port is used for status messages from Scan Engines. You can allow all machines, certain machines, or no machines to have access from outside your firewall. In the latter case, only machines inside the firewall can access DbProtect. This is completely at your discretion, but for convenience Application Security, Inc. recommends you at least allow users to connect from their desktop machines. DbProtect has its own method of authentication and using a firewall is not required to restrict access. The Message Collector component of DbProtect listens for HTTPS traffic on port (unless you configure it differently during the Console installation) which the Sensor uses to send Alerts to the Console. Application Security, Inc. recommends you disallow all traffic to that port except from the Sensors. Components of DbProtect communicate via Internet Protocol (IP) connections. To help you configure your firewall properly, the table in Appendix D: Network Ports Used by DbProtect lists each component and describes how they each use the network. Application Security, Inc. 13

15 Data Repository DbProtect requires a Microsoft SQL Server 2000, Microsoft SQL Server 2005, or Microsoft SQL Server 2008 Data Repository to operate. This Data Repository stores all Alerts and audit data, as well as its system configuration information. During setup, the installation wizard prompts you to specify the Microsoft SQL Server 2000, Microsoft SQL Server 2005, or Microsoft SQL Server 2008 instance where you want to install the Data Repository. Important: Make sure to read Required installation and runtime user account rights and privileges (for the Console and Data Repository) before you install the Console and Data Repository components. What you will find in this help topic: Requirement: Administrators group membership for Windows login Acceptable Data Repository software Local vs. remote installation considerations. Requirement: deleting your existing DbProtect Data Repository If a Data Repository and account already exist on your Microsoft SQL Server database, you must delete them. REQUIREMENT: ADMINISTRATORS GROUP MEMBERSHIP FOR WINDOWS LOGIN You must log on with a Windows account in the Administrators group.this is required to install the Windows service. The service name is DbProtect. For more information on starting and stopping DbProtect services, see the DbProtect Administrator s Guide. ACCEPTABLE DATA REPOSITORY SOFTWARE Your Data Repository can be: Microsoft SQL Server 2000 instance (SP4 or higher) Microsoft SQL Server 2005 Microsoft SQL Server You can install a new instance, or choose an existing instance, for your Data Repository. During setup, the Console installation wizard prompts you to specify the instance where you want to install the Data Repository. LOCAL VS. REMOTE INSTALLATION CONSIDERATIONS You can install your Microsoft SQL Server Data Repository locally or remotely, i.e., on a physical box separate from where the Console is installed. Note: If you supply your own Microsoft SQL Server instance as the Database Repository, you must patch the instance to SP4 or later. Application Security, Inc. 14

16 Customer Support Customer Support is available from 9 A.M. to 9 P.M. (GMT -5) Monday through Friday, except for company holidays. You may contact technical support for the list of company holidays. Extended support of 24x7 is available as an added cost. You may contact sales@appsecinc.com if you require this service. Telephone (in the U.S.): Telephone (outside the U.S.): support@appsecinc.com Application Security, Inc. 15

17 Chapter 2 - Planning Your DbProtect Installation This chapter explains how to plan your DbProtect installation. What you will find in this chapter: Network Pre-Installation Considerations DbProtect Installation Checklist DbProtect Version Compatibility Matrix, and Determining the Current Version of Installed DbProtect Applications. Application Security, Inc. 16

18 Network Pre-Installation Considerations This section provides a comprehensive overview of the DbProtect technical components, and lists What you will find in this section: Network connectivity Ports and firewalls. Network connectivity Ports and firewalls The Console must have network connectivity to the following: all applications you want to monitor all installed Scan Engines all installed Sensors SNMP and Syslog systems (optional). DbProtect has its own method of authentication and using a firewall is not required to restrict access. The Message Collector component of DbProtect listens for HTTPS traffic on port which the Sensor uses to send Alerts to the Console. Application Security, Inc. recommends you disallow all traffic to that port except from the Sensors. Every Sensor installation requires its own dedicated port for communication. Specify which port number the Sensor should use to receive commands from the Console. The Sensor can not share the same port with any other program. This does not mean each Sensor requires a different port number on each separate host server. For example, you can use the same port number for each Sensor you install on each individual host machine (e.g., port 20000). Or you can specify a different port number for each Sensor on each host machine. For more information, see Installing, Starting/Stopping, and Reconfiguring the Sensors. The DbProtect Console uses port (by default) to receive data from the Sensors. The Sensors, by comparison, receives data from the Console on port (by default). Additionally, when the Sensor sends Alerts (via port 20000) to the Console's Message Collector component, the Message Collector receives these Alerts on port (by default). For more information, see DbProtect suite components - installation steps. Note: If you maintain a firewall with hardened security, the traffic on both ports is SSL. DbProtect Analytics uses port to communicate with the DbProtect Console. Application Security, Inc. 17

19 If you are installing a Sensor on the same host server where the Console is installed, do not specify ports or (unless you re certain these ports are available). If you are installing a host-based Sensor on any *nix platform, you can, at any time, change the port number; for more information, see Appendix C: Modifying the Sensor Listener Port Number. Note: No other machines should be permitted to connect to the Sensors. Components of DbProtect communicate via Internet Protocol (IP) connections. To help you configure your firewall properly, the table in Appendix D: Network Ports Used by DbProtect lists each component and describes how they each use the network. Application Security, Inc. 18

20 DbProtect Installation Checklist Below is a checklist for a typical DbProtect installation scenario: Action 1. REVIEW THE MINIMUM SYSTEM REQUIREMENTS. Before you install any software, carefully read the minimum system requirements, prerequisites, and recommendations for: the Console Scan Engines Sensors (host-based or network-based). For more information, see Chapter 3 - Minimum System Requirements. 2. OBTAIN THE LICENSE FILES. For more information, see Chapter 4 - Licensing. 3. INSTALL THE DBPROTECT COMPONENTS. Application Security, Inc. provides you with the installation files for: the DbProtect management bundle, which includes the Console Sensors (host-based or network-based) Scan Engines. Note: The Console and the Scan Engines run on Windows. The host- and networkbased Sensors, however, can run on a variety of database/os combinations. For more information, see Chapter 5 - Installing the DbProtect Components, Logging Into the DbProtect Console, and DbProtect Console Login Troubleshooting. Application Security, Inc. 19

21 DbProtect Version Compatibility Matrix, and Determining the Current Version of Installed DbProtect Applications This section includes a DbProtect version compatibility matrix, and instructions which explain how to determine the current version of any installed DbProtect application (including the Console, Database Component, Scan Engine, and Sensor). DbProtect version compatibility matrix The DbProtect version compatibility matrix is below: Suite Version Console Management Server Database Component Supported Versions of: Scan Engine Sensor Analytics , 6.3, 6.4, 6.5, , 6.2, 6.1, , 3.10, 3.11, , 3.10, 3.9, R , 6.0, 5.8, 5.7, R , 5.8, 5.7, 5.6, , 3.9, , 3.8, R , 5.7, 5.6, R , 5.6, 5.5, 5.4.7, , 5.5, 5.4.7, , 3.7, 3.6, 3.5, , 3.6, 3.5, 3.4, 3.3, , 3.5, 3.4, 3.3, , Application Security, Inc. 20

22 Suite Version Console Management Server Database Component Supported Versions of: Scan Engine Sensor Analytics , 1.2, 1.1, , 5.5, 5.4.7, , 3.5, 3.4, 3.3, 3.2 N/A , 1.2, 1.1, , 5.5, 5.4.7, , 3.5, 3.4, 3.3, R , 1.2, 1.1, , 5.5, 5.4.7, , 3.5, 3.4, 3.3, , 1.2, 1.1, , 5.5, 5.4.7, , 3.5, 3.4, 3.3, 3.2 Determining the current version of any installed DbProtect software component To determine the current version of any installed DbProtect software component: 1. Choose Start > Control Panel to display the Control Panel dialog box. 2. Double click the Add or Remove Programs icon to display the Add or Remove Programs dialog box. Application Security, Inc. 21

23 3. Click any of the following DbProtect applications (assuming they are currently installed on your computer): DbProtect Console Management Server AppSecInc Database Component DbProtect Scan Engine DbProtect Sensor DbProtect Console Message Collector DbProtect Analytics. FIGURE: Add or Remove Programs dialog box (Application Security, Inc. Database Component highlighted) 4. Click the Click here for support information link to display the Support Info pop-up, which lists the exact version number of the installed DbProtect application. FIGURE: Support Info pop-up (Application Security, Inc. Database Component version) Application Security, Inc. 22

24 5. Go to the DbProtect Version Compatibility Matrix, and Determining the Current Version of Installed DbProtect Applications and determine whether the installed version of your DbProtect application is compatible with your DbProtect suite version. Application Security, Inc. 23

25 Chapter 3 - Minimum System Requirements This chapter provides minimum system requirements for the following DbProtect components: the Console, the Sensors, and the Scan Engines. What you will find in this chapter: DbProtect Suite - Minimum System Requirements Scan Engines - Minimum System Requirements Sensors - Minimum System Requirements. Application Security, Inc. 24

26 DbProtect Suite - Minimum System Requirements This section provides detailed minimum system requirements for the DbProtect suite. What you will find in this section: Hardware Back-End Database Operating system Required installation and runtime user account rights and privileges (for the Console and Data Repository) Browser Java Runtime Environment (JRE) Networking, port, and firewall considerations Additional DbProtect suite assumptions, prerequisites, and recommendations. Hardware Back-End Database Processor. 1.5 GHz processor minimum; 2+ GHz processors recommended. Dual processors recommended for larger installations. Dual processors recommended if you are running the Console and a network-based Sensor on the same machine. RAM. 8 GB minimum. DbProtect requires a back-end database, which you connect to using either Windows Authentication (using the Local System Windows Service account) or SQL Authentication. Supported back-end database types include the following: Microsoft SQL Server 2000 SP4 Microsoft SQL Server 2005 Microsoft SQL Server Caution! Microsoft SQL Server Express Editions are not supported. For more information, see Console Management Server Setup. Application Security, Inc. 25

27 Hint: Hard drive space. On the drive where you are installing DbProtect Suite: 20 GB minimum; 35 GB or more recommended (may vary). In addition, you will need 100GB for DbProtect Analytics temporary storage (which may be on a separate hard drive). When you upgrade the DbProtect Console from a version lower than 3.10, the upgrade creates a backup of all files. This means space requirements are temporarily doubled for the period of the upgrade. The upgrade creates backups of the DbProtect and AppDetective folders (DbProtectBackup and AppDetectiveBackup, respectively). You can safely delete these backup files after your upgrade is complete, but only after you have logged into the DbProtect Console to make sure your upgrade was successful, and you can log into the DbProtect Console (for more information on logging into the Console, see Logging Into the DbProtect Console (and DbProtect Console Login Troubleshooting)). You must have a minimum of 1GB of disk space on your C:\ drive -- even if you are installing the DbProtect suite on an alternate drive -- because the installer is uncompressed to the default windows temp directory on C:\. The operating system uses this space for unpacking installer files. This additional space is required only for users installing the product for the first time, as well as those upgrading from previous versions of DbProtect suite. DbProtect Analytics requires temporary disk space in order to process reports. The size of the TEMP folder depends on the size of the reports, which, in turn, depends on the estimates amount of vulnerabilities and vulnerability details in a report. In general, 100 GB of temporary storage is required, but your actual size will vary. Please note that if you run multiple DbProtect Analytics reports concurrently, they will each use the TEMP space. If you don't have enough space on your C:\ drive, there is a workaround. 1.) Right click My Computer and select Properties to display the System Properties dialog box. 2.) Click the Environment Variables button to display the Environment Variables dialog box. 3.) Edit the system environment variables TEMP and TMP to point to another drive that has enough space (e.g., E:\systmp). Operating system The DbProtect suite runs on Windows 2003 or Windows Note: For DbProtect Audit and Threat Management, the Console uses local Microsoft Windows groups for authentication. Consequently, you cannot also use the Console machine as a domain controller. For DbProtect Vulnerability Management, the Console authenticates through Active Directory. Application Security, Inc. 26

28 You must have Microsoft.NET Framework 3.5 SP1 -- among other prerequisite DbProtect Console components -- installed in order to install the DbProtect Console. If the DbProtect installer does not detect Microsoft.NET Framework 3.5 SP1 -- or the other prerequisite DbProtect Console components -- installed on your host server, the installer will prompt you to install it. For more information, see DbProtect suite components - installation steps. Required installation and runtime user account rights and privileges (for the Console and Data Repository) Note: If you are using Windows authentication, your DbProtect Console server and Data Repository database server (if remote) must have a trusted relationship with one another, or be in the same domain/workgroup. The Console requires certain privileges on the host where it is installed, as well as on the associated Data Repository. The following table explains the account privileges required for various aspects of installation and runtime operation of the Console. Account Purpose Used by Requirements Setup User Account used when installing the software for the first time or when upgrading the system. Person installing Member of Windows group Administrators on the DbProtect server host. Note: This user must have privileges on the target database for upgrades. Needs access to SQL Server database master and have SQL Server role Database Creator (dbcreator) or equivalent permissions on the SQL Server to be used for the Data Repository. Note: SQL Server rights are not required if you intend to use SQL authentication credentials when the DbProtect installer prompts you for database installer information. For all operating systems, the Setup User must also have the Logon as a service privilege, and must belong to the local Administrators group. Application Security, Inc. 27

29 Account Purpose Used by Requirements Runtime User Account used to run all of the services in the DbProtect system. Allows DbProtect to read, write and modify data in its backend database. The DbProtect Console, DbProtect Message Collector, and Cognos8 services. Log on as a service Windows user right. Read, write, and change rights to the area of the filesystem where the DbProtect software is installed (the default location is C:\Program Files\AppSecInc). Needs access to the SQL Server database AppDetective and must have the database roles db_datareader and db_datawriter. Note: It is possible to configure the system to use SQL authentication to access the database. In this case, the Runtime User does not need SQL Server access. If you want to run a DbProtect Analytics report with data derived from an external data source (like Oracle Audit Vault), you may encounter an error if the DbProtect suite and Oracle Audit Vault are installed on a different domain. In this case, you must run the Cognos 8 service with a user who can access the domain controller (i.e., run the cognos 8 service as a domain user, not a local system account user). For more information on working with data sources (like Oracle Audit Vault), see the DbProtect User s Guide. Application Security, Inc. 28

30 Account Purpose Used by Requirements Database User Allows DbProtect to read, write and modify data in its Data Repository using SQL authentication. Note: This account is optional. DbProtect Console and DbProtect Message Collector services. Needs access to the SQL Server database AppDetective and have the database roles db_datareader and db_datawriter. Database Installer Account used during the setup process to create and configure the Data Repository. Setup program Needs access to SQL Server database master and have SQL Server role Database Creator (dbcreator) or equivalent permissions on the SQL Server to be used for DbProtect's Data Repository. Note: The user has the option to use the credentials of the Setup User as long as that user has appropriate SQL Server permissions as described above. Browser Java Runtime Environment (JRE) Networking, port, and firewall considerations Internet Explorer 6 or greater with JavaScript enabled. The minimum screen resolution is 1024x768. You must have the Java Runtime Environment (JRE) SE 6 Update 11 installed on your computer in order to connect to the Console via a web browser. The DbProtect installer prompts you to install the JRE if it s not already installed. Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. Application Security, Inc. 29

31 Additional DbProtect suite assumptions, prerequisites, and recommendations The DbProtect suite installation process assumes a clean installation of DbProtect using an Application Security, Inc.-provided CD, or via download from the Application Security, Inc. customer portal site. The DbProtect suite also requires the following prerequisite components to be installed on your DbProtect suite host machine: Note: Setup Support Files Database Schema SHATTER Knowledgebase Management Console Message Collector Analytics and Reporting Vulnerability Assessment (VA) Policy Editor Documentation and Additional Content. Legacy Vulnerability Assessment (VA) Reporting is an optional component. If you do not have these components installed, the DbProtect suite installer can install them for you. For more information, see Installing the DbProtect Suite Components. Additional Console assumptions, prerequisites, and recommendations follow: Microsoft SQL Server 2000 Prerequisite. Patch your Microsoft SQL Server 2000 Data Repository to at least Service Pack 4 (SP4) before installing the Console. For more information, see Data Repository. Administrators Group Prerequisite. You must log on with a Windows account in the Administrators group.this is required to install the Windows service. The service name is DbProtect Console. For more information on starting/ stopping services, see the DbProtect Administrator s Guide. Application Security, Inc. 30

32 Server-Level Login on Microsoft SQL Server (with sysadmin Privileges) Prerequisite. Regardless of which authentication type (i.e., Windows Authentication or SQL Authentication) you choose when you are installing the Console, you must first create the specified account as a server-level login on your Microsoft SQL Server before you begin installing the Console. In addition, your Console server and Data Repository server (if remote) must have a trusted relationship with one another. For example, they must be in the same domain or workgroup. Otherwise you will receive the following error message: Note: "Login failed for user '(null)'. Reason: Not associated with trusted SQL Server Connection." Also, your database server must have a valid Microsoft SQL Server account for the Console server to access. If you want to use: -Microsoft SQL Server authentication, you can create a new username/password, add the necessarily privileges, and install the DbProtect Console with that username/ password. -Windows authentication, you can do the following: By default Microsoft SQL Server 2000 adds the "Builtin\Administrators" group. This means users can add any domain user to the Administrators group in Windows and install the DbProtect Console using that domain user. Or, you can create a new user from the Enterprise Manager with the name "domainname\username", then select Windows Authentication, then enter "domainname". You can now use that domain user to install the DbProtect Console. Microsoft SQL Server 2005/2008 browser service requirement. The Microsoft SQL Server 2005/2008 browser service must be on if you: -have a Microsoft SQL Server 2005/2008 Data Repository installed on a nondefault instance, in order for the DbProtect Console to function correctly -are upgrading from DbProtect or later with a Microsoft SQL Server 2005/2008 Data Repository (i.e., the Microsoft SQL Server 2005/2008 browser service must be running at the time of the upgrade) -plan to specify (or specified) an instance name (not a port) during installation of the Database Component; for more information, see DbProtect suite components - installation steps. If processing speed is an issue, and/or if you plan to audit a large volume of data, Application Security, Inc. recommends you use a Microsoft SQL Server database. Application Security, Inc. 31

33 Windows Installer 3.1. If you do not have Windows Installer 3.1 installed on any supported version of Windows before you run the DbProtect installer, a dialog box informs you that you must install it. You can download Windows Installer 3.1 from the here: details.aspx?familyid=889482fc-5f56-4a38-b838- DE776FD4138C&displaylang=en. For more information on DbProtect installation, see Installing the DbProtect Suite Components. The following prerequisites and recommendations are specifically relevant to logging into the DbProtect Console via a web browser: -You must have 11 of the Java Runtime Environment (JRE) installed on your computer in order to connect to the DbProtect Console via a web browser. The DbProtect installer prompts you to install the JRE if it s not already installed. -Some older version of Google Desktop (5.1 and earlier) may cause problems when loading the DbProtect Console applet in Internet Explorer. You should turn off Google Desktop, or re-install a newer (5.2 or greater) version. -Application Security, Inc. recommends you clear your Java cache after an upgrade. The Java cache does not get automatically cleared following a reboot. For more information, see Appendix O: Clearing Your Java Cache. The Microsoft kb hotfix is required in order to install DbProtect Analytics (part of the DbProtect suite component installation; for more information, see Installing the DbProtect Suite Components). Application Security, Inc. 32

34 Scan Engines - Minimum System Requirements DbProtect s network-based, Vulnerability Management Scan Engines discover database applications within your infrastructure and assesses their security strength. Backed by a proven security methodology and extensive knowledge of applicationlevel vulnerabilities, DbProtect locates, examines, reports, and fixes security holes and misconfigurations. Scan Engines scan your databases for vulnerabilities, and allow you to perform Penetration (Pen) Tests and Audits against them. Target databases include: Oracle Oracle Application Server Microsoft SQL Server Lotus Notes/Domino Sybase DB2 DB2 on the Mainframe MySQL. What you will find in this section: Supported versions of target databases Supported Windows versions (on your Scan Engine host server) Scan Engine prerequisites Rights and privileges Hardware Lotus/Domino requirements Sybase requirements DB2 requirements Networking, port, and firewall considerations. Application Security, Inc. 33

35 Supported versions of target databases The following table lists which databases the Scan Engines are licensable and scannable, and the supported version(s) of each database type. Target database Supported versions ORACLE DATABASE SERVERS MICROSOFT SQL SERVER LOTUS NOTES/ DOMINO SYBASE DATABASE SERVERS Oracle 11gR1, Oracle 11gR2, Oracle 10g, Oracle9i, and Oracle8i. Microsoft SQL Server Versions 2000, 2005, 2005 Express Edition, and MSDE 2000 SP4. Lotus Notes/Domino 6.0, 6.5, 7.0, 8.0, and 8.5. Note: DbProtect Vulnerability Management performs Audits (but not Penetration Tests) against Domino Groupware (Notes). DbProtect Vulnerability Management performs Penetration Tests (but not Audits) against Domino Web. Sybase , 12.0, 12.5, , 15, and Note: An issue exists in the current Sybase 15 driver that results in an DbProtect connection failure when a Sybase 15 driver is installed. This is a known issue with the Sybase driver, and not DbProtect; for more information, see search.sybase.com/kbx/solvedcases?id_number= The current suggested workaround is to use an older Sybase driver, even if you have Sybase 15 installed (the Sybase driver, for example). For more information, see Sybase client/client driver/.net driver installation. IBM DB2 (LUW) IBM DB2 Version 8.1, IBM DB2 Version 8.2, IBM DB2 Version 9.1, and IBM DB2 Version 9.5. IBM DB2 Z SERIES DB2 Version 7, 8, and 9 (z/os and OS/390). Note: Additional requirement: DB2 Connect installed. MYSQL SERVERS MySQL 4.0, 4.1, 5.0, and 5.1. Note: To run an Audit on MySQL, your workstation requires the appropriate MySQL ODBC driver installed. For more information, see MySQL client driver installation. Supported Windows versions (on your Scan Engine host server) Windows 2003 Server SP 2 or greater, Windows Application Security, Inc. 34

36 Scan Engine prerequisites Rights and privileges Hardware The Scan Engine requires the following prerequisite components to be installed on your Scan Engine host machine in order to install the Scan Engine: Microsoft XML Core Services 4.0 SP2 Microsoft.NET Framework 3.5 SP1. Note: x86 will read x64 if you are installing the Scan Engine on a 64-bit host machine. Microsoft Visual Studio 2005 C++ Redistributable (x86) WinPcap for non-admin users who want to run the Scan Engine on any supported Windows version; for more information, see Supported Windows versions (on your Scan Engine host server). If an admin user is going to run the Scan Engine, there is no need to install WinPcap To run an Audit Job on MySQL, your workstation requires the appropriate MySQL ODBC driver installed. For more information, see MySQL client driver installation. If you do not have these components installed, the Scan Engine installer can install them for you. For more information, see Installing Scan Engines. Required rights and privileges follow: Note: To install a Scan Engine, you must have administrative privileges on Windows. Since the Scan Engine installs and runs as a service, the service account must have the logon as a service privilege enabled. The minimum privileges required on the Data Repository are the database roles (db_datawriter and db_datareader). Contact Application Security, Inc. Support at support@appsecinc.com if you plan to install Scan Engines across multiple Active Directory Domains. In order to run DbProtect with a Scan Engine installed, you must have the permission Full Control on the following items: -The directory where you installed DbProtect. -The SYSTEM32 directory. -The registry key HKEY_LOCAL_MACHINE\SOFTWARE\ASI and all subkeys underneath. -The registry key HKEY_LOCAL_MACHINE\SOFTWARE\ODBC and all subkeys underneath. RAM. 1GB or more. Hard drive space. 512 MB of free disk space with additional space required to store vulnerability information. Processor. 1 GHz or larger. Application Security, Inc. 35

37 Lotus/Domino requirements Sybase requirements DB2 requirements Networking, port, and firewall considerations In order to run Lotus Domino features, you must have the Lotus Notes Client installed on your system. DbProtect requires a valid.id file and password to function properly. If you are already a Lotus Notes user, you do not need to reload your Lotus Notes client. For more information, see Lotus Notes client driver installation. Note: DbProtect does not perform Audits on Lotus Notes/Domino applications. To run an Audit on a Sybase SQL Server/Adaptive Server Enterprise application, your workstation requires the appropriate client drivers installed. For more information, see Sybase client/client driver/.net driver installation. You must have Full Control on the registry key: HKEY_LOCAL_MACHINE\SYBASE\Setup. If you are using ODBC Drivers versions less than 3.7, you must also have read/write permissions on the following local system files on the client machine: ${SYBASE_ROOT}\ini\sql.ini. To run an Audit on DB2, your workstation requires the appropriate client drivers installed. For more information, see Appendix G: DB2 Administrative Client Driver Installation. Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. Application Security, Inc. 36

38 Sensors - Minimum System Requirements This section provides detailed minimum system requirements for the host-based and network-based Sensor components of DbProtect. What you will find in this section: Host-based Sensors - supported database platforms Network-based Sensors - supported database platforms Host-based Sensor for SQL Server (on Windows) - minimum system requirements Host-based Sensor for DB2 (on Red Hat Enterprise Linux) - minimum system requirements Host-based Sensor for DB2 (on Solaris) - minimum system requirements Host-based Sensor for DB2 (on AIX) - minimum system requirements Host-based Sensor for DB2 (on Windows) - minimum system requirements Host-based Sensor for Sybase (on Solaris) - minimum system requirements Host-based Sensor for Sybase (on AIX) - minimum system requirements Host-based Sensor for Oracle (on Solaris) - minimum system requirements Host-based Sensor for Oracle (on AIX) - minimum system requirements Host-based Sensor for Oracle (on HP-UX) - minimum system requirements Host-based Sensor for Oracle (on Red Hat Enterprise Linux) - minimum system requirements Host-based Sensor for Oracle (on Windows) - minimum system requirements Network-based Sensor for Sybase - minimum system requirements Network-based Sensor for Oracle - minimum system requirements Network-based Sensor for DB2 - minimum system requirements. Application Security, Inc. 37

39 Host-based Sensors - supported database platforms Host-based Sensors allow you to monitor the following databases on a host server: Microsoft SQL Server on Windows Oracle on Solaris, AIX, HP-UX, Red Hat Enterprise Linux, and Microsoft Windows DB2 on Red Hat Enterprise Linux, Solaris, AIX, and Microsoft Windows Sybase on Solaris and AIX. A host-based Sensor must reside on the same machine as the Microsoft SQL Server instance(s), Oracle SID(s), or DB2 UDB instance it is monitoring. Note: Although it is theoretically possible to install a host-based Sensor and the Console on the same host, Application Security, Inc. recommends that for host-based Sensors on production databases you install the Console and Data Repository on different hosts. For more information, see DbProtect Suite - Minimum System Requirements. The supported database platforms list for host-based Sensors is below. Supported databases Supported OS For more information, see: MICROSOFT SQL SERVER Microsoft SQL Server 2000 (all x86 and x64 editions) Microsoft SQL Server 2005 (all x86 and x64 editions) Microsoft SQL Server 2008 (all x86 and x64 editions) WINDOWS Windows 2000 Server (including Advanced Server), 32-bit and 64-bit (excluding Itanium); Windows Server 2003 (including Enterprise Edition), 32-bit and 64-bit (excluding Itanium); Windows 2008, 32-bit and 64-bit (excluding Itanium). Host-based Sensor for SQL Server (on Windows) - minimum system requirements Application Security, Inc. 38

40 Supported databases Supported OS For more information, see: DB2 DB2 versions 8, 9, and 9.5. SYBASE Sybase 11.x-15. RED HAT ENTERPRISE LINUX Red Hat Enterprise Linux 3, 4, or 5 (32-bit x86 and 64-bit x64). Note: The host-based Sensor installer may display a warning message if you run it on Red Hat Enterprise Linux 3 to inform you DB2 is not supported on version 3. You may safely ignore this warning. SOLARIS Solaris 8, 9, and 10 (32-bit and 64-bit SPARC). AIX AIX 5.2 Technology Level 5 and greater (32-bit and 64- bit). WINDOWS Windows 2000 Server (including Advanced Server), 32-bit and 64-bit (excluding Itanium); Windows Server 2003 (including Enterprise Edition), 32-bit and 64-bit (excluding Itanium); Windows 2008, 32-bit and 64-bit (excluding Itanium). SOLARIS Solaris 8, 9, and 10 (32-bit and 64-bit SPARC). AIX AIX 5.2 Technology Level 5 and greater (32-bit and 64- bit). Host-based Sensor for DB2 (on Red Hat Enterprise Linux) - minimum system requirements Host-based Sensor for DB2 (on Solaris) - minimum system requirements Host-based Sensor for DB2 (on AIX) - minimum system requirements Host-based Sensor for DB2 (on Windows) - minimum system requirements Host-based Sensor for Sybase (on Solaris) - minimum system requirements Host-based Sensor for Sybase (on AIX) - minimum system requirements Application Security, Inc. 39

41 Supported databases Supported OS For more information, see: ORACLE Oracle 9iR2, 10g, 10gR2, and 11gR1. SOLARIS Solaris 8, 9, and 10 (32- and 64-bit SPARC). AIX AIX 5.2 Technology Level 5 and greater. HP-UX HP-UX 11i v1 or later on the PA-RISC processor and HP- UX 11i v2 or later on the Itanium (IA64) processor. RED HAT ENTERPRISE LINUX Red Hat Enterprise Linux 3, 4, and 5 (32-bit x86 and 64- bit x64). WINDOWS Windows 2000 Server (including Advanced Server), 32-bit and 64-bit (excluding Itanium); Windows Server 2003 (including Enterprise Edition), 32-bit and 64-bit (excluding Itanium); Windows 2008, 32-bit and 64-bit (excluding Itanium). Host-based Sensor for Oracle (on Solaris) - minimum system requirements Host-based Sensor for Oracle (on AIX) - minimum system requirements Host-based Sensor for Oracle (on HP-UX) - minimum system requirements Host-based Sensor for Oracle (on Red Hat Enterprise Linux) - minimum system requirements Host-based Sensor for Oracle (on Windows) - minimum system requirements Application Security, Inc. 40

42 Network-based Sensors - supported database platforms Network-based Sensors allow you to monitor Windows-based Sybase, Oracle, and DB2 on the network. If you want to install a network-based Sensor, the table below lists supported database/os combinations, and links you to the minimum system requirements. Network-based Sensors only run on the Windows OS, but the databases they monitor do not need to be running on Windows. The supported database platforms list for network-based Sensors is below. Supported databases Supported OS For more information, see: SYBASE Sybase 11.x-15. ORACLE Oracle 8, 8i, 9iR1, 9iR2, 10gR2, and 11gR1. DB2 DB2 UDB versions 8, 9, and 9.5; DB2 for zseries v8, v7 (DRDA) (TCP/IP). WINDOWS Windows 2000 Server (including Advanced Server), 32-bit and 64-bit (excluding Itanium); Windows Server 2003 (including Enterprise Edition), 32-bit and 64-bit (excluding Itanium); Windows 2008, 32-bit and 64-bit (excluding Itanium). Note: Network-based Sensors only run on the Windows OS, but the databases they monitor do not need to be running on Windows. Network-based Sensor for Sybase - minimum system requirements Network-based Sensor for Oracle - minimum system requirements Network-based Sensor for DB2 - minimum system requirements Host-based Sensor for SQL Server (on Windows) - minimum system requirements This help topic provides detailed minimum system requirements for the host-based Sensor for SQL Server (on Windows). What you will find in this help topic: Supported SQL Server versions Supported Windows versions Rights and privileges Hardware Networking, port, and firewall considerations Important server and instance information SQL Server Cluster support. Application Security, Inc. 41

43 SUPPORTED SQL SERVER VERSIONS Microsoft SQL Server 2000 (all x86 and x64 editions) Microsoft SQL Server 2005 (all x86 and x64 editions) Microsoft SQL Server 2008 (all x86 and x64 editions). SUPPORTED WINDOWS VERSIONS Windows 2000 Server (including Advanced Server), 32-bit and 64-bit (excluding Itanium); Windows Server 2003 (including Enterprise Edition), 32-bit and 64-bit (excluding Itanium); Windows 2008, 32-bit and 64-bit (excluding Itanium). RIGHTS AND PRIVILEGES Installation Rights and Privileges: You need the following rights and privileges to install a host-based Sensor for Microsoft SQL Server (on Windows): To install a host-based Sensor for Microsoft SQL Server, you must be a Windows user with administrative rights on both the host server and Microsoft SQL Server. You must also have domain administrator rights to install a host-based Sensor for SQL Server in a cluster. To run the host-based Sensor for Microsoft SQL Server, you must have "Log on as a service" rights on Windows, and administrative rights on Microsoft SQL Server at runtime. To run the host-based Sensor for Microsoft SQL Server, you must have run as a service" rights on Windows, and administrative rights on Microsoft SQL Server at runtime. Microsoft SQL Server 2005/2008 Windows User Requirement: Microsoft SQL Server 2005/2008 doe not create a login for the Windows user Local System by default. You must run the host-based Sensor for SQL Server (on Windows) as a Windows user that exists in your SQL Server instance. Service Account Requirements: In addition, the service account (i.e., the user running the DbProtect Sensor service) requires, at a minimum: to be in the sysadmin role (Microsoft SQL Server 2000 only) to have ALTER TRACE permission (Microsoft SQL Server 2005/2008 only) to have permission to execute the following stored procedures: -sp_trace_create -sp_trace_setevent -sp_trace_setfilter -sp_trace_getdata -sp_trace_setstatus Application Security, Inc. 42

44 You must also have read/write or full permission on the Sensor installation directory (which is, by default, <installation folder>:/appsecinc/sensor). You must also have read rights on the following register entries (if they exist): HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\SQL_COG_NY_D\Cluster HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\SQL_COG_NY_D\MSSQLServer\CurrentVersion. To use the Audit Filter Wizard (for more information, see the DbProtect User s Guide), the service account must also be able to query the sysobjects table within all databases. HARDWARE RAM. 2GB, or at least 512 MB in addition to operating system and database memory requirements. Application Security, Inc. recommends adding more memory if your data volume is high. Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is required if you configure the Sensor to log to a local file. NETWORKING, PORT, AND FIREWALL CONSIDERATIONS Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. IMPORTANT SERVER AND INSTANCE INFORMATION Each machine should have only one Sensor. Every Sensor requires its own dedicated port for communication. One host-based Sensor for Microsoft SQL Server (on Windows) can monitor multiple instances on a single machine. You can monitor as many Microsoft SQL Server instances as your license allows; for more information, see Chapter 4 - Licensing. SQL SERVER CLUSTER SUPPORT If you want to install a host-based Sensor on a single instance, or multiple instances, of a Microsoft SQL Server Cluster, then you must read Appendix A: Installing/Uninstalling Sensors in a SQL Server Cluster. Application Security, Inc. 43

45 Host-based Sensor for DB2 (on Red Hat Enterprise Linux) - minimum system requirements This help topic provides detailed minimum system requirements for the host-based Sensor for DB2 (on Red Hat Enterprise Linux). What you will find in this help topic: Supported DB2 versions Supported Red Hat Enterprise Linux versions Rights and privileges Required Red Hat Enterprise Linux 32- and 64-bit minimum kernel release MON_HEAP_SZ database configuration parameter Hardware Networking, port, and firewall considerations Important server and instance information Single instance monitoring limitation User group requirement DB2 auditing usage for failed logins. SUPPORTED DB2 VERSIONS DB2 versions 8, 9, and 9.5. SUPPORTED RED HAT ENTERPRISE LINUX VERSIONS Red Hat Enterprise Linux 3, 4, or 5 (32-bit x86 and 64-bit x64). Caution! The host-based Sensor installer may display a warning message if you run it on Red Hat Enterprise Linux 3 to inform you DB2 is not supported on version 3. You may safely ignore this warning. RIGHTS AND PRIVILEGES The DB2 administrator must grant the following privileges to the appradar user for every DB2 database in the instance the user wants to monitor. These privileges are: SYSADM if the user wants to monitor failed logins DBADM if the user does not want to monitor failed logins. REQUIRED RED HAT ENTERPRISE LINUX 32- AND 64-BIT MINIMUM KERNEL RELEASE Host-based Sensors for DB2 on Red Hat Enterprise Linux 32- and 64-bit require a minimum Red Hat Enterprise Linux kernel release of version 2.6. Otherwise, install a kernel patch that supports asynchronous I/O. Application Security, Inc. 44

46 MON_HEAP_SZ DATABASE CONFIGURATION PARAMETER The host-based Sensor for DB2 (on Red Hat Enterprise Linux) uses DB2 internal feature monitoring. The MON_HEAP_SZ database configuration parameter specifies the number of 4KB blocks of memory available to the monitoring facility. If this parameter is set too low, monitoring won t turn on and, consequently, the host-based Sensor for DB2 won t be able to monitor your DB2 database. Application Security, Inc. recommends a value of 1024 for the MON_HEAP_SZ configuration parameter, but you should use the formula provided by IBM to determine your exact monitoring memory requirements. For more information, see com.ibm.db2.udb.doc/admin/c htm HARDWARE RAM. 2GB, or at least 512 MB in addition to operating system and database memory requirements. Application Security, Inc. recommends adding more memory if your data volume is high. Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is required if you configure the Sensor to log to a local file. NETWORKING, PORT, AND FIREWALL CONSIDERATIONS Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. IMPORTANT SERVER AND INSTANCE INFORMATION Each machine should have only one Sensor. Every Sensor requires its own dedicated port for communication. You can monitor as many DB2 instances as your license allows; for more information, see Chapter 4 - Licensing. SINGLE INSTANCE MONITORING LIMITATION A host-based Sensor for DB2 (installed on a *nix platform) can only monitor one DB2 instance. The host-based Sensor for DB2 uses an IBM-provided API that caches the value of the DB2INSTANCE environment variable. Consequently, even if the environment variable s value changes, the API will not switch to the other instance. This prevents the host-based Sensor for DB2 process from monitoring more than one instance at a time, and it prevents it from switching from one instance to another (unless you re-start the Sensor). There is a workaround, however, that allows you to monitor multiple instances on an DB2 server. For more information, see Appendix P: Monitoring Multiple Instances on a DB2 Server. Application Security, Inc. 45

47 USER GROUP REQUIREMENT The account running the DB2 instance must be a member of the AppRadar group, and the account running the Sensor must be a member of the DB2 group. DB2 AUDITING USAGE FOR FAILED LOGINS "Failed login" support utilizes DB2's "auditing" feature. This is unique to host-based Sensors for DB2, since all other types of host-based Sensor utilize "event monitoring." The host-based Sensors for DB2 automatically turns on DB2 auditing. If you enable any Rule related to failed logins (specifically, "Failed Login", "Password Guessing", or "Scripted Password Attack"). The host-based Sensors for DB2 monitor all other types of events using the DB2 "event monitoring" facility. To enable the host-based Sensor for DB2 to activate native auditing (in order to monitor failed login events) set the following parameters during Sensor installation: Set the environment variable DB2INSTANCE to the name of the DB2 instance that you want the host-based Sensor for DB2 to monitor (e.g., DB2INSTANCE=db2inst1) Add the path to the script db2audit.exe (in the DB2 instance installation directory) to the PATH environment variable (e.g., PATH=$PATH:/home/ db2inst1/sqllib/adm). For more information on how the host-based Sensors for DB2 uses auditing to monitor failed logins and how to manually manage the resulting audit files, see the DbProtect Administrator s Guide. Caution! Host-based Sensors for DB2 fully control DB2 "auditing" if user authentication (failed login) events are enabled in a Policy (specifically, "Failed Login", "Password Guessing", or "Scripted Password Attack"). In other words, the host-based Sensor for DB2 turns "auditing" on, sets it, and turns it off. If you are using DB2 "auditing" on other applications, the host-based Sensors for DB2 can potentially override (and effectively disable) DB2 "auditing" on these other applications. The host-based Sensors for DB2 monitor all other types of events using the DB2 "event monitoring" facility. Application Security, Inc. 46

48 Host-based Sensor for DB2 (on Solaris) - minimum system requirements This help topic provides detailed minimum system requirements for the host-based Sensor for DB2 (on Solaris). What you will find in this help topic: Supported DB2 versions Supported Solaris versions Rights and privileges Required Solaris patches Hardware Networking, port, and firewall considerations Important server and instance information Single instance monitoring limitation User group requirement DB2 auditing usage for failed logins. SUPPORTED DB2 VERSIONS DB2 versions 8 and 9. SUPPORTED SOLARIS VERSIONS Solaris 8, 9, and 10 (32- bit and 64-bit SPARC). RIGHTS AND PRIVILEGES The DB2 administrator must grant the following privileges to the appradar user for every DB2 database in the instance the user wants to monitor. These privileges are: SYSADM if the user wants to monitor failed logins DBADM if the user does not want to monitor failed logins. Application Security, Inc. 47

49 REQUIRED SOLARIS PATCHES The following table lists OS patches required for Solaris versions 8 and 9. Solaris version Required patch Solaris 8 Patch Id: Summary: SunOS 5.8: 32-bit shared library patch for C is the corresponding 64-bit patch. Date: Aug/01/2006 Patch Id: Summary: SunOS 5.8: Math Library (libm) patch Date: May/08/2003 Patch Id: Summary: SunOS 5.8: kernel patch Date: Jul/20/2006 Solaris 9 Patch Id: / Summary: SunOS 5.9: 32-bit shared library patch for C is the corresponding 64-bit patch Date: Aug/07/2006 Patch Id: Summary: SunOS 5.9: Math Library (libm) patch Date: May/08/2003 Patch Id: (or better) Summary: SunOS 5.9: Kernel Patch Date: Apr/25/2006 HARDWARE RAM. 2GB, or at least 512 MB in addition to operating system and database memory requirements. Application Security, Inc. recommends adding more memory if your data volume is high. Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is required if you configure the Sensor to log to a local file. NETWORKING, PORT, AND FIREWALL CONSIDERATIONS Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. Application Security, Inc. 48

50 IMPORTANT SERVER AND INSTANCE INFORMATION Each machine should have only one Sensor. Every Sensor requires its own dedicated port for communication. You can monitor as many DB2 instances as your license allows; for more information, see Chapter 4 - Licensing. SINGLE INSTANCE MONITORING LIMITATION A host-based Sensor for DB2 (installed on a *nix platform) can only monitor one DB2 instance. The host-based Sensor for DB2 uses an IBM-provided API that caches the value of the DB2INSTANCE environment variable. Consequently, even if the environment variable s value changes, the API will not switch to the other instance. This prevents the host-based Sensor for DB2 process from monitoring more than one instance at a time, and it prevents it from switching from one instance to another (unless you re-start the Sensor). There is a workaround, however, that allows you to monitor multiple instances on an DB2 server. For more information, see Appendix P: Monitoring Multiple Instances on a DB2 Server. USER GROUP REQUIREMENT The account running the DB2 instance must be a member of the AppRadar group, and the account running the Sensor must be a member of the DB2 group. DB2 AUDITING USAGE FOR FAILED LOGINS "Failed login" support utilizes DB2's "auditing" feature. This is unique to host-based Sensors for DB2, since all other types of host-based Sensor utilize "event monitoring." The host-based Sensors for DB2 automatically turns on DB2 auditing. If you enable any Rule related to failed logins (specifically, "Failed Login", "Password Guessing", or "Scripted Password Attack"). The host-based Sensors for DB2 monitor all other types of events using the DB2 "event monitoring" facility. To enable the host-based Sensor for DB2 to activate native auditing (in order to monitor failed login events) set the following parameters during Sensor installation: Set the environment variable DB2INSTANCE to the name of the DB2 instance that you want the host-based Sensor for DB2 to monitor (e.g., DB2INSTANCE=db2inst1) Add the path to the script db2audit.exe (in the DB2 instance installation directory) to the PATH environment variable (e.g., PATH=$PATH:/home/ db2inst1/sqllib/adm). For more information on how the host-based Sensors for DB2 uses auditing to monitor failed logins and how to manually manage the resulting audit files, see the DbProtect Administrator s Guide. Application Security, Inc. 49

51 Caution! Host-based Sensors for DB2 fully control DB2 "auditing" if user authentication (failed login) events are enabled in a Policy (specifically, "Failed Login", "Password Guessing", or "Scripted Password Attack"). In other words, the host-based Sensor for DB2 turns "auditing" on, sets it, and turns it off. If you are using DB2 "auditing" on other applications, the host-based Sensors for DB2 can potentially override (and effectively disable) DB2 "auditing" on these other applications. The host-based Sensors for DB2 monitor all other types of events using the DB2 "event monitoring" facility. Application Security, Inc. 50

52 Host-based Sensor for DB2 (on AIX) - minimum system requirements This help topic provides detailed minimum system requirements for the host-based Sensor for DB2 (on AIX). What you will find in this help topic: Supported DB2 versions Supported AIX versions Rights and Privileges Hardware Networking, port, and firewall considerations Important server and instance information Single instance monitoring limitation User group requirement DB2 auditing usage for failed logins. SUPPORTED DB2 VERSIONS DB2 versions 8, 9, and 9.5. SUPPORTED AIX VERSIONS AIX 5.2 Technology Level 5 and greater (32-bit and 64-bit). RIGHTS AND PRIVILEGES The DB2 administrator must grant the following privileges to the appradar user for every DB2 database in the instance the user wants to monitor. These privileges are: SYSADM if the user wants to monitor failed logins DBADM if the user does not want to monitor failed logins. HARDWARE RAM. 2GB, or at least 512 MB in addition to operating system and database memory requirements. Application Security, Inc. recommends adding more memory if your data volume is high. Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is required if you configure the Sensor to log to a local file. NETWORKING, PORT, AND FIREWALL CONSIDERATIONS Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. Application Security, Inc. 51

53 IMPORTANT SERVER AND INSTANCE INFORMATION Each machine should have only one Sensor. Every Sensor requires its own dedicated port for communication. You can monitor as many DB2 instances as your license allows; for more information, see Chapter 4 - Licensing. SINGLE INSTANCE MONITORING LIMITATION A host-based Sensor for DB2 (installed on a *nix platform) can only monitor one DB2 instance. The host-based Sensor for DB2 uses an IBM-provided API that caches the value of the DB2INSTANCE environment variable. Consequently, even if the environment variable s value changes, the API will not switch to the other instance. This prevents the host-based Sensor for DB2 process from monitoring more than one instance at a time, and it prevents it from switching from one instance to another (unless you re-start the Sensor). There is a workaround, however, that allows you to monitor multiple instances on an DB2 server. For more information, see Appendix P: Monitoring Multiple Instances on a DB2 Server. USER GROUP REQUIREMENT The account running the DB2 instance must be a member of the AppRadar group, and the account running the Sensor must be a member of the DB2 group. DB2 AUDITING USAGE FOR FAILED LOGINS "Failed login" support utilizes DB2's "auditing" feature. This is unique to host-based Sensors for DB2, since all other types of host-based Sensor utilize "event monitoring." The host-based Sensors for DB2 automatically turns on DB2 auditing. If you enable any Rule related to failed logins (specifically, "Failed Login", "Password Guessing", or "Scripted Password Attack"). The host-based Sensors for DB2 monitor all other types of events using the DB2 "event monitoring" facility. To enable the host-based Sensor for DB2 to activate native auditing (in order to monitor failed login events) set the following parameters during Sensor installation: Set the environment variable DB2INSTANCE to the name of the DB2 instance that you want the host-based Sensor for DB2 to monitor (e.g., DB2INSTANCE=db2inst1) Add the path to the script db2audit (in the DB2 instance installation directory) to the PATH environment variable (e.g., PATH=$PATH:/home/db2inst1/sqllib/ adm). For more information on how the host-based Sensors for DB2 uses auditing to monitor failed logins and how to manually manage the resulting audit files, see the DbProtect Administrator s Guide. Application Security, Inc. 52

54 Caution! Host-based Sensors for DB2 fully control DB2 "auditing" if user authentication (failed login) events are enabled in a Policy (specifically, "Failed Login", "Password Guessing", or "Scripted Password Attack"). In other words, the host-based Sensor for DB2 turns "auditing" on, sets it, and turns it off. If you are using DB2 "auditing" on other applications, the host-based Sensors for DB2 can potentially override (and effectively disable) DB2 "auditing" on these other applications. The host-based Sensors for DB2 monitor all other types of events using the DB2 "event monitoring" facility. Host-based Sensor for DB2 (on Windows) - minimum system requirements This help topic provides detailed minimum system requirements for the host-based Sensor for DB2 (on Red Hat Enterprise Linux). What you will find in this help topic: Supported DB2 versions Supported Windows versions Rights and privileges Hardware Networking, port, and firewall considerations Important server and instance information Network connectivity User group requirement. SUPPORTED DB2 VERSIONS DB2 versions 8, 9, and 9.5. SUPPORTED WINDOWS VERSIONS Windows 2000 Server (including Advanced Server), 32-bit and 64-bit (excluding Itanium); Windows Server 2003 (including Enterprise Edition), 32-bit and 64-bit (excluding Itanium); Windows 2008, 32-bit and 64-bit (excluding Itanium). RIGHTS AND PRIVILEGES The DB2 administrator must grant the following privileges to the appradar user for every DB2 database in the instance the user wants to monitor. These privileges are: SYSADM if the user wants to monitor failed logins DBADM if the user does not want to monitor failed logins. To install a host-based Sensor for DB2, you must be a Windows user with administrative rights on the host server. Application Security, Inc. 53

55 HARDWARE RAM. 2GB, or at least 512 MB in addition to operating system and database memory requirements. Application Security, Inc. recommends adding more memory if your data volume is high. Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is required if you configure the Sensor to log to a local file. NETWORKING, PORT, AND FIREWALL CONSIDERATIONS Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. IMPORTANT SERVER AND INSTANCE INFORMATION Each machine should have only one Sensor. Every Sensor requires its own dedicated port for communication. One host-based Sensor for DB2 (on Windows) can monitor multiple instances on a single machine. You can monitor as many DB2 instances as your license allows; for more information, see Chapter 4 - Licensing. NETWORK CONNECTIVITY Network connectivity is required for communication with the Console and, optionally, with SNMP and Syslog systems. USER GROUP REQUIREMENT The account running the DB2 instance must be a member of the AppRadar group, and the account running the Sensor must be a member of the DB2 group. Host-based Sensor for Sybase (on Solaris) - minimum system requirements This help topic provides detailed minimum system requirements for the host-based Sensor for Sybase (on Solaris). What you will find in this help topic: Supported Sybase versions Supported Solaris versions Rights and privileges Required Solaris patches Interfaces file requirement Sybsecurity prerequisite Hardware Networking, port, and firewall considerations Important server and instance information. Application Security, Inc. 54

56 SUPPORTED SYBASE VERSIONS Sybase 11.x SUPPORTED SOLARIS VERSIONS Solaris 8, 9, and 10 (32- and 64-bit SPARC). RIGHTS AND PRIVILEGES To run the host-based Sensor for Sybase v and above, you must be assigned, at a minimum, the sso_ role. You must also be the owner of the sybsecurity database. To run the host-based Sensor for Sybase v , you must also have select permission on the syssrvroles table in the master database. A command to grant that permission is: grant select on syssrvroles to sso_role. REQUIRED SOLARIS PATCHES The following table lists OS patches required for Solaris versions 8 and 9. Solaris version Required patch Solaris 8 Patch Id: Summary: SunOS 5.8: 32-bit shared library patch for C is the corresponding 64-bit patch. Date: Aug/01/2006 Patch Id: Summary: SunOS 5.8: Math Library (libm) patch Date: May/08/2003 Patch Id: Summary: SunOS 5.8: kernel patch Date: Jul/20/2006 Solaris 9 Patch Id: / Summary: SunOS 5.9: 32-bit shared library patch for C is the corresponding 64-bit patch Date: Aug/07/2006 Patch Id: Summary: SunOS 5.9: Math Library (libm) patch Date: May/08/2003 Patch Id: (or better) Summary: SunOS 5.9: Kernel Patch Date: Apr/25/2006 Application Security, Inc. 55

57 To determine your Solaris patch level: Note: Any user can execute the following command. 1. Execute the following command: uname -a; showrev -p egrep -e '^Patch: ^Patch: ^Patch: ' cut -d" " -f1,2 The output displays your OS and patches; for example: SunOS sunny Generic_ sun4u sparc SUNW,Ultra-80 Patch: Patch: Patch: INTERFACES FILE REQUIREMENT The interfaces file provides *nix clients and servers with connectivity information about a Sybase server. Among other things, this file contains a list of all installed Sybase servers. By default the interfaces file is located in the directory addressed by the SYBASE environment variable. The SYBASE environment variable should point at an interfaces file which lists all the Sybase servers you may want to monitor. SYBSECURITY PREREQUISITE Sybase monitoring requires the presence of the Sybase Security System (sybsecurity) device. The sybsecurity device stores the sybsecurity database. The sybsecurity database is created as part of the auditing configuration process. It contains all the system tables in the model database as well as a system table for keeping track of server-wide auditing options and system tables for the audit trail. sybsecurity is not installed by default when you install Sybase. Instead, you must install sybsecurity separately from the main Sybase installation. If sybsecurity is not installed, Application Security, Inc. provides a script called sybsecurity_installer.sh (stored in the util directory of your host-based Sybase installer) which you can run to automatically install sybsecurity on your Sybase host. HARDWARE RAM. 2GB, or at least 512 MB in addition to operating system and database memory requirements. Application Security, Inc. recommends adding more memory if your data volume is high. Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is required if you configure the Sensor to log to a local file. NETWORKING, PORT, AND FIREWALL CONSIDERATIONS Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. Application Security, Inc. 56

58 IMPORTANT SERVER AND INSTANCE INFORMATION Each machine should have only one Sensor. Every Sensor requires its own dedicated port for communication. One host-based Sensor for Sybase (on Solaris) can monitor multiple Sybase databases on a single machine. You can monitor as many Sybase databases as your license allows; for more information, see Chapter 4 - Licensing. Host-based Sensor for Sybase (on AIX) - minimum system requirements This help topic provides detailed minimum system requirements for the host-based Sensor for Oracle (on AIX). What you will find in this help topic: Supported Sybase versions Supported AIX versions Rights and Privileges Interfaces file requirement Sybsecurity prerequisite Hardware Networking, port, and firewall considerations Important server and instance information. SUPPORTED SYBASE VERSIONS Sybase 11.x SUPPORTED AIX VERSIONS AIX 5.2 Technology Level 5 and greater. RIGHTS AND PRIVILEGES To run the host-based Sensor for Sybase v and above, you must be assigned, at a minimum, the sso_ role. You must also be the owner of the sybsecurity database. To run the host-based Sensor for Sybase v , you must also have select permission on the syssrvroles table in the master database. A command to grant that permission is: grant select on syssrvroles to sso_role. INTERFACES FILE REQUIREMENT The interfaces file provides *nix clients and servers with connectivity information about a Sybase server. Among other things, this file contains a list of all installed Sybase servers. By default the interfaces file is located in the directory addressed by the SYBASE environment variable. The SYBASE environment variable should point at an interfaces file which lists all the Sybase servers you may want to monitor. Application Security, Inc. 57

59 SYBSECURITY PREREQUISITE Sybase monitoring requires the presence of the Sybase Security System (sybsecurity) device. The sybsecurity device stores the sybsecurity database. The sybsecurity database is created as part of the auditing configuration process. It contains all the system tables in the model database as well as a system table for keeping track of server-wide auditing options and system tables for the audit trail. sybsecurity is not installed by default when you install Sybase. Instead, you must install sybsecurity separately from the main Sybase installation. If sybsecurity is not installed, Application Security, Inc. provides a script called sybsecurity_installer.sh (stored in the util directory of your host-based Sybase installer) which you can run to automatically install sybsecurity on your Sybase host. HARDWARE RAM. 2GB, or at least 512 MB in addition to operating system and database memory requirements. Application Security, Inc. recommends adding more memory if your data volume is high. Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is required if you configure the Sensor to log to a local file. NETWORKING, PORT, AND FIREWALL CONSIDERATIONS Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. IMPORTANT SERVER AND INSTANCE INFORMATION Each machine should have only one Sensor. Every Sensor requires its own dedicated port for communication. One host-based Sensor for Sybase (on AIX) can monitor multiple Sybase databases on a single machine. You can monitor as many Sybase databases as your license allows; for more information, see Chapter 4 - Licensing. Application Security, Inc. 58

60 Host-based Sensor for Oracle (on Solaris) - minimum system requirements This help topic provides detailed minimum system requirements for the host-based Sensor for Oracle (on Solaris). What you will find in this help topic: Supported Oracle versions Supported Solaris versions Rights and privileges Required Solaris patches Hardware Networking, port, and firewall considerations Important server and instance information Oracle Word size prerequisite Creating the appradar Runtime User Account and working with Oracle (on Solaris) SGA shared memory permissions Sensor re-start requirement (for DDL trigger removals/re-adds) - on Solaris Configuring a host-based Sensor for Oracle (on Solaris) to monitor Oracle databases on an Oracle RAC. SUPPORTED ORACLE VERSIONS Oracle 9iR2, 10gR1, 10gR2, and 11gR1. SUPPORTED SOLARIS VERSIONS Solaris 8, 9, and 10 (32- and 64-bit SPARC). RIGHTS AND PRIVILEGES Host-based Sensor for Oracle installations on all UNIX platforms (Solaris, AIX, HP-UX, and Red Hat Enterprise Linux) require the following rights and privileges: To install the host-based Sensor for Oracle package, you must have administrative (root) privileges on the host. If this is not possible, a tar distribution of the host-based Sensor for Oracle is also available. To run the host-based Sensor for Oracle, you must use a user that is a member of the same dba group as oracle on the host. The appradar account must belong to the Oracle DBA group or to the database, and it must allow for login by a system account. Application Security, Inc. 59

61 REQUIRED SOLARIS PATCHES The following table lists OS patches required for Solaris versions 8 and 9. Solaris version Required patch Solaris 8 Patch Id: Summary: SunOS 5.8: 32-bit shared library patch for C is the corresponding 64-bit patch. Date: Aug/01/2006 Patch Id: Summary: SunOS 5.8: Math Library (libm) patch Date: May/08/2003 Patch Id: Summary: SunOS 5.8: kernel patch Date: Jul/20/2006 Solaris 9 Patch Id: / Summary: SunOS 5.9: 32-bit shared library patch for C is the corresponding 64-bit patch Date: Aug/07/2006 Patch Id: Summary: SunOS 5.9: Math Library (libm) patch Date: May/08/2003 Patch Id: (or better) Summary: SunOS 5.9: Kernel Patch Date: Apr/25/2006 To determine your Solaris patch level: Note: Any user can execute the following command. 1. Execute the following command: uname -a; showrev -p egrep -e '^Patch: ^Patch: ^Patch: ' cut -d" " -f1,2 The output displays your OS and patches; for example: SunOS sunny Generic_ sun4u sparc SUNW,Ultra-80 Patch: Patch: Patch: Application Security, Inc. 60

62 HARDWARE RAM. 2GB, or at least 512 MB in addition to operating system and database memory requirements. Application Security, Inc. recommends adding more memory if your data volume is high. Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is required if you configure the Sensor to log to a local file. NETWORKING, PORT, AND FIREWALL CONSIDERATIONS Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. IMPORTANT SERVER AND INSTANCE INFORMATION Each machine should have only one Sensor. Every Sensor requires its own dedicated port for communication. One host-based Sensor for Oracle (on Solaris) can monitor multiple Oracle SIDs on a single machine. You can monitor as many Oracle SIDs as your license allows; for more information, see Chapter 4 - Licensing. ORACLE WORD SIZE PREREQUISITE You must install a host-based Sensor for Oracle corresponding to the word-size Oracle uses, not the operating system. For example, if Oracle is 32-bit but the operating system is 64-bit, your host-based Sensor for Oracle must be 32-bit. This is only true for host-based Sensor for Oracle installations, and it s true for all Unix operating systems on which it runs (i.e., AIX, HP-UX, Red Hat Enterprise Linux, and Solaris). CREATING THE APPRADAR RUNTIME USER ACCOUNT AND WORKING WITH ORACLE (ON SOLARIS) SGA SHARED MEMORY PERMISSIONS Creating the appradar Runtime User Account: Application Security, Inc. strongly recommends you create a unique DbProtect user called appradar, and use this account for host-based Sensor for Oracle installation. While creating this user is not mandatory, it will ensure that other database administrators can t turn off your host-based Oracle Sensors. The appradar user must belong to the primary group of the Oracle user. In many cases oracle is the default Oracle user name, while the default group name is typically either oracle or dba. The user (i.e., appradar) must be a member of the same dba group as oracle on the host. To determine your Oracle group name, enter the following command: id oracle. Your Oracle user name (uid) and group name (gid) should display, e.g., uid=1001(oracle) gid=503(dba) Application Security, Inc. 61

63 Note: To ensure proper permissioning, verify group ownership of the Oracle process memory segments by executing ipcs -m. This command displays current user and group memberships of the Oracle segment. Confirm the appradar user has the same primary group as the group ownership of the shared memory, and that this user is also in the dba group. To create the runtime user account: 1. Use an administrative account to create a runtme user account called appradar (suggested name). 2. Set the proper Oracle permissions for this user; see above. Working with Oracle SGA Shared Memory Permissions: The Oracle System Global Area (SGA) is a group of shared memory areas that are dedicated to an Oracle instance. Oracle processes use SGA to store and communicate information. Among other things, SGA allows processes (such as the host-based Sensor for Oracle on any *nix platform) to attach, read, and/or write -- but not execute. SGA properties are similar to those of a file, i.e., owner, group, and mode. The permission to attach, read, and/or write depends on the SGA mode. The mode for shared memory and a file both depend on the umask setting of the OS session that creates the shared memory or file. When you start an Oracle instance, Oracle creates SGA. The SGA mode depends on the umask setting of the OS session which starts the Oracle instance. If the umask setting of the OS session masks the bit "read for group", the SGA's modes will not have permission for the group to read. Consequently, your host-based Sensor for Oracle on any *nix platform -- which is in the same group as Oracle OS user -- can not read information from the SGA. As a result, your host-based Sensor for Oracle on a *nix platform will not fire Alerts. Solution: Use the umask command to change the user mask of the session to make sure the group read bit is not masked off. (An example of a correct setting is: umask 026.) You should place this command in the appropriate shell startup file for the Oracle database user ID. After you change the umask value, restart Oracle. After Oracle starts up, use ipcs m to check the SGA to make sure the modes for the Oracle segments include group read, which grants other users in this group permission to read the segment. This allows the appradar runtime user (who is part of the same group) to read the SGA and monitor activity. SENSOR RE-START REQUIREMENT (FOR DDL TRIGGER REMOVALS/RE-ADDS) - ON SOLARIS If you remove and re-add a DDL trigger for any reason, you must re-start the Sensor afterwards. Most DDL rules will not fire until this is done. Application Security, Inc. 62

64 CONFIGURING A HOST-BASED SENSOR FOR ORACLE (ON SOLARIS) TO MONITOR ORACLE DATABASES ON AN ORACLE RAC Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle relational database management system (RDBMS) software simultaneously while accessing a single database, thus providing a clustered database. For more information on configuring a host-based Sensor (regardless of the host operating system) to monitor databases on an Oracle RAC, see Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC. Host-based Sensor for Oracle (on AIX) - minimum system requirements This help topic provides detailed minimum system requirements for the host-based Sensor for Oracle (on AIX). What you will find in this help topic: Supported Oracle versions Supported AIX versions Rights and privileges Hardware Networking, port, and firewall considerations Important server and instance information Oracle Word size prerequisite Creating the appradar Runtime User Account and working with Oracle (on AIX) SGA shared memory permissions Sensor re-start requirement (for DDL trigger removals/re-adds) - on AIX Configuring a host-based Sensor for Oracle (on AIX) to monitor Oracle databases on an Oracle RAC. SUPPORTED ORACLE VERSIONS Oracle 9iR2, 10gR1, 10gR2, and 11gR1. SUPPORTED AIX VERSIONS AIX 5.2 Technology Level 5 and greater. Application Security, Inc. 63

65 RIGHTS AND PRIVILEGES Host-based Sensor for Oracle installations on all UNIX platforms (Solaris, AIX, HP-UX, and Red Hat Enterprise Linux) require the following rights and privileges: To install the host-based Sensor for Oracle package, you must have administrative (root) privileges on the host. If this is not possible, a tar distribution of the host-based Sensor for Oracle is also available. To run the host-based Sensor for Oracle, you must use a user that is a member of the same dba group as oracle on the host. HARDWARE RAM. 2GB, or at least 512 MB in addition to operating system and database memory requirements. Application Security, Inc. recommends adding more memory if your data volume is high. Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is required if you configure the Sensor to log to a local file. NETWORKING, PORT, AND FIREWALL CONSIDERATIONS Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. IMPORTANT SERVER AND INSTANCE INFORMATION Each machine should have only one Sensor. Every Sensor requires its own dedicated port for communication. One host-based Sensor for Oracle (on AIX) can monitor multiple instances on a single machine. You can monitor as many Oracle SIDs as your license allows; for more information, see Chapter 4 - Licensing. ORACLE WORD SIZE PREREQUISITE You must install a host-based Sensor for Oracle corresponding to the word-size Oracle uses, not the operating system. For example, if Oracle is 32-bit but the operating system is 64-bit, your host-based Sensor for Oracle must be 32-bit. This is only true for host-based Sensor for Oracle installations, and it s true for all Unix operating systems on which it runs (i.e., AIX, HP-UX, Red Hat Enterprise Linux, and Solaris). Application Security, Inc. 64

66 CREATING THE APPRADAR RUNTIME USER ACCOUNT AND WORKING WITH ORACLE (ON AIX) SGA SHARED MEMORY PERMISSIONS Creating the appradar Runtime User Account: Application Security, Inc. strongly recommends you create a unique DbProtect user called appradar, and use this account for host-based Sensor for Oracle installation. While creating this user is not mandatory, it will ensure that other database administrators can t turn off your host-based Oracle Sensors. The appradar user must belong to the primary group of the Oracle user. In many cases oracle is the default Oracle user name, while the default group name is typically either oracle or dba. The user (i.e., appradar) must be a member of the same dba group as oracle on the host. To determine your Oracle group name, enter the following command: id oracle. Your Oracle user name (uid) and group name (gid) should display, e.g., uid=1001(oracle) gid=503(dba) Note: To ensure proper permissioning, verify group ownership of the Oracle process memory segments by executing ipcs -m. This command displays current user and group memberships of the Oracle segment. Confirm the appradar user has the same primary group as the group ownership of the shared memory, and that this user is also in the dba group. To create the runtime user account: 1. Use an administrative account to create a runtime user account called appradar (suggested name). 2. Set the proper Oracle permissions for this user; see above. Working with Oracle SGA Shared Memory Permissions: The Oracle System Global Area (SGA) is a group of shared memory areas that are dedicated to an Oracle instance. Oracle processes use SGA to store and communicate information. Among other things, SGA allows processes (such as the host-based Sensor for Oracle on any *nix platform) to attach, read, and/or write -- but not execute. SGA properties are similar to those of a file, i.e., owner, group, and mode. The permission to attach, read, and/or write depends on the SGA mode. The mode for shared memory and a file both depend on the umask setting of the OS session that creates the shared memory or file. When you start an Oracle instance, Oracle creates SGA. The SGA mode depends on the umask setting of the OS session which starts the Oracle instance. If the umask setting of the OS session masks the bit "read for group", the SGA's modes will not have permission for the group to read. Consequently, your host-based Sensor for Oracle on any *nix platform -- which is in the same group as Oracle OS user -- can not read information from the SGA. As a result, your host-based Sensor for Oracle on a *nix platform will not fire Alerts. Application Security, Inc. 65

67 Solution: Use the umask command to change the user mask of the session to make sure the group read bit is not masked off. (An example of a correct setting is: umask 026.) You should place this command in the appropriate shell startup file for the Oracle database user ID. After you change the umask value, restart Oracle. After Oracle starts up, use ipcs m to check the SGA to make sure the modes for the Oracle segments include group read, which grants other users in this group permission to read the segment. This allows the appradar runtime user (who is part of the same group) to read the SGA and monitor activity. SENSOR RE-START REQUIREMENT (FOR DDL TRIGGER REMOVALS/RE-ADDS) - ON AIX If you remove and re-add a DDL trigger for any reason, you must re-start the Sensor afterwards. Most DDL rules will not fire until this is done. CONFIGURING A HOST-BASED SENSOR FOR ORACLE (ON AIX) TO MONITOR ORACLE DATABASES ON AN ORACLE RAC Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle relational database management system (RDBMS) software simultaneously while accessing a single database, thus providing a clustered database. For more information on configuring a host-based Sensor (regardless of the host operating system) to monitor databases on an Oracle RAC, see Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC. Host-based Sensor for Oracle (on HP- UX) - minimum system requirements This help topic provides detailed minimum system requirements for the host-based Sensor for Oracle (on HP-UX). What you will find in this help topic: Supported Oracle versions Supported HP-UX versions Rights and privileges Hardware Networking, port, and firewall considerations Important server and instance information Oracle Word size prerequisite Creating the appradar Runtime User Account and working with Oracle (on Solaris) SGA shared memory permissions Sensor re-start requirement (for DDL trigger removals/re-adds) - on HP-UX Configuring a host-based Sensor for Oracle (on HP-UX) to monitor Oracle databases on an Oracle RAC. SUPPORTED ORACLE VERSIONS Oracle 9iR2, 10gR1, 10gR2, and 11gR1. Application Security, Inc. 66

68 SUPPORTED HP-UX VERSIONS HP-UX 11i v1 or later on the PA-RISC processor and HP-UX 11i v2 or later on the Itanium (IA64) processor. RIGHTS AND PRIVILEGES Host-based Sensor for Oracle installations on all UNIX platforms (Solaris, AIX, HP-UX, and Red Hat Enterprise Linux) require the following rights and privileges: To install the host-based Sensor for Oracle package, you must have administrative (root) privileges on the host. If this is not possible, a tar distribution of the host-based Sensor for Oracle is also available. To run the host-based Sensor for Oracle, you must use a user that is a member of the same dba group as oracle on the host. HARDWARE RAM. 2GB, or at least 512 MB in addition to operating system and database memory requirements. Application Security, Inc. recommends adding more memory if your data volume is high. Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is required if you configure the Sensor to log to a local file. NETWORKING, PORT, AND FIREWALL CONSIDERATIONS Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. IMPORTANT SERVER AND INSTANCE INFORMATION Each machine should have only one Sensor. Every Sensor requires its own dedicated port for communication. One host-based Sensor for Oracle (on HP-UX) can monitor multiple instances on a single machine. You can monitor as many Oracle SIDs as your license allows; for more information, see Chapter 4 - Licensing. ORACLE WORD SIZE PREREQUISITE You must install a host-based Sensor for Oracle corresponding to the word-size Oracle uses, not the operating system. For example, if Oracle is 32-bit but the operating system is 64-bit, your host-based Sensor for Oracle must be 32-bit. This is only true for host-based Sensor for Oracle installations, and it s true for all Unix operating systems on which it runs (i.e., AIX, HP-UX, Red Hat Enterprise Linux, and Solaris). Application Security, Inc. 67

69 CREATING THE APPRADAR RUNTIME USER ACCOUNT AND WORKING WITH ORACLE (ON HP-UX) SGA SHARED MEMORY PERMISSIONS Creating the appradar Runtime User Account: Application Security, Inc. strongly recommends you create a unique DbProtect user called appradar, and use this account for host-based Sensor for Oracle installation. While creating this user is not mandatory, it will ensure that other database administrators can t turn off your host-based Oracle Sensors. The appradar user must belong to the primary group of the Oracle user. In many cases oracle is the default Oracle user name, while the default group name is typically either oracle or dba. The user (i.e., appradar) must be a member of the same dba group as oracle on the host. To determine your Oracle group name, enter the following command: id oracle. Your Oracle user name (uid) and group name (gid) should display, e.g., uid=1001(oracle) gid=503(dba) Note: To ensure proper permissioning, verify group ownership of the Oracle process memory segments by executing ipcs -m. This command displays current user and group memberships of the Oracle segment. Confirm the appradar user has the same primary group as the group ownership of the shared memory, and that this user is also in the dba group. To create the runtime user account: 1. Use an administrative account to create a runtime user account called appradar (suggested name). 2. Set the proper Oracle permissions for this user; see above. Working with Oracle SGA Shared Memory Permissions: The Oracle System Global Area (SGA) is a group of shared memory areas that are dedicated to an Oracle instance. Oracle processes use SGA to store and communicate information. Among other things, SGA allows processes (such as the host-based Sensor for Oracle on any *nix platform) to attach, read, and/or write -- but not execute. SGA properties are similar to those of a file, i.e., owner, group, and mode. The permission to attach, read, and/or write depends on the SGA mode. The mode for shared memory and a file both depend on the umask setting of the OS session that creates the shared memory or file. When you start an Oracle instance, Oracle creates SGA. The SGA mode depends on the umask setting of the OS session which starts the Oracle instance. If the umask setting of the OS session masks the bit "read for group", the SGA's modes will not have permission for the group to read. Consequently, your host-based Sensor for Oracle on any *nix platform -- which is in the same group as Oracle OS user -- can not read information from the SGA. As a result, your host-based Sensor for Oracle on a *nix platform will not fire Alerts. Application Security, Inc. 68

70 Solution: Use the umask command to change the user mask of the session to make sure the group read bit is not masked off. (An example of a correct setting is: umask 026.) You should place this command in the appropriate shell startup file for the Oracle database user ID. After you change the umask value, restart Oracle. After Oracle starts up, use ipcs m to check the SGA to make sure the modes for the Oracle segments include group read, which grants other users in this group permission to read the segment. This allows the appradar runtime user (who is part of the same group) to read the SGA and monitor activity. SENSOR RE-START REQUIREMENT (FOR DDL TRIGGER REMOVALS/RE-ADDS) - ON HP-UX If you remove and re-add a DDL trigger for any reason, you must re-start the Sensor afterwards. Most DDL rules will not fire until this is done. CONFIGURING A HOST-BASED SENSOR FOR ORACLE (ON HP- UX) TO MONITOR ORACLE DATABASES ON AN ORACLE RAC Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle relational database management system (RDBMS) software simultaneously while accessing a single database, thus providing a clustered database. For more information on configuring a host-based Sensor (regardless of the host operating system) to monitor databases on an Oracle RAC, see Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC. Host-based Sensor for Oracle (on Red Hat Enterprise Linux) - minimum system requirements This help topic provides detailed minimum system requirements for the host-based Sensor for Oracle (on Red Hat Enterprise Linux). What you will find in this help topic: Supported Oracle versions Supported Red Hat Enterprise Linux versions Rights and privileges Hardware Networking, port, and firewall considerations Important server and instance information Oracle Word size prerequisite Creating the appradar Runtime User Account and working with Oracle (on Red Hat Enterprise Linux) SGA shared memory permissions Sensor re-start requirement (for DDL trigger removals/re-adds) - on Red Hat Enterprise Linux. Configuring a host-based Sensor for Oracle (on Red Hat Enterprise Linux) to monitor Oracle databases on an Oracle RAC. Application Security, Inc. 69

71 SUPPORTED ORACLE VERSIONS Oracle 9iR2, 10gR1, 10gR2, and 11gR1. SUPPORTED RED HAT ENTERPRISE LINUX VERSIONS Red Hat Enterprise Linux 3, 4, and 5 (32-bit x86 and 64-bit x64). RIGHTS AND PRIVILEGES Host-based Sensor for Oracle installations on all UNIX platforms (Solaris, AIX, HP-UX, and Red Hat Enterprise Linux) require the following rights and privileges: To install the host-based Sensor for Oracle package, you must have administrative (root) privileges on the host. If this is not possible, a tar distribution of the host-based Sensor for Oracle is also available. To run the host-based Sensor for Oracle, you must use a user that is a member of the same dba group as oracle on the host. HARDWARE RAM. 2GB, or at least 512 MB in addition to operating system and database memory requirements. Application Security, Inc. recommends adding more memory if your data volume is high. Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is required if you configure the Sensor to log to a local file. NETWORKING, PORT, AND FIREWALL CONSIDERATIONS Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. IMPORTANT SERVER AND INSTANCE INFORMATION Each machine should have only one Sensor. Every Sensor requires its own dedicated port for communication. One host-based Sensor can monitor multiple instances on a single machine. You can monitor as many Oracle SIDs as your license allows; for more information, see Chapter 4 - Licensing. ORACLE WORD SIZE PREREQUISITE You must install a host-based Sensor for Oracle corresponding to the word-size Oracle uses, not the operating system. For example, if Oracle is 32-bit but the operating system is 64-bit, your host-based Sensor for Oracle must be 32-bit. This is only true for host-based Sensor for Oracle installations, and it s true for all Unix operating systems on which it runs (i.e., AIX, HP-UX, Red Hat Enterprise Linux, and Solaris). Application Security, Inc. 70

72 CREATING THE APPRADAR RUNTIME USER ACCOUNT AND WORKING WITH ORACLE (ON RED HAT ENTERPRISE LINUX) SGA SHARED MEMORY PERMISSIONS Creating the appradar Runtime User Account: Application Security, Inc. strongly recommends you create a unique DbProtect user called appradar, and use this account for host-based Sensor for Oracle installation. While creating this user is not mandatory, it will ensure that other database administrators can t turn off your host-based Oracle Sensors. The appradar user must belong to the primary group of the Oracle user. In many cases oracle is the default Oracle user name, while the default group name is typically either oracle or dba. The user (i.e., appradar) must be a member of the same dba group as oracle on the host. To determine your Oracle group name, enter the following command: id oracle. Your Oracle user name (uid) and group name (gid) should display, e.g., uid=1001(oracle) gid=503(dba) Note: To ensure proper permissioning, verify group ownership of the Oracle process memory segments by executing ipcs -m. This command displays current user and group memberships of the Oracle segment. Confirm the appradar user has the same primary group as the group ownership of the shared memory, and that this user is also in the dba group. To create the runtime user account: 1. Use an administrative account to create a runtime user account called appradar (suggested name). 2. Set the proper Oracle permissions for this user; see above. Working with Oracle SGA Shared Memory Permissions: The Oracle System Global Area (SGA) is a group of shared memory areas that are dedicated to an Oracle instance. Oracle processes use SGA to store and communicate information. Among other things, SGA allows processes (such as the host-based Sensor for Oracle on any *nix platform) to attach, read, and/or write -- but not execute. SGA properties are similar to those of a file, i.e., owner, group, and mode. The permission to attach, read, and/or write depends on the SGA mode. The mode for shared memory and a file both depend on the umask setting of the OS session that creates the shared memory or file. When you start an Oracle instance, Oracle creates SGA. The SGA mode depends on the umask setting of the OS session which starts the Oracle instance. If the umask setting of the OS session masks the bit "read for group", the SGA's modes will not have permission for the group to read. Consequently, your host-based Sensor for Oracle on any *nix platform -- which is in the same group as Oracle OS user -- can not read information from the SGA. As a result, your host-based Sensor for Oracle on a *nix platform will not fire Alerts. Application Security, Inc. 71

73 Solution: Use the umask command to change the user mask of the session to make sure the group read bit is not masked off. (An example of a correct setting is: umask 026.) You should place this command in the appropriate shell startup file for the Oracle database user ID. After you change the umask value, restart Oracle. After Oracle starts up, use ipcs m to check the SGA to make sure the modes for the Oracle segments include group read, which grants other users in this group permission to read the segment. This allows the appradar runtime user (who is part of the same group) to read the SGA and monitor activity. SENSOR RE-START REQUIREMENT (FOR DDL TRIGGER REMOVALS/RE-ADDS) - ON RED HAT ENTERPRISE LINUX If you remove and re-add a DDL trigger for any reason, you must re-start the Sensor afterwards. Most DDL rules will not fire until this is done. CONFIGURING A HOST-BASED SENSOR FOR ORACLE (ON RED HAT ENTERPRISE LINUX) TO MONITOR ORACLE DATABASES ON AN ORACLE RAC Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle relational database management system (RDBMS) software simultaneously while accessing a single database, thus providing a clustered database. For more information on configuring a host-based Sensor (regardless of the host operating system) to monitor databases on an Oracle RAC, see Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC. Host-based Sensor for Oracle (on Windows) - minimum system requirements This help topic provides detailed minimum system requirements for the host-based Sensor for Oracle (on Windows). What you will find in this help topic: Supported Oracle versions Supported Windows versions Rights and privileges Hardware Networking, port, and firewall considerations Important server and instance information Oracle-reserved character installation restriction Configuring a host-based Sensor for Oracle (on Windows) to monitor Oracle databases on an Oracle RAC Configuring a host-based Sensor for Oracle (on Windows) to monitor Oracle databases in an Oracle Fail Safe environment. SUPPORTED ORACLE VERSIONS Oracle 9iR2, 10gR1, 10gR2, and 11gR1. Application Security, Inc. 72

74 SUPPORTED WINDOWS VERSIONS Windows 2000 Server (including Advanced Server), 32-bit and 64-bit (excluding Itanium); Windows Server 2003 (including Enterprise Edition), 32-bit and 64-bit (excluding Itanium); Windows 2008, 32-bit and 64-bit (excluding Itanium). RIGHTS AND PRIVILEGES To install a host-based Sensor for Oracle, you must be a Windows user with administrative rights on the host server. HARDWARE RAM. 2GB, or at least 512 MB in addition to operating system and database memory requirements. Application Security, Inc. recommends adding more memory if your data volume is high. Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is required if you configure the Sensor to log to a local file. NETWORKING, PORT, AND FIREWALL CONSIDERATIONS Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. IMPORTANT SERVER AND INSTANCE INFORMATION Each machine should have only one Sensor. Every Sensor requires its own dedicated port for communication. One host-based Sensor for Oracle (on Windows) can monitor multiple instances on a single machine. You can monitor as many Oracle SIDs as your license allows; for more information, see Chapter 4 - Licensing. ORACLE-RESERVED CHARACTER INSTALLATION RESTRICTION Make sure you install your host-based Sensor for Oracle (on Windows) in a path that does not include Oracle-reserved characters such as parentheses. This is an Oracle restriction. For example: C:\Program Files (x86). In a case such as this, you must install the host-based Sensor for Oracle (on Windows) in another location. Application Security, Inc. 73

75 CONFIGURING A HOST-BASED SENSOR FOR ORACLE (ON WINDOWS) TO MONITOR ORACLE DATABASES ON AN ORACLE RAC Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle relational database management system (RDBMS) software simultaneously while accessing a single database, thus providing a clustered database. For more information on configuring a host-based Sensor (regardless of the host operating system) to monitor databases on an Oracle RAC, see Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC. CONFIGURING A HOST-BASED SENSOR FOR ORACLE (ON WINDOWS) TO MONITOR ORACLE DATABASES IN AN ORACLE FAIL SAFE ENVIRONMENT Windows-only Oracle Fail Safe is another type of Oracle cluster. It is a core feature included with every Oracle 11gR1, Oracle 10g and Oracle9i license for Microsoft Windows 2000 and Microsoft Windows Oracle Fail Safe is integrated with Microsoft Cluster Server to allow you to configure and verify Microsoft Windows clusters and to automatically fail over Oracle databases and applications. For more information on configuring a host-based Sensor for Oracle on Windows to monitor Oracle databases in an Oracle Fail Safe environment, see Appendix Q: Monitoring Oracle Databases in an Oracle Fail Safe Environment: Sensor and Cluster Configuration Steps. Network-based Sensor for Sybase - minimum system requirements This help topic provides detailed minimum system requirements for the networkbased Sensor for Sybase. What you will find in this help topic: Supported Sybase versions Supported Windows versions Rights and privileges Hardware Networking, port, and firewall considerations. SUPPORTED SYBASE VERSIONS Sybase 11.x SUPPORTED WINDOWS VERSIONS Windows 2000 Server (including Advanced Server), 32-bit and 64-bit (excluding Itanium); Windows Server 2003 (including Enterprise Edition), 32-bit and 64-bit (excluding Itanium); Windows 2008, 32-bit and 64-bit (excluding Itanium). Note: Network-based Sensors only run on the Windows OS, but the databases they monitor do not need to be running on Windows. Application Security, Inc. 74

76 RIGHTS AND PRIVILEGES To install the network-based Sensor, you must have administrative privileges on Windows. To run the network-based Sensor, you must have administrative and run as a service" privileges on Windows. To create a custom Filter for Sybase, you require read access to the following tables: master..sysdatabases and the sysobjects, sysusers, and syscolumns tables in the target databases being audited. For more information on Filters, see the DbProtect Administrator s Guide and the DbProtect User s Guide. HARDWARE Dedicated hardware recommendation. Application Security, Inc. recommends you install the network-based Sensor on dedicated hardware, because it improves performance and it s easier to support. However, you can install the network-based Sensor and the Console on the same machine. Note: Generally, to facilitate the networking requirements listed below, your network administrator will install the network-based Sensor on a machine in the same data center as the database(s) it will be monitoring. RAM. At least 512 MB. Application Security, Inc. recommends adding more memory if your data volume is high. Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is required if you configure the to log to a local file. NETWORKING, PORT, AND FIREWALL CONSIDERATIONS Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. The following consideration The following networking requirements apply specifically to network-based Sensors: The network-based Sensor machine must be on the same Local Area Network (LAN) as the database machine(s) that it is monitoring, or otherwise have access to network traffic going to/coming from each database machine being monitored. You can accomplish this using a variety of methods, including a Switched Port Analyzer (SPAN) port on a Cisco switch, a mirror port, Network Tap, a Data Aggregator device, or re-direction using VLANs. Two network interface cards (NICs) are required, i.e., one for communication from the network-based Sensor to the Console, and one to capture database traffic. The network environment must be standard Ethernet (10MB, 100MB, or 1GB -- whatever standard Ethernet card the machine supports). Older drivers may not work. Other environments currently not supported: ATM, Token Ring, FDDI. Application Security, Inc. 75

77 Note: Application Security, Inc. recommends you use two network interface cards: one for listening to database traffic, and one to communicate with the Console, if data volume is high. Network-based Sensor for Oracle - minimum system requirements This help topic provides detailed minimum system requirements for the networkbased Sensor for Oracle. What you will find in this help topic: Supported Oracle versions Supported Windows versions Rights and privileges Hardware Networking, port, and firewall considerations. SUPPORTED ORACLE VERSIONS Oracle 8, 8i, 9iR2, 10gR1, 10gR2, and 11gR1. SUPPORTED WINDOWS VERSIONS Windows 2000 Server (including Advanced Server), 32-bit and 64-bit (excluding Itanium); Windows Server 2003 (including Enterprise Edition), 32-bit and 64-bit (excluding Itanium); Windows 2008, 32-bit and 64-bit (excluding Itanium). Note: Network-based Sensors only run on the Windows OS, but the databases they monitor do not need to be running on Windows. RIGHTS AND PRIVILEGES To install the network-based Sensor, you must have administrative privileges on Windows. To run the network-based Sensor, you must have administrative and run as a service" privileges on Windows. To create a custom Filter for Oracle, you must have the following privileges: all_users, all_tables, all_tab_columns, and all_objects. For more information on Filters, see the DbProtect Administrator s Guide and the DbProtect User s Guide. HARDWARE RAM. 2GB, or at least 512 MB in addition to operating system and database memory requirements. Application Security, Inc. recommends adding more memory if your data volume is high. Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is required if you configure the Sensor to log to a local file. Application Security, Inc. 76

78 Note: Dedicated hardware recommendation. Application Security, Inc. recommends you install the network-based Sensor on dedicated hardware, because it improves performance and it s easier to support. However, you can install the network-based Sensor and the Console on the same machine. Generally, to facilitate the networking requirements listed below, your network administrator will install the network-based Sensor on a machine in the same data center as the database(s) it will be monitoring. NETWORKING, PORT, AND FIREWALL CONSIDERATIONS Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. The following consideration The following networking requirements apply specifically to network-based Sensors: Note: The network-based Sensor machine must be on the same Local Area Network (LAN) as the database machine(s) that it is monitoring, or otherwise have access to network traffic going to/coming from each database machine being monitored. You can accomplish this using a variety of methods, including a Switched Port Analyzer (SPAN) port on a Cisco switch, a mirror port, Network Tap, a Data Aggregator device, or re-direction using VLANs. Two network interface cards (NICs) are required, i.e., one for communication from the network-based Sensor to the Console, and one to capture database traffic. The network environment must be standard Ethernet (10MB, 100MB, or 1GB -- whatever standard Ethernet card the machine supports). Older drivers may not work. Other environments currently not supported: ATM, Token Ring, FDDI. Application Security, Inc. recommends you use two network interface cards: one for listening to database traffic, and one to communicate with the Console, if data volume is high. Network-based Sensor for DB2 - minimum system requirements This help topic provides detailed minimum system requirements for the networkbased Sensor for DB2. What you will find in this help topic: Supported DB2 versions Supported Windows versions Rights and privileges Hardware Networking, port, and firewall considerations. SUPPORTED DB2 VERSIONS DB2 UDB versions 8, 9, and 9.5; DB2 for zseries v8, v7 (DRDA) (TCP/IP). Application Security, Inc. 77

79 SUPPORTED WINDOWS VERSIONS Windows 2000 Server (including Advanced Server), 32-bit and 64-bit (excluding Itanium); Windows Server 2003 (including Enterprise Edition), 32-bit and 64-bit (excluding Itanium); Windows 2008, 32-bit and 64-bit (excluding Itanium). Note: Network-based Sensors only run on the Windows OS, but the databases they monitor do not need to be running on Windows. RIGHTS AND PRIVILEGES To install the network-based Sensor, you must have administrative privileges on Windows. To run the network-based Sensor, you must have administrative and run as a service" privileges on Windows. To create a custom Filter for DB2, you must install the appropriate DB2 administrative client drivers (for more information, see Appendix G: DB2 Administrative Client Driver Installation), and configure it to recognize the monitored database (either through Discovery or reference). Creating a custom Filter for DB2 also requires access to read the following tables: -sysibm.systables -ysibm.syscolumns -sysibm.sysroutines For more information on Filters, see the DbProtect Administrator s Guide and the DbProtect User s Guide. HARDWARE Note: RAM. 2GB, or at least 512 MB in addition to operating system and database memory requirements. Application Security, Inc. recommends adding more memory if your data volume is high. Hard drive space. 50 MB of free disk space. A minimum of 100 MB of space is required if you configure the Sensor to log to a local file. Dedicated hardware recommendation. Application Security, Inc. recommends you install the network-based Sensor on dedicated hardware, because it improves performance and it s easier to support. However, you can install the network-based Sensor and the Console on the same machine. Generally, to facilitate the networking requirements listed below, your network administrator will install the network-based Sensor on a machine in the same data center as the database(s) it will be monitoring. Application Security, Inc. 78

80 NETWORKING, PORT, AND FIREWALL CONSIDERATIONS Please see Networking, port, and firewall considerations for important information on network connectivity, port availability, and firewalls. The following consideration The following networking requirements apply specifically to network-based Sensors: Note: The network-based Sensor machine must be on the same Local Area Network (LAN) as the database machine(s) that it is monitoring, or otherwise have access to network traffic going to/coming from each database machine being monitored. You can accomplish this using a variety of methods, including a Switched Port Analyzer (SPAN) port on a Cisco switch, a mirror port, Network Tap, a Data Aggregator device, or re-direction using VLANs. Two network interface cards (NICs) are required, i.e., one for communication from the network-based Sensor to the Console, and one to capture database traffic. The network environment must be standard Ethernet (10MB, 100MB, or 1GB -- whatever standard Ethernet card the machine supports). Older drivers may not work. Other environments currently not supported: ATM, Token Ring, FDDI. Application Security, Inc. recommends you use two network interface cards: one for listening to database traffic, and one to communicate with the Console, if data volume is high. Application Security, Inc. 79

81 Chapter 4 - Licensing This chapter explains DbProtect licensing. What you will find in this chapter: DbProtect licensing overview How are licenses consumed? The mechanics of DbProtect licensing Viewing your node locked Scan Engine licensing information. DbProtect licensing overview How are licenses consumed? DbProtect licensing is enforced and controlled by information obtained from an Application Security, Inc.-provided set of license files. If a license is not installed, you will not be able to log into DbProtect. If you have subscribed to software updates, the license file also determines when the DbProtect maintenance subscription is scheduled to expire. DbProtect license files are node locked. In order to receive a license for your product implementation, you will need to provide some specific details about your server(s) to Application Security, Inc. Each database/application on your network requires a license to be Penetration Tested or Audited (by a Scan Engine) or monitored (by a Sensor). Discovery results are not metered. Vulnerabilty Assessment license consumption. When you run a test against a database/application for the first time, one license of the appropriate type (i.e., Penetration Test or Audit) is consumed from the available set of licenses for that particular database/application type. The consumed license is then node locked to the IP address of the Penetration Tested or Audited database/ application. You can re-test these applications any time without consuming another license. For more information on viewing your number of available licenses, see Viewing your node locked Scan Engine licensing information. Audit and Threat Management license consumption. When you enumerate a database asset to monitor with the appropriate type of Sensor, the Sensor registration process is what consumes a Sensor license. The license remains node locked for a given database as long as it is registered via the Sensor Manager in DbProtect Audit and Threat Management (for more information, see Registering a Sensor in the DbProtect User s Guide). Application Security, Inc. 80

82 The mechanics of DbProtect licensing To use DbProtect, you must install at least two license files, i.e., one for DbProtect, and one for each registered/installed Scan Engine. What you will find in this help topic: What you will need Licensing artifacts Deploying your license files Viewing your node locked Scan Engine licensing information. WHAT YOU WILL NEED Contact Application Security, Inc. Customer Support and provide the following information: For each host where a Console and a Scan Engine is installed, provide Application Security, Inc. Customer Support with the VolumeID, and specify the number of Penetration Test and Audit licenses you require for each database type. Note: To obtain the VolumeID, run asiidentify.exe at the command line. By default, asiidentify.exe is usually located in the following folder: C:\<DbProtect Installation Folder>\AppSecInc\DbProtect\GUI\bin Application Security, Inc. Customer Support or your sales representative will your license files and installation instructions. LICENSING ARTIFACTS Application Security, Inc. Customer Support will you a set of license files (ADnnnnnnnnn.lic and ARnnnnnnnnn.lic). You must copy the: ADnnnnnnnnn.lic and ARnnnnnnnnn.lic license files on your DbProtect host, so you can manage database threats and perform audits via the Console ADnnnnnnnnn.lic on each host running a Scan Engine (to activate Vulnerability Management). The following sub-topic (Deploying your license files) explains specifically where you should deploy your license (.lic) files. Application Security, Inc. 81

83 DEPLOYING YOUR LICENSE FILES The following table explains specifically where you should deploy your license (.lic) files. On your DbProtect host: Install each ADnnnnnnnnn.lic file in the following folders: c:\<dbprotect Installation Folder>\Program Files\AppSecInc\Common Files\licenses\ c:\<dbprotect Installation Folder>\Program Files\AppSecInc\Common Files\licenses\ Install each ARnnnnnnnnn.lic file in the following folder: c:\<dbprotect Installation Folder>\AppSecInc\DbProtect\GUI\licenses On each Scan Engine host: Install each ADnnnnnnnnn.lic file in the following folders: c:\<dbprotect Installation Folder>\AppSecInc\AppDetective\licenses c:\<dbprotect Installation Folder>\AppSecInc\licenses If you are adding or changing any licenses, then you must manually restart the following services (as applicable to the host): DbProtect Console DbProtect Scan Engine. Viewing your node locked Scan Engine licensing information On any Scan Engine host, you can open the License Viewer. It shows where your Scan Engine license file is located, how many licenses you have, how many Penetration Test and Audit licenses you ve used (and on which platforms), etc. To view your Scan Engine licensing info: 1. Choose Start > Programs > AppSecInc > AppDetective ScanEngine > LicenseViewer.exe to display the License Viewer. The License Viewer provides: the license file location in the License File: field (stored by default in the c:\<dbprotect Installation Folder>\AppSecInc\Adscanengine\adse\licenses folder Application Security, Inc. 82

84 your basic license file information, including: - Customer Name - License Type - Product Version - Expiration Date - ASAP Expiration - Machine ID# 2. The AppDetective - Licensing Info dialog box allows you to: view how many licenses you purchased (see the Licenses Purchased: field, which is below the Penetration Tests and Security Audits tabs) click the Penetration Tests and Security Audits tabs, respectively, to see how many Penetration Test and Audit licenses you ve used to-date use the Application Type: drop-down to filter your used license data by platform (e.g., Oracle, My SQL, Sybase, Web Applications, etc.). 3. You can also click the: Get Machine ID # button to display the AppDetective - Machine ID Number pop up, which displays your machine ID Hint: Click the Copy to clipboard button to copy your machine ID to your computer s clipboard, whereupon you can paste the number into a field, document, etc. Select License File button to display an Open dialog box, which allows you to open your.lic file. Application Security, Inc. 83

85 Chapter 5 - Installing the DbProtect Components, Logging Into the DbProtect Console, and DbProtect Console Login Troubleshooting This chapter explains how to install the following DbProtect components: the DbProtect suite components (which include the Database Schema, the SHATTER Knowledgebase, the Management Console; the Console Message Collector, DbProtect Analytics, and Documentation and Additional Content.) Scan Engines Sensors. This chapter also explains how to log into the Console for the first time. Note: First make sure you have carefully read the minimum system requirements for the DbProtect components. For more information, see Chapter 3 - Minimum System Requirements. What you will find in this chapter: Installing the DbProtect Suite Components Installing Scan Engines Installing, Starting/Stopping, and Reconfiguring the Sensors Logging Into the DbProtect Console (and DbProtect Console Login Troubleshooting). Application Security, Inc. 84

86 Installing the DbProtect Suite Components What you will find in this section: DbProtect suite components Installing files to a drive other than the default C drive Post-upgrade recommendation: clear your Java cache Pre-upgrade requirement: set Windows "Recovery" settings to "no action" DbProtect suite components - installation steps. DbProtect suite components The DbProtect suite is comprised of a management bundle, which consists of the following components: Database Schema; for more information, see Database Component Setup SHATTER Knowledgebase; for more information, see AppSecInc SHATTER Knowledgebase Setup Management Console; for more information, see Console Management Server Setup Console Message Collector; for more information, see Console Message Collector Setup DbProtect Analytics; for more information, see DbProtect Analytics Setup Legacy VA (Vulnerability Assessment) Reporting, i.e., an optional component (unchecked by default) that allows you to add (or exclude) legacy Vulnerability Assessment reports to your DbProtect suite installation (in addition to the Cognos reports available in DbProtect Analytics). If you do not want to include legacy Vulnerability Assessment reports in your DbProtect suite installation, then do not select the Legacy VA Reporting option during your DbProtect suite installation. As a result, legacy Vulnerability Assessment reports will not be available. For more information, see the DbProtect User s Guide. On the other hand, if you want to include legacy Vulnerability Assessment reports in your DbProtect suite installation, then you should select the Legacy VA Reporting option during your DbProtect suite installation. As a result, legacy Vulnerability Assessment reports will be available. For more information, see the DbProtect User s Guide. VA (Vulnerability Assessment) Policy Editor, which adds a Policy Editor to the Start menu, allowing you to edit a Policy. This feature is required. For more information on editing Policies and using the Policy Editor, see the DbProtect User s Guide. Application Security, Inc. 85

87 Documentation and Additional Content. In addition, the DbProtect suite employs data collection agents: a Scan Engine (for Vulnerability Assessment), and Sensors (for Audit and Threat Management), and Analytics (for reporting). The DbProtect suite is deployed as one distribution, which detects/installs prerequisites, and installs the necessary components. Note: First make sure you have carefully read the minimum system requirements for the Console and Data Repository. For more information, see DbProtect Suite - Minimum System Requirements. Installing files to a drive other than the default C drive Post-upgrade recommendation: clear your Java cache Pre-upgrade requirement: set Windows "Recovery" settings to "no action" The DbProtect suite installer places the components and the license files into a common area: the Windows Program Files directory default (C:\Program Files). If you want to install these files on a different drive, refer to support.microsoft.com/kb/933700, which has instructions on (and warnings about) changing the default Program Files location. Application Security, Inc. recommends you clear your Java cache after an upgrade. The Java cache does not get automatically cleared following a reboot. For more information, see Appendix O: Clearing Your Java Cache. Windows services have a set of "Recovery" settings. You must set these to "no action" before you upgrade to a newer version of DbProtect. Otherwise, the upgrade may fail. Application Security, Inc. 86

88 DbProtect suite components - installation steps This topic explains how to install the following DbProtect suite components: Database Component Setup AppSecInc SHATTER Knowledgebase Setup Console Management Server Setup Console Message Collector Setup DbProtect Analytics Setup. All components are deployed as one distribution. To install the DbProtect suite: 1. Locate the DbProtect setup file on the Application Security, Inc.-provided CD, or download it from the Application Security, Inc. customer portal site. If downloading, save the file to a convenient location (e.g., c:\temp). Application Security, Inc. 87

89 2. The installer detects/installs prerequisites. Double click DbProtect suite executable (DbProtect_Setup.exe) file to begin installing the DbProtect suite. The first screen of the DbProtect suite installer checks your host machine for prerequisites and components, and displays which (if any) missing prerequisites and components it will install for you. For more information, see DbProtect Suite - Minimum System Requirements. FIGURE: DbProtect suite installer Application Security, Inc. 88

90 Note: All DbProtect suite components are required, except for the optional Legacy VA (Vulnerability Assessment) Reporting option. As explained in DbProtect suite components, Legacy VA (Vulnerability Assessment) Reporting is an optional component that allows you to add (or exclude) legacy Vulnerability Assessment reports to your DbProtect suite installation (in addition to the Cognos reports available in DbProtect Analytics). If you do not want to include legacy Vulnerability Assessment reports in your DbProtect suite installation, then do not select the Legacy VA Reporting option during your DbProtect suite installation. As a result, legacy Vulnerability Assessment reports will not be available. For more information, see the DbProtect User s Guide. On the other hand, if you want to include legacy Vulnerability Assessment reports in your DbProtect suite installation, then you should select the Legacy VA Reporting option during your DbProtect suite installation. As a result, legacy Vulnerability Assessment reports will be available. For more information, see the DbProtect User s Guide. By default, the DbProtect installer installs the DbProtect suite components under C:\Program Files\AppSecInc. You can manually enter a new destination path in the Destination folder: field, or click the folder/magnifying glass icon to locate a destination folder. The common bootstrapper command line parameter /ControlArgs INSTALLLOCATION: path allows you to specify the DbProtect suite installation location, e.g., DbProtect_Setup.exe /ControlArgs INSTALLLOCATION: C:\Program Files\AppSecInc2 /qb. For more information on common bootstrapper command line parameters, see Appendix S: Remote-Deploying DbProtect Components on Windows in Your Enterprise. Read the License Agreement (which you can display by clicking the I have read and accept the license agreement link). If you accept the terms of the License Agreement, check the I have read and accept the license agreement checkbox to illuminate the Install button. Click the Install button to begin the installation of the prerequisites (if any are listed), and the components in the order in which they are displayed. 3. The installation begins. The DbProtect suite installer installs any missing prerequisites and components detected in Step 2. Note: Depending which prerequisites and components are missing, this part of the installation could take some time. For example, if your host server is missing Microsoft.NET Framework 3.5 SP1. Next the Database Component Setup Wizard welcome screen displays. Application Security, Inc. 89

91 DATABASE COMPONENT SETUP Note: The DbProtect suite installer automatically installs an AppDetective Microsoft SQL Server database as part of the Database Component installation process. However, you can create your own AppDetective Microsoft SQL Server database, as long as it adheres to specific requirements outlined in Appendix T: Creating Your Own Microsoft SQL Server AppDetective Database. If your AppDetective Microsoft SQL Server database does not adhere to these requirements, the Database Component installation will fail (meaning, your entire DbProtect suite installation will also fail). 4. if you want to include Vulnerability The Database Component Setup welcome screen is shown below. Database Component Setup FIGURE: Database Component Setup (welcome screen) Click the Next button to display the Database Component (End-User License Agreement) screen. Application Security, Inc. 90

92 5. The Database Component Setup (End-User License Agreement) screen is shown below. FIGURE: Database Component Setup (End-User License Agreement) screen Read the License Agreement. If you accept the terms of the License Agreement, check I accept the terms of the license agreement to illuminate the Next button. Click the Next button to display the Destination Folder screen. Application Security, Inc. 91

93 6. The Destination Folder screen is shown below. FIGURE: Database Component Setup (Destination Folder screen) By default, the DbProtect installer installs the Database Component in the \Database sub-folder located under C:\Program Files\AppSecInc. You can click the Change... button to specify a different installation path for the Database Component. Click the Next button to display the Database Component Repository screen. Application Security, Inc. 92

94 7. The Database Component Repository screen is shown below. FIGURE: Note: Database Component Setup (Database Component Repository screen) The DbProtect suite requires a Microsoft SQL Server data respository. This screen allows you to specify the location of the Microsoft SQL Server instance, which can be local or remote. You can use the Database Instance drop-down to select an available instance for the Database Component Repository. Or you can manually enter an instance name (in the editable Database Instance dropdown field) using the syntax hostname\instance (e.g., myserver\myinstance) or hostname:port (e.g., myserver:1883). If you enter hostname:port, you do not need to have the SQL Server browser service turned on; for more information, see Additional DbProtect suite assumptions, prerequisites, and recommendations. Important: If you want to change the username/password to connect to the back-end database, you can do so with the Configuration Manager tool; for more information, see Appendix F: Using the Configuration Manager Tool in the DbProtect User s Guide. However, if you want to change the back-end database host or port, see Appendix G: Moving or Changing Your DbProtect Back-End Database in the DbProtect Administrator s Guide. Application Security, Inc. 93

95 Hint: If you select an instance name and the SQL Server browser service is down at the time of installation, an error message displays informing you the installer was unable to establish a connection to the specified instance. However, if you select an instance name and SQL Server browser service is up at the time of installation - - but then is subsequently turned off -- DbProtect will not be able to function until you turn the SQL Server browser service back on, or change the connection string to a valid port number instead of an instance name. You can also click the Browse... button to locate a different instance on your network. The Select Computer pop-up displays, allowing you to search for a database host. Click the Next button to display the Database Installation Credentials screen. 8. The Database Installation Credentials screen is shown below (with the default Windows Authentication database authentication type selected). FIGURE: Database Component Setup (Database Installation Credentials screen --default Windows Authentication database authentication type selected) The Database User Credentials screen allows you to select the authentication type to use to connect to the database. DbProtect will use this user to create/modify tables, views, and other objects in the database. Note: The DbProtect suite installer automatically creates the database. Application Security, Inc. 94

96 Select one of the following authentication types for the database user: Note: Windows Authentication (default), and go to Step 9 SQL Authentication, and go to Step 10. If you're not sure which authentication type to select, see your database administrator. 9. If you selected default Windows Authentication database authentication type in Step 8, the Database Installation Credentials screen looks like this: FIGURE: Database Component Setup (Database Installation Credentials screen -- default Windows Authentication database authentication type selected) The default Windows Authentication (a/k/a <domain\user>) database authentication type uses the Windows credentials from the account with which you are currently logged in (for fresh installations). You must click the Test Connection button to test the database user credentials. If the connection is successful, a green checkmark icon displays, and the Next button is illuminated. You can click either one of the following buttons: -Modify Database Properties button to display the Database Properties dialog box, which allows you to modify your database data file and log file location. Go to Step 11. -Next button to display the Ready to Install Database Component screen and go to Step 12. Application Security, Inc. 95

97 Note: These credentials are used only for first-time installations in order to create the database. When you upgrade, the DbProtect installer will attempt to use Windows Authentication (if possible). If Windows Authentication fails, this screen displays during the upgrade. 10.If you selected default SQL Authentication database authentication type in Step 8, the Database Installation Credentials screen looks like this: FIGURE: Database Component Setup (Database Installation Credentials screen -- SQL Authentication database authentication type selected Important: Make sure you have enabled SQL authentication on the database. Hint: Enter a valid Login: and Password: combination. You must click the Test Connection button to test the database user credentials. If the connection is successful, a green checkmark icon displays, and the Next button is illuminated. You can check the Remember the database credentials for upgrades checkbox (unchecked by default) if you want to store this SQL authentication login/password combination to use when you upgrade to a newer version of DbProtect in the future. This checkbox only displays if you select the SQL Authentication database authentication type. Application Security, Inc. 96

98 Note: You can click either one of the following buttons: -Modify Database Properties button to display the Database Properties dialog box, which allows you to modify your database data file and log file location. Go to Step 11. -Next button to display the Ready to Install Database Component screen and go to Step 12. DbProtect does not store the credentials provided in this step unless you check the Remember the database credentials for upgrades checkbox. These credentials are used only for first-time installations in order to create the database. 11.If you click the Modify Database Properties button in Step 9 or Step 10, the Database Properties dialog box displays, which allows you to modify your database data file and log file location. FIGURE: Database Component Setup Wizard (Database Properties screen) Important: This is an advanced option, and if you have no reason to force locations, Application Security, Inc. recommends you leave these fields blank. Do the following: Hint: Specify the: -Database data file path -Database log file path. You can click the Recommend Path button to have the Database Component Setup Wizard populate the fields automatically. Application Security, Inc. 97

99 Click the: -OK button to apply any changes you made to the database data file and/or log file locations. -Cancel button to cancel any changes. Go back to the Database Installation Credentials screen displayed in Step 9 (if you selected Windows Authentication in Step 8), or the Database Installation Credentials screen displayed Step 10 (if you selected SQL Authentication in Step 8). 12.The Ready to Install Database Component screen is shown below. FIGURE: Database Component Setup Wizard (Ready to Install Database Component screen) Click the Install button to install the Database Component. Note: The DbProtect suite installer automatically installs an AppDetective Microsoft SQL Server database as part of the Database Component installation process. However, the installation may fail if you created your own AppDetective Microsoft SQL Server database, but it does not adhere to specific requirements outlined in Appendix T: Creating Your Own Microsoft SQL Server AppDetective Database. If your AppDetective Microsoft SQL Server database does not adhere to these requirements, the Database Component installation will fail (meaning, your entire DbProtect suite installation will also fail). When the installation is complete, the Completed the Database Component Setup Wizard screen displays. Application Security, Inc. 98

100 13.The Completed the Database Component Setup Wizard screen is shown below. FIGURE: Database Component Setup Wizard (Completed the Database Component Setup Wizard screen) Click the Finish button to complete the Database Component installation. Next, the Console Management Server Setup wizard welcome screen displays. Application Security, Inc. 99

101 APPSECINC SHATTER KNOWLEDGEBASE SETUP 14.The AppSecInc SHATTER Knowledgebase Setup wizard welcome screen is shown below. FIGURE: Note: AppSecInc SHATTER Knowledgebase Setup Wizard (welcome screen) Application Security, Inc. strongly recommends you close all other applications before continuing the installation. Application Security, Inc. 100

102 15.The AppSecInc SHATTER Knowledgebase Setup wizard welcome screen is shown below. FIGURE: Note: AppSecInc SHATTER Knowledgebase Setup Wizard (welcome screen) Application Security, Inc. strongly recommends you close all other applications before continuing the installation. Application Security, Inc. 101

103 16.The AppSecInc SHATTER Knowledgebase Setup Wizard (Ready to Install AppSecInc SHATTER Knowledgebase) screen is shown below. FIGURE: AppSecInc SHATTER Knowledgebase Setup Wizard (Ready to Install AppSecInc SHATTER Knowledgebase) screen Note: Application Security, Inc. strongly recommends you close all other applications before continuing the installation. Click the Install button to install the AppSecInc SHATTER Knowledgebase. When the installation is complete, the Completed the AppSecInc SHATTER Knowledgebase Setup Wizard screen displays. Application Security, Inc. 102

104 17.The Completed the AppSecInc SHATTER Knowledgebase Setup Wizard screen is shown below. FIGURE: Completed the AppSecInc SHATTER Knowledgebase Setup Wizard screen Click the Finish button to complete the Database Component installation. Next, the Console Management Server Setup wizard welcome screen displays. Application Security, Inc. 103

105 CONSOLE MANAGEMENT SERVER SETUP 18.The Console Management Server Setup wizard welcome screen is shown below. FIGURE: Note: Console Management Server Setup (welcome screen) Application Security, Inc. strongly recommends you close all other applications before continuing the installation. Application Security, Inc. 104

106 19.The DbProtect Server Port screen is shown below. FIGURE: Console Management Server Setup wizard (DbProtect Server Port screen) The Console Management Server is DbProtect s web application management interface. You access it via a web browser. This screen allows you to select the server port the web service runs on. DbProtect users connect to the Console via secure HTTPS connection to the specified server port. Do the following: Specify the Console server port. The default port (20080) is recommended for most configurations. If necessary, enter a different port number ( ). Consult your network administrator to determine which network port is acceptable. For more information on required open listen ports, see Networking, port, and firewall considerations. Check the Test Port button to test the availability of the specified server port. If the port is available, a checkmark icon displays, and the Next button is illuminated. Click the Next button to display the Service Log On Credentials screen. Application Security, Inc. 105

107 20.The Service Log On Credentials screen is shown below. FIGURE: Console Management Server Setup wizard (Service Log On Credentials) screen This step allows you to specify the user DbProtect will use to: Note: run the DbProtect Console and DbProtect Message Collector services browse the Windows Active Directory or NT 4 domains. For all operating systems, this user must have the Logon as a service privilege, and must belong to the local Administrators group. You can select: -Run service as LocalSystem to run the DbProtect Console service as the current logged-in user. -Select Run service as:, then manually enter (or click the Browse... button to select) the Windows account domain path and user name in the Account: field (e.g., Domain1\Account1), then enter the Windows account password in the Password: field. Check the Test Credentials button to test the Run service as: credentials provided. If the credentials are valid, a checkmark icon displays, and the Next button is illuminated. Click the Next button to display the Database Run Time Credentials screen. Application Security, Inc. 106

108 21.The Database Run Time Credentials screen is shown below. FIGURE: Console Management Server Setup wizard (Database Run Time Credentials screen) This service connects to the DbProtect database using either Windows Authentication (using the Local System Windows Service account) or SQL Authentication. You can select: -Windows Authentication. If you select this option, DbProtect uses the service credentials that you specified in Step 17 to connect to the DbProtect database at runtime. -SQL Authentication (make sure you have enabled SQL authentication). If you select this option, you must also enter a valid Login: and Password: combination. Regardless of your selection, the Console uses these credentials to read and write data. Only the db_datareader and db_datawriter roles are required for these credentials. Note: You can change these credentials at any time. For more information, see Appendix F: Using the Configuration Manager Tool in the DbProtect User s Guide. Click the Test Connection button to test the database run time credentials. If the connection is successful, a green checkmark icon displays, and the Next button is illuminated. Click the Next button to display the Ready to Install Console Management Server screen. Application Security, Inc. 107

109 22.The Ready to Install Console Management Server screen is shown below. FIGURE: Console Management Server Setup wizard (Ready to Install Console Management Server screen) Click the Install button to begin the Console installation. When the Console installation completes, a success message displays and the Finish button is illuminated. Application Security, Inc. 108

110 23.The Completed the Console Management Server Setup screen is shown below. FIGURE: Console Management Server Setup wizard (Completed the Console Management Server Setup screen) Click the Finish button to complete the Console installation. Next, the Message Collector Setup wizard welcome screen displays. Application Security, Inc. 109

111 CONSOLE MESSAGE COLLECTOR SETUP 24.The Console Message Collector Setup wizard welcome screen is shown below. FIGURE: Note: Console Message Collector Setup wizard (welcome screen) Application Security, Inc. recommends you close all other applications before continuing the installation. Click the Next button to display the Service Log On Credentials screen. Application Security, Inc. 110

112 25.The Service Log On Credentials screen is shown below. FIGURE: Console Message Collector Setup wizard (Service Log On Credentials screen) This service runs using either Windows Authentication (using the Local System Windows Service account) or SQL Authentication. If you selected: -Windows Authentication in Step 18, the Message Collector will use the service credentials to connect to the database at run-time. -SQL Authentication in Step 18, the Message Collector will use the SQL credentials you entered in Step 18 to connect to the database at run-time. Click the Test Connection button to test the database run time credentials. If the connection is successful, a green checkmark icon displays, and the Next button is illuminated. Click the Next button to display the Ready to Install Console Management Server screen. Application Security, Inc. 111

113 26.The Ready to Install Message Collector screen is shown below. FIGURE: Message Collector Setup wizard (Ready to Install Console Message Collector screen) Click the Install button to begin the Message Collector installation. When the Message Collector installation completes, the Completed the Console Message Collector Setup Wizard screen displays and the Finish button is illuminated. Application Security, Inc. 112

114 27.The Completed the Console Message Collector Setup Wizard screen is shown below. FIGURE: Console Message Collector Setup wizard (Completed the Console Message Collector Setup Wizard screen) Click the Finish button to complete the Console Message Collector installation. Next, the Analytics Setup wizard welcome screen displays. Application Security, Inc. 113

115 DBPROTECT ANALYTICS SETUP 28.The DbProtect Analytics Setup welcome screen is shown below. FIGURE: Note: DbProtect Analytics Setup (welcome screen) Application Security, Inc. recommends you close all other applications before continuing the installation. Click the Next button to display the DbProtect Analytics (End-User ( License Agreement) screen. Application Security, Inc. 114

116 29.The DbProtect Analytics (End-User License Agreement) screen is shown below FIGURE: Console Message Collector Setup wizard (Service Log On Credentials screen) Read the License Agreement. If you accept the terms of the License Agreement, check I accept the terms of the license agreement to illuminate the Next button. Click the Next button to display the DbProtect Analytics Setup (Destination Location) screen. Application Security, Inc. 115

117 30.The DbProtect Analytics Setup (Destination Location) screen is shown below. FIGURE: DbProtect Analytics Setup (Destination Location) screen The DbProtect suite installer automatically installs DbProtect Analytics in the following folder: <installation directory>\appsecinc\dbprotect\. This folder is not modifiable. Since DbProtect Analytics is an add-on package, it is automatically installed under DbProtect Console subfolders. The DbProtect suite installer validates: Note: available disk space for temporary storage (i.e., at least 2 GB of available disk space on same server where DbProtect is installed). that at least 2 GB of memory is available (4 GB recommended). If you do not have at least 2 GB, an error message displays on this page and the Next button is not illuminated. 2 GB of memory allows you to complete the installation process, but may yield poor performance except with very small data sets. Click the Next button to display the DbProtect Analytics Setup (DbProtect( Console data repository) screen. Application Security, Inc. 116

118 31.The DbProtect Analytics Setup (DbProtect ( Console data repository) screen is shown below. FIGURE: Note: DbProtect Analytics Setup (DbProtect Console data repository) screen The DbProtect suite requires a Microsoft SQL Server data respository. This screen allows you to specify the location of the Microsoft SQL Server instance, which can be local or remote. You can use the Database Instance drop-down to select an available instance for the DbProtect Console data repository. Or you can manually enter an instance name (in the editable Database Instance: dropdown field) using the syntax hostname\instance (e.g., myserver\myinstance) or hostname:port (e.g., myserver:1883). If you enter hostname:port, you do not need to have the SQL Server browser service turned on; for more information, see Additional DbProtect suite assumptions, prerequisites, and recommendations. Click the Next button to display the DbProtect Analytics (Database Creation User Credentials) screen. Application Security, Inc. 117

119 32.The DbProtect Analytics (Database Creation User Credentials) screen is shown below (with the default Windows Authentication database authentication type selected). DbProtect Analytics Setup (Database Creation User Credentials) screen -- default Windows Authentication database authentication type selected) The DbProtect Analytics installer creates a database called DbpAnalytics to store DbProtect Analytics data. You must provide valid credentials to create this database. The user must have sysadmin privileges on the database server. You can connect to the new DbpAnalytics database using either of the following authentication types: Windows Authentication. Uses the current logged-on user's privileges. SQL Authentication (make sure you have enabled SQL Authentication). Select one of the following authentication types for the database user: Windows Authentication (default), and go to Step 32 SQL Authentication, and go to Step 33. Application Security, Inc. 118

120 33.If you selected default Windows Authentication database authentication type in Step 32, the Database Installation Credentials screen looks like this: FIGURE: DbProtect Analytics Setup (Database Creation User Credentials) screen -- default Windows Authentication database authentication type selected The default Windows Authentication (a/k/a <domain\user>) database authentication type uses the Windows credentials from the account with which you are currently logged in (for fresh installations). You must click the Test Connection button to test the database user credentials. If the connection is successful, a green checkmark icon displays, and the Next button is illuminated. Click the Next button to display the DbProtect Analytics Setup wizard (Analytics Service Log On Credentials) screen and go to Step 35. Application Security, Inc. 119

121 Note: These credentials are used only for first-time installations in order to create the database. When you upgrade, the DbProtect suite installer will attempt to use Windows Authentication (if possible). If Windows Authentication fails, this screen displays during the upgrade. 34.If you selected default SQL Authentication database authentication type in Step 32, the Database Installation Credentials screen looks like this: FIGURE: DbProtect Analytics Setup (Database Creation User Credentials) screen -- SQL Authentication database authentication type selected Important: Make sure you have enabled SQL authentication on the database. Do the following: Enter a valid Login: and Password: combination. You must click the Test Connection button to test the database user credentials. If the connection is successful, a green checkmark icon displays, and the Next button is illuminated. Hint: You can check the Use these credentials to access database also at runtime checkbox (checked by default) if you want to use these same credentials to access the DbpAnalytics database at runtime, which allows you to skip Step 35. This checkbox only displays if you select the SQL Authentication database authentication type. If the test connection succeeds, click the Next button to display the Analytics Service Log On Credentials page. Application Security, Inc. 120

122 Click the Next button to display the DbProtect Analytics Setup wizard (Analytics Service Log On Credentials) screen. 35.The DbProtect Analytics Setup wizard (Analytics Service Log On Credentials) screen is shown below. FIGURE: DbProtect Analytics Setup wizard (Analytics Service Log On Credentials) screen Enter your DbProtect Analytics Windows service account credentials. You can select: -Run service as LocalSystem, if you want to use the "local system" account, which has full access rights and privileges on the host computer. -Run service as:. This selection allows you to specify a domain user login and password in the bottom half of the screen. If you select Run service as:, you must click the Test Credentials button to proceed. If the test connection succeeds, click the Next button to display the DbProtect Analytics Setup (Database Run Time User Credentials) page (unless you checked Use these credentials to access database also at runtime in Step in which case, go to Step 36). Application Security, Inc. 121

123 Important: When using Windows authentication for the SQL back-end connection, DbProtect Analytics uses this user profile. This profile must be a Windows user with administrator rights. Also, the account name specified must have the "log on as service" permission set in the Local Security Policy of the server (for more information, see your Windows help). If you select Run service as:, then you must enter the Account: user s name, and the Password: for the specified user. Hint: Click the Next button to display the DbProtect Analytics Setup (Database Run Time User Credentials) page. Application Security, Inc. recommends you use the same account as the DbProtect Console service. 36.The DbProtect Analytics Setup (Database ( Run Time User Credentials) screen is shown below. FIGURE: DbProtect Analytics Setup (Database Run Time User Credentials) screen Enter your DbProtect Analytics database runtime user credentials. At runtime, DbProtect Analytics uses this user to access the DbProtect Console database and the DbProtect Analytics database. You can connect to the DbProtect Console database and the DbProtect Analytics database using either of the following authentication types: Windows Authentication. Uses the privileges associated with the service user specified in Step 35. SQL Authentication (make sure you have enabled SQL Authentication). Application Security, Inc. 122

124 Select one of the following authentication types for the database user: Windows Authentication (default), and go to Step 37 SQL Authentication, and go to Step If you selected default Windows Authentication database authentication type in Step 36, the Database Installation Credentials screen looks like this: FIGURE: DbProtect Analytics Setup (Database Run Time User Credentials) screen The default Windows Authentication (a/k/a <domain\user>) database authentication type uses the Windows credentials from the account with which you are currently logged in (for fresh installations). Click the Next button to display the DbProtect Analytics Setup (Ready to Install DbProtect Analytics) screen and go to Step 39. Application Security, Inc. 123

125 38.If you selected default SQL Authentication database authentication type in Step 32, the DbProtect Analytics Setup (Database Run Time User Credentials) screen looks like this: FIGURE: DbProtect Analytics Setup (Database Run Time User Credentials) screen -- SQL Authentication database authentication type selected Important: Make sure you have enabled SQL authentication on the database. Do the following: Enter a valid Login: and Password: combination. You must click the Test Connection button to test the database user credentials. If the connection is successful, a green checkmark icon displays, and the Next button is illuminated. If the test connection succeeds, click the Next button to display the Analytics Service Log On Credentials page. Click the Next button to display the DbProtect Analytics Setup (Ready to Install DbProtect Analytics) screen. Application Security, Inc. 124

126 39.The DbProtect Analytics Setup (Ready to Install DbProtect Analytics) screen is shown below. FIGURE: DbProtect Analytics Setup (Ready to Install DbProtect Analytics) screen Click the Install button to begin the DbProtect Analytics installation. Note: Your DbProtect Analytics installation may fail during the import content phase, which will cause the entire DbProtect Analytics installation to fail. There is a workaround that allows the DbProtect Analytics installation to proceed without importing the content (which you can import later, manually). The specific workaround depends whether you are installing DbProtect Analytics via the DbProtect suite installer or the DbProtect Analytics MSI. If you are installing DbProtect Analytics via the DbProtect suite installer, run the following command: DbProtect_Setup.exe /ComponentArgs "Analytics":"IMPORT_CONTENT=0" If you are installing DbProtect Analytics via the DbProtect Analytics MSI, run the following command: msiexec /i <installername.msi> IMPORT_CONTENT=0 l*v install.log For more information on remote-deploying all individual DbProtect component MSIs to the specified target hosts, see Appendix S: Remote- Deploying DbProtect Components on Windows in Your Enterprise. Application Security, Inc. 125

127 When the DbProtect Analytics installation completes, the DbProtect Analytics Setup (Completed the DbProtect Analytics Setup) screen displays and the Finish button is illuminated. The Completed the DbProtect Analytics Setup Wizard screen is shown below. FIGURE: Completed the DbProtect Analytics Setup Wizard screen Click the Finish button to complete the DbProtect Analytics installation. Next, the Analytics Setup wizard welcome screen displays. 40.Click the Finish button to install additional content and documentation, and complete the DbProtect suite installation. A Congratulations pop up displays after you successfully complete the installation. FIGURE: Congratulations pop up Click the OK button to close the pop up. Application Security, Inc. 126

128 41.DbProtect Console, DbProtect Message Collector, and Cognos 8 (i.e., the DbProtect Analytics service) begin running as Windows services on your computer. These services automatically start when you start your computer. 42.Obtain and install your Application Security, Inc.-issued DbProtect licenses. You will need: ADnnnnnnnnn.lic and ARnnnnnnnnn.lic license files on your DbProtect host, so you can manage database threats and perform audits via the Console an individual ADnnnnnnnnn.lic license file on each host running a Scan Engine (to activate Vulnerability Assessment). For specific details, see Chapter 4 - Licensing. Application Security, Inc. 127

129 Installing Scan Engines This section provides detailed installation steps for the Scan Engine component of DbProtect. Note: First make sure you have carefully read the minimum system requirements for the Scan Engine. For more information, see Scan Engines - Minimum System Requirements. Scan Engine - installation steps To install a Scan Engine: 1. Locate the Scan Engine setup file on the Application Security, Inc.- provided CD, or download it from the Application Security, Inc. FTP site. If downloading, save the file to a convenient location (e.g., c:\temp). 2. Double click Scan Engine executable (.exe) file to begin installing the Scan Engine. The installer checks your host machine for the following prerequisite components: Microsoft XML Core Services 4.0 SP2 Microsoft.NET Framework 3.5 SP1 Note: x86 will read x64 if you are installing the Scan Engine on a 64-bit host machine. Microsoft Visual Studio 2005 C++ Redistributable (x86) WinPcap for non-admin users who want to run the Scan Engine on any supported Windows version; for more information, see Supported Windows versions (on your Scan Engine host server). If an admin user is going to run the Scan Engine, there is no need to install WinPcap. Application Security, Inc. 128

130 The installer displays which (if any) missing prerequisite components it will automatically install for you; for more information, see Scan Engine prerequisites. FIGURE: If the installer: Scan Engine installation wizard Detects missing prerequisite components, a dialog box displays which components are missing, and prompts you to install them. If the Scan Engine installer detects you are missing components, go to Step 3. Does not detect any missing prerequisite components, the Welcome to the DbProtect Scan Engine Setup Wizard dialog box displays. Go to Step Install missing prerequisite components. Click the Install button to begin the installation of the prerequisites (if any are listed), and the components in the order in which they are displayed. The installer installs any missing prerequisite components detected in Step 2. If you are missing Microsoft.NET Framework 3.5 SP1, the installation of this component will probably take some time. Also, you may have to reboot your host machine in order to continue. When the installer finishes installing any missing prerequisite components detected in Step 2, the Welcome to the DbProtect Scan Engine Setup Wizard dialog box displays. Go to Step 4. Application Security, Inc. 129

131 4. After the installer has installed all missing prerequisite components -- or detected the presence of all prerequisite components -- the Welcome to the DbProtect Scan Engine Setup Wizard dialog box displays. FIGURE: Welcome to the DbProtect Scan Engine Setup Wizard dialog box Click the Next button to display the End-User License Agreement dialog box. 5. The End-User License Agreement dialog box is shown below. FIGURE: End-User License Agreement dialog box Application Security, Inc. 130

132 Read the License Agreement. If you accept the terms of the License Agreement, select I accept the terms in the license agreement. Click the Next button to display the Destination Folder dialog box. 6. The Destination Folder dialog box is shown below. FIGURE: Destination Folder dialog box By default, the installer installs Scan Engine in under <installation directory>\program Files\AppSecInc\Scan Engine. You can click the Change... button to specify a different installation path for the Scan Engine. You can click the: Change... button to select a different folder where the installer will install Scan Engine files Next button to display the DbProtect Console Information dialog box. Application Security, Inc. 131

133 7. The DbProtect Console Information dialog box is shown below. FIGURE: DbProtect Console Information dialog box Do the following: Hint: Enter the HOSTNAME of the machine where you installed the Console; for more information, see DbProtect suite components - installation steps. You can click the Browse... button to each for a valid hostname on your network. Enter which HTTP PORT the Console uses ( ). The default port (20080) is recommended for most configurations, but it could be a different port number ( ). For more information on required open listen ports, see Networking, port, and firewall considerations. -If you do not know the Console port number, do the following: a.) Open the server.xml file (stored under \<DbProtect Installation Folder>\AppSecInc\gui\tomcat\conf b.) Locate the following line: <Connector classname= org.apache.coyote.tomcat4.coyoteconnector port = <port number used> c.) Use this port number. You must click the Test Connection button to test the hostname and port information. If the connection is successful, a green checkmark icon displays, and the Next button is illuminated. Application Security, Inc. 132

134 Note: The TEST_CONNECTIONS=<value> parameter in the Scan Engine MSI allows you to enter 0 as the <value> to disable the checking of test connections. The Scan Engine installer will you to continue installing the Scan Engine by ignoring the result of clicking the Test Connection buttons on the GUI Scan Engine installer; for more information, see Scan Engine MSI: installation prerequisites and command line arguments. Click the Next button to display the Scan Engine Service Information dialog box. 8. The Scan Engine Service Information dialog box is shown below. FIGURE: DbProtect Console Information dialog box Do the following: Enter the HOSTNAME of the machine the Scan Engine will use to respond to requests. Hint: You can click the Browse... button to search for a valid hostname on your network. Enter which HTTP PORT of the machine the Scan Engine will use to respond to requests ( ). The default port (20001) is recommended for most configurations, but you can specify a different port number ( ). For more information on required open listen ports, see Networking, port, and firewall considerations. You must click the Test Connection button to test the hostname and port information. If the connection is successful, a green checkmark icon displays, and the Next button is illuminated. Application Security, Inc. 133

135 Note: The TEST_CONNECTIONS=<value> parameter in the Scan Engine MSI allows you to enter 0 as the <value> to disable the checking of test connections. The Scan Engine installer will you to continue installing the Scan Engine by ignoring the result of clicking the Test Connection buttons on the GUI Scan Engine installer; for more information, see Scan Engine MSI: installation prerequisites and command line arguments. Click the Next button to display the Service Logon Information dialog box. 9. The Service Logon Information dialog box is shown below. FIGURE: Service Logon Information dialog box (Run Scan Engine service as LocalSystem selected) This step allows you to specify the DbProtect Scan Engine service logon information. Note: For all operating systems, this user must have the Logon as a service privilege, and must belong to the local Administrators group. You can select the default Run Scan Engine service as LocalSystem to run the DbProtect Scan Engine service as the current logged-in user. Click the Next button to display the DbProtect Database Information dialog box, and go to Step 10. Application Security, Inc. 134

136 Alternately, you can select Specify Scan Engine service credentials, in which case the Service Logon Information dialog box looks like this: FIGURE: Service Logon Information dialog box (Specify Scan Engine service credentials selected) Do the following: Manually enter (or click the Browse... button to select) the Windows account domain path and user name in the Account: field (e.g., Domain1\Account1), then enter the Windows account password in the Password: field. Check the Test Credentials button to test the Run service as: credentials provided. If the credentials are valid, a checkmark icon displays, and the Next button is illuminated. Click the Next button to display the DbProtect Database Information dialog box, and go to Step 10. Application Security, Inc. 135

137 10.The DbProtect Database Information dialog box is shown below. FIGURE: DbProtect Database Information dialog box (default Windows Authentication database authentication type selected) This step allows you to enter your back-end database information, as well as the authentication type to use to connect to the back-end database. Use the Server drop-down to specify the location of your back-end database. Or you can manually enter an instance name (in the editable Server drop-down field) using the syntax servername,port (e.g., myserver,1234) or servername\instancename,port (e.g., myserver\myinstance,1234). Next, select one of the following authentication types for the back-end database user: Note: Windows Authentication SQL Authentication If you're not sure which authentication type to select, see your database administrator. If you select SQL Authentication: Enter a valid Login: and Password: combination. You must click the Test Connection button to test the back-end database user credentials. If the connection is successful, a green checkmark icon displays, and the Next button is illuminated. Application Security, Inc. 136

138 Note: The TEST_CONNECTIONS=<value> parameter in the Scan Engine MSI allows you to enter 0 as the <value> to disable the checking of test connections. The Scan Engine installer will you to continue installing the Scan Engine by ignoring the result of clicking the Test Connection buttons on the GUI Scan Engine installer; for more information, see Scan Engine MSI: installation prerequisites and command line arguments. Important: Make sure you have enabled SQL authentication on the back-end database. Click the Next button to display the Ready to install DbProtect Scan Engine dialog box. 11.The Ready to install DbProtect Scan Engine dialog box is shown below. FIGURE: Ready to install DbProtect Scan Engine dialog box Application Security, Inc. 137

139 Do the following: Click the Install button to install the Scan Engine. FIGURE: Installing DbProtect Scan Engine dialog box When the installation is complete, the Completed the DbProtect Scan Engine Setup Wizard dialog box displays. Application Security, Inc. 138

140 12.The Completed the Database Component Setup Wizard dialog box is shown below. FIGURE: Completed the Database Component Setup Wizard dialog box Click the Finish button to complete the Scan Engine installation. 13.DbProtect Scan Engine begins running as a Windows service on your computer. This service automatically starts when you start your computer. 14.Obtain and install your Application Security, Inc.-issued Scan Engine licenses. You will need: ADnnnnnnnnn.lic and ARnnnnnnnnn.lic license files on your DbProtect host, so you can monitor database activity and assess database vulnerabilities via the Console an individual ADnnnnnnnnn.lic license file on each host running a Scan Engine (to activate to activate Vulnerability Assessment). For specific details, see Chapter 4 - Licensing. 15.Restart the DbProtect Scan Engine service after you copy the license files. Wait 20 seconds for the license to initialize. All DbProtect services start automatically every time you start your computer. If you need to start or stop any DbProtect services for any reason, see the DbProtect Administrator s Guide. Application Security, Inc. 139

141 Installing, Starting/Stopping, and Reconfiguring the Sensors This section provides detailed installation steps for the Sensor components of DbProtect. There are two types of Sensors available: host-based and network-based. This section also explains how to start and stop the Sensors (on a Windows or *nix platform), and how to reconfigure your Sensors (on a Windows or *nix platform). Note: First make sure you have carefully read the minimum system requirements for the Sensors. For more information, see Sensors - Minimum System Requirements. What you will find in this section: Host-based Sensors (supported databases and platforms) Network-based Sensors (supported databases and platforms) Host-based Sensor for SQL Server (on Windows) - installation steps Host-based Sensor for DB2 (on Red Hat Enterprise Linux) - installation steps Host-based Sensor for DB2 (on Solaris) - installation steps Host-based Sensor for DB2 (on AIX) - installation steps Host-based Sensor for DB2 (on Windows) - installation steps Host-based Sensor for Sybase (on Solaris) - installation steps Host-based Sensor for Sybase (on AIX) - installation steps Host-based Sensor for Oracle (on Solaris) - installation steps Host-based Sensor for Oracle (on AIX) - installation steps Host-based Sensor for Oracle (on HP-UX) - installation steps Host-based Sensor for Oracle (on Red Hat Enterprise Linux) - installation steps Host-based Sensor for Oracle (on Windows) - installation steps Network-based Sensor for Sybase, Oracle, and DB2 - installation steps Starting and stopping the Sensors Reconfiguring a Sensor (installed on Windows) via the DbProtect Sensor Configuration tool or the command line. Application Security, Inc. 140

142 Host-based Sensors (supported databases and platforms) Host-based Sensors allow you to monitor the following databases on a host server: Microsoft SQL Server on Windows DB2 on Solaris, AIX, Red Hat Enterprise Linux, and Windows Oracle on Solaris, AIX, HP-UX, Red Hat Enterprise Linux, and Windows. If you want to install a host-based Sensor, the table below lists supported database/os combinations, and links you to the installation steps. DB OS Go to: MICROSOFT SQL SERVER WINDOWS Host-based Sensor for SQL Server (on Windows) - installation steps DB2 RED HAT ENTERPRISE LINUX SOLARIS AIX WINDOWS Host-based Sensor for DB2 (on Red Hat Enterprise Linux) - installation steps Host-based Sensor for DB2 (on Solaris) - installation steps Host-based Sensor for DB2 (on AIX) - installation steps Host-based Sensor for DB2 (on Windows) - installation steps SYBASE SOLARIS Host-based Sensor for Sybase (on Solaris) - installation steps AIX Host-based Sensor for Sybase (on AIX) - installation steps ORACLE SOLARIS Host-based Sensor for Oracle (on Solaris) - installation steps AIX HP-UX RED HAT ENTERPRISE LINUX WINDOWS Host-based Sensor for Oracle (on AIX) - installation steps Host-based Sensor for Oracle (on HP-UX) - installation steps Host-based Sensor for Oracle (on Red Hat Enterprise Linux) - installation steps Host-based Sensor for Oracle (on Windows) - installation steps Application Security, Inc. 141

143 Network-based Sensors (supported databases and platforms) Network-based Sensors allow you to monitor Sybase, Oracle, and DB2 on the network. If you want to install a network-based Sensor, the table below lists supported database/os combinations, and links you to the installation steps. Note: Network-based Sensors only run on the Windows OS, but the databases they monitor do not need to be running on Windows. DB OS Go to: DB2 WINDOWS Network-based Sensor for Sybase, Oracle, and DB2 - SYBASE installation steps ORACLE Host-based Sensor for SQL Server (on Windows) - installation steps Important: To install a host-based Sensor for Microsoft SQL Server, you must be a Windows user with administrative rights on both the host server and Microsoft SQL Server. You must also have domain administrator rights to install a host-based Sensor for SQL Server in a cluster. To run the hostbased Sensor for Microsoft SQL Server, you must have run as a service" rights on Windows, and administrative rights on Microsoft SQL Server at runtime. To install the host-based Sensor for Microsoft SQL Server on Windows: 1. Locate the setup file on the Application Security, Inc.-provided CD, or download it from the Application Security, Inc. FTP site or website. 2. Save the file to a convenient location (e.g., c:\temp). Application Security, Inc. 142

144 3. Double click the executable file to display the installation wizard (Welcome page) and begin the Sensor installation. The installer displays which version of the Sensor it will install. FIGURE: Welcome page Click the Install button to display the License Agreement page. 4. The License Agreement page is shown below. FIGURE: License Agreement page Application Security, Inc. 143

145 Read the License Agreement. If you accept the terms of the License Agreement, select I accept the terms in the license agreement. Click the Next button to display the Choose Destination Location page. 5. The Destination Folder page is shown below. FIGURE: Destination Folder page Choose the location of the Sensor installation directory. You can click the: -Change... button to choose a directory manually -Next button to choose the default location. (The default location is: <installation folder>:\appsecinc\sensor\). Click the Next button to display the Sensor Type page. Application Security, Inc. 144

146 6. The Sensor Type page is shown below. FIGURE: Sensor Type page Select Host-based Sensor and click the Next button to display the Server Port page. Note: You can reconfigure an installed Windows-based Sensor at anytime via the Windows Start menu or the command line; for more information, see Reconfiguring a Sensor (installed on Windows) via the DbProtect Sensor Configuration tool or the command line. Application Security, Inc. 145

147 7. The Server Port page is shown below. FIGURE: Server Port page Specify which port number the Sensor should use to receive commands from the Console. The default port (20000) is recommended for most configurations, but you can specify a different port number ( ). For more information on required open listen ports, see Networking, port, and firewall considerations. You must click the Test Port button to test the port information. If the connection is successful, a green checkmark icon displays, and the Next button is illuminated. Click the Next button to display the Service Log On Credentials page. Application Security, Inc. 146

148 8. The Sensor Service Logon Details page is shown below. FIGURE: Sensor Service Logon Details page Specify a database user login and password. Important: If you want to specify a non-local user username and password for the Sensor to run under, you must do so in this step. You can select: -Run service as Local System, if you want to use the "local system" account, which has full access rights and privileges on the host computer. -Run service as: to specify a domain user login and password. Important: The Sensor logs in to the monitored database, and the Sensor service runs, under this user profile. This profile must be a Windows user with administrator rights. Also, the account name specified must have the "log on as service" permission set in the Local Security Policy of the server (for more information, see your Windows help). If you select Run service as:, then you must enter a valid domain name\user name and password. Also, the domain user must be a Windows user with administrative rights on both the host server and SQL Server, and must have domain administrator rights to install a host-based Sensor for SQL Server in a cluster. Click the Next button to display the Install DbProtect Sensor page. Application Security, Inc. 147

149 9. The Install DbProtect Sensor page is shown below. FIGURE: Install DbProtect Sensor page If want to review or change any settings you can click the Back button. Click the Install button. When the installation finishes, a Sensor installation success page displays. Application Security, Inc. 148

150 10.The Sensor installation success page is shown below. FIGURE: Sensor installation success page Review the installation details at the bottom of the page. Click the Finish button to close the installer. 11.A congratulations pop up displays. FIGURE: Note: Sensor installation success page Click the OK button to close the congratulations pop up. DbProtect allows you to use the DbProtect Sensor Configuration tool to reconfigure the Sensor installation parameters (for example, server port number). For more information, see Reconfiguring a Sensor (installed on Windows) via the DbProtect Sensor Configuration tool. Application Security, Inc. 149

151 Host-based Sensor for DB2 (on Red Hat Enterprise Linux) - installation steps Note: You can configure your host-based Sensor for DB2 (on Red Hat Enterprise Linux) to start automatically upon system reboot; for more information, see Appendix R: Configuring Your Host-Based Sensor (Installed on a *nix Platform) to Start Automatically Upon System Reboot. Important: For information on performing an ASAP update of a host-based Sensor for DB2 on a *nix host, see the DbProtect Administrator s Guide. To install a host-based Sensor for DB2 on Red Hat Enterprise Linux 3, 4, or 5 (32-bit x86 and 64-bit x64): 1. Application Security, Inc. strongly recommends you create a unique DbProtect user called appradar, and use this account for host-based Sensor for DB2 installation. While creating this user is not mandatory, it will ensure that other database administrators can't turn off your host-based DB2 Sensors. The appradar user must belong to the primary group of the DB2 instance owner. In many cases db2inst1 is the default DB2 user name, while the default group name is typically db2iadm1. The user (i.e., appradar) must be a member of the same db2iadm1 group as DB2 user on the host. To determine your DB2 group name, enter the following command: id db2inst1. Your DB2 user name (uid) and group name (gid) should display, e.g., uid=1001(db2inst1) gid=503(db2iadm1). Caution! A host-based Sensor for DB2 can only monitor one DB2 instance. If you want to monitor multiple instances on an DB2 server, see Appendix C: Modifying the Sensor Listener Port Number and Appendix P: Monitoring Multiple Instances on a DB2 Server. 2. The DB2 administrator must grant the following privileges to the appradar user for every DB2 database in the instance you want to monitor: SYSADM if you want to monitor unsuccessful authentication attempts DBADM if you do not want to monitor unsuccessful authentication attempts. 3. The person installing the host-based DB2 Sensor logs in as the user who will run the host-based DB2 Sensor, i.e., appradar, or the user created by the Unix administrator (root) in Step 1. Caution! The account running the DB2 database must be in the same user group as the account running the host-based Sensor for DB2 installation script. Application Security, Inc. 150

152 4. Download or copy the host-based Sensor file to your target database host. The file names are: AppRadar Sensor_<version number>_linux32.tgz.sh for Red Hat Enterprise Linux (32-bit x86) AppRadar Sensor_<version number>_linux64.tgz.sh for Red Hat Enterprise Linux (64-bit x64). 5. Install the host-based Sensor file as follows: sh "./AppRadar Sensor_<version number>_linux32.tgz.sh" install <installation_dir> for Red Hat Enterprise Linux (32-bit x86), where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. sh "./AppRadar Sensor_<version number>_linux64.tgz.sh" install <installation_dir> Note: for Red Hat Enterprise Linux (64-bit x64), where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. If the filename contains spaces, then don't forget to quote these spaces in the command. The host-based Sensor is installed in the "<installation_dir>/asiappradar/" directory. 6. Start your Sensor; for more information, see Starting and stopping the Sensors. Important: The Sensor uses default port to receive commands from the Console. This port is recommended for most configurations, but you can specify a different port number ( ). To change the default port number for host-based Sensors installed on a *nix platform, you must manually modify the sensor.xml and sensor_original.xml files; for more information, see Appendix C: Modifying the Sensor Listener Port Number. For more information on required open listen ports, see Networking, port, and firewall considerations. Application Security, Inc. 151

153 Host-based Sensor for DB2 (on Solaris) - installation steps Note: You can configure your host-based Sensor for DB2 (on Solaris) to start automatically upon system reboot; for more information, see Appendix R: Configuring Your Host-Based Sensor (Installed on a *nix Platform) to Start Automatically Upon System Reboot. Important: For information on performing an ASAP update of a host-based Sensor for DB2 on a *nix host, see the DbProtect Administrator s Guide. To install a host-based Sensor for DB2 on Solaris 8, 9, and 10 (64-bit SPARC): 1. Application Security, Inc. strongly recommends you create a unique DbProtect user called appradar, and use this account for host-based Sensor for DB2 installation. While creating this user is not mandatory, it will ensure that other database administrators can't turn off your host-based DB2 Sensors. The appradar user must belong to the primary group of the DB2 instance owner. In many cases db2inst1 is the default DB2 user name, while the default group name is typically db2iadm1. The user (i.e., appradar) must be a member of the same db2iadm1 group as DB2 user on the host. To determine your DB2 group name, enter the following command: id db2inst1. Your DB2 user name (uid) and group name (gid) should display, e.g., uid=1001(db2inst1) gid=503(db2iadm1). Caution! A host-based Sensor for DB2 can only monitor one DB2 instance. If you want to monitor multiple instances on an DB2 server, see Appendix C: Modifying the Sensor Listener Port Number and Appendix P: Monitoring Multiple Instances on a DB2 Server. 2. The DB2 administrator must grant the following privileges to the appradar user for every DB2 database in the instance you want to monitor: SYSADM if you want to monitor unsuccessful authentication attempts DBADM if you do not want to monitor unsuccessful authentication attempts. 3. The person installing the host-based DB2 Sensor logs in as the user who will run the host-based DB2 Sensor, i.e., appradar, or the user created by the Unix administrator (root) in Step 1. Caution! The account running the DB2 database must be in the same user group as the account running the host-based Sensor for DB2 installation script. 4. Download or copy the host-based Sensor installation file to your target database host. The file is: AppRadar Sensor_<version number> Solaris64.tgz.sh Application Security, Inc. 152

154 5. Install the host-based Sensor file as follows: sh "./AppRadar Sensor_<version number> Solaris64.tgz.sh" install <installation_dir> where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. If the filename contains spaces, then don't forget to quote these spaces in the command. The host-based Sensor is installed in the "<installation_dir>/asiappradar/" directory. 6. Start your Sensor; for more information, see Starting and stopping the Sensors. Important: The Sensor uses default port to receive commands from the Console. This port is recommended for most configurations, but you can specify a different port number ( ). To change the default port number for host-based Sensors installed on a *nix platform, you must manually modify the sensor.xml and sensor_original.xml files; for more information, see Appendix C: Modifying the Sensor Listener Port Number. For more information on required open listen ports, see Networking, port, and firewall considerations. Host-based Sensor for DB2 (on AIX) - installation steps Note: You can configure your host-based Sensor for DB2 (on AIX) to start automatically upon system reboot; for more information, see Appendix R: Configuring Your Host-Based Sensor (Installed on a *nix Platform) to Start Automatically Upon System Reboot. Important: For information on performing an ASAP update of a host-based Sensor for DB2 on a *nix host, see the DbProtect Administrator s Guide. Application Security, Inc. 153

155 To install a host-based Sensor for DB2 on a *nix host running AIX 5.2 Technology Level 5 and up: 1. Application Security, Inc. strongly recommends you create a unique DbProtect user called appradar, and use this account for host-based Sensor for DB2 installation. While creating this user is not mandatory, it will ensure that other database administrators can't turn off your host-based DB2 Sensors. The appradar user must belong to the primary group of the DB2 instance owner. In many cases db2inst1 is the default DB2 user name, while the default group name is typically db2iadm1. The user (i.e., appradar) must be a member of the same db2iadm1 group as DB2 user on the host. To determine your DB2 group name, enter the following command: id db2inst1. Your DB2 user name (uid) and group name (gid) should display, e.g., uid=1001(db2inst1) gid=503(db2iadm1). Caution! A host-based Sensor for DB2 can only monitor one DB2 instance. If you want to monitor multiple instances on an DB2 server, see Appendix C: Modifying the Sensor Listener Port Number and Appendix P: Monitoring Multiple Instances on a DB2 Server. 2. The DB2 administrator must grant the following privileges to the appradar user for every DB2 database in the instance you want to monitor: SYSADM if you want to monitor unsuccessful authentication attempts DBADM if you do not want to monitor unsuccessful authentication attempts. 3. The person installing the host-based DB2 Sensor logs in as the user who will run the host-based DB2 Sensor, i.e., appradar, or the user created by the Unix administrator (root) in Step 1. Caution! The account running the DB2 database must be in the same user group as the account running the host-based Sensor for DB2 installation script. 4. Download or copy the host-based Sensor file to your target database host. The file names are: AppRadar Sensor_<version number>_aix-ppc-32.tgz.sh for AIX (32-bit) AppRadar Sensor_<version number>_aix-ppc-64.tgz.sh for AIX (64-bit). Application Security, Inc. 154

156 5. Install the host-based Sensor file as follows: sh "./AppRadar Sensor_<version number>_aix-ppc-32.tgz.sh" install <installation_dir> for AIX (32-bit), where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. sh "./AppRadar Sensor_<version number>_aix-ppc-64.tgz.sh" install <installation_dir> Note: for AIX (64-bit), where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. If the filename contains spaces, then don't forget to quote these spaces in the command. The host-based Sensor is installed in the "<installation_dir>/asiappradar/" directory. 6. Start your Sensor; for more information, see Starting and stopping the Sensors. Important: The Sensor uses default port to receive commands from the Console. This port is recommended for most configurations, but you can specify a different port number ( ). To change the default port number for host-based Sensors installed on a *nix platform, you must manually modify the sensor.xml and sensor_original.xml files; for more information, see Appendix C: Modifying the Sensor Listener Port Number. For more information on required open listen ports, see Networking, port, and firewall considerations. Host-based Sensor for DB2 (on Windows) - installation steps Important: To install a host-based Sensor for DB2, you must be a Windows user with administrative rights on the host server. To install a host-based Sensor for DB2 on Windows: 1. Locate the setup file on the Application Security, Inc.-provided CD, or download it from the Application Security, Inc. FTP site or website. 2. Save the file to a convenient location (e.g., c:\temp). Application Security, Inc. 155

157 3. Double click the executable file to display the installation wizard (Welcome page) and begin the Sensor installation. The installer displays which version of the Sensor it will install. FIGURE: Welcome page Click the Install button to display the License Agreement page. 4. The License Agreement page is shown below. FIGURE: License Agreement page Application Security, Inc. 156

158 Read the License Agreement. If you accept the terms of the License Agreement, select I accept the terms in the license agreement. Click the Next button to display the Choose Destination Location page. 5. The Destination Folder page is shown below. FIGURE: Destination Folder page Choose the location of the Sensor installation directory. You can click the: -Change... button to choose a directory manually -Next button to choose the default location. (The default location is: c:\appsecinc\sensor\). Click the Next button to display the Sensor Type page. Application Security, Inc. 157

159 6. The Sensor Type page is shown below. FIGURE: Sensor Type page Select Host-based Sensor and click the Next button to display the Server Port page. Note: You can reconfigure an installed Sensor at anytime via the Windows Start menu or the command line; for more information, see Reconfiguring a Sensor (installed on Windows) via the DbProtect Sensor Configuration tool or the command line. Application Security, Inc. 158

160 7. The Server Port page is shown below. FIGURE: Server Port page Specify which port number the Sensor should use to receive commands from the Console. The default port (20000) is recommended for most configurations, but you can specify a different port number ( ). For more information on required open listen ports, see Networking, port, and firewall considerations. You must click the Test Port button to test the port information. If the connection is successful, a green checkmark icon displays, and the Next button is illuminated. Click the Next button to display the Service Log On Credentials page. Application Security, Inc. 159

161 8. The Sensor Service Logon Details page is shown below. FIGURE: Sensor Service Logon Details page Specify a database user login and password. Important: If you want to specify a non-local user username and password for the Sensor to run under, you must do so in this step. You can select: -Run service as Local System, if you want to use the "local system" account, which has full access rights and privileges on the host computer. -Run service as: to specify a domain user login and password. Important: The Sensor logs in to the monitored database, and the Sensor service runs, under this user profile. This profile must be a Windows user with administrator rights. Also, the account name specified must have the "log on as service" permission set in the Local Security Policy of the server (for more information, see your Windows help). If you select Run service as:, then you must enter a valid domain name\user name and password. Click the Next button to display the Install DbProtect Sensor page. Application Security, Inc. 160

162 9. The Install DbProtect Sensor page is shown below. FIGURE: Install DbProtect Sensor page If want to review or change any settings you can click the Back button. Click the Install button. When the installation finishes, a Sensor installation success page displays. Application Security, Inc. 161

163 10.The Sensor installation success page is shown below. FIGURE: Sensor installation success page Review the installation details at the bottom of the page. Click the Finish button to close the installer. 11.A congratulations pop up displays. FIGURE: Sensor installation success page 12.Click the OK button to close the congratulations pop up. Note: DbProtect allows you to switch a host-based Sensor to a network-based Sensor, or vice-versa, without having to uninstall the Sensor, then re-install/ reconfigure it. There are two ways to accomplish this. The first is via the DbProtect Sensor Configuration tool; for more information, see Reconfiguring a Sensor (installed on Windows) via the DbProtect Sensor Configuration tool. The second is via the command line; for more information, see Reconfiguring a Sensor (installed on Windows) via a command line. Application Security, Inc. 162

164 Host-based Sensor for Sybase (on Solaris) - installation steps To install a host-based Sensor for Sybase on a *nix host running Solaris 8, 9, 10 (32- and 64-bit SPARC): 1. Login as a user that will run the Sensor, i.e., appradar. Caution! Do not log in as root Note: The user (i.e., appradar) must be a member of the same dba group as oracle on the host. 2. Download or copy the installer to a writable directory on your target database host. The file names are: AppRadar Sensor_<version number>_solaris32.tgz.sh for Solaris (32-bit SPARC) AppRadar Sensor_<version number>_solaris64.tgz.sh for Solaris (64-bit SPARC). 3. Install the host-based Sensor file as follows: sh "./AppRadar Sensor_<version number>_solaris32.tgz.sh" install <installation_dir> for Solaris (32-bit SPARC), where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. sh "./AppRadar Sensor_<version number>_solaris64.tgz.sh" install <installation_dir> Note: for Solaris (64-bit SPARC), where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. If the filename contains spaces, then don't forget to quote these spaces in the command. The host-based Sensor is installed in the "<installation_dir>/asiappradar/" directory. 4. Start your Sensor; for more information, see Starting and stopping the Sensors. Application Security, Inc. 163

165 Important: The Sensor uses default port to receive commands from the Console. This port is recommended for most configurations, but you can specify a different port number ( ). To change the default port number for host-based Sensors installed on a *nix platform, you must manually modify the sensor.xml and sensor_original.xml files; for more information, see Appendix C: Modifying the Sensor Listener Port Number. For more information on required open listen ports, see Networking, port, and firewall considerations. Host-based Sensor for Sybase (on AIX) - installation steps To install a host-based Sensor for Sybase on a *nix host running AIX 5.2 Technology Level 5 and greater: 1. Login as a user that will run the Sensor, i.e., appradar. Caution! Do not log in as root Note: The user (i.e., appradar) must be a member of the same dba group as oracle on the host. 2. Download or copy the installer to a writable directory on your target database host. The file names are: AppRadar Sensor_<version number>_aix-ppc-32.tgz.sh for AIX (32-bit 32-bit) AppRadar Sensor_<version number>_aix-ppc-64.tgz.sh for AIX (64-bit 64-bit). 3. Install the host-based Sensor file as follows: sh "./AppRadar Sensor_<version number>_aix-ppc-32.tgz.sh" install <installation_dir> for AIX (32-bit), where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. sh "./AppRadar Sensor_<version number>_aix-ppc-64.tgz.sh" install <installation_dir> for AIX (64-bit), where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. Note: If the filename contains spaces, then don't forget to quote these spaces in the command. The host-based Sensor is installed in the "<installation_dir>/asiappradar/" directory. 4. Start your Sensor; for more information, see Starting and stopping the Sensors. Application Security, Inc. 164

166 Important: The Sensor uses default port to receive commands from the Console. This port is recommended for most configurations, but you can specify a different port number ( ). To change the default port number for host-based Sensors installed on a *nix platform, you must manually modify the sensor.xml and sensor_original.xml files; for more information, see Appendix C: Modifying the Sensor Listener Port Number. For more information on required open listen ports, see Networking, port, and firewall considerations. Host-based Sensor for Oracle (on Solaris) - installation steps Note: Note: You can configure your host-based Sensor for Oracle (on Solaris) to start automatically upon system reboot; for more information, see Appendix R: Configuring Your Host-Based Sensor (Installed on a *nix Platform) to Start Automatically Upon System Reboot. Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle relational database management system (RDBMS) software simultaneously while accessing a single database, thus providing a clustered database. For more information on configuring a host-based Sensor to monitor databases on an Oracle RAC, see Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC. Important: For information on performing an ASAP update of a host-based Sensor for Oracle on a *nix host, see the DbProtect Administrator s Guide. To install a host-based Sensor for Oracle on a *nix host running Solaris 8, 9, 10 (32- and 64-bit SPARC): 1. Login as a user that will run the Sensor, i.e., appradar. Caution! Do not log in as root Note: The user (i.e., appradar) must be a member of the same dba group as oracle on the host. 2. Download or copy the host-based Sensor file to your target database host. The file names are: AppRadar Sensor_<version number>_solaris32.tgz.sh for Solaris (32-bit SPARC) AppRadar Sensor_<version number>_solaris64.tgz.sh for Solaris (64-bit SPARC). Application Security, Inc. 165

167 3. Install the host-based Sensor file as follows: sh "./AppRadar Sensor_<version number>_solaris32.tgz.sh" install <installation_dir> for Solaris (32-bit SPARC), where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. sh "./AppRadar Sensor_<version number>_solaris64.tgz.sh" install <installation_dir> Note: for Solaris (64-bit SPARC), where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. If the filename contains spaces, then don't forget to quote these spaces in the command. The host-based Sensor is installed in the "<installation_dir>/asiappradar/" directory. 4. Finally, you must configure your host-based Sensor for Oracle DDL triggers, and configure your host-based Sensor for Oracle audit trail to monitor failed logins. For more information, see Appendix E: Working with Oracle DDL Triggers (for Host-Based Sensors for Oracle Installed on *nix Platforms Only) and Appendix J: Configuring Your Oracle Audit Trail in Order to Monitor Logins, respectively. Note: If you remove and re-add a DDL trigger for any reason, you must re-start the Sensor afterwards. Most DDL rules will not fire until this is done. 5. Start your Sensor; for more information, see Starting and stopping the Sensors. Important: The Sensor uses default port to receive commands from the Console. This port is recommended for most configurations, but you can specify a different port number ( ). To change the default port number for host-based Sensors installed on a *nix platform, you must manually modify the sensor.xml and sensor_original.xml files; for more information, see Appendix C: Modifying the Sensor Listener Port Number. For more information on required open listen ports, see Networking, port, and firewall considerations. Application Security, Inc. 166

168 Host-based Sensor for Oracle (on AIX) - installation steps Note: Note: You can configure your host-based Sensor for Oracle (on AIX) to start automatically upon system reboot; for more information, see Appendix R: Configuring Your Host-Based Sensor (Installed on a *nix Platform) to Start Automatically Upon System Reboot. Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle relational database management system (RDBMS) software simultaneously while accessing a single database, thus providing a clustered database. For more information on configuring a host-based Sensor to monitor databases on an Oracle RAC, see Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC. Important: For information on performing an ASAP update of a host-based Sensor for Oracle on a *nix host, see the DbProtect Administrator s Guide. To install a host-based Sensor for DB2 on a *nix host running AIX 5.2 (64-bit) Technology Level 5 and up (or AIX 5.3 Technology Level 5 for Sensors prior to version 3.3): 1. Login as a user that will run the Sensor, i.e., appradar. Caution! Do not log in as root. Note: The user (i.e., appradar) must be a member of the same dba group as oracle on the host. 2. Download or copy the host-based Sensor file to your target database host. The file name is: AppRadar Sensor_<version number>_aix-ppc-64.tgz.sh for 64-bit AIX. 3. Install the host-based Sensor file as follows: sh "./AppRadar Sensor_<version number>_aix-ppc-64.tgz.sh" install <installation_dir> for AIX 5.2 (64-bit), where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. Note: If the filename contains spaces, then don't forget to quote these spaces in the command. The host-based Sensor is installed in the "<installation_dir>/asiappradar/" directory. 4. Finally, you must configure your host-based Sensor for Oracle DDL triggers, and configure your host-based Sensor for Oracle audit trail to monitor failed logins. For more information, see Appendix E: Working with Oracle DDL Triggers (for Host-Based Sensors for Oracle Installed on *nix Platforms Only) and Appendix J: Configuring Your Oracle Audit Trail in Order to Monitor Logins, respectively. Application Security, Inc. 167

169 Note: If you remove and re-add a DDL trigger for any reason, you must re-start the Sensor afterwards. Most DDL rules will not fire until this is done. 5. Start your Sensor; for more information, see Starting and stopping the Sensors. Important: The Sensor uses default port to receive commands from the Console. This port is recommended for most configurations, but you can specify a different port number ( ). To change the default port number for host-based Sensors installed on a *nix platform, you must manually modify the sensor.xml and sensor_original.xml files; for more information, see Appendix C: Modifying the Sensor Listener Port Number. For more information on required open listen ports, see Networking, port, and firewall considerations. Host-based Sensor for Oracle (on HP- UX) - installation steps Note: Note: You can configure your host-based Sensor for Oracle (on HP-UX) to start automatically upon system reboot; for more information, see Appendix R: Configuring Your Host-Based Sensor (Installed on a *nix Platform) to Start Automatically Upon System Reboot. Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle relational database management system (RDBMS) software simultaneously while accessing a single database, thus providing a clustered database. For more information on configuring a host-based Sensor to monitor databases on an Oracle RAC, see Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC. Important: For information on performing an ASAP update of a host-based Sensor for Oracle on *nix host, see the DbProtect Administrator s Guide. To install a host-based Sensor for Oracle on a *nix host running HP-UX 11i v1 (11.11) and greater on the PA-RISC processor and HP-UX 11i v2 (11.23) and greater on the Itanium (IA64) processor: 1. Login as a user that will run the Sensor, i.e., appradar. Caution! Do not log in as root. Note: The user (i.e., appradar) must be a member of the same dba group as oracle on the host. Application Security, Inc. 168

170 2. Download or copy the host-based Sensor file to your target database host. If you are installing a host-based Sensor on a *nix host running: HP-UX 11i v1 (11.11) and greater on the PA-RISC processor, the name if the file is: AppRadar Sensor_<version number>_hpux-hppa-64.tgz.sh HP-UX 11i v2 (11.23) and greater on the Itanium (IA64) processor, the name if the file is: AppRadar Sensor_<version number>_aix-ia64-64.tgz.sh 3. Install the host-based Sensor file as follows: Note: sh./appradar Sensor_<version number>_aix-ia64-64.tgz.sh" install <installation_dir> for HP-UX 11i v1 (11.11) and greater on the PA-RISC processor, where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. sh "./AppRadar Sensor_<version number>_hpux-ia64-64.tgz.sh" install <installation_dir> for HP-UX 11i v2 (11.23) and greater on the Itanium (IA64) processor, where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. If the filename contains spaces, then don't forget to quote these spaces in the command. The host-based Sensor is installed in the "<installation_dir>/asiappradar/" directory. 4. Finally, you must configure your host-based Sensor for Oracle DDL triggers, and configure your host-based Sensor for Oracle audit trail to monitor failed logins. For more information, see Appendix E: Working with Oracle DDL Triggers (for Host-Based Sensors for Oracle Installed on *nix Platforms Only) and Appendix J: Configuring Your Oracle Audit Trail in Order to Monitor Logins, respectively. Note: If you remove and re-add a DDL trigger for any reason, you must re-start the Sensor afterwards. Most DDL rules will not fire until this is done. 5. Start your Sensor; for more information, see Starting and stopping the Sensors. Application Security, Inc. 169

171 Important: The Sensor uses default port to receive commands from the Console. This port is recommended for most configurations, but you can specify a different port number ( ). To change the default port number for host-based Sensors installed on a *nix platform, you must manually modify the sensor.xml and sensor_original.xml files; for more information, see Appendix C: Modifying the Sensor Listener Port Number. For more information on required open listen ports, see Networking, port, and firewall considerations. Host-based Sensor for Oracle (on Red Hat Enterprise Linux) - installation steps Note: Note: You can configure your host-based Sensor for Oracle (on Red Hat Enterprise Linux) to start automatically upon system reboot; for more information, see Appendix R: Configuring Your Host-Based Sensor (Installed on a *nix Platform) to Start Automatically Upon System Reboot. Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle relational database management system (RDBMS) software simultaneously while accessing a single database, thus providing a clustered database. For more information on configuring a host-based Sensor to monitor databases on an Oracle RAC, see Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC. Important: For information on performing an ASAP update of a host-based Sensor for Oracle on a *nix host, see the DbProtect Administrator s Guide. Caution! The host-based Sensor installer may display a warning message if you run it on Red Hat Enterprise Linux 3 to inform you DB2 is not supported on version 3. You may safely ignore this warning. To install a host-based Sensor for Oracle on a host running Red Hat Enterprise Linux 3, 4, or 5 (32-bit x86 and 64-bit x64): 1. Login as a user that will run the Sensor, i.e., appradar. Caution! Do not log in as root. Note: The user (i.e., appradar) must be a member of the same dba group as oracle on the host. Application Security, Inc. 170

172 2. Download or copy the host-based Sensor file to your target database host. The file names are: AppRadar Sensor_<version number>_linux32.tgz.sh for Red Hat Enterprise Linux (32-bit x86) AppRadar Sensor_<version number>_linux64.tgz.sh for Red Hat Enterprise Linux (64-bit x64). 3. Install the host-based Sensor file as follows: sh "./AppRadar Sensor_<version number>_linux32.tgz.sh" install <installation_dir> for Red Hat Enterprise Linux (32-bit x86), where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. sh "./AppRadar Sensor_<version number>_linux64.tgz.sh" install <installation_dir> Note: for Red Hat Enterprise Linux (64-bit x64), where <installation_dir> is the directory where you want to install the Sensor, e.g. /opt. If the filename contains spaces, then don't forget to quote these spaces in the command. The host-based Sensor is installed in the "<installation_dir>/asiappradar/" directory. 4. Finally, you must configure your host-based Sensor for Oracle DDL triggers, and configure your host-based Sensor for Oracle audit trail to monitor failed logins. For more information, see Appendix E: Working with Oracle DDL Triggers (for Host-Based Sensors for Oracle Installed on *nix Platforms Only) and Appendix J: Configuring Your Oracle Audit Trail in Order to Monitor Logins, respectively. Note: If you remove and re-add a DDL trigger for any reason, you must re-start the Sensor afterwards. Most DDL rules will not fire until this is done. 5. Start your Sensor; for more information, see Starting and stopping the Sensors. Application Security, Inc. 171

173 Important: The Sensor uses default port to receive commands from the Console. This port is recommended for most configurations, but you can specify a different port number ( ). To change the default port number for host-based Sensors installed on a *nix platform, you must manually modify the sensor.xml and sensor_original.xml files; for more information, see Appendix C: Modifying the Sensor Listener Port Number. For more information on required open listen ports, see Networking, port, and firewall considerations. Host-based Sensor for Oracle (on Windows) - installation steps Note: Note: Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle relational database management system (RDBMS) software simultaneously while accessing a single database, thus providing a clustered database. For more information on configuring a host-based Sensor to monitor databases on an Oracle RAC, see Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC. Windows-only Oracle Fail Safe is another type of Oracle cluster. It is a core feature included with every Oracle 11gR1, Oracle 10g and Oracle9i license for Microsoft Windows 2000 and Microsoft Windows Oracle Fail Safe is integrated with Microsoft Cluster Server to allow you to configure and verify Microsoft Windows clusters and to automatically fail over Oracle databases and applications. For more information on configuring a hostbased Sensor for Oracle on Windows to monitor databases in an Oracle Oracle Fail Safe environment, see Appendix Q: Monitoring Oracle Databases in an Oracle Fail Safe Environment: Sensor and Cluster Configuration Steps. Important: To install a host-based Sensor for Oracle, you must be a Windows user with administrative rights on the host server. Hint: Make sure you install your host-based Sensor for Oracle (on Windows) in a path that does not include Oracle-reserved characters such as parentheses. This is an Oracle restriction. For example: C:\Program Files (x86). In a case such as this, you must install the host-based Sensor for Oracle (on Windows) in another location. Application Security, Inc. 172

174 To install a host-based Sensor for Oracle on Windows: 1. Locate the setup file on the Application Security, Inc.-provided CD, or download it from the Application Security, Inc. FTP site or website. 2. Save the file to a convenient location (e.g., c:\temp). 3. Double click the executable file to display the installation wizard (Welcome page) and begin the Sensor installation. The installer displays which version of the Sensor it will install. FIGURE: Welcome page Click the Install button to display the License Agreement page. Application Security, Inc. 173

175 4. The License Agreement page is shown below. FIGURE: License Agreement page Read the License Agreement. If you accept the terms of the License Agreement, select I accept the terms in the license agreement. Click the Next button to display the Choose Destination Location page. Application Security, Inc. 174

176 5. The Destination Folder page is shown below. FIGURE: Destination Folder page Choose the location of the Sensor installation directory. You can click the: -Change... button to choose a directory manually -Next button to choose the default location. (The default location is: c:\appsecinc\sensor\). Click the Next button to display the Sensor Type page. Application Security, Inc. 175

177 6. The Sensor Type page is shown below. FIGURE: Sensor Type page Select Host-based Sensor and click the Next button to display the Server Port page. Note: You can reconfigure an installed Sensor at anytime via the DbProtect Sensor Configuration tool or the command line; for more information, see Reconfiguring a Sensor (installed on Windows) via the DbProtect Sensor Configuration tool or the command line. Application Security, Inc. 176

178 7. The Server Port page is shown below. FIGURE: Server Port page Specify which port number the Sensor should use to receive commands from the Console. The default port (20000) is recommended for most configurations, but you can specify a different port number ( ). For more information on required open listen ports, see Networking, port, and firewall considerations. You must click the Test Port button to test the port information. If the connection is successful, a green checkmark icon displays, and the Next button is illuminated. Click the Next button to display the Service Log On Credentials page. Application Security, Inc. 177

179 8. The Sensor Service Logon Details page is shown below. FIGURE: Sensor Service Logon Details page Specify a database user login and password. Important: If you want to specify a non-local user username and password for the Sensor to run under, you must do so in this step. You can select: -Run service as Local System, if you want to use the "local system" account, which has full access rights and privileges on the host computer. -Run service as: to specify a domain user login and password. Important: The Sensor logs in to the monitored database, and the Sensor service runs, under this user profile. This profile must be a Windows user with administrator rights. Also, the account name specified must have the "log on as service" permission set in the Local Security Policy of the server (for more information, see your Windows help). If you select Run service as:, then you must enter a valid domain name\user name and password. Click the Next button to display the Install DbProtect Sensor page. Application Security, Inc. 178

180 9. The Install DbProtect Sensor page is shown below. FIGURE: Install DbProtect Sensor page If want to review or change any settings you can click the Back button. Click the Install button. When the installation finishes, a Sensor installation success page displays. Application Security, Inc. 179

181 10.The Sensor installation success page is shown below. FIGURE: Sensor installation success page Review the installation details at the bottom of the page. Click the Finish button to close the installer. 11.A congratulations pop up displays. FIGURE: Note: Sensor installation success page Click the OK button to close the congratulations pop up. DbProtect allows you to switch a host-based Sensor to a network-based Sensor, or viceversa, without having to uninstall the Sensor, then re-install/reconfigure it. There are two ways to accomplish this. The first is via the DbProtect Sensor Configuration tool; for more information, see Reconfiguring a Sensor (installed on Windows) via the DbProtect Sensor Configuration tool. The second is via the command line; for more information, see Reconfiguring a Sensor (installed on Windows) via a command line. Application Security, Inc. 180

182 Network-based Sensor for Sybase, Oracle, and DB2 - installation steps Caution! Network-based Sensors only run on the Windows OS, but the databases they monitor do not need to be running on Windows. Important: To install the network-based Sensor, you must have administrative privileges on Windows. To run the network-based Sensor, you must have administrative and run as a service" privileges on Windows. To install a network-based Sensor for DB2, Oracle, or Sybase: 1. Locate the setup file on the Application Security, Inc.-provided CD, or download it from the Application Security, Inc. FTP site or website. 2. Save the file to a convenient location (e.g., c:\temp). 3. Double click the executable file to display the installation wizard (Welcome page) and begin the Sensor installation. The installer displays which version of the Sensor it will install. FIGURE: Welcome page Click the Install button to display the License Agreement page. Application Security, Inc. 181

183 4. The License Agreement page is shown below. FIGURE: License Agreement page Read the License Agreement. If you accept the terms of the License Agreement, select I accept the terms in the license agreement. Click the Next button to display the Choose Destination Location page. Application Security, Inc. 182

184 5. The Destination Folder page is shown below. FIGURE: Destination Folder page Choose the location of the Sensor installation directory. You can click the: -Change... button to choose a directory manually -Next button to choose the default location. (The default location is: c:\appsecinc\sensor\). Click the Next button to display the Sensor Type page. Application Security, Inc. 183

185 6. The Sensor Type page is shown below. FIGURE: Sensor Type page Select Network-based Sensor and click the Next button to display the Server Port page. Note: You can reconfigure an installed Windows-based Sensor at anytime via the DbProtect Sensor Configuration tool or the command line; for more information, see Reconfiguring a Sensor (installed on Windows) via the DbProtect Sensor Configuration tool or the command line. Application Security, Inc. 184

186 7. The Server Port page is shown below. FIGURE: Server Port page Specify which port number the Sensor should use to receive commands from the Console. The default port (20000) is recommended for most configurations, but you can specify a different port number ( ). For more information on required open listen ports, see Networking, port, and firewall considerations. You must click the Test Port button to test the port information. If the connection is successful, a green checkmark icon displays, and the Next button is illuminated. Click the Next button to display the Service Log On Credentials page. Application Security, Inc. 185

187 8. The Sensor Service Logon Details page is shown below. FIGURE: Sensor Service Logon Details page Specify a database user login and password. Important: If you want to specify a non-local user username and password for the Sensor to run under, you must do so in this step. You can select: -Run service as Local System, if you want to use the "local system" account, which has full access rights and privileges on the host computer. -Run service as: to specify a domain user login and password. Important: The Sensor logs in to the monitored database, and the Sensor service runs, under this user profile. This profile must be a Windows user with administrator rights. Also, the account name specified must have the "log on as service" permission set in the Local Security Policy of the server (for more information, see your Windows help). If you select Run service as:, then you must enter a valid domain name\user name and password. Click the Next button to display the Install DbProtect Sensor page. Application Security, Inc. 186

188 9. The Install DbProtect Sensor page is shown below. FIGURE: Install DbProtect Sensor page If want to review or change any settings you can click the Back button. Click the Install button. When the installation finishes, a Sensor installation success page displays. Application Security, Inc. 187

189 10.The Sensor installation success page is shown below. FIGURE: Sensor installation success page Review the installation details at the bottom of the page. Click the Finish button to close the installer. 11.A congratulations pop up displays. FIGURE: Sensor installation success page 12.Click the OK button to close the congratulations pop up. Note: DbProtect allows you to switch a network-based Sensor to a host-based Sensor, or vice-versa, without having to uninstall the Sensor, then re-install/ reconfigure it. There are two ways to accomplish this. The first is via the DbProtect Sensor Configuration tool; for more information, see Reconfiguring a Sensor (installed on Windows) via the DbProtect Sensor Configuration tool. The second is via the command line; for more information, see Reconfiguring a Sensor (installed on Windows) via a command line. Application Security, Inc. 188

190 Starting and stopping the Sensors What you will find in this help topic: Starting and stopping the Sensors on Windows Starting and stopping the Sensors on *nix platforms. STARTING AND STOPPING THE SENSORS ON WINDOWS There are four DbProtect services: DbProtect Message Collector DbProtect Console DbProtect Scan Engine AppRadar Sensor You only need to start the AppRadar Sensor service in order for DbProtect to collect data from Sensors, and for you to connect to DbProtect. These services are configured to start whenever Windows starts. There are several ways to start and stop the services on Windows. Starting a Sensor from the command line: To start a Sensor from the command line: 1. Choose Start > Run to display the Run dialog box. 2. Enter cmd.exe in the Open field. 3. Click the OK button to display a command window. 4. Enter the following to start the service: C:\> net start AppRadar Sensor The following messages display: The AppRadar Sensor service is starting. The AppRadar Sensor service was started successfully. Stopping a Sensor from the command line: To stop a Sensor from the command line: 1. Choose Start > Run to display the Run dialog box. 2. Enter cmd.exe in the Open field. 3. Click the OK button to display a command window. Application Security, Inc. 189

191 4. Enter the following to stop the service: C:\> net stop ServiceName where ServiceName is one of the following: DbProtect Message Collector DbProtect Console DbProtect Scan Engine AppRadar Sensor The following messages display: The ServiceName service is stopping. The ServiceName service was stopped successfully. Starting a Sensor from the Control Panel: To start a Sensor from the Control Panel: 1. Choose Start > Control Panel to display the Control Panel dialog box. 2. Double click the Administrative Tools icon to display the Administrative Tools dialog box. 3. Double click the Services icon to display the Services dialog box. 4. Highlight any of the following services: DbProtect Message Collector DbProtect Console DbProtect Scan Engine AppRadar Sensor 5. Click the Start link to display the Service Control pop-up. The service starts. The Status column in the Services dialog box should read Started. Stopping a Sensor from the Control Panel: To stop a Sensor from the Control Panel: 1. Choose Start > Control Panel to display the Control Panel dialog box. 2. Double click the Administrative Tools icon to display the Administrative Tools dialog box. 3. Double click the Services icon to display the Services dialog box. 4. Highlight any of the following services: DbProtect Message Collector DbProtect Console DbProtect Scan Engine AppRadar Sensor Application Security, Inc. 190

192 5. Click the Stop link to display the Service Control pop-up. The service stops. The Status column in the Services dialog box should be blank. STARTING AND STOPPING THE SENSORS ON *NIX PLATFORMS To start and stop the Sensors on a *nix platform: 1. To start a host-based Sensor on a *nix platform, do the following: Log in as the DbProtect Sensor user you created during the installation process (appradar, for example). Once you are successfully authenticated as this user, go to the /util directory where you installed the host-based Sensor (for example: <sensor installation path>/opt/asiappradar/sensor/util). Run the command:./appradar_start 2. To start a host-based Sensor on a *nix platform, do the following: Log in as the user you created in during the installation process (appradar, for example). Once you are successfully authenticated as this user, go to the /util directory where you installed the host-based Sensor (for example: <sensor installation path>/opt/asiappradar/sensor/util). Run the command:./appradar_stop Reconfiguring a Sensor (installed on Windows) via the DbProtect Sensor Configuration tool or the command line DbProtect allows you to switch a network-based Sensor to a host-based Sensor, or vice-versa, without having to uninstall the Sensor, then re-install/reconfigure it. You can accomplish this via the: DbProtect Sensor Configuration tool; for more information, see Reconfiguring a Sensor (installed on Windows) via the DbProtect Sensor Configuration tool command line; for more information, see Reconfiguring a Sensor (installed on Windows) via a command line. The DbProtect Sensor Configuration tool also allows you to reconfigure additional Sensor installation parameters for a Sensor installed on Windows. Specifically, you can reconfigure the: server port number the Windows user that is used to run the Sensor. For more information, see Reconfiguring a Sensor (installed on Windows) via the DbProtect Sensor Configuration tool. Application Security, Inc. 191

193 RECONFIGURING A SENSOR (INSTALLED ON WINDOWS) VIA THE DBPROTECT SENSOR CONFIGURATION TOOL To reconfigure a Sensor installed on Windows via the DbProtect Sensor Configuration tool: 1. Choose Start > All Programs > AppSecInc > Sensor > Configure Sensor to display the DbProtect Sensor Configuration tool. FIGURE: DbProtect Sensor Configuration tool 2. Click the Next button. The DbProtect Sensor Configuration tool pages that follow are identical to the Sensor installation pages (for Sensor installations on Windows). If you want to: switch a network-based Sensor to a host-based Sensor, or vice-versa, see Step 3 reconfigure the Sensor installation parameters (i.e., the server port number and/or the Windows user that is used to run the Sensor), see Step 4. Application Security, Inc. 192

194 3. The DbProtect Sensor Configuration tool allows you to switch a network-based Sensor to a host-based Sensor, or vice-versa, without having to uninstall the Sensor, then re-install/reconfigure it. If you want to switch a: Network-based Sensor to a host-based Sensor, see Host-based Sensor for DB2 (on Windows) - installation steps or Host-based Sensor for Oracle (on Windows) - installation steps (depending on the database type). Step 6 of each (identical) topic explains how to specify the Sensor type, i.e., hostor network-based. If all you want to do is switch the Sensor type, follow the wizard steps until the end. If you want to reconfigure additional Sensor installation parameters (i.e., the server port number and/or the Windows user that is used to run the Sensor), go to the next step, below. Host-based Sensor to a network-based Sensor, see Host-based Sensor for DB2 (on Windows) - installation steps or Host-based Sensor for Oracle (on Windows) - installation steps. Step 6 of each (identical) topic explains how to specify the Sensor type, i.e., hostor network-based. If all you want to do is switch the Sensor type, follow the wizard steps until the end. If you want to reconfigure additional Sensor installation parameters (i.e., the server port number and/or the Windows user that is used to run the Sensor), go to the next step, below. Important: After you switch a network-based Sensor to a host-based Sensor, or vice- versa, you must re-register the Sensor via the Console; for more information, see Registering a Sensor in the DbProtect User s Guide. 4. The DbProtect Sensor Configuration tool allows you to reconfigure the Sensor installation parameters (i.e., the server port number and/or the Windows user that is used to run the Sensor) of a Sensor installed on Windows. Again, the DbProtect Sensor Configuration tool pages are identical to the Sensor installation pages (for Sensor installations on Windows). For more information on reconfiguring the installation parameters of a: Host-based Sensor for SQL Server (on Windows), see Host-based Sensor for SQL Server (on Windows) - installation steps. Host-based Sensor for DB2 (on Windows), see Host-based Sensor for DB2 (on Windows) - installation steps. Host-based Sensor for Oracle (on Windows), see Host-based Sensor for Oracle (on Windows) - installation steps. Application Security, Inc. 193

195 Network-based Sensor for Sybase, Oracle, and DB2 (on Windows), see Network-based Sensor for Sybase, Oracle, and DB2 - installation steps. In each of these topics, Step 7 explains how to reconfigure the server port number. Step 8 explains how to reconfigure the Windows user that is used to run the Sensor. Important: If you reconfigure the server port number, you must re-register the Sensor via the Console; for more information, see Registering a Sensor in the DbProtect User s Guide. However, if you only reconfigure the Windows user that is used to run the Sensor, you do not need to register the Sensor. RECONFIGURING A SENSOR (INSTALLED ON WINDOWS) VIA A COMMAND LINE DbProtect allows you to use a command line to switch a network-based Sensor to a host-based, or vice-versa, without having to uninstall the Sensor, then re-install/ reconfigure it. To reconfigure a Sensor installed on Windows via the command line: 1. Choose Start > Run to display the Run dialog box. 2. Enter cmd.exe in the Open field. 3. Click the OK button to display a command window. 4. Switch your directory path to: <sensor installation folder>\appsecinc\ Sensor\bin 5. If you want to: switch a network-based Sensor to a host-based Sensor, or vice-versa, see Step 5 reconfigure the Sensor server port number for a Sensor installed on Windows, see Step Enter the following command to switch a: host-based Sensor to a network-based Sensor: appradar_sensor.exe -z -m network-based network-based Sensor to a host-based Sensor: appradar_sensor.exe -z -m host-based Important: After you switch a network-based Sensor to a host-based Sensor, or vice- versa, you must re-register the Sensor via the Console; for more information, see Registering a Sensor in the DbProtect User s Guide. Application Security, Inc. 194

196 7. Enter the following command to reconfigure the Sensor server port number for a Sensor installed on Windows: appradar_sensor.exe z p <new sensor port number> For example, if you want to switch the port number to 20001, enter the following command: appradar_sensor.exe z p Important: If you reconfigure the server port number, you must re-register the Sensor via the Console; for more information, see Registering a Sensor in the DbProtect User s Guide. Hint: You can run the command appradar_sensor.exe h to display a help screen that lists all your command line options. Application Security, Inc. 195

197 Logging Into the DbProtect Console (and DbProtect Console Login Troubleshooting) What you will find in this section: Logging Into the DbProtect Console Logging Into the DbProtect Console Using SSO DbProtect Console Login Troubleshooting. Logging Into the DbProtect Console Caution! Some older versions of Google Desktop (5.1 and earlier) may cause problems when loading the DbProtect Console applet in Internet Explorer. You should turn off Google Desktop, or reinstall a newer (5.2 or greater) version. Note: You must have the Java Runtime Environment (JRE) SE 6 Update 11 installed in order to connect to the DbProtect Console via a web browser. To log into the DbProtect Console: 1. Do one of the following: Open Internet Explorer 6.0 or greater with JavaScript enabled, and the screen resolution set to a minimum of 1024x768. Enter InstallPort in the Address line, where: -YourMachineName is the computer name of your Console machine -InstallPort is the port number entered during installation. A Security Alert pop up displays, prompting you to accept a security certificate from Application Security, Inc. DbProtect uses this certificate to communicate with users over a secure channel. Application Security, Inc. 196

198 Note: If you experience difficulty logging into DbProtect and connecting to DbProtect, you may need to troubleshoot the Java Runtime Environment (JRE) security settings on your Internet Explorer 6 or greater web browser. For more information on a workaround, see Troubleshooting the Java Run Time Environment (JRE) Security Settings on Internet Explorer 6 or Troubleshooting the Java Run Time Environment (JRE) Security Settings on Internet Explorer 7. Another possible solution is to clear your Java cache. For more information, see Clearing Your Java Cache. 2. Click the OK button to display the DbProtect Console login page. FIGURE: DbProtect Console login page 3. Do the following: In the Username: field, enter your DbProtect user name. You can use any of the following formats: -username: local user -<computername>\username -<netbios domain name>\username -<dns domain name>\username -username@<dns domain name> In the Password: field, enter your DbProtect password. Use the Domain: drop-down to select your domain, or manually enter a domain in the Domain: field. Application Security, Inc. 197

199 Note: DbProtect is designed to use only Secure Sockets Layer (SSL) communication, which encrypts your user name and credentials prior to transmission to DbProtect. DbProtect then uses the Windows Authentication subsystem to verify the credentials. Hint: You can check the Remember settings on this computer checkbox to store your Username:, Password: and Domain: login values. You can click the Rest button to reset the entered Username:, Password: and Domain: login values. 4. Click the Login button to display the DbProtect Console. For more information on navigating the DbProtect Console, see Global Navigation in DbProtect in the DbProtect User s Guide. FIGURE: DbProtect Console (Vulnerability Management / Dashboard selected) Every DbProtect Console page includes global navigation elements. They are: Application tabs (in the upper portion of every Console page) which allow you to toggle between the different components of DbProtect. Specifically, you can click the: -Vulnerability Management tab to display and use DbProtect Vulnerability Management; for more information, see Vulnerability Management in the DbProtect User s Guide -Audit & Threat Management tab to display and use DbProtect Audit & Threat Management; for more information, see Audit and Threat Management in the DbProtect User s Guide -Analytics & Reporting tab to use DbProtect Analytics and run DbProtect reports; for more information, see the DbProtect Analytics User s Guide -Asset Management tab to view and manage all your database assets; for more information, see DbProtect Asset Management in the DbProtect User s Guide Application Security, Inc. 198

200 -Administration tab to use Content Packs and view your DbProtect system information; for more information, see The DbProtect Administration Page: Content/Compliance Packs and System Information in the DbProtect User s Guide. -User/Organization information, i.e., your logged-in user ID and your associated effective Organization (in the upper right portion of every DbProtect Console page). If you are a Super User or an Admin User, and your User ID is associated with multiple Organizations, you can toggle between Organizations. For more information, see Setting Your Effective Organization in the DbProtect User s Guide. help and logout links (in the upper right portion of every DbProtect Console page). Clicking these links allows you to display the DbProtect online help and log out of DbProtect, respectively. Logging Into the DbProtect Console Using SSO Starting with version 6.1, DbProtect allows you to use Windows authentication to log into the DbProtect Console using a login mechanism known as single sign-on (SSO). Note: SSO capability only works on Microsoft Windows systems. If Windows authentication is properly configured, you can log into the DbProtect Console via Internet Explorer 6.0 or greater without having to enter a username and password. For security purposes, SSO is ideally combined with strong authentication methods like smart cards or one-time password tokens. There are numerous benefits to implementing SSO. For example, SSO reduces the proliferation of user accounts and passwords and enables a more secure environment. SSO also eliminates the need for DbProtect users to remember an additional password. Other benefits include: reducing time spent re-entering passwords for the same identity reducing IT costs due to lower number of IT help desk calls about passwords security on all levels of entry/exit/access to systems without the inconvenience of re-prompting users centralized reporting for compliance adherence. In order to implement SSO, you (or your administrator) must modify several configuration files. For more information, see the DbProtect Administrator s Guide. To log into the DbProtect Console using SSO: 1. Do the following: Open Internet Explorer 6.0 or greater with JavaScript enabled, and the screen resolution set to a minimum of 1024x768. Enter InstallPort in the Address line, where: -YourMachineName is the computer name of your DbProtect Console machine -InstallPort is the port number entered during installation. Application Security, Inc. 199

201 A Security Alert pop up displays, prompting you to accept a security certificate from Application Security, Inc. DbProtect uses this certificate to communicate with users over a secure channel. Caution! If an access denied pop-up displays, prompting you to enter your credentials, this means you don t have access to the DbProtect system, even though you re a valid Windows user. If this happens, contact your DbProtect administrator to obtain access to the DbProtect system. Note: If you experience difficulty logging into the DbProtect Console and connecting to DbProtect, you may need to troubleshoot the Java Runtime Environment (JRE) security settings on your Internet Explorer 6 or greater web browser. For more information on a workaround, see Troubleshooting the Java Run Time Environment (JRE) Security Settings on Internet Explorer 6 or Troubleshooting the Java Run Time Environment (JRE) Security Settings on Internet Explorer 7. Another possible solution is to clear your Java cache. For more information, see Clearing Your Java Cache. 2. The DbProtect Console displays; more information on navigating the Console, see Global Navigation in DbProtect in the DbProtect User s Guide. FIGURE: DbProtect Console (Vulnerability Management / Dashboard selected) Every DbProtect Console page includes global navigation elements. They are: Application tabs (in the upper portion of every DbProtect Console page) which allow you to toggle between the different components of DbProtect. Specifically, you can click the: -Vulnerability Management tab to display and use DbProtect Vulnerability Management; for more information, see Vulnerability Management in the DbProtect User s Guide Application Security, Inc. 200

202 -Audit & Threat Management tab to display and use DbProtect Audit & Threat Management; for more information, see Audit and Threat Management in the DbProtect User s Guide -Analytics & Reporting tab to use DbProtect Analytics and run DbProtect reports; for more information, see the DbProtect Analytics in the DbProtect User s Guide -Asset Management tab to view and manage all your database assets; for more information, see DbProtect Asset Management in the DbProtect User s Guide -Administration tab to use Content Packs and view your DbProtect system information; for more information, see DbProtect Administration: Content/ Compliance Packs, Data Sources, and System Information in the DbProtect User s Guide. -User/Organization information, i.e., your logged-in user ID and your associated effective Organization (in the upper right portion of every DbProtect Console page). If you are a Super User or an Admin User, and your User ID is associated with multiple Organizations, you can toggle between Organizations. For more information, see Setting Your Effective Organization in the DbProtect User s Guide. help and logout links (in the upper right portion of every DbProtect Console page). Clicking these links allows you to display the DbProtect online help and log out of DbProtect, respectively DbProtect Console Login Troubleshooting This topic consists of the following sub-topics: Troubleshooting the Java Run Time Environment (JRE) Security Settings on Internet Explorer 6 Troubleshooting the Java Run Time Environment (JRE) Security Settings on Internet Explorer 7 Clearing Your Java Cache Adding the DbProtect URL to Your List of Trusted Intranet Sites In Internet Explorer. TROUBLESHOOTING THE JAVA RUN TIME ENVIRONMENT (JRE) SECURITY SETTINGS ON INTERNET EXPLORER 6 If you are experiencing difficulty logging into the DbProtect Console, you may need to troubleshoot the Java Runtime Environment (JRE) security settings on your Internet Explorer (IE) 6 or greater web browser. If your web browser is IE 6, 6 Active X controls and enable third-party browser extensions security settings may not be enabled on your IE 6 browser. If this is the case, you will encounter an error message you attempt to authenticate, and you can t log in to the DbProtect Console. Application Security, Inc. 201

203 Note: The following security settings should be the default values in your IE 6 web browser. You should only change the settings if you re experiencing difficulty logging into the DbProtect Console. To enable proper Active X controls and enable third-party browser extensions security settings on IE 6, do the following: 1. Launch IE Do the following to display the Security Settings dialog box: Choose: Tools > Internet Options. Click the Security tab. Click the Custom Level button. 3. Set the following security settings to Enable or Prompt: Download signed ActiveX controls Run ActiveX controls and plug-ins. 4. Click the OK button. 5. Click the Advanced tab. The Security Settings dialog box displays. FIGURE: Internet Explorer Advanced Settings dialog box 6. Check Enable Third-party browser extensions (requires restart). 7. Click the OK button. 8. Close and re-launch IE 6. Application Security, Inc. 202

204 Try to log back into the DbProtect Console. If you continue to experience trouble, contact Application Security, Inc. Customer Support at TROUBLESHOOTING THE JAVA RUN TIME ENVIRONMENT (JRE) SECURITY SETTINGS ON INTERNET EXPLORER 7 If your web browser is IE 7, JRE 1.6 may be disabled and/or multiple JREs may be enabled on your client (i.e., the location from which your IE 7 browser is running). JRE 1.6 must be enabled in order for you to connect to the DbProtect Console. If JRE 1.6 is disabled, or if multiple JREs of different versions are enabled on your client, then you will encounter an error message when you attempt to authenticate, and you can t log in to the DbProtect Console. To ensure JRE 1.6 is enabled, and to temporarily disable multiple JREs on your client machine (using IE 7), do the following: 1. Launch IE Do the following to display the Settings dialog box: Choose: Tools > Internet Options. Click the Advanced tab. 3. Scroll down to the Java (Sun) portion of the dialog box and verify the following: JRE 1.6 is enabled (i.e., the box must be checked) multiple JRE installations are listed. JRE 1.6 must be enabled in order for you to connect to the DbProtect Console. If it is not, check the JRE 1.6 box. If JRE 1.6 is enabled, and other JRE versions are also enabled, then you must temporarily disable them by un-checking the boxes. 4. Click the Apply button. 5. Click the OK button. 6. Close and re-launch IE 7. Try to log back into the DbProtect Console. If you continue to experience trouble, contact Application Security, Inc. Customer Support at support@appsecinc.com. CLEARING YOUR JAVA CACHE If you are experiencing difficulty logging into the DbProtect Console, you may need to clear your Java cache. Application Security, Inc. also recommends you clear your Java cache after an upgrade. The Java cache does not get automatically cleared following a reboot. To clear your Java cache: Application Security, Inc. 203

205 1. Choose Start > Control Panel to display the Control Panel. 2. Double click the Java icon to display the Java Control Panel dialog box. 3. With the default General tab selected, click the Settings... button (in the Temporary Internet Files section of the dialog box) to display the Temporary Files Settings dialog box. 4. Click the Delete Files... button to clear your Java cache. Close your web browser and attempt to log into the DbProtect Console again. ADDING THE DBPROTECT URL TO YOUR LIST OF TRUSTED INTRANET SITES IN INTERNET EXPLORER In order for single sign-on (SSO) to function properly, you may need to configure Internet Explorer by adding the DbProtect URL to your list of trusted intranet sites. Note: The following steps explain how to configure Internet Explorer 7. Steps may vary slightly for other browser versions. In Internet Explorer, do the following: 1. Choose Tools > Internet Options to display the Internet Options dialog box. 2. Select the Security tab. 3. Select Local Intranet from the list of zone sites (at the top of the Internet Options dialog box). 4. Click the Sites button to display a Local intranet pop up. 5. Click the Advanced button to display a second Local intranet pop up. 6. Add to the Add this website to the zone: field, where <dbprotecturl> is the DbProtect Console URL; for more information, see Logging Into the DbProtect Console Using SSO. 7. Click the Add button to add DbProtect to your list of trusted local intranet sites. 8. Click the Close button to close the second Local intranet pop up. 9. Click the Close button to close the first Local intranet pop up. 10.Click the Apply button on the Internet Options dialog box to apply your changes. 11.Click the OK button to close the Internet Options dialog box. Application Security, Inc. 204

206 Chapter 6 - Uninstalling the DbProtect Components This chapter explains how to uninstall the following DbProtect components: the Console, Sensors, and Scan Engines. What you will find in this chapter: Uninstalling the DbProtect Suite Components Uninstalling and Unregistering a Sensor Uninstalling and Unregistering a Scan Engine. Application Security, Inc. 205

207 Uninstalling the DbProtect Suite Components This section provides uninstallation steps for the DbProtect suite components. You should uninstall the DbProtect suite components from the Start Menu or from the Control Panel. This topic consists of the following sub-topics: Before You Uninstall the DbProtect Suite Components Uninstalling the DbProtect Suite Components from the Start Menu. Before You Uninstall the DbProtect Suite Components Uninstalling the DbProtect Suite Components from the Start Menu Before you uninstall the DbProtect Console, do the following: 1. Unregister all Sensors from within DbProtect before uninstalling the DbProtect suite components. Unregistering a Sensor brings the Sensor back to its original install state, allowing you to register the Sensor again with the DbProtect Console. For more information, see Uninstalling and Unregistering a Sensor. 2. If you are uninstalling the DbProtect Console with the intention of reinstalling it later on a different server, you should back-up your SQL Server back-end database before you begin un-installing the DbProtect suite components. Then you can restore the SQL Server back-end database to whichever instance you select after you re-install the DbProtect suite components elsewhere. For more information on backing up your backend database, see the DbProtect Administrator s Guide. To uninstall the DbProtect suite components from the Start Menu: 1. Choose Start > AppSecInc > DbProtect > Uninstall DbProtect to display the uninstallation wizard. 2. Follow the prompts. The order of the uninstallation process is the exact opposite of the DbProtect suite component installation process (for more information, see Installing the DbProtect Suite Components). Caution! The DbProtect suite component uninstallation process does not delete your back-end database. 3. A message informs you when the uninstallation is complete. Click the Finish button. Application Security, Inc. 206

208 Uninstalling and Unregistering a Sensor This section provides uninstallation and unregistration (including forced unregistration) steps for a Sensor. What you will find in this section: Uninstallation vs. unregistration Uninstalling a Sensor (on Windows) Uninstalling a Host-Based Sensor for Oracle (on a *nix platform) Uninstalling a Host-Based Sensor for DB2 (on a *nix platform) Unregistering a Sensor. Uninstallation vs. unregistration Uninstalling a Sensor (on Windows) DbProtect Audit and Threat Management allows you to uninstall and/or unregister your Sensors. The key differences between uninstallation and unregistration follow: Note: Unregistration removes the Sensor from the Console, but does not remove the Sensor from the host where it is installed. Uninstallation removes the Sensor from the server where is installed, but does not remove the Sensor from the Console where it may have been registered (assuming the Sensor was not unregistered before it was uninstalled). Unregister all Sensors from within DbProtect before uninstalling the Console or Sensors. Unregistering a Sensor brings the Sensor back to its original install state, allowing you to register the Sensor again with DbProtect. For more information, see Unregistering a Sensor. You can uninstall any host-based or network-based Sensor (installed on Windows) from the Start Menu or the Control Panel. What you will find in this help topic: Uninstalling a Sensor (on Windows) from the Start Menu Uninstalling a Sensor (on Windows) from the Control Panel. UNINSTALLING A SENSOR (ON WINDOWS) FROM THE START MENU To uninstall a Sensor (on Windows) from the Start Menu: 1. Choose Start > AppSecInc > Sensor > Uninstall Sensor to display the uninstallation wizard. 2. Follow the prompts. Application Security, Inc. 207

209 3. A message informs you when the uninstallation is complete. Click the Finish button. UNINSTALLING A SENSOR (ON WINDOWS) FROM THE CONTROL PANEL To uninstall a Sensor (on Windows) from the Control Panel: 1. Choose Start > Control Panel to display the Control Panel. 2. Double click the Add or Remove Programs icon. 3. Select Sensor. 4. Click the Change/Remove button. 5. Follow the prompts. 6. A message informs you when the uninstallation is complete. Click the Finish button. Uninstalling a Host-Based Sensor for Oracle (on a *nix platform) Uninstalling a Host-Based Sensor for DB2 (on a *nix platform) To uninstall a host-based Sensor for Oracle (on a *nix platform): 1. If you installed a DDL trigger, use remove.sql (located in <Sensor Install Directory>/ASIappradar/sensor/java) to remove it. 2. If you turned on native auditing for failed logins, do the following (if necessary): Modify the audit_trail value in the pfile init.ora file Truncate the dba_audit_session table. 3. Unregister the host-based Sensor for Oracle; for more information, see Uninstalling and Unregistering a Sensor. 4. Stop the host-based Sensor for Oracle; for more information, see Starting and stopping the Sensors in the DbProtect User s Guide or DbProtect Administrator s Guide. 5. Delete the installation directory of the host-based Sensor for Oracle. To uninstall a host-based Sensor for DB2 (on a *nix platform): 1. Unregister the host-based Sensor for DB2; for more information, see Uninstalling and Unregistering a Sensor. 2. Stop the host-based Sensor for Oracle; for more information, see Starting and stopping the Sensors in the DbProtect User s Guide or DbProtect Administrator s Guide. 3. Delete the installation directory of the host-based Sensor for DB2. Application Security, Inc. 208

210 Unregistering a Sensor When you unregister a Sensor via the Sensor Manager, the Sensor stops sending messages and Alerts. Unregistration returns the Sensor to its original, unconfigured installation state -- but it is not removed. Note: An unregistered Sensor continues to log events to a notification file (appradar_app.txt located in the Sensor s log directory), but only whether the Sensor is up or down. You can forcibly unregister a Sensor in the rare event it does not respond to an unregistration request via the Sensor Manager. What you will find in this help topic: Unregistering a Sensor via the Sensor Manager Forcibly unregistering a Sensor (if unregistration via the Sensor Manager fails). UNREGISTERING A SENSOR VIA THE SENSOR MANAGER To unregister a Sensor via the Sensor Manager: 1. Log into the Console and select Audit & Threat Management. 2. Do one of the following to display the Sensor Manager: Click the Sensors - Manage Sensor workflow link on the Home page. Click the Sensors tab from anywhere on the page. FIGURE: Sensor Manager 3. Highlight a registered Sensor, and click the Unregister button. An unregistration confirmation pop-up displays. FIGURE: Unregistration confirmation pop-up Click the Yes button. DbProtect unregisters your Sensor. Application Security, Inc. 209

211 Note: If unregistration is unsuccessful, DbProtect prompts you to let it attempt a forced unregistration; for more information, see Forcibly unregistering a Sensor (if unregistration via the Sensor Manager fails). FORCIBLY UNREGISTERING A SENSOR (IF UNREGISTRATION VIA THE SENSOR MANAGER FAILS) You can forcibly unregister a Sensor in the rare event it does not respond to an unregistration request via the Sensor Manager. To forcibly unregister a Sensor: 1. Do the following (in any order): On the Sensor Manager, click the Yes button when you are prompted to forcibly unregister a Sensor. Run force_unregister.bat (on Windows) or force_unregister (on *nix platforms) on the Sensor's host, located by default in the following directories: -On Windows installations: <Sensor Install Directory>\AppSecInc\ Sensor\utils -On *nix installations: <Sensor Install Directory>/ASIappradar/sensor/ util Your Sensor is forcibly unregistered. Note: You can register the Sensor again, if necessary; for more information, see the DbProtect User s Guide. Application Security, Inc. 210

212 Uninstalling and Unregistering a Scan Engine This section provides uninstallation and unregistration steps for a Scan Engine. What you will find in this section: Unregistering a Scan Engine Uninstalling a Scan Engine. Unregistering a Scan Engine When you unregister a Scan Engine, you return the Scan Engine to its original, unconfigured installation state -- but it is not removed. Note: You should unregister your Scan Engine before you uninstall it. To unregister a Scan Engine: 1. Log into DbProtect and select Vulnerability Management. 2. Click the Scan Engines button on the toolbar. 3. Do one of the following to unregister a Scan Engine: Choose Scan Engines > Unregister from the menu. Right click a Scan Engine in the Scan Engines portion of the Scan Engines page, and choose Unregister. 4. The Confirm Unregister pop up prompts you to confirm the unregistration. Click the Yes button. 5. DbProtect unregisters your Scan Engine. Uninstalling a Scan Engine You can uninstall an Scan Engine from the Control Panel. Note: You should unregister an Scan Engine before you uninstall it; for more information, see Unregistering a Scan Engine. To uninstall a Scan Engine: 1. Choose Start > Control Panel to display the Control Panel. 2. Double click the Add or Remove Programs icon. 3. Select DbProtect Scan Engine. 4. Click the Change/Remove button. 5. Follow the prompts. Application Security, Inc. 211

213 6. A message informs you when the uninstallation is complete. Click the Finish button. Application Security, Inc. 212

214 Chapter 7 - Installation Troubleshooting This chapter provides answers to some troubleshooting questions. What you will find in this chapter: How do I contact Customer Support? How can I watch (or "tail") my log files? What happens if I uninstall the SQL Server instance a Sensor is monitoring? I uninstalled DbProtect without unregistering my Sensors. What can I do so I can register my Sensors again without reinstalling them? How can I find out my SQL Server virtual server name? How can I review the audit events in a log file? The DbProtect or Sensor service failed to start, and when I look at the DbProtect or Sensor log file located in the log directory, they indicate a "bind to port" error. What should I do? My Sensor is using a Policy with only the Select from User Table Rule enabled. I executed a SQL DELETE statement against my database, and the Select from User Table Rule fired. Why? Are there any firewall issues I should consider? Do I require domain administrator rights after I install a Sensor on a Cluster? Is a Windows account created when I install a Sensor on SQL Server? Are any accounts created within SQL Server? I see my Sensor listed as timed out in the Sensor Manager. What can I do to reactivate my Sensor? What should I do if the following error message displays: Error Occurred. The DbProtect database is not available at the moment. Please retry your request later.? What should I do if I m not receiving any Alerts? Why am I displaying a blank page on the DbProtect Console UI? I m having trouble establishing a connection between the Console and my Sensor installed on Microsoft Windows Application Security, Inc. 213

215 How do I contact Customer Support? How can I watch (or "tail") my log files? What happens if I uninstall the SQL Server instance a Sensor is monitoring? I uninstalled DbProtect without unregistering my Sensors. What can I do so I can register my Sensors again without reinstalling them? A: support@appsecinc.com; for more information, see What should I do if I m not receiving any Alerts?. A: DbProtect provides a tail program if you wish to watch the Sensor and DbProtect log files. To watch the: Sensor log file, on Windows execute the tailsensor.bat file, stored in C:\<Sensor installation directory>\util DbProtect log file, execute the tailconsole.bat file, stored in C:\<DbProtect Installation Folder>\AppSecInc\DbProtect\GUI\util. A: The Sensor will not receive any new Alerts. You should unregister the Sensor first, then uninstall it. For more information on unregistering a Sensor, see the DbProtect User s Guide. For more information on uninstalling a Sensor, see Uninstalling and Unregistering a Sensor. Alternately, you can reconfigure your Sensor to monitor another database instance. For more information on reconfiguring a Sensor, see the DbProtect User s Guide. A: Application Security, Inc. provides a Sensor reset batch file (force_unregister.bat on Microsoft Windows and force_unregister on Unix) with each Sensor installation. The file is located in the util folder of the Sensor installation directory (e.g. for Windows c:\<sensor installation directory>\util\force_unregister.bat). When you execute the batch file, it resets the Sensor to its original settings. You can then register the Sensor again. Application Security, Inc. 214

216 How can I find out my SQL Server virtual server name? How can I review the audit events in a log file? The DbProtect or Sensor service failed to start, and when I look at the DbProtect or Sensor log file located in the log directory, they indicate a "bind to port" error. What should I do? My Sensor is using a Policy with only the Select from User Table Rule enabled. I executed a SQL DELETE statement against my database, and the Select from User Table Rule fired. Why? A: You can find the SQL_virtual_server_name in the Cluster Administrator, located in the cluster's Resources folder. To display: right click the SQL Network Name Resource, and select Properties. In the dialog box that displays, click the Parameters tab. Your SQL_virtual_server_name displays in the Name field. A: The log file (appradar_notifications.txt) is stored in c:\<sensor installation directory>\appsecinc\sensor\logs. Optionally, you can specify a different target location on this page. Audit logs, when configured to go to a file, are in the \logs sub-folder in the Sensor installation directory; for more information Installing, Starting/Stopping, and Reconfiguring the Sensors. A: Make sure no other application is using the ports you specified during installation of the Sensor and DbProtect. Restart the service after you ve shut down any software that is using or blocking the ports. A: When SQL Server executes a DELETE statement, its underlying engine first does a SELECT statement on the target table before proceeding with the deletion. Application Security, Inc. 215

217 Are there any firewall issues I should consider? Do I require domain administrator rights after I install a Sensor on a Cluster? Is a Windows account created when I install a Sensor on SQL Server? Are any accounts created within SQL Server? A: The DbProtect Console is accessible via HTTPS on port You can allow all machines, certain machines, or no machines to have access from outside your firewall. In the latter case, only machines inside the firewall can access the DbProtect Console. This is completely at your discretion, but for convenience Application Security, Inc. recommends you at least allow users to connect from their desktop machines. DbProtect has its own method of authentication and using a firewall is not required to restrict access. The Message Collector component of DbProtect listens for HTTPS traffic on port 20081, which the Sensor uses to send Alerts. Application Security, Inc. recommends you disallow all traffic to that port except from the Sensors. Sensors listen on port for HTTPS traffic from DbProtect (unless you configure them differently during installation), or you can reconfigure Sensor to change the port number; for more information, see Installing, Starting/Stopping, and Reconfiguring the Sensors. No other machines should be permitted to connect to the Sensors. A: No. For more information on installing Sensors on a SQL Server Cluster, see Appendix A: Installing/Uninstalling Sensors in a SQL Server Cluster. A: A: No. A: A: No. Application Security, Inc. 216

218 I see my Sensor listed as timed out in the Sensor Manager. What can I do to reactivate my Sensor? A: When a Sensor times out, it means DbProtect is unable to communicate with it. Do the following: The Sensor may be under heavy load. Wait two minutes and check again. Determine if the IP address of either DbProtect or the Sensor has changed since you registered the Sensor. If either one has, change the IP address back to its original value, or, if that s not possible, unregister and register the Sensor. For more information on unregistering a Sensor, see the DbProtect Administrator s Guide. For more information on manually removing a Sensor, if necessary, see Uninstalling and Unregistering a Sensor. Use your ping utility to verify your DbProtect machine can communicate with your Sensor machine. On the Sensor machine, ensure the DbProtect Sensor service is running. If the service was stopped, try starting it again; for more information on starting and stopping DbProtect services, see the DbProtect Administrator s Guide. Verify that you have correctly configured any firewalls between DbProtect and the Sensor; for more information, see Are there any firewall issues I should consider? Make sure the following services are running: On the DbProtect Console host: -DbProtect Message Collector -DbProtect Console -DbProtect Scan Engine On the Sensor host: -DbProtect Sensor For more information on starting and stopping DbProtect services, see the DbProtect Administrator s Guide. Check the dbprotect.log file for errors; for more information, see Appendix H: DbProtect Log Files. support@appsecinc.com; for more information, see What should I do if I m not receiving any Alerts? Application Security, Inc. 217

219 What should I do if the following error message displays: Error Occurred. The DbProtect database is not available at the moment. Please retry your request later.? What should I do if I m not receiving any Alerts? A: Make sure the database instance that DbProtect uses (i.e., MSSQL) is running, and make sure the database credentials you specified during installation are correct. For more information on starting and stopping DbProtect services, see the DbProtect Administrator s Guide. For more information on DbProtect component installation, see Chapter 5 - Installing the DbProtect Components, Logging Into the DbProtect Console, and DbProtect Console Login Troubleshooting. support@appsecinc.com; for more information, see What should I do if I m not receiving any Alerts? A: A: If you re not receiving any Alerts, make sure you have: met all of the minimum system requirements, including required patches and permissions; for more information, see Chapter 3 - Minimum System Requirements. properly installed your Sensor; for more information, see Installing, Starting/ Stopping, and Reconfiguring the Sensors. properly connected to the Console; for more information, see the DbProtect User s Guide. no firewall issues that may be blocking communication between DbProtect and your Sensors; for more information, see Are there any firewall issues I should consider? A: If you are still not receiving any Alerts, here are some Alert considerations: A: Note: A security Alert is a notification of a monitored security event on the database host or network. DbProtect fires an Alert when the criteria for the Rule in the associated Policy is met (unless an exception or Filter prevents the Alert from firing). The level of a security Alert is either High, Medium, or Low. For more information on Policies, see the DbProtect User s Guide. An Informational Alert (also known as an audit) is a record of standard database activity. The level of an Informational Alert can be Info-1, Info-2, Info-3, or r Info-4. The Alert Manager only displays security Alerts. It does not display Informational Alerts. For more information, see the DbProtect User s Guide. If you want to view your Informational Alerts, must run the Auditing Event Summary Report or create a new report template that includes the Informational risk level. For more information, see the DbProtect User s Guide. Note: The default settings for new report templates do not include Informational Alerts. Application Security, Inc. 218

220 Alternately, you can view your most recent Informational Alerts via the Dashboard; for more information, see the DbProtect User s Guide Informational Alerts may only show up every 15 minutes depending on the configuration. A: If you are still not receiving any Alerts, here are some Sensor considerations: A: For network-based Sensors: Make sure you have properly configured your SPAN port; for more information, see Network-based Sensor for Sybase, Oracle, and DB2 - installation steps. Ensure that your SPAN port is detecting network traffic. Do the following: -On your Sensor machine, double click c:\<sensor installation directory>\bin\net_cfg_test.exe to display the Network Configuration Test Tool. -Use the drop-down to select the network card that is connected to your SPAN port. The tool should display a list of servers which are either sending or receiving network traffic. -If this list does not include your database server, confirm you have correctly configured the SPAN port. If you SPAN port is detecting network activity, verify you have properly configured your network-based Sensor. Specifically, did you configure the network-based Sensor with the correct IP address(es) and port(s)? For Oracle, is the network-based Sensor configured with the correct SID and service name? For more information, see the DbProtect User s Guide. For host-based Sensors: Is the host-based Sensor pointing to the correct database? Is the database active right now? For more information, see the DbProtect User s Guide. Are you specifically not receiving DDL Alerts? Open the appsensor.log. See if it contains something similar to the following error message: _20:27: [error] ( ) [TcpServer::open] Error opening TCP server port (icp_server.cpp:57)) If so, this means the IPC port is already in use. A: If you are still not receiving any Alerts, here are some Policy considerations: A: What Policy did you deploy? Will the deployed Policy fire Alerts based on the database events you want to monitor? Application Security, Inc. 219

221 Edit the deployed Policy. Change a rule to display a common, Informational Alert event (i.e., Info-1, Info-2, Info-3, or Info-4) as a Low event, i.e., an event that will trigger a Low security Alert and display in the Alert Manager; for more information, see for more information, see the DbProtect User s Guide. Then, go to the Alert Manager to see if Low security Alert displays; for more information, see the DbProtect User s Guide. A: If you are still not receiving any Alerts, here are some SSL-related considerations: A: Is the time the same on the DbProtect and the Sensor machines? Time zone differences are acceptable as long as both machines represent the same point in time (within a few minutes). Has the IP address or hostname of the DbProtect or the Sensor machine changed recently? If so, un-register and re-register the Sensor. You may need to forcibly unregister the Sensor. A: Finally, if you are still not receiving any Alerts, contact Application Security, Inc. Customer Support. Execute the collectinfo.bat files on both your DbProtect and Sensor machines. On your DbProtect machine, you must execute two separate collectinfo.bat files (i.e., one for the MessageCollector service, and one for the GUI). These collectinfo.bat files are located in the following folders: c:\<sensor installation directory>\util c:\<dbprotect Installation Folder>\DbProtect\MessageCollector\util Executing these.bat files creates a.zip file in each folder, i.e., one for the MessageCollector service, and one for the GUI. Caution! The GUI and MessageCollector.zip files are both named AppsecIncConsole.zip. Re-name one before sending to Application Security, Inc. Customer support. On your Sensor machine, execute the collectinfo.bat files located here: C:\<DbProtect Installation Folder>\DbProtect\GUI\util. Executing this.bat file creates a.zip file (one for each Sensor). This.zip file contains configuration and log files which allow Application Security, Inc. Customer Support to troubleshoot your issue. Attach all three generated.zip files (i.e., two from your DbProtect machine and one from your Sensor server) to an , and send to support@appsecinc.com for analysis. Application Security, Inc. 220

222 Why am I displaying a blank page on the DbProtect Console UI? I m having trouble establishing a connection between the Console and my Sensor installed on Microsoft Windows 2008 A: A: You must enable Javascript on your web browser. If you re having trouble establishing a connection between the Console and a Sensor installed on Microsoft Windows 2008 (i.e., a host-based Sensor for Oracle on Windows, a host-based Sensor for DB2 on Windows, a host-based Sensor for Microsoft SQL Server on Windows, or any network-based Sensor), make sure IPV6 support is not enabled on the network adapter, and that your Microsoft Windows Firewall is disabled. Application Security, Inc. 221

223 Appendices What you will find in this chapter: Appendix A: Installing/Uninstalling Sensors in a SQL Server Cluster Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC Appendix C: Modifying the Sensor Listener Port Number Appendix D: Network Ports Used by DbProtect Appendix E: Working with Oracle DDL Triggers (for Host-Based Sensors for Oracle Installed on *nix Platforms Only) Appendix F: Modifying the "Log On As" User for the DbProtect Sensor and DbProtect Message Collector Services Appendix G: DB2 Administrative Client Driver Installation Appendix H: DbProtect Log Files Appendix I: Using App DSN, the Repair ODBC Utility Appendix J: Configuring Your Oracle Audit Trail in Order to Monitor Logins Appendix K: Required Client Drivers for Audits Appendix L: Required Audit Privileges Appendix M: Auditing SQL Server (Using Windows Authentication) Against a Machine on a Different or Untrusted Domain Appendix N: Troubleshooting the Java Run Time Environment (JRE) Security Settings on Internet Explorer 6 and 7 Appendix O: Clearing Your Java Cache Appendix P: Monitoring Multiple Instances on a DB2 Server Appendix Q: Monitoring Oracle Databases in an Oracle Fail Safe Environment: Sensor and Cluster Configuration Steps Appendix R: Configuring Your Host-Based Sensor (Installed on a *nix Platform) to Start Automatically Upon System Reboot Appendix S: Remote-Deploying DbProtect Components on Windows in Your Enterprise Appendix T: Creating Your Own Microsoft SQL Server AppDetective Database Application Security, Inc. 222

224 Appendix A: Installing/ Uninstalling Sensors in a SQL Server Cluster This appendix explains how to configure Sensors in a Clustered environment. Note: In this appendix: DbProtect allows you to build one (or multiple) database instances within one (or multiple) virtual servers. For more information, see Installing Sensors in a SQL Server Cluster (single instance) and Installing DbProtect in a SQL Server Cluster (Sensors installed on multiple instances), respectively. Assumptions Working with a SQL Server Cluster (Sensors installed on a single instance) Working with a SQL Server Cluster (Sensors installed on multiple instances). Assumptions This appendix assumes you: have a strong working knowledge of implementation and administration of Windows and SQL Server Clustering have a Windows Cluster configured with SQL Server in a Cluster Group are logged in as a user with both domain and SQL Server administrative privileges your shared drive (referred to as X:, in this appendix) is currently located in the same Resource Group as the Virtual SQL Server instance your Sensor will monitor (applies to single instance installations only) all necessary Cluster resources are currently online, and you have identified the Cluster s Active Node (applies to single instance installations only) are working with multiple virtual servers, each one containing at least one database instance (applies to multiple instance installations only). Application Security, Inc. 223

225 Working with a SQL Server Cluster (Sensors installed on a single instance) This topic explains how to install/uninstall Sensors on a single instance of a SQL Server Cluster. What you will find in this help topic: SQL Server Cluster diagram (Sensors installed on a single instance) Installing Sensors in a SQL Server Cluster (single instance) Upgrading Sensors in a SQL Server Cluster (Sensors installed on a single instance) Uninstalling Sensors in a SQL Server Cluster (Sensors installed on a single instance). SQL SERVER CLUSTER DIAGRAM (SENSORS INSTALLED ON A SINGLE INSTANCE) The following diagram displays a SQL Server Cluster setup, where the Sensor files are installed on a shared drive. The DbProtect Sensor service is installed on each Node. FIGURE: SQL Server Cluster diagram (Sensors installed on a single instance) Application Security, Inc. 224

226 INSTALLING SENSORS IN A SQL SERVER CLUSTER (SINGLE INSTANCE) To install a single instance of Sensors in a SQL Server Cluster: 1. Open the Cluster Administrator and determine which Node is Active, i.e., the owner of the SQL Server Cluster Resource. 2. Log in to the Active Node. 3. Install a Sensor on the shared drive (X: X:); for more information, see Installing, Starting/Stopping, and Reconfiguring the Sensors. Note: When installing a host-based Sensor for SQL Server, you must install the Sensor on your shared drive, not in the default location. Also, when initializing a host-based Sensor for SQL Server, note whether you select Existing domain user or the Local System Account. You will need this information in Step 7, below. The Sensor files are copied to your shared drive (X: X:), and a service called DbProtect Sensor is created, pointing to the DbProtect.exe file on your shared drive (X: X:). 4. Since the DbProtect Sensor service is only installed on the Active Node (Node A) A at this point, you must also install the service on the other Node (Node B) B in your Cluster. Use the Cluster Administrator to change ownership to the Node where you need to install the DbProtect Sensor service (i.e., Node B). B 5. Log in to the new Active Node (e.g., Node B), B i.e., the owner of the resources. Make sure it has access to the shared drive (X: X:). 6. Open a command prompt and go to the bin directory where you installed the Sensor in Step Run the following command: appradar_sensor -i -S "user" -P "password" where "user" and "password" specify the logon account used to run the service. Note: Examples: The local system account does not require a password. appradar_sensor -i -S "".\LocalSystem or appradar_sensor -i -S "DomainName\DomainUser" -P "password" 8. Repeat Steps 4-7 for other Nodes in the Cluster. Application Security, Inc. 225

227 9. From the Active Node, open the Cluster Administrator and locate the Group with the shared drive and SQL Server resources. 10.Choose File > New > Resource to display the New Resource dialog box. 11.Add a new Resource to the same Group to which the shared drive (X: X:) belongs. Enter a name in the Name field, e.g., DbProtect Under Resource Type, select Generic Service. Select a Group type from the drop-down. Note: The correct Group may (or may not) already display in the Group field as the default selection; it depends how you configured the Cluster and where you installed the Sensor. Regardless, you must select the Group that contains the shared drive (X:) Optionally, you can enter a Description. Do not check Run this Resource in a separate Resource monitor. Click the Next button. The Possible Owners dialog box displays. 12.Verify all your Nodes in the Cluster display in the Possible owners: box. All your Nodes must display in this list. If necessary, add a possible owner from the Available Nodes list. Click the Next button to display the Dependencies dialog box. 13.Move the shared drive (X: X:), the SQL Server, and the virtual IP address from the Available resources: box to the Resource dependencies: box. Click the Next button to display the Generic Service Parameters dialog box. 14.Specify the following parameters: In the Service name: field enter: DbProtect_Sensor Leave the Start parameters: field blank. Do not check Use Network Name for computer name. Click the Next button to display the Registry Replication dialog box. 15.Click the Finish button. The Resource (DbProtect DbProtect, which you named in Step 11, above) displays in the Resource Group in the Cluster Administrator. The Resource is initially Offline (in the State column). 16.Right click your new Resource (DbProtect) and select Bring Online to bring your new Resource online. Application Security, Inc. 226

228 17.To prevent the DbProtect Resource from causing an entire group to failover, do the following: Open the Cluster Administrator. Right click the Resource. Select Properties. Select the Advanced tab. Uncheck Affect The Group. When the DbProtect Resource fails over, it does not impact the other resources in that group. On the other hand, when other resources in the group failover (e.g., the disk or SQL Server), the DbProtect Resource also fails over because other Resources in the group still have the Affect The Group option enabled. Note: For more information on how to register a Sensor, and on how to configure and deploy a Sensor, see the DbProtect User s Guide. UPGRADING SENSORS IN A SQL SERVER CLUSTER (SENSORS INSTALLED ON A SINGLE INSTANCE) Note: This topic only applies to single instance SQL Server Cluster installations. For multiple instance installations, see the DbProtect Administrator s Guide. To upgrade Sensors in a Cluster: 1. Go to the Node where you initially ran the installer in Installing Sensors in a SQL Server Cluster (single instance), and ensure this is the Active Node (i.e., Node A). 2. Take the DbProtect Resource offline. You can: Open the Cluster Administrator. Right click the DbProtect Resource. Select Take Offline. Or, you can: Open the Cluster Administrator. Highlight the DbProtect Resource. Choose File > Take Offline. 3. Run the Sensor installer from Node A (it should automatically detect that it needs to perform an upgrade install rather than a new install). You can also perform an ASAP Update from Node A; for more information on ASAP Updates, see the DbProtect Administrator s Guide. Application Security, Inc. 227

229 4. Bring the DbProtect Resource back online. You can: Open the Cluster Administrator. Right click the DbProtect Resource. Select Bring Online. Or, you can: Open the Cluster Administrator. Highlight the DbProtect Resource. Choose File > Bring Online. UNINSTALLING SENSORS IN A SQL SERVER CLUSTER (SENSORS INSTALLED ON A SINGLE INSTANCE) Note: For multiple instance installations, you must uninstall the Sensor on each Node. For more information, see Chapter 6 - Uninstalling the DbProtect Components. Uninstalling DbProtect in a SQL Server Cluster is somewhat more complex than a standard DbProtect uninstallation. Note: You must perform the uninstallation steps in the order specified, or you will not have a clean slate. There are two prerequisites: Node B must start out as the Active Node; if it is not already the Active Node, simulate a failover to create this condition. If you registered/configured the clustered Sensor via the UI, you should first unregister it via the UI prior to uninstallation; for more information, see the DbProtect User s Guide. To uninstall DbProtect in a SQL Server Cluster: 1. Take the DbProtect Resource offline. Steps 9-16 in Installing Sensors in a SQL Server Cluster (single instance) explain how to create a Resource. You must take this Resource offline prior to uninstallation. To take the Resource offline: Open the Cluster Administrator. Right click the Resource. Select Take Offline. Or, you can: Open the Cluster Administrator. Highlight the Resource. Choose File > Take Offline. Application Security, Inc. 228

230 2. With the secondary Node (i.e., Node B) the Active Node, delete the DbProtect Sensor service from this Node. Open a command prompt on the Node where you installed the Sensor manually (i.e., Node B). Go to the bin directory of the shared drive where you installed the Sensor in Step 3 of Installing Sensors in a SQL Server Cluster (single instance), e.g., c:\<sensor installation directory>\bin. Run the following command: appradar_sensor -u. Press <ENTER>. The DbProtect Sensor service is uninstalled on the secondary Node. 3. Delete the DbProtect Resource via the Cluster Administrator. To delete the DbProtect Resource: Open the Cluster Administrator. Right click the Resource. Select Delete. Or, you can: Open the Cluster Administrator. Highlight the Resource. Choose File > Delete. 4. Make Node A your Active Node. Open the Cluster Administrator. Right click the SQL Server Resource. Select Initiate Failure. Or, you can: Note: Open the Cluster Administrator. Highlight the Resource. Choose File > Initiate Failure. You must perform these steps four times before the simulated failover actually occurs. 5. Uninstall the Sensor from Node A. Go to the Node where you installed the Sensor (i.e., Node A, which is now the Active Node). Uninstall the Sensor; for more information, see Chapter 6 - Uninstalling the DbProtect Components. Application Security, Inc. 229

231 6. At this point, the DbProtect Sensor service should no longer be running or present, and the SQL Server Cluster should be both online and functioning normally. Working with a SQL Server Cluster (Sensors installed on multiple instances) This topic explains how to install/uninstall Sensors on a Cluster consisting of multiple virtual servers, each with at least one instance of SQL Server. It consists of the following sub-topics: SQL Server Cluster diagram (Sensors installed on multiple instances) Installing DbProtect in a SQL Server Cluster (Sensors installed on multiple instances) Upgrading DbProtect in a Cluster (Sensors installed on multiple instances) Uninstalling DbProtect in a SQL Server Cluster (Sensors installed on multiple instances). Application Security, Inc. 230

232 SQL SERVER CLUSTER DIAGRAM (SENSORS INSTALLED ON MULTIPLE INSTANCES) The following diagram displays a SQL Server Cluster setup, where the Sensor is installed on multiple Cluster Nodes. FIGURE: SQL Server Cluster diagram (Sensors installed on multiple instances) Application Security, Inc. 231

233 INSTALLING DBPROTECT IN A SQL SERVER CLUSTER (SENSORS INSTALLED ON MULTIPLE INSTANCES) DbProtect allows you to build multiple database instances within one (or multiple) virtual servers. To install Sensors on a Cluster consisting of multiple virtual servers, each with at least one instance of SQL Server: 1. Install a Sensor on each Node in your SQL Server Cluster. For more information, see the Installing, Starting/Stopping, and Reconfiguring the Sensors. 2. In a multiple instance installation, you must register each Sensor using the Node's hostname or IP address, not the virtual host or IP address. Example: Using the diagram in SQL Server Cluster diagram (Sensors installed on a single instance) as an example, register one Sensor as IP address (Node A), and the other Sensor as IP address (Node B). B For more information on registering a Sensor, see Registering a Sensor in the DbProtect User s Guide. 3. When you install multiple instances of DbProtect in a SQL Server Cluster, you must configure and deploy each Sensor. Note: For more information on configuring a Sensor, see the DbProtect User s Guide. DbProtect does not allow you to use the same database instance alias twice, so you must use aliases like: Note: MySQLServerInstance1_Node1 and MySQLServerInstance2_Node1 on the first Sensor MySQLServerInstance1_Node2 and MySQLServerInstance2_Node2 on the second Sensor And so on. Alerts will appear as if they come from a different database instance if your primary Node fails over to the secondary Node. UPGRADING DBPROTECT IN A CLUSTER (SENSORS INSTALLED ON MULTIPLE INSTANCES) For more information on multiple instance upgrades, see the DbProtect Administrator s Guide. UNINSTALLING DBPROTECT IN A SQL SERVER CLUSTER (SENSORS INSTALLED ON MULTIPLE INSTANCES) For multiple instance installations, you must uninstall the Sensor on each Node. For more information, see Uninstalling and Unregistering a Sensor. Application Security, Inc. 232

234 Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC Oracle Real Application Clusters (RAC) allows multiple computers to run Oracle relational database management system (RDBMS) software simultaneously while accessing a single database, thus providing a clustered database. In a non-rac Oracle database, by contrast, a single instance accesses a single database. In order to configure a host-based Sensor to monitor databases on an Oracle RAC, do the following: 1. Install a host-based Sensor for Oracle on each node in your Oracle RAC. For more information, go to the appropriate operating system-dependent topic: Host-based Sensor for Oracle (on Solaris) - installation steps Host-based Sensor for Oracle (on AIX) - installation steps Host-based Sensor for Oracle (on HP-UX) - installation steps Host-based Sensor for Oracle (on Red Hat Enterprise Linux) - installation steps Host-based Sensor for Oracle (on Windows) - installation steps. 2. In the DbProtect Console, register each host-based Sensor for Oracle you installed in Step 1. If you installed your host-based Sensor for Oracle on: Windows, see Configuring a host-based Sensor to monitor Oracle SIDs and services and deploying the configuration information (when Sensor is installed on Windows) in the DbProtect User s Guide for more information any supported *nix operating system (i.e., Solaris, AIX, HP-UX, or Red Hat Enterprise Linux), see Configuring a host-based Sensor to monitor Oracle SIDs and services and deploying the configuration information (when Sensor is installed on a *nix-based operating system) in the DbProtect User s Guide for more information. Application Security, Inc. 233

235 3. In the DbProtect Console, configure an instance for each host-based Sensor for Oracle you registered in Step 2. Make sure your Instance Alias is: unique for each registered host-based Sensor for Oracle is easily identifiable for the database you are monitoring easily identifies the node where the Sensor is installed (e.g., Oracle RAC Node 1, Oracle RAC Node 2, 2 etc.). If you installed your host-based Sensor for Oracle on: Windows, see Configuring a host-based Sensor to monitor Oracle SIDs and services and deploying the configuration information (when Sensor is installed on Windows) in the DbProtect User s Guide for more information any supported *nix operating system (i.e., Solaris, AIX, HP-UX, or Red Hat Enterprise Linux), see Configuring a host-based Sensor to monitor Oracle SIDs and services and deploying the configuration information (when Sensor is installed on a *nix-based operating system) in the DbProtect User s Guide for more information. 4. When configuring each instance, also ensure you deploy the exact same Policy for each host-based Sensor for Oracle (otherwise, you may get inconsistent results for the Alerts you are expecting to see). Again, if you installed your host-based Sensor for Oracle on: Windows, see Configuring a host-based Sensor to monitor Oracle SIDs and services and deploying the configuration information (when Sensor is installed on Windows) in the DbProtect User s Guide for more information any supported *nix operating system (i.e., Solaris, AIX, HP-UX, or Red Hat Enterprise Linux), see Configuring a host-based Sensor to monitor Oracle SIDs and services and deploying the configuration information (when Sensor is installed on a *nix-based operating system) in the DbProtect User s Guide for more information. Application Security, Inc. 234

236 Appendix C: Modifying the Sensor Listener Port Number Host-based and network-based Sensors listen on port for HTTPS traffic from DbProtect (e.g., reconfiguration or status requests) unless you configure them differently during installation, or you change the port number using a utility option of the appradar_sensor executable. As explained in Appendix P: Monitoring Multiple Instances on a DB2 Server, one reason you may want to change the port number used by DbProtect Sensor is because you want to monitor multiple Sensor instances on server. To do so, you must install one host-based Sensor for DB2 for each instance you want to monitor. You must then modify each host-based Sensor for DB2 installation and to assign a unique port number. To modify a Sensor listen port number: 1. Open a command prompt and go to the directory where you installed the Sensor, e.g., <Sensor installation directory>. 2. Stop the DbProtect Sensor by running one of the following commands: bin\appradar_sensor k (on Microsoft Windows), or util/appradar_stop (on any *nix platform) Change the port and optionally the logging level by running the following command: bin/appradar_sensor z p <port number> -m <sensor type> - L <logging level> Substitute the new port number for <port Number> and host-based or network-based for <sensor type>: e.g., bin/appradar_sensor z p m host-based -L info Run the command appradar_sensor h to see a full list of options, arguments, and defaults. 3. Re-start the Sensor by running the command bin\appradar_sensor s (on Microsoft Windows), or util/appradar_start (on any *nix platform) Application Security, Inc. 235

237 Appendix D: Network Ports Used by DbProtect Components of DbProtect communicate via Internet Protocol (IP) connections. To help you configure your firewall properly, the following table lists each component and describes how they each use the network. Application Application Protocol Type Port Encrypted User (GUI)- Configurable? Direction Sensors All Sensors SOAP TCP Over SSL Yes Inbound/ Listen Host-based Oracle with DDL Triggers Installed Internal UDP 7777 No Inbound/ Listen (local connections only) Scan Engines All Scan Engines SOAP TCP Over SSL At install time Inbound/ Listen SQL 1433 No No Inbound/ Listen (local connections only) Console All Consoles HTTP TCP Yes Inbound/ Listen Tomcat Java 32XXX No No Inbound/ Listen (local connections only) SQL 1433 Outbound/ Console back-end database Application Security, Inc. 236

238 Application Application Protocol Type Port Encrypted User (GUI)- Configurable? Direction Message Collector All Message Collectors HTTP TCP Over SSL No, ARC + 1 Inbound/ Listen DbProtect Analytics Tomcat Java 32XXX No No Inbound/ Listen (local connections only) All DbProtect Analytics SOAP TCP No No Inbound/ Listen (local connections only) Application Security, Inc. 237

239 Appendix E: Working with Oracle DDL Triggers (for Host- Based Sensors for Oracle Installed on *nix Platforms Only) DbProtect relies on the use of Oracle DDL triggers to capture traffic that does not pass through Oracle's SGA memory structures. This appendix explains how to upgrade the Oracle DDL triggers on your host-based Sensors for Oracle (on *nix platforms only) from a prior Sensor release. It also explains how to specify a schema (other than the default SYS) for DDL trigger execution. This appendix consists of the following topics: Upgrading the Oracle DDL Triggers for Your Host-Based Sensor for Oracle (From a Prior Sensor Release) Specifying a Schema (Other Than the Default SYS) For DDL Trigger Execution. Upgrading the Oracle DDL Triggers for Your Host-Based Sensor for Oracle (From a Prior Sensor Release) To upgrade the Oracle DDL triggers from a prior host-based Sensor for Oracle release (on *nix platforms only). 1. Find the Sensor installation subdirectory util (typically <Sensor installation directory>/util). 2. Run sqlplus from this location and login as sysdba. Remember to set the appropriate ORACLE_HOME and ORACLE_SID values for your environment. If this Sensor is monitoring multiple SIDs, then you will need to perform this sequence multiple times changing the environment variables each time to point to the next SID. Application Security, Inc. 238

240 3. Run the if you are upgrading from Sensor version 3.10 or prior), and enter the schema name for the DDL trigger (default: SYS) to remove, update, or disable DDL triggers. If you specified a schema in the prior release (other than the default SYS) for DDL trigger execution, supply that schema to these scripts. Enter the schema name for the trigger (default is SYS) SYS Specifying a Schema (Other Than the Default SYS) For DDL Trigger Execution To configure the DDL triggers for your host-based Sensors for Oracle (on *nix platforms only) to use a schema other than the default SYS, for the following: 1. Find the Sensor installation subdirectory util (typically <Sensor installation directory>/util). 2. Run sqlplus from this location and login as sysdba. Remember to set the appropriate ORACLE_HOME and ORACLE_SID values for your environment. If this Sensor is monitoring multiple SIDs and you wish to change the user/ schema for more than one SID, then you need to perform this sequence multiple times changing the environment variables each time to point to the next SID where you want to change the user/schema from the default SYS. 3. Run the to grant required permissions to a user/ schema (if your DDL trigger resides in a schema other than the default SYS). To do so: run the grant the required DDL trigger permissions to another user by entering the user/schema name. Important: You do not need to run this command if you have wish to use SYS as the schema where you want to execute DDL triggers. Application Security, Inc. 239

241 Example: Below is example of how to use the to grant correct permissions to a non-sys user/schema named Enter a non-sys schema name for the trigger (no default) ABC 4. Re-start your Sensor; for more information, see the DbProtect Administrator's Guide. 5. Use the DbProtect Console to configure your host-based Sensor for Oracle (on *nix platforms only) to specify a schema (other than the default SYS) for DDL trigger execution. Specifically, enter the name of the schema where the DDL trigger resides in the DDL Trigger Name Schema field of the Sensor Manager page for each SID you want to have an user/schema other than the default SYS. For more information, see Configuring a host-based Sensor to monitor Oracle SIDs and services and deploying the configuration information (when Sensor is installed on a *nix-based operating system) in the DbProtect User's Guide. 6. Deploy the Sensor configuration. Application Security, Inc. 240

242 Appendix F: Modifying the "Log On As" User for the DbProtect Sensor and DbProtect Message Collector Services In this appendix: What is the "Log On As" user? Modifying the Windows Authentication LocalSystem account. What is the "Log On As" user? When you install DbProtect (see Chapter 5 - Installing the DbProtect Components, Logging Into the DbProtect Console, and DbProtect Console Login Troubleshooting), the Database Runtime Configuration page allows you to configure your DbProtect runtime user account. This is the "log on as" user, i.e., the user whose privileges are used to log into and use DbProtect. You can connect to your custom SQL Server instance using SQL Authentication or Windows Authentication. The latter uses the LocalSystem account as the run-as user for the services installed (i.e., DbProtect and DbProtect Message Collector). This chapter explains how to modify the Windows Authentication LocalSystem account if you want. Modifying the Windows Authentication LocalSystem account To modify the Windows Authentication LocalSystem account: 1. Choose Start > Control Panel to display the Control Panel. 2. Double click the Administrative Tools icon. 3. Double click the Services icon to display the Services dialog box. 4. Highlight a service (e.g., DbProtect Message Collector) to display the DbProtect Message Collector Properties pop-up. 5. Click the Log On tab to display the Log on as: portion of the DbProtect Message Collector Properties pop-up displays. 6. Select This account: and enter the: new "log on as" user s domain name\user name (or click the Browse button to display the Select User pop-up and locate a valid user) \ Application Security, Inc. 241

243 password for the specified user. 7. Click the Apply button. A message informs you the revised "log on as" account change will not take effect until you reboot your computer. Click the OK button. Application Security, Inc. 242

244 Appendix G: DB2 Administrative Client Driver Installation To download and install DB2 client drivers: 1. Do one of the following to download and install a DB2 client driver: Contact your system administrator, who can provide the DB2 installation CD containing the client drivers. Visit the IBM website ( drivers.html) and search for an appropriate driver. As a final alternative, you can download an evaluation version of DB2 from the IBM website, and install the client drivers which come with the installation package. For more information, see db2/. 2. Locate the downloaded client driver on your hard drive (a.zip file), and install using the wizard. Application Security, Inc. 243

245 Appendix H: DbProtect Log Files This appendix explains: DbProtect Log Files Sensor Log Files Scan Engine Log Files. DbProtect Log Files DbProtect log files come in two categories: Normal Operations Console Log Files DbProtect Installation and Upgrade Log Files. NORMAL OPERATIONS CONSOLE LOG FILES Log file: Description: Location: dbprotect.log gui_wrapper.log This is the main application log that is written to during system usage. Log entries are in the following format: Sat 01 Jan 23:59:59 [ThreadIdentifer] LEVEL Component Log Message where the date and time are presented first, followed by the DbProtect thread identifier, the level of the log message (which will be either INFO, WARN or ERROR), the DbProtect Audit and Threat Management component and then the log message. Each log message entry can span multiple lines. Log for the component that manages the service life cycle of the DbProtect service. \Program Files\ AppSecInc\ DbProtect\GUI\ logs\ Application Security, Inc. 244

246 Log file: Description: Location: catalina*.log messagecollector _wrapper.log messagecollector.log Application logs for the Tomcat engine used by DbProtect. Log for the component that manages the service life cycle of the Message Collector service. This is a log file for DbProtect. It tracks the error entries for the Alert-collecting component of DbProtect. \Program Files\AppSecInc\ DbProtect\GUI\ tomcat\logs\ and \Program Files\AppSecInc\ DbProtect\Message Collector\tomcat\ logs\ \Program Files\ AppSecInc\ DbProtect\Message Collector\logs\ Application Security, Inc. 245

247 DBPROTECT INSTALLATION AND UPGRADE LOG FILES The following DbProtect log files are related to installation and upgrade. Once installation has completed successfully, you can ignore these files (or you can safely remove them). Bootstrapper_ log BackendInstaller_install_silent.log DBC_install.log LegacyUninstaller_install.log LegacyUninstaller_uninstall.log DbProtect_install.log MessageCollector_install.log DBC-uninstall-1.0.log DBC-uninstall-1.1.log DBC-uninstall-fix-1.1.log DBC-uninstall-fix-1.2.log Sensor Log Files The section of the appendix explains: Archiving Normal Operations Sensor Log Files Replay Log Files ARCHIVING Log files automatically archive themselves when they reach a certain size, e.g. 100 MB. For example, when a log file named appsensor.log reaches its limit, the file is renamed appsensor.log.1 and a new appsensor.log file is started. When appsensor.log again reaches its limit, appsensor.log.1 is renamed appsensor.log.2, appsensor.log is renamed appsensor.log.1, a new appsensor.log is started, and so on. Each type of log listed below has a different file size limit at which archiving occurs, and each has a different maximum number of archives. Application Security, Inc. 246

248 NORMAL OPERATIONS SENSOR LOG FILES Log file: Description: Location: appsensor.log sga-segments.log Sensor application log (created during normal operations). This file generally contains warnings and errors, and at the default Warning level the file size grows slowly. However, you can configure this file to include also debug messages for troubleshooting, if the AppSecInc Support Team asks you to set the level to Debug or Development. In this case, the file size grows rapidly. Note: This file rolls over at 100MB and does so a maximum of three times. A log file created by host-based Sensors for Oracle installed on *nix platforms (monitoring one or more Oracle instances). This log file describes shared memory segments in use by Oracle. The host-based Sensor requires this information so it may attach to those same shared memory segments in order to read database traffic. It extracts shared memory information by using an Oracle function which writes SGA information to a trace file. This occurs only when you start or re-configure the Sensor. \Program Files\ AppSecInc\Sensor \logs\ <install directory>/ ASIappradar/ sensor/logs REPLAY LOG FILES Also in the logs directory are Sensor log files related to store-&-forward, i.e., AppSecInc s method of storing Alerts temporarily in case DbProtect becomes unavailable. These are more commonly known as the replay log files. They come in two forms: *.replay.log, which contains Alerts to be forwarded to DbProtect when it becomes available *.replay.log.bookmark, which is a bookmark pointing to the replay log indicating where forwarding left off the last time it ran. If DbProtect becomes unavailable, these files ensure your Alerts will continue to be logged. They store Alerts in binary form which are replayed to DbProtect when it is back online. Application Security, Inc. 247

249 The growth rate of the Alert log files depends on Alert rate and size. An average replay log grows at rate of approximately 2k/second -- but only when the Sensor cannot communicate with DbProtect. The number of and size of Alert log files depends on how many Alerts per second are being fired and how long the Message Collector component of DbProtect has been down. Once it s back online, the replay logs will not shrink in size, but rather they will disappear one file at a time. Replay logs roll over at 500MB and continue to do so every 500MB until DbProtect becomes available. SENSOR INSTALLATION AND UPGRADE LOG FILE The Sensor configuration.log file is related to installation and upgrade. Once installation is completed, you can ignore these files (or you can remove them safely). Scan Engine Log Files Scan Engine log files are classified in two categories: Scan Engine Installation and Update Log Files Scan Engine Application Log Files. SCAN ENGINE INSTALLATION AND UPDATE LOG FILES The Scan Engine installation and update log files -- for versions 5.5 and above only -- are located in the <%Temp%> directory, e.g., C:\Documents and Settings\<user>\Local Settings\Temp Hint: You can run the command echo %TEMP% to determine the name and location of your Temp directory. The names of the installation and update log files are: ScanEngineInstall.log ScanEngine_{GUID}.log (e.g., ScanEngine_{D164A132-DE80-4EE7-8EB1- BAF1DC605B6A}.log). SCAN ENGINE APPLICATION LOG FILES Scan Engines of all supported versions include application log files. The locations of the application log files differ, depending on your Scan Engine version. Note: For more information on supported Scan Engine versions, see DbProtect Version Compatibility Matrix, and Determining the Current Version of Installed DbProtect Applications. Application Security, Inc. 248

250 The Scan Engine application log files are in located in the following supported version-specific locations: Hint: For Scan Engine version 5.5 and above, the Scan Engine application log files are located in the following folder: <%UserProfile%>\<%Local Application Data%>\AppSecInc\AppDetective\logs\ You can run the command echo %USERPROFILE% to determine the name and location of your USERPROFILE directory. The <%Local Application Data%> varies on different Windows versions. For example, on Windows 2000/2003: C:\Documents and Settings\<UserName>\Local Settings\Application Data\AppSecInc\AppDetective\logs\. On Windows 2008: C:\Users\<UserName>\AppData\Local\AppSecInc\AppDetective\logs\ Note: If the Scan Engine runs as a LocalSystem account, <UserName> is Default User on Windows 2003 and Default on Windows For supported Scan Engines before version 5.5, the Scan Engine application log files are located in one of the following locations (depending on your Scan Engine version): C:\Program Files\AppSecInc\ScanEngine\logs or C:\Program Files\AppSecInc\adse\logs The name of the Scan Engine application log file is: adscanengine.exe.<pid>.log (e.g., adscanengine.exe.1508.log). Application Security, Inc. 249

251 Appendix I: Using App DSN, the Repair ODBC Utility App DNN is a built-in Repair OBDC (Open Database Connectivity) utility that allows you to synch the database where your Scan Engine results are stored with the DbProtect Data Repository component. App DNN also allows you to change the type of authentication DbProtect Vulnerability Management. uses to authenticate to the database server (i.e., from Windows authentication to SQL Server authentication -- or vice-versa). To use App DSN: 1. Choose Start > Programs > AppSecInc > AppDetective Scan Engine > AppDSN to display the App DSN utility. FIGURE: App DSN utility Use the Server drop-down to select the SQL Server 2005 instance where the Scan Engine stores its results, or enter the SQL Server 2005 instance name. Important: This must be the same database DbProtect Vulnerability Management uses. Hint: Click the Locate instances... button to search for/display all SQL Server instances on your network. Application Security, Inc. 250

252 2. Select to authenticate to the database server using: Windows Authentication (strongly recommended) or SQL Server Authentication. If you select: Windows Authentication, then the DbProtect Scan Engine service uses the login/password credentials supplied in the Sensor installation section of the DbProtect. If you want to change or verify these values, you must run services.msc SQL Server Authentication, then you must enter a SQL Server authentication Login Name: and Password: 3. Click the OK button. The Repair ODBC utility changes the database server the Scan Engine uses to store its results, and/or changes the type of authentication DbProtect Vulnerability Management uses to authenticate to the database server. Application Security, Inc. 251

253 Appendix J: Configuring Your Oracle Audit Trail in Order to Monitor Logins You can configure your Oracle audit trail settings in order for your host-based Sensor for Oracle to monitor logins. Specifically, the following DbProtect Rules can monitor failed and successful logins: Login attempt successful Failed Login Password guessing Password scripted attack. To configure your Oracle audit trail settings so your host-based Sensor for Oracle can monitor logins, you must set the Oracle audit trail of the database to db so that it logs the logins (failed and successful) to the dba_audit_session table. Note: Because this step is optional, you only need to complete these steps for SIDs that you want to monitor for logins. You should complete these steps for each SID that resides on a server, assuming the host-based Sensor is going to monitor these SIDs. You can complete the following steps for each Oracle database instance that your host-based Sensor for Oracle is configured to monitor (assuming you want to monitor logins). To configure your host-oracle audit trail to enable your host-based Sensor for Oracle to monitor logins: 1. Using an Oracle client such as sqlplus, set the audit trail to db: alter system set audit_trail='db' scope=spfile; shutdown startup 2. Enable session auditing: audit session; Note: If your host-based Sensor for Oracle is already running, you need to restart it; for more information, see the DbProtect Administrator s Guide. Application Security, Inc. 252

254 Appendix K: Required Client Drivers for Audits In this appendix: DB2 client driver installation Lotus Notes client driver installation Sybase client/client driver/.net driver installation DB2 Connect installation MySQL client driver installation. DB2 client driver installation To perform an Audit on a DB2 server, you must install the DB2 administrative client. If you do not have these drivers and privileges, DbProtect Vulnerability Management cannot access tables that are critical for information gathering. If you are already a DB2 user, and you have the administrative client installed, you do not need to reinstall the client drivers. You only need your login name and password. In this help topic: Supported and non-supported client configurations Downloading and installing the DB2 client drivers. SUPPORTED AND NON-SUPPORTED CLIENT CONFIGURATIONS DB2 version 7 client local connections to a DB2 version 8 server are not supported. For example, you cannot use a DB2 version 7 client to catalog a DB2 version 8 instance on the same machine as a local node. A detailed matrix on the DB2 website describes the standard and gateway configuration support for DB2 clients. For more information, see the following: com.ibm.db2.udb.doc/start/r htm. DOWNLOADING AND INSTALLING THE DB2 CLIENT DRIVERS To download and install DB2 client drivers: 1. The client drivers needed are Administration. Do one of the following: Contact your system administrator, who can provide the DB2 installation CD containing the client drivers. Visit the IBM website ( all_download_drivers.html) and search for an appropriate driver. Application Security, Inc. 253

255 As a final alternative, you can download an evaluation version of DB2 from the IBM website, and install the client drivers which come with the installation package. For more information, see db2/. 2. Locate the downloaded client driver on your hard drive (a.zip file). 3. Use a utility like Winzip to unzip the contents into a temporary install directory. 4. Once the files are extracted into the temporary install directory, double click the setup file (setup.exe) to begin the installation process. 5. Click the Next button to choose the DB2 Administration client. 6. Choose Typical. 7. Click the Next button. 8. Choose to install the client in the default location. 9. Click the Next button. A dialog box informs you if there is enough information to complete the installation. 10.Click the Next button. 11.Click the Finish button. 12.Reboot your system. The DB2 client drivers are now installed. You can now perform Audits on an DB2 server. Lotus Notes client driver installation To perform an Audit of a Lotus Notes-based Domino Mail Server, you must install the Lotus Notes client drivers. If you are already a Lotus Notes user, you do not need to reinstall the client drivers. You only need to find your.id file, typically located in your C:\Lotus\Notes\Data folder. You must also know your password. In this help topic: Downloading and installing Lotus Notes client software Starting Lotus Notes for the first time. Application Security, Inc. 254

256 DOWNLOADING AND INSTALLING LOTUS NOTES CLIENT SOFTWARE To download and install Lotus Notes client software: 1. Open in your browser. 2. Click the Downloads link. 3. Click the most appropriate Lotus Notes client software download link. Note: You must register to access the download site. 4. Download the Lotus Notes client software setup file to a convenient location (e.g., C:\temp). 5. Double click the setup file you downloaded from the Lotus website to display the welcome dialog box. 6. Click the Next button to display the license dialog box. 7. Read the License Agreement. 8. If you consent to the License Agreement, press the Yes button to display the name and company dialog box. 9. Enter your name and company name. 10.Click the Next button to display the default installation directory dialog box. 11.Do not change the default installation directories. 12.Click the Next button to display the setup dialog box. 13.Select Typical Setup. 14.Click the Next button to display the Lotus Notes program icons dialog box. 15.Specify the folder where you want to install the Lotus Notes program icons. 16.Lotus Notes is installed. STARTING LOTUS NOTES FOR THE FIRST TIME Your Domino administrator must set up a valid Lotus Notes account for you. He/she can provide you with a password as well as an.id file which you must copy to your C:\Lotus\Notes\Data folder. Contact your Domino administrator if you are unsure about the proper responses to give in the following procedure. Application Security, Inc. 255

257 To start Lotus Notes for the first time: 1. Choose Start > Lotus Applications > Lotus Notes to display the set up connections dialog box. 2. Click the Next button to display the Connect to Domino Server dialog box. 3. Click the Next button. 4. Choose your desired method of connecting to the server. If you are in an office, select Connect through a LAN. 5. Click the Next button to display the Server dialog box. 6. Enter your server name. (Ask your Domino administrator if you are unsure.) 7. Click the Next button to display the Browse for Your ID File/Lotus Notes Name dialog box. 8. Browse for your.id file, or use your Lotus Notes name. (Ask your Domino administrator if you are unsure.) 9. Click the Next button. 10.Setup is complete. Note: You may or may not want to set up your , news, directory server, and proxy servers. This is usually done by your Domino administrator. At this point, you have provided enough information to run DbProtect Vulnerability Management for Lotus Domino. Sybase client/ client driver/.net driver installation To perform an Audit on a Sybase ASE dataserver, you must have the following installed on your workstation: the Sybase client a Sybase ASE ODBC driver a client-appropriate ADO.NET driver. DbProtect uses both the Sybase ASE ODBC and ADO.NET drivers to access your Sybase dataserver. For more information on supported Sybase client versions, see Chapter 3 - Minimum System Requirements. Note: An issue exists in the current Sybase /3 ODBC driver that results in a DbProtect connection failure when a Sybase /3 ODBC driver is installed. This is a known issue with the Sybase ODBC driver, and not with DbProtect. The current suggested workaround is to use an older Sybase ODBC driver, even if you have Sybase installed (Sybase 15, for example). Application Security, Inc. 256

258 This topic consists of the following sub-topics: Checking If You Have the Proper Sybase ASE ODBC Drivers Installed Checking If You Have the ADO.NET Driver Installed Downloading and Installing Sybase ASE ODBC Drivers and the Sybase Client- Appropriate.NET Driver. CHECKING IF YOU HAVE THE PROPER SYBASE ASE ODBC DRIVERS INSTALLED To check if you have the proper Sybase ASE ODBC driver installed: 1. Choose Start > Settings > Control Panel. 2. Double click the Administrative Tools icon. 3. Double click the Data Sources (ODBC) icon. 4. Click the Drivers tab. 5. Scroll down and check if you have either the Sybase ASE ODBC Driver or the Adaptive Server Enterprise ODBC Driver installed (in the Name column) 6. If you: have the drivers on your machine, you are ready to use DbProtect s security Audit feature (assuming you have the proper ADO.NET driver installed, as explained in Checking If You Have the ADO.NET Driver Installed) do not have the driver installed, go to Downloading and Installing Sybase ASE ODBC Drivers and the Sybase Client-Appropriate.NET Driver. CHECKING IF YOU HAVE THE ADO.NET DRIVER INSTALLED To check if you have the Sybase ADO.NET driver installed: 1. For Sybase 12.5.x and 15.0.x, check the [install dir]\ado.net\dll directory for the dll files listed in Step 3-4 of Downloading and Installing Sybase ASE ODBC Drivers and the Sybase Client-Appropriate.NET Driver, respectively. For Sybase 15.5, check the [install dir]\dataaccess\adonet\dll directory for the dll files listed in Step 5 of Downloading and Installing Sybase ASE ODBC Drivers and the Sybase Client-Appropriate.NET Driver. 2. If the dlls are there, then the ADO.NET driver is installed and can be used after you copy the dlls to [Common Files] folder (as explained in Downloading and Installing Sybase ASE ODBC Drivers and the Sybase Client-Appropriate.NET Driver). Application Security, Inc. 257

259 3. If the dlls are not present, then you must install the ADO.NET driver before you can Audit a Sybase database. In Sybase 12.5.x and 15.0.x the option to install the ADO.NET driver is not selected by default. Therefore you must perform a custom installation and select the driver manually. However, in Sybase 15.5, the driver is installed by default. Therefore, you do not need to perform a custom installation, but you still must copy the the dlls to [Common Files] folder (as explained in Downloading and Installing Sybase ASE ODBC Drivers and the Sybase Client-Appropriate.NET Driver). 4. If you: have the drivers on your machine, you are ready to use the DbProtect security Audit feature (assuming you have the proper Sybase ASE ODBC drivers installed, as explained in Checking If You Have the Proper Sybase ASE ODBC Drivers Installed) do not have the driver installed, go to Downloading and Installing Sybase ASE ODBC Drivers and the Sybase Client-Appropriate.NET Driver. DOWNLOADING AND INSTALLING SYBASE ASE ODBC DRIVERS AND THE SYBASE CLIENT-APPROPRIATE.NET DRIVER Refer to the Sybase installation CDs shipped with your database installation to obtain the correct Sybase ASE ODBC drivers and ADO.NET drivers. Alternately, you can obtain the Sybase ASE ODBC drivers in the Sybase Software Developer Kit (SDK). This is not a free download. You need to select the following drivers in the custom installation option: Sybase Open Client and ASE Data providers (ODBC,OLEDB,ADODB.NET). For more information, see You can try to download a free copy of the Sybase SDK. However, Application Security, Inc. is not responsible for when (and whether) Sybase is making this available. Application Security, Inc. 258

260 To download and install Sybase ASE ODBC drivers and the Sybase client and a clientappropriate.net driver: 1. Select Custom in your Sybase driver installer and make sure you select ODBC and ADO.NET. 2. To Audit a Sybase database, you must install both the Sybase client and a client-appropriate ADO.NET driver (included in the Sybase client distribution). You must also copy some files to the [Common Files] folder so DbProtect can retrieve them. In all cases, the.net Framework 1.1 must be installed in order for the driver to work; for more information, see Chapter 3 - Minimum System Requirements. For more infomation on installing the Sybase client-appropriate.net driver for: Sybase 12.5, see Step 3 Sybase 15, see Step 4 Sybase 15.5, see Step Sybase The ADO.NET drivers are not installed by default. You must select the ADO.NET drivers manually when you install the 12.5 Sybase client. After the installation, the driver files will be located in the following folder: [client install dir]/ado.net/dll Copy the following files to the <installation folder>/appsecinc/common Files folder: Sybase.Data.AseClient.dll sybdrvado11.dll sybdrvssl.dll 4. Sybase The ADO.NET drivers are not installed by default. You must select the ADO.NET drivers manually when you install the 15.0 Sybase client. After the installation, the driver files will be located in the following folder: [client install dir]/ado.net/dll Copy the following files to the <installation folder>/appsecinc/common Files folder: Sybase.Data.AseClient.dll sybdrvado115.dll sybdrvkrb.dll sybdrvssl.dll sbgse2.dll policy.1.15.sybase.data.aseclient policy.1.15.sybase.data.aseclient.dll Application Security, Inc. 259

261 5. Sybase The ADO.NET drivers are installed by default, including both a.net v.1.1 driver and a.net v.2.0 driver. There is no need to perform a custom installation. DbProtect cannot use the ADO.NET v2.0 driver, even if it s installed. After the installation, the driver files will be located in the following folder: [installdir]\dataaccess\adonet\dll. However, DbProtect cannot read these files in the default location. Therefore, in order to Audit a Sybase database, you must copy the following files to the <installation folder>/appsecinc/common Files folder: policy.1.15.sybase.data.aseclient policy.1.15.sybase.data.aseclient.dll sbgse2.dll Sybase.Data.AseClient.dll sybcsi_certicom_fips26.dll sybcsi_core26.dll sybdrvado115a.dll sybdrvkrb.dll DB2 Connect installation There are certain requirements to Audit IBM DB2 for Mainframe (OS/390 and z/os). You must have DB2 Connect installed on the same computer where the Scan Engine is installed. DbProtect does not support the use of a DB2 Connect in a gateway configuration. All DB2 Connect editions require you to obtain a proper license from IBM. IBM DB2 OS/390 and z/os Audits work when using: Note: DB2 Connect Personal Edition 8.1 or 8.2 (any FP), which you can obtain from: downloadv8.html If you are installing an IBM DB2 v8.x driver, you must install the Microsoft.NET Framework 1.1 on your system first. For more information, see Microsoft.NET Framework 1.1 Prerequisite for IBM DB2 v8.x Client Drivers. DB2 Connect Personal Edition 9.1 (any FP), which you can obtain from: www-1.ibm.com/software/data/db2/udb/support/downloadv9.html DB2 Connect Personal Edition 9.5 (any FP), which you can obtain from: If you have a computer with an IBM Data Server Client installed, you can activate DB2 Connect Personal Edition by registering your DB2 Connect Personal Edition license to that computer. Enterprise editions of DB2 Connect (at the versions listed above or higher) should also work, as long as they are not used in a gateway configuration. Finally, there are certain requirements when accessing a host database at a lower level than the DB2 Connect installation. Application Security, Inc. 260

262 For version 8, 8 refer to: db2luw/v8/topic/com.ibm.db2.udb.doc/conn/r htm For version 9.1, refer to: db2luw/v9/topic/com.ibm.db2.udb.uprun.doc/doc/r htm For version 9.5, refer to: db2luw/v9r5/topic/com.ibm.db2.luw.qb.dbconn.doc/doc/r html MySQL client driver installation To perform an Audit on MySQL, you must have the MySQL ODBC driver installed on your Scan Engine machine. DbProtect uses the MySQL ODBC driver to access your MySQL. For more information on supported versions of MySQL, see Scan Engines - Minimum System Requirements. This topic consists of the following sub-topics: Checking If You Have the Proper MySQL ODBC Drivers Installed Downloading and Installing MySQL ODBC Drivers. CHECKING IF YOU HAVE THE PROPER MYSQL ODBC DRIVERS INSTALLED To check if you have the proper MySQL ODBC driver installed: 1. Choose Start > Settings > Control Panel. 2. Double click the Administrative Tools icon. 3. Double click the Data Sources (ODBC) icon. 4. Click the Drivers tab. 5. Scroll down and check if you have either the MySQL ODBC 3.51 Driver or the MySQL ODBC 5.1 Driver installed (in the Name column). 6. If you: have the drivers on your machine, you are ready to use DbProtect s security Audit feature do not have the driver installed, go to Downloading and Installing MySQL ODBC Drivers. DOWNLOADING AND INSTALLING MYSQL ODBC DRIVERS To download and install MySQL ODBC drivers: 1. You can download MySQL ODBC drivers here: downloads/connector/odbc/5.1.html Application Security, Inc. 261

263 Appendix L: Required Audit Privileges In this appendix: IBM DB2 Audit Privileges IBM DB2 z/os Audit Privileges Lotus Domino Groupware Audit Privileges Microsoft SQL Server Audit Privileges and User Creation Scripts MySQL Audit Privileges Oracle Audit Privileges and User Creation Script Sybase Audit Privileges Operating System Considerations (for Audits). IBM DB2 Audit Privileges Note: For more information on IBM DB2 OS check requirements, see Operating System Considerations (for Audits). To conduct a full IBM DB2 Audit, you need the following privileges. Make sure the account you are using has rights to use the following tables, views, and functions: Note: CONNECT GET DATABASE MANAGER CONFIGURATION & LIST DATABASE DIRECTORY Service Info (on Windows only) SYSIBM.SYSCOLAUTH SYSIBM.SYSINDEXAUTH SYSIBM.SYSPASSTHRUAUTH SYSIBM.SCHEMAAUTH SYSIBM.SYSDBAUTH SYSIBM.SYSTABAUTH SYSIBM.SYSFUNCTIONS SYSIBM.SYSPROCEDURES SYSIBM.SYSVERSIONS SYSPROC.SNAPSHOT_DATABASE SYSPROC.SNAPSHOT_DATABASE requires the Audit user to have SYSMON authority. Users with SYSADM, SYSCTRL, or SYSMAINT authority automatically inherit SYSMON authority. Application Security, Inc. 262

264 Below is a list of checks within DbProtect Vulnerability Assessment for an IBM DB2 Audit, and the tables and views they need permission to access in order to function properly: CLIENT authentication: GET DATABASE MANAGER CONFIGURATION & LIST DATABASE DIRECTORY SERVER authentication: GET DATABASE MANAGER CONFIGURATION & LIST DATABASE DIRECTORY DCS authentication: GET DATABASE MANAGER CONFIGURATION & LIST DATABASE DIRECTORY Trust All Client: GET DATABASE MANAGER CONFIGURATION & LIST DATABASE DIRECTORY Authentication type: GET DATABASE MANAGER CONFIGURATION & LIST DATABASE DIRECTORY Service runs as LocalSystem: Service Info (Windows ONLY) Permissions granted to PUBLIC: SYSIBM.SYSCOLAUTH, SYSIBM.SYSINDEXAUTH, SYSIBM.SYSPASSTHRUAUTH, SYSIBM.SCHEMAAUTH, SYSIBM.SYSDBAUTH, SYSIBM.SYSTABAUTH Permissions granted to user: SYSIBM.SYSCOLAUTH, SYSIBM.SYSINDEXAUTH, SYSIBM.SYSPASSTHRUAUTH, SYSIBM.SCHEMAAUTH, SYSIBM.SYSDBAUTH, SYSIBM.SYSTABAUTH Permissions grantable: SYSIBM.SYSCOLAUTH, SYSIBM.SYSINDEXAUTH, SYSIBM.SYSPASSTHRUAUTH, SYSIBM.SCHEMAAUTH, SYSIBM.SYSDBAUTH, SYSIBM.SYSTABAUTH Permissions on system catalog: SYSIBM.SYSDBAUTH, SYSIBM.SYSTABAUTH Permissions to list users: SYSIBM.SYSDBAUTH, SYSIBM.SYSTABAUTH db2ckpwd buffer overflow (Version verify): SYSIBM.SYSVERSIONS Query Compiler DoS (Verify version): SYSIBM.SYSVERSIONS Date/Varchar DoS (Verify version): SYSIBM.SYSVERSIONS Latest FixPak not installed: SYSIBM.SYSVERSIONS Control Center buffer overflow (Verify version): SYSIBM.SYSVERSIONS Excessive DBADM connections For the Excessive DBADM connections check, the IBM DB2 OS user must have: SELECT or CONTROL privilege on the APPLICATIONS and SNAPAPPL_INFO administrative views SYSMON, SYSCTRL, SYSMAINT, or SYSADM authority which is required to access snapshot monitor data. Some DB2 Audit checks need to differentiate between fixpaks such as 4/4a, 6/6a, etc. These checks require specific permissions. Specifically, the checks affected are: Arbitrary code execution in a federated system (Verify version) Arbitrary code execution when processing connection messages (Verify version) Arbitrary file creation in XML Extender functions (Verify version) Application Security, Inc. 263

265 Buffer overflow in CALL statement (Verify version) Buffer overflow in db2fmp (Verify version) Buffer overflow in generate_distfile procedure (Verify version) Buffer overflow in REC2XML function (Verify version) Buffer overflow in SATADMIN.SATENCRYPT function (Verify version) Buffer overflow in the JDBC listener (Verify version) Buffer overflows in XML Extender functions (Verify version) DoS in string formatting functions (Verify version) Latest FixPak not installed Multiple Buffer overflows in libdb2.so.1 library (Verify version) Multiple critical vulnerabilities in IBM DB2 (Verify version) Multiple DoS vulnerabilities in SQLJRA protocol The IBM DB2 OS user must have access to the db2greg command on all Unix platforms for the following IBM DB2 LUW checks: Permission on files Setuid bit enabled Setgid bit enabled In order for DbProtect Vulnerability Assessment to work properly with any of these checks, you must set special permissions, depending on what version of DB2 is running on your server. The following table explains which permissions are required for which versions of DB2: If your server is running DB2 version: Requirements: 9.10 or later SELECT or CONTROL privilege on the ENV_INST_INFO administrative view. OR SYSADM and/or ATTACH privileges. AND EXECUTE privilege on the ENV_GET_INST_INFO table function (required for IBM DB2 LUW v and later) or later EXECUTE privilege on the ENV_GET_INST_INFO table function or later SYSADM or ATTACH privileges. 7 Registry access or OS access. Application Security, Inc. 264

266 IBM DB2 z/os Audit Privileges This topic consists of the following sub-topics: Full IBM DB2 z/os Audit Requirements Per Check IBM DB2 z/os Audit Requirements. FULL IBM DB2 Z/OS AUDIT REQUIREMENTS You require the following permissions (which SYSADM has by default) in order to conduct a full IBM DB2 z/os Audit with all checks enabled: SELECT privileges on the following catalog tables: -SYSIBM.SYSCOLAUTH -SYSIBM.SYSDBAUTH -SYSIBM.SYSPACKAUTH -SYSIBM.SYSPLANAUTH -SYSIBM.SYSROUTINEAUTH -SYSIBM.SYSSCHEMAAUTH -SYSIBM.SYSTABAUTH -SYSIBM.SYSUSERAUTH -SYSIBM.GETVARIABLE Permission to call the following function: SYSIBM.GETVARIABLE Permission to call the following stored procedure: SYSPROC.DSNWZP PER CHECK IBM DB2 Z/OS AUDIT REQUIREMENTS To conduct an IBM DB2 z/os Audit with selected checks enabled, the following permissions are required in a per-check basis: Note: All checks require permission to call the following function: SYSIBM.GETVARIABLE The following IBM DB2 z/os Audit checks require permission to call the stored procedure SYSPROC.DSNWZP: -Dual logging not enabled -Dual archiving not enabled -SMF accounting is not set to start automatically -Audit Trace is not set to start automatically -SMF statistics not set to start automatically -Authorization checking disabled -Collection interval for statistics -System install administrators and operators If the SYSPROC.DSNWZP and SYSPROC.ADMIN_DS_LIST stored procedures are not enabled, you must enable them and set up the proper environments so they can function correctly. Application Security, Inc. 265

267 The IBM DB2 z/os Audit check Connection and sign-on exits requires permission to call the stored procedure SYSPROC.ADMIN_DS_LIST. The following table lists IBM DB2 z/os Audit checks which must have SELECT privileges on the corresponding IBM DB2 z/os tables: Check Access list of authorization IDs Administrative authorities on DB2 Subsystem Privileges granted to PUBLIC on packages Administrative authorities for DB2 catalog database Administrative authorities over databases Privileges granted to PUBLIC on plans PUBLIC granted Administrative authorities on DB2 Subsystem Privileges granted to PUBLIC on columns Privileges granted to PUBLIC on routines Easily-guessed usernames and passwords No permission is required Privileges granted to PUBLIC on databases Privileges granted to PUBLIC on DB2 subsystem Corresponding IBM DB2 z/os tables requiring SELECT privileges SYSIBM.SYSTABAUTH SYSIBM.SYSUSERAUTH SYSIBM.SYSPACKAUTH SYSIBM.SYSDBAUTH SYSIBM.SYSDBAUTH SYSIBM.SYSPLANAUTH SYSIBM.SYSUSERAUTH SYSIBM.SYSCOLAUTH SYSIBM.SYSROUTINEAUTH SYSIBM.SYSDBAUTH SYSIBM.SYSUSERAUTH Application Security, Inc. 266

268 Check Password same as username for account Privileges on the DB2 catalog Privileges granted to PUBLIC on schemas Privileges granted to PUBLIC on DB2 catalog tables Privileges granted to PUBLIC on tables Administrative authority for database granted to PUBLIC Corresponding IBM DB2 z/os tables requiring SELECT privileges SYSIBM.SYSDBAUTH SYSIBM.SYSTABAUTH SYSIBM.SYSPLANAUTH SYSIBM.SYSCOLAUTH SYSIBM.SYSSCHEMAAUTH SYSIBM.SYSPACKAUTH SYSIBM.SYSROUTINEAUTH SYSIBM.SYSUSERAUTH PSYSTABAUTH SYSIBM.SYSSCHEMAAUTH SYSTABAUTH SYSTABAUTH SYSIBM.SYSDBAUTH Lotus Domino Groupware Audit Privileges Note: For more information on Lotus Domino OS check requirements, see Operating System Considerations (for Audits). To conduct a full Lotus Domino Groupware Audit, you need the following privileges. Make sure the account you are using has rights to use the following tables and views: Read all databases Read decsadm.nsf and all of its documents Read names.nsf and all of its documents Execute commands on the server Read all user documents At a document level, DbProtect Vulnerability Assessment checks certain fields, including: $Author, $Readers, RM_MapFrom, $Readers, and fields of type LNRTTYPE_AUTHORS_FIELD. DbProtect Vulnerability Assessment also verifies certain Lotus Domino Groupware properties (for example, if you have attachments and if they are encrypted). If any of the required fields listed above are encrypted and the id does not have access to it, then some of the checks below will not work properly. Application Security, Inc. 267

269 Caution! Despositor access that only has access to read public documents is sufficient to run a Lotus Domino Groupware Audit, with the exception of the names.nsf database which requires Reader access. Besides SHOW commands, the following Lotus Domino Groupware commands are also executed: TELL HTTP SHOW FILE ACCESS SET SECURE Below is a list of checks within the DbProtect Vulnerability Assessment for a Lotus Domino Audit, and the tables and views they need permission to access in order to function properly: Anonymous can create documents: Read all databases Anonymous granted Designer or higher access: Read all databases Anonymous user in Authors field: Read all databases Default has Editor or higher access: Read all databases Encrypted field full-text indexed: Read all databases Unspecified user type in ACL: Read all databases DECS password unencrypted: Read decsadm.nsf and all of its documents Anonymous ACL missing: Read all databases, Read names.nsf and all of its documents Access server unrestricted: Read names.nsf and all of its documents All people can use monitors: Read names.nsf and all of its documents All users can run personal agents: Read names.nsf and all of its documents Anonymous access via HTTPS: Read names.nsf and all of its documents Anonymous access via Notes RPC: Read names.nsf and all of its documents Bindsock arbitrary file creation: Read names.nsf and all of its documents CGI directory leak: Read names.nsf and all of its documents Check passwords on Notes IDs: Read names.nsf and all of its documents Create databases unrestricted: Read names.nsf and all of its documents Enumerate groups: Read names.nsf and all of its documents Failed access control on file attachments: Read names.nsf and all of its documents inotes client ActiveX control buffer overflow: Read names.nsf and all of its documents Application Security, Inc. 268

270 inotes s_viewname buffer overflow: Read names.nsf and all of its documents Latest maintenance release not applied: Read names.nsf and all of its documents Long POST request DoS: Read names.nsf and all of its documents Maximum number of request headers: Read names.nsf and all of its documents Maximum size of request contents: Read names.nsf and all of its documents Maximum size of request headers: Read names.nsf and all of its documents Maximum URL length: Read names.nsf and all of its documents Maximum URL path segments: Read names.nsf and all of its documents Non-admins can use monitors: Read names.nsf and all of its documents Notes RPC buffer overflow: Read names.nsf and all of its documents Notes_ExecDirectory buffer overflow: Read names.nsf and all of its documents Password change interval for user: Read names.nsf and all of its documents PATH buffer overflow: Read names.nsf and all of its documents Public keys compared to directory: Read names.nsf and all of its documents Restricted agents runlist: Read names.nsf and all of its documents Restricted Java/COM runlist: Read names.nsf and all of its documents Saved not encrypted: Read names.nsf and all of its documents Servlets disabled: Read names.nsf and all of its documents Unrestricted agents runlist: Read names.nsf and all of its documents Unrestricted Java/COM runlist: Read names.nsf and all of its documents User can create new databases: Read names.nsf and all of its documents Administration over HTTP: Read names.nsf and all of its documents, Execute a command on the server Anonymous access via HTTP: Read names.nsf and all of its documents, Execute a command on the server Anonymous access via IIOP: Read names.nsf and all of its documents, Execute a command on the server Anonymous access via IIOPS: Read names.nsf and all of its documents, Execute a command on the server Application Security, Inc. 269

271 Anonymous access via LDAP: Read names.nsf and all of its documents, Execute a command on the server Anonymous access via LDAPS: Read names.nsf and all of its documents, Execute a command on the server ESMTP buffer overflow: Read names.nsf and all of its documents, Execute a command on the server Expired certificates allowed: Read names.nsf and all of its documents, Execute a command on the server HTTP authenticate buffer overflow: Read names.nsf and all of its documents, Execute a command on the server HTTP database browsing: Read names.nsf and all of its documents, Execute a command on the server HTTP logging not enabled: Read names.nsf and all of its documents, Execute a command on the server HTTP methods excluded from logging: Read names.nsf and all of its documents, Execute a command on the server HTTP MIME types excluded from logging: Read names.nsf and all of its documents, Execute a command on the server HTTP return codes excluded from logging: Read names.nsf and all of its documents, Execute a command on the server HTTP user agents excluded from logging: Read names.nsf and all of its documents, Execute a command on the server HTTPS allows anonymous access: Read names.nsf and all of its documents, Execute a command on the server Inadequate amgr process logging: Read names.nsf and all of its documents, Execute a command on the server Incomplete POST DoS: Read names.nsf and all of its documents, Execute a command on the server Interface address leak in banner: Read names.nsf and all of its documents, Execute a command on the server LDAP buffer overflow: Read names.nsf and all of its documents, Execute a command on the server LDAP format string: Read names.nsf and all of its documents, Execute a command on the server MS-DOS device web path leak: Read names.nsf and all of its documents, Execute a command on the server Personal agents runlist: Read names.nsf and all of its documents, Execute a command on the server Redirected host/location buffer overflow: Read names.nsf and all of its documents, Execute a command on the server Routing loop DoS (Verify version): Read names.nsf and all of its documents, Execute a command on the server SMTP buffer overflow: Read names.nsf and all of its documents, Execute a command on the server Unencrypted HTTP: Read names.nsf and all of its documents, Execute a command on the server Application Security, Inc. 270

272 Unencrypted IIOP: Read names.nsf and all of its documents, Execute a command on the server Unencrypted IMAP: Read names.nsf and all of its documents, Execute a command on the server Unencrypted LDAP: Read names.nsf and all of its documents, Execute a command on the server Unencrypted NNTP: Read names.nsf and all of its documents, Execute a command on the server Unencrypted POP3: Read names.nsf and all of its documents, Execute a command on the server Web retriever HTTP status buffer overflow: Read names.nsf and all of its documents, Execute a command on the server Web Retriever logging: Read names.nsf and all of its documents, Execute a command on the server Easily-guessed Internet password: Read all user documents Easily-guessed Notes password: Read all user documents Agent manager debugging not enabled: Execute a command on the server Ambiguous webnames allowed: Execute a command on the server Console password not set: Execute a command on the server Inadequate console logging: Execute a command on the server NDS password present: Execute a command on the server NDS userid present: Execute a command on the server Phone line logging not enabled: Execute a command on the server Microsoft SQL Server Audit Privileges and User Creation Scripts Note: For more information on Microsoft SQL Server OS check requirements, see Operating System Considerations (for Audits). This topic consists of the following sub-topics: Microsoft SQL Server 2000 and MSDE Audit Privileges Running the Microsoft SQL Server 2000 User Creation Script Running the Microsoft SQL Server 2000 with Sysadmin User Creation Script Microsoft SQL Server 2005 and Microsoft SQL Server 2008 Audit Privileges Credentials for Microsoft SQL Server Audits Running the Microsoft SQL Server 2005 and 2008 User Creation Script Registry Access for Microsoft SQL Server 2000, 2005, and Application Security, Inc. 271

273 MICROSOFT SQL SERVER 2000 AND MSDE AUDIT PRIVILEGES To conduct a full Microsoft SQL Server 2000 or MSDE Audit, you need the following privileges. Make sure the account you are using has rights to use the following tables and views: Check master.dbo.xp_loginconfig EXECUTE Privileges Required master.dbo.xp_regread exec <db name>.dbo.sp_helprotect msdb.dbo.sp_get_sqlagent_properties SELECT master.dbo.syslogins (MSSQLSysLogins) master.dbo.sysxlogins master.dbo.sysdatabases master.dbo.sysconfigures master.dbo.syscurconfigs master.dbo.syscharsets <db name>.dbo.sysusers <db name>.dbo.sysobjects <db name>.dbo.syscomments Application Security, Inc. 272

274 In addition, certain Microsoft SQL Server 2000 DISA-STIG Database Security Configuration checks require you to be a member of the sysadmin fixed server role or the db_owner fixed database role on the publication database. The following table provides specific information about which checks require which roles (and why): Microsoft SQL Server 2000 DISA-STIG checks: DBMS replication account privileges Replication snapshot folder protection Database auditing Auditing of Security Events Startup Stored Procedures Use: Replication system stored procedures. fn_trace_getinfo and fn_trace_geteventinfo functions. To run these checks, you must be a member of: The sysadmin fixed server role or the db_owner fixed database role on the publication database. The sysadmin fixed server role. Below is a list of checks within the DbProtect Vulnerability Assessment for a Microsoft SQL Server 2000 Audit, and the tables and views they need permission to access in order to function properly: Agent jobs privilege escalation: exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Auditing of failed logins: master.dbo.xp_loginconfig Auditing of successful logins: master.dbo.xp_loginconfig Blank password: master.dbo.sysxlogins Blank password for sa: master.dbo.sysxlogins Blank password for well-known login: master.dbo.sysxlogins BULK INSERT buffer C2 Audit master.dbo.sysconfigures, master.dbo.syscurconfigs Case-insensitive sort order: master.dbo.syscharsets, master.dbo.sysconfigures,master.dbo.syscurconfigs Changing mode may leave sa password Cleartext password written by master.dbo.xp_cmdshell Computed Column UDF Database ownership chaining not disabled: sysconfigures,syscurconfigs DBCC addextendedproc buffer DBCC BUFFER buffer Application Security, Inc. 273

275 DBCC CHECKCONSTRAINTS buffer overflow: DBCC CLEANTABLE buffer overflow: DBCC INDEXDEFRAG buffer overflow: DBCC PROCBUF buffer overflow: DBCC SHOWCONTIG buffer overflow: DBCC SHOWTABLEAFFINITY buffer overflow: DBCC UPDATEUSAGE buffer overflow: DBMS remote system credential use and access: master.dbo.sysxlogins, [master].dbo.sysservers Default login enabled: master.dbo.syslogins, master.dbo.xp_loginconfig Direct updates on data dictionary: master.dbo.sysconfigures, master.dbo.syscurconfigs DTS package procedures granted to public: sp_helprotect DTS package password publicly viewable: msdb.dbo.sysuser, exec msdb.dbo.sp_helprotect DTS password exposed in properties dialog: DTS passwords publicly viewable: <db name>.dbo.sysuser, exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Easily-guessed password: Easily-guessed password for sa: Easily-guessed password for well-known login: Encoded password written by installation: master.dbo.xp_cmdshell Enterprise Manager improperly revokes proxy account: Error logs can be overwritten: Registry access Note: To learn more about enabling registry access for Microsoft SQL Server 2000, see Registry Access for Microsoft SQL Server 2000, 2005, and Escalated privileges in heterogeneous joins: Extended stored proc privilege upgrade: exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Fixed server role granted: master.dbo.syslogins Format string in C runtime Format string vuln in FORMATMESSAGE buffer Global temporary stored proc exists: sysobjects,sysusers Guest user exists in database: <db name>.dbo.sysuser, master.dbo.sysdatabases Hello buffer Infected with Spida worm: <db name>.dbo.sysobjects, master.dbo.sysdatabases, master.dbo.xp_cmdshell Jet running in sandbox Mode: Registry access Note: To learn more about enabling registry access for Microsoft SQL Server 2000, see Registry Access for Microsoft SQL Server 2000, 2005, and Job output file Application Security, Inc. 274

276 Latest service pack applied: Lumigent Log Explorer buffer overflow: <db name>.dbo.sysobjects, master.dbo.sysdatabases Malformed RPC request DoS: Malformed TDS packet header DoS: MDX Query buffer overflow: Objects not owned by dbo: <db name>.dbo.sysobjects, master.dbo.sysdatabases, <db name>.dbo.sysuser OLEDB ad hoc queries allowed: Registry access Note: To learn more about enabling registry access for Microsoft SQL Server 2000, see Registry Access for Microsoft SQL Server 2000, 2005, and Orphaned user: <db name>.dbo.sysuser, master.dbo.sysdatabases, master.dbo.syslogins Password same as login name: Permission grantable: exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Permissions granted to public: <db name>.dbo.sp_helprotect Permission on mswebtasks: exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Permission on registry extended proc: exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Permission on sp_mssetalertinfo: exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Permission on sp_mssetserverproperties: exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Permission on sp_readwebtask: exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Permission on sp_runwebtask: exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Permission on xp_readerrorlog: exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Permission to select from syslogins: exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Permission to select from system table: <db name>.dbo.sysobjects, exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Permissions granted on sp_add_dtspackage: msdb.dbo.sysuser, exec msdb.dbo.sp_helprotect Permissions granted on xp_cmdshell: exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Permissions granted to user: <db name>.dbo.sysuser, exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Public can create Agent jobs: exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases pwdencrypt buffer overflow: RAISERROR buffer overflow: Application Security, Inc. 275

277 Registry extended proc not removed: <db name>.dbo.sysobjects, master.dbo.sysdatabases Remote access allowed: master.dbo.sysconfigures, master.dbo.syscurconfigs Remote data source function unchecked buffer: Replication password publicly viewable: Resolution service DoS: Resolution service heap overflow: Resolution service stack overflow: Reusable cached administrator connection: sp_attachsubscription command injection: <db name>.dbo.sysobjects, master.dbo.sysdatabases sp_mscopyscriptfile command injection: <db name>.dbo.sysobjects, master.dbo.sysdatabases, SQL Agent password publicly viewable: msdb.dbo.sp_get_sqlagent_properties, sp_helprotect SQL Agent procedures granted to public: sp_helprotect SQLServerAgent password in registry: <db name>.dbo.sysobjects, master.dbo.sysdatabases srv_paraminfo buffer overflow in sp_oacreate: srv_paraminfo buffer overflow in sp_oadestroy: srv_paraminfo buffer overflow in sp_oagetproperty: srv_paraminfo buffer overflow in sp_oamethod: srv_paraminfo buffer overflow in sp_oasetproperty: srv_paraminfo buffer overflow in xp_displayparamstmt: srv_paraminfo buffer overflow in xp_execresultset: srv_paraminfo buffer overflow in xp_peekqueue: srv_paraminfo buffer overflow in xp_printstatements: srv_paraminfo buffer overflow in xp_proxiedmetadata: srv_paraminfo buffer overflow in xp_setsqlsecurity: srv_paraminfo buffer overflow in xp_showcolv: srv_paraminfo buffer overflow in xp_sqlagent_monitor: srv_paraminfo buffer overflow in xp_sqlinventory: srv_paraminfo buffer overflow in xp_updatecolvbm: Standard SQL Server authentication allowed: <db name>.dbo.sysobjects, master.dbo.sysdatabases, master.dbo.xp_loginconfig Statement permission granted: master.dbo.sysdatabases, exec <db name>.dbo.sp_helprotect SysAdmin only for CmdExec job steps: <db name>.dbo.sysobjects, master.dbo.sysdatabases sysadmin role granted: master.dbo.syslogins Table to store DTS passwords publicly viewable: <db name>.dbo.sysuser, master.dbo.sysdatabases, exec <db name>.dbo.sp_helprotect Application Security, Inc. 276

278 Temporary stored procedures bypass permissions: UDB broadcast buffer overflow: master.dbo.xp_cmdshell Unauthorized object permission grants: <db name>.dbo.sysuser, exec <db name>.dbo.sp_helprotect, master.dbo.sysdatabases Windows account name shown as hostname: master.dbo.xp_loginconfig XMLHTTP control allows local file access: <db name>.dbo.sysobjects, master.dbo.sysdatabases, xp_cmdshell not removed: <db name>.dbo.sysobjects, master.dbo.sysdatabases replace for xp_cmdshell not removed/not disabled: select object_id() xp_controlqueueservice buffer overflow: <db name>.dbo.sysobjects, master.dbo.sysdatabases xp_createprivatequeue buffer overflow: <db name>.dbo.sysobjects, master.dbo.sysdatabases xp_createqueue buffer overflow: master.dbo.sysdatabases, <db name>.dbo.sysobjects xp_decodequeuecmd buffer overflow: <db name>.dbo.sysobjects, master.dbo.sysdatabases xp_deleteprivatequeue buffer overflow: <db name>.dbo.sysobjects, master.dbo.sysdatabases xp_deletequeue buffer overflow: <db name>.dbo.sysobjects, master.dbo.sysdatabases xp_dirtree buffer overflow: <db name>.dbo.sysobjects, master.dbo.sysdatabases xp_displayqueuemesgs buffer overflow: master.dbo.sysdatabases, <db name>.dbo.sysobjects xp_dsninfo buffer overflow: <db name>.dbo.sysobjects, master.dbo.sysdatabases xp_mergelineages buffer overflow: master.dbo.sysdatabases, <db name>.dbo.sysobjects xp_oledbinfo buffer overflow: <db name>.dbo.sysobjects, master.dbo.sysdatabases xp_proxiedmetadata buffer overflow: master.dbo.sysdatabases, <db name>.dbo.sysobjects, xp_readpkfromqueue buffer overflow: <db name>.dbo.sysobjects, master.dbo.sysdatabases xp_readpkfromvarbin buffer overflow: <db name>.dbo.sysobjects, master.dbo.sysdatabases xp_repl_encrypt buffer overflow: <db name>.dbo.sysobjects, master.dbo.sysdatabases xp_resetqueue buffer overflow: <db name>.dbo.sysobjects, master.dbo.sysdatabases xp_sprintf buffer overflow: xp_sqlagent_param buffer overflow: <db name>.dbo.sysobjects, master.dbo.sysdatabases Application Security, Inc. 277

279 xp_sqlinventory buffer overflow: master.dbo.sysdatabases, <db name>.dbo.sysobjects xp_unpackcab buffer overflow: <db name>.dbo.sysobjects, master.dbo.sysdatabases xstatus backdoor: master.dbo.sysxlogins RUNNING THE MICROSOFT SQL SERVER 2000 USER CREATION SCRIPT Application Security Inc. has written a convenient Microsoft SQL Server 2000 user creation script (CreateUserSQLServer2k.sql) which creates an account with the minimum privileges necessary to perform Audits on a Microsoft SQL 2000 instance. The contents of the CreateUserSQLServer2k.sql script follow: --create login use [master] EXEC sp_addlogin 'aduser', 'Admin123', 'master' GO --add user to each database EXEC sp_msforeachdb ' USE [?] sql_variant = databasepropertyex(name,''updateability'') FROM master.dbo.sysdatabases where databasepropertyex(name,''status'')=''online'' and name = ''?'' = ''READ_WRITE'' BEGIN EXEC sp_adduser ''aduser'' END' GO --assign privileges needed for audit USE [master] GO GRANT EXECUTE ON dbo.xp_loginconfig TO [aduser] GRANT SELECT ON dbo.syslogins TO [aduser] GRANT SELECT ON dbo.sysxlogins TO [aduser] Application Security, Inc. 278

280 GRANT SELECT ON dbo.sysaltfiles TO [aduser] GRANT SELECT ON dbo.sysdatabases TO [aduser] GRANT SELECT ON dbo.sysconfigures TO [aduser] GRANT SELECT ON dbo.syscurconfigs TO [aduser] GRANT SELECT ON dbo.sysservers TO [aduser] GRANT SELECT ON dbo.sysmembers TO [aduser] GRANT SELECT ON dbo.sysprotects TO [aduser] GRANT SELECT ON dbo.spt_values TO [aduser] GRANT EXECUTE ON sp_helpreplicationdboption TO [aduser] GRANT EXECUTE ON sp_helpsrvrolemember TO [aduser] GRANT EXECUTE ON sp_helprolemember TO [aduser] GRANT SELECT ON dbo.sysoledbusers TO [aduser] EXEC sp_msforeachdb ' sql_variant = databasepropertyex(name,''updateability'') FROM master.dbo.sysdatabases where databasepropertyex(name,''status'')=''online'' and name = ''?'' = ''READ_WRITE'' BEGIN GRANT EXECUTE ON [?].dbo.sp_helprotect TO [aduser] GRANT EXECUTE ON [?].dbo.sp_helpuser TO [aduser] END ' EXEC sp_msforeachdb ' USE [?] sql_variant = databasepropertyex(name,''updateability'') FROM master.dbo.sysdatabases where databasepropertyex(name,''status'')=''online'' and name = ''?'' = ''READ_WRITE'' Application Security, Inc. 279

281 BEGIN GRANT SELECT ON dbo.sysusers TO [aduser] GRANT SELECT ON dbo.sysobjects TO [aduser] GRANT SELECT ON dbo.syscomments TO [aduser] END ' use [msdb] GRANT SELECT ON dbo.sysjobs TO [aduser] GRANT SELECT ON dbo.sysjobhistory TO [aduser] print 'all done.' RUNNING THE MICROSOFT SQL SERVER 2000 WITH SYSADMIN USER CREATION SCRIPT Application Security Inc. has written a convenient Microsoft SQL Server 2000 user creation script (CreateUserSQLServer2kwithSA.sql) which creates an account with the minimum privileges necessary to perform Audits on a Microsoft SQL 2000 instance, and adds it to the SYSADMIN server role. The contents of the CreateUserSQLServer2kwithSA.sql script follow: USE master GO EXEC sp_addlogin 'aduser', 'Admin123' GO EXEC sp_msforeachdb ' USE [?] sql_variant = databasepropertyex(name,''updateability'') FROM master.dbo.sysdatabases where databasepropertyex(name,''status'')=''online'' and name = ''?'' = ''READ_WRITE'' BEGIN EXEC sp_grantdbaccess ''aduser'', ''aduser'' END' GO EXEC sp_addsrvrolemember "aduser", SYSADMIN Application Security, Inc. 280

282 MICROSOFT SQL SERVER 2005 AND MICROSOFT SQL SERVER 2008 AUDIT PRIVILEGES Important: Application Security Inc. wrote a convenient Microsoft SQL Server 2005 and Microsoft SQL Server 2008 user creation script (CreateUserSQLServer2k52k8PublicRevoked.sql) that creates an account with the minimum privileges necessary to perform an Audit on a Microsoft SQL Server instance. If you want to run this script, just make sure whatever account you use to conduct your Audit has at least the SELECT privileges listed in the script. For more information, see Running the Microsoft SQL Server 2005 and 2008 User Creation Script. Any Audit check for Microsoft SQL Server 2005 and Microsoft SQL Server 2008 queries the following views: sys.databases sys.configurations sys.server_principals sys.server_role_members In Microsoft SQL Server 2005 and Microsoft SQL Server 2008 the public group can select from these views but, due to metadata visibility concept, DbProtect Vulnerability Assessment may not return all records. For this reason, each of the checks listed below requires the following permissions in order to retrieve data: VIEW DEFINITION, VIEW ANY DEFINITION, and CONTROL SERVER. In addition, you must have permission to select from system table: select all rows from master.sys.database_permissions, <dbname>.sys.system_objects views which implies VIEW DEFINITION on database scope permission. For the check Symmetric Keys: encrypting mechanism to work properly, the auditing user should have access to all keys. The user must be a privileged user have been granted access to all the keys. You can use one of the following statements to grant access: for every database GRANT VIEW DEFINITION TO [aduser] or in master database GRANT VIEW ANY DEFINITION TO [aduser] In addition, certain Microsoft SQL Server 2005 and 2008 DISA-STIG Database Security Configuration checks require you to be a member of the sysadmin fixed server role or Application Security, Inc. 281

283 the db_owner fixed database role on the publication database. The following table provides specific information about which checks require which roles (and why): Microsoft SQL Server 205 and 2008 DISA-STIG checks: DBMS replication account privileges Replication snapshot folder protection Use: Replication system stored procedures. To run these checks, you must be a member of: The sysadmin fixed server role or the db_owner fixed database role on the publication database Below is a list of DbProtect Vulnerability Assessment checks used to run a Microsoft SQL Server 2005 or and Microsoft SQL Server 2008 Audit, including the tables and views they need permission to access in order to function properly: Agent XPs enabled: select from sys.configurations view. Application user access to external objects: select from <dbname>.sys.objects, <dbname>.sys.database_permissions. Asymmetric Keys: private key encryption type: select from master.dbo.sysdatabases, select from <dbname>.sys.asymmetric_keys, VIEW DEFINITION on database scope permission. Auditing of failed logins: master.dbo.xp_loginconfig. Auditing of failed/successful logins: execute xp_loginconfig. Audit trace status: select from fn_trace_getinfo, fn_trace_geteventinfo. Blank password checks: select password_hash column of sys.sql_logins for all sql logins which implies CONTROL SERVER permission. BUILTIN\Administrators not removed: select all rows from sys.server_principals view which implies VIEW ANY DEFINITION permission. C2 Audit Mode: select from sys.configurations view. CLR objects allowed: select from sys.configurations view. Common criteria compliance disabled: select from sys.configurations view. Database job/batch queue monitoring: select from master.sys.procedures, select name, job_id columns from msdb.dbo.sysjobs and select job_id column from msdb.dbo.sysjobhistory. Database Master Key: access control: select from master.dbo.sysdatabases, <dbname>.sys.database_principals, <dbname>.sys.database_permissions. Application Security, Inc. 282

284 Database Master Key: encryption password: select from master.dbo.sysdatabases,<dbname>.sys.key_encryptions,<dbname>.sys.symmetric_keys, VIEW DEFINITION on database scope permission. Database Master Key: is_master_key_encrypted_by_server: select from sys.databases. Database Master Key: password storage: select from sys.master_key_passwords. Database ownership chaining not disabled: select from sys.configurations view. DBA OS privilege assignment: execute sp_helpsrvrolemember. DBMS account password expiration: select from sys.sql_logins. DBMS administration OS accounts: execute sp_helpsrvrolemember. DBMS audit log backups: select from fn_trace_getinfo. DBMS audit record access: select from sys.server_permissions, master.dbo.syslogins and master.dbo.sysusers, execute sp_helpsrvrolemember. DBMS Password Policy Enforced: execute xp_loginconfig, select from sys.sql_logins. DBMS remote system credential use and access: select from dbo.sysservers, sys.linked_logins. DBMS services dedicated custom account: Registry access. DBMS software file backups: Registry access. DBMS dedicated software directory and partition: Registry access. DBMS network port, protocol, and services (PPS) configuration: Registry access*. Note: To learn more about enabling registry access for Microsoft SQL Server 2005 and 2008, see Registry Access for Microsoft SQL Server 2000, 2005, and Dedicated data file directories: select from sys.master_files, sys.databases, Registry access*. Default password for well-known login: makes connection attempts. Default Trace Disabled: select from sys.configurations view. DTS package password publicly viewable: select all rows from msdb.sys.database_permissions, sys.types, sys.all_objects, sys.certificates, sys.fulltext_catalogs, sys.routes, sys.remote_service_bindings, sys.services, sys.service_contracts, sys.service_message_types, sys.xml_schema_collections, sys.assemblies views which implies VIEW DEFINITION on database scope permission. DTS package procedures granted to public: select from msdb.sys.database_permissions view. DTS procedures granted to PUBLIC: select from msdb.sys.database_principals, msdb.sys.database_permissions. Easily-guessed password checks: select password_hash column of sys.sql_logins for all sql logins which implies CONTROL SERVER permission. Encryption of DBMS sensitive data in transit: Registry access. Application Security, Inc. 283

285 Error logs can be overwritten: Registry access. Event forwarding not disabled: Registry access. Note: To learn more about enabling registry access for Microsoft SQL Server 2005 and 2008, see Registry Access for Microsoft SQL Server 2000, 2005, and Fixed server role granted: select all rows from sys.server_principals, sys.server_role_members views which implies VIEW ANY DEFINITION permission. Global temporary stored proc exists: select from tempdb.sys.all_objects. Guest user exists in database: select all rows from sys.databases and <dbname>.sys.database_principals, and <dbname>.sys.database_permissions views. Integration Services OS account least privileges: Windows Management Instrumentation (WMI). Latest service pack/hot fix not applied: uses - requires no privileges. Linked Servers Definitions: select from sys.servers view. Permissions granted on sp_add_dtspackage: select all rows from msdb.sys.database_permissions, sys.types, sys.all_objects, sys.certificates, sys.fulltext_catalogs, sys.routes, sys.remote_service_bindings, sys.services, sys.service_contracts, sys.service_message_types, sys.xml_schema_collections, sys.assemblies views which implies VIEW DEFINITION on database scope permission. Lumigent Log Explorer buffer overflow: select all rows from master.sys.objects view which implies VIEW DEFINITION on master database permission. Not using NTFS partition: execute xp_instance_regread. OLEDB ad hoc queries allowed: select from sys.configurations view, Registry access. Note: To learn more about enabling registry access for Microsoft SQL Server 2005 and 2008, see Registry Access for Microsoft SQL Server 2000, 2005, and Password same as login name: select password_hash column of sys.sql_logins view for all sql logins which implies CONTROL SERVER permission. Permission grantable: select all rows from sys.databases, <dbname>.sys.database_permissions views which implies VIEW DEFINITION on database scope permission. Permission on OLE automation procs: select all rows from master.sys.database_permissions view which implies VIEW DEFINITION on database scope permission. Permission on registry extended proc: select all rows from master.sys.database_permissions view which implies VIEW DEFINITION on database scope permission. Application Security, Inc. 284

286 Permission to select from system table: select all rows from master.sys.database_permissions view which implies VIEW DEFINITION on database scope permission. Permissions granted on xp_cmdshell: select all rows from master.sys.database_permissions view which implies VIEW DEFINITION on database scope permission. Permissions granted to PUBLIC: select all rows from sys.databases, <dbname>.sys.database_permissions views. Permissions granted to user: select all rows from sys.databases, <dbname>.sys.database_permissions, sys.types, sys.all_objects, sys.certificates, sys.fulltext_catalogs, sys.routes, sys.remote_service_bindings, sys.services, sys.service_contracts, sys.service_message_types, sys.xml_schema_collections, sys.assemblies views which implies VIEW DEFINITION on database scope permission. Permissions on files: execute xp_instance_regread. Protection of DBMS asymmetric encryption keys: select from master.dbo.sysdatabases, <dbname>.sys.asymmetric_keys, <dbname>.sys.database_principals, <dbname>.sys.database_permissions, VIEW DEFINITION on database scope permission. Proxy account subsystem privileges: select subsystem, subsystem_id columns from msdb.dbo.syssubsystems. Registry extended proc not removed: select from master.sys.system_objects view. Registry permissions: execute xp_instance_regread. Remote access allowed: select from sys.configurations view. Remote admin connections allowed: select from sys.configurations view. Sample database not removed: select all rows from sys.databases view. Service Broker Endpoints exist: select from sys.service_broker_endpoints. Service runs as LocalSystem: execute xp_instance_regread. SMO and DMO XPs enabled: select from sys.configurations view. SQL Server Agent account user rights: Windows Management Instrumentation (WMI). SQL Server Agent proxy accounts are not dedicated: execute sp_enum_login_for_proxy. SQL Server component service account user rights: Windows Management Instrumentation (WMI). SQL Server file permissions: Registry access*, OS access (Permission to read files in the installation directory of the database) also Windows Management Instrumentation (WMI). SQL Server service account: Windows Management Instrumentation (WMI). SQL Server service account user rights: Windows Management Instrumentation (WMI). Application Security, Inc. 285

287 Standard SQL Server authentication allowed: execute xp_instance_regread. Statement permission granted: select all rows from sys.databases, <dbname>.sys.database_permissions views which implies VIEW DEFINITION on database scope permission. Symmetric Keys: allowed encryption algorithms: select from master.dbo.sysdatabases, <dbname>.sys.symmetric_keys, VIEW DEFINITION on database scope permission. Symmetric Keys: encrypting mechanism: select from master.dbo.sysdatabases, <dbname>.sys.symmetric_keys, <dbname>.sys.key_encryptions, VIEW DEFINITION on database scope permission. sysadmin role granted: select all rows from sys.server_principals, sys.server_role_members views which implies VIEW ANY DEFINITION permission. Unauthorized object permission grants: select all rows from sys.databases, <dbname>.sys.database_permissions, sys.types, sys.all_objects, sys.certificates, sys.fulltext_catalogs, sys.routes, sys.remote_service_bindings, sys.services, sys.service_contracts, sys.service_message_types, sys.xml_schema_collections, sys.assemblies views which implies VIEW DEFINITION on database scope permission. XML web service access: select from sys.http_endpoints. Web assistant procedures enabled: select from sys.configurations view. xp_cmdshell not removed/not disabled: select from sys.configurations view. CREDENTIALS FOR MICROSOFT SQL SERVER AUDITS If you are unable to Audit a Microsoft SQL Server database using Windows Authentication, you may be using an account that lacks the proper credentials. There are a number of different ways to supply the proper credentials for Microsoft SQL Server. The appropriate method depends on your circumstances. The following table explains how to change your credentials under different scenarios when you attempt to perform an Audit on the Microsoft SQL Server TARGET machine Application Security, Inc. 286

288 from another machine (HOST). Once you have valid credentials on the target HOST, you should be able to perform your Audit. Part If Then 1 TARGET and HOST are in the same or trusted domain. If you are logged in to HOST as a user that has Administrative access to TARGET, you do not need to supply additional credentials. Or... If you are logged in as user without Administrative access, you will need to supply TARGET s sa credentials. Application Security, Inc. 287

289 Part If Then 2 TARGET is in WORKGROUP_X and HOST is in DOMAIN_A Or... TARGET is in WORKGROUP_X and HOST is in WORKGROUP_Y Or... TARGET is in WORKGROUP_X and HOST is in WORKGROUP_X You can supply sa credentials in DbProtect Vulnerability Assessment. Or... You can create a local user on TARGET and a local user on HOST with matching user names and passwords. Note: You cannot use Domain names here. Or... Select the Properties branch option Connect to Microsoft SQL Servers via Named Pipes in the DbProtect Vulnerability Assessment Properties branch, then use the Net Use technique to establish credentials on TARGET. You must select this option to force DbProtect Vulnerability Assessment to use named pipes. You must check this option if you want to Audit a Microsoft SQL Server database (using Windows Authentication) against a machine on a different or untrusted domain. Additional steps are required. For more information, see Auditing Microsoft SQL Server (Using Windows Authentication) Against a Machine on a Different or Untrusted Domain. To use the Net Use technique: -Open a command prompt. -Enter the net use command to log in to the target server with valid credentials. -The command should adhere to the following format: net use \\computerip / user:[domainname\]username -DbProtect Vulnerability Assessment prompts you for a valid password on the TARGET. -Verify access by re-entering net use. Note: DbProtect Vulnerability Assessment does not support Pen Testing any Microsoft SQL Server instances which use named pipes for connection. Application Security, Inc. 288

290 Part If Then 3 TARGET is in DOMAIN_A and HOST is either in an untrusted DOMAIN_B or in WORKGROUP_X You can use any of the methods listed in Part 2, above. Or... You can add HOST to DOMAIN_A. RUNNING THE MICROSOFT SQL SERVER 2005 AND 2008 USER CREATION SCRIPT Application Security Inc. has written a convenient Microsoft SQL Server 2005 and Microsoft SQL Server 2008 user creation script (CreateUserSQLServer2k52k8PublicRevoked.sql) which creates an account with the minimum privileges necessary to perform Audits on either a Microsoft SQL Server 2005 or a Microsoft SQL Server 2008 instance. Caution! If you want to run this script, make sure whatever account you use to conduct your Audit has at least the SELECT privileges listed in the script (see below). The contents of the CreateUserSQLServer2k52k8PublicRevoked.sql script follow: CREATE LOGIN [aduser] WITH PASSWORD=N'Admin123', DEFAULT_DATABASE=[master] GO EXEC sp_msforeachdb ' USE [?] sql_variant = databasepropertyex(name,"updateability") FROM master.dbo.sysdatabases where databasepropertyex(name,"status")="online" and name = "?" = "READ_WRITE" BEGIN CREATE USER [aduser] FOR LOGIN [aduser] WITH DEFAULT_SCHEMA=[dbo] END' GO USE [master] Application Security, Inc. 289

291 GO GRANT EXECUTE ON dbo.xp_loginconfig TO [aduser] GRANT SELECT ON dbo.syslogins TO [aduser] GRANT SELECT ON dbo.sysdatabases TO [aduser] GRANT SELECT ON dbo.sysconfigures TO [aduser] GRANT SELECT ON dbo.syscurconfigs TO [aduser] GRANT SELECT ON dbo.syscharsets TO [aduser] GRANT SELECT ON sys.configurations TO [aduser] GRANT SELECT ON sys.server_principals TO [aduser] GRANT SELECT ON sys.server_role_members TO [aduser] GRANT ALTER TRACE TO [aduser] GRANT SELECT ON sys.fn_trace_getinfo TO [aduser] EXEC sp_msforeachdb ' sql_variant = databasepropertyex(name,"updateability") FROM master.dbo.sysdatabases where databasepropertyex(name,"status")="online" and name = "?" = "READ_WRITE" BEGIN GRANT EXECUTE ON [?].dbo.sp_helprotect TO [aduser] END' GRANT SELECT ON sys.servers TO [aduser] GRANT EXECUTE ON dbo.sp_helpsrvrolemember TO [aduser] GRANT SELECT ON dbo.fn_trace_geteventinfo TO [aduser] GRANT SELECT ON dbo.fn_trace_getinfo TO [aduser] GRANT SELECT ON sys.databases TO [aduser] GRANT SELECT ON sys.master_key_passwords TO [aduser] GRANT SELECT ON sys.sql_logins TO [aduser] GRANT SELECT ON sys.master_files TO [aduser] Application Security, Inc. 290

292 GRANT SELECT ON sys.procedures TO [aduser] GRANT SELECT ON sys.server_permissions TO [aduser] GRANT SELECT ON sys.all_objects TO [aduser] GRANT SELECT ON sys.certificates TO [aduser] GRANT SELECT ON sys.fulltext_catalogs TO [aduser] GRANT SELECT ON sys.routes TO [aduser] GRANT SELECT ON sys.remote_service_bindings TO [aduser] GRANT SELECT ON sys.services TO [aduser] GRANT SELECT ON sys.service_contracts TO [aduser] GRANT SELECT ON sys.service_message_types TO [aduser] GRANT SELECT ON sys.xml_schema_collections TO [aduser] GRANT SELECT ON sys.assemblies TO [aduser] GRANT SELECT ON sys.http_endpoints TO [aduser] GRANT SELECT ON dbo.sysservers TO [aduser] GRANT SELECT ON dbo.sysservers TO [aduser] GRANT SELECT ON sys.linked_logins TO [aduser] GRANT SELECT ON sys.service_broker_endpoints TO [aduser] GRANT SELECT ON sys.credentials TO [aduser] GRANT EXECUTE ON dbo.sp_helppublication TO [aduser] GRANT EXECUTE ON dbo.sp_helpmergepublication TO [aduser] GRANT EXECUTE ON dbo.sp_helpmergesubscription TO [aduser] GRANT EXECUTE ON dbo.sp_helpsubscription TO [aduser] GRANT EXECUTE ON dbo.sp_help_publication_access TO [aduser] GRANT EXECUTE ON dbo.sp_helpuser TO [aduser] GRANT SELECT ON sys.dm_os_cluster_nodes TO [aduser] GRANT SELECT ON sys.database_files TO [aduser] GRANT EXECUTE ON dbo.sp_helpreplicationdboption TO [aduser] GRANT EXECUTE ON dbo.sp_helprolemember TO [aduser] GRANT SELECT ON dbo.sysprocesses TO [aduser] grant view any definition to [aduser] GRANT VIEW SERVER STATE TO [aduser] GO Application Security, Inc. 291

293 USE [msdb] GO GRANT EXECUTE ON dbo.sp_get_sqlagent_properties TO [aduser] GRANT SELECT ON dbo.sysproxysubsystem TO [aduser] GRANT SELECT ON dbo.sysproxies TO [aduser] GRANT EXECUTE ON dbo.sp_enum_login_for_proxy TO [aduser] GRANT SELECT ON dbo.sysjobs ([name],[job_id]) TO [aduser] GRANT SELECT ON dbo.sysjobhistory ([job_id]) TO [aduser] GRANT SELECT ON dbo.syssubsystems ([subsystem],[subsystem_id]) TO [aduser] GRANT SELECT ON [dbo].[sysjobsteps] ([proxy_id],[subsystem], [job_id]) TO [aduser] GRANT SELECT ON dbo.sysjobs TO [aduser] GO EXEC sp_msforeachdb ' USE [?] sql_variant = databasepropertyex(name,"updateability") FROM master.dbo.sysdatabases where databasepropertyex(name,"status")="online" and name = "?" = "READ_WRITE" BEGIN GRANT SELECT ON dbo.sysusers TO [aduser] GRANT SELECT ON dbo.sysobjects TO [aduser] GRANT SELECT ON dbo.syscomments TO [aduser] GRANT VIEW DEFINITION TO [aduser] GRANT SELECT ON sys.database_permissions TO [aduser] GRANT SELECT ON sys.objects TO [aduser] GRANT SELECT ON sys.asymmetric_keys TO [aduser] GRANT SELECT ON sys.database_principals TO [aduser] GRANT SELECT ON sys.key_encryptions TO [aduser] GRANT SELECT ON sys.symmetric_keys TO [aduser] GRANT SELECT ON sys.types TO [aduser] Application Security, Inc. 292

294 GRANT SELECT ON sys.sysmembers TO [aduser] GRANT SELECT ON sys.database_role_members TO [aduser] GRANT SELECT ON sys.schemas TO [aduser] GRANT SELECT ON sys.system_objects TO [aduser] END' GO REGISTRY ACCESS FOR MICROSOFT SQL SERVER 2000, 2005, AND 2008 Some Microsoft SQL Server 2000, 2005, and 2008 Audit privileges require you to have remote registry access in order to perform Audits on Microsoft SQL Server instances. These required Audit privileges are listed in: Microsoft SQL Server 2000 and MSDE Audit Privileges (for all applicable Microsoft SQL Server 2000 Audit privileges) Microsoft SQL Server 2005 and Microsoft SQL Server 2008 Audit Privileges (for all applicable Microsoft SQL Server 2005 and 2008 Audit privileges). Depending on your version of Microsoft SQL Server 2000, 2005, and 2008 (and whether you are using Microsoft SQL Server Authentication or Windows Authentication), you can get the remote registry value in either of the following two ways: 2. Via the xp_regread extended stored procedure (explained in the following table). If your version of Microsoft SQL Server is: Microsoft SQL Server 2000 (service pack prior to SP4) And you are using: Microsoft SQL Server Authentication Windows Authentication Detail Grant execute on xp_regread to the DbProtect Vulnerability Assessment user or the Public role. Grant execute on xp_regread to the Windows user or to the Public role, and permissions on the key being accessed. Application Security, Inc. 293

295 If your version of Microsoft SQL Server is: Microsoft SQL Server 2000 SP4 and Microsoft SQL Server 2005 or 2008 And you are using: Microsoft SQL Server Authentication Windows Authentication Microsoft SQL Server Authentication or Windows Authentication Detail Grant execute on xp_regread to the DbProtect Vulnerability Assessment user or the Public role. Grant execute on xp_regread to Windows user or the Public role, and permissions on the key being accessed. Although authentication mode (i.e., Microsoft SQL Server Authentication or Windows Authentication) is used, DbProtect Vulnerability Assessment requires an entry on the target (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft \Microsoft SQL Server\<INSTANCE>\MSSQLServer\ ExtendedProcedures\Xp_regread Allowed Paths) of the requested registry subkey. (Reference: support.microsoft.com/kb/887165) Since the Microsoft SQL Server installation program pre-populates the Xp_regread Allowed Paths registry entry with the extended stored procedures that Microsoft SQL Server can access, you only need to add the following registry entries: HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Microsoft SQL Server\Instance Names\SQL HKEY_LOCAL_MACHINE\SYSTEM\Current ControlSet\Services\MSSQLServerOLAP Service HKEY_LOCAL_MACHINE\SYSTEM\Current ControlSet\Services\ReportServer 3. Get the remote registry value via the Windows Remote Registry API, and provide a valid Windows account with remote registry access. Application Security, Inc. 294

296 MySQL Audit Privileges Note: For more information on MySQL Server OS check requirements, see Operating System Considerations (for Audits). To conduct a full MySQL Audit, you need the following privileges. Make sure the account you are using has rights to use the following tables and views: Anonymous user exists: SELECT on user table Blank account passwords: SELECT on user table Blank root password: SELECT on user table Default passwords for test accounts: SELECT on user table Easily-guessed account passwords: SELECT on user table Easily-guessed root password: SELECT on user table FILE privileges granted: SELECT on user table General log file not enabled: execute SHOW VARIABLES Password for user same as username: SELECT on user table Permissions grantable: SELECT on the user table, SELECT on the db table, SELECT on the host table, SELECT on the tables_priv table, and SELECT on the procs_priv table Permissions on GRANT tables: SELECT on the user table, SELECT on the db table, SELECT on the host table, SELECT on the tables_priv table, SELECT on the procs_priv table, and SELECT on the columns_priv' table Permissions on user table: SELECT on the user table, SELECT on the db table, SELECT on the host table, SELECT on the tables_priv table, and SELECT on the columns_priv table. PROCESS privileges granted: SELECT on user table Sample database not removed: execute SHOW DATABASES SSL encryption not enabled: execute SHOW VARIABLES Grant SELECT on procs_priv Note: The Grant SELECT on procs_priv privilege is only required on the Permissions on GRANT tables and Permissions grantable MySQL Audit checks on MySQL 5.0 and greater. MYSQL CHECKS MySQL Audit Easily-guessed root password Easily-guessed passwords Blank password Blank root password Universal access SSL is enabled Grant tables privileges Application Security, Inc. 295

297 Ensure sample databases have been removed Permissions on [User] table Permissions granted directly to user Logging not enabled MySQL mysqld Privilege Escalation Vulnerability MySQL libmysqlclient Library Read_One_Row Buffer Overflow Vulnerability MySQL COM_CHANGE_USER Password Memory Corruption Vulnerability MySQL Double Free Heap Corruption Vulnerability MySQL COM_CHANGE_USER Password Length Account Compromise Vulnerability MySQL libmysqlclient Library Read_Rows Buffer Overflow Vulnerability MySQL COM_TABLE_DUMP Memory Corruption Vulnerability MySQL COM_TABLE_DUMP Memory Corruption Vulnerability MySQL Bind Address Not Enabled Weak Default Configuration Vulnerability MySQL Null Root Password Weak Default Configuration Vulnerability WinMySQLadmin Plain Text Password Storage Vulnerability MySQL Root Operation Symbolic Link File Overwriting Vulnerability MySQL SHOW GRANTS Password Hash Disclosure Vulnerability MySQL Local Buffer Overflow Vulnerability MySQL Authentication Algorithm Vulnerability MySQL GRANT Global Password Changing Vulnerability MySQL Unauthenticated Remote Access Vulnerability Permissions on GRANT tables Permissions grantable Note: The Grant SELECT on procs_priv privilege is only required on the Permissions on GRANT tables and Permissions grantable MySQL Audit checks on MySQL 5.0 and greater. MySQL Pen Test Easily-guessed root password Easily-guessed password Blank password Blank root password MySQL mysqld Privilege Escalation Vulnerability MySQL libmysqlclient Library Read_One_Row Buffer Overflow Vulnerability MySQL COM_CHANGE_USER Password Memory Corruption Vulnerability Application Security, Inc. 296

298 MySQL Double Free Heap Corruption Vulnerability MySQL COM_CHANGE_USER Password Length Account Compromise Vulnerability MySQL libmysqlclient Library Read_Rows Buffer Overflow Vulnerability MySQL COM_TABLE_DUMP Memory Corruption Vulnerability MySQL COM_TABLE_DUMP Memory Corruption Vulnerability MySQL Bind Address Not Enabled Weak Default Configuration Vulnerability MySQL Null Root Password Weak Default Configuration Vulnerability WinMySQLadmin Plain Text Password Storage Vulnerability MySQL Root Operation Symbolic Link File Overwriting Vulnerability MySQL SHOW GRANTS Password Hash Disclosure Vulnerability MySQL Local Buffer Overflow Vulnerability MySQL Authentication Algorithm Vulnerability MySQL GRANT Global Password Changing VulnerabilityMySQL MySQL Unauthenticated Remote Access Vulnerability Oracle Audit Privileges and User Creation Script Note: For more information on Oracle OS check requirements, see Operating System Considerations (for Audits) and Appendix O: Oracle Critical Patch Update Detection in the AppDetectivePro User s Guide. This topic consists of the following sub-topics: Oracle Audit Privileges Running the Oracle User Creation Script. ORACLE AUDIT PRIVILEGES To conduct a full Oracle Audit, you need the following privileges. Make sure the account you are using has rights to use the following tables, views, and functions: $PWFILE_USERS ALTER USER username TEMPORARY TABLESPACE TEMP DBA_OBJ_AUDIT_OPTS DBA_OBJECTS DBA_PROFILES DBA_ROLES DBA_ROLE_PRIVS DBA_STMT_AUDIT_OPTS DBA_SYS_PRIVS DBA_TABLES Application Security, Inc. 297

299 Note: DBA_TAB_PRIVS DBA_USERS DBA_VIEWS DBMS_UTILITY.PORT_STRING PRODUCT_COMPONENT_VERSION SYS.LINK$ SYS.USER$ SYS.REGISTRY$HISTORY SYS.DBA_DB_LINKS SYS.DBA_LIBRARIES SYS.DBA_OBJECTS SYS.DBA_ROLE_PRIVS SYS.DBA_SOURCE SYS.DBA_USERS SYS.DBA_DB_LINKS SYS.V_$INSTANCE SYS.DBA_TS_QUOTAS V$LOG V$PWFILE_USERS V$VERSION V_$DATABASE V_$DATAFILE V_$LOGFILE V_$SESSION V_$PARAMETER (DbProtect Vulnerability Assessment selects from V$PARAMETER but you must grant SELECT on V_$PARAMETER) The user account must have the CREATE SESSION privilege. In addition, the user account used for Audits needs a temporary table space assigned, which you can create with the following command: ALTER USER username TEMPORARY TABLESPACE TEMP The following script creates an account with the minimum privileges necessary to perform a Security Audit on an Oracle SID. Be sure that whatever account is used to conduct your Audit has at least the SELECT privileges listed below: DROP USER aduser cascade; CREATE USER aduser IDENTIFIED BY AD123; GRANT SELECT ON SYS.DBA_DB_LINKS TO aduser; GRANT SELECT ON SYS.DBA_DATA_FILES TO aduser; GRANT SELECT ON SYS.DBA_OBJECTS TO aduser; GRANT SELECT ON SYS.DBA_OBJ_AUDIT_OPTS TO aduser; Application Security, Inc. 298

300 GRANT SELECT ON SYS.DBA_PROCEDURES TO aduser; GRANT SELECT ON SYS.DBA_PROFILES TO aduser; GRANT SELECT ON SYS.DBA_ROLES TO aduser; GRANT SELECT ON SYS.DBA_ROLE_PRIVS TO aduser; GRANT SELECT ON SYS.DBA_STMT_AUDIT_OPTS TO aduser; GRANT SELECT ON SYS.DBA_SYS_PRIVS TO aduser; GRANT SELECT ON SYS.DBA_TABLES TO aduser; GRANT SELECT ON SYS.DBA_INDEXES TO aduser; GRANT SELECT ON SYS.DBA_TAB_PRIVS TO aduser; GRANT SELECT ON SYS.DBA_TS_QUOTAS TO aduser; GRANT SELECT ON SYS.DBA_USERS TO aduser; GRANT SELECT ON SYS.DBA_SOURCE TO aduser; GRANT SELECT ON SYS.DBA_VIEWS TO aduser; GRANT SELECT ON SYS.PRODUCT_COMPONENT_VERSION TO aduser; GRANT SELECT ON SYS.LINK$ TO aduser; GRANT SELECT ON SYS.USER$ TO aduser; GRANT SELECT ON SYS.V_$PARAMETER TO aduser; GRANT SELECT ON SYS.V_$LOG TO aduser; GRANT SELECT ON SYS.V_$PWFILE_USERS TO aduser; GRANT SELECT ON SYS.V_$INSTANCE TO aduser; GRANT SELECT ON SYS.V_$DATABASE TO aduser; GRANT SELECT ON SYS.DBA_PRIV_AUDIT_OPTS TO aduser; GRANT SELECT ON SYS.DBA_REPCATLOG TO aduser; GRANT SELECT ON SYS.DEFPROPAGATOR TO aduser; GRANT SELECT ON SYS.V_$DATAFILE TO aduser; GRANT SELECT ON SYS.V_$LOGFILE TO aduser; GRANT SELECT ON SYS.V_$SESSION TO aduser; GRANT SELECT ON SYS.REGISTRY$HISTORY TO aduser; GRANT CREATE SESSION TO aduser; grant javasyspriv to aduser; grant create procedure to aduser; Application Security, Inc. 299

301 The following is a list of checks within the DbProtect Vulnerability Assessment for Oracle Security Audit, and the tables and views which they need permission to in order to function properly: Note: _TRACE_FILES_PUBLIC undocumented configuration parameter is NOT set to FALSE This check requires SYSDBA privileges, and, because of this, it is not part of any built-in Policies. Account associated with DEFAULT profile: DBA_USERS Account granted the predefined role CONNECT: DBA_ROLE_PRIVS Account granted the predefined role DBA: DBA_ROLE_PRIVS Account granted the predefined role RESOURCE: DBA_ROLE_PRIVS Accounts with SYSTEM as default tablespace: DBA_USERS ANSI join syntax bypasses object privileges: PRODUCT_COMPONENT_VERSION ANY system privilege applies to data dictionary: V$PARAMETER Auditing Not Enabled: V$PARAMETER Auditing of CREATE SESSION not enabled: DBA_STMT_AUDIT_OPTS BFILENAME buffer overflow (Verify version):product_component_version Brute-force database password: DBA_USERS Brute-force role password: SYS.USER$ Cleartext password stored with database link: SYS.LINK$ Create library privilege: DBA_SYS_PRIVS, PRODUCT_COMPONENT_VERSION Database link buffer overflow (Verify version):product_component_version Database user allows remote authentication: DBA_USERS, V$PARAMETER DBLINK_ENCRYPT_LOGIN not enabled: SYS.LINK$, V$PARAMETER DBMS dedicated software directory and partition: V$DATAFILE, V$LOGFILE, V$PARAMETER Default database password: DBA_USERS Easily-guessed database password: DBA_USERS Easily-guessed role password: SYS.USER$ Expired password: DBA_USERS, PRODUCT_COMPONENT_VERSION Kick Listener DoS (Verify version): PRODUCT_COMPONENT_VERSION Label Security row label improperly assigned: PRODUCT_COMPONENT_VERSION Label Security SQL predicates bypassed: PRODUCT_COMPONENT_VERSION Application Security, Inc. 300

302 Label Security unauthorized higher level read: PRODUCT_COMPONENT_VERSION Listener debug DoS (Verify version): PRODUCT_COMPONENT_VERSION Listener format string buffer overflow (Verify version): PRODUCT_COMPONENT_VERSION Locked account: DBA_USERS, PRODUCT_COMPONENT_VERSION MTDS DoS (Verify version): PRODUCT_COMPONENT_VERSION NERP DoS (Verify version): PRODUCT_COMPONENT_VERSION Non-standard account with DBA role: DBA_ROLE_PRIVS NSPTCN buffer overflow (Verify version): PRODUCT_COMPONENT_VERSION NSPTCN data offset DoS (Verify version): PRODUCT_COMPONENT_VERSION Object privilege grantable: DBA_TAB_PRIVS Object privilege granted to account: DBA_TAB_PRIVS, DBA_USERS Object privilege granted to PUBLIC: DBA_TAB_PRIVS Oracle Configuration Manager: DBA_USERS Oracle DIAGNOSTIC_DEST parameter: V$PARAMETER Oracle file overwrite: PRODUCT_COMPONENT_VERSION Oracle LOG_ARCHIVE_DEST parameter: V$DATABASE, V$PARAMETER OS authentication prefix: V$PARAMETER Overdue password change: sys.user$ Password for database user same as username: DBA_USERS Privilege granted to SELECT from data dictionary: DBA_TABLES, DBA_TAB_PRIVS Privilege on audit trail table: DBA_TAB_PRIVS Privilege on database link table: DBA_TAB_PRIVS, DBA_USERS Privilege to execute UTL_FILE granted to PUBLIC: DBA_TAB_PRIVS Privilege to execute UTL_HTTP granted to PUBLIC: DBA_TAB_PRIVS Privilege to execute UTL_SMTP granted to PUBLIC: DBA_TAB_PRIVS Privilege to execute UTL_TCP granted to PUBLIC: DBA_TAB_PRIVS Profile settings - Failed Login Attempts: DBA_PROFILES, PRODUCT_COMPONENT_VERSION Profile settings - Password Grace Time: DBA_PROFILES, PRODUCT_COMPONENT_VERSION Profile settings - Password Life Time: DBA_PROFILES, PRODUCT_COMPONENT_VERSION Profile settings - Password Lock Time: DBA_PROFILES, PRODUCT_COMPONENT_VERSION Application Security, Inc. 301

303 Profile settings - Password Reuse Maximum: DBA_PROFILES, PRODUCT_COMPONENT_VERSION Profile settings - Password Reuse Time: DBA_PROFILES, PRODUCT_COMPONENT_VERSION Profile settings - Password Verify Function: DBA_PROFILES, PRODUCT_COMPONENT_VERSION Remote login password file not disabled: V$PARAMETER Remote OS Authentication enabled: V$PARAMETER Remote OS Roles enabled: V$PARAMETER Requestor version DoS (Verify version): PRODUCT_COMPONENT_VERSION Role without password: DBA_ROLES Roles granted WITH ADMIN OPTION: DBA_ROLE_PRIVS SERVICE_CURLOAD DoS (Verify version): PRODUCT_COMPONENT_VERSION SERVICE_NAME buffer overflow (Verify version): PRODUCT_COMPONENT_VERSION SNMP DoS (Verify version): PRODUCT_COMPONENT_VERSION SQL92_SECURITY parameter not enabled: V$PARAMETER SYSDBA auditing bug: PRODUCT_COMPONENT_VERSION SYSDBA privilege assignments System privilege granted to account: DBA_SYS_PRIVS, DBA_USERS System privilege granted to PUBLIC: DBA_SYS_PRIVS System privilege granted WITH ADMIN OPTION: DBA_SYS_PRIVS System privilege with ANY clause: DBA_SYS_PRIVS TCL debugger installs with setuid root: DBA_SYS_PRIVS TCL debugger installs with setuid root: PRODUCT_COMPONENT_VERSION TO_TIMESTAMP_TZ buffer overflow (Verify version):product_component_version TZ_OFFSET buffer overflow (Verify version):product_component_version Trace reporting buffer overflow: PRODUCT_COMPONENT_VERSION UTL_FILE_DIR unrestricted: V$PARAMETER XSQL Servlet stylesheet as URL parameter: PRODUCT_COMPONENT_VERSION Auditing of Schema Objects: DBA_OBJ_AUDIT_OPTS, DBA_VIEWS Application Security, Inc. 302

304 RUNNING THE ORACLE USER CREATION SCRIPT Application Security Inc. has written a convenient Oracle user creation script (CreateUserSQLServer2k.sql) which creates an account with the minimum privileges necessary to perform Audits on a Microsoft SQL 2000 instance. The contents of the CreateUserSQLServer2k.sql script follow: DROP USER aduser cascade; CREATE USER aduser IDENTIFIED BY AD123; GRANT SELECT ON SYS.DBA_DB_LINKS TO aduser; GRANT SELECT ON SYS.DBA_DATA_FILES TO aduser; GRANT SELECT ON SYS.DBA_OBJECTS TO aduser; GRANT SELECT ON SYS.DBA_OBJ_AUDIT_OPTS TO aduser; GRANT SELECT ON SYS.DBA_PROCEDURES TO aduser; GRANT SELECT ON SYS.DBA_PROFILES TO aduser; GRANT SELECT ON SYS.DBA_ROLES TO aduser; GRANT SELECT ON SYS.DBA_ROLE_PRIVS TO aduser; GRANT SELECT ON SYS.DBA_STMT_AUDIT_OPTS TO aduser; GRANT SELECT ON SYS.DBA_SYS_PRIVS TO aduser; GRANT SELECT ON SYS.DBA_TABLES TO aduser; GRANT SELECT ON SYS.DBA_INDEXES TO aduser; GRANT SELECT ON SYS.DBA_TAB_PRIVS TO aduser; GRANT SELECT ON SYS.DBA_TS_QUOTAS TO aduser; GRANT SELECT ON SYS.DBA_USERS TO aduser; GRANT SELECT ON SYS.DBA_SOURCE TO aduser; GRANT SELECT ON SYS.DBA_VIEWS TO aduser; GRANT SELECT ON SYS.PRODUCT_COMPONENT_VERSION TO aduser; GRANT SELECT ON SYS.LINK$ TO aduser; GRANT SELECT ON SYS.USER$ TO aduser; GRANT SELECT ON SYS.V_$PARAMETER TO aduser; GRANT SELECT ON SYS.V_$LOG TO aduser; GRANT SELECT ON SYS.V_$PWFILE_USERS TO aduser; GRANT SELECT ON SYS.V_$INSTANCE TO aduser; GRANT SELECT ON SYS.V_$DATABASE TO aduser; GRANT SELECT ON SYS.DBA_PRIV_AUDIT_OPTS TO aduser; GRANT SELECT ON SYS.DBA_REPCATLOG TO aduser; GRANT SELECT ON SYS.DEFPROPAGATOR TO aduser; Application Security, Inc. 303

305 GRANT SELECT ON SYS.V_$DATAFILE TO aduser; GRANT SELECT ON SYS.V_$LOGFILE TO aduser; GRANT SELECT ON SYS.V_$SESSION TO aduser; GRANT SELECT ON SYS.REGISTRY$HISTORY TO aduser; GRANT CREATE SESSION TO aduser; grant javasyspriv to aduser; grant create procedure to aduser; Sybase Audit Privileges To conduct a full Sybase Audit, you need the following privileges. Make sure the account you are using has rights to use the following tables and views: master.dbo.syslogins master.dbo.syssrvroles master.dbo.sysdatabases master.dbo.sysconfigures master.dbo.syscurconfigs master.dbo.sysroles master.dbo.sysloginroles master.dbo.sysattributes master.dbo.sysservers exec sp_loginconfig exec sp_displayaudit (if it's >= 11.5) sp_auditoption (if it's < 11.5 and >= 11.0) master.dbo.syblicenseslog master.dbo.syscharsets <db name>.dbo.sysusers <db name>.dbo.sysobjects <db name>.dbo.syscomments exec <db name>.dbo.sp_help_resource_limit (if it's >= 11.5) Application Security, Inc. 304

306 The following is a list of checks within the DbProtect Vulnerability Assessment for Sybase Security Audit, and the tables and views which they need permission to in order to function properly: Audit database owned by sa_role member: master.dbo.syslogins, master.dbo.sysloginroles, master.dbo.syssrvroles, <dbname>.dbo.sysusers Guest user exists in sybsecurity: master.dbo.syslogins, master.dbo.syssrvroles, <dbname>.dbo.sysusers Login granted sa_role: master.dbo.syslogins, master.dbo.sysloginroles, master.dbo.syssrvroles, <dbname>.dbo.sysusers Login granted sso_role: master.dbo.syslogins, master.dbo.sysloginroles, master.dbo.syssrvroles, <dbname>.dbo.sysusers Objects not owned by dbo: master.dbo.syslogins, master.dbo.syssrvroles, <dbname>.dbo.sysusers, <dbname>.dbo.sysobjects Permission granted in sybsecurity: master.dbo.syslogins, master.dbo.syssrvroles, <dbname>.dbo.sysobjects Permission granted on system table: master.dbo.syslogins, master.dbo.syssrvroles, <dbname>.dbo.sysobjects Permission granted on xp_cmdshell: master.dbo.syslogins, master.dbo.syssrvroles, <dbname>.dbo.sysobjects Permission to select from syslogins: master.dbo.syslogins, master.dbo.syssrvroles Permissions granted to public: master.dbo.syslogins, master.dbo.syssrvroles, <dbname>.dbo.sysusers Permissions granted to user: master.dbo.syslogins, master.dbo.syssrvroles, <dbname>.dbo.sysusers Remote access allowed: master.dbo.syslogins, master.dbo.syssrvroles Roles revoked from the sa login: master.dbo.syslogins, master.dbo.sysloginroles, master.dbo.syssrvroles Server configured with remote server: master.dbo.syslogins, master.dbo.syssrvroles Statement permission granted: master.dbo.syslogins, master.dbo.syssrvroles, <dbname>.dbo.sysusers Unrestricted access to syscomments: master.dbo.syslogins, master.dbo.syssrvroles Updates allowed to system tables: master.dbo.syslogins, master.dbo.syssrvroles With grant option: master.dbo.syslogins, master.dbo.syssrvroles, <dbname>.dbo.sysusers xp_cmdshell context: master.dbo.syslogins, master.dbo.syssrvroles, <dbname>.dbo.sysobjects Absolute value of numeric DoS (Verify version): master.dbo.syslogins, master.dbo.syssrvroles Application Security, Inc. 305

307 Allow resource limit: master.dbo.syslogins, master.dbo.syssrvroles Audit logout not set: sybsystemprocs.dbo.sp_loginconfig, sso_role Audit queue size: master.dbo.syslogins, master.dbo.syssrvroles Audit subsystem not installed: master.dbo.syslogins, master.dbo.syssrvroles Auditing disabled: sybsystemprocs.dbo.sp_loginconfig, sso_role Auditing of failed logins not enabled: sybsystemprocs.dbo.sp_loginconfig, sso_role Auditing of successful logins not enabled: sybsystemprocs.dbo.sp_loginconfig, sso_role Current audit table: master.dbo.syslogins, master.dbo.syssrvroles DBCC CHECKVERIFY buffer overflow: master.dbo.syslogins, master.dbo.syssrvroles DROP DATABASE buffer overflow: master.dbo.syslogins, master.dbo.syssrvroles Event log computer name: master.dbo.syslogins, master.dbo.syssrvroles Event logging: master.dbo.syslogins, master.dbo.syssrvroles Exceeded licensing limitations: master.dbo.syblicenseslog Latest patch not applied: master.dbo.syslogins, master.dbo.syssrvroles List resource limits: master.dbo.syslogins, master.dbo.syssrvroles Log audit logon failure: master.dbo.syslogins, master.dbo.syssrvroles Log audit logon success: master.dbo.syslogins, master.dbo.syssrvroles No patches available for version: master.dbo.syslogins, master.dbo.syssrvroles Password array buffer overflow: master.dbo.syslogins, master.dbo.syssrvroles Require message confidentiality with encryption: master.dbo.syslogins, master.dbo.syssrvroles Require message integrity: master.dbo.syslogins, master.dbo.syssrvroles Select all DoS (Verify version): master.dbo.syslogins, master.dbo.syssrvroles Select/Into DoS (Verify version): master.dbo.syslogins, master.dbo.syssrvroles SSL enabled: master.dbo.syslogins, master.dbo.syssrvroles Start mail session: master.dbo.syslogins, master.dbo.syssrvroles Suspend audit when full disabled: master.dbo.syslogins, master.dbo.syssrvroles Vulns for v ESD#1 (Verify version): master.dbo.syslogins, master.dbo.syssrvroles xp_cmdshell not removed: master.dbo.syslogins, master.dbo.syssrvroles, <dbname>.dbo.sysobjects Application Security, Inc. 306

308 xp_freedll buffer overflow: master.dbo.syslogins, master.dbo.syssrvroles, <dbname>.dbo.sysobjects Blank password for sa: master.dbo.syslogins, master.dbo.syssrvroles Check password for digit: master.dbo.syslogins, master.dbo.syssrvroles Default login exists: sybsystemprocs.dbo.sp_loginconfig, sso_role Default login granted role: sybsystemprocs.dbo.sp_loginconfig, sso_role Default password for dba repository user: master.dbo.syslogins, master.dbo.syssrvroles Default password for entldbdbo: master.dbo.syslogins, master.dbo.syssrvroles Default password for entldbreader: master.dbo.syslogins, master.dbo.syssrvroles Default password for jagadmin: master.dbo.syslogins, master.dbo.syssrvroles Default password for PIAdmin: master.dbo.syslogins, master.dbo.syssrvroles Default password for pkiuser: master.dbo.syslogins, master.dbo.syssrvroles Default password for PortalAdmin: master.dbo.syslogins, master.dbo.syssrvroles Default password for pso: master.dbo.syslogins, master.dbo.syssrvroles Default SAP password: master.dbo.syslogins, master.dbo.syssrvroles Easily-guessed password: master.dbo.syslogins, master.dbo.syssrvroles Easily-guessed sa password: master.dbo.syslogins, master.dbo.syssrvroles Expired logins: master.dbo.syslogins, master.dbo.syssrvroles Guest user exists in database: master.dbo.syslogins, master.dbo.syssrvroles, <dbname>.dbo.sysusers Locked logins: master.dbo.syslogins, master.dbo.syssrvroles Login attributes less restrictive: master.dbo.syslogins, master.dbo.syssrvroles Login mode: sybsystemprocs.dbo.sp_loginconfig, sso_role Maximum failed logins: master.dbo.syslogins, master.dbo.syssrvroles Minimum password length: master.dbo.syslogins, master.dbo.syssrvroles Orphaned user: master.dbo.syslogins, master.dbo.syssrvroles, <dbname>.dbo.sysusers Password same as login name: master.dbo.syslogins, master.dbo.syssrvroles Per login password expiration: master.dbo.syslogins, master.dbo.syssrvroles Application Security, Inc. 307

309 Roles without passwords: master.dbo.syslogins, master.dbo.syssrvroles Secure default login exists: master.dbo.syslogins, master.dbo.syssrvroles System-wide password expiration: master.dbo.syslogins, master.dbo.syssrvroles Unified login required: master.dbo.syslogins, master.dbo.syssrvroles Unlocked sa login: master.dbo.syslogins, master.dbo.syssrvroles Use security services: master.dbo.syslogins, master.dbo.syssrvroles Not using NTFS partition: master.dbo.syslogins, master.dbo.syssrvroles Permissions on files: master.dbo.syslogins, master.dbo.syssrvroles Registry permissions: master.dbo.syslogins, master.dbo.syssrvroles Service runs as LocalSystem: master.dbo.syslogins, master.dbo.syssrvroles Setgid bit enabled: master.dbo.syslogins, master.dbo.syssrvroles Setuid bit enabled: master.dbo.syslogins, master.dbo.syssrvroles Operating System Considerations (for Audits) Some DbProtect Vulnerability Assessment Audit checks require more than just a valid database account to perform correctly. They have different requirements depending upon whether the operating system (OS) is Windows or UNIX. (The checks are listed in the Audit category OS Integrity.) They only run if the target database has the appropriate OS. This topic consists of the following sub-topics: Windows OS Audit Check Requirements UNIX OS Audit Check Requirements. WINDOWS OS AUDIT CHECK REQUIREMENTS DbProtect Vulnerability Assessment performs Windows OS checks via Windows authentication. Make sure the account and computer you are running DbProtect Vulnerability Assessment from has the appropriate permissions for the corresponding checks: Not Using NTFS Partition. Permission to read the installation disk type. Registry Permissions. Remote registry access. Service Runs as Local System. Permission to list the system services. Permissions on Files. Permission to read files in the installation directory of the database. Application Security, Inc. 308

310 UNIX OS AUDIT CHECK REQUIREMENTS DbProtect Vulnerability Assessment performs Unix OS checks via a Telnet or SSH account. Your account must have the appropriate read and directory listing permissions activated on the database installation and running directories. If you run the following checks: Permissions on Files Then you must have permission to: List files in the installation directories of the database. Setgid Bit Enabled Setuid Bit Enabled Properly-Configured Environment Variables DbProtect Vulnerability Assessment can Audit platforms that use system variables to specify the location of the database instances. In UNIX, you must set the environment variables correctly in order to use SSH or Telnet to access the accounts. Specific requirements follow. If you want to Audit the following platform: Oracle Sybase MySQL Then you must have permission to: Make sure the $ORACLE_HOME variable is correct. Make sure the $SYBASE variable is correct. Define a datadir or basedir variable to point to the database root. Application Security, Inc. 309

311 Appendix M: Auditing SQL Server (Using Windows Authentication) Against a Machine on a Different or Untrusted Domain If you attempt to Audit a SQL Server database (using Windows Authentication) against a machine on a different or untrusted domain, the following error message may display: SQLSTATE: 28000, Native error: 18452, Message: [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user ''. The user is not associated with a trusted SQL Server connection.. To Audit a SQL Server database (using Windows Authentication) against a machine on a different or untrusted domain: 1. Establish a connection to the target server. Enter the appropriate Net Use syntax. For a remote host that is a: member of domain, enter: net use \\ip /user:domain\username workgroup member (standalone computer), enter: net use \\ip / user:username or net use \\ip /user:computername\username 2. Use named pipes to connect to an untrusted domain. Select the Properties branch option Connect to Microsoft SQL Servers via Named Pipes. You must check this option when Auditing a SQL Server database in an untrusted domain. Note: You must enable the named pipes protocol on both the Scan Engine host and the SQL Server target server when using this option. 3. Make sure of the following: That the Server and Remote Registry services on your remote host are running That the Net Use set of credentials file being used is a member of either the domain hosting the target server, or a domain that is trusted by that domain Application Security, Inc. 310

312 That login provides remote registry access and read-only file access to the remote machine. To check this, do the following: -enter: net use \\server with your credentials, and expand HKEY_LOCAL_MACHINE on the target server -enter: net use \\server\c$ to verify you can access files on the target server. That access to the remote host can be restricted by firewall, which is common on Windows You can verify this on the remote host by looking into the firewall settings/logs for rejects packets. This means there should be connectivity on port 445 or 139 on the target host. 4. Do the following to create and test a DSN connection to the target host: Choose Control Panel > Administrative Tools > Data Sources (ODBC). Open the System DSN tab and click the Add button. Choose Microsoft SQL Server from the list. Click the Finish button. Enter a Name and Description for this data source entry. In the Server field, enter the IP address and listening port of the target server, e.g., ,1756. Click the Next button. Select SQL Server Authentication and enter your database credentials in the Login ID and Password fields. Click the Next button. Follow the steps in the wizard. 5. You should now be able to test the connection to the data source. If this test is successful, you should also be able to perform the Audit with the Scan Engine. If you are unable to connect, try using the other IP address, or use Windows Authentication rather than the SQL credentials (after connecting with Net Use). Application Security, Inc. 311

313 Appendix N: Troubleshooting the Java Run Time Environment (JRE) Security Settings on Internet Explorer 6 and 7 If you are experiencing difficulty logging into the DbProtect Console, you may need to troubleshoot the Java Runtime Environment (JRE) security settings on your Internet Explorer (IE) 6 or greater web browser. This appendix explains how. If your web browser is IE 6. Proper Active X controls and enable third-party browser extensions security settings may not be enabled on your IE 6 browser. If this is the case, you will encounter an error message you attempt to authenticate, and you can t log in to the DbProtect Console. To troubleshoot this problem, see Enabling proper Active X controls and enable third-party browser extensions security settings (using IE 6). If your web browser is IE 7. JRE 1.6 may be disabled and/or multiple JREs may be enabled on your client (i.e., the location from which your IE 7 browser is running). JRE 1.6 must be enabled in order for you to connect to the DbProtect Console. If JRE 1.6 is disabled, or if multiple JREs of different versions are enabled on your client, then you will encounter an error message when you attempt to authenticate, and you can t log in to the DbProtect Console. To troubleshoot this problem, see Ensuring JRE 1.6 is enabled and temporarily disabling other JREs on your client machine (using IE 7). Application Security, Inc. 312

314 Enabling proper Active X controls and enable thirdparty browser extensions security settings (using IE 6) Note: The following security settings should be the default values in your IE 6 web browser. You should only change the settings if you re experiencing difficulty logging into the DbProtect Console. To enable proper Active X controls and enable third-party browser extensions security settings on IE 6: 1. Launch IE Do the following to display the Security Settings dialog box: Choose: Tools > Internet Options. Click the Security tab. Click the Custom Level button. 3. Set the following security settings to Enable or Prompt: Download signed ActiveX controls Run ActiveX controls and plug-ins. 4. Click the OK button. 5. Click the Advanced tab. The Security Settings dialog box displays. FIGURE: Internet Explorer Advanced Settings dialog box 6. Check Enable Third-party browser extensions (requires restart). 7. Click the OK button. 8. Close and re-launch IE 6. Application Security, Inc. 313

315 Try to log back into the DbProtect Console. If you continue to experience trouble, contact Application Security, Inc. Customer Support at Ensuring JRE 1.6 is enabled and temporarily disabling other JREs on your client machine (using IE 7) To ensure JRE 1.6 is enabled, and to temporarily disable multiple JREs on your client machine (using IE 7): 1. Launch IE Do the following: Choose: Tools > Internet Options. Click the Advanced tab to display the Settings dialog box. 3. Scroll down to the Java (Sun) portion of the dialog box and verify the following: JRE 1.6 is enabled (i.e., the box must be checked) multiple JRE installations are listed. JRE 1.6 must be enabled in order for you to connect to the Console. If it is not, check the JRE 1.6 box. If JRE 1.6 is enabled, and other JRE versions are also enabled, then you must temporarily disable them by un-checking the boxes. 4. Do the following: Click the Apply button. Click the OK button. Close and re-launch IE Try to log back into the Console. If you continue to experience trouble, contact Application Security, Inc. Customer Support at Application Security, Inc. 314

316 Appendix O: Clearing Your Java Cache If you are experiencing difficulty logging into the DbProtect Console, you may need to clear your Java cache. Application Security, Inc. also recommends you clear your Java cache after an upgrade. The Java cache does not get automatically cleared following a reboot. To clear your Java cache: 1. Choose Start > Control Panel to display the Control Panel. 2. Double click the Java icon to display the Java Control Panel dialog box. 3. With the default General tab selected, click the Settings... button (in the Temporary Internet Files section of the dialog box) to display the Temporary Files Settings dialog box. 4. Click the Delete Files... button to clear your Java cache. 5. Close your web browser and attempt to log into the DbProtect Console again. Application Security, Inc. 315

317 Appendix P: Monitoring Multiple Instances on a DB2 Server To monitor multiple instances on an DB2 server: 1. Install one host-based Sensor for DB2 (on any *nix platform) for each instance you want to monitor; for more information, see: Host-based Sensor for DB2 (on Red Hat Enterprise Linux) - installation steps Host-based Sensor for DB2 (on Solaris) - installation steps Host-based Sensor for DB2 (on AIX) - installation steps. 2. Modify the XML files for each host-based Sensor for DB2 installation and assign a unique port number to each host-based Sensor for DB2. To do so, you must change the port number so each host-based Sensor for DB2 has a unique port number; for more information, see Appendix C: Modifying the Sensor Listener Port Number. 3. In these environments, when launching the sensor, go to <Sensor installation directory>/util, and run the following command to launch it: appradar_start -m. This allows the host-based Sensor for DB2 to coexist with other Sensors on the same host and within the same account. Application Security, Inc. 316

318 Appendix Q: Monitoring Oracle Databases in an Oracle Fail Safe Environment: Sensor and Cluster Configuration Steps This appendix explains how to configure a host-based Sensor for Oracle (on Windows) in an Oracle Fail Safe environment. It also explains how to configure your Oracle Fail Safe cluster, once you have properly configured your Sensor. In this appendix: About Oracle Fail Safe Oracle Fail Safe vs. Oracle RAC Sensor configuration steps (Oracle Fail Safe) Cluster configuration steps (Oracle Fail Safe). About Oracle Fail Safe Oracle Fail Safe vs. Oracle RAC Oracle Fail Safe, a type of Oracle cluster, is a core feature included with every Oracle 11gR1, Oracle 10g and Oracle9i license for Microsoft Windows 2000 and Microsoft Windows Oracle Fail Safe is integrated with Microsoft Cluster Server to allow you to configure and verify Microsoft Windows clusters and to automatically fail over Oracle databases and applications. Oracle Fail Safe is essentially a Microsoft Clustering Services (MSCS) plug-in. In an MSCS architecture, two systems share the same disk, which only one system controls at a time. In the event of a failure (determined by the heartbeat mechanism), the standby system replaces the instance currently running the Oracle instance (and controlling the storage). Oracle Fail Safe differs in several ways from Oracle Real Application Cluster (RAC); for more information on installing and configuring a host-based Sensor for Oracle (on Windows) to monitor Oracle databases on a RAC, see Appendix B: Installing and Configuring a Host-Based Sensor for Oracle to Monitor Oracle Databases on an Oracle RAC. Application Security, Inc. 317

319 Oracle Fail Safe is generally considered easier to implement and administer than RAC. Most organizations that run applications on Microsoft Windows have already implemented MSCS and are familiar with it. In addition, Oracle Fail Safe is a core feature of Oracle9i and Oracle10g for Windows, so you won t need additional licenses. Another key difference: unlike Oracle RAC (which can run in a Microsoft Windows or on a *nix-based platform), Oracle Fail Safe runs on Microsoft Windows only. Thus, this appendix is only relevant if you are configuring a host-based Sensor for Oracle (on Windows); for more information, see Configuring a host-based Sensor to monitor Oracle SIDs and services and deploying the configuration information (when Sensor is installed on Windows) in the DbProtect User s Guide. Sensor configuration steps (Oracle Fail Safe) To monitor Oracle databases in an Oracle Fail Safe environment, first complete the following host-based Sensor for Oracle (on Windows) configuration steps: 1. Install your host-based Sensor for Oracle (on Windows); for more information, see Host-based Sensor for Oracle (on Windows) - installation steps. 2. Register your host-based Sensor for Oracle (on Windows); for more information, see Registering a Sensor in the DbProtect User s Guide. 3. Configure and deploy your host-based Sensor for Oracle (on Windows). Pay special attention to: Step 5 of Configuring a host-based Sensor to monitor Oracle SIDs and services and deploying the configuration information (when Sensor is installed on Windows) in the DbProtect User s Guide, where you must select a network adapter that is associated with a real IP address (where the network traffic can sniff packets). Make sure this is not the cluster heartbeat card, because cluster heartbeat cards do not detect network traffic. Step 10 of Configuring a host-based Sensor to monitor Oracle SIDs and services and deploying the configuration information (when Sensor is installed on Windows in the DbProtect User s Guide, where you must configure your network adapter for the cluster's virtual IP address. If this is not already populated in the IP Address: field, then you must enter it manually. 4. Complete the remaining configuration steps described in Configuring a host-based Sensor to monitor Oracle SIDs and services and deploying the configuration information (when Sensor is installed on Windows in the DbProtect User s Guide, and deploy the configured instance to your host-based Sensor for Oracle (on Windows). 5. Next, configure your Oracle Fail Safe cluster; for more information, see Cluster configuration steps (Oracle Fail Safe). Application Security, Inc. 318

320 Cluster configuration steps (Oracle Fail Safe) Once you have configured your host-based Sensor for Oracle (on Windows) to monitor Oracle databases in an Oracle Fail Safe environment (as explained in Sensor configuration steps (Oracle Fail Safe)), you must next complete the following cluster configuration steps: 1. In your cluster, make the other node the active node either by initiating a failover or by moving the cluster resources over to that node. 2. From the new active node, access your shared drive via Windows Explorer. 3. On the shared drive, go to the directory where your host-based Sensor for Oracle (on Windows) is installed and navigate to the <installation directory>\sensor\conf\overrides directory. 4. Open the file networkadapter_sensor_override.xsl in any text editor such as Notepad. 5. In a separate text editor window, open the file sensor.xml, which is located in the <installation directory>\sensor\conf\ directory. 6. In the sensor.xml file, locate the line that begins: <networkadapter name=. Copy everything on that line between the double quotes (but not the double quotes themselves). 7. Go to the text editor window where the networkadapter_sensor_override.xsl file is open and locate the following section: <!-- This is node 1 --> <xsl:element name="networkadapter"> <!-- Insert network adapter in between xsl attribute tags --> <xsl:attribute name="name">insert_network_adapter_here</xsl:attribute> 8. Paste the information you copied in Step 6 from the sensor.xml file to the location in Step 7. Specifically, you must paste the information you copied in Step 6 between the tags <xsl:attribute name="name"> and </ xsl:attribute> so it replaces the string reading: INSERT_NETWORK_ADAPTER_HERE. The string INSERT_NETWORK_ADAPTER_HERE should no longer be visible once you paste the actual network adapter information for node 1 from the sensor.xml file into this location. 9. Open a command prompt window in the Sensor's <installation directory>\sensor\bin\ directory on the shared drive. 10.From the command prompt window, run the utility: list_net_adapter.exe 11.The list_net_adapter.exe utility outputs the list of network adapters it detects on cluster node. Note which network adapter corresponds to the real IP address for that node (i.e., not the cluster heartbeat network adapter). Application Security, Inc. 319

321 12.Copy the network adapter information. 13.Paste the network adapter information into the area of the networkadapter_sensor_override.xsl file reserved for the other node of your Oracle Fail Safe cluster. It should be just below the location from Step 8. It looks something like this: <!-- This is node 2 --> <xsl:element name="networkadapter"> <!-- Insert network adapter in between xsl attribute tags --> <xsl:attribute name="name">insert_network_adapter_here</ xsl:attribute> Again, paste the network adapter information between the tags <xsl:attribute name="name"> and </xsl:attribute>, replacing the string that reads: INSERT_NETWORK_ADAPTER_HERE. The string INSERT_NETWORK_ADAPTER_HERE should no longer be visible once the actual network adapter information for node 2 from the list_net_adapter.exe utility is pasted in this location. 14.Save the changes made to networkadapter_sensor_override.xsl, then close the file. 15.Rename the networkadapter_sensor_override.xsl file so the words networkadapter_ are removed. The new file name should be named: sensor_override.xsl 16.Copy the sensor_override.xsl file from the <installation directory>\sensor\conf\overrides directory to the <installation directory>\sensor\conf\ directory (one level up). 17.Restart the DbProtect Sensor service. You can do this in either of two ways: Stop then start the DbProtect Sensor service from the Windows Service Control Manager on the cluster's active node. Bring the DbProtect Sensor Cluster resource offline, then bring it online again in the Cluster Administrator on either cluster node. 18.Once the host-based Sensor for Oracle (on Windows) restarts, a new file displays in your Sensor installation's <installation directory>\sensor\conf\ directory. The new file is named: sensor_transformed.xml. This new file contains two occurrences of the <networkadapter> XML element, which the Sensor uses to monitor your Oracle Fail Safe cluster. Application Security, Inc. 320

322 Appendix R: Configuring Your Host-Based Sensor (Installed on a *nix Platform) to Start Automatically Upon System Reboot In most cases when you configure an Oracle or DB2 database on a *nix server, the server is set up to automatically start the database and bring up Oracle or DB2 upon system restart/reboot. In such cases, you can also have your host-based Sensor for Oracle or DB2 automatically come up when the server (where the Sensors are installed) gets rebooted. This appendix explains how to configure your host-based Sensor for Oracle on a *nix platform (i.e., Solaris, AIX, or Red Hat Enterprise Linux) or DB2 on a *nix platform (i.e., (i.e., Solaris, AIX, HP-UX, or Red Hat Enterprise Linux) to automatically start up whenever you restart your system. In order to accomplish this goal, you must customize the startup file (located in your <Sensor installation directory>/util directory) to fit your *nix environment. To configure your host-based Oracle or DB2 Sensors (installed on a *nix platform) to start automatically upon system reboot: 1. Copy the appradar_startup.sh (for example to arstart). 2. Make the following modifications to the new arstart file. user=sensor_user SENSOR_DIR=sensor_dir prog= DbProtect Sensor Replace the account sensor_user with whatever account name you use to run your host-based Sensor (installed on a *nix platform). Replace the path sensor_path with the path to the <Sensor installation directory>, e.g., /home/aroracle/ ASIappradar/sensor Application Security, Inc. 321

323 3. Copy the modified file (arstart in this example) from the util subdirectory to the appropriate platform-specific subdirectory (listed in the following table). *nix Platform AIX (Oracle and DB2) HP-UX (Oracle and DB2) Red Hat Enterprise Linux (Oracle and DB2) Solaris (Oracle and DB2) Symbolic Links Commands /etc/arstart /sbin/init.d/arstart /etc/init.d/arstart /etc/init.d/arstart 4. If you are running a host-based Sensor for: Oracle, then change the group of the arstart file to the Oracle DBA group (typically dba), and set the permissions to 750. To do so, run the following respective commands: -# chgrp dba arstart -# chmod 750 arstart DB2, change the group to the DB2 admin group (usually db2grp1) by running the following command: # chgrp db2grp1 arstart 5. Create symbolic links to the arstart script in the appropriate run-level script directories (as per the following examples). *nix Platform Symbolic Links Commands AIX HP-UX # ln -s /etc/arstart /etc/rc.d/rc2.d/ S99arstart # ln -s /etc/arstart /etc/rc.d/rc2.d/ K01arstart # ln -s /sbin/init.d/arstart /sbin/rc3.d/ S990arstart # ln -s /sbin/init.d/arstart /sbin/rc3.d/ K001arstart Application Security, Inc. 322

324 *nix Platform Symbolic Links Commands AIX Red Hat Enterprise Linux Solaris # ln -s /etc/arstart /etc/rc.d/rc2.d/ S99arstart # ln -s /etc/arstart /etc/rc.d/rc2.d/ K01arstart # ln -s /etc/init.d/arstart /etc/rc.d/rc3.d/ S99arstart # ln -s /etc/init.d/arstart /etc/rc.d/rc5.d/ K01arstart # ln -s /etc/init.d/arstart /etc/rc.d/rc5.d/ S99arstart # ln -s /etc/init.d/arstart /etc/rc3.d/ K01arstart # ln -s /etc/init.d/arstart /etc/rc3.d/ S99arstart Note: The specific link names (e.g., S99arstart) are dependent on the specific configuration of your database server. You must execute the arstart script right after the startup script for Oracle (typically dbora) or DB2 (typically db2start). Application Security, Inc. 323

325 Appendix S: Remote- Deploying DbProtect Components on Windows in Your Enterprise You can use a third-party tool -- such as Microsoft Operations Manager (MOM) -- to install and/or remote-deploy the DbProtect components (i.e., the DbProtect suite, Scan Engines, and Sensors) without user intervention ( silently ) on Microsoft Windows. Specifically, such tools allow you to remote-deploy individual installer packages (MSIs) to specified target hosts. Note: You can also deploy DbProtect components on Windows individually using a command line, without any user interaction with third-party tools. This appendix consists of the following topics: Understanding the DbProtect bootstrappers Common DbProtect bootstrapper command line parameters Installing the DbProtect suite via the command line (with default options) Extracting individual MSIs from the component setup files DbProtect suite component MSIs: installation prerequisites and command line arguments Scan Engine MSI: installation prerequisites and command line arguments Sensor MSI: installation prerequisites and command line arguments Using msiexec to install the MSIs. Understanding the DbProtect bootstrappers The DbProtect suite, Scan Engine, and Sensor bootstrappers contain one or more individual MSIs. The names of the bootstrappers follow: DbProtect suite: DbProtect_Setup.exe Sensor: AppRadar Sensor_<ver>_<Windows version>.exe (e.g., AppRadar Sensor_3.10.5_Win32.exe Scan Engine: appdetective_scanengine_setup_<ver>_en-us.exe (e.g., appdetective_scanengine_setup_ _en-us.exe Application Security, Inc. 324

326 Each bootstrapper can detect which prerequisites must be installed on your system. For example, if you are installing the DbProtect suite, and you already have the required Microsoft.NET Framework 3.5 SP1 installed, then the DbProtect_Setup.exe bootstrapper does not install the Microsoft.NET framework; for more information, see Chapter 5 - Installing the DbProtect Components, Logging Into the DbProtect Console, and DbProtect Console Login Troubleshooting. For more information on installation prerequisites and optional command line argument installation parameters for the: DbProtect suite component MSIs, see DbProtect suite component MSIs: installation prerequisites and command line arguments Scan Engine component MSI, see Scan Engine MSI: installation prerequisites and command line arguments Sensor component MSI, see Sensor MSI: installation prerequisites and command line arguments. Common DbProtect bootstrapper command line parameters All DbProtect bootstrappers support a set of common command line parameters, explained in the table below. Common bootstrapper command line parameter Allows you to: /? Display a help screen. /help /qb /nq /Log /LogFile [path] /ConfigFile [path] /ExtractCab /DisplayCab Force basic user interface (UI) mode. Force full UI mode. Enable logging. Specify a log file. Specify a configuration file. Extract embedded components. Display a list of embedded components. Application Security, Inc. 325

327 Common bootstrapper command line parameter /ComponentArgs [ name : value...] /ControlArgs INSTALLLOCATION: path Allows you to: Pass optional parameters to a DbProtect component MSI. To see a list of optional parameters for the: DbProtect Console MSIs, see DbProtect suite component MSIs: installation prerequisites and command line arguments Scan Engine MSI, see Scan Engine MSI: installation prerequisites and command line arguments Sensor MSI, see Sensor MSI: installation prerequisites and command line arguments. Specify the DbProtect suite installation location. For example: DbProtect_Setup.exe /ControlArgs INSTALLLOCATION: C:\Program Files\AppSecInc2 /qb Installing the DbProtect suite via the command line (with default options) Extracting individual MSIs from the component setup files To install the DbProtect suite with no user interaction, using all default options, run the following command: DbProtect_Setup.exe /qb Note: When you install the DbProtect suite via the command line, the installer automatically accepts the license agreement. You can extract the individual MSIs (and third-party prerequisites) from each bootstrapper and install the MSIs individually. To extract individual MSIs from a bootstrapper, open a command prompt and run the following commands: 1. To extract individual MSIs from the: DbProtect suite bootstrapper, run the following command: DbProtect_Setup.exe /ExtractCab, then see DbProtect suite component MSIs: installation prerequisites and command line arguments Sensor bootstrapper, run the following command: AppRadar Sensor_<ver>_<Windows version>.exe /ExtractCab (e.g., AppRadar Sensor_3.10.5_Win32.exe /ExtractCab, then see Sensor MSI: installation prerequisites and command line arguments. Scan Engine bootstrapper, run the following command: appdetective_scanengine_setup_<ver>_en-us.exe /ExtractCab (e.g., appdetective_scanengine_setup_ _en-us.exe /ExtractCab, then see Scan Engine MSI: installation prerequisites and command line arguments Application Security, Inc. 326

328 Running any of the MSI extraction commands above creates a folder called: SupportFiles in your current directory. This folder contains the individual DbProtect MSIs (and third-party prerequisites) necessary to complete your silent installation. DbProtect suite component MSIs: installation prerequisites and command line arguments The DbProtect suite bootstrapper contains the following MSIs: Note: Database Component MSI; for more information, see Database Component MSI and command line arguments SHATTER Knowledgebase MSI; for more information, see SHATTER Knowledgebase MSI and command line arguments Console MSI and the Message Collector MSI; for more information, see The DbProtect Console MSI and the Message Collector MSIs and command line arguments DbProtect Analytics MSI; for more information, see The DbProtect Analytics MSI and command line arguments. DbProtect Uninstaller MSI; for more information, see The DbProtect Uninstaller MSI Legacy Vulnerability Assessment Reporting MSI; for more information, see Legacy Vulnerability Assessment Reporting MSI Vulnerability Assessment Policy Editor MSI; for more information, see Vulnerability Assessment Policy Editor MSI. The DbProtect suite bootstrapper also contains a Documentation and Additional Content MSI, but this MSI does not include any command line arguments. DATABASE COMPONENT MSI AND COMMAND LINE ARGUMENTS The Database Component MSI is called: DatabaseInstaller.msi. This file is stored under the SupportFiles directory (created after you extract the DbProtect Console component, explained in Extracting individual MSIs from the component setup files). The prerequisites for installing the Database Component MSI follow: Microsoft Visual Studio CRT 2005 SP1 Microsoft.NET Framework 3.5 SP1 MDAC 2.6. Application Security, Inc. 327

329 As explained in Common DbProtect bootstrapper command line parameters, the / ComponentArgs [ name : value...] command allows you to pass optional parameters to a DbProtect component MSI. The following table lists the The following table lists the optional command line arguments for the Database Component MSI: Database Component MSI optional installation parameter DBTYPE=<value> INSTALLMODE=<value> Description The target database type of the Database Schema. The only supported value is MSSQL. If you are installing the Database Schema for the first time, enter the value full. If you are upgrading the Database Schema, enter the value update. SHATTER KNOWLEDGEBASE MSI AND COMMAND LINE ARGUMENTS The SHATTER Knowledgebase MSI is called: DataComponent.msi. This file is stored under the SupportFiles directory (created after you extract the MSIs, explained in Extracting individual MSIs from the component setup files). The prerequisites for installing the SHATTER Knowledgebase MSI follow: Microsoft Visual Studio CRT 2005 SP1 Microsoft.NET Framework 3.5 SP1 Database Component; for more information, see Database Component MSI and command line arguments. As explained in Common DbProtect bootstrapper command line parameters, the / ComponentArgs [ name : value...] command allows you to pass optional parameters to a DbProtect component MSI. The following table lists the optional command line arguments for the SHATTER Knowledgebase MSI: SHATTER Knowledgebase MSI command line argument DBTYPE=<value> INSTALLMODE=<value> Description The target database type of the SHATTER Knowledgebase. Supported values are: Access or MSSQL. If you are installing the SHATTER Knowledgebase for the first time, enter the value full. If you are upgrading the SHATTER Knowledgebase, enter the value update. Application Security, Inc. 328

330 THE DBPROTECT CONSOLE MSI AND THE MESSAGE COLLECTOR MSIS AND COMMAND LINE ARGUMENTS The DbProtect Console MSI and the Message Collector MSIs are called DbProtectInstaller.msi and MessageCollector.msi, respectively. These files are stored under the SupportFiles directory (created after you extract the MSIs, explained in Extracting individual MSIs from the component setup files). The prerequisites for installing the Console MSI and Message Collector MSI follow: Microsoft Visual Studio CRT 2005 SP1 Microsoft.NET Framework 3.5 SP1 MDAC 2.6 Database Component; for more information, see Database Component MSI and command line arguments SHATTER Knowledgebase; for more information, see SHATTER Knowledgebase MSI and command line arguments. As explained in Common DbProtect bootstrapper command line parameters, the / ComponentArgs [ name : value...] command allows you to pass optional parameters to a DbProtect Console MSI and the Message Collector component MSIs. The following table lists the optional command line arguments for the DbProtect Console MSI and Message Collector MSI: DbProtect Console and Message Collector MSI command line argument INSTALLLOCATION=<value> RUNTIME_DATABASE_LOGON_TYPE =<value> RUNTIME_DATABASE_USERNAME =<value> RUNTIME_DATABASE_PASSWORD =<value> SERVICE_LOGON_TYPE=<value> SERVICE_USERNAME=<value> SERVICE_PASSWORD=<value> Description Defines the target directory where the DbProtect Console and/or Message Collector components should be installed. Database authentication type at runtime, either SqlAuth or WinAuth. Username to access the database at runtime. Password to access the database at runtime. Service logon type (either ServiceLocalSystem or ServiceAccount). Service username when not using local system. Service user password when not using local system Application Security, Inc. 329

331 DbProtect Console and Message Collector MSI command line argument CONSOLE_HOST=<value> PORTNUMBER=<value> Description Host name for the DbProtect Console or Message Collector service to listen to. Default value is: localhost. Port for the DbProtect Console or Message Collector service to listen to. Note: All DbProtect port numbers have defaults. Sensor: 20000, Scan Engine: 20001, DbProtect Console: 20080, Message Collector: 20081, DbProtect Analytics: For more information, see Port considerations. THE DBPROTECT ANALYTICS MSI AND COMMAND LINE ARGUMENTS The DbProtect Analytics MSI is called DbPAnalytics.msi. This file is stored under the SupportFiles directory (created after you extract the MSIs, explained in Extracting individual MSIs from the component setup files). The prerequisites for installing the DbProtect Analytics MSI follow: Microsoft Visual Studio CRT 2005 SP1 Microsoft.NET Framework 3.5 SP1 MDAC 2.6 Database Component; for more information, see Database Component MSI and command line arguments SHATTER Knowledgebase; for more information, see SHATTER Knowledgebase MSI and command line arguments. As explained in Common DbProtect bootstrapper command line parameters, the /ComponentArgs [ name : value...] command allows you to pass optional parameters to an DbProtect Analytics component MSI. The following table lists the optional command line arguments for the DbProtect Analytics MSI: DbProtect Analytics MSI command line argument DATABASE_SERVER=<value> Description Location of the DbProtect Analytics database server, in one of the following formats: hostname host:port host\instancename Application Security, Inc. 330

332 DbProtect Analytics MSI command line argument Description DATABASE_LOGON_TYPE=<value> The DbProtect Analytics database authentication type used to create the DbProtect Analytics database. Enter WinAuth or SqlAuth as the <value>. DATABASE_USERNAME=<value> DATABASE_PASSWORD=<value> RUNTIME_DATABASE_LOGON_TYPE =<value> RUNTIME_DATABASE_USERNAME= <value> RUNTIME_DATABASE_PASSWORD= <value> SERVICE_USERNAME=<value> SERVICE_PASSWORD=<value> Username to access the DbProtect Analytics database at runtime. Required when DATABASE_LOGON_TYPE= SqlAuth. Password to access the DbProtect Analytics database at runtime. Required when DATABASE_LOGON_TYPE= SqlAuth. DbProtect Analytics database authentication type at runtime, enter either WinAuth or SqlAuth. Username to access the DbProtect Analytics database at runtime. Required when RUNTIME_DATABASE_LOGON_TYPE= SqlAuth. Password to access the DbProtect Analytics database at runtime. Required when RUNTIME_DATABASE_LOGON_TYPE= SqlAuth. Service username when not using local system account. Service user password when not using local system account. THE DBPROTECT UNINSTALLER MSI The DbProtect Uninstaller MSI is called SetupInstaller.msi. This file is stored under the SupportFiles directory (created after you extract the MSIs, explained in Extracting individual MSIs from the component setup files). There are no command line arguments -- all this MSI file does is add a DbProtect suite uninstallation shortcut to the Start menu, as well as some support files. For more information on uninstalling the DbProtect suite, see Chapter 6 - Uninstalling the DbProtect Components. Application Security, Inc. 331

333 LEGACY VULNERABILITY ASSESSMENT REPORTING MSI The Legacy Vulnerability Assessment Reporting MSI is called AdpReporting.msi. This file is stored under the SupportFiles directory (created after you extract the MSIs, explained in Extracting individual MSIs from the component setup files). There are no command line arguments. This MSI file adds legacy Vulnerability Assessment reports to your DbProtect suite installation (in addition to the Cognos reports available in DbProtect Analytics). If you do not want to include legacy Vulnerability Assessment reports in your DbProtect suite installation, then do not select the Legacy VA Reporting option during your DbProtect suite installation. As a result, legacy Vulnerability Assessment reports will not be available in DbProtect Vulnerability Management. For more information, see the DbProtect User s Guide. If you want to include Vulnerability Assessment reports in your DbProtect suite installation, then you should select the Legacy VA Reporting option during your DbProtect suite installation. As a result, legacy Vulnerability Assessment reports will be available in DbProtect Vulnerability Management; for more information, see the DbProtect User s Guide. VULNERABILITY ASSESSMENT POLICY EDITOR MSI The Vulnerability Assessment Reporting MSI is called AdpPolicyEditor.msi. This file is stored under the SupportFiles directory (created after you extract the MSIs, explained in Extracting individual MSIs from the component setup files). There are no command line arguments. This MSI file adds the Policy Editor to the Start menu, allowing you to edit a Policy. This feature is required. For more information on editing Policies and using the Policy Editor, see the DbProtect User s Guide. Scan Engine MSI: installation prerequisites and command line arguments The Scan Engine MSI is called: ScanEngine.msi. This file is stored under the SupportFiles directory (created after you extract the MSIs, explained in Extracting individual MSIs from the component setup files). The prerequisites for installing the Scan Engine MSI follow: Microsoft Visual Studio CRT 2005 SP1 Microsoft.NET Framework 3.5 SP1 MDAC 2.6. Application Security, Inc. 332

334 As explained in Common DbProtect bootstrapper command line parameters, the / ComponentArgs [ name : value...] command allows you to pass optional parameters to a DbProtect component MSI. The following table lists the optional command line arguments for the Scan Engine MSI: Scan Engine MSI command line argument INSTALLDIR=<path> TEST_CONNECTIONS=<value> CONSOLE_HOST=<value> CONSOLE_PORT=<value> SCANENGINE_HOST=<value> SCANENGINE_PORT=<value> SERVICE_LOGON_TYPE=<value> SERVICE_USERNAME=<value> SERVICE_PASSWORD=<value> SCANENGINE_DATABASE_SERVER= <value> SCANENGINE_DATABASE_ TRUSTED_CONNECTION=<value> SCANENGINE_DATABASE_ USERNAME=<value> SCANENGINE_DATABASE_ PASSWORD=<value> Description Defines the target directory where the Scan Engine should be installed. Enter 0 as the <value> to disable the checking of test connections. The Scan Engine installer will you to continue installing the Scan Engine by ignoring the result of clicking the Test Connection buttons on the GUI Scan Engine installer; for more information, see Installing Scan Engines. The DbProtect Console host name. The DbProtect Console installation port number. The Scan Engine host name. The Scan Engine installation port number. Enter ServiceLocalSystem as the <value> for a Local System account. Enter ServiceAccount as the <value> if you want to specify a different account. You can specify the user name and password for the service account in the SERVICE_USERNAME and SERVICE_PASSWORD arguments, respectively. The user name for the logon account of DbProtect Scan Engine service. The password for the logon account of DbProtect Scan Engine service. The Scan Engine database server name. Enter yes as the <value> if you want to use Windows Authentication. Enter no as the <value> if you want to use Microsoft SQL Server Authentication. The user name for Microsoft SQL Server Authentication. The password for Microsoft SQL Server Authentication. Application Security, Inc. 333

335 Sensor MSI: installation prerequisites and command line arguments The Sensor MSI is called: service_installer.msi. This file is stored under the SupportFiles directory (created after you extract the MSIs, explained in Extracting individual MSIs from the component setup files). The prerequisites for installing the Sensor MSI follow: Microsoft Visual Studio CRT 2005 SP1 Microsoft.NET Framework 3.5 SP1 MDAC 2.6. As explained in Common DbProtect bootstrapper command line parameters, the / ComponentArgs [ name : value...] command allows you to pass optional command line parameters to a DbProtect component MSI. The following table lists the optional command line arguments for the Sensor MSI: Sensor MSI command line argument INSTALLLOCATION=<value> SENSOR_TYPE=<value> SERVICE_LOGON_TYPE=<value> SERVICE_USERNAME=<value> SERVICE_PASSWORD=<value> PORTNUMBER=<value> Description The full target directory path where the Sensor should be installed. Host-based or network-based. Service logon type. Either ServiceLocalSystem or ServiceAccount. Service username (when not using local system). Service user password (when not using local system). Port for the DbProtect Console or Message Collector service to listen to. Note: All DbProtect port numbers have defaults. Sensor: 20000, Scan Engine: 20001, DbProtect Console: 20080, Message Collector: 20081, DbProtect Analytics: For more information, see Port considerations. Application Security, Inc. 334

336 Using msiexec to install the MSIs msiexec allows you to install, modify, and perform operations on a Microsoft Windows installer from the command line. Run the following command to silently pass installation parameters to the DbProtect MSIs via the DbProtect bootstrappers: msiexec /i <msi_name>.msi /l*v install.log /qb (or /qn) /name=value Where: /qb provides a basic UI /qn provides no UI name=value allows you to pass optional parameters to your component MSIs as command line arguments. Acceptable installation command line arguments are specific for each component MSI. For a list of: -DbProtect suite component MSI command line arguments, see DbProtect suite component MSIs: installation prerequisites and command line arguments -Scan Engine component MSI command line arguments, see Scan Engine MSI: installation prerequisites and command line arguments -Sensor component MSI command line arguments, see Sensor MSI: installation prerequisites and command line arguments. Application Security, Inc. 335

337 Hint: You can run msiexec /? to display a Microsoft Windows Installer dialog box that includes all msiexec options (install, display, restart, logging, update, repair, etc.). FIGURE: Microsoft Windows Installer dialog box with msiexec options Application Security, Inc. 336