Using the Small Servers
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.
| 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.