Written by: Peder Sverdrup, January 2013Contents
- 1. Introduction
- 2. The XP Telnet server and client
- 3. Telnet on the LAN
- 4. Telnet on the WAN
- 5. Remote configuration with sc.exe
- 6. Other Telnet clients
- 6.1 Hyperterminal
- 7. Other Telnet servers
- 8. References
- Fig. 1 Wireshark, Telnet login using simple user/password
- Fig. 2 NTLM, with admin user odd
- Fig. 3 NTLM, with admin user billyboy
- Fig. 4 NTLM, with limited user oddlim, member of TelnetClients
- Fig. 5 NTLM, with limited user oddlim, not member of TelnetClients
Telnet is client-server software to access and control a remote machine (the server). During a Telnet session, the client machine receives a command interpreter window from the server machine. Depending on user rights, the client can read, write and execute commands on the server. There is no graphics or mouse interaction. Telnet is an alternative to Remote Desktop (which has graphics and mouse interaction). In mixed environments, with several different operating systems, Telnet is especially useful: a UNIX client can usually connect to a windows server, etc. Telnet uses less resources than other remote management tools, because there is no graphics and no encryption. A client and server often comes with the operating system, so usually no need to install extra software.
Windows XP Professional comes with both a Telnet server and a Telnet client. Our lab consists of several Windows XP machines, and we will explore how Telnet works when connecting these machines under different network conditions.
- The Telnet protocol is specified in RFC 854.
- Telnet does no encryption of data. Which means there are security considerations involved.
- Telnet uses the TCP/IP network protocol. TCP port 23 is reserved for Telnet client-server communication. If your machine does not have TCP/IP installed, neither the Telnet server nor the client will work.
- The server listens by default on port 23. The default port number can be changed in the registry,
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\TelnetServer\1.0\TelnetPort. Many other characteristics can also be manipulated here.
- Several XP executables (path:
%WINDIR%\system32\) are associated with Telnet:
- tlntsvr.exe The server executable, runs as an XP service. By default, for security reasons, it is not turned on.
- tlntadmn.exe, sc.exe, net.exe For server administration.
- telnet.exe The client executable. It opens its own command interpreter window.
- Several Microsoft .cpl and .msc applets are useful in administering Telnet (the applet GUIs can be opened from the Run command interpreter, input the full name of the applet):
- nusrmgr.cpl To administer the local Windows users.
- services.msc To administer services, particularly the Telnet server service.
- lusrmgr.msc On the server: to administer the TelnetClients group.
- secpol.msc On the server: determines privileges for remote users logging in using local accounts (Security Settings - Local Policies - Security Options - Network access: sharing and security model for local accounts). This is relevant only when using NTLM authentication.
- firewall.cpl On the server: to administer the Windows firewall.
- Windows XP has several different account types, with different local and Telnet privileges:
- Authentication: with this term we mean how the server can determine who is trying to log on. There are two Telnet authentication methods:
- User/Password User/password is transmitted unencrypted.
- NTLN No unencrypted transmission of password.
Setup: two Windows XP Professional 32-bit machines, on the same LAN. There is no windows network domain, and they are not in the same workgroup. In my setup, the client has IP 10.0.0.10, and machine name (NetBIOS): plutotech. The server has IP 10.0.0.11, and machine name: oes.
In my setup the client has an english XP Pro version, the server has a norwegian XP Pro version. I assume this difference in OS language does not influence this demonstration.
Initially, we want the configuration of the server and the client to be "vanilla", that is, unchanged with respect to how it comes with a new XP install.
You need to be Administrator on the server to change configuration. At your server, open the XP command interpreter (
cmd). We use the command-line programs
net to configure the server. To get help, you can for instance do
net help or
sc is short for ServiCes (or Service Configuration?), and
qc is short for Query Configuration.
We want the server to be started manually (not automatically on machine boot, because of security), and we do not want it to be disabled. Query server configuration with:
sc qc tlntsvr
Check that START_TYPE is set to 3 (Demand). If not, change the setting with the command
sc config tlntsvr start= demand
(There is a space after the =).
Check further server configuration with:
The server should be listening on port 23. Both Password and NTLM should be allowed for logon authentication. If any of these settings are missing, they can be corrected with:
tlntadmn config port = 23
tlntadmn config sec = +NTLM
tlntadmn config sec = +passwd
If the server is not running (State is Stopped), manually start the server:
sc start tlntsvr
tlntadmn start, or:
net start tlntsvr, or:
net start telnet, or start the server from services.msc in the Control Panel. Two more commands to check server status:
sc query tlntsvr and
sc queryex tlntsvr.
I now have the following configuration:
C:\Documents and Settings\odd>tlntadmn
The following are the settings on localhost
Alt Key Mapped to 'CTRL+A' : YES
Idle session timeout : 1 hours
Max connections : 2
Telnet port : 23
Max failed login attempts : 3
End tasks on disconnect : YES
Mode of Operation : Console
Authentication Mechanism : NTLM, Password
Default Domain : OES
State : Running
C:\Documents and Settings\odd>
We now need to configure the Windows firewall.
- Open up port 23. Or:
- Make an exception for tlntsvr.exe.
On your client machine, start the client (telnet.exe) from Run. Alternatively, you can open a command interpreter and run the client from there. In both cases, you end up with a Telnet command prompt (the Telnet client has its own command interpreter). To get help in this window, type
Type d to check the client configuration (operating parameters):
Microsoft Telnet> d
Escape Character is 'CTRL+"'
Will auth(NTLM Authentication)
Local echo off
New line mode - Causes return key to send CR & LF
Current mode: Console
Will term type
Preferred term type is ANSI
We see that the client is able to use NTLM authentication. If it were not, do:
tlntadmn config sec=+NTML
We are now ready to log into the server. We are going to see that with both simple user/password authentication, and with NTLM authentication, we log in with the credentials of a valid server Windows account. However, there are differences in how the credentials are entered, and transmitted over the network.
On your client machine, start the client (telnet.exe) from Run. Type o to Open a telnet connection:
Enter the server IP (or the machine name).
You are about to send your password information to a remote
computer in Internet zone. This might not be safe. Do you
want to send anyway(y/n):
Answer y. You will get a message:
Access Denied: Specified user is not a member of TelnetClients group.
Server administrator must add this user to the above group.
Telnet Server has closed the connection
Connection to host lost.
Press any key to continue...
Now try again, this time answer n. You will then be asked for a username and password:
Welcome to Microsoft Telnet Service
For now, not worrying about security, log in with user/pass for an Administrator user on the server. You should get logged in and receive a command interpreter for the server.
Welcome to Microsoft Telnet Server.
C:\Documents and Settings\odd>
So, what is happening here? With Telnet, you can choose between two different ways of authenticating:
- Simple user/password authentication without encryption. Both user and password is sent in plaintext over the network. The client authenticates by entering
- User/pass for an Administrator account on the server machine.
- User/pass for a limited account on the server machine, only if this server account is member of the group TelnetClients (check lusrmgr.msc).
- NTLM (New Technology Lan Man) authentication. With this method, the password is never transmitted in plain text over the network. No username or password is entered from the keyboard. Telnet uses the credentials (meaning: username and password) of the Windows user at the client machine, to log into the Telnet server. This means that the client Windows account, must have its twin-account (same username and password) on the server, for login to be possible. The following rules apply:
- On the server, the Local Security Settings (secpol.msc): Security Settings - Local Policies - Security Options - Network access: sharing and security model for local accounts. The tab Local Security Settings has two options: Classic - local users authenticate as themselves, and Guest only - local users authenticate as Guest. To get access to a running Telnet server, one needs to choose the Classic option. Because Guests do not get Telnet access.
- A client administrator account can log into a server administrator account.
- A client administrator account can log into a server limited account, only if the server account is member of TelnetClients group.
- A client limited account can not log into a server administrator account.
- A client limited account can log into a server limited account, only if the server account is member of TelnetClients group.
Now we will try to explain the login process just witnessed. When answering y to the question, one chooses NTLM. The following error message occurs because the client Windows account had no twin on the server, and/or the Local Security Settings were misconfigured. Then, when one answers n, one chooses simple user/password login. This mechanism is simpler and less secure. When the client is configured to use both NTLM and user/pass, NTLM is tried first. If NTLM does not succeed, the client tries user/pass.
Wireshark is a program that reads individual data packets off your network card, and lets you view their raw contents. Wireshark also has advanced packet analysis tools for many different protocols, including TCP/IP and Telnet. Installed on the client machine, Wireshark monitors all packets entering and leaving the computer. When telneting to another machine, Telnet packets show up. By reading individual packets, and then collocating -- "Follow TCP Stream" in Wireshark -- it is possible to analyze the information flow. We will try to get some insight into how Telnet authentication works.
The server has an administrator account with the username "odd" and the password "kampen", and these are the credentials we will use to gain access. The server machine name is "plutotech".
Figure 1 shows Wireshark when logging in with simple user/password. It is clear that:
- Both username and password is transmitted unencrypted.
- Login-credentials are transmitted character-by-character, as they are typed. So when transmitting the username "odd", the "o" is sent on the wire as soon as it is typed on the computer, in its own Telnet packet. Then the "o" is actually returned from the server to the client. Same with the two "d"'s. This is why we see "oodddd" in Wireshark.
- Also the password is sent character-by-character. It is not returned.
Fig. 1 Wireshark, Telnet login using simple user/password
- Only username "odd" and the client computername "plutotech" are transmitted unencrypted. The password is encrypted or not transmitted.
- With NTLM no username or password is entered from the keyboard. The credentials of the active Windows account on the client machine is used for login. The username and the computername is sent in one single Telnet packet.
- It seems like the password is not transmitted at all. Figures 2, 3, 4, and 5 show login with different usernames/passwords, and account privileges. It is beyond this paper to give a further analysis of the NTLM security scheme, rather see Davenport, .
- It is conspicuous that there is no option to enter the username and password from the keyboard. This suggests that the password is never transmitted (not even in encrypted form).
Fig. 2 NTLM, with admin user odd
Fig. 3 NTLM, with admin user billyboy
Fig. 4 NTLM, with limited user oddlim, member of TelnetClients.
Fig. 5 NTLM, with limited user oddlim, not member of TelnetClients.
So far the server and the client have been on the same Local Area Network. We will now see how Telnet works when this is not the case. The lab now consists of two geographically separate locations:
- Aurskog: the server location.
- Vinterbro: the client location.
- It is possible to configure the Aurskog router with Telnet, and the router server listens on port 23. Therefore, in order to reach the Telnet server on the XP machine, we need to change the Telnet port. Any free port can be used. In this example, we set the Telnet server to listen at port 1006.
- Windows firewall on the server: open up port 1006, or make an exception for tlntsvr.exe.
- NAT (Port Forwarding) on the Aurskog router: forward port 1006 to IP 10.0.0.6 (this is the server).
- Aurskog router firewall should be open on port 1006. Depending on the router model, this is done automatically once the NAT is configured. If not, you need to do it manually.
- Check that the server can do NTLM authorization.
- Start the Telnet server.
You should now be able to log into the Telnet server by using the Aurskog router WAN address and the port 1006. Remember that to authenticate with NTLM, your active account needs to have a twin-account on the server (it could be any server account, it does not have to be the account from which you started the Telnet server). If the Aurskog router has a dynamic IP address, and the router supports dyndns, you might want to sign up for a free account, and use you dyndns hostname instead of the router IP.
Windows XP is primarily a workstation, not a server, so server software may be a bit buggy. If you are not able to start the Telnet server, you may try to reboot your machine.
So far in this paper it has been assumed that one has local access, or local access via Remote Desktop, to all the machines, when using sc.exe to configure. Here we will look at the possibility of directly using the configuration program sc.exe to configure a remote machine.
We would for instance like to run commands lik:
sc \\10.0.0.11 query tlntsvr
sc \\oes query tlntsvr
We want to sit at the client machine when running such commands.
When the client and server machines are on the same LAN, this is easy:
- One initial observation is that sc.exe does not provide any possibility to enter a username and password. Therefore one would suspect that sc.exe authenticates with NTLM. And indeed, for it to work, the client account that you are logged into needs to have its twin account on the server (same user and password). Just like NTLM.
- We have to open the Windows firewall on the server on TCP ports 139 and 445. If "File and Printer Sharing" is already an exception in the firewall, these ports are already open, because this service uses TCP 139 and 445 (and UDP 137 and 138).
- Remotely logged in users have to authenticate as them selves (secpol.msc).
- To query the local machine:
sq query tlntsvr. To query a remote machine on the LAN:
sc \\10.0.0.11 query tlntsvr, or
sc \\oes query tlntsvr.
We have been trying to set up a connection where we can reach a computer on the WAN with sc.exe. However, we are not able to make this work. When trying to reach the Aurskog computer with sc.exe from the Vinterbro computer, we can see traces of the attemt in the Aurskog ruter log. We are not able to observe the attemt at the Aurskog computer. One problem is that sc.exe varies the ports it uses to connect to the Aurskog router. It does not use one fixed port. Which makes it difficult to know which ports to forward to the Aurskog computer.
From a bit of web research, it seems like the XP sc.exe version can not be used for connections outside the LAN. However, we are not 100% sure of this.
Further topics to research this:
- sc.exe and RPC (Remote Procedure Call)
- IPC (Inter Process Communication) connection
- The NET and NET USE commands
http://serverfault.com/questions/104365/controlling-services-on-another-computer. Just for completeness here, if you want to do this with only stock Windows tools you can first establish an IPC connection to the remote machine (to establish a security token on that machine) and then use the "SC" command:
net use \\remote\IPC$ /user:local-username-on-remote-machine password
sc \\remote stop service-name
net use \\remote\IPC$ /delete
You can use the Windows program Hyperterminal as your Telnet client. To connect from the command line:
C:\>"c:\Program Files\Windows NT\hypertrm.exe" /t url:port
C:\>"c:\Program Files\Windows NT\hypertrm.exe" /t ip:port
- Hyperterminal seems to not support NTLM. Even when we try to log in from a twin account, it asks for user and password.
- Making a connection from the GUI does not work. We tried to connect at port 1006, but we could not make it work. When we afterwards check the properties of the connection, the port is set to 700. So it seems like the program automatically changes the port to 700.
- Working from the GUI, we are not able to transfer files. We tried to transfer a simple Notepad text file, but could not make it work.
Fig. 6 Hyperterminal
To configure a Cisco router with the IOS, one typically logs into the device with Telnet. Many other routers also have similar capabilities, however with OS that is less configurable, and less adapted to command-line configuration.
- How Telnet works
- Configure the TCP Port Number Used by Telnet Server
- Configure the Telnet Terminal Type
- Switch Between Session Mode and Command Mode
- The NTLM Authentication Protocol and Security Support Provider