1



[pic]

CyberGrants, Inc.

System Security Setup and Policies

Prepared by Max Kartsev & Sean P. Flanagan

CyberGrants, Inc.

Last Updated: 11/05/07

Part I

System Setup

1. General Overview

1. System Business Functions

The CyberGrants system is online, Web-based application that provides grants management software products for family, private, community and corporate foundations and corporate contributions departments. The system is represented by two major components:

• The CyberGrants Grants Management System: provides clients with browser-based access to online grants management functions such as budgeting, reporting, letter writing, grant reviews, online applications, invitations, custom questions and payment processing.

• The CyberGrants Matching Gifts and Volunteer Software: provides online capability for donors, nonprofit organizations, and program administrators to conduct employee-based giving within the rules and regulations of their respective foundations.

Additional, out-of-band, system functions include data transfers to or from clients, and batch processing. The major data transfer components are:

o Accounts Payable (AP) feeds: this process involves sending the AP data to client organizations for the generation of checks

o Donor feeds for the CyberGrants Matching Gifs program: this process involves periodic upload of human resources data onto CyberGrants systems. The data is then applied against the donor database for respective grant makers to update employee records, check their eligibility, etc.

o Miscellaneous feeds, such as product donation which contain information on products donated to non-profit organizations.

1.2 Implementation of Core Components

CyberGrants is largely a PL/SQL system built upon the three-tier client/server architecture scheme. Tier 1 is a virtual entity, substantiated by HTTP requests coming from client Web browsers. Tier 2, the application layer, comprises the web and application servers. Tier 3, the database layer, comprises the backend database servers. Each layer is made up of a pair of identically configured servers accessing shared storage via redundant SCSI channels.

The core part of the application layer (Tier 2) is Oracle9i Application Server (9iAS). At present time, three components of 9iAS are utilized: Oracle HTTP Server (Apache), Oracle Reports Server, and Oracle PL/SQL. Oracle HTTP Server is the front end that handles all incoming requests and routes them to other components. Oracle PL/SQL represents the Business Logic of the Tier 2, serving as an intermediary between the HTTP server and the backend Oracle database; its primary role is to convert incoming database requests into corresponding PL/SQL procedures and execute them against the database via Oracle Net8 link. Oracle Reports is a part of the Business Intelligence; it picks up reports queries, runs them against the backend database, and converts the output into HTML or PDF using a set of customized templates. Other sub-components of 9iAS include Apache JServ (the servlet engine), and various Apache modules (mods) such as mod_plsql, mod_ssl, mod_perl, etc.

The core part of the Tier 3 is Oracle9i database server, which houses the actual CyberGrants’ grant management code (all written in PL/SQL). The code is placed within two Oracle tablespaces: TS_DATA and TS_INDEX, serving as containers for the data and index parts of the system, respectively. There are three main Oracle users (schemas) that own most of the CyberGrants’ database entities; other schemas have been created within the same database for selected clients and projects.

2. System Data Flow

2.1 Data Flow Diagram

2.2 Data Flow Schematics

PL/SQL Gateway (B1-B3)

1. The PL/SQL Server Page request from a client browser is detected by the HTTP server and routed to mod_plsql (B1)

2. mod_plsql routes the request to the PL/SQL Gateway (B2)

3. PL/SQL Gateway prepares the call parameters, connects to the Oracle9i database using information stored in its DAD (Database Access Descriptor), and issues native Oracle PL/SQL commands to invoke a PL/SQL procedure stored in the Oracle9i database instance. (B3)

4. The PL/SQL procedure in the Oracle database generates an HTML page using data and the PL/SQL Web Toolkit installed in the database.

5. The response is returned to the PL/SQL Gateway. (B3)

6. Oracle PL/SQL Gateway forwards the response back to the mod_plsql instance running in the HTTP server. (B2)

7. The HTTP Server sends the response to the client browser.

Servlets (A1-A4)

1. A request for a servlet class from a client browser is detected by the HTTP server and routed to the mod_jserv module in the HTTP server (A1)

2. The mod_jserv module forwards the request to the servlet engine, JServ. If the engine is not already running, then mod_jserv will spawn one and initialize the servlet (A2)

3. The servlet engine translates the incoming request into a request object, creates a response object, and passes both objects to the servlet class (A3)

4. The servlet class executes and generates response data. If necessary, it connects to the Oracle9i database via ODBC client (A4)

5. The data generated by the class is passed back to the servlet engine in the servlet response object (A3)

6. The servlet engine passes the response to the mod_jserv module and Oracle HTTP Server (A2)

7. The HTTP server passes the response to the client browser.

Reports (C1-C4)

1. A request for a report from a client browser is detected by the HTTP server and routed to the mod_cgi module in the HTTP Server (C1)

2. The mod_cgi invokes the Reports Web CGI (C2)

3. The Reports Web CGI handles the login transaction, converts the report to command-line format, and submits the request for execution by the Reports Server (C3)

4. The Reports Server checks its output cache for an existing response to the request. If the cache has an acceptable output, then the Reports Server returns it to The Reports Web CGI. If no acceptable output is found, the Reports Server queues the job request and sends the command line to first available runtime engine for execution. The runtime engine runs the report against the Oracle 9i database (C4)

5. The Reports Server returns the output to the Reports Web CGI (C3)

6. The Reports Web CGI returns the output to the mod_cgi module in the HTTP Server (C2)

7. The HTTP Server sends the report output to the client's browser.

3. Web and Application Servers (Tier 2)

3.1 CyberGrants

3.1.1 Inventory

Hardware: 2x E220R, each with 2x 450 MHZ CPU, 2 GB RAM, 2x 18 GB int. storage;

Storage: 2x D1000 storage arrays, each with ~36 GB

Operating system: Sun Solaris 8, 64-bit

Volume manager: Solstice Disk Suite 4.2.1, with soft partitions

Application server software: Oracle9iAS version 1.0.2.x.x

Web Server: Oracle HTTP Server (Apache v. 1.3.19)

Reports services: Oracle Reports Server v. 6.0.8.18.0 (Part of Oracle Developer 6i Suite)

Other components: JRE 1.4.2, Apache Jserv, connectivity middleware (SQL*Net)

3.1.2 Server redundancy

The Tier 2 servers are configured as primary and standby nodes. The primary node serves client HTTP requests while standby node is configured as exact replica of the primary. Each node contains its own local operating system, web and application software binaries, and the web content (HTML files, reports, production code, pictures, etc.)

Updates to the web and application content are made by developers on the primary server and automatically propagated to the standby node by rsync(1) process. Each Tier 2 server is independent and can be easily replaced with its peer node by simply switching its logical IP address and restarting Web and application software.

3.2 File System Layout

The table below reflects generic file system layout of the Tier 1 web and application servers. Note that certain root disk slices and other local and shared file systems, as well as their capacities, are created to accommodate requirements of certain applications and conventions. A particular site may choose a different set of file systems depending on software products in use and their local requirements.

Mount Point Size Access Description

--------------------------------------------------------------------------------------------------------------------

/ 2.0 GB Local OS (root disk)

swap 2.0 GB Local OS swap (root disk)

/var 2.0 GB Local OS (root disk)

/CG 10.0 GB Local Oracle binaries & user homes (root disk)

swap 2 2.0 GB Local OS additional swap (root disk) (*)

/cgapp/cybergrants 18 GB Shared Oracle 9ias content and databases

(*) Optional, depends on system utilization and space constraints

3.3 File systems considerations

1. Internal hard drives are mirrored one-to-one using VxVM or SDS

2. Internal drives (root disks) are partitioned (sliced) to accommodate a volume manager requirements, which may vary depending on volume manager software

3. All application binaries are installed on local (internal) disks, as well as homes for local users;

5. /cgapp/cybergrants is mounted on each node locally as a regular VxVM volume or SDS metadevice

3.4 Oracle Application Server Software Configuration

3.4.1 Availability

From the Oracle Application Server software perspective, 9ias nodes are setup as standalone, independent machines, where each server will have access to its privately-owned storage resources.

One single logical IP address is configured on one of the servers that accept incoming connections from clients.

3.4.2 Binaries

Oracle 9ias binaries are installed locally on each node under a subdirectory /CG/oracle/product/ias

3.4.3 Initialization files

9ias initialization files are installed locally on each node

3.4.4 User accounts within the operating oystem

UNIX user named ias

This user will be the owner of IAS software and will be running Oracle 9ias processes (daemons); this user must belong to a UNIX group named oinstall as its primary group, and UNIX group named dba as its secondary group.

3.4.5 User environment variables

The following UNIX environment variables are set in the ~/.profile file for user ias:

HOME=/CG/oracle/product/ias

ORACLE_BASE=/CG/oracle

ORACLE_HOME=/CG/oracle/product/ias

LOGNAME=ias

PATH=/usr/bin:/usr/openwin/bin:/usr/dt/bin:/opt/vnc:/CG/oracle/product/ias/bin:/usr/ccs/bin

LD_LIBRARY_PATH=:/CG/oracle/product/ias/6iserver/lib:/CG/oracle/product/ias/6iserver/network/jre11/lib/sparc/native_threads

3.4.6 Software ownership and permissions

9ias binaries, 9ias database files, as well as any other 9ias related files and subdirectories are owned by a UNIX user ias and UNIX group oinstall. The default permissions of ias-owned subdirectories and mount points are 0755.

3.4.7 Systems requirements for Solaris

The following changes must be made to /etc/system file on each node that will run Oracle Applications Server software:

set shmsys:shminfo_shmmax=4294967295

set shmsys:shminfo_shmmin=1

set shmsys:shminfo_shmseg=10

set shmsys:shminfo_shmmni=100

set semsys:seminfo_semmns=1000

set semsys:seminfo_semmni=100

set semsys:seminfo_semmsl=450

4. Database Servers (Tier 3)

4.1 CyberGrants

4.1.1 Inventory

Hardware: 2x SunFire 480R, each with 2x 900 GHZ CPU, 4 GB RAM, 2x 36 GB int. storage;

Storage: 2x D2, each with ~432 GB (shared)

Operating System: Sun Solaris 8 Kernel, 64-bit

Volume Manager: Solstice Disk Suite 4.2.1, with soft partitions

Oracle Database: Oracle9i version 9.0.1.4.0, Enterprise Edition, 32-bit

4.1.2 Server redundancy

The Tier 3 servers are configured as primary and standby nodes. The primary node runs a database instance and serves requests from Tier 2 server. Each Tier 3 node contains its own local copy of the operating system and Oracle database software.

The active server mounts the necessary storage resources (file systems) containing Oracle database related files. It is attached to a standby node via a shared Differential Wide Ultra SCSI bus. In case the active node fails, storage resources can be automatically or manually switched over to the standby node and the database can be started on that node.

