Using the Small Servers | Router Management

Problem

You want to enable or disable router services like finger, echo, and chargen.

Solution

The finger application provides a remote way of seeing who is logged into the router. You can enable it with the ip finger global configuration command:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#ip finger
Router1#

Every Cisco router also has a set of small TCP and UDP server applications that are sometimes useful for test purposes:

Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#service tcp-small-servers
Router1(config)#service udp-small-servers
Router1(config)#end
Router1#

Discussion

The finger command is a simple utility that allows you to do the equivalent of a show users command on a remote router. Unix computers generally have a standard finger program that you can run as follows:

Freebsd% finger @Router1
[Router1]

 Line User Host(s) Idle Location
 66 vty 0 kdooley idle 00:22:47 freebsd
 67 vty 1 ijbrown idle 1d07h freebsd
* 68 vty 2 idle 00:00:00 freebsd

 Interface User Mode Idle Peer Address

Freebsd%

But you can also use the Telnet program, and connect to TCP port 79 to access the finger server as well. You can do this from another router, for example:

Router2#telnet 10.1.1.2 finger
Trying 10.1.1.2, 79 ... Open

 Line User Host(s) Idle Location
 66 vty 0 kdooley idle 00:24:14 freebsd
 67 vty 1 ijbrown idle 1d07h freebsd
* 67 vty 1 idle 00:00:00 10.2.2.2

 Interface User Mode Idle Peer Address


[Connection to 10.1.1.2 closed by foreign host]
Router2#

Notice that in both cases the output includes not only the active users, but also the finger process itself, which is indicated as the line with the asterisk.

The finger protocol is defined in RFC 1288. It is disabled by default on Cisco routers. While this can be convenient to see who is logged in to a remote router without having to log in to check, it also can represent a serious security problem. Not only does it display a set of valid login IDs, which can be used to focus an attack, but it consumes a VTY line on the router, which can prevent legitimate access if done persistently. The finger protocol also has a checkered history. A bug in the original finger implementation was one of the methods used by the first great viral attack to shut down large sections of the Internet (the infamous Morris Worm).

For all of these reasons, we strongly recommend you keep this protocol disabled on all of your routers. If it has been enabled for any reason, you can disable it as follows:

Router1(config)#no ip finger

We should also note in passing that the ip finger command replaces the earlier service finger command, which you will find in many references:

Router1(config)#service finger

If you use this deprecated version of the command, the router will automatically replace it with the newer command.

Cisco routers also support a set of simple TCP and UDP applications that are relatively common standards for IP devices. In IOS levels 12.0 and higher, the TCP and UDP small servers are disabled by default, and you must enable them if you wish to use them. In earlier IOS levels, they are enabled by default.

In general, we find that the small servers are only marginally useful, and we recommend disabling them when you are not actively using them for testing purposes. These servers listen for incoming packets from any source. There have been network denial of service attacks based on these servers. Usually the attacks simply exploit the fact that the TCP servers in particular will accept a connection from any device that requests one. If a hostile user sends a stream of TCP SYN packets to one of these ports, the router will have to respond to it and devote internal resources to keeping the session active. This can use up router resources.

The UDP servers are also potentially dangerous because a hostile user can spoof the source address in the packet to force your router to send a barrage of response packets to a third party. A similar attack could potentially be launched using the TCP servers, because the router will respond to any TCP SYN packet with a SYN ACK. Another network device could find itself unable to cope with receiving a barrage of unsolicited SYN ACK packets.

Therefore, we recommend disabling these services except when you specifically need to use one of them:

Router1(config)#no service tcp-small-servers
Router1(config)#no service udp-small-servers

However, with these cautions, the small servers do have legitimate uses.

The TCP and UDP small servers are shown in Table 2-2. The router implements both TCP and UDP based versions of each of these server functions, on the same port numbers. These are all well-known ports and commonly implemented applications. They are usually used for testing purposes.

Table 2-2. TCP and UDP small servers
Port number	Common name	RFC	Description
7	Echo	RFC 862	The server process responds to any client input by sending back the identical input.
9	Discard	RFC 863	The server process discards any data sent by the client.
13	Daytime	RFC 867	The server responds with the current time and date, and then closes the session.
19	Chargen	RFC 864	The server sends a constant stream of ASCII characters to the client.

The easiest way to explain what these functions do is to simply try them. The TCP versions are easier to demonstrate because you can use the standard Telnet application, and just tell it to connect to a different TCP port number.

The echo function just responds to whatever you type by sending back the same data:

Freebsd% telnet Router1 echo
Trying 172.25.25.1...
Connected to Router1.
Escape character is '^]'.
It gives a very echo to the seat where love is thron'd
It gives a very echo to the seat where love is thron'd
^]
telnet> quit
Connection closed.
Freebsd%

In its UDP version, the echo function merely copies the data segment of the packet and returns it to the sender.

The discard function is considerably less useful. The TCP version allows the client to establish a TCP session with the server, and then ignores everything you send it:

Freebsd% telnet Router1 discard
Trying 172.25.25.1...
Connected to Router1.
Escape character is '^]'.
Go off; I discard you: let me enjoy my private; go off.
^]
telnet> quit
Connection closed.
Freebsd%

The UDP version of this application listens for packets on UDP port number 9 and ignores them. It doesn't respond in any way to these packets.

The TCP version of the daytime server accepts a connection request, then immediately sends a packet containing the current time and date in ASCII format, and disconnects the session:

Freebsd% telnet Router1 daytime
Trying 172.25.25.1...
Connected to Router1.
Escape character is '^]'.
Sunday, January 5, 2003 17:41:21-EST
Connection closed by foreign host.
Freebsd%

The UDP daytime server listens on UDP port number 13 and responds with a single packet containing the same ASCII time data as the TCP version. The daytime server is marginally useful for checking a clock, but other applications such as NTP are much more robust if you actually want to configure a reliable time service. We discuss NTP in Chapter 14.

The Character Generation ( chargen) function is probably the most useful of the TCP small servers. As soon as you make a connection to this port number, the router will start sending a continuous stream of data back to the client. We have often used this feature as a sort of poor man's traffic generator to investigate network loading issues:

Freebsd% telnet Router1 chargen
Trying 172.25.25.1...
Connected to Router1.
Escape character is '^]'.
!"#$%&'( )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_Qabcdefg
!"#$%&'( )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_Qabcdefgh
"#$%&'( )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_Qabcdefghi
#$%&'( )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_Qabcdefghij
$%&'( )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_Qabcdefghijk
%&'( )*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_Qabcdefghijkl

^]
telnet> quit
Connection closed.
Freebsd%

The UDP version of the chargen server listens for a UDP packet on the well-known port number 19, and then generates a single response packet back to the sender. This response packet contains a random number between 0 and 512 bytes of arbitrary character data.