 |
|
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
|
|