All shared file systems are mirrored (RAID 1) using redundant storage arrays connected to the host systems via redundant SCSI channels.

4.2 File System Layout

The table below reflects file system layout of the Tier 3 servers. Note that certain root disk slices and other local and shared file systems, as well as their capacities, are created to accommodate requirements of certain applications and conventions. A particular site may choose a different set of file systems depending on software products in use and their local requirements.

Mount Point Size Access Description

--------------------------------------------------------------------------------------------------------------------

/ 2.0 GB Local OS (root disk)

swap 2.0 GB Local OS swap (root disk)

/var 2.0 GB Local OS root disk

/CG 10.0 GB Local Oracle binaries (root disk)

swap 2 2.0 GB Local OS additional swap (root disk) (*)

/cgdb//ts_system 8.0 GB Shared Oracle system & archived logs

/cgdb//ts_index 16.0 GB Shared Oracle indexes

/cgdb//ts_users 2.0 GB Shared Oracle users TBS

/cgdb//ts_rollback 8.0 GB Shared Oracle rollback segments

/cgdb//ts_temp 8.0 GB Shared Oracle temp (sorts etc.)

/cgdb//ts_data 24.0 GB Shared Oracle data files

/cgdb//dumps 2.0 GB Shared Oracle error logs and UTL files

/cgdb//logs 24.0 GB Shared Oracle archived logs (**)

/cgdb//backup 72.0 GB Shared Oracle exports and online backups

/cgdb//init 1.o GB Shared Oracle initialization files

/cgdb//ctl_redo_1 1.0 GB Shared Oracle control and redo group 1

/cgdb///ctl_redo_2 1.0 GB Shared Oracle control and redo group 2

/cgdb///ctl_redo_3 1.0 GB Shared Oracle control and redo group 3

(*) Optional, depends on system utilization and space constraints

(**) May also be configured as part of another file system

4.3 File system considerations

1. Internal hard drives are mirrored one-to-one

2. Internal drives (root disks) are partitioned (sliced) to accommodate volume manager requirements, which may be different depending on a volume manager in use

3. All Oracle database binaries are installed on local (internal) disks, as well as homes for local users

5. For improved I/O throughput, file systems holding various Oracle segments are either split between pairs of spindles or defined as stripes on top of RAID 0+1 device

4.4 Oracle Database Software Configuration

4.4.1 Availability

Oracle 9i database nodes are setup as active/standby nodes. There is a single instance of the database configured, ‘cg,’ that runs on the primary node, with an ability to be monitored and failed over (or manually switched over) to its standby peer node using UNIX tools. In this scenario, storage resources are simply switched over by deporting disk groups on the primary server and importing and mounting them on the standby node, as well as switching the database floating IP address to the standby node. Once the resources migrate to the standby node, oracle database can be started.

Another instance, ‘cgs’, is configured as a standby instance and placed into recovery mode, on the standby server. This instance is managed by Oracle9i Guard, which takes care of transferring and applying archived logs. This instance can be used if primary instance became corrupted beyond recovery. In this case, Oracle Guard tools can be used to perform a switchover operation where the physical standby instance becomes a primary instance. Once such operation is performed, a new standby instance must be created and the roles can be reversed, if necessary, at a later time.

4.4.2 Oracle Binaries

Oracle database binaries are installed locally on each cluster node under a subdirectory /CG/oracle/product/9.0.1

4.4.3 Oracle Initialization Files

Oracle instance initialization file, initcg.ora, is located on the shared storage under /cgdb//init directory.

4.4.4 Oracle Users within the operating system

Oracle runs as UNIX user named oracle, and belongs to a UNIX group dba, with a default UNIX umask of 0022

4.4.5 Oracle Users Within the Database

The following Oracle users/schemas must be created database: wwwuser, cgadmin, report_user. These users must be given the dba privilege within the Oracle database. The following PL*SQL commands can be used to create these users:

SQL> create user identified by default tablespace TS_DATA temporary tablespace TS_TEMP;

SQL> grant dba to ;

4.4.6 Oracle user environment variables

The following UNIX environment variables are set via Oracle user's ~/.profile file:

ORACLE_HOME=/CG/oracle/product/9.0.1

ORACLE_BASE=/CG/oracle

ORACLE_SID=cgrants

PATH=$PATH:/CG/oracle/product/9.0.1/bin:/usr/ccs/bin:/usr/openwin/bin:/usr/dt/bin

4.4.7 Oracle software ownership and permissions

Oracle binaries, database files, control files, redo logs, as well as any other database-related files and subdirectories are owned by a UNIX user oracle and UNIX group "dba". The default permissions for oracle-owned subdirectories and mount points are 0755.

The following is the list of all Oracle-owned directories:

/cgdb/ora_ctl_redo_1

/cgdb/ora_ctl_redo_2

/cgdb/ora_ctl_redo_3

/cgdb/ora_data

/cgdb/ora_index

/cgdb/ora_rollback

/cgdb/ora_sys

/cgdb/ora_tempseg

/cgdb/ora_users

/CG/oracle

/var/opt/oracle

4.4.8 Oracle systems requirements for Solaris

The following changes must be made to /etc/system file on each cluster node that will run Oracle database:

set shmsys:shminfo_shmmax=4294967295

set shmsys:shminfo_shmmin=1

set shmsys:shminfo_shmseg=10

set shmsys:shminfo_shmmni=100

set semsys:seminfo_semmns=1000

set semsys:seminfo_semmni=100

set semsys:seminfo_semmsl=450

4.4.9 Installation of Oracle 9i Database Binaries

The first time, Oracle database binaries have been installed from the original set of CD-ROM disks shipped by Oracle Corp. The first database has then been patched and numerous bugs have been inoculated. Once made functional and tested, the binary distribution of Oracle software contained within its installation directory has been archived and zipped into one large file (a “tarball”) which has been used to install Oracle on other servers. This tremendously shortens and simplifies Oracle installations on multiple servers and ensures the same version and patch level. The ‘tarball’ can be obtained from CyberGrants’ distribution server or from any existing Oracle production server.

Part II

System Access

5. Connectivity and Remote Access

5.1 Abstract

CyberGrants, Inc. provides two types of access: (1) browser access to the Grants Management Application, and (2) maintenance access.

The application access is what comprises CyberGrants’ functionality as an ASP. It is used by both CyberGrants employees and all customers as primary means of conducting business online. It is segregated into two major sub-types formally classified as external and internal (discussed in the following two sections). Both methods are browser based, using HTTP protocol either over SSL on TCP/443 or non-SSL on TCP/9990. The application access, whether external or internal, deals exclusively with the Grants Management software product and provides no means to administer actual servers or operating systems.

For the application, the system provides six privilege levels (roles) that determine the scope of actions users can perform within the application and the objects they can view and/or manipulate. Users are assigned roles upon account creation.

Maintenance access is provided to administer server platforms and firewalls, and to perform tasks ‘behind the curtain’. It is also used by developers to transfer data for new software releases between development, staging, and production environments, to access software repositories, and perform miscellaneous actions (e.g. receiving initial data from customers for conversion, etc.)

5.2 Access to the CyberGrants Application

External access

- Donors: usually active company employees and retirees; a smaller percentage of donors are contractors and temporary workers. Donors access the CyberGrants application predominantly via HTTP over SSL, although they also have an option to use plain HTTP on port TCP/9990. The choice of secure or insecure HTTP is left to the customer organization. Customers who use employee Social Security Numbers (SSN’s) normally prefer using SSL-enabled port. Most customers, however, use employee ID’s as part of their identification to the system and thus have no particular requirements. Nonetheless, SSL-enabled port is the default at CyberGrants, Inc.

- Non-profit organizations: customers who work for non-profit organizations use plain HTTP access to the application, with some exceptions. This is due to the fact that non-profit organizations never transmit sensitive or confidential information.

- Some customers, whether donors or non-profits, prefer to use plain HTTP due to specific constraints on their part. For example, some customers are behind firewalls that do not allow outgoing SSL-encrypted traffic; there also those who access the Internet via slow dial-up links and consider plain HTTP for performance reasons.

Internal access

- Account administrators: at contract initiation, a group of people on the customer’s side is assigned to handle all account specific responsibilities such as budgeting, reporting, letter writing, grant reviews, defining business rules, etc. Account administrators use special sign-on procedure over SSL-enabled port.

- Account coordinators: these are CyberGrants employees assigned to handle customer’s accounts. They perform all preliminary functions necessary to bring the customer’s account in production and continue working with customer’s account coordinators for the duration of their contract. Account administrators access the CyberGrants application via SSL-enabled port.

Access rules and authorities

- User authentication is carried out using cookies (this formerly was accomplished via Basic HTTP authentication)

- After user has been authenticated, session state is maintained using cookies. User ID’s and passwords that are stored in cookies are first encrypted and then encoded with a combination of Base-64 and hex encoding algorithms.

- User passwords are 3DES encrypted in the Oracle database using Oracle 9iAS Obfuscation Toolkit

- Password management is configurable by the client (either client account administrators or CyberGrants account coordinators). Configuration options include the following: minimum password length, password format (disallowed words, required characters, etc), ability to reuse/prevent reuse of passwords, maximum number of failed login attempts before locking account

Access roles

- Viewer: view organizations and request information; selectively approve or reject requests; cannot create or edit organizations

- Strict viewer: same as the Viewer role, but can only view and approve a restricted set of objects according to what was granted to them by account administrators

- Basic: same as the Viewer role, but with ability to create and edit organizations

- Strict basic: same as the Basic role, but can access and manipulate only their own data

- Budget: same as the Basic role, with an ability to create and edit budgets

- Admin: allowed to perform all functions, including using admin tab and deleting and editing organizations and requests

5.3 Maintenance Access

In order to perform maintenance and updates on CyberGrants production, development, and staging systems, we need to have an ability to log into those systems. Our production systems are installed at a co-located data center; they are separated from our office network by a long-hauled and insecure link (in other words, the Internet). All other systems – development, staging, e-mail, user workstations, etc – are located within the corporate office network, 5 miles away from production plant. The goal here is to be able to administer hosts on both networks in a secure and unified fashion. At some point in time, an idea of connecting the two networks via LAN-to-LAN IP-Sec VPN has been suggested. However, after a thorough consideration this was not considered an option. At present time, maintenance access to the systems is accomplished as follows:

Access to production systems

- A number of Internet facing UNIX login servers (“turnstiles”) have been built on the CyberGrants DMZ. Access is allowed via Secure Shell v.2 protocol using public key infrastructure (PKI). Upon successful login, users may login to other systems, also via SSH.

- Access to firewalls is allowed via SSH from the internal network. All other types of access will require physical attendance (e.g. hardwired access to the firewall console)

