Actually this has been the norm for quite a while.  Simpler methods would 
be to setup the modem support as a dialback so that the vendor has to use a 
dedicated line in order for the remote modem to dial it back after the 
first call. If you add layers to the support requirement (i.e. 
administrative, physical, and technical overhead), one  diminishes the cost 
effectiveness of vendor support.  Also look into the possibility of using a 
Sentry DialBack Device which allows for the turning on/off of remote 
devices via a time block schedule.

Also restrict the use of where the dial-up user can go

Adding another layer may complicate matters:  With a SecurID token card 
authentication, one has to setup the ACE server, setup users, set up NTP 
since SecurID relies on a reliable clock in order to sync with the Token.



At 04:19 PM 10/10/00 -0400, Ng, Kenneth \(US\) wrote:
>Either (a) SecurID token card authentication, (b) modem is normally turned
>off until needed (and we run a periodic war dialer to find modems left
>turned on), or (c) the server is completely disconnected from the network.
>
>-----Original Message-----
>From: Sean Boyle [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, October 10, 2000 4:04 PM
>To: Firewalls Mailing List
>Subject: Modems on Servers
>
>
>With increasing regularity, vendors seem to be insisting (to the point
>of being a lockout spec) on modems being attached to their products in
>order to qualify for a support contract.
>
>How are others handling this 'backdoor' remote access system?
>
>--
>PGP Fingerprint: 22 68 D5 18 7F 3D D2 28  38 97 90 97 17 55 61 59
>GPG Fingerprint: D5C0 2D79 F517 EEB6 D30B  58B3 9E37 E7CA 47A9 56EE
>Opinions expressed here do not necessarily express the opinions of
>Mentor Graphics or its subsidiaries.
>
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
>
>*****************************************************************************
>The information in this email is confidential and may be legally privileged.
>It is intended solely for the addressee. Access to this email by anyone else
>is unauthorized.
>
>If you are not the intended recipient, any disclosure, copying, distribution
>or any action taken or omitted to be taken in reliance on it, is prohibited
>and may be unlawful. When addressed to our clients any opinions or advice
>contained in this email are subject to the terms and conditions expressed in
>the governing KPMG client engagement letter.
>*****************************************************************************
>-
>[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.]

Reply via email to