Network Security December 7 999

User Authentication: Options in Oracle Alison Webb

Introduction

I spent last summer doing a succession of Oracle audits, all in different environments. What struck me particularly was how many problems are posed for the manufacturer of a large database management system who wants to offer his clients the sort of network access that everyone expects these days, coupled with manageable access control.

These problems are increased by the (in my view natural and understandable) reluctance of existing clients to leap immediately to the latest release of the manufacturer’s software, and their refusal to use it in exactly the ways the designers had planned. The number of ways you can configure the user/database connection in Oracle are legion, and each of them draws on different features to simplify database man- agement and make life easy for the users, If you want security as well, then you really need to think through the access methods in some detail.

This article looks at these methods - there are two or three basic models, but the complexity comes when users mix up old methods with new, as they bolt bits on to existing systems.

The three elements

It’s not possible to simplify without losing some of the useful detail,

but I’ve focused on what seem to me to be the essential points,

At its simplest, an Oracle system consists of three things.

The first element is the application data, impenetrably structured, and looking to the operating system on which it sits like one large file.

The second element is the database management system, including the access routines and all the screens, forms and programs that together comprise the complete application, These look to the operating system like a lot of files, but they work together as one system, often known as an ‘instance’. In practice, these elements of the working software may be spread among two or more processors, but their internal communication does not necessarily affect user authentication, so I haven’t elaborated on this,

The third element is the user. Users always get to the data via the instance. The user needs an identity recorded in the instance (the Oracle ID), which dictates the choices open to him or her when working on the system.

What are we connecting to what?

As far as the structure of a system is concerned, we’re interested in who can get to the data, so I’ve tried to define what access routes to the data there are.

Type 7. All elements on one host

In the simplest, and oldest, configurations, the data, the instance and the user are on the same operating system. The user connects using an old-style terminal. To access the application, he or she logs on to the operating system, then connects to the instance. This involves some sort of authentication check to assign an Oracle ID to the operating system user. When users make enquiries or update the data, the instance collects the information they want from the database and returns it to them, or.makes the requested changes.

Type 2. Separate database and database management system

There’s no reason why the data should not be on a host separate from the instance that manages it. Equally, one instance may need to retrieve or update data on an entirely separate database, via a second instance. The connections between the parties that need to communicate are managed by the networking services that come with Oracle: SQL*Net, or Net8 in Oracle8. The necessary definitions of hosts to be contacted and the connections between them are set up by the database administrators, and stored in special configuration files. The user sees no difference (except possibly in response time).

Type 3. User on a different host from the instance

In a sense, anyone who accesses his or her Oracle system from a PC rather than a directly connected ‘green screen’ is on a separate host - and that’s nearly

10 0 1999 Elsevier Science Ltd

December 7 999 Network Security

everyone these days. However, people who use terminal emulation software to start a session, and there are still quite a few of them, are choosing to turn their PC back into a terminal for their Oracle session, If they do this, their access method corresponds most closely to Type 1.

If they are genuinely networked, then they have two options:

They may login across the network to the operating system of the host for the Oracle instance and from there access the application. From the Oracle standpoint, this turns them into Type 1 users again, because the instance will see them coming from its host’s operating system.

They may run Oracle client software on their local machines which lets them communicate directly with the instance, rather like the database/instance connection in Type 2. In this case, they have nothing to do with the host operating system under which the instance runs, apart from using its communication services to reach the instance. This means that although to address their messages properly they need to know the host network address, they never need a login to the host operating system. This is probably the most common type of connection at the moment.

Type 4. User accesses the instance via the Web

Although it’s still in its infancy, this access method has obvious advantages because it opens up the application to travelling users, and those who are on the corporate network but with the sort of physical link that isn’t wide enough for standard client/server applications. The user starts from an ordinary Web browser, like

