In general, I think I agree with you but you seem to have missed a few points:
[out of order]
Chuck Yerkes writes:
> (3) RPC? Over the 'Net? I think I stop that at my firewall.
By "private RPC mechanism", I was not referring to Sun RPC, or any other
specific protocol. I was simply referring to any means by which a function
called on one computer can pass its arguments to, and get results from, a
function on another computer. Since the specific protocol (carried within
the TCP connection) would be known only to its author, it would appear to be
arbitrary data to, and therefore be unstoppable by, a firewall.
Chuck Yerkes writes:
> (2) Not allow ANY inbound connections, other than those that are proxy
> controlled (ftp, telnet responses, etc).
It doesn't matter which end initiates the connection or whether or not it
goes through a proxy, as long as the two ends can exchange arbitrary data
with each other. A proxy could (for example) ensure that only a known set
of commands are passed over an FTP control connection but it could have
nothing to say about what flows over an FTP data connection other than to
prevent data from flowing in the "wrong" direction. Thus, simultaneous
STOR and RETR connections, even through a proxy, could be made to carry
a "private RPC mechanism" as I described above.
> Yes, an internal 'doctored' telnet that can negotiate proxies to an
> outside 'doctored' telnetd, and has, say Kerberos tickets, can present
> a problem.
As you (and others) have pointed out, the real defense is in authentication
at the proxy.
A preferable defense might be to prevent users from doing things they
shouldn't (running unknown programs) but when has that ever worked?
Don
--
dkrapf @
access .
digex .
net | See Clearly
dkrapf @
hermes .
acm .
rpi .
edu | Think Clearly
References:
|
|
