Security

arupnanda's picture

Collaborate 2012 Sessions and Select Article

Thank you all who came to my sessions at #IOUG Collaborate 2012 #C12LV on April 22-24 in Las Vegas. I had four full sessions, two panels and one bootcamp. Quite a busy schedule, as you can see. I also worked on some urgent performance issues at work during the week.

You can download the the slides and scripts here. They are available from the IOUG site but I thought I would put them for download here as well.

martin.bach's picture

The art of getting security right-an observation

A number of high-profile hacks recently (and not so recent) has caught my attention. Well I thought, not such a big problem-I don’t have a PS3 and hence don’t have an account that can be hacked. I was still intrigued that the hackers managed to get hold of the passwords. I may be wrong here, as I haven’t followed the developments not close enough (as I wasn’t affected), but the question I asked myself: how can they be obtained? Surely Sony must have used some sort of encryption for passwords. It’s so far-fetched that anybody stores passwords in clear text somewhere!

Oh well then, Sony has been targeted a number of times and time and time again the security was breached. They only consolation is that the intruders have made it very public when they were successful, otherwise we’d have never learned about the problems Sony has with security.

Now other sites were hacked as well, and somehow I felt the impacts coming closer, such as kernel.org and others.

arupnanda's picture

Difference between Select Any Dictionary and Select_Catalog_Role

When you want to give a user the privilege to select from data dictionary and dynamic performance views such as V$DATAFILE, you have two options:

grant select any dictionary to ;
grant select_catalog_role to ;

Did you ever wonder why there are two options for accomplishing the same objective? Is one of them redundant? Won't it make sense for Oracle to have just one privilege? And, most important, do these two privileges produce the same result?

oraclebase's picture

Security: It’s always the silly things that get you…

I had to laugh when I read this story about Amazon Web Services. It’s posted with an attention grabbing title that implies this is an Amazon problem, but it is squarely down to user error/oversight.

Luckily I’ve not fallen into this trap yet, but I have done equally silly things in the past. That reminds me, I must go to a Pete Finnigan session next time we are at the same conference… :)

Cheers

Tim…




marco's picture

The Oracle XMLDB “anonymous” user account

Trying here to be as correct as possible, as far as I understand it currently.

ANONYMOUS is an Oracle user account specifically designed for HTTP access. It has only one system privilege, that is “create session” and the account is locked by default. If it is unlocked, it only is used for HTTP access via the XDB Protocol Server, aka PL/SQL Gateway, and can access objects in the XDB Repository that are protected by an ACL (Access Control Lists) mentioning this “principal”.

By default there is no ACL file that grants any privilege to this “user” ANONYMOUS. When APEX is installed then there will be a /sys/acls/ro_anonymous_acl.xml file that grants read access to the /images/ or /i/ directory (depending on the APEX version). If you lock ANONYMOUS or remove the ACL defined privileges then APEX can not show/access those files in that XDB Repository folder (/images, /i) if you would need to access these files. For example when using the APEX listener setup the application images and help doc images are stored locally on the server and not in the database, so in principal there is no need to access those image(s) directories in the database.

Example of an ACL which can used by XDB which grants read properties and read content rights to all objects which are protected by this ACL

#66cc66;"><acl description#66cc66;">=#ff0000;">"File /sys/acl/my_acl.xml"
     xmlns#66cc66;">=#ff0000;">"http://xmlns.oracle.com/xdb/acl.xsd"
     xmlns:dav#66cc66;">=#ff0000;">"DAV:"
     xmlns:xsi#66cc66;">=#ff0000;">"http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation#66cc66;">=#ff0000;">"http://xmlns.oracle.com/xdb/acl.xsd
                         http://xmlns.oracle.com/xdb/acl.xsd"#66cc66;">>
  #66cc66;"><ace#66cc66;">>
    #66cc66;"><principal#66cc66;">>ANONYMOUS#66cc66;">principal#66cc66;">>
    #66cc66;"><grant#66cc66;">>true#66cc66;">grant#66cc66;">>
    #66cc66;"><privilege#66cc66;">>
      #66cc66;"><read #66cc66;">-properties#66cc66;">/>
      #66cc66;"><read #66cc66;">-contents#66cc66;">/>
      #66cc66;"><resolve #66cc66;">/>
    #66cc66;">privilege#66cc66;">>
  #66cc66;">ace#66cc66;">>
