Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

Detecting Manually Compiled Network Daemons

Nessus plugin #33851 (Network daemons not managed by the package system) is a credentialed check that audits each of the server processes on the audited Linux system. If the running process is not part of a known system package, the plugin reports that the program is the result of a hand-compiled solution. Below is a screen shot of the plugin detecting a hand compiled httpd program:


Reportsmaller

Why should you avoid manually compiled programs on production systems?

System administrators sometimes argue that they prefer to use manually compiled programs rather than use a packaged version coming either from their OS vendor or their internal organization, as it gives them a better control of every compilation option, gcc optimization, etc... or just because they will claim they need a “newer” version of the daemon than what is provided by the Linux distribution they are using.

While this approach can make sense for a server running at home, the practice does not scale for the enterprise. Unless this is properly documented, using hand-compiled packages very often ties a given server to the administrator who compiled it, making him much harder to replace or second, makes that IT organization much less scalable.

Hand-compiling programs on production systems frequently opens the way to more hand-compiled packages. Due to the complex interdependencies of several open-source packages, installing the newest version of, say, a popular wiki, might involve compiling the newest version of PHP, which in turn will require the newest version of mysql-client, which may require upgrading several underlying libraries. This leads to a situation where upgrading the entire operating system becomes a daunting task, since Linux does always not guarantee backward binary compatibility. This leads the way to running production systems with outdated software years after they have been declared as "end of life" by their publisher. A full upgrade will inevitably lead to conflicts, where the system-provided Apache web server might compete with the locally compiled web server for port 80.

Good system administration practices dictate that one should deviate as little as possible from the environment provided by the operating-system vendor. While this might be frustrating sometimes, this approach guarantees you that a full-time security team will correct the security flaws found in the packages you use, that a full-time QA team made sure that your upgrade will be as painless as possible and it makes it much easier for your system administrators to recreate their environment on a clean system (without having to resort to copying / from one Linux system to another).

Finally, on commercially supported Linux distributions, hand-compiling several key programs may nullify the support contract.

For More Blog Posts Regarding Patch Auditing

The following previous blog posts deal with patch auditing: