Useless Services

Useless services

Useless Services

Like a vestigial tail, there are often applications running on our machines that no longer serve any useful purpose. These services may be part of an earlier set of libraries that the programmers built on and never bothered to take out. This is one of the downsides of ever-increasing processing power and memory capacity. Programmers used to carefully ration every byte they used and would never allow unnecessary lines in their code. However, in this age of bloatware and gigabyte-sized operating systems, it is often easier to leave legacy services in rather than risk breaking some other program that depends on them. The incredible thing is that these services are often turned on by default. Here is a list of some of those services:

Useless Services in Linux

Services Common Port Numbers Functions
chargen 19 Sends a stream of standard characters when polled. Not only isn’t this service used anymore, but it can be used to generate a denial of service (DoS) attack by having it continually spit out character streams.
daytime 13 Returns the time of day. Not really needed of any modern system functions.
discard 9 Discards whatever is sent to it silently. Mainly used for testing purposes.
echo 7 Replies back with whatever was sent to it. Like chargen, echo can be used in DoS attacks by sending it a steady stream of data to echo.
finger 79 Much has been said about this service. [Consider, for example, the original Internet worm, released by Robert Morris in 1988, which exploited a buffer overflow bug in the finger program and propagated itself from one machine to another.] Very useful to hackers.
qotd (quote of the day) 17 Sends out a little quote or phrase that the system administrator sets up when you log in.


If you are running Windows, there are other services you will probably want to disable. Here is a partial listing of those useless services:

Useless Windows in Windows

Service Description
Remote Registry Enables viewing and changing Windows Registry from a remote computer (including hackers’ computers).
ClipBook (Windows XP only) Shares Clipboard contents over a network
Function Discovery Resource Publication (Windows Vista, 7, 8, 8.1) Publishes shared resources (printers, libraries, etc.) on this computer over a network.
Offline Files (Windows Professional/Business/Ultimate) Caches selected folders and files from file servers so that the items are always available.
SSDP Discovery Detects and publishes Simple Services, such as UPnP devices (home entertainment systems, media streaming, printers, some WiFi routers, etc).
Telnet (Windows XP only) Enables remote access to a command-line interface over a network.
WebClient Enables creating, accessing and modifying files on the Internet using Windows-based programs. This does not affect FTP, SSH, SCP or browser-based access.
Windows Media Player Network Sharing Service Enables streaming music and video to home entertainment systems and other computers/devices over a network.

If you disable at least some of these services, your system should be harder for hackers and bots to attack, and your system will be more secure.

External Links:

Remove useless services/apps at linuxquestions.org

Useless services in CentOS VDS/VPS at nixcraft.com

Turn off Unnecessary Windows Services at www.marksanborn.net

Disable Unneeded Services in Windows at www.winhelp.us

Remote Access Options

remote accessSooner or later, odds are good that you will either want or need the ability to work remotely. Providing remote access must be undertaken very cautiously, because as soon as you allow an employee to connect to the corporate network, you have to some degree extended your network boundary to their workstation. This means your network’s security is now only as good as the security of the remote user’s system or network. In some cases, this borders on no security at all. This is why remote access must only be granted after careful consideration and planning. While the different types of remote access have different levels of security risk, all types of remote access have some common planning and configuration steps.

Remote Access: VPNs

The first step is to determine what type of remote access is appropriate. A virtual private network (VPN) extends a private network across a public network, such as the Internet. It enables a computer to send and receive data across shared or public networks as if it were directly connected to the private network, while benefiting from the functionality, security, and management policies of the private network. This generally provides the greatest level of functionality, but also poses the greatest risk. If the remote system is compromised, an attacker is effectively inside your corporate network. While there are steps you can take to mitigate these risks, they may be time-intensive and effort-intensive. To plan, configure and properly secure a VPN solution is the most involved choice of the various remote access solutions you could provide.

Remote Access: Remote Desktop Software