#66cc66;">acl#66cc66;">>

By default when a resource (a file or folder) is created by a process it will get the privileges defined in the bootstrap ACL (which is protected by itself). So no privileges will be granted to this ANONYMOUS account by default. And even when unlocked, this user only opens up, by default, to hierarchy enabled, XDB Repository related objects. Mind the mentioning “by default”; Its is possible to opening up and overrule default security ruling in place when you alter the content of ACL defaults (which is, could be considered, a security breach). For example you could alter the contents of the bootstrap_acl.xml file in such a way, if your have maliceious intentions from within the database, but you would need very powerful database account access to start with anyway, to make this happen.

Example of the default content of the bootstrap_acl.xml file:

SQL#66cc66;">> #993333; font-weight: bold;">SELECT xdburitype#66cc66;">(#ff0000;">'/sys/acls/bootstrap_acl.xml'#66cc66;">)#66cc66;">.getCLOB#66cc66;">(#66cc66;">) #993333; font-weight: bold;">FROM dual;
 
#66cc66;"><acl description#66cc66;">=#ff0000;">"Protected:Readable by PUBLIC and all privileges to OWNER" 
     xmlns#66cc66;">=#ff0000;">"http://xmlns.oracle.com/xdb/acl.xsd" 
     xmlns:dav#66cc66;">=#ff0000;">"DAV:" 
     xmlns:xsi#66cc66;">=#ff0000;">"http://www.w3.org/2001/XMLSchema-instance" 
     xsi:schemaLocation#66cc66;">=#ff0000;">"http://xmlns.oracle.com/xdb/acl.xsd 
          http://xmlns.oracle.com/xdb/acl.xsd"#66cc66;">>
  #66cc66;"><ace#66cc66;">>
    #66cc66;"><principal#66cc66;">>dav:owner#66cc66;">principal#66cc66;">>
    #66cc66;"><grant#66cc66;">>true#66cc66;">grant#66cc66;">>
    #66cc66;"><privilege#66cc66;">>
      #66cc66;"><all #66cc66;">/>
    #66cc66;">privilege#66cc66;">>
  #66cc66;">ace#66cc66;">>
  #66cc66;"><ace#66cc66;">>
    #66cc66;"><principal#66cc66;">>XDBADMIN#66cc66;">principal#66cc66;">>
    #66cc66;"><grant#66cc66;">>true#66cc66;">grant#66cc66;">>
    #66cc66;"><privilege#66cc66;">>
      #66cc66;"><all #66cc66;">/>
    #66cc66;">privilege#66cc66;">>
  #66cc66;">ace#66cc66;">>
  #66cc66;"><ace#66cc66;">>
    #66cc66;"><principal#66cc66;">>PUBLIC#66cc66;">principal#66cc66;">>
    #66cc66;"><grant#66cc66;">>true#66cc66;">grant#66cc66;">>
    #66cc66;"><privilege#66cc66;">>
      #66cc66;"><read #66cc66;">-properties#66cc66;">/>
      #66cc66;"><read #66cc66;">-contents#66cc66;">/>
      #66cc66;"><read #66cc66;">-acl#66cc66;">/>
      #66cc66;"><resolve #66cc66;">/>
    #66cc66;">privilege#66cc66;">>
  #66cc66;">ace#66cc66;">>
#66cc66;">acl#66cc66;">>

Be aware that, although the PUBLIC ACE (Access Control Entries) entry sounds dangerous, this only means that from within the database DIRECT access to the objects via database accounts are possible. This is not possible via HTTP (by default). An example to this effect would be that for the APEX /images directory, which is protected only for read only access of the principal ANONYMOUS, this means that PL/SQL packages (owned/executed by users from WITHIN the database) etc, will not have access to these image files.

