but cman.ora can be used to prevent TCP/IP connections from specific servers that is what i have studied from metallink.oracle.com

From Documentation:

Protocol-Specific Parameters (protocol.ora)

Some protocols have platform-specific parameters. These are stored in the protocol.ora file. The protocol.ora file is located in $ORACLE_HOME/network/admin on UNIX and ORACLE_HOME\network\admin on Windows platforms, or in the directory specified by the TNS_ADMIN environment variable or registry value.
Listed next are some of the common parameters. For a complete listing of parameters for your operating system and platform, see your operating-system-specific documentation.
protocol.EXCLUDED_NODES
Purpose: Specifies which clients are restricted access to the database.
Syntax: protocol.excluded_nodes= (hostname | ip_address, hostname | ip_address,...)
Example: tcp.excluded_nodes= (hr.com, 144.25.5.25)

protocol.INVITED_NODES
Purpose: Specifies which clients are allowed access to the database. This list takes precedence over the protocol.EXCLUDED_NODES parameter if both lists are present.
Syntax: protocol.invited_nodes= (hostname | ip_address, hostname | ip_address,...)
Example: tcp.invited_nodes= (sales.com, 144.185.5.73)

protocol.VALIDNODE_CHECKING
Purpose: Checks for the protocol.INVITED_NODES and protocol.EXCLUDED_NODES to determine which clients to allow or deny access.
Default: NO
Values: YES | NO
Example: tcp.validnode_checking=yes


Hope this helps

What you could do (and what I had to do once) would be to create an allow_login table that will allow a client to login to the database based on one of the following being true:

host name of connection
os userid
application used

In a login trigger, you can interrogate those values (from either v$session or application context, I don't recall which) and then check if any of the "valid criteria" are met -- if so, login proceeds, else, raise an application error stating that login is not permitted for User X running Application Y from Host Z, and log it to the audit trail.

The challenge with using sqlnet.ora and the like is it restricts solely on the basis of IP, and that can be a real challenge in a DHCP world. This workaround allowed the DBA staff to connect to the database from anywhere using any tool, any app running "approved" servers to connect, and other "approved" apps running from anywhere to connect.

This solution is by no means perfect, and the most probable failure point is the application name, and probably should be used as the validation of last resort, as someone with bad intentions could rename the application to an "approved" name -- provided they knew what it was.

However, hostnames and usernames are significantly harder to fudge in a secured environment.

And, while it goes without saying, if you have such a requirement, you should be auditing successful and failed login events to determine if there appear to be (or have been) unauthorized access.

thanks for your responses
Mr : Riaz Shahid,Adam Musch

hi

first time i am Seting the Mts and Dedciated server.

could u plz tell me, how to do set up.

i have two databases on one server
i want to configure cman.ora
and block one tcp/ic add
will i have to define diff cman.ora and sqlnet.ora
for diff db's.
if one how how should i make the entries as i have one
production and one test db on a single server.