Another option is to provide remote desktop functionality. This would allow a remote user to see and use the desktop of a system at work. A remote desktop acts as if the user is at work, while a VPN acts as if the user’s computer is at work. This type of solution is slightly easier to implement, because you can typically isolate the traffic that needs to be permitted through the firewall to a single TCP port. Many of the same risks exist, however, in that if an attacker manages to gain access to an internal desktop remotely, it is usually easy for them to move information out of the network or otherwise cause mischief. Another key consideration with this type of solution is that you need to have a computer at home and a computer at work. With the VPN option, youonly need to use one system, so if the user has a laptop, it can be used while they work remotely. There are several options for remote desktop functionality: LogMeIn (which is no longer free), TeamViewer (free for home users), and Symantec’s PcAnywhere, to name but a few.


Remote Access: Remote Shell

The last and least functional option is that of a remote shell. Because most users do not operate extensively (or even at all) in a console environment, this type of remote access is generally most suitable for network administration personnel. While it may be impossible for typical users to operate their systems without a GUI, many network tasks and most firewall administration tasks can be permormed with only terminal access. Because the widely-used Telnet protocol sends all data unencrypted, any sensitive tasks should only be performed using a secured protocol such as secure shell (SSH), or Telnet over a Secure Internet Protocol (IPsec) tunnel.

External Links:

VPN at Wikipedia

Network Security: Disabling Services

network securityI thought it might be a good idea to do a series of articles on network security, and to kick it off I’m going to cover disabling unnecessary services. This article assumes your network is running Linux, at least for services.

As a Linux administrator you will want to know and define the following elements:

  • The role of the server (web, database, proxy, etc.)
  • Services that are required to perform a specific server role (e.g. Apache)
  • Ports required to be opened (e.g. port 80 for HTTP)

All the other services should be disabled and all other ports should be closed. When these tasks are performed, the server becomes a specialized server to play only the designated role.


To ensure network security by hardening a server, you must first disable any unnecessary services and ports. The process involves removing any unnecessary services, such as rlogin, and locking down unnecessary Transmission Control Protocol or User Datagram Protocol (TCP/UDP) ports. Once these services and ports are secure, you must then regularly maintain the system.

Network Security: Controlling Services

Different Linux distributions have different front ends to control services. For example, in Red Hat Linux, you can enable and disable services by navigating to System -> Administration -> Services and opening the Service Configuration utility. From there, you may select or deselect the services, start, stop or restart them and edit the run level of individual services. Although most modern Linux distros have enhanced their GUIs to cover most of the administrative tasks, it is important for admins to know how to perform the tasks without a GUI.

Linux has greater network security than most operating systems; even so, the Linux kernel is being constantly updated and there are undoubtedly many security vulnerabilities that have not yet been discovered. Most Linux services are not vulnerable to this exploits; however, an administrator can reduce the risk by removing unnecessary services. Virtually every Linux distribution includes many services, so it makes sense that administrators customize the system to meet their or their company’s needs, as removing unnecessary services also removes risk and thus improves network security.




No matter what distribution of Linux you are using, the /etc/inetd.d or /etc/xinetd.d directory (for some newer releases, including Red Hat). This is the default configuration file for the inetd (or xinetd) daemon. This files in this directory enable you to specify the daemons to start by default and supply the arguments that correspond to the desired style of functioning for each daemon. It controls many services, include File Transfer Protocol (FTP) and Telnet. It determines what services are available to the system what services are available to the system. inetd or xinetd is a super server listening for incoming network activity for a range of services. It determines the actual nature of the service being requested and launches the appropriate server.

The /etc/inetd.conf (or /etc/xinetd.conf) directs requests for services to the /etc/inetd.d (or /etc/xinetd.d) directory. Each service has a configuration in this directory. If a service is commented out in its specified configuration file, the service is unavailable. Because inetd/xinted is so powerful, for optimal network security only the root should be able to configure its services.

Network Security: Disabling Telnet, FTP and rlogin