The “service” provided via the XDB Protocol Server and its access rules are defined in the xdbconfig.xml configuration file. The services defined there (for example APEX’s entries via PL/SQL, that is, via the PL/SQL gateway) in this xdbconfig.xml file links up to the to be used “principal” (ANONYMOUS in the case of APEX) security access owner, role, trusted user or LDAP definition, for that specific service.

Normally an anonymous user is a user whose credentials have not been validated (hence unauthenticated) that is permitted access to only unprotected resources, but by default all created objects in the XDB repository will be protected by the default bootstrap ACL and in normal cases a ACL with a defined ANONYMOUS principal is not created, does not exist in the database. Even if, you would still need entries in the xdbconfig.xml file that link the (unlocked) ANONYMOUS account with a defined service that grants you access or an entry point to the database.

The underlying by Oracle implemented security mechanism is the same as for the database and also it used the advanced security feature VPD. Due to the fact that Oracle itself makes use of this, a extra license is not needed for this advanced security feature, as long as you don’t use it yourself. Oracle XMLDB in itself is a “no cost option” that comes along when you buy the licenses needed for your database software.

This is a backup copy of a XMLDB OTN Forum Thread.

oraclebase's picture

Barclaycard Security: So boring it works…

I’ve just bought something over the net using my Barclaycard. As usual, the checkout screen bounces me to a Barclaycard verification screen. As usual it asks me for several letters from my password. As usual my password doesn’t work. As usual I reset the password. Not as usual, the screen then asks me for the 9th letter of my password when I only set an 8 character password. Phone call later my password is reset again. I complete my order. I have to rest my password, but can’t use the one I set previously as it “has been used to recently”.

If I was a thief I really couldn’t be arsed to go through this when I could just mug a granny in the street. I see now how Barclaycard security works. It bores people out of commiting credit card fraud… Sigh…

Cheers

Tim…




oraclebase's picture

Do virtual keyboards promote weak passwords?

I’m quite big on password complexity. I like to use mixed case, numbers and special characters in my passwords.

Since having the iPad (and now the Android phone) I find it a real bind typing in strong passwords. The mixed case isn’t so bad, but I do have more login mistakes with the virtual keyboard. What really bugs me is having to switch keyboards two or three times to get all the special characters and numbers in. Every time I have to type a password on a mobile device I feel a certain tension…

My recent experience has left me thinking how nice it would be to have a weak password, preferably lower case letters only. So my next thought was, do virtual keyboards promote weak passwords?

Of course, I don’t expect anyone to comment and admit they have switched back to weak passwords, but it would be nice to know if anyone else feels my pain… :)

Cheers

Tim…

Niall Litchfield's picture

Oracle.com passwords

Just a quick note for anyone who has missed the Oracle Security alerts email. If you downloaded either Enterprise Manager 11g or Oracle Database 11.2.0.2 before November 17th last year then you downloaded a version of OUI that sent unencrypted passwords for your oracle.com SSO account to Oracle over the intertubes. Not Good. Oracle have [...]

arupnanda's picture

Build a Simple Firewall for Databases Using SQL Net

This article was initially published in 2003 in DBAZine.com, which has since been folded.

So, you want to set up a secured database infrastructure?

You are not alone. With the proliferation of threats from all sources — identity thefts to corporate espionage cases — and with increased legislative pressures designed to protect and serve consumer privacy, security has a taken on a new meaning and purpose. Part of the security infrastructure of an organization falls right into your lap as a DBA, since it’s your responsibility to secure the database servers from malicious entities and curious insiders.

What are your options? Firewalls are first to come to mind. Using a firewall to protect a server, and not just a database server, is not a new concept and has been around for a while. However, a firewall may be overkill in some cases. Even if a firewall is desirable, it may still have to be configured and deployed properly. The complexity in administering a firewall, not to mention the cost to acquire one, may be prohibitive. If the threat level can be reduced by proper positioning of existing firewalls, the functionality of additional ones can be created by a tool available free with Oracle Net, Node Validation. In this article, you will learn how to build a rudimentary, but effective, firewall-like setup with just Oracle Net, and nothing else.

Background

