Find and Disable 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.
