>> Has anyone ever configured RealSecure in a manner that prevents a
user whom
>> is terminal serving or telneting or PCAnywhereing into one server,
to do
>> support work, from using that same server to "jump-off" to another
server.
Unfortunately, that's not possible to do with Realsecure because:
RS is not a firewall or access-control product.
There are some limited scenarios where RS could be operated as one. Instead
of having a proper control in place to start with, you could kill/block the
traffic / behaviour that you didn't want, but that's neither efficient nor
secure. For starters, the protection doesn't fail safe, i.e. when the
sensors go down, so does your almost-like-a-firweall-function.
However, you still want a solution to your problem...
I'm assuming that outgoing connections are only disallowed when someone is
remotely connected, otherwise it's simple - firewall the host, disallow
outgoing connections entirely.
Even if RS was the tool that enforced your restriction, the restriction must
be defined to be regognized. That's *really* difficult, involving many
aspects.
You want users privileges to depend on their method of access, i.e.
non-local vs. local. That's high-level - requiring visibility of
a) the action to initiate the connection or the connection itself
b) the user/account
c) determine controlling source of the context/user/application
Ideally, that would be a spiffy operating system. Another approach is that
the application ( pcanywhere, telnet, vnc) itself manages the restriction,
perhaps even with help of the OS.
It couldn't done from a network or stack point of view, because you have two
streams, each valid/allowed. One stream is between remote worker & host A
(to application/port PCAnywhere for example), the other between A & B. Even
on the same wire, nothing binds the two streams together, from the network
sensor's perspective. You could theoretically correlate data from network
sensors, server sensors and various host agents to find this out, but it's
infeasible to do.
Some "real" operating systems have general support for rights depending on
source terminal. Windows does not. In theory you should use such
access-controls/rights *on* the host to enforce your restriction, but even
if Windows understood this kind of thing properly...
... applications like PCAnywhere, vnc or telnet basically act to bridge or
circumvent a technical or securty restriction. The whole point is to make
local functionality available to a remote user. That's why Server sensor
won't help - unless the OS knows about it, Server sensor doesn't really care
(a somewhat overbroad generalization, I know). But if the OS did know, you'd
just use that feature to not allow the behaviour in the first place.
To sum it up, you're seeing a a best-of-both worlds dilemma. First, people
want remote access, then paranoia kicks in. I'd suggest not using RA if the
risk is percieved to be too high, but people tend to want the impossible (or
very difficult)
I'd change the strategy, stack the deck in your favor - don't do the
impossible (or very difficult). Instead of taking away something that's
already there - design things so that it is not available in the first
place.
Modularize the problem. Make the local/remote a separate item - don't
TS/vnc/PCAnywhere into the full production environment, create a sand-box
host (sand-box?!) instead.
Now all you have to worry about is restricting that sand-box to suit your
needs. This is a straightforward excercise - make sure that even if you're
sitting at the console, you're unable to do anything you shouldn't. Firewall
it, deploy IDS, use host rights, remove binaries, install third-party tools
- whatever it takes. Mandate DNA-matching authentication if helps.
Regards,
Robert
_______________________________________________
ISSForum mailing list
[EMAIL PROTECTED]
TO UNSUBSCRIBE OR CHANGE YOUR SUBSCRIPTION, go to
https://atla-mm1.iss.net/mailman/listinfo
