Remote Management Services


The most common method of accessing a server or configuring its layered application is through the Console GUI. This is mostly done at install time when the machine is first configured. After a server has been moved to a production environment, for purposes other than switching backup media, it is not usually acceptable to allow physical access to the machine. To resolve this problem, a method for providing external access to the server is required. The following sections review a number of alternatives for allowing remote access to a system.

Telnet

In the past, access to computer systems was granted by hard-wiring a terminal device to a server. These devices, commonly known as dumb terminals, would allow for rudimentary character-based access. As systems evolved and networks became more prevalent, this terminal access mode was ported to a network-aware application. The result was called a terminal emulator, and the protocol it used, for the most part, was Telnet.

The Telnet protocol uses TCP port 23 for conversations between the user's system and the target server. When it is invoked and a conversation is established, the user is presented with a username and login prompt. After the user is authenticated, a login shell is created for the user based on information contained in /etc/passwd.

The Telnet service is part of xinetd. You can enable the service by editing /etc/xinetd.d/telnet and changing the disabled flag to no. This is what the Telnet file should look like in a live environment:

 service telnet {         socket_type   = stream         protocol      = tcp         wait          = no         user          = root         server        = /usr/sbin/in.telnetd         disable       = no } 

The drawback to the Telnet protocol can be found in the way the packets are sent to the target server. In Telnet, there is no provisioning for protecting the information contained within each packet as it traverses the network. As information is entered in the terminal session, it is broadcasted in cleartext across the network. This includes the original authentication steps, allowing a network eavesdropper to intercept the traffic and collect usernames, passwords, and other sensitive information passed during the conversation. For this reason, the Telnet protocol is considered inappropriate for use.

ssh

A replacement method for accessing servers can be found in an application called Secure Shell (ssh). This protocol communicates over TCP port 22. This application establishes a link between the host and the destination computer, exchanges a series of cryptographic keys, and establishes an encrypted channel between the two machines. This channel is then used to create a login shell for the user. Because the channel is encrypted, the user's data, such as username, password, and so on, is protected from network sniffing. The user can then proceed with system maintenance tasks such as resetting passwords and editing system configuration files, knowing that any information exchanged is secure.

You start sshd as a standalone application through /etc/init.d and configure it through files contained within /etc/ssh. You can initiate the sshd service at boot time by using the YaST Runlevel Editor (System, Runlevel Editor). Figure 8.9 shows the service as enabled at boot time.

Figure 8.9. Adding sshd to run at boot.


You can connect to a host through ssh using the syntax shown here:

 Athena> ssh -l eric Hermes.UniversalExport.ca 

In this example, the -l option is used to specify the login account at the remote end. Without this option, ssh will use the account name associated with the current session to connect. Once you are connected, an encrypted session is established between the hosts. After an exchange of cryptographic information, you will be asked for the password of the remote account. Once the password has been verified, you will have an encrypted terminal connection. Later in this chapter, you will learn how ssh connections can be turned into tunnels for encrypting insecure protocols between hosts.

VNC and XDMCP

Often, it is desirable to run the GUI version of a configuration tool. On systems running the X Windows System environment, two methods are available to provide remote GUI access: VNC and XDMCP.

The Virtual Network Computing (VNC) application provides remote access to an existing GUI desktop. The default install of SLES disables remote management. To permit external users to connect to a server through VNC, you must perform the following configuration steps:

1.

Start YaST/YaST2.

2.

Choose Network Services.

3.

Choose Remote Administration.

4.

Select Allow Remote Administration.

5.

Restart the display manager.

6.

Modify firewall settings appropriately.

WARNING

Beware of the unexpected runlevel switch.

When Allow Remote Administration is selected, you will be prompted to issue the rcxdm restart command. Doing so results in the machine switching to runlevel 3. A more gentle way of restarting the display manager would be to log off and on again from the GUI console or issue a reboot command.


