Bill Heiser wrote:
>
>
> Eric Murray <ericm @
MicroUnity .
com> wrote:
>
> > Actually, it occurs that in this second scenario -- a confederate of the
> > baddies, perhaps a disaffected employee inside your network -- even
> > authentication of outbound connections wouldn't help you: if this
> > insider is `trusted' -- allowed to make outbound connections through
> > (say) your telnet application gateway -- then she can if so determined
> > misuse this channel anyway (eg:
Bill, I didn't write that. Watch your attributions please.
Not that I don't agree with it, as far as it goes.
> > connects out via your telnet application gateway to a port on a <---**
> > collaborating remote system, which echoes back commands to be
> > executed on your local system; user's local program -- either
> > custom written, or `expect' wrapped around an ordinary telnet
> > client(?) -- then acts accordingly, and echoes resulting output
> > back down the line
>
>
> ... Well how about if the application gateway does not allow internal
> users to "telnet to a port", but only allows telnet to the standard
> remote telnet port? ...
Still a problem, if they can telnet they can send data.
Any halfway determined employee can get company secrets out past
any resonable security.
You have to draw the line somewhere. At some point you will have to
trust the employees. If not, you will become more and more parnoid
and restrictive until you wind up locking them in a cage
and poking them with sharp sticks. :-)
--
ericm ericm @
microunity .
com
Follow-Ups:
References:
|
|
