> the alternative being real authentication (eg
> SecurId) for every outbound connexion as well as every inbound
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:
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
..even if she has to supply the connect authentication manually (eg
SecurId) to set the connection up. So even things like TIS's
authentication hooks don't seem to prevent this kind of thing?
I.
--
Ian Dunkin <imd1707 @
ggr .
co .
uk>
--
Follow-Ups:
References:
|
|