- To obtain console access to UNIX servers users must use SSH to login to the turnstiles, then use telnet to login to UNIX consoles via terminal concentrators.

- Optional access is provided via VNC in cases where graphics are required. In such situations, a VNC server is started on turnstile servers. Client applications are then started on other servers and display against the VNC server. A VNC client in the corporate office is used to connect to VNC server. It must be noted that such procedures are initiated on demand only; VNC server software does not run all the time, and required TCP ports are only enabled within the duration of such procedures.

- FTP access is allowed to our production FTP server as means of transferring AP and donor feeds. Transferred files are normally encrypted. FTP server is custom compiled, it allows access by real users only, and anonymous access is prohibited. The FTP subsystem runs in a jailed environment created within the OS.

Access to systems in the corporate office

- Access to UNIX servers is allowed via Secure Shell v.2 protocol using public key infrastructure (PKI).

- Access to the corporate firewall is allowed via SSH from the internal network and via HTTPS. All other types of access will require physical attendance (e.g. hardwired access to the firewall console)

- Optional access is provided via VNC to both UNIX and Windows based servers in cases where graphics are required. VNC server software normally runs at all times. VNC software on UNIX servers must be started when needed.

- Remote PPTP VPN access is permitted to the corporate network. By itself, VPN access only establishes IP connectivity to the network. Users must obtain additional credentials in order to use other services (e.g. SSH keys to access UNIX servers, Lotus Domino ID files to read corporate e-mail, etc.)

Key generation and access authority

- Maintenance access to CyberGrants servers is restricted to CyberGrants employees only, with no exceptions

- Access via Secure Shell is granted to individuals directly responsible for maintaining the systems – the CyberGrants Operations. The Operations is a small group of people consisting of server administrators, database administrators, and senior developers

- Secure Shell keys are generated by the server administrator only. Private keys require to be protected by pass phrases.

- Privileged access to servers and firewalls (i.e. ‘root’ on UNIX and ‘enable’ on Cisco devices) is restricted to the server administrators

- Privileged access to Oracle databases (i.e. users SYS, OPER, SYSTEM, DBA role, and CyberGrants custom Oracle schemas) is restricted to database and server administrators.

- VPN access to the corporate network is granted on demand subject to approval by upper management

- Access to corporate e-mail is granted to all staff members; e-mail accounts are created by the server administrator.

- Access to the code repository is granted to developers only. Accounts are created by the senior developer.

.

6. Hosting Facility (NaviSite, Inc.)

6.1 General information

Site functions

NaviSIte, Inc. is a vendor that provides CyberGrants with the following paid co-location services:

- Secure cabinet and floor space for CyberGrants’ servers and network equipment

- Climate-controlled data center grade environment

- Unlimited and reliable network bandwidth

- A block of publicly routable class-C IP addresses

- IP services such as DNS, SMTP relays, and time synchronization

- External monitoring of selected public IP addresses

6.1.2 Site location

The Massachusetts branch of NaviSite, Inc. is located approx. 5 miles from CyberGrants corporate office, at the following address:

NaviSite, Inc.

400 Minuteman Road

Andover, MA 01810

Phone: 888-298-8222

Fax: 978-682-8300



6.2 Environmental requirements

Building

- Building conforms to local standards of structural integrity and forceful entry. Also conforms to local geographic area’s seismic ratings; in general, not subject to sensible seismic activity and is located away from faults

- Building is surrounded by 3’ tall 12” wide concrete wall to prevent vehicular damages; reinforced steel is used for construction

Server floor

- Server floor is on ground level without windows or outside walls, with multiple door access

- outside the premises power and network cables are housed in pipes incased in concrete banks to prevent damages and interference

- Cable runs within the server floor are underneath raised floors and above suspended ceilings

- Regulated 72 (F) ambient air temperature (+/- 2 degrees), 45% humidity (+/- 5%) maintained at all times

6.3 Electric power

Power feeds

- Power feeds are supplied from two independent substations and terminate at a perimeter switch located approx. 0.5 miles from the main building. From the switch, a single feed is supplied to the datacenter and splits into two transformers located on premises. From that point, dual feeds are supplied to the internal facilities

- N+1 redundancy in all systems (both A/C and D/C)

- Redundant “A” and “B” circuits

- Automatic Transfer Switches (ATS) and bypass circuits to provide full N+1 redundancy

Emergency features

- Power-off switches (“red buttons”) are installed in strategic places inside the computer room and allow equipment to be turned off quickly

Back-up generator

- Back-up generator is sized to run entire site for at least 24 hours without re-fueling

- Un-interrupted service for at least 4.5 days (108 hours) with re-fueling

- Re-fueling is performed without shutting the generator down

- 24/7 national maintenance and re-fueling contract

- Fuel is recycled periodically to avoid problems due to stagnant fuel

- Generator tests are performed monthly

Uninterruptible power supplies

- Parallel UPS, utilizing HotSync® technology, valve-regulated lead-acid (VRLA)

- N+1 redundancy (both A/C and D/C)

- UPS units are partitioned from the main server floor and located in a different room

- Capable to sustain full D/C power for at least 2 hours

Power conditioning

- Large A/C capacitors and surge arrestors are installed for incoming current that feeds UPS units

- Electric current leaving UPS units is “cleaned up” with additional circuits to further remove spikes and voltage drops

6.4 Fire protection requirements

Fire detection mechanisms

- Early warning VESDA fire detection systems and FM 200

- Smoke and high temperature sensors installed inside the server floor

- Liquid sensing alarms below raised floors in all rooms.

Fire suppression mechanisms

- Extinguishers are installed in strategic places according to local regulations

- Dry-pipe, pre-action, double interlock suppression, with zone specific discharge

- Gaseous Clean Agent (GCA) fire suppression systems are installed and spaced evenly along perimeter walls to allow quick access

- Automatic sprinkler systems are installed all computer and storage rooms and are subject to periodic inspection by NaviSite’s maintenance crew

Other features

- At least 2 hour fire separation between areas of disparate functions (i.e. main server floor and entrance lobby, etc.)

- Equipment is located in cabinets designed specifically for the hosting facility and capable to protect against certain amount of accidentally discharged liquid

- Ordinary combustibles (tapes) are stored outside the computer room

- HEPA filters for any distribution systems that provide outside/conditioned air to the data center

Staff and policies

- Facilities are inspected by local fire department according to applicable regulations

- Fire department crews have access to all areas of the data center and will be able to enter the premises quickly in case of a fire emergency

- Onsite staff perform periodic training to their onsite personnel on the equipment use

- Documented formal policies are available from NaviSite, Inc. upon request

6.5 Physical access

Area segmentation

Building is divided into areas depending on levels of security and function, such as:

- Main lobby and waiting area, and security desk

- Atrium area housing Network Operations personnel and monitoring equipment

- Server floor (ground level); server floor is further split into areas of disparate functions

- Corporate quarters (offices) and recreational area for on-site employees (second floor)

Secure multiple door access

To reach server floor, visitors must pass through intermediate areas and check points in a sequence indicated below:

- Card access through outer doors (main entrance) leading to the lobby for employees; non-employees (visitors) must be ‘buzzed in’ from inside by the security desk

- Biometric hand reader access through doors leading into atrium (Operations); access also requires card and/or PIN

- Card access from the atrium area to the server floor

Security surveillance

- Digital surveillance cameras installed in strategic places (main lobby, atrium, and server floor)

- Digital audit trail is retained for 30 days; other records (visits, etc.) retained for longer periods of time

Admittance

- Access is restricted to designated employees and must be negotiated between CyberGrants management and NaviSite

- One-time visitors (e.g. hardware repair vendors) must be accompanied by authorized CyberGrants personnel

- Access requires positive photo ID, which must be surrendered to security desk upon entry and returned upon exiting the building. Authorized CyberGrants employees must also possess knowledge of personal pass code

- All visits are logged, including times, names, and reasons

Security and tracking of equipment

- Cabinets that house systems equipment are kept locked at all times except when maintenance is in progress. Only NaviSite personnel is allowed to open and lock cabinets on behalf of the customer

- Equipment pieces are tagged and inventory is maintained in NaviSite’s database, including serial numbers, models, and descriptions

- 48 hour advance notice must be given for arrivals and removals of equipment, along with serial numbers; this does not include small items such as tapes and hard drives

7. Network setup: production

7.1 Abstract

The CyberGrants production network is a two tier network. Our hosting facility, NaviSite, Inc, provides CyberGrants with a block of 16 public IP addresses routed to CyberGrants firewall through a 100 Mbps VLAN.

The CyberGrants firewall is a dual Cisco PIX 515 Unrestricted firewall configured in high availability mode. Each PIX unit contains two on-board FE interfaces and an additional four-port FE card. Publicly routable IP addresses are statically translated (NAT) into their respective addresses configured on hosts on the other (protected) side of the firewall. Three physical 100 Mbps networks are configured behind the firewall:

▪ CyberGrants DMZ (CG-DMZ)

This DMZ houses CyberGrants publicly accessible front-end Web / Applications servers. Selected IP addresses on the DMZ are open for incoming Internet traffic for HTTP (TCP/80, TCP/9990), HTTPS (TCP/443), SSH, and FTP.

▪ Auxiliary DMZ (Aux-DMZ)

This DMZ is reserved for servers that run both Web / Application components and databases on the same host platforms. Although the CyberGrants Grants Management System is a multi-tiered installation, some customers may have specific needs and constraints to install both tiers on the same physical server. Such systems are installed on this DMZ segment, which is isolated from the main DMZ and the internal network. Selected IP addresses on this DMZ are open for incoming Internet traffic for HTTP (TCP/80, TCP/9990), HTTPS (TCP/443), and SSH.

▪ CyberGrants internal network (INSIDE)

This network houses CyberGrants back-end servers running Oracle9i database software. This segment accepts no public traffic. The allowed traffic coming from the CyberGrants DMZ is restricted to Oracle Net8 protocol (TCP/1526) and SSH.

7.2 Network topology

8. Network setup: corporate office

8.1 Abstract

The CyberGrants corporate network is located in Andover, MA approximately 5 miles from the production plant (NaviSite, Inc.) The office is connected to the Internet via a dedicated T1 link provided by XO Communications, Inc. XO also provides CyberGrants with a block of 32 publicly routable IP addresses.

The CyberGrants corporate firewall is a single MultiTech RouteFinder VPN firewall configured with three 100 Mbps interfaces: public, DMZ, and internal. A number of public IP addresses are statically translated into their respective addresses configured on DMZ hosts. The configured network segments are:

▪ Public

