Firewall Security

‰ Assigning owners and groups to points

‰ Setting the access permissions on each point, both for attributes and for data

‰ Assigning owners and groups to modules. Module level security is only accessible with the System Management Tools, which you can obtain from the OSIsoft support Web site.

‰ Maintaining the Trust Database for automated logins

6.4.1 Running applications on the system console

The piadmin user account has full privileges on all PI objects. Running any application from the PI home console grants that application the piadmin status.

In high security environments, piconfig and pisetpass utilities can be forced to perform a login. This is done with the timeout parameter CheckUtilityLogin set to 1. The user is prompted to enter a PI username and password before being allowed to proceed when this feature is enabled.

6.4.2 Running applications remotely

Most PI applications can run remotely and have the -remote set of flags for that purpose. Login as piadmin grants the user full access to all PI objects.

Caution: Some operations are modifying local files and cannot be done remotely.

Specifically this applies to modifications of the timeout and firewall tables.

6.5 Firewall Security

The first level of PI access security is a firewall maintained by the pinetmgr subsystem. The firewall allows the PI System Manager to control access to the PI Data Archive at the IP address level.

The pinetmgr process manages all connections to PI, including subsystem connections and TCP/IP applications. pinetmgr uses the PI Firewall Database to screen access based on the IP address.

The database is a list of IP addresses and/or IP address masks. Each entry is associated with the ALLOW or DISALLOW keyword, and this specifies whether or not pinetmgr completes the connection request.

piconfig is used to maintain the PI Firewall Database.

