sqlnet-proxy, test-sqlnet — Oracle SQL*Net Proxy
sqlnet-proxy [-hv] [-d ] dbglev-f
cfgfile
test-sqlnet [-hv] [-d ] dbglev-f [cfgfile-r] [-t ]test_expr
The sqlnet-proxy provides proxying service for the Oracle SQL*Net Protocol. The proxy recognizes the initial Transparent Network Substrate (TNS — do not mistake this abbreviation for Trusted Network Solutions, a.s.) handshaking, after successful intialisation, it forwards requests and responses between client and server (checking TNS Layer). During this phase, the proxy checks database login attempts so that effective limitation of allowed users can be done.
The proxy reads its configuration file and starts listening
on specified IP sockets (address/port couples), as specified in
the listen-on configuration section (see listen-on(5)).
Format of the configuration file is described in sqlnet-proxy.cfg(5).
Program test-sqlnet tests syntax and partially semantics of configuration; for test expression syntax, see test-expr(5).
The current version of SQL*Net proxy uses two layers of ACL
(see access-control(7)) named session-acl and
service-acl.
When a connection (either transparent or non-transparent) arrives,
proxy decides according to the first level of ACL whether to accept it
or not. Then proxy waits for the connect (CN) packet.
The total time until whole CN packet is received is limited to
the init-timeout. After completing the CN packet,
the configuration is consulted, proper service-acl is
selected and according to it, connection is allowed or not. In
addition to the general Kernun ACL criteria,
the set of acceptable service names can be specified
(service-name item, see sqlnet-proxy.cfg(5)).
Target server/port/service can be coded by the client
in the CONNECT_DATA.SERVICE_NAME
(or CONNECT_DATA.SID) aatributes
by the following syntax
service_name@server[:port]ADDRESS.HOST
and ADDRESS.PORT attributes.
The default port can be set in configuration
(the default-port item).
If a plug-to directive is used in
session-acl found, its value has precedence over the
server used in the CN string.
This means that the sqlnet-proxy will ignore the
server given in the CN string and connect to the
plug-to server.
Firewall administrator can choose the out-of-band method described in auth(7) for authenticating users on the proxy.
If the remote server replies by the RD (redirect) string,
the proxy itself tries to connect the advised server
without co-operation with the client.
Of course, the new connection is again checked against
the session-acl set.
The client is notified by the final
response — accept (AC) or refuse (RF).
The sqlnet-proxy protects against the risc of
an infinite loop in RD packets. The admin can set the maximal number
of RD packets in one session
(the session-acl.redirections item).
Special care should be taken in case of using
the plug-to directive.
If remote (plug-to) server uses RD
string, result of session-acl checking can lead to
re-connecting this server (and infinite loop, too). If intention of RD
answer is only port switching, the port number of the
plug-to directive value should be zero (“let
port untouched”).
Several versions of TNS Listenner (lower layer of SQL*Net Server) have weak protection against intrusion attacks. The Kernun sqlnet-proxy can avoid some of them by configuring additional security attributes in the configuration:
max-service-name-lenSeveral versions of TNS Listenner crash by the buffer overrun error when reading too long names. This item specifies the maximal length of the SID/SERVICE_NAME attribute of the CN string allowed by the proxy.
check-reserved-bitsSome versions of TNS Listenner crashes when the initial TNS handshaking packet has reserved bits filled with non-zero values. This item switches on/off checking of the reserved bits.
The sqlnet-proxy allows administrators to
restrict which database users can use its service for particular ACL.
However, the protocol is not freely published and there can be some
problems with unknown versions of it. Thus, full support of this
feature is provided for TNS (Transparent Network Substrate) versions
3.07 and 3.10 through 3.13. Proxying of other versions must be
permitted by the protocol-version configuration item,
however, database user checking is switched off in this case.
For known protocol versions, set of permitted database user can
be specified by the db-user configuration item.
The proxy uses common Kernun mechanism for listening on its sockets, forking new processes as needed and killing old redundant processes, optionally changing root directory and running with alternative user privileges. For more detailed information, see application(5) and tcpserver(7).
The proxy uses common Kernun mechanism for network
input/output operations. Configuration allows for specifying
several parameters like buffer sizes and timeouts, both for
client and server connections. They can be included in
the client-conn and server-conn
configuration sections,
respectively. For more detailed information, see netio(7).
The proxy uses common Kernun mechanism for name resolving (see resolving(7)).
The proxy uses common Kernun mechanism for logging (see logging(7)). For every session, the SESSION-START (SQLP-801-I), the ACL (SQLS-810-I and SQLS-820-I), the SESSION-INIT (SQLS-840-I) and the SESSION-END (SQLP-809-I) messages are logged.
The program options are as follows:
-hPrint usage information and exit.
-vDisplay version information and exit.
-d
dbglevSet debuging level to a specific number. Permitted values are 3 through to 9, 3 being the least and 9 the most verbose. See logging(7) for details. This setting is relevant only till configuration reading is finished.
-f
cfgfileRead cfgfile
for configuration information.
-rResolve names in configuration prior to testing.
-t
test_exprTest configuration according to given expression.
Format of the test_expr
is described in test-expr(5).