This is the unprotected side of the firewall facing the Internet; it is connected to XO Communications’ router. No hosts have been installed on this segment due to high security risk. This segment is reserved mainly for network connectivity testing. A number of public IP addresses have been configured on the firewall and are statically linked to hosts on the DMZ.

▪ DMZ

This network segment contains Internet facing hosts: mail proxy, Disaster Recovery (fallback) Web / Application server, and the staging Web / Application server. Access to this segment is allowed for HTTP protocol (TCP/80 and TCP/9990), and SSH.

HTTP connectivity is required to allow external customers to review pre-production functionality of the CyberGrants system before it is pushed into production, as well as for demonstrations of new concepts. The staging site operates on mocked up or obsolete data.

The Disaster Recovery Web / Application server is administratively sealed from the outside access due to the fact that it contains a copy of production data; however, in case a DR contingency plan needs to be invoked, the HTTP access to this site will be enabled.

▪ Internal

This network houses corporate workstations, DR database servers, staging database servers, development Web / Application and database servers, voice / PBX systems, network attached storage servers, and other devices. Access to this segment is allowed from the DMZ for the following services: SSH, SMTP, Oracle Net8, NetBIOS / SMB.

The corporate firewall also allows remote PPTP VPN connections for CyberGrants employees. The VPN allows access to various services on the corporate network and using client software such as Lotus Notes e-mail, Oracle SQL client, VNC, PBX software, SSH, etc.

8.2 Network topology

9. Intrusion Detection System

9.1. Network based intrusion Detection system (NIDS)

CyberGrants' implements Cisco Intrusion Detection System (IDS) on its Cisco PIX firewall. The IDS functionality comes bundled with Cisco PIX Firewall software v.6.2(2) The IDS performs auditing of incoming traffic, i.e. traffic coming in from the low security interface (the Internet) toward higher security interfaces (perimeter networks and the inside interface)

Cisco IDS provides an ability to trigger alerts and actions based on signatures found in packets that arrive on the outside interface. Two audit policies have been defined: informational policy and attack policy (IDS-Info and IDS-Attack, respectively). Packets matching the IDS-Info policy signatures are logged. Packets matching the IDS-Attack policy signatures are dropped, and the connection is reset if it is a part of an active session.

Alert messages are forwarded via syslog to a designated UNIX host located on the internal network, where they are logged into a file. The syslog facility designated for syslog is "local4". The log file containing IDS messages is rotated on a nightly basis and archived for the duration of 6 months.

Another IDS measure is Unicast RPF IP spoofing protection (RFC 2267) that does a route lookup based on the source address. If there is no route found for the packet or the route found does not match the interface on which the packet arrived, the packet is dropped. The RPF implements ingress filtering (i.e. checks inbound packets for IP source address integrity) on the outside interface.

9.2 Host Based Intrusion Detection System (HIDS)

9.2.1 Tripwire

As a part of the intrusion detection system, CyberGrants implements Tripwire for Servers, an integrity assessment tool from Tripwire, Inc. The software is installed on the CyberGrants Web and Application servers (Tier 2) The servers are positioned on the perimeter network (DMZ). Tripwire for Servers is installed in command line mode. Snapshots of the data have been created on each server. Data integrity checks are performed on a daily basis via a cron job. A report is sent via SMTP mail to CyberGrants’ sysop account and audited periodically to determine if any changes have occurred.

The following categories of data are subject for integrity checks by Tripwire:

• Operating system image (configuration files, binaries, libraries, special device files, etc.)

• Application image (static vendor configuration files, binaries, libraries, device files, etc.)

• CyberGrants proprietary application files and directories (static HTTP content and images, configuration files for online applications, Java programs and servlets, etc.)

• Miscellaneous entities (custom compiled FTP server files, Secure Shell configuration files and keys, log files and directories, etc.)

Log files and reports generated by Tripwire for Servers are stored in a dedicated IDS log directory; the retention period of IDS logs is 3 months.

9.2.2 Log auditing

Additional method of detecting unauthorized entry and suspicious activity deployed on CyberGrants servers is log monitoring. This is accomplished using a set of scripts that run via cron facility. The primary candidates for auditing are the following logs:

• /var/adm/messages

This file is parsed on a nightly or semi-daily basis. Options allow to search through the file pre-defined tokens or phrases indicative of possible unauthorized login attempts, etc.

The output of the log parser is sent to system operator via e-mail

• /var/adm/sulog

This file is processes on a nightly or semi-daily basis. The incremental content of su attempts is sent to system operator via e-mail

• /CG/logs/IDS/messages

This is the file on a DMZ host where Cisco PIX Intrusion Detection System sends its syslog output. The content of the log is made up of entries indicating IP packets arriving on the outside interface of the firewall and either rejected or dropped due to non-compliance with the firewall access list. The goal of the script is to search the file for well known and most dangerous signatures and send the results to the system operator via e-mail

10. Monitoring of services and events

10.1 Abstract

System event monitoring for CyberGrants servers and CyberGrants client systems installed on CyberGrants physical network) is built around the ‘Mon’ software written in PERL language by Jim Trocki of Transmeta Corp. The software is available under the GNU General Public license at

The core part of the software is a high performance scheduler engine designed to run as a daemon and execute arbitrary programs (“modules”) at scheduled intervals. Depending on the completion status of a module, the software will execute arbitrary “alert” programs.

The software comes bundled with numerous pre-written modules to probe various systems services and facilities such as FTP, telnet, NTP, HTTP, SSL, DNS, RPC, SMTP, POP3, IMAP, and many others. It also contains alert modules that can be used to send messages to designated individuals via SMTP mail, SNPP, or by directly submitting pages via HTTP to paging facilities’ web sites.

The monitoring software is installed across all servers on CyberGrants DMZ and the inside network. Coupled servers (i.e. those capable of automatic failover or manual switchover) are configured such that a standby host performs monitoring of its active peer. Standalone servers are monitored by a central monitoring host.

10.2 Alert types

The following alerts are currently deployed on CyberGrants servers:

1. Pager alert

Functionality: an HTTP session is created between a monitoring host and service provider paging facility (SkyTel). The page is submitted via a command line interface in the same fashion as if it were done using a Web browser. The page is sent to CyberGrants production pager. The page contains hostnames of the machine it came from, hostname of the machine where a failure was detected, facility name, time stamp, and a short abbreviation describing the failure.

Based on: LWP::UserAgent

2. SMTP alert

Functionality: a SMTP mail is sent to CyberGrants system operator account (sysop) containing a description of a problem. The message includes a hostname of the machine the page came from, a hostname of the machine where failure was detected, name of the facility, description of the failure, and a time stamp.

Based on: shell script, UNIX sendmail

10.3 Monitored services

At present time, the following services are monitored on CyberGrants servers:

1. HTTP (TCP/80)

Functionality: a direct TCP socket connection between a monitoring host and a web server. An HTTP session is established and HTTP GET request is submitted to probe public HTTP listener.

Based on: LWP::UserAgent

Frequency: 3 to 5 minutes.

2. HTTP (TCP/9990)

Functionality: same as TCP/80 with an addition of HTTP Basic user authentication in HTTP header and Base64 encoding of the user credentials. A HTTP GET request is submitted along with user name and password. A submitted URL contains a prefix with Oracle9iAS DAD. Effectively, this allows testing both HTTP listener and the availability of Oracle9i database.

Based on: LWP::UserAgent and MIME::Base64

Frequency: 5 to 7 minutes.

3. HTTPS (TCP/443)

Functionality: same as TCP/9990, in conjunction with SSL-enabled libraries. A HTTP get request is submitted via SSL along with user credentials to probe Apache SSL listener and Oracle9iAS backend database.

Based on: OpenSSL and Crypt::SSLeay

Frequency: 5 to 7 minutes

4. ICMP ping

Functionality: an ICMP Echo request is sent to a peer host.

Based on: shell script with OS bundled ping

Frequency: 3 to 5 minutes

5. Process monitor

Functionality: to monitor OS and application processes. The probe is initiated locally on the same server and checks against a list of processes and arguments supplied in a configuration file.

Based on: shell script

Frequency: 3 to 5 minutes

6. Space monitor

Functionality: to monitor disk space utilization. Probe initiated locally on the same server and checks space usage for each file system specified in a configuration file.

Based on: shell script

Frequency: 10 to 30 minutes

7. VxVM monitor

Functionality: to monitor state of objects managed by Veritas Volume Manager. Checks performed locally. Probes run against VxVM physical disks, subdisks, plexes, and volumes.

Based on: shell script

Frequency: 5 to 10 minutes

8. SVM monitor

Functionality: to monitor state of objects managed by Sun Volume Manager (formerly Solstice Disk Manager) Checks performed locally. Probes run against SVM metadevices and metasets

Based on: shell script

Frequency: 5 to 10 minutes

9. Net8/SQLNet monitor

Functionality: a direct TCP socket connection between a monitoring host and Oracle database server. A SQL-Net session is established and queries are run against the database to retrieve its status. Optional queries can be performed to create a test table, and insert dummy values into and delete them from the table.

Based on: DBI::Perl, DBD::Oracle

Frequency: 3 to 5 minutes

10. Custom Reports monitor

Functionality: same as TCP/9990. A specially crafted URL is submitted to a monitored host. The URL contains a prefix that instructs the server to run a Java servlet. The servlet creates a SQL*Plus query and forwards the query to the Oracle9iAS Reports 6.0 facility. The reports server, in turn, contacts the backend Oracle9i database and creates a HTML or PDF report with the received data in it.

Based on: same as TCP/9990 module

Frequency: 10 to 20 minutes

11. Security event management

11.1 General Information

CyberGrants is a small-size company; management of security related events is therefore a part of our general event management policy and performed by the same individuals who maintain the systems.

11.2 Origins of security events

1. Alerts from “mon” software

The “mon” software is installed across all UNIX systems. Alerts generated by the software indicate various conditions: HTTP timeouts, lack of space, disk device failures, OS failures, etc. From the security perspective, this type of alerts may help to detect denial of service attacks (DoS)

Additional “mon” alerts also originate from IDS log monitoring modules to indicate that pre-defined intrusion signatures have been found in the logs.

2. Alerts from external NaviSite systems

CyberGrants hosting facility (NaviSite, Inc.) provides services such as external ping and TCP probes. Such probes are initiated from designated NaviSite’s hosts and send alarms to their Network Operations Center (NOC) Such events are usually critical (i.e. host not responding to ICMP ping or TCP handshake)

3. Alerts from scripts

A number of scripts run periodically on CyberGrants hosts (e.g. log parsers). Most of the scripts are security-oriented and help to detect potential break-ins and perform forensic actions

11.3 Targets of security alerts

1. CyberGrants production pager

Critical alerts from “mon” software and some log parsing scripts are sent to the production pager. The pager is enabled at all times within all US time zones and carried by the systems administrator.

