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