Frank,
You missed the point, the whole architecture is very transparent to the
user. In fact, if architected and implemented correctly, the user wouldn't
even know about the stuff going on in the background.
I never stated to allow the world access to the TS only authorized users,
the authentication and authorization permissions would be at one convenient
central management station.
Would you like me to get out the 8 x 10 glossy photos with circles and
arrows with a paragraph on the back of each one.. Or would you like me to
sit on the Group W bench.. :)
/m
At 12:49 PM 7/14/00 -0500, Frank Knobbe wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, July 13, 2000 10:21 PM
> >
> > This is way overkill. The solution provided earlier was a
> > very simple and
> > elegant solution using existing and proven technology that is
> > freely available and does not require more than a couple of weeks
> > of interoperability testing.
>
>Not at all. IMHO it's far easier to configure the firewall with token
>authentication for the ICA port than to lock your TS down so much
>that intruders could not do a lot of damage. a) you would also
>restrict your users, and I'm sure that there is something on the TS
>that your users would need to use on the network, like email or
>access to apps. b) It is easier to maintain a decent level of
>security and maintain all configuration, that were necessary to
>achieve that level, if you focus on the access (protocol through
>firewall) part rather than the security environment on the server
>itself.
>
>It seems to me that a lot of security consultants have lost a sense
>of reality and common sense. I don't mean you in particular, but a
>lot of folks just go way overboard in securing systems, up to a level
>were security is so tight, they restrict themselves too much and
>cause problems, or of course spend too much time on it. You method of
>allowing the world access to the ICA port but securing the TS system
>on a configuration level could be likened to leaving the front door
>unlocked, but requiring keys and sign-in sheets and escorts and
>whatnot for each room in the building. My suggestion of restricting
>access to the ICA port but being a little more lax in the security on
>the system itself is more like enforcing access on the front door
>with a secure lock, but leaving the rooms inside the building easier
>accessible. Now look around where you work. Unless you are in a high
>security facility (i.e. research lab, military facility, etc), you
>will agree that your front door is tight, but your office doors
>(although shut) are not locked. You can also easily see why
>(especially when you have to unlock your restroom every time you need
>to go :)
>
>In addition, using your method would require additional security
>configurations and security checks every time you change something on
>the TS, i.e. installing a new, performing upgrades, etc. My method
>let's you do that quicker.
>
>Now, I'm as paranoid as you are about folks getting into my system.
>But I also see the value of easier maintenance and support. I hope
>that this message will not light up an old holy war. These are just
>my opinions (imagine standard disclaimer here).
>
>Regards,
>Frank
>
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGP Personal Privacy 6.5.1
>Comment: PGP or S/MIME (X.509) encrypted email preferred.
>
>iQA/AwUBOW9Sr0RKym0LjhFcEQJwDQCghHyXoXn9xYOvSK1/lig9ydHnFXkAoNM+
>jCnGg55PNMoxrbqW/ytq61tx
>=wU8i
>-----END PGP SIGNATURE-----
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
