Software Management Plan Analysis

Submitted By Rob-Reinitz
Words: 736
Pages: 3

The recommendation for a software management plan is to use RPM. RPM is a software management tool originally created by Red Hat, and later GNU’ed and given to the public at http://www.rpm.org/. It forms the core of administration on most systems, since one of the major tasks for any administrator is installing and keeping software up to date. Various estimates place most of the blame for security break-ins on bad passwords, and old software with known vulnerabilities. This isn’t exactly surprising on would think, but while the average server contains 200-400 software packages on average, on begins to see why keeping software up to date can be a major task.
The main page for RPM leaves something-to-be-desired, but the book “Maximum RPM” on the other hand is really wonderful and freely available (http://www.rpm.org/). This book is suggested for any Red Hat administrator, and can say safely that it is required reading if you plan to build RPM packages. The basics of RPM are pretty self-explanatory; packages come in an rpm format, with a simple filename convention (package_name-package_version-rpm_build_version-architecture.rpm or nfs-server-2.2beta29-5.i386.rpm)
All computer systems can suffer from malware and viruses, including Linux. Thankfully, very few viruses exist for Linux, so users typically do not install antivirus software. It is still recommended that Linux users have antivirus software installed on Linux systems that are on a network or that have files being transferred to the device. Some users may argue that antivirus software uses up too much resource. Thankfully, low-footprint software exists for Linux. To better understand antivirus programs, it may be beneficial to understand malware itself.
In order to manage critical and noncritical security-related updates, there are some things that are recommended. The first of which is to turn off any unused services. Services which you don't enable can't be attacked from the outside. If you don't provide access to a service, it doesn't matter if there are any vulnerabilities in the daemon which would provide that service. So disable anything you don't need to use.
Some daemons are started when the system boots, and remain active as long as the system remains up. For these persistent daemons, you need to look at the initialization scripts or programs used to start services when the system boots. Other services are not started at boot time, but instead are managed by either inetd or xinetd. If your system is configured with inetd, look at /etc/inetd.conf, and remove, or simply prefix with a "#" character to make it a comment, any entry providing a service you don't need.
The second step would be where available, install IP filter or firewall rules. While restricting network access helps, it is no guarantee that you won't be attacked. If you allow itt-tech.edu, you can be attacked from another itt-tech.edu system. But restricting access to a smaller group of systems will reduce the number of attempts you see made against you.