Note: Requests from the local host (that is, the same computer on which pinetmgr

6.5.1 Firewall Database

The Firewall Database is a table with two fields. The first field is an IP address, IP address mask, or host name. The second field defines whether access for that address, mask, or host name is allowed.

IP address mask syntax consists of a portion of an IP address and asterisks. An asterisk in an IP address field matches any number. Here are two examples:

192.168.149.55 192.168.177.*

New connection host names and IP addresses are checked against the Firewall Database in the following order.

1. If the connection originates from the local host, the connection is always accepted. 2. Firewall Database is searched for an exact match of IP address entry or host name

entry. If an entry is found the search stops and the connection is treated according to that entry.

3. Firewall Database is searched for a wildcard match, for example, the connecting address of 192.168.168.22 matches a Hostmask of 192.168.*.*. A matching Disallow has precedence over an Allow.

Here is an example:

Host/Mask Value 192.168.168.* ALLOW 192.168.168.67 DISALLOW

Only hosts within the 192.168.168.0 subnet are allowed connections. 192.168.168.67 is not allowed to connect; even though it matches the first host mask.

Modifying the Firewall Database

Piconfig is used to modify the Firewall Database. PI will recognize modifications to the Firewall Database within 15 minutes, or upon restarting PI, whichever comes first. The Firewall Database can only be modified from a local piconfig session.

List Attributes and Entries Example

This piconfig example lists all entries:

Piconfig> @table pi_gen,pifirewall Piconfig> @ostructure hostmask,value Piconfig> @select hostmask="*" Piconfig> @endsection

*.*.*.* ALLOW

6.5 - Firewall Security

Limit Connections Example

The next example modifies the Firewall Database to only allow connections from the subnet 123.45.678.0.

Piconfig> @table pi_gen,pifirewall Piconfig> @mode create,t

Piconfig> @istructure hostmask,value Piconfig> 192.168.168.*, ALLOW

Disallow Specific Host Example

Host names may also be used to allow or disallow specific host machines. The host name with domain name must be entered. For example to prevent connections from host “bobcat” on domain “somewhere.com” the following must be entered:

Piconfig> @table pi_gen,pifirewall Piconfig> @mode create

Piconfig> @istructure hostmask,value Piconfig> bobcat.somewhere.com,DISALLOW

Rename an Entry Example

The attribute NEWhostmask is used to rename an entry in the Firewall Database. Here is an example:

Piconfig> @table pi_gen,pifirewall Piconfig> @mode list

Piconfig> @ostructure hostmask,value Piconfig> @select hostmask=*

192.168.168.*,ALLOW

bobcat.somewhere.com,DISALLOW Piconfig> @mode edit

Piconfig> @istructure hostmask,NEWhostmask

Piconfig> bobcat.somewhere.com, tomcat.somewhere.com

Connection attempts from tomcat will be disallowed. For example if apisnap run from that host, it would behave as follows:

e:\pi\adm>apisnap tamarind:5450 PI API version 1.2.3.4

Attempting connection to tamarind:5450 Error 2, connecting to tamarind:5450

The pipc.log on host tomcat would have the following entry:

11-Dec-02 16:19:03

D:\piapi\piapi32\apicomm.c> recv: Error: 10054, Unknown error

A look at the PI Server message log, would have a message indicating the connection was not allowed:

0 pinetmgr 11-Dec-02 16:29:37

>> PInet Refused TCP/IP connection, hostname: tomcat.somewhere.com, 192.168.168.129

Modify the Hostmask *.*.*.* Example

If you wish to modify the hostmask *.*.*.*, you must use the following example. Do not use a wild card selection.

Piconfig> @table pi_gen,pifirewall Piconfig> @mode edit

Piconfig> @istructure hostmask,value Piconfig> "*.*.*.*",DISALLOW

To delete the global mask entry use the following:

Piconfig> @mode delete

Piconfig> @istructure hostmask Piconfig> "*.*.*.*"

Note: To disallow all network connection, make sure you have an entry with

“*.*.*.*”,Disallow, and all other entries are either deleted or set to Disallow.

Note: PIconfig loads the PIfirewall table in memory; all edits are to the in memory

image. Changes are written to disk when the new table is loaded or piconfig is exited.

6.6 Database Security

Database level security controls access to the various PI server databases such as PI Point and PI Module Database. PI Server installation sets the owners of these tables to piadmin. Therefore, only the piadmin account can initially change the settings. After installation, system administrators can alter the security settings to grant other users modification and access privileges.

Following a brief description of all the security tokens in the DBsecurity table:

6.6.1 PIDBSEC

Only piadmin can change this token, which allows other users to view/change the DBsecurity table itself. The PIDBSEC token also controls programmatic access to the timeout table.

Other users or groups may still be assigned modify privileges in the DBsecurity table but any changes to this token must be done by piadmin.

6.6.2 PIARCADMIN

Controls access to archive management functions: Archive creation and registration. Archive shifts. To create new archives or change their attributes the user needs write access to this token.

6.6 - Database Security

6.6.3 PIARCDATA

Controls access to archive data that is not point specific. Access to archive events is controlled by individual point security. Such general data includes the list of archives (piartool -al) archive counters, archive activity grid and cache information (piartool -as, piartool -aag, etc.)

PIartool -aw is also controlled by this token although it does access actual archive events.

6.6.4 PIBatch

Controls the PIbatch database.

6.6.5 PICampaign

Controls the PIcampaign database.

6.6.6 PIDS

Controls the Digital States table. To create or edit sets or states the user needs write access to this token.

6.6.7 PIHeadingSets

Controls the PIheadingsets database.

6.6.8 PIModules

Controls the creation and modifications of modules in the MDB. Note that each module has its individual ownership and security specifications. This token controls access to the database as a whole.

6.6.9 PIPOINT

Control the Point database. As with the MDB, there is individual point security specifications. This token also controls access to the Point Source table.

6.6.10 PITransferRecords

Controls the creation and modification of transfer records in the MDB.

6.6.11 PIUSER

This token controls several tables: PIusers, PIgroups, PIContext and PItrust.

6.6.12 Individual Subsystem Tokens

Every PI subsystem has now a security token that controls access to that subsystem thread table and auditing. Initially, this token is owned by piadmin and is not visible in the Dbsecurity table.

This setting can be modified by adding the appropriate token to the table.