Andrew MacKenzie wrote: >My only question is: Would machine B need to be on a serial port or some >such? Would a private ethernet line (or route) to machine A suffice? Good question. Here's the tradeoff. If you connect the two machines with just a plain byte channel, you can be sure what software on machine B might be exposed to attack across this channel. If you connect the two machines with TCP/IP, then the risk is that machine B might have a bunch of servers listening on various ports, and then a compromised machine A might be able to break into machine B across the TCP/IP link between the two, which is undesirable. The goal of the link between machines A and B is to establish a security perimeter between the two, and to do this as well as possible, we should limit the "surface area" of the code on machine B that's exposed to the other side of this security parameter. Now you might ask: What does byte channel vs. TCP/IP have to do with serial port vs. ethernet? As far as I know, the answer is: Not much, except that with a serial port it is easy to build a byte channel, whereas with an ethernet, you'll probably end up with TCP/IP connecting the two machines. TCP/IP is less desirable, as I argued above. But you might be able to recapture the advantages of a byte channel and still use TCP/IP if you stick a very strict packet filter on machine B. For example, you could run a private ethernet link between the two machines, stick a chroot-ed ftp server on machine B, and then add a packet filter on machine B that allows only ports 20 & 21 from only machine A and drops everything else. I think this ought to be about as good as the serial port based scheme I suggested.
This archive was generated by hypermail 2b30 : Sun Jan 12 2003 - 19:29:25 PST