| 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> |
Parent Directory
| 
Revision Log