With any luck, my last column convinced a few of you that taking a part of your network completely off the Internet is not as absurd as it may sound.
With any luck, my last column convinced a few of you that taking a part of your network completely off the Internet is not as absurd as it may sound. No matter how many times some developer hypes his increasingly "Internet-aware" software, the fact remains that such awareness carries a very real price and may not provide a correspondingly significant benefit.
Complete isolation clearly is not appropriate in every situation; I would be the last one to argue against making the fullest use of the power of the public Internet.
Happily, there is a middle ground. Specialized switching technologies offer many of the advantages of physical isolation, while they still allow the transfer of data between networks. The "total isolation" model discussed last time relied upon the user to act as an intermediary, examining data on each network and physically transferring appropriate traffic back and forth. That process, however, also can be automated and relegated to a device known as a real-time switch.
The real-time switch sits between two machines on a local networkone outward facing, one inward facingbut is only physically connected to one at any given time. Data comes in from a public network through the outward-facing box and is handed off to the switch. It, in turn, strips out all protocol header information and inspects the contents of the raw data. The switch can then connect to the inward-facing machine and pass on data deemed safe. At no time is a live TCP/IP session established. The process is reversed for outward-bound data.
That process can be tricky to implement, particularly with complex transactions, and is in many ways less discerning than a human observer. Moreover, it cannot accommodate transactions, which require a live TCP/IP session. But it does block network protocol-based attacks and filters out most threatening traffic at speeds sufficient to allow real-time network transactions; switch throughput can range from 130Mbps to 800Mbps. Note that these switches are designed to complement, rather than replace firewalls. Because they are designed to accommodate a specific, limited set of appli-cations, they are best used to create an "air gap" between a networks demilitarized zone and isolated, sensitive servers. Firewalls remain necessary to protect other transactions and protect the switches outward-facing connection from direct attack.
Similar techniques can be used to create "leakproof" one-way connections between machines and networks. Specialized hardware links physically capable of transferring data in only one direction are available, or real-time switches can be adapted for that purpose by disabling the shuttling of data in one direction (that is a configurable option in some hardware).
Those solutions may or may not work in your environment, but they illustrate part of the range of options available beyond the traditional firewall. A creative defensive approach may be your best weapon against a crafty opponent.