
Experimentation revealed three levels of message hiding: none, message compression to discourage casual eavesdropping and key-based encryption. Any use of encryption or compression, of course, made the Sniffer packet-level display unintelligible. But while we could not decipher the messages' contents, the database server destination address commonly appeared in the TCP/IP headers of our encrypted LAN messages.
In one test of our VB application, Oracle8 and Oracle's Advanced Network Option, DES-based encryption slowed database responses by 35 percent compared with the use of clear text; the RC4 RSA standard slowed responses by 18 percent (see "Database Response Times" above right). Your mileage may vary, because in some cases compression saves bandwidth by reducing a database response message from two or three 1,500-byte Ethernet packets to one.
Firewalls--either packet filters or proxy servers--can give a false sense of security in a database server environment. Similarly, routers offer false hope to administrators who need to establish private links between networks and nodes. For example, on a TCP/IP-based network, the assumption that host names or Internet addresses (e.g., 192.100.200.19) are a reliable and trustworthy means to identify a connection's start and end points is unwarranted. Placing a network adapter in promiscuous mode, which allows it to eavesdrop on all the packets traversing the network regardless of their destination addresses, is a simple matter of programming a few C or assembler statements using the manufacturer's reference manual for that adapter. Anyone with programming skills can not only receive any network message but also send bogus messages, and he or she can also insert arbitrary addressing information into the spoofed messages.
Sending messages with bogus address stamps, if done carefully, can allow an unauthorized computer to add itself to the network smoothly and unobtrusively. It's all too easy for a skilled, dishonest programmer to create an environment in which a computer poses as a database server or authorized database client. It isn't difficult to defeat a security system that relies on restricting database server traffic to certain node addresses, even in the presence of a well-designed router-isolated network. Fooling a router into passing WAN messages with bogus addresses takes about the same effort as spoofing LAN messages.
With a bit of clever programming, someone can then insert a computer in the midst of a conversation between two other computers on a TCP/IP network. This interesting but misguided exploitation of the IP's address assignment algorithm lets the intruder send and receive unauthorized database transactions. Essentially, the algorithm specifies that a network adapter honor another adapter's claim to be a particular Internet address by equating the claimed dot address with the most recent hardware address received from that other adapter. The intruding computer can display, record, selectively filter or even modify the database transactions that flow through it.
As we risked eternal damnation to experiment with these TCP/IP loopholes, we found encryption (DES- or RSA-based) an excellent obstacle to message spoofing. Compression was an obstacle only when we did not use the same data-access middleware as the rest of the network, which means inside jobs perpetrated by people familiar with your network can overcome the unintelligibility introduced by network message compression. Viewing, filtering and spoofing unencrypted, clear-text messages was a piece of cake.
Barry Nance, a computer analyst and consultant for 28 years, is the author of Introduction to Networking (Que, 1997) and Client/Server LAN Programming (Que, 1994). Send your comments on this article to him at barryn@erols.com.
|