-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Friday, July 14, 2000 7:11 PM
>
> I didn't hear no bell.. :) Let's go one more round.
Sure, I'm game... :)
BTW: [EMAIL PROTECTED] and I continued our discussion offline for a
little bit. Turns out that his approach also sets authentication at
the outside perimeter (firewall/router), just using Kerberos instead
of Radius/Tacacs/etc. A misunderstanding of his scenario on my
part.... Anyway...
> Put the box anywhere on the
> network, as long the there is a some sort of ACL in front and
> in back of
An ACL in the front is easier to setup and maintain than an ACL on
the back (as is TS in the DMZ), see below.
> >As far as I'm concerned security
> is the inverse
> >of complexity. Authenticating users at the boundary is a
> simple approach
> >but has it's own limitations.
Such as?
> [...]
> >Authenticating users at the boundary can also provides
> reasonable security
> >with a minimual amount of client setup but it only grants
> someone access
> >into the network. They still need the Citrix piece to be
> able to use the
> >application efficiently. Thus we have introduced complexity to
> >the solution. The client now has two pieces of software that
> >need to be installed, configured and maintained. And the user
> >now has
> to go through
> >two authentication processes.
Correct, that's why I was so pumped about the possibility of having a
challenge/response token login on the TS instead of the standard
user/password/domain logon. I hope David can get something similar
from Axent. Currently, users need to authenticate against the
firewall with a token, and then log on the TS with their domain
account. If both could be combined, you have only one logon interface
for the user, but still strong security since you are using OTP's.
> >My preference for this type of configuration is to put the
> Citrix box in
> >the DMZ, not make it part of the domain, install all the
> apps the users
> >need to get to and only grant the apps access to the hosts
> and services on
> >the internal network that are required for it to function
> properly. [...]
That, however, is not always possible. I have quite a few clients
that still have Novell on the back end for file/print. One client for
example needs to have their attorney's get on to the Terminal Server
in order to run PCDocs. Docs makes use of a SQL servers and Novell
servers (library). So here are some pitfalls for firewalling the TS
from the rest of the internal network:
a) Protocols not supported by firewall: May it be IPX or SNA, there
are some protocols that aren't easily firewalled.
b) Unauthenticated ACL's: How would you define your access control
lists on the firewall? Would you have the user authenticate again
with a password? If not, you would base your rule set on the host TS
address, which leads to c).
c) Host Hopping: If you define your firewall rules to allow the TS
access to the internal network, you surely would only allow it access
to machines it needs to and do not allow access to other internal
devices, correct? That's great, better than full access. But now we
have holes to a few machines that could be exploited to hop along to
other servers.
I believe securing a network from attacks coming from a TS is a
futile effort. I therefore focus on the access to the TS, not from
it. The way I see it, your network is compromised once someone hacks
into the TS, no matter how hard you try.
Regards,
Frank
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.1
Comment: PGP or S/MIME (X.509) encrypted email preferred.
iQA/AwUBOXE2hURKym0LjhFcEQJiLQCgmNieOZpV5FT9ILZUH5BVvw+OJ9oAniJq
u9Z87F2I1TpZiAKdrhZkbfIN
=gSJO
-----END PGP SIGNATURE-----
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
