Thursday, January 14, 2010

TCP Validnode Checking

Somebody asked me few days back about this so thought of just writing few lines about it and showing a test case. Here you go...

Depending on the type of application and network configuration, valid node checking can be a powerful tool to restrict most traffic from the Listener. Most web applications only require access to the Listener from the application servers and a limited number of clients for administration.

For Oracle 9i/10/11g, the valid node checking lines are added to the $ORACLE_HOME/network/admin/sqlnet.ora
For Oracle 8/8i, the lines are added to the $ORACLE_HOME/network/admin/protocol.ora file.

tcp.validnode_checking = yes
tcp.invited_nodes = (x.x.x.x name, x.x.x.x name)
tcp.excluded_nodes=( x.x.x.x name, x.x.x.x name)

Include either the invited_nodes or excluded_nodes, but do not use both. Wildcards, subnets, etc. are not valid, only individual IP addresses or host names are allowed. For more sophisticated checking, use Oracle Connection Manager.

The Listener must be stopped and started for valid node checking to become active. There is no hard limit on the number of nodes that can be included, but for a large number of entries using Oracle Connection Manager may be a better solution. If many clients require direct SQL*Net access to the database, it is often difficult to use valid node checking due to constantly changing network configurations.

Let’s now take an example -

Step 1 – Two users (SUSH and ROOP) connected to one of the test database using sqlplus.

Both were able to connect to the database.

Step 2 – I then updated the sqlnet.ora of this test database and added the following parameters –

tcp.validnode_checking = yes
tcp.invited_nodes = (10.100.10.11, 10.100.10.12)

Since I want to give privilege only to my machine to connect to this database, I added my machine’s IP address along with the IP address of the server itself. I added these parameters not only to the server’s sqlnet.ora but to my machine’s sqlnet.ora also.

Step 3 – Bounced the Listener. So, that the changed parameters can be now in effect.

Step 4 – Now I tried to connect to the same schema again and I was successful in doing so.

Step 5 – Now SUSH tried to connect to the same schema but she was unsuccessful with the following error –

H:\>sqlplus test_schema/*****@sandbox

SQL*Plus: Release 11.1.0.6.0 - Production on Wed Jan 6 15:48:02 2010

Copyright (c) 1982, 2007, Oracle. All rights reserved.

ERROR:
ORA-12537: TNS:connection closed

This proves that valid node checking helps in securing the database server and is quite a robust security solution from external attacks. But we need to assess each database server and find if it will really be a viable solution to your environment.

Challenges you can face while implementing this solution will be like –

1. One can have multiple applications on one database. So one application might be touched by only application servers but another can be touched by not only app server but individuals also. So the management tracking all these IP addresses will be too cumbersome.


2. One can have only one Listener for all the databases on one server. This has same issues as described in point 1.

No comments:

Post a Comment