Terminal Servers and Network Security
		
		     C.E. Bemis and Lynn Hyman
			December 12, 1990

	Network terminal servers provide a very useful function in
local area networks and we are most familiar with LAT (Local Area
Transport) type terminal servers.  Here, LAT refers to a LAN (Local
Area Network) protocol developed by Digital Equipment Corporation and
now is used by many vendors including Able Communications, Datability,
Emulex, Xyplex, Racal-Milgo and others.  LAT is designed to efficiently
concentrate terminal type traffic on a broadcasting medium like an
Ethernet.  The protocol does not have a network layer and as such, LAT
traffic is local.  Some vendors have developed a VAN (Value Added 
Network) feature for LAT where LAT packets can be routed encapsulated
in other routable protocols, IP for example, but the encapsulation is
proprietary to that vendor.  Cisco Systems, Network Systems and others
have developed and used "routable LAT" as a VAN feature.  It is 
noteworthy that the developers of LAT, Digital Equipment Corporation, do
not provide "routable LAT" because the protocol was designed to be a
Local Protocol to use the Ethernet efficiently with optimal sized data
packets up to the Ethernet maximum of 1518 bytes.

	The value of terminal servers are many and varied: 1. they 
concentrate terminal traffic for ethernet efficiency, 2. they provide
a mechanism referred to as "reverse LAT" where dumb devices like 
terminals, printers etc. may be attached to the Ethernet via a terminal
server, 3. they keep the backplane of computers clean of the many and
varied RS-232 type cables and connectors that are required for directly
attached dumb devices, 4. they provide a convienent connection for dial
in/out modems and 5. network security aspects are quite simple.

	LAT Servers, either for terminals, printers or whatever, may be
partitioned into various "LAT Groups", 255 total, which can serve as
a network partitioning mechanism.  By default, all LAT terminal servers
function in LAT Group 0.  Hosts, to which LAT servers are connected over
the Ethernet, may be set up to listen to particular LAT Group numbers 
and ignore all others.  LAT Services, host and Server alike, may also
use particular LAT Group numbers, for example a print service located
off one particular Server port, to partition a network.

	LAT terminal servers are easily managed, the TSM (Terminal 
Server Manager) software from DEC is an example, and the LAT devices
are easily secured with password access.  Passwords for priveleged
access, either over the network via LAT, over the network via a
Remote Console Connetion (MOPRC), or directly from an attached terminal
or other device, should always be set and protected like other 
priveleged functions that are Password protected.  Services defined on a
server may also be individually password protected, a password being
required for access into or out of a particular port on a server and
the password are defined on a service by service, or port by port basis.
Network security for servers is a LAN function, inside the broadcasting
medium only, because LAT never enters into or out of the local 
broadcasting network unless a proprietary VAN feature might be 
implemented.  If "routed LAT" has been implemented, it is usually a
point-to-point implementation between two routers.  Here the security
envelope has been extended to the remote location, but not to the
entire WAN, only to those routers from a specific vendor that 
participate in that set up of "routed LAT".

	Fairly recent changes in terminal servers have occured and the
complexity of the network security aspects has increased which may
pose some unrecognized risks.  Terminal servers are now offered that
communicate over X.25 networks via modems as well as communicating
on an ethernet; terminal servers are now offered that communicate via
the TCP/IP suite thus offering a Telnet server.  TCP/IP may be a part
of the server in addition to LAT, and/or in addition to X.25 access, all
in addition to the connection to the local ethernet or LAN.  It is easy
to see that the security envelope has been extended to the WAN, at least
as far as the X.25 network will reach, and as far as the IP network 
reaches.  The very nature of a terminal server, without an operating
system like a computer and without elaborate mechanisms to limit, audit
and otherwise provide a secure environment, is the reason for additional
concern.  Terminal servers, multiprotocol servers, are a favorite 
stepping stone for would be hackers and crackers because they provide
no audit trail.  Once on a server, your packets can then go anywhere
that the multiprotocol functions will let them.  For LAT, this is
local, for IP, this is anywhere IP can take them, LAN or WAN and,
similarly for X.25/X.129.  Multiprotocol terminal servers have been
implicated in many of the recent well publicised hacker/cracker episodes
and they continue to pose risks-- unless they are properly protected!!

	Of particular interest is the "firewall" protected network where
a router/gateway would separate the WAN from the local (LAN) environment.  
This arrangement is most useful for the control of WAN routing messages
which would never then enter the LAN environment, and for control of
WAN traffic by providing filter mechanisms.  Such filters might be
based on network addresses, IP or DECnet, by protocol or IP port/server,
or on other flags in incoming/outgoing packets.  Usually, such filter
mechanisms are inclusive, rather than exclusive, where everything is
allowed except those specifically identified and filtered.  Exclusive
filtering is network management intensive and unless the situation,
usually a paranoid one, warrants it, exclusive filtering is not widely
used. The massive application of inclusive filtering is usually not
performed either in an unclassified network environment and protection
is usually a host based function.  Terminal servers of the multiprotocol
type may easily defeat the most carefully designed network 
implementation and "firewall" implementations!!  Suppose you have LAT
hosts not permitted by any routable protocol to communicate to any
WAN host and your network design and possibly "firewall" inclusive
filtering would prevent it.  A bypass, where incoming/outgoing traffic,
in a step-stone fashion via your multiprotocol terminal server can 
defeat your implementation.  An outsider, otherwise not permitted to
communicate via any mechanism with certain of your internal hosts may
simply set up a session on a multiprotocol server, usually not protected
like full function computers, and complete the connection.

	What to do ?--
Network access, in contrast to direct physical Port based access, must be
protected on multiprotocol terminal servers!!  Usually, IP terminal
servers implement a "virtual" Telnet server on virtual port 2048.  I 
have seen this implementation on two different vendors servers. This
feature is usually not even noticed by the installer.  Once on the
server via a Telnet connect to "virtual port" 2048, a user may enter
the default access password and gain access to all the services and
connections that any non-priv'd direct user of the server would normally
have access to. In some cases, on servers that I have noticed, network
access may even allow priv'd access just by using the default.  Audit
features/trails are not possible, security and network implementations
are bypassed.  Use the mechanisms inherent on each of the various
manufacturers multiprotocol servers, and the mechanisms are different
on each manufacturers server, to Password protect the server from
network access.  Certain manufacturers servers, depending on the
software revision level, offer no protection at all!!!

Seriously consider restricting multi-protocol terminal servers from any
WAN access if the need for direct WAN access is not needed.  Why use a
terminal server when a REAL host can be used with all the bells and 
whistles like a real operating system, audit trails, security features
etc.  WAN restrictions on multi-protocol terminal servers may be
accomplished by an IP address filter on a site firewall router.  Some
servers may allow the use of IP address masks directly on the server.
Servers may also be configured without any default metwork gateway
being defined which would then allow the server to only be used in
its own broadcasting environment.  In this case, the server has no
knowledge, nor can it "learn", anything about routes to hosts not
part of its broadcasting domain.


	Last corrected/modified by C.E. Bemis, Jr., 12/7/89@8:00AM EDT