[Top][Contents][Prev][Next][Last]Search

Network Security Settings

This appendix discusses the following topics:
Introduction
Restricting access to the terminal server
Restricting access to DNS information
Restricting SNMP access
Preventing misuse of directed broadcasts

Introduction

Authorization procedures define what a user may do once he or she has access to your local area network. Authorization occurs after authentication has been completed.

In the MAX TNT, you restrict or authorize network access in the following profiles:

For information about using packet filters or firewalls to define which packets may cross your network, see Chapter 9, Ascend Packet Filters, and Appendix C, Secure Access Firewalls.

Restricting access to the terminal server

The MAX TNT terminal server handles incoming calls initiated by means of a modem or terminal-adapter (TA). These calls are usually initiated by a dial-in user, so authorization is an important part of the setup. For details of authenticating terminal-server logins, see Appendix A, Access Security Settings.

For the MAX TNT to answer modem or TA calls, the terminal-server software must be enabled. Following is the related parameter:

If the software is not enabled, you can enable it as follows:

Most sites do not allow dial-in users to access the MAX TNT terminal-server administrative commands, such as Traceroute or Ping. In most cases, the terminal server is a stepping stone toward access to one or more network hosts. There are several ways to configure the Terminal-Server profile to enable this type of access:

Authorizing terminal-mode access

 Typically, administrators set up terminal-mode to negotiate a user-to-host session as part of the dial-in Expect-Send script. Instead of providing only the login and password needed to authenticate a Connection profile, the script also includes the terminal-server prompt and a command, such as PPP, SLIP, Telnet, or Rlogin. In this way, the session to a host is invoked as part of the login process, so the user never actually sees the command-line prompt. Alternatively, you can provide access to the command line and restrict which commands are accessible.

Password-protecting the command line

For details of setting up a password that is always required for access to the terminal-server command line, see How security mode affects terminal-server authentication of Appendix A, Access Security Settings.

Restricting network commands

By default, the Terminal-Server profile disables the use of the Ping and Traceroute commands as a security measure, because these commands authorize users to gain information about the network. Following are the related parameters, shown with settings that disable Ping and Traceroute:

You can set the parameters to Yes if you want to enable use of the Ping and Traceroute commands from the terminal-server prompt.

Authorizing interactive logins from the terminal-server

By default, the Terminal-Server profile disables the use of the TCP, Rlogin, and Telnet commands, because those commands are provided in immediate mode in a more secure fashion. Following are the related parameters, shown with settings that disable the TCP, Rlogin, and Telnet commands:

The following commands enable the use of the Telnet command from the terminal-server prompt:

Setting Telnet session defaults

 The following parameters affect Telnet session defaults:

Users can modify some of the default values on a per-session basis when they invoke the Telnet command. Following is an example that configures some of the session parameters:

Terminal-Type specifies a terminal type for the Telnet session, such as the vt100. Clear-Call specifies whether or not user termination of a Telnet session terminates the connection as well. Buffer-Chars determines whether the terminal server buffers input characters for 100 milliseconds before forwarding them to the host, or sends the characters as received.

In the Telnet-Options subprofile, Telnet-Mode specifies whether Binary, ASCII, or Transparent mode is the default for Telnet sessions. Auto-Telnet instructs the terminal server to interpret unknown command strings as the name of a host for a Telnet session. Local-Echo sets a global default for echoing characters locally. Users can change the echo setting within an individual Telnet session.

Authorizing PPP sessions from the terminal-server

Typically, PPP sessions are initiated by dial-in software, such as Netscape Navigator, Microsoft Explorer, or Windows 95 (which has a resident TCP/IP stack). The terminal-server software initially handles a call if it is from a modem or TA. However, after the terminal server detects a PPP packets from the caller, it passes the call on to the router, where it is handled as a regular PPP connection without entering a terminal-server interface.

If the user's dial-in software does not support PPP, the user can still initiate a PPP session from within the terminal-server software. To do so, a user could log into the terminal server in terminal mode and use the PPP command, or include the PPP command in an Expect-Send script; for example:

Following are the parameters related to authorizing PPP sessions initiated from the terminal-server software. The settings shown are the defaults.

For example, the following commands enable PPP sessions, and specify that the MAX TNT should start PPP negotiation immediately when the PPP command is executed:

You can use the Delay parameter to instruct the terminal server to transition to packet-mode processing after the specified number of seconds. By setting the Info parameter, you can specify that no message be displayed, or specify one of the following messages:

Authorizing SLIP sessions from the terminal-server

 Some applications require SLIP rather than PPP. The MAX TNT does not support a direct SLIP dial-in, because SLIP doesn't support authentication. However, if SLIP-Mode is enabled in the terminal server, users can initiate a SLIP session and then run an application such as FTP in that session. To initiate SLIP, the user must invoke a session from within the terminal-server software. To do so, a user could log into the terminal server in terminal mode and use the SLIP command, or include the SLIP command in an Expect-Send script; for example:

Following are the parameters related to authorizing SLIP sessions initiated from the terminal-server software. The settings shown are the defaults.

For example, the following commands authorize SLIP sessions and specify that the terminal server will respond to BootP in SLIP sessions:

The SLIP-BOOTP parameter enables the terminal server to respond to BootP within SLIP sessions. If it is set to Yes, an interactive user who initiates a SLIP session can get an IP address from the designated IP address pool via BootP. If the parameter is set to No, the terminal server does not run BootP. Instead, the system prompts the user to accept an IP address at the start of the SLIP session. By setting the Info parameter, you can specify that a default startup message will be displayed, or an advanced message that includes a subnet mask and IP gateway address.

Authorizing immediate mode access

In immediate mode, the terminal server does not display the command-line prompt or a menu of hosts. Instead, it uses TCP, Rlogin, or Telnet, as specified, to direct dial-in users immediately to a designated host. Following are the parameters required for setting up immediate mode. The settings shown are examples.

If the call uses PPP encapsulation, the normal course of events for the MAX TNT is to authenticate the call by means of PAP or CHAP and then use the router software to establish an async PPP session. To avoid redirection of the call and enable the user to log into the Telnet host instead, you must set the Telnet-Host-Auth parameter to Yes.

The following example shows how to enable immediate Telnet connections for async connections, including async PPP:

If the Service parameter is set to None, immediate mode is disabled. The other choices for establishing an immediate host connection for dial-in users are Telnet, Raw-TCP, or Rlogin.

The Host parameter specifies the hostname or address to which users will be connected in terminal server immediate mode. You can also specify a TCP port number to use for the connections.

The Telnet-Host-Auth parameter is related only to asynchronous PPP calls in immediate mode. If it is set to No, the calls fail. If it is set to Yes, the MAX TNT terminal server processes the calls and directs them to the Telnet host rather than to the unit's router software.

Authorizing menu mode access

In menu mode, the terminal server does not display the command-line prompt. Instead, it displays a menu from which a user can select a host with which to initiate a Telnet login. If you define the menu locally in the Menu-Mode-Options subprofile, it can display up to four host descriptions. If you define the menu in RADIUS, by means of the Ascend-Host-Info attribute, it can display up to ten host descriptions. (For details, see the MAX TNT RADIUS Guide.)

For details of setting up a password that is required for accessing the terminal server when menu mode is in use or when users toggle from menu-mode to terminal-mode, see How security mode affects terminal-server authentication of Appendix A, Access Security Settings.

Following are the parameters that enable you to describe up to four hosts that will be accessible to users in menu mode. The settings shown are the defaults.

If you set Start-With-Menus to Yes, the terminal server brings up the menu upon initial login. If the Toggle-Screen parameter is set to Yes, users can press 0 (the zero key) in the menu to toggle to the terminal-server command line. To configure menu mode to obtain the menu from RADIUS, set the Remote-Configuration parameter to Yes. The Text and Host parameters expect a text description and an IP address, respectively, of up to four hosts. The MAX TNT uses only the specified IP addresses to access the hosts.

The following commands configure the menu shown in Figure B-1, and specify that the menu should be displayed upon initial login:

With this configuration, the MAX TNT authenticates the user's login name and password, and then displays a text-based menu such as the one shown in Figure B-1:

Figure B-1. Terminal-server menu mode

Users can Telnet to the specified host by pressing 1, 2, 3, or 4, or can quit the menu by pressing Q. Quitting the menu terminates the connection. If the Toggle-Screen parameter were set to Yes, users could press 0 to exit menu mode and enter the terminal-server command line.

Restricting access to DNS information

Domain Name Service (DNS) is a TCP/IP service for centralized management of address resolution. Service providers can maintain multiple DNS servers, each one dedicated to a particular client or location. In that case, it might be important, for security reasons, to ensure that connections are always directed to the correct DNS service. With per-connection DNS access, a service provider can direct specific users to the DNS servers appropriate to their services or locations. (For information about configuring local DNS servers and options, see Chapter 4, IP Routing.)

What is client DNS?

Client DNS enables the MAX TNT to direct incoming connections to DNS servers belonging to particular locations or customers, and to prevent those users from accessing the local DNS servers. The addresses configured for client DNS servers are presented to WAN connections during IPCP negotiation.