Let’s see a typical setup. Acme, Inc. has several departments — two of which are Payroll and Benefits. Each department’s database resides on a separate server. Similarly, each department’s applications run on separate servers. There are several application servers and database servers for each department. To protect the servers from unauthorized access, each database server is placed behind a firewall with ports open to communicate SQL*Net traffic only. This can be depicted in figure 1 as follows:


Figure 1: Protecting departmental database and application servers using multiple firewalls.

This scheme works. But notice how many firewalls are required and the complexity that having this number adds to the administration process. What can we do to simplify the setup? How about removing all the firewalls and having one master firewall around the servers, as in Figure 2?

Figure 2: One master firewall around all the servers.

This method protects the servers from outside attacks; however, it still leaves inside doors open. For instance, the application server PAYROLL1 can easily connect to the database server of the Benefits Department BENEFITDB1, which is certainly inappropriate. In some organizations, there could be legal requirements to prevent this type of access.

Rather than creating a maze of firewalls as in the case we noted previously, we can take advantage of the SQL*Net Node Validation to create our own firewall. We will do this using only Oracle Net, which is already installed as a part of the database install. The rest of this article will explain in detail how to accomplish this.

Objective

Our objective is to design a setup as shown in figure 3. In this network, the application servers benefits1 and benefits2 access the database on server benefitsdb1. Similarly, application servers payroll1 and payroll2 access the database on server payrolldb1. Clients should be given free access to the intended machines. Client machines shouldn’t be allowed to access the database on other departments (e.g., benefits1 and benefits2 shouldn’t be able to access the database on payrolldb1). Likewise, application servers payroll1 and payroll2 should not be allowed to access benefitsdb1.


Figure 3: One master firewall and restricting access from non-departmental clients.

Note the key difference in requirements here — we are not interested in disallowing any type of access from client machines to servers of another department. Rather, it’s enough to disable access at the Oracle level only. This type of restriction is enforced by the listener. A listener can check the IP address of the client machine and, based on certain rules, decide to allow or deny the request. This can be enabled by a facility called Valid Node Checking, available as a part of Oracle Net installation. Let’s see how this can be done.

To set up valid node checking, simply place a set of lines on a specific file on the server. In our example, the following lines are placed in the parameter file on the server payrolldb1, allowing access to servers payroll1 and payroll2.

tcp.validnode_checking = yes

tcp.invited_nodes = (payroll1, payroll2)

Where this parameter file is located depends on the Oracle version. In Oracle 8i, it’s a file named protocol.ora; in Oracle 9i, it’s called sqlnet.ora. Both these files are located in the directory specified by the environmental variable TNS_ADMIN, which defaults to $ORACLE_HOME/network/admin in UNIX or %ORACLE_HOME%\network\admin in Windows.

These parameters are self-explanatory. The first line, tcp.validnode_checking = yes, specifies that the nodes are to be validated before accepting the connection.

The second line specifies that only the clients payroll1 and payroll2 are allowed to connect to the listener. The clients are indicated by either IP address (e.g., 192.168.1.1) or the node name as shown above. The list of node names is specified by a single line separated by commas. It is important to have only one line — you shouldn’t break it up.

The values take effect only during the startup of the listener. After making the change in protocol.ora (in Oracle 8i) or sqlnet.ora (in Oracle 9i and later), stop and restart the listener. After you’ve done so, if a user, regardless of the authentication in the database or authority level, attempts to connect to the database on benefits1 from the node payroll1, he receives the error as shown below.

$ sqlplus scott/tiger@payrolldb1

SQL*Plus: Release 9.2.0.4.0 - Production on Tue Jan 2o 9:03:33 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

ERROR: ORA-12537: TNS:connection closed

Enter user-name:

The error message is not very informative; it does not explicitly state the nature of the error. This error occured, however, because the connection request came from a client that is not listed as accepted. In this case, the listener simply rejected the connection originating from the node benefits1, regardless of the user. Yet the same user trying to connect from node payroll1 would succeed.

Excluded Nodes

In the previous example, we saw how to allow only a certain set of clients, and disallow all others. Similarly, you can specify the other type of rule — exclude some clients and allow all others. Say the lines in the parameter file are as follows:

tcp.validnode_checking = yes