2. CyberGrants general hotline

Events detected by NaviSite NOC during regular business hours are phoned in by NaviSite operators

3. Mobile phone

During off-hours (between 5pm and 8am EST) NaviSite NOC contacts CyberGrants at a designated mobile phone

4. CyberGrants phone contacts

Certain database and software conditions detected by CyberGrants clients are reported by phone to the respective client account coordinators and either analyzed by the coordinators or handed off to developers of the systems administrator for resolution

5. SMPT mail

Non-critical alerts from “mon” software, Tripwire reports, log parsing reports, non-critical messages from CyberGrants personnel and CyberGrants clients are send to CyberGrants system operator. Human-initiated e-mail is usually sent to account coordinators and/or software developers.

11.4 Response to security events

Security and other events are loosely classified into four categories: disastrous, critical, non-critical, and informational. Usually events are handled and resolved by the CyberGrants personnel. In cases where a third party vendor needs to be involved, CyberGrants will coordinate the efforts with the respective vendor. The events falling under the disaster category constitute extremely rare conditions such as fire at the hosting facility datacenter, forced physical break in and theft of equipment, or the hosting facility going out of business on a very short notice.

Systems administrators, developers, and account coordinators maintain lists of immediate contacts for the entities they administer and support including but not restricted to:

▪ Contacts for hardware support vendors

▪ Contacts for software support vendors

▪ Contact numbers for CyberGrants’ clients

▪ Contact numbers for CyberGrants’ team members

▪ Contract numbers

▪ Warranty information

▪ Device serial numbers

▪ Device part numbers

▪ Login and password information (e.g. firewall “enable” passwords, UNIX account passwords, SecureShell keys, SSL server key pass phrases)

▪ Original device configuration information (e.g. PIX firewall rules, Apache server configuration files, Oracle9iAS DAD configuration files)

Upon detection of a problem, actions may depend on how severe the condition is:

▪ Critical events may require immediate intervention such as shutdown of the application, database, or operating system to mitigate denial of service attacks. If the condition is severe and loss of service or data is in progress, systems administrator and/or developers are allowed to initiate corrective actions before contacting their management. This is especially true if the management cannot be reached for some reason

▪ Non-critical events are resolved either immediately if bringing down the system is not required; otherwise downtime is negotiated between CyberGrants and our clients and conditions are resolved during off-hours

▪ Informational events are usually resolved during working hours. They can also be escalated as non-critical events if necessary and handled the same way non-critical events are handled

Disastrous events must always be handled with intervention of all key subject matter experts and CyberGrants’ management (i.e. CyberGrants President) A plan may need to be executed to recover from the disaster; this plan is described in the CyberGrants “Disaster Recovery Plan” document

12. Change Control Management

CyberGrants Change Control Management defines a brief set of rules that must be followed when performing changes on production and staging systems. The rules represent the core part of the change control policy and have been approved by the management. However, there may exist separate and more detailed policies created on a per-project basis.

▪ Changes must be tested on the CyberGrants staging environment at Two Dundee Park before they are implemented on production. The duration of the testing period must be at least 1 week before it is considered successful.

▪ Changes on production systems must be documented in a format readable and accessible by all key members involved in the change, and the upper management. Documentation must be retained for at least 1 year.

▪ Changes of CyberGrants code must be registered (checked in) with the local code versioning system (VSS)

▪ Changes affecting system functionality and performance must be approved by the CyberGrants upper management and respective management and account coordinators at client organizations whose applications are affected

▪ A backout plan must be created, tested, and documented in order to be able to reverse the change in case it does not improve or affects functionality or performance, or affects it in an unpredictable way. The backout plan must accommodate details such as timeliness and contact information

▪ Changes must be negotiated with and approved by clients whose applications will be affected at least 1 week in advance. Maintenance must not interfere with certain well-known client activities (e.g. automated data feeds, presentations, etc.)

▪ Under normal conditions, a formal notice must be sent to clients one week in advance regarding scheduled maintenance if it requires services to be down for more than 3 minutes during business hours and more than 10 minutes during off-hours or weekends

▪ If conditions allow, maintenance must take place during off-hours, between 2am and 8am EST. The recommended least-busy days are Saturday or Sunday.

▪ If a change requires client involvement during maintenance, appropriate time frames and communication channels must be discussed in advance with respective clients and are responsibility of CyberGrants’ account coordinators

▪ Bugs in the code must be documented and checked in with the CyberGrants bug tracking database in Lotus Notes

▪ Bug history and fixes must be retained for at least two years from the moment bugs are discovered, or for the lifetime of the major code release, whichever comes first

13. Backup policy and procedures

13.1 Abstract

To backup its data, CyberGrants, Inc. employs two independent policies, one for production data and the other for its corporate office. This is necessary due to significant differences between two environments: OS and hardware platform diversity, data retention periods, requirements for data recovery in emergency situations, and logistical issues.

Production environment is homogeneous; it is based on UNIX servers running the same operating system with consistent versions and patch levels. The main function of the production systems is to run the Grants Management Application software. There are a few other, auxiliary UNIX systems: FTP servers, a backup server, a logging server, etc. Consistent platform architecture and purpose allow for unified backup procedure.

Corporate office contains a variety of software and hardware platforms that encompass unrelated projects and installations: development systems, DR systems, staging systems, code repository, e-mail servers, PBX servers, user workstations, etc. Development, DR, and staging systems are UNIX-based; others run various versions of MS Windows. Due to such diversity, per-project backup procedures have been employed, in many cases using backup tools native to the applications.

13.2 Production site backups

13.2.1 Backup server hardware and software

o Sun Ultra 5/10

o Sun Solaris 8

o DLT tape library with a single DLT 7000 tape drive

o Veritas NetBackup BusinessServer v4.5

13.2.2 Backup media

o DLT (Digital Linear Tape) IV cartridges

o Native capacity: 35 GB (70 GB compressed)

13.2.3 Oracle Database backups to disk

o Weekly full (Sunday): full online backup of Oracle database is performed weekly on Sundays. A self-contained, compressed set of Oracle files is created on the database server and stored within a file system allocated for that purpose.

o Daily incremental: Oracle database logs are archived every hour into a special location on the database server and replicated on a standby peer server

o Nightly logical: logical backup (export) of the Oracle database is performed nightly; export dump file is stored on the database server.

o Offsite DR copy: at regular intervals, Oracle database logs are transmitted via Secure Shell to the corporate office, where they are applied to a standby instance at 2 am.

13.2.4 Tape backups

o Weekly full (Sunday): full backup of operating system binaries, application software binaries, Oracle database binaries, Oracle database weekly online backup sets, and Oracle weekly export dump (see Section 2.5.2.3)

o Daily incremental (Monday – Saturday): differential incremental backup of operating system binaries, application software binaries, Oracle database binaries, application and system logs, Oracle database archived redo logs accumulated during the course of the day, and nightly Oracle export dump

13.3 Corporate office site backups

13.3.1 Backup server hardware and software

o Sun Ultra 5/10

o Sun Solaris 8

o DLT tape library with a single DLT 7000 tape drive

o Native UNIX backup tools (ufsdump)

13.3.2 Backup media

o DLT (Digital Linear Tape) IV cartridges

o Native capacity: 35 GB (70 GB compressed)

13.3.3 Application backups to disk

o Code repositories, phone PBX, e-mail systems, and other important machines are backed up weekly to a network attached storage (NAS) server drives via SMB protocol

o CyberGrants staff members have subdirectories allocated for them on the NAS server. They are advised that any customer related files and other important electronic documents created on their workstations should be backed up to the respective staff folders; this procedure is performed by the staff members at their discretion

13.3.4 Tape backups

o Monthly full for Oracle databases: full cold backup of all Oracle databases (DR, staging, and development) is performed on first Sunday of each month. Monthly full backup for Oracle databases in the corporate office has proven to be sufficient because the databases can be rebuilt using either production or corporate backups and applying source code from the code repository.

o Monthly full for network-attached storage: full cold backup of the corporate NAS server is performed monthly. The backup contains files created by CyberGrants employees, weekly backup sets of various office applications, etc.

13.4 Data retention policies

o Oracle full backup on disk 1 week

o Oracle archived logs on disk 1 week

o Oracle daily exports on disk 1 week

o Oracle weekly export dumps on disk 1 month

o Oracle monthly export dumps on disk 1 month

o Full tape backups 10 years

o Incremental tape backups 2 weeks

13.5 Media logistics policy

o Production tapes are collected once a week and stored off-site in the corporate office for 2 months.

o Production tapes older than 2 months are shipped through a third party media archiving company for permanent storage in a fireproof, climate controlled vault. Tapes are collected for storage once a month

o Corporate backup tapes are shipped off-site for permanent vaulting once a month in one batch along with production tapes

Part III

Appendices

Appendix 1

Operating system hardening task examples

Note to readers

The tasks described in this section are for illustration purposes only. The list of tasks in this document is by no means comprehensive or up-to-date. It is not an actual task list used by the CyberGrants engineers on the field. The actual procedures may be different and subject to change to reflect newly discovered security threats, requirements of new software and operating system releases, changes in the security policy, etc. Thus, the correctness and coherence of the below procedure are not guaranteed by the CyberGrants Operations team.

Abstract

CyberGrants production servers’ operating system is Sun Solaris 8. A master image of an operating system is maintained in our software repository; it is used to install a copy of an operating environment on servers with the same hardware characteristics. The image is pre-configured and fine tuned for the best security and performance. Since the same image is used across groups of servers, it assures consistency in the OS version and features.

Approximately two or three times a year, the systems are patched to the latest available levels of kernel and security. Depending upon particular software installed on the servers, specific OS patches may also be applied, e.g. patches recommended for Volume Manager or Oracle Database software.

Operating system hardening tasks

File Permissions

✓ umask Setting

Set initial file creation umask to 0022 by un-commenting the following entry in /etc/default/login file:

UMASK=022

✓ xhost Permissions

On headless systems (i.e. systems not equipped with physical frame buffer devices), the xhost binary should be made executable by user root only (as opposed to its default setting of 0775). Perform the following:

# chmod 0744 /usr/openwin/bin/xhost

# chmod 0744 /usr/X/bin/xhost

✓ suid Programs

Identify suid executable binaries and scripts on the system:

# find / -type f \( -perm -04000 –o –perm -02000 \) –exec ls –lg {} \;

For many programs, suid bit can be turned off by changing permissions to 0555 or similar.

Care should be exercised, however, because some suid programs may be required for normal operation.

TCP/IP Stack

✓ Random Number Generation

Set the TCP random generation number to true random by adding the following entry in etc/default/inetinit file:

TCP_STRONG_ISS=2

