vdw/trunk/ora_obj_srvr.html

<HTML>
<META name="keywords" content="spoofing oracle, spoofing sqlnet, spoofing net8,
 sqlnet protocol, net8 protocol, oracle">
<Head>
<title>Warehouse version of Oracle Dedicated Server</title>
<h3>Warehouse version of Oracle Dedicated Server</h3>
</head>
<BODY>
<P>
Much of the packet-level and client/server socket code came from a sort of
"tnsping" perl script written by James W. Abendschan (jwa@jammed.com).
I added the packet type recognition and response logic, client-"database"
connect conversation, and sql query hand-off to the virtual warehouse. 
<P>
<a href=oracle_obj_srvr_pl.txt>The server</a> (speaks Net8, acts as middleman
between desktop client and warehouse server, which speaks sql).  The server is
started by the Oracle tnslsnr process, which thinks it's the oracle server.
<P>
<a href=tns_cmds.txt>Table of Net8 Command packets used</a>
<P>
<a href=tns_replies.txt>Table of Net8 Reply packets used</a>
<P>
NOTE:  Originally the server process spoofed the entire client/oracle connect
handshake, before handing the client over to the warehouse.  Then when adding
user validation I discovered that it was a lot easier to have the server
process connect directly to the real DB and allow the client and DB to talk
to each other for the connect handshake while the server monitored the packets.
This way most of the handshake logic doesn't need to be handled by the server,
so less spoofing is needed.  The server watches until it sees that the user
successfully logs in, then it disconnects the real DB and connects to the
warehouse (which is a middleman between the client and the real DB).
<P>
So the table of Net8 Reply packets contains many more packet types than the
server now uses.  However you could use these to spoof the handshake process
without a real Oracle DB connection, but they are very version specific on
both the client and server side, and no doubt contain some hardcoded stuff
that should be dynamic (I lifted them from the client and tnslsnr log files).
The names for commands and replies are just the best name I could come up
with based on what I thought the function was.
<P>
<a href=stored_procs.txt>Related Stored Procedures on Real DB</a>
<P>
<a href=obj_srvr_com.txt>VMS .COM file that starts warehouse server process</a>
This is used because it fits well with the existing SCT Banner system on our
server.  If running Banner on unix use a similar job submission shell script.
If not using Banner, you could skip this and have your OS process called from
the real DB be an OS script that starts the obj_srvr executable (see Related
Stored Procedures above).
<P>
<a href=listener_ora.txt>listener.ora</a> and <a href=tnsnames_ora.txt>tnsnames.ora</a> for tnslsnr
<P>
<a href=vdw.html>Back to warehouse main page</a>
</BODY>
</HTML>
1	dpavlin	1	<HTML>
2			<META name="keywords" content="spoofing oracle, spoofing sqlnet, spoofing net8,
3			sqlnet protocol, net8 protocol, oracle">
4			<Head>
5			<title>Warehouse version of Oracle Dedicated Server</title>
6			<h3>Warehouse version of Oracle Dedicated Server</h3>
7			</head>
8			<BODY>
9			<P>
10			Much of the packet-level and client/server socket code came from a sort of
11			"tnsping" perl script written by James W. Abendschan (jwa@jammed.com).
12			I added the packet type recognition and response logic, client-"database"
13			connect conversation, and sql query hand-off to the virtual warehouse.
14			<P>
15			<a href=oracle_obj_srvr_pl.txt>The server</a> (speaks Net8, acts as middleman
16			between desktop client and warehouse server, which speaks sql). The server is
17			started by the Oracle tnslsnr process, which thinks it's the oracle server.
18			<P>
19			<a href=tns_cmds.txt>Table of Net8 Command packets used</a>
20			<P>
21			<a href=tns_replies.txt>Table of Net8 Reply packets used</a>
22			<P>
23			NOTE: Originally the server process spoofed the entire client/oracle connect
24			handshake, before handing the client over to the warehouse. Then when adding
25			user validation I discovered that it was a lot easier to have the server
26			process connect directly to the real DB and allow the client and DB to talk
27			to each other for the connect handshake while the server monitored the packets.
28			This way most of the handshake logic doesn't need to be handled by the server,
29			so less spoofing is needed. The server watches until it sees that the user
30			successfully logs in, then it disconnects the real DB and connects to the
31			warehouse (which is a middleman between the client and the real DB).
32			<P>
33			So the table of Net8 Reply packets contains many more packet types than the
34			server now uses. However you could use these to spoof the handshake process
35			without a real Oracle DB connection, but they are very version specific on
36			both the client and server side, and no doubt contain some hardcoded stuff
37			that should be dynamic (I lifted them from the client and tnslsnr log files).
38			The names for commands and replies are just the best name I could come up
39			with based on what I thought the function was.
40			<P>
41			<a href=stored_procs.txt>Related Stored Procedures on Real DB</a>
42			<P>
43			<a href=obj_srvr_com.txt>VMS .COM file that starts warehouse server process</a>
44			This is used because it fits well with the existing SCT Banner system on our
45			server. If running Banner on unix use a similar job submission shell script.
46			If not using Banner, you could skip this and have your OS process called from
47			the real DB be an OS script that starts the obj_srvr executable (see Related
48			Stored Procedures above).
49			<P>
50			<a href=listener_ora.txt>listener.ora</a> and <a href=tnsnames_ora.txt>tnsnames.ora</a> for tnslsnr
51			<P>
52			<a href=vdw.html>Back to warehouse main page</a>
53			</BODY>
54			</HTML>