tcp.excluded_nodes = (payroll3)

All clients but those connecting from payroll3 would be able to connect to all nodes. So, in this case, clients benefits1 and benefits2 would be able to connect to payrolldb1 in addition to clients payroll1 and payroll2. Isn’t that counter to what we wanted to achieve? Where can this exclusion be used?

In real life cases, networks are subdivided into subnetworks, and they offer adequate protection. In a particular subnet, there may be a greater number of clients needing access than the number being restricted. In such a case, it might be easier to specifically refuse access from a set of named clients, conveniently named in the tcp.excluded_nodes parameter. You can also use of this parameter to refuse access from certain machines that had been used to launch attacks in the past.

You can also mix excluded and included nodes, in which case, the invited nodes are given precedence over excluded ones. But there are three very big drawbacks to this approach.
1. There is no way to specify a wild card character in the node list. You must specify a node explicitly by its name or its IP address.
2. All excluded or invited nodes are to be specified in only one line, severely limiting your ability to specify a large number of nodes.
3. Since the validation is based on IP address or client names only and it’s relatively easy to spoof these two key pieces of identification, the system is not inherently secure.

For these reasons, mixing excluded and included nodes is not quite suitable for excluding a large list of servers from a network or subnetwork. This method can be used when the list of machines accessing the network is relatively small and the machines are in a subnetwork, behind a firewall. In such a configuration, the risk of external attacks is very slight, and the risk of unauthorized access by spoofing key identification is negligible.

Oracle Net also provides another means to develop a rudimentary firewall using a lesser known and even lesser used tool called Connection Manager. This tool is far more flexible in the setup; you can specify wildcards n-node names without restrictions such as the need to have only a single line for naming the nodes. A detailed discussion of Connection Manager with real-life examples can be found in the book Oracle Privacy Security Auditing.

Troubleshooting

Of course, things may not always proceed as smoothly as in the examples we’ve cited so far. One of the common problems you can encounter is that the exclusion may not work even though the files may be present and the parameters seem to be defined properly.

To diagnose a node checking issue you may encounter, you need to turn on tracing during the connection process. Tracing the process can be done in several levels of detail, and in this case, you should enable it for the level called support, or "16." Place the following line in the file sqlnet.ora:

trace_level_server = support

Doing this causes the connection process to write detailed information in a trace file under the directory $ORACLE_HOME/network/trace. The directory can be specified to a different value by a parameter in the file sqlnet.ora, as
trace_directory_server = /tmp

By doing this, the trace information to be written to the directory /tmp instead of the default. After setting the parameters as shown above, you should attempt the connection again. There is no need to bounce the listener. The connection attempt will create trace files named similar to svr_0.trc to be written in the proper directory. You should open this file in an editor (parts of the file are shown below).

[20-JAN-2004 12:00:01:234] Attempted load of system pfile
source /u02/oracle/product/9.2/network/admin/sqlnet.ora

[20-JAN-2004 12:00:01:234] Parameter source loaded successfully

[20-JAN-2004 12:00:01:234]

[20-JAN-2004 12:00:01:234] -> PARAMETER TABLE LOAD RESULTS FOLLOW <-

[20-JAN-2004 12:00:01:234] Successful parameter table load

[20-JAN-2004 12:00:01:234] -> PARAMETER TABLE HAS THE FOLLOWING CONTENTS <-

[20-JAN-2004 12:00:01:234] tcp.validnode_checking = yes

[20-JAN-2004 12:00:01:234] trace_level_server = support

[20-JAN-2004 12:00:01:234] tcp.invited_nodes = (192.168.1.1, 192.168.1.2)

[20-JAN-2004 18:27:04:484] NAMES.DIRECTORY_PATH = (TNSNAMES)

[20-JAN-2004 18:27:04:484] tcp.excluded_nodes = (192.168.1.3)

[20-JAN-2004 18:27:04:484] --- PARAMETER SOURCE INFORMATION ENDS ---

These lines indicate that

1. The parameter file /u02/oracle/product/9.2/network/admin/sqlnet.ora was read by the listener.

2. The parameters were loaded successfully.

3. The contents of the parameter were read as they were mentioned.

