Oracle Consulting Oracle Training Oracle Support Development
Home
Catalog
Oracle Books
SQL Server Books
IT Books
Job Interview Books
eBooks
Rampant Horse Books
911 Series
Pedagogue Books

Oracle Software
image
Write for Rampant
Publish with Rampant
Rampant News
Rampant Authors
Rampant Staff
 Phone
 800-766-1884
Oracle News
Oracle Forum
Oracle Tips
Articles by our Authors
Press Releases
SQL Server Books
image
image

Oracle 11g Books

Oracle tuning

Oracle training

Oracle support

Remote Oracle

STATSPACK Viewer

Privacy Policy

 

   
 

Oracle Tips by Burleson

Checking for Attempted Oracle Break-ins

The reason you want to password protect the listener is to make sure no unauthorized person tries to modify the listener. However, listener password management is not as robust as that inside the database – there are no expiry dates for the password, no format validations, etc. This may tend to make the password a little weaker, and make it more prone to break-ins through brute force. Hackers try all the possible passwords they can guess to finally hit upon the correct one.

However, every unsuccessful attempt is clearly recorded in the log file of the listener. Here is an example of the listener.log that displays an attempted access with an incorrect password:

05-JUL-2003 21:14:39 * services * 1169

1 TNS-01169: The listener has not recognized the password

05-JUL-2003 21:14:46 * services * 1169

2 TNS-01169: The listener has not recognized the password

05-JUL-2003 21:14:55 *

 

Figure 7.8 Typical Client and Server Restrictions Based on Departments

In this network, the application servers CLAIMS1 and CLAIMS2 access the database on server CLAIMDBSVR. Since we know that no client machines other than the ones shown here are going to access the server database, the Net8 listener on the database server can be configured to accept connections only from these machines. The network also has some other servers, such as the application servers ENROLLMENT1 and ENROLLMENT2 accessing the database on server ENROLLDBSVR. The listener on CLAIMDBSVR can be configured so that the connection requests from ENROLLMENT1 and ENROLLMENT2 are rejected and CLAIMS1 and CLAIMS2 are accepted.

This can be done suing a facility called Valid Node Checking in Net8. A set of parameters can be placed in

ome parameter files on the server with the following lines.

tcp.validnode_checking = yes
tcp.excluded_nodes = (enrollment1, enrollment2)
tcp.invited_nodes = (claims1, claims2)

The location of these parameters varies from version to version. In Oracle 8i, these are set in a file named protocol.ora; in Oracle 9i, these are set in sqlnet.ora. Both of 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.

Important: The parameters are set in sqlnet.ora in Oracle9i and protocol.ora in Oracle 8i.

These parameters are intuitively 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 the nodes enrollment1 and enrollment2 are not allowed to connect to the listener. The nodes are indicated either by IP Address (e.g. 192.168.1.100), or the node names as shown above. A single line that is separated by commas specifies the list of node names. The single line is important – you can't break the line.

The third line states that the nodes claims1 and claims2 are allowed. This is important if you specify some node named in the excluded list, but then specify that node as

allowed in the invited list. If this list is specified, then it takes precedence over the excluded list.

After making the change in protocol.ora (in Oracle 8i) or sqlnet.ora (in Oracle 9i and above), stop and restart the listener. The values take effect only during the startup of the listener. After this change, if a user, regardless of the authentication in the database or authority level, connects from the node enrollment1, he or she receives the error

$ sqlplus nathan/5ucc355@claimdb
 
SQL*Plus: Release 9.2.0.2.0 - Production on Wed Jul 2 11:57:06 2003

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

ERROR:
ORA-12537: TNS:connection closed


Enter user-name:
 
The error message is a little less intuitive It does not explicitly state the nature of the error.

The same user connecting from node CLAIMS1 will succeed. In this case, the listener simply rejects the connection originating from the node ENROLLMENT1, regardless of the user. 

This principle can be extended to cover a variety of friend or foe servers and clients. However, there is no way to specify a wild card character in the node list. For this reason, this method is not very suitable for excluding a list of servers from a network or sub-network. This can be used where the list of machines accessing the network is relatively small and the machines are in a sub-network, behind a firewall. Since the names of the machines are known, the list of allowed and excluded nodes can be easily set up, and this approach can be used.

Summary

  • Node Validation can be used to instruct listeners to accept or reject a connection from a specific client.
     

  • The parameter file is sqlnet.ora in Oracle 9i and protocol.ora in Oracle8i.
     

  • The nodes must be explicitly specified by name or by IP Address; no wildcards are supported

 



 


Download your Oracle scripts now:

www.oracle-script.com

The definitive Oracle Script collection for every Oracle professional DBA

 

Linux Oracle commands syntax poster

ION Oracle tuning software

Oracle data dictionary reference poster



Oracle Forum

BC Oracle consulting support training

BC remote Oracle DBA   

 

   

 Copyright © 1996 -2016 by Burleson. All rights reserved.


Oracle® is the registered trademark of Oracle Corporation. SQL Server® is the registered trademark of Microsoft Corporation. 
Many of the designations used by computer vendors to distinguish their products are claimed as Trademarks