An alternative way to accomplish this is to use ndd command in one of the system initialization scripts (see “Tunable Parameters” section)

✓ Tunable Parameters

Create an executable script, cg_inetfix, in /etc/init.d directory using the following commands:

# touch /etc/init.d/cg_inetfix

# chown root:sys /etc/init.d/cg_inetfix

# chmod 744 /etc/init.d/cg_inetfix

# cd /etc/rc2.d

# ln -s /etc/init.d/cg_inetfix S70_cg_inetfix

Set the TCP, UDP, and IP parameters by adding the following lines to cg_inetfix file:

ndd -set /dev/tcp tcp_recv_hiwat 32768

ndd -set /dev/tcp tcp_xmit_hiwat 32768

ndd -set /dev/tcp tcp_time_wait_interval 60000

ndd -set /dev/tcp tcp_conn_req_max_q 1024

ndd -set /dev/tcp tcp_conn_req_max_q0 2048

ndd -set /dev/tcp tcp_strong_iss 2

ndd -set /dev/tcp tcp_keepalive_interval 900000

ndd -set /dev/ip ip_forwarding 0

ndd -set /dev/ip ip_strict_dst_multihoming 1

ndd -set /dev/ip ip_forward_src_routed 0

ndd -set /dev/ip ip_forward_directed_broadcasts 0

ndd -set /dev/ip ip_enable_group_ifs 0

ndd -set /dev/ip ip_ignore_redirect 1

ndd -set /dev/ip ip_respond_to_echo_broadcast 0

ndd -set /dev/ip ip_respond_to_timestamp 0

ndd -set /dev/ip ip_respond_to_timestamp_broadcast 0

ndd -set /dev/ip ip_respond_to_address_mask_broadcast 0

ndd -set /dev/ip ip_send_redirects 0

ndd -set /dev/ip ip_path_mtu_discovery 0

Network Services

✓ NFS Server

Rename NFS server startup script:

# cd /etc/rc3.d

# mv S15nfs.server s15nfs.server

✓ NFS Client

Rename NFS client startup script:

# cd /etc/rc2.d

# mv S73nfs.client s73nfs.client

Edit /etc/dfs/dfstab and comment out or delete all entries that contain ‘share’ command;

✓ Automounter

Rename automounter startup script:

# cd /etc/rc2.d

# mv S74autofs s74autofs

✓ System V Printing Services

Rename LP startup script:

# cd /etc/rc2.d

# mv S80lp s80lp

✓ sendmail

Rename sendmail’s startup script:

# cd /etc/rc2.d

# mv S88sendmail s88sendmail

✓ Berkeley “r” Services

Comment out the following "r" services in /etc/inetd.conf (disregard this step if the entries have been commented out as part of any other procedure in this document):

rlogin, rsh, rcp, rexecd, rexd

“Pin” down (disable) password-less “r” services using the following commands:

cp /dev/null /.rhosts

cp /dev/null /etc/hosts.equiv

chown root:root /.rhosts /etc/hosts.equiv

chmod 444 /.rhosts

chmod 600 /etc/hosts.equiv

✓ FTP Services

Comment out ftp service in /etc/inetd.conf (disregard this step if the entries have been commented out as part of any other procedure in this document).

Add all system users to /etc/ftpusers file to ensure that their logins are locked up even if inetd allows ftp. The following command may be useful:

# cat /etc/passwd | cut -f1 -d: > /etc/ftpusers

If, for any reason, ftp service is required on the system, install the chroot’ed version of WU ftp server. It is available on the CG distribution host.

✓ Common Desktop Environment (CDE) Login Daemon

If the system is headless and will not be running X server, rename the DT login daemon startup script:

# cd /etc/rc2.d

# mv S99dtlogin s99dtlogin

✓ Media Volume Management

Rename the vold’s startup script:

# cd /etc/rc.d

# mv S92volmgt s92volmgt

✓ SNMP Services

Rename SNMP service startup script:

# cd /etc/rc3.d

# mv S76snmpdx s76snmpdx

✓ Other inetd Services

Comment out the following entries from /etc/inetd.conf file and re-initialize inetd daemon by sending it a HUP signal once the changes have been made:

name, shell, login, exec, comsat, talk, uucp, tftp, finger, systat, netstat, time, echo, discard, daytime, chargen, rquotad, rusersd, sprayd, walld, rstatd, rexd, ufsd, fs, printer

Note that if all services offered by inetd have been disabled (meaning that all entries in /etc/inetd.conf have been commented out), inetd daemon itself becomes obsolete and it may be rational to disable it by editing /etc/init.d/inetsvc file and comment out the entry where /usr/sbin/inet.d is started:

/usr/sbin/inetd -s &

Logging

✓ Modify /etc/rc2.d/S72inetsvc script to invoke inetd with the –t option:

/usr/sbin/inetd -s -t &

✓ Enable login attempt logging:

touch /var/adm/loginlod

chmod 600 /var/adm/loginlog

✓ In the /etc/default/su file, make sure to uncomment an entry that enables logging of su attempts:

SYSLOG=YES

✓ Remote logins as certain "non-human" application users (oracle, ias, etc.,) are not allowed

✓ Connections to SSH port 22 are only allowed to “human” users; all accounts must have their private keys protected by a pass phrase, conventional UNIX authentication is not allowed

Remote root login

✓ Remote root login must be disabled. To become root, a user must login into their personal account first and use the ‘su’ command to gain root privileges. To disable remote root login, un-comment the following entry in /etc/default/login file:

CONSOLE=/dev/console

Using of “su” command

✓ Using the ‘su’ utility should be restricted to a selected number of users. Accounts allowed to use ‘su’ are the ones that belong to individuals (i.e. authorized CyberGrants’ staff) who login into the system remotely in order to perform maintenance or other tasks. Other UNIX accounts such as those used to run application daemons (e.g. ‘oracle’ or ‘ias’) should be restricted from using ‘su’. To accomplish this, become root and perform the following :

- add the following entry to the /etc/group file to create a new UNIX group, suusers:

suusers::115:

- add all users who will use su command to the ‘suusers’ group, in the /etc/group file;

- run the following commands to change ownership and permissions on ‘su’ executables:

chown root:suusers /bin/su /usr/bin/su /sbin/su.static

chmod o-x /usr/bin/su /bin/su /sbin/su.static

Login shells

✓ User logins should be restricted to a selected number of UNIX shells, such as sh, ksh, or csh. To accomplish this, modify or create a file, /etc/shells, and put the following lines in it:

/bin/sh

/bin/csh

/bin/ksh

Operating system footprint

✓ Operating system and application footprints such as banners should be reduced or eliminated. For example:

- Disable operating system banner by adding the following entry to /etc/default/telnetd file:

BANNER=”\r\n\r\n”

- Disable default ftpd banner by adding the following entry to /etc/default/ftpd file:

/etc/default/ftpd should contain: BANNER=””

Kernel Security

✓ For systems running Solaris 8, add the following entries to /etc/system file to prevent stack overflow attacks (or install patch 109320-01 or higher):

set noexec_user_stack=1

set noexec_user_stack_log=1

Note that some programs may need to be able to execute code in their stacks. Make sure to test the application before the system is put into production and see if it works with this setting.

Appendix 2

Application security hardening tasks examples

Note to readers

The tasks described in this section are for illustration purposes only. The list of tasks in this document is by no means comprehensive or up-to-date. It is not an actual task list used by the CyberGrants engineers on the field. The actual procedures may be different and subject to change to reflect newly discovered security threats, requirements of new software and operating system releases, changes in the security policy, etc. Thus, the correctness and coherence of the below procedure are not guaranteed by the CyberGrants Operations team.

Abstract

This document contains a list of tasks to be performed on CyberGrants Tier 2 servers running Oracle9i Application Server (9iAS) version 1.0.2.x. It is aimed to fix security vulnerabilities of certain 9iAS components such as Oracle HTTP Server powered by Apache, Oracle Reports, Oracle PL/SQL, Jserv, etc. The application hardening tasks described here represent a cumulative array of fixes to address various aspects of potential security threats known to date; however, the text does not contain explicit references to security advisories and may not reflect the latest exploits; it will not eliminate the possibility of a break-in and should only be used to compliment other means and best practices of security (such as firewalls, intrusion detection systems, security audits, patching of software, etc.)

Locations for configuration files and directories

To save some typing, this text refers to configuration files by their names, omitting their full pathnames, such as httpd.conf, jserv.conf, and so on. To help navigate through the file system, full pathnames for these files are listed below. Please note that here some files are referred by their default generic names; there may be more than one instance of each configuration file on the system, in which case their names may be slightly different and/or contain prefixes and suffixes. For example, if the system has two independent Apache listeners (one on port 80 and the other on port 9990) their names may be httpd_80.conf and httpd_9990.conf, respectively. Same is be true for Jserv configuration files that are referenced by the Apache configuration files.

$ORACLE_HOME: /CG/oracle/product/ias

httpd.conf: $ORACLE_HOME/Apache/Apache/conf/httpd.conf

jserv.conf: $ORACLE_HOME/Apache/Jserv/etc/jserv.conf

jserv.properties: $ORACLE_HOME/Apache/Jserv/etc/jserv.properties

oracle_apache.conf: $ORACLE_HOME/Apache/Apache/conf/oracle_apache.conf

plsql.conf: $ORACLE_HOME/Apache/modplsql/cfg/plsql.conf

wdbsrv.app: $ORACLE_HOME/Apache/modplsql/cfg/wdbsrv.app

xml.conf: $ORACLE_HOME/xdk/admin/xml.conf

ojsp.conf: $ORACLE_HOME/Apache/jsp/conf/ojsp.con

6iserver.conf $ORACLE_HOME/6iserver/conf/6iserver.conf

14.3 Implemented Security Patches

The following is an itemized list of security patches applied to various Oracle9i and/or Oracle9iAS components. The primary sources of the information that led to implementing the listed patches are security advisories (such as CERT, CVE, BugTraq, etc.) as well as audits performed on CyberGrants servers on a regular basis by third parties. This list is intended to grow over time as more vulnerabilities are discovered. For all issues, references are given to respective HTTP web sites as well as other sections of this document that describe implemented workarounds.

1. CERT:CA-2002-23: Multiple Vulnerabilities in OpenSSL and mod_ssl

URL:

CVE: CAN-2002-0656, CAN-2002-0082, and others.

Fix: apply patch #2492925 from for

Oracle HTTP Server(OHS) and mods v1.3.19; 08/15/02

This patch replaces openssl binary and mod_ssl.so shared library. It does not change

version of OpenSSL.

Note: apply patch #2424256 before applying this patch

2. CERT:CA-2002-17: Chunked-Encoding Issue



CVE: CAN-2002-0392