The last step involves modifying the firewall. By default, VNC client packages communicate to the server over port 5901. If the client will be connecting from VNC client, this port will have to be opened on the firewall. The version of VNC server bundled with SLES also provides for HTTP/Java connections from client web browsers. By default, VNC provides for HTTP access over port 5801. Enabling this port on the firewall permits access to a Java-capable, browser-based VNC client. The URL for the VNC client would be http://target_machine:5801. In our case, this would be

http://Hermes.UniversalExport.ca:5801

Both the VNC client and HTTP VNC client are representations of a desktop. It is possible to modify the screen geometry to suit your needs. By default, the geometry is set to a resolution of 1024x768. You can change this setting by modifying the /etc/xinetd.d/vnc configuration file. VNC is also capable of offering, on distinct TCP ports, different default screen resolutions. Examples of these resolutions can be toggled on or off by changing the disabled flag from yes to no in the configuration file. The appropriate firewall changes are also required.

XDMCP is the X Display Manager Control Protocol. Whereas VNC represents a virtual desktop, XDMCP allows for a fully functioning desktop to be run on a remote machine. This is often used in environments where X-based terminal sessions are required. The Linux Terminal Services Project uses XDMCP to provide X-based resources to lower-end PCs. Additionally, other platforms that do not support the X Windows System natively can run third-party software and allow them to run an X Windows System desktop. If you enable Remote Administration, XDMCP is enabled alongside VNC. Unlike VNC, however, the firewall configuration changes required for XDMCP to operate properly are significantly more complex. XDMCP requires manual changes to the firewall setting to allow UDP traffic to flowsomething the YaST firewall configuration utility does not permit natively.

NOTE

For more information on VNC, you can visit the project home page at

http://www.uk.research.att.com/archive/vnc/index.html

Other sites discussing the configuration of VNC include

http://www.softpanorama.org/Xwindows/vnc.shtml

http://www.uk.research.att.com/archive/vnc/sshvnc.html

http://gentoo-wiki.com/HOWTO_Xvnc_terminal_server


Securing System Management Conversations

It is important to secure the communications channel used to make modifications to a server. If this is not done, someone on a network could intercept traffic flow and read the transmitted packets. This form of wiretapping could reveal passwords as well as a number of system configuration parameters that could be exploited.

We have seen that it is more prudent to use a protocol such as ssh over the unencrypted Telnet protocol. The GUI System Management options VNC and XDMCP both transmit their information in cleartext. This means that someone with enough patience would be able to intercept a conversation and reconstruct a session to the point of being able to extract the same information vulnerable under Telnet. It is therefore imperative to secure this link if possible.

To secure links, you can look at additional functionality available through the ssh program. ssh is capable of making an encrypted terminal session to a host as well as create an encrypted tunnel to a host. Over this encrypted tunnel, it is possible to run nonsecure protocols safely. You do this by using the -L option of the ssh command. This turns on mapping of a port on the local machine through the secure tunnel to a port on the target machine. As an example, a user on Athena can create an encrypted tunnel to Hermes for use with VNC by typing

 Athena> ssh -L 5902:localhost:5901 Hermes.UniversalExport.ca 

This command maps any connections to port 5902 on the localhostin this case, Athenathrough the encrypted tunnel to port 5901 on Hermes. When the command is executed, an ssh session to the remote host (Hermes) will be created using the currently active username. If the remote username is different, the -l switch will have to be used to supply the appropriate username. The user will then be prompted for the password for the account on the remote node. When the connection is successful, a shell will be created on the remote machine. This shell must be maintained because it supports the tunnel session.

NOTE

You can also configure your system to support what is known as X forwarding. You can do this by including the -X switch on your ssh command, followed by the X Windows System application you want to run on the remote system.


To run an encrypted VNC connection to Hermes from Athena, the user then executes a VNC session pointing to the port on the local machine representing the local end of the tunnelin this case, port 5902as follows:

 Athena> vncviewer -encodings "copyrect hextile" localhost:5902 

