Find and Disable Insecure Services on Linux

Insecure Services on Linux

The world has changed a lot in the last era, especially when it comes to computing. This applies also to the services we run on our Linux systems. Some of these services (like rlogin), were previously the defacto tools to do administration. Now they are considered to be bad and insecure.

What makes a service insecure?

Services can become insecure when they have characteristics like:

  • No (or weak) authentication
  • No (or weak) encryption
  • Insecure protocols
  • Running as root

Authentication insecurities

One example might be if a program only requires a password or pin, without any information like an username. This happens often in physical solutions, but sometimes also in software. The risk involved is two-folded: it is easy to guess and provides no (or weak) accounting.

Weak encryption

Some programs come without any form of encryption. This doesn’t mean all programs are insecure by default. It depends on the task they have. When communicating via the network, it rapidly becomes a risk, as data can be sniffed. If any confidential data, like authentication details, is shared over the link, the service is “leaking” this information.

Another risk with encryption is when weak protocols and ciphers are used, or its implementation is flawed. A good example here is the usage of SSL version 3, which was previously fine. Now it is considered to be weak (e.g. POODLE attack).

Insecure protocols

Protocols define basic rules on communication and exchange of information. Some of the older protocols are now considered to be weak. This includes protocols which lack encryption, yet provide the possibility to authenticate. The credentials by the user can be easily sniffed on the (inter)network

Examples:

  • FTP
  • HTTP
  • IMAP
  • NIS
  • POP3
  • SNMP v1/v2c

Where possible avoid using these protocols for services which share sensitive data.Running as root

Running as root

Most software has the risk of being exploited at some stage. To prevent the impact as much as possible, processes should not run with root privileges. Doing so might give away the full system when one layer of your security defenses is breached. Fortunately, most well-known Linux daemons drop privileges.

Conclusion

Implement proper authentication methods for your software. If you are dealing with sensitive information, make use of encryption and ensure the right ciphers and protocols are being used. Run your software with the least amount of privileges, and enable logging of important, or security-related events.

Lynis Enterprise

Lynis Enterprise screenshot to help with system hardening

This blog post is part of our Linux security series and the mission to get Linux and Unix-based systems more secure.

Does system hardening take a lot of time, or do you have any compliance in your company? Have a look at Lynis Enterprise.

Or start today with the open source security scanner Lynis (GitHub)


Leave a Reply

Your email address will not be published. Required fields are marked *