Fix: apply patch #2424256 from for

Oracle HTTP Server(OHS) and mods v1.3.19; 07/02/02

This patch replaces httpd binary without changing version of Apache.

Application hardening tasks

HTTP Server Resource Allocation

1. Make sure that the number of server processes to start initially is set to 5 in the httpd.conf file:

StartServers 5

2. Make sure that the lowest and highest numbers of spare server daemons is not too high; the default values are sufficient. This is set in the httpd.conf file:

MinSpareServers 5

MaxSpareServers 10

3. Set the maximum number of simultaneous client requests 150 (as opposed to a default settings of 300):

MaxClients 150

4. Set the maximum number of client requests per a child daemon process to 10,000 (as opposed to unlimited) in httpd.conf file:

MaxRequestsPerChild 10000

5. Set the number of client requests per a persistent connection to 100 (this should be a default setting) in httpd.conf file:

MaxKeepAliveRequests 100

6. Make sure that HTTP timeout for send and receive sides of the connection is set to no greater than 300 seconds; if possible, this value should be reduced to 180 seconds, in httpd.conf file:

Timeout 180

7. Make sure to enable persistent connections and set a timeout to 15 seconds, in httpd.conf file:

KeepAlive On

KeepAliveTimeout 15

HTTP Server Footprint and Status Reporting

1. Disable the server from reporting its version in server generated pages in httpd.conf file:

ServerSignature Off

2. Disable the mod_status loadable module from Apache by commenting out the following line in httpd.conf file:

LoadModule status_module libexec/mod_status.so

3. Disable the mod_info loadable module from Apache by commenting out the following line in httpd.conf:

LoadModule info_module libexec/mod_info.so

4. Disable (comment out) the alias and “Location” directive for server status in httpd.conf file:

5. Disable (comment out) the alias and “Location” directive for server-info in httpd.conf file:

6. Comment out or set to “Off” the “ExtendedStatus” directive in httpd.conf file (note that this line must be commented out if the mod_status module has been disabled in one of the previous steps):

ExtendedStatus Off

7. Disable HTTP server from advertising its version in HTTP header by adding the following directive to httpd.conf file:

ServerTokens Prod

Server Root Directories

1. Make sure that $ORACLE_HOME/Apache/Apache/conf directory and all files underneath are owned by user root, group root, and have correct permissions, e.g.:

# chown –R root:root $ORACLE_HOME/Apache/Apache/conf

# cd $ORACLE_HOME/Apache/Apache/conf

# chmod 0444 httpd_*.conf magic mime.types mod__ose.conf oracle_apache.conf

# chmod 0500 ssl.*

# chmod 0644 ssl.crt/*

# chmod 0744 ssl.crl/* ssl.prm/*

# chmod 0400 ssl.key/*

# chmod 0400 ssl.csr/*

Note 1: the original owner of these files and directories may be different (such as ias); changing the ownership to user root may cause problems during Apache software upgrades because the upgrade is usually performed as user ias. Thus, make sure to temporarily change these ownerships back to the original user before upgrade is peformed

Note 2: it is not necessary to change permissions on directories named ssl.* and files contained therein if SSL is not enabled

2. Make sure that $ORACLE_HOME/Apache/Apache/bin directory and all executables underneath are owned by user root, group root, and have correct permissions, e.g.:

# chown –R root:root $ORACLE_HOME/Apache/Apache/bin

# chmod 0755 $ORACLE_HOME/Apache/Apache/bin

# cd $ORACLE_HOME/Apache/Apache/bin

# chmod 0744 ./*

3. Make sure that all log files underneath $ORACLE_HOME/Apache/Apache/logs directory writeable by user root are owned by user root, group root, and have correct permissions. The directory itself should be owned by its original user (ias) due to the fact that some logs must be writeable by this user, i.e.:

# chown ias:oinstall $ORACLE_HOME/Apache/Apache/logs

# cd $ORACLE_HOME/Apache/Apache/logs

# chown root:root access_log_* error_log_*

# chmod 0644 access_log_* error_log_*

Apache Modules

1. Disable (comment out) the “LoadModule” directives listed below, from httpd.conf file:

LoadModule mmap_static_module libexec/mod_mmap_static.so

LoadModule vhost_alias_module libexec/mod_vhost_alias.so

LoadModule agent_log_module libexec/mod_log_agent.so

LoadModule referer_log_module libexec/mod_log_referer.so

LoadModule status_module libexec/mod_status.so

LoadModule info_module libexec/mod_info.so

LoadModule includes_module libexec/mod_include.so

LoadModule autoindex_module libexec/mod_autoindex.so

LoadModule userdir_module libexec/mod_userdir.so

LoadModule proxy_module libexec/libproxy.so

LoadModule usertrack_module libexec/mod_usertrack.so

LoadModule example_module libexec/mod_example.so

LoadModule dms_module libexec/mod_dms.so

LoadModule fastcgi_module libexec/mod_fastcgi.so

Server Name resolution

1. Make sure the HostNameLookups is set to “Off” in httpd.conf file:

HostnameLookups Off

Directory Indexing

1. Disable Apache mod_autoindex module by commenting out the following “LoadModule” directive from httpd.conf file (disregard this step if it has been already done as part of disabling Apache modules):

LoadModule autoindex_module libexec/mod_autoindex.so

2. Comment out the following lines from httpd.conf file:

Note: this step is optional and not required if the mod_autoindex module has been disabled

3. Specify a default indexing file (index.htm, index.shtml, etc. depending on the application requirement) using the “DirectoryIndex” directive, in httpd.conf file, e.g.:

DirectoryIndex index.html

User Directories

1. Disable Apache mod_userdir module by commenting out the following “LoadModule” directive from httpd.conf file (disregard this step if it has been already done as part of disabling Apache modules):

LoadModule userdir_module libexec/mod_userdir.so

2. Disable browsing of user directories by setting the “UserDir” directive in httpd.conf file (this may have no effect if mod_userdir has been disabled):

UserDir disabled

Directory Access Rules

1. Restrict the Document Root directory to default-deny stance in httpd.conf file:

Options None

AllowOverride None

Order Deny,Allow

Deny from All

2. Establish access conditions for each directory in httpd.conf file; e.g.:

Options SymLinksIfOwnerMatch

AllowOverride None

Order allow,deny

Allow from all

3. Create the rules similar to the above for all peer directories and their sub subdirectories (such as those defined by the “image” and “help” aliases in httpd.conf file).

4. Make sure that ownerships on all symbolic links are consistent with the user id HTTP server runs as (i.e. “ias”)

Miscellaneous Aliases and Directories

1. Disable (commented out) “Alias”, “Directory”, “Location”, and “Files” directives that are not required by the CyberGrants’ application. Pay specific attention to those “Alias” directives that contain matching “Directory” or “Location” directives as those may be especially dangerous. For example, the following are good candidates:

/jservdocs

Dynamic Monitoring Services (DMS)

1. Disable Apache module by commenting out the following “LoadModule” directive in httpd.conf file (disregard this step if it has been already done as part of disabling Apache modules):

LoadModule dms_module libexec/mod_dms.so

2. Comment out the following lines in httpd.conf file:

SetHandler dms-handler

3. Comment out the following DMS aliases from Apache Jserv configuration file, jserv.conf:

ApJServMount /dms1 /root

ApJServGroupMount /dms balance://group1/root

Process Monitoring

1. Restrict access to Apache process manager module service (“oprocmgr”) by adding the following lines to the default setting for mod_oprocmgr, in httpd.conf file. Substitute appropriate values for the network and subnet:

ProcNode

SetHandler oprocmgr-service

Order Deny,Allow

Deny from all

Allow from /

SetHandler oprocmgr-status

Order Deny,Allow

Deny from all

Allow from /

Oracle Fast CGI

1. Disable the FastCGI module by commenting out the following “LoadModule” directive from httpd.conf files (disregard this step if it has been already done as part of disabling Apache modules):

LoadModule fastcgi_module libexec/mod_fastcgi.so

2. Comment out the following FastCGI lines from httpd.conf file:

Perl Script Execution

1. Comment out the following directives from httpd.conf file:

PerlWarn On

PerlFreshRestart On

PerlSetEnv PERL5OPT Tw

PerlSetEnv PERL5LIB ""

SetEnv PERL5LIB ""

PerlModule Apache

PerlModule Apache::Status

PerlModule Apache::Registry

PerlModule Apache::CGI

PerlModule Apache::DBI

PerlRequire

2. Comment out the following “Alias” directive from httpd.conf file:

Alias /perl/ "/CG/oracle/product/ias/Apache/Apache/cgi-bin/"

Common Gateway Interface (CGI)

1. Make sure that there is only one active “ScriptAlias” directive in the httpd.conf file:

ScriptAlias /cgi-bin/ "/cgi-bin/"

2. Set ownership and permissions on the cgi-bin directory:

# chown root:root cgi-bin

# chmod 0755 cgi-bin

3. Set ownership and permissions on all binary executables in cgi-bin directory, e.g.:

# chown root:root rwcgi60

# chmod 0555 rwcgi60

4. Make sure that only required executable binaries remain under the cgi-bin directory; remove any other unnecessary binary executables and scripts (such as “printenv” or “test-cgi”)

5. Set the following for the “Directory” directive for the cgi-bin to allow execution of CGI programs, in httpd.conf file:

AllowOverride None

Options None

Order Allow,Deny

Allow from all

Oracle 6iserver Aliases

1. Comment out the following “Alias” and “SetEnv” directives from the 6iserver configuration file, 6iserver.conf:

Alias /webcache/ "/6iserver/reports60/server/cache/"

Alias /dev60html/ "/6iserver/tools/web60/html/"

Alias /forms60java/ "/6iserver/forms60/java/"

Alias /jinitiator/ "/6iserver/jinit/doc/"

Alias /dev60temp/ "/6iserver/tools/web60/temp/"

SetEnvIf Request_URI "f60cgi" ORACLE_HOME=/6iserver

SetEnvIf Request_URI "f60cgi" LD_LIBRARY_PATH=/6iserver/lib

SetEnv FORMS60_WEB_CONFIG_FILE "/6iserver/forms60/server/formsweb.cfg

Alias /rep60demo/ "/6iserver/tools/devdem60/demo/reports/"

Alias /rep60demo/ "/6iserver/tools/web60/html/"

Alias /forms60demo/ "/6iserver/tools/devdem60/web/"

Alias /web_qt/ "/6iserver/doc60/admin/quicktour/US/"

Oracle SOAP

1. Disable (comment out) the following SOAP entries from Apache Jserv configuration file, jserv.conf:

ApJServGroup group2 1 1 /Apache/Jserv/etc/jservSoap.properties