The local host will recognize the local port as one end of a tunnel and will forward all subsequent packets through the tunnel to port 5901 on the remote end, establishing a secure VNC session. The encoding parameters are used to alter the VNC conversation to tune the information flow between the client and the server, thus enhancing performance.

One direct benefit of this method is to reduce the number of exposed ports on the firewall. Because all communications with the remote host happen through the encrypted tunnel, the conversation is pure ssh traffic and requires only port 22. All the other ports required for VNC can be closed on the target host, masking the availability of VNC altogether. The other advantage is that VNC becomes available only to already-authenticated clients because they had to establish the tunnel in the first place. The only drawback is that a user must authenticate to create the tunnel and then again for the VNC logon screen.

NOTE

ssh tunnels are a great way of securing connections to machines and applications that, by design, do not support encrypted links.

If you think of IMAP or POP, most servers support these through their SSL equivalents. Database traffic, in most cases, is not encrypted. Using this method, you can tunnel your MySQL traffic from your application server to your database server, and the traffic will be transparently encrypted over the wire.


Restricting Connections by IP Address

By definition, servers offer applications to users. In some instances, these applications are accessed remotely over the network through an established port. To reduce the exposure of these services to attacks, it would be beneficial if you could restrict who is allowed to establish a connection. Exchanging authentication credentials is not a complete solution because it is dependent on a pre-existing connection. What is required, therefore, is a method to prevent connections from all but specific clients.

The xinetd super-server allows for the control of the source addresses that are permitted to use xinetd resources. In the default case, it accepts connections from any source IP address. The xinetd configuration file, /etc/xinetd.conf, contains a line that describes valid sources for connections. By default, it is a comment line. If you uncomment the only_from line in the /etc/xinetd.conf file, you can supply a list of IP addresses for valid client machines. In a server environment, this approach is feasible because server addresses are typically static. Placing unique addresses from a DHCP pool in this section could lead to exposing the services to unintended clients.

The following is an excerpt of the xinetd.conf file.

 defaults {         log_type        = FILE /var/log/xinetd.log         log_on_success  = HOST EXIT DURATION         log_on_failure  = HOST ATTEMPT #       only_from      = localhost         instances       = 30         cps             = 50 10 #       interface       = 127.0.0.1 } 

Changing the only_from line to remove the comment symbol (#) and replacing localhost with a specific list of addresses will restrict all traffic for xinetd to those addresses. Further granularity can be achieved by placing the only_from line in the application-specific configuration file in the /etc/xinetd.d directory. Using this approach, you can allow ssh traffic to a list of hosts while allowing VNC traffic from a different list.

The xinetd restriction on IP further reduces the exposure of version harvesting for other utilities such as sftp, echo, and telnet. Because some versions of applications are known to have vulnerabilities, restricting connectionsand hence the display of any banner informationreduces the chance of an unwanted machine mining services for information.

In the case of VNC, you could reopen port 5801 on the firewall. With xinetd, you can then grant access to unique static IP addresses for selected machines. You would then be able to offer VNC over HTTP to these specific clients.

A Secure System Management Environment

In the previous sections, you saw several different methods for accessing a server to perform system management tasks. Because of the sensitivity of the information typically used in system management, encrypted channels are mandatory.

The ssh command was used to create a secure channel through which normally insecure VNC could be used. This allows the system administrator to exploit the benefits of the GUI interface without compromising the security of the session. We also examined how to restrict access to the xinetd family of services to specific IP addresses. In a properly switched environment, such restrictions could be used to allow VNC and XDMCP access to specific workstations.

The secure access methods discussed here can be used to facilitate system management and reduce the number of people requiring physical access to the servers themselves.



    SUSE LINUX Enterprise Server 9 Administrator's Handbook
    SUSE LINUX Enterprise Server 9 Administrators Handbook
    ISBN: 067232735X
    EAN: 2147483647
    Year: 2003
    Pages: 134

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net