Client DNS has two levels: a global configuration that applies to all PPP connections, which is defined in the IP-Global profile, and a connection-specific configuration that applies only to the WAN connection, which is defined in the Connection profile. The client DNS addresses configured in the IP-Global profile are used only if the caller's configured profile specifies no client servers.

Following are the parameters related to configuring client DNS (shown with their default values):

A connection can use one of the following DNS servers:

The MAX TNT uses the global addresses only if a Connection profile does not specify a server address, or if Client-DNS-Addr-Assign has been set to No. You can use the Client-DNS-Addr-Assign parameter to turn off client DNS for a connection without deleting its configuration.

Configuring client DNS servers at the system level

Following is an example of configuring client DNS servers at the system level:

The secondary server is accessed only if the primary one is inaccessible. If both client DNS servers in the IP-Global profile are not accessible and the caller's configured profile does not specify a connection-specific client DNS server, the MAX TNT can allow the client to access the local DNS servers, depending on the setting of the Allow-as-Client-DNS-Info parameter. Following is an example in which the administrator allows clients to access local DNS servers when client DNS servers are not found:

Setting connection-specific DNS parameters

 Following is an example in which an administrator sets up connection-specific DNS parameters:

The secondary server is accessed only if the primary one is inaccessible.

Restricting SNMP access

The MAX TNT supports SNMP on a TCP/IP network. An SNMP management station that uses the Ascend Enterprise MIB can query the MAX TNT, set parameters, sound alarms when certain conditions appear in the MAX TNT, and perform other management tasks.

An SNMP manager must be running on a host on the local IP network, and the MAX TNT must be able to find that host, via either a static route or RIP. In addition to these restrictions, the MAX TNT has its own SNMP password security (community strings), which you should set up to protect the MAX TNT from being reconfigured from an unauthorized SNMP station.

Overview of SNMP security

The SNMP profile contains SNMP-readable information related to the unit itself and to its SNMP security. There are two levels of security:

Following are the related parameters, which are shown with their default values:

Enabling SNMP in the MAX TNT

 If you leave the Enabled parameter in the SNMP profile set to No (the default), no SNMP utilities can access the MAX TNT. The following commands enable SNMP on a unit:

Note: The Contact and Location fields are SNMP readable and settable. They should indicate the person to contact about this unit and the unit's location, respectively.

Setting community strings

SNMP community strings set the administrative authorization policy for executing SNMP Set and Get commands from a management station. When the management station interacts with the MAX TNT, it must provide the proper community string to gain read access, and provide a separate community string to gain write access to the system's configuration.

Default community strings for read access (Read-Community) and read-write access (Read-Write-Community) are as follows:

The following commands assign a new, confidential Read-Write-Community string. This string will be required from an SNMP management station for the station to gain read-write access to the MAX TNT:

You can specify up to 32 characters in an SNMP community string.

Setting up and enforcing address security

If the Enforce-Address-Security parameter is set to No (its default value), any SNMP manager that presents the right community name will be allowed access. If it is set to Yes, the MAX TNT checks the source IP address of the SNMP manager and allows access only to those IP addresses listed in the Read-Access-Host and Write-Access-Host arrays. Each array can include up to five host addresses.

The following commands enforce address security and specifies a trusted address for both read and write access:

Preventing misuse of directed broadcasts

Denial-of-service attacks known as "smurf" attacks typically use ICMP Echo Request packets with a spoofed source address and the direction of packets to IP broadcast addresses. These attacks are intended to cause degraded network performance, possibly to the point that the network becomes unusable.

Disabling directed broadcasts

To prevent the MAX TNT router from being used as an intermediary in this type of denial-of-service attack that is launched from another network, you should disable the MAX TNT from forwarding directed broadcasts it receives from another network. The following example shows how to disable directed broadcasts that are not locally generated on all IP interfaces of a MAX TNT with a four-port Ethernet card in shelf 1, slot 12:

Ignoring ICMP Echo Requests to the broadcast address

 To prevent the MAX TNT router from being used in this type of denial-of-service attack when an attacker compromises another router on the same Ethernet as the MAX TNT, you need to prevent the MAX TNT itself from responding to directed-broadcast ICMP Echo Requests.

The following example shows how to configure the MAX TNT to ignore ICMP Echo Requests sent to the IP broadcast address:


[Top][Contents][Prev][Next][Last]Search

techpubs@eng.ascend.com

Copyright © 1998, Ascend Communications, Inc. All rights reserved.