ApJServMount /soap/servlet ajpv12://localhost:8200/soap

ApJServMount /dms2 ajpv12://localhost:8200/soap

ApJServGroupMount /soap/servlet balance://group2/soap

2. Comment out the following “Alias” directive from httpd.conf file:

Alias /soapdocs/ "/soap/"

Oracle Servlet Engine (OSE)

1. Comment out the following “include” statement from oracle_apache.conf file:

include “/Apache/Apache/conf/mod__ose.conf"

Oracle9iAS Discoverer Services

1. Comment out the following “Alias” directive from the oracle_apache.conf file:

Alias /disco4ivfiles/ "Apache/Apache/htdocs/disco4iv/"

2. Comment out the following lines from the Apache JServ configuration file, jserv.conf:

ApJServGroupMount /Discoverer4i /viewer4i

ApJServGroupMount /discoverer4i balance://group1/viewer4i

3. Comment out the following lines from JServ configuration file, jserv.properties:

viewer4i.properties=/Apache/Jserv/etc/disco4iviewer.properties

wrapper.classpath=/Apache/Apache/htdocs/disco4iv/disco4res.jar

Oracle Portal Services

1. Comment out the following Oracle Portal aliases and directories from plsql.conf file:

Aias /help/ "/portal30/doc/"

Alias /images/ "/portal30/images/"

Directory "/portal30/images/" >

Directory "/portal30/doc/" >

2. Remove (or comment out) Oracle Portal DAD entries from the Oracle PL/SQL gateway configuration file, wdbsrv.app:

[DAD_portal30]

DAD_portal30_sso]

DAD_test]

DAD_sample]

3. Comment out the following “Alias” directive from oracle_apache.conf file:

Alias /portal30/java/ "/portal30/java/"

4. Comment out the following classpath entries from jserv.properties file (these directives may be collectively identified by the “# Oracle Portal” comment):

wrapper.classpath=/portal30/bibeans/jewt-opt-4_1_2.zip

wrapper.classpath=/portal30/bibeans/share-opt-1_1_7.zip

wrapper.classpath=/portal30/bibeans/utility.jar

wrapper.classpath=/portal30/bibeans/utilitygui.jar

wrapper.classpath=/portal30/bibeans/utilitypersist.jar

wrapper.classpath=/portal30/bibeans/utilityxml.jar

wrapper.classpath=/portal30/bibeans/swingall.jar

wrapper.classpath=/portal30/bibeans/graph.jar

wrapper.classpath=/portal30/bibeans/graphgui.jar

wrapper.classpath=/portal30/bibeans/LW_PfjBean.jar

wrapper.classpath=/portal30/bibeans/bivisbeans.jar

wrapper.classpath=/lib/http_client.jar

wrapper.classpath=/jlib/javax-ssl-1_2.jar

wrapper.classpath=/jlib/jssl-1_2.jar

wrapper.classpath=/lib/wwcache.jar

wrapper.classpath=/lib/xmlparserv2.jar

wrapper.env=DISPLAY=:0.0

wrapper.env=WV_GATEWAY_CFG=/Apache/modplsql/cfg/wdbsvr.app

Oracle PL/SQL

1. Modify prefix for PL/SQL gateway administration pages from “admin_” to (for example) “_pls_admin_” to obscure the default prefix, in the plsql.conf file. This is accomplished by setting the “adminPath” directive under [PLSQL_GATEWAY] entry, e.g.:

[PLSQL_GATEWAY]

adminPath = /_pls_admin_/

2. Enable Basic authentication for the PL/SQL gateway administration pages by creating a new DAD named “plsadmin”. This DAD will become an entry point to the PL/SQL gateway and will require user authentication against the backend database. The new DAD is created by adding the following DAD definition to the wdbsrv.app file:

[DAD_plsadmin]

connect_string = cg

password =

username =

default_page =

document_table =

document_path =

document_proc =

upload_as_long_raw =

upload_as_blob =

name_prefix =

always_describe =

after_proc =

before_proc =

reuse = Yes

connmax =

pathalias =

pathaliasproc =

enablesso = No

sncookiename =

stateful = STATELESS_RESET

custom_auth = PerPackage

response_array_size = 128

exclusion_list =

cgi_env_list =

error_style =

nls_lang =

3. Set the user name in the wdbsrv.app file to a valid Oracle user name. The system will prompt for a password for this user upon accessing the PL/SQL admin pages. This is done by setting the “administrators” directive under [PLSQL_GATEWAY] section, i.e.:

[PLSQL_GATEWAY]

administrators =

4. Further restricted access to the PL/SQL gateway administration pages to a range of IP addresses by creating the “Location” directives listed below and substituting appropriate values for network and netmask, in the plsql.conf file:

Order Deny,Allow

Deny from all

Allow from /

Order Deny,Allow

Deny from all

Allow from /

5. Restrict execution of the sys*, dbms_*, utl_*, owa_*, and htp* packages and procedures directly via HTTP server by adding them to the “exclusion_list” directive in wdbsrv.app file for all DAD’s that are involved in the application, such as [DAD_cybergrants]; also include this directive into the new DAD, [DAD_plsadmin]:

exclusion_list =sys.*,dbms_*,utl_*,owa_*,htp*

Oracle XSQL

1. Comment out the following lines from jserv.properties file:

# Oracle XSQL Servlet

wrapper.classpath=/lib/oraclexsql.jar

# XSQLConfig.xml File location

wrapper.classpath==/xdk/lib

Oracle XML

1. Comment out the following lines from the Oracle XML configuration file, xml.conf:

ApJServAction .xsql /servlets/oracle.xml.xsql.XSQLServlet

Alias /xsql/ "=/xdk/"

2. Comment out the following “include” directive from oracle_apache.conf file (note that this step can be performed instead of the previous step):

include "=/xdk/admin/xml.conf"

3. Comment the following lines from jserv.properties file:

# Oracle XML Parser V2 (with XSLT Engine)

wrapper.classpath==/lib/xmlparserv2.jar

# Oracle XML SQL Components for Java

wrapper.classpath==/rdbms/jlib/xsu12.jar

Oracle JSP (OJSP)

1. Comment out the following lines from OJSP configuration file, ojsp.conf:

Alias /jspdocs/ "=/jsp/doc/"

ApJServAction .jsp /servlets/oracle.jsp.JspServlet

ApJServAction .sqljsp /servlets/oracle.jsp.JspServlet

2. Comment out the following “include” directive from oracle_apache.conf file (note that this step can be performed instead of the previous):

include "=/Apache/jsp/conf/ojsp.conf"

Oracle Reports Services

1. Create the following “Location” directive to restrict rwcgi60 from executing with dangerous arguments, to an IP address range, in the httpd.conf file:

Order Deny,Allow

Deny from all

Allow from /

Revision history

|Name |Date |Description |

|MK |12/15/01 |Created first draft |

|MK |02/10/02 |Revised Section 3 and 4 to reflect new hardware architecture |

|MK |06/10/02 |Added Sections “OS Hardening Tasks” and “App. Hardening Tasks” (Sections 13 and 14) |

|MK |06/18/02 |Added Section “Change Control Management” (Section 11) |

|MK |06/20/02 |Added Section “Backup Policy and Procedure” (Section 12) |

|MK |09/05/02 |Modified Section 2: added “System Data Flow Diagram” |

|MK |09/10/02 |Modified Section 7: added “Network Topology Diagram” |

|MK |01/04/03 |Split document into Part 1 and Part 2 |

|MK |01/25/03 |Added “Monitoring of Services and Events” (Section 9) |

|MK |03/28/03 |Revised Sections 8, 9, 10, and 11 in response to security audit requirements |

|MK |06/15/03 |Revised Sections 13 and 14 to reflect new fixes |

|MK |10/10/03 |Added Section “Hosting Facility (NaviSite, Inc.)” |

| | |This section becomes Section 6. |

| | |Re-numbered sections 7 through 14 accordingly |

|MK |11/10/03 |Renamed Part II from “System Security” to “System Security Setup”; |

| | |Added Part III: “Appendices and Technical Notes”; |

| | |Renamed Sections 13 and 14 into “Appendix 1” and “Appendix 2”, respectively and |

| | |placed them into Part III |

|MK |05/02/04 |Revised Sections 4.1 through 4.4 |

|MK |12/08/04 |Revised Section 5 |

| | |Created Section 8 and renumbered the subsequent sections |

| | |Made miscellaneous changes throughout the document. |

|MK |05/02/05 |Revised Section 6 |

|WL |09/19/05 |Updated JRE version |

|MK |04/10/06 |Minor changes to section 13 |

|EAI |11/05/06 |Updated CG Branding |

-----------------------

B3

C2

mod_cgi

C1

Servlet Class

cgapp2

B2

A4

mod_plsql

A3

B1

mod_jserv

A2

A1

Oracle HTTP Server

Apache JServ

Application Server Layer

Grant makers

10.10.10.5

10.10.10.0 / 24

Aux-DMZ

CG-DMZ

Internal network

Cisco 2550

Cisco 2550

192.168.100.5

192.168.110 / 24

192.168.100 / 24

192.168.110.5

HTTP / HTTPS

E1

E2

Internet

E3

Cisco 515 UR

Cisco 515 UR

216.251.230.91

216.251.230.92

E0

E5

PL/SQL Gateway

mod_perl

mod_ssl

Oracle Net8

Reports Web CGI

C3

Static

Content

C4

Oracle Reports Server

Database Server Layer

SCSI

DAS

Oracle9i Database

Public network

216.251.248.16 / 27

Cisco 2900 XL

216.251.230.90 / 24

CyberGrants, Inc.

NaviSite, Inc.

VLAN Switch

216.251.230.4

Internet

T1

cgapp1

Internet

PPTP VPN 10.1.1.0 / 24

XO Communications, Inc.

cgdb2

cgaux

cgtc

Cisco 2900 XL

cgdb1

CyberGrants, Inc.

66.89.218.17

Router

66.89.218.161

Public network 66.89.218.160 / 27

100 Mbps switch

Virtual public IP addresses configured on firewall

Static NAT links to DMZ

66.89.218.175

Firewall

192.168.5.1

192.168.10.1

DMZ

192.168.5.0 / 24

Terminal

concentrators

Staging DB servers

Disaster Recovery

DB server

Mail gateway &

anti-SPAM

Lotus Domino

mail server

Staging HTTP/App

server

DR HTTP/App

server

Development

HTTP/App server

Development

DB server

NAS / SMB server:

- binaries repository

- misc. storage

- network backups

VSS server:

- code repository

- bug database

- misc. SQL tools

Print server &

MicroSoft DC

PBX server

User workstations

Internal network

192.168.10.0 / 24

100 Mbps switch

100 Mbps switch

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download