While most admins find in convenient to log in remotely their Linux/Unix machines over a network for administrative purposes, in a high-network security environment, only physical access may be permitted for administering a server. In this case, you should disable the Telnet interactive login utility. Because of security vulnerabilities in FTP, you should disable it as well, and use SFTP (Secure FTP) if necessary. To accomplish these two objectives, do the following:

  • Edit the /etc/inetd.d/telnet (or xinetd.d/telnet) file by opening the file, using vi or the editor of your choice
  • Comment out the service telnet line by adding a number sign (#) before service telnet
  • Write and quit the file
  • Restart inetd or xinetd by entering:
    /etc/rc.d/init.d/inetd restart
    or for xinetd:
    /etc/rc.d/xinit.d/xinetd restart
  • Attempt to log onto the system using Telnet. You should fail.
  • Diable the FTP service using the same method.
  • Attempt to access the system via FTP. You should fail.

The remote login (rlogin) service is enabled by default in the /etc/inetd.d/rlogin (or /etc/xinetd.d/rlogin) file. Rlogin has security vulnerabilities because it can bypass the password prompts to access a system remotely. There are two services associated with rlogin: login and RSH (remote shell). To disable these services you have to open the rlogin file and comment out the service login line, and then open the rsh file and comment out the service shell line. Restart xinetd to ensure your system is no longer offering these services. Disabling these three services will go a long way towards improving network security on your Linux server.


External links:

inetd at Wikipedia

SSH Server Configuration in pfSense

SSH

Enabling SSH access in pfSense 2.0.

For today’s article, I decided to cover something I probably should have covered earlier on: how to enable Secure Shell (SSH) login in pfSense 2.0. You may never have occasion to access your pfSense box remotely outside of the web GUI, but enabling the SSH server is still a good idea just in case you do.

Secure Shell (SSH) is a cryptographic network protocol for secure data communication, remote command-line login, remote command execution, and other secure network services between two networked computers that connects via a secure channel over an insecure network, a sever and a client. Typically SSH is used for access to shell accounts on Unixoid operating systems, but it can also be used in a similar fashion for accounts on Windows. It was designed as a replacement for Telnet and other insecure remote shell protocols such as the BSD rsh and rexec protocols, which send information – including passwords – in plain text, thus rendering them vulnerable to interception and disclosure. The encryption used by SSH is intended to provide confidentiality and integrity of data over an unsecured network.


Configuring the SSH Server

To enable the Secure Shell (SSH) service in pfSense, navigate to System -> Advanced, and scroll down to the section labeled “Secure Shell“. Check the “Enable Secure Shell” check box to enable SSH. You will be prompted for a username and password when you connect. You can use the same credentials that you use to connect to the web GUI. But if you check “Disable password login for Secure Shell“, you can use your RSA keys instead. At “SSH port“, leave the edit box blank to use the default port, or type in a different port to use a different one. If you are not going to allow SSH access to your pfSense box from the Internet, you can probably leave the default unchanged; otherwise, it is probably a good idea to choose a port a hacker is unlikely to guess, and even then, it is advisable to do any remote (i.e., from outside the network) administration through a VPN. Finally, press the “Save” button to save the changes and the pfSense SSH service will be started.

Using RSA Keys for SSH Login

SSH

PuTTYGen in action under Windows.

Using RSA keys is one way to secure client/server connections between the client and the SSH server. In order to utilize RSA keys, you must first generate a public-private key pair using a tool such as ssh-keygen on a Linux-based system or a Mac, or a tool such as PuTTYGen on a Windows-based system. To use ssh-keygen, simply open a terminal, run ssh-keygen, and save the key (you can also specify a pass code). To use PuTTYGen, open it and press the “Generate” button to generate a public/private key pair. You can enter a passphrase in the appropriate edit box, and press “Save private key” to save the private key. You can copy and paste the public key from the text box at the top of the application’s dialog box.

SSH

Pasting a public key in the pfSense User Manager.

Once you have a public/private key pair, you need to make sure that “Disable password login for Secure Shell” is checked in the Secure Shell settings at System -> Advanced. Then navigate to System -> User Manager, and click on the “e” next to the admin listing in the table to edit settings for the admin account. Scroll down to “Authorized keys” and check the “Click to paste an authorized key” check box. Now you can paste the public key into the text box. Press the “Save” button to save the changes.

Now, when you connect to pfSense using an SSH client, you will not be prompted for a password. Instead, your client must have the private key of the public/private key pair generated earlier in order to be authenticated.


External Links:

How to Enable SSH Access at doc.pfsense.org

The SSH lockout table at doc.pfsense.org

Forum posting on safely adding SSH users to pfSense at serverfault.com

© 2013 David Zientara. All rights reserved. Privacy Policy