4. The names of the excluded and invited nodes are displayed.

If the information is not as shown here, the problem be caused by the way the parameter file is written; most likely a typographical error such as a missing parenthesis. This type of error should be fixed before proceeding further along the trace file.

If the parameters are indeed loaded properly, you should next check the section of the file in which the node validity checking is done. This section looks like this:

[20-JAN-2004 12:30:45:321] ntvllt: Found tcp.invited_nodes. Now loading...

[20-JAN-2004 12:30:45:321] ntvllhs: entry

[20-JAN-2004 12:30:45:321] ntvllhs: Adding Node 192.168.1.1

[20-JAN-2004 12:30:45:321] ntvllhs: Adding Node 192.168.1.2

[20-JAN-2004 12:30:45:321] ntvllhs: exit

[20-JAN-2004 12:30:45:321] ntvllt: exit

[20-JAN-2004 12:30:45:321] ntvlin: exit

[20-JAN-2004 12:30:45:321] nttcnp: Validnode Table IN use; err 0x0

The first line indicates that the parameter tcp.invited_nodes was found. Next, the entries in that list are read and displayed one after the other. This is the most important clue. If the addresses were written incorrectly, or the syntax were wrong, the trace files would have indicated this by not specifying the node names checked. The last line in this section shows that the ValidNode table was read and used with error code of 0x0 (in hexadecimal, equating to zero) — the table has no errors. If there were a problem in the way the valid node parameters were written in the parameter file, the trace file would have shown something different. For instance, say the parameters were written as

tcp.excluded_nodes = (192.168.1.3

Note how a parenthesis is left out, indicating a syntax problem. However, this does not affect the connection; the listener simply ignores the error and allows the connection without doing a valid node checking. Upon investigation, we would find the root of the problem in the trace file. The trace file shows the following information.

--- PARAMETER SOURCE INFORMATION FOLLOWS ---

[20-JAN-2004 12:45:03:214] Attempted load of system pfile

source /u201/oracle/product/9.2/network/admin/sqlnet.ora

[20-JAN-2004 12:45:03:214] Load contained errors 14] Error stack follows: NL-00422: premature end of file NL-00427: bad list

[20-JAN-2004 12:45:03:214]

[20-JAN-2004 12:45:03:214] -> PARAMETER TABLE LOAD RESULTS FOLLOW <-

[20-JAN-2004 12:45:03:214] Some parameters may not have been loaded

[20-JAN-2004 12:45:03:214]

See dump for parameters which loaded OK This clearly shows that the parameter file had errors that prevented the parameters from loading. Because of this, the valid node checking is turned on and in use, but there is nothing in the list of the excluded nodes as shown in the following line from the trace file:

[20-JAN-2004 12:45:03:214] nttcnp: Validnode Table IN use; err 0x0

Since the error is 0x0, no error is reported by the validity checking routine. The subsequent lines on the trace file show other valuable information. For instance this line,

[20-JAN-2004 12:45:13:211] nttbnd2addr: using host IP address: 192.168.1.1

shows that the IP address of the server to which the listener was supposed to route the connection was 192.168.1.1. If all goes well, the listener allows the client to open a connection. This is confirmed by the following line:

[20-JAN-2004 12:45:14:320] nttcon: NT layer TCP/IP connection has been established.

As the line says, the TCP/IP connection has been established. If any other problems exist, the trace file will show enough helpful information for a diagnosis.

Summary

To summarize:

  1. Node Validation can be used to instruct listeners to accept or reject a connection from a specific client.
  2. The parameter file is sqlnet.ora in Oracle 9i and protocol.ora in Oracle8i.
  3. The nodes must be explicitly specified by name or by IP Address; no wildcards are supported.
arupnanda's picture

IOUG Webcast on Security

Many thanks to those who attended my webcast "Secure Your Database in a Single Day" for IOUG's wecast series. I hope you found it useful. I would highly appreciate if you take a moment to let me know how you felt - good, bad and ugly. Please write to me at arup@proligence.com.

You can find the scripts referenced in the webcast here.

To prevent automated spam submissions leave this field empty.
Syndicate content