Internet Explorer, but doesn’t contact the database instance directly. instead, he or she sets up a Web session with an extra Oracle server (the Oracle Applications Server) which sits between the user and the normal instance. This extra server manages the message translation between the user’s Web session (for which it is the server) and the standard Oracle session used to access the data (for which the OAS is the client). This means that the fundamentals of how Oracle works do not change: the OAS is an automated interpreter slotted in, which converts the messages from the user (Web format) and the instance (Oracle format) as they pass through it to the other party.

These messages include the normal Oracle user authen- tication. As with Type 2 users, there is no operating system involved, apart from the transparent running of the network services the messages need to communicate.

There is one additional aspect to Web access, which arises because it’s likely to be used outside a private network. Web- format http packets are not encrypted, so your ID and password are vulnerable to sniffing if you’re sending them across the Internet. So is your data, although normally it takes more work to derive meaning from intercepted data packets than from the neatly bundled security information. If this is a concern at your site, it is something that needs to be considered separately. Oracle security cannot really help you. Some sites, for instance, use the user authentication features of their firewall to get round this problem: firewalls can set up encrypted sessions which provide a sort of tamper-proof

coating for the naked http messages between the user and the OAS.

Although the configurations differ, as far as user connections go, there are just two types, Type 1 users (entry via the host operating system) must at some point login to the operating system and so have some sort of operating system ID; Type 2 users bypass this step. Both must acquire an Oracle ID when they first contact the instance. Normally, this acquisition is via Oracle’s own authentication check.

so far, this is pretty straightforward. The gothic elements arise chiefly, I think, because most people’s applications aren’t brand-new implementations of exactly what Oracle supply. Just as my Victorian house has original cornices, central heating and plastic windows, so sites retain features of old applications that they like, but enhance them with modern structures,some of which fit well and some of which do not.

There are also one or two Oracle features equivalent to a Victorian coal-hole - useful at the time, but rather a security hazard these days.

Coal-hole 1: Passthrough

Type 7 users

As we’ve seen, Type 1 users login first to the operating system which runs the Oracle instance, so they have two authentication checks. In the old days, when everyone was a Type 1 user, they all had to remember two IDS and passwords - one for the host operating system and one for Oracle. If all they did on the host was access Oracle, this was

0 1999 Elsevier Science Ltd 11

Network Security December 7 999

unnecessarily complicated, so Oracle devised a way of allowing the application to accept authentication by the operating system under certain, controllable, conditions. This ‘OPS$ passthrough’ became widely used.

In its simplest manifestation, the database administrator (dba) makes sure that each user has an Oracle ID, which is in the same as that for his or her operating system. There can be an optional prefix in the Oracle list, which by default is OPSS. When the user starts an Oracle session, Oracle picks up his or her operating system ID, and if it corresponds to a name in its own list, assumes that the necessary authentication has already been done. The user’s access rights are those associated with the OPSSname.

In practice, bearing in mind that Unix is a widely used Oracle platform, there can be some elaborations on the theme. Suppose you are a Type 3 user, who first logs on locally (first authentication check) and then starts a remote session on the Oracle host (second authen- tication check) before accessing the application (third authentication check). OPS$ reduces your authentication checks from 3 to 2. Why not use the Unix passthrough features, trusted host or trusted user, to make the first check the only one? The downside is that the Oracle host now has to rely on the systems administrator on the user’s local machine, but if the network is small and private, as many used to be, this may be an acceptable risk.

Thus within the Oracle user community, there are people who are never authenticated by Oracle itself: they are checked by either the operating system of the Oracle host or by the

12

operating system of their own local machine.

Accounts and passthrough

Again, I suspect, for historical reasons, Oracle distinguishes two types of passthrough accounts.

The first allows both Type 1 and Type 2 users to login. In the Oracle database table the OPSS account is stored with a password. If the user goes for a Type 1 login, this password is not checked: Oracle relies on the operating system. If, in different circumstances, the user opts for Type 2, then the Oracle authentication routine will come into play, and the Oracle password will be checked.

The second account only allows a Type 1 login. The password entry is locked, as Unix accounts can be locked,so that the user cannot be authenticated by Oracle. These types of accounts are known as EXTERNAL accounts, because the user identity is provided externally, that is, by the host operating system.

Unfortunately, most people want to use the Type 2 sign-on these days. They want to sit at a remote client, and use a nice Windows- based GUI to talk directly with the Oracle system, not set up an old-fashioned telnet session with the Unix host first, and then see old-fashioned character-based screens.

To make this possible, yet still only have one authentication check, Oracle lets you set a parameter, remote os_authent, in the system initialization file, so that your local operating system can authenticate you instead of the Oracle host.

However, there is no guarantee that the remote authentication will be carried out by relatively

well-secured operating systems like Unix or NT. Windows95 is also an operating system. Win95 users who have Oracle client software installed can set their own ID at will, either in the Oracle.ini file (16-bit client) or using Control Panel / Password for the 32-bit client - hardly a challenging assignment for the average hacker. He or she just needs to choose an ID that is likely to give a high level of access to Oracle, and passthrough will let him or her in, bypassing authentication.

In practice, then, remote OPS$ logins can be an enormous security hole. You can limit the scope of remote_os_authent in the SQL*Net configuration settings. The section on The Oracle Audit gives details.

Coal-hole 2: Remote administration

7. Automatic access

The second coal-hole concerns remote SQL*Net access for Oracle administrators.

The dba needs from time to time a high level of Oracle access to connect to the database internals. Such access is not defined in tables: it is implicit in the ID name itself, which is standard for all systems. It is not authenticated independently: Oracle assumes that if you are logged on as the administrator, then you have the access right. This means that if I have a small local Oracle system which I administer, I can set the SQL*Net variables to point at a remote database, perhaps more important than mine, and then connect to its internals and do what I will. My target will not know I am not its own local administrator.

0 1999 Elsevier Science Ltd

December 7 999 Net work Security

Again, this can be prevented by the way in which SQL*Net is configured. Blocking remote dba connection still allows an ordinary SQL*Net connection (with authentication if the passthroughs are switched off), but forever stops the dba using the powerful commands to manage the database.

Allowing administrator access

This said, blocking access may cause problems for a lone Oracle administrator responsible for several machines.

You can re-install this right, in a more controlled way, by using the ORAPWD utility to set up a special Oracle password file (encrypted) which holds the password for database management. The remote dba is authenticated against this password, and then allowed access, without needing an operating system ID on the Oracle host. I find this rather Heath Robinson, but I suppose at least it does the job.

There may be another practical problem in Oracle administration, if the host operating system administrator and the Oracle administrator are not the same person, because the operating system administrator will need access as Oracle dba administrator from time to time. If he or she needs to find out the dba password from the Oracle administrator, it can waste time and be inconvenient. Many sites fix this, at some cost to security, by setting up a command file with restricted access which simply lists the Oracle dba name and the current password. To start an Oracle session, the operating system administrator refers to the command, which provides the information. If the Oracle dba changes his or her password, he or she simply adjusts the file. The

0 1999 Elsevier Science Ltd

control is very restricted Unix permissions on the command file, particularly as, unlike the ORAPWD file, its contents are in a readable form.

The Oracle audit

So much for the theory - what practical issues are there if you are doing an audit of Oracle access control?

You cannot avoid, I think, finding out which access paths are in use for your application, The chances are that you’ll find most or all of them. Even if the majority use the standard client/server route I’ve called Type 2, there will still be the operating system dba, for which Type 1 access will be more convenient, and perhaps now some remote users who come in

via the Web. Once you are clear about the routes, you can decide what the risks are, and what checks you need to do.

On the practical side, I’ve listed below where to find some of the configuration files and other information I’ve mentioned:

1. The Oracle user list

The list of users and their characteristics is held within the Oracle application data. You can retrieve the list by using an ID with the right level of privilege to run an SQL query against the database table that holds it.

Note that the password is held in an encrypted format - it’s not just that these users are particularly conscientious about

A sample query and response is:

SQL> run

1* select username, password from dba_users

USERNAME PASSWORD

SYS 8CC 1 OCBOB22332F3

SYSTEM C8FFABBOBCOFFE8D

SCOTT F894844C34402867

OPS$BOB5 B43DEF98DAC47A31

OPS$BEN6 715F84556254A8A3

ANNE5 61 E39C48EB4CECOB

OPS$TIM 5332EDCC856D31 D6

OPS$OPER EXTERNAL

OPS$FIN 811 BE1945262BD32

VICTOR 40A73BF45E68C170

OPSSBIL6 586691385BD40AOA

13

Network Security December 7 999

choosing an unguessable password.

The other thing to notice is the user with the password entry ‘EXTERNAL’. The disabling of direct login works in the same way as a Unix locked account: the user cannot enter a password that when encrypted, matches the string in the table.

2. The system initialization files

These are text files and not impossibly long, so if you get copies of them, you can audit them using your word processor.

The primary file is called init{databaseid},ora: so, for example, if your application is called ‘GL’, then the primary file will be ‘initGL.ora’.

The standard name for the secondary initialization file, which is really just an extension of init.ora, is ‘config.ora’. Look at the primary file as well, though: it can point to additional configuration files using the parameter ‘IFILE= {filename}‘, so if there are any extras, get copies of these as well.

The parameters to check that I’ve mentioned in this article are:

(1) Those connected with the OPS$ passthrough from the oracle host operating system. The key one is ‘os_authent prefix’, and it shows the prefix which is used to identify accounts which rely on the operating system rather than Oracle authentication. If my operating system account is ‘ALISON’ and my Oracle account is ‘OPSSALISON’, then I won’t be authenticated. You can choose your own prefix, including a null string I’,

(2) Those connected with the passthrough from a remote operating system (OPSS) or

from a remote Oracle system. The essential parameter is ‘remote OS authent’ which must be set to ‘true’ to allow remote passthrough.

The other setting you need for remote passthrough is not in the Oracle configuration file at all, but in the host operating system, which must have a defined user named daemon. Daemon acts as a sort of default ID for EXTERNAL users who don’t have one of their own. (This isn’t really a security issue - except that to stop outsiders passing through, you need to be careful there is no corresponding Oracle ops$daemon account.)

Don’t forget that if remote_os_authent is set to true with no other controls, users who administer the remote Oracle system will be able to exercise powerful privileges on the Oracle server without needing a password. Normally, the amount of access allowed by remote os_authent is restricted by setiings in the SQL*Net configuration file, listener.ora.

3. The SQl*Net configuration file LISTENER. ORA

Settings in this file determine:

(1) If remote operating system users can escape local authentication.

The options are:

l ops_dollar_login_aIlowed; ops_dollar_login_denied.

l ops_dollar_login_denied is default.

the

(2)lf a remote dba can gain privileged access to the system a

l The options are remote_

dba_ops_allowed; remote_ dba_ops_denied. ‘Denied’ is the default, and when set, users with dba privileges cannot make operating system authorized logins over the network. They can, however, do ordinary work.

4. ORAPWD

The file holding the settings is not browsable, but its name is standard: orapw{databaseid}. You can check the operating system settings on the file, to make sure it cannot be accessed or deleted.

To check if the file is in use, look in init.ora.

The setting remote_login_ passwordfile shows you if access is:

l NONE -the file is not in use.

l EXCLUSIVE - the file is used only for one Oracle system.

l SHARED -the file is used only for several Oracle systems on the host.

Conclusion

In practice, as always, when you start work, you’ll find other ways of managing access control, employed to get the best match between what the users want, what the support staff want and what Oracle provide. This is what makes an auditor’s job interesting. But it’s all too easy to get bogged down in complexity, so you end up knowing that although the mass of users are quite well-controlled, you have some lurking doubts about groups within the community. I hope this article helps you resolve them.

14 0 1999 Elsevier Science Ltd