Host Operating Systems

Hardening any host is a matter of paring its functionality down to the essentials for successful operation and ensuring that the running functions are as secure as possible. Host hardening can be broken down into a number of discrete tasks, each of which is different based on the operating system. These hardening steps should occur whether or not you run host antivirus (AV), host firewalls, or host IDS. These technologies should augment your host security, not replace good system administration.

NOTE

Hopefully you aren't looking to this book as an authoritative source for host-hardening guidelines. Instead, I recommend that you look at many of the excellent websites and books already published on the subject.

The following links and book titles are good sources of information on system security:

  • Windows Microsoft has a number of hardening guides and tools designed to help harden Microsoft OSs. These guides can be found at the following URL: http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/tools/tools.asp.
  • General UNIX At the UNIX level, in general, there are so many guides that it is difficult to choose just one. Search on "UNIX" and "hardening" using your favorite search engine. The best book on the subject is Practical UNIX and Internet Security, Third Edition, by Garfinkel, Spafford, and Schwartz (O'Reilly, 2003).
  • Solaris Sun hosts a series of white papers on Solaris security at the following URL: http://www.sun.com/software/security/blueprints/.
  • Linux There are a number of different distributions of Linux, and each has its own particular hardening guidelines. As an example, a Debian Linux security guide can be found here: http://www.linuxsecurity.com/docs/harden-doc/html/securing-debian-howto/index.en.html.
  • BSD UNIX There are several different flavors of Berkeley Software Distribution (BSD) UNIX. The hardening guide for FreeBSD can be found here: http://people.freebsd.org/~jkb/howto.html.

Partitioning Disk Space

In the event of a problem, you don't want one rogue process to consume your entire system's disk space. Although partitioning is often not done for desktop systems, it is very commonly done for server systems. In UNIX, for example, it is good practice to set aside separate partitions for the following components:

  • / (or root) This is the root partition where the OS kernel resides. This partition is typically fairly small.
  • /var This partition usually holds system log data. By having it in a separate partition, system log events can't accidentally consume all the free space on the file system.
  • /home User directories are contained here, where the space they use can be limited.
  • /usr This partition usually contains all the software for the system and is commonly one of the largest partitions on the box.
  • /tmp This is a small partition for miscellaneous functions.

Turning Off Unneeded Services

If the host is a standard desktop, it probably doesn't need to run any services for other users such as File Transfer Protocol (FTP). If it is a server, the running services should be limited to those that are required to perform the job of the server. This means running HTTP but not Telnet on a web server. Turning off unneeded services limits your exposure to vulnerable services. If your web server is running only HTTP, a vulnerability in the OS's FTP daemon isn't something you must worry a lot about for that particular system.

Patching the Services Needed

Any services that must be running should be kept up-to-date with the latest patches. This is no simple task because patches can break other parts of a program. Be sure first to test any patches on test or nonessential systems before deploying them to critical systems.

NOTE

Patch management systems are starting to become more common in modern applications and OSs. These systems work by having the OS and application query central servers for update information. For example, Microsoft Windows XP has an autoupdate system that informs users that a security fix is available and that asks them to click Yes to install. AV products offer similar functionality. These systems can greatly aid an organization in keeping desktop systems up-to-date, but because of the testing issue, I don't recommend them for servers. Similar systems can be used within a large organization to manage system patching for network devices. This ensures that even if a vendor deems a patch worthy of installation, it won't actually get installed until the information technology (IT) staff deems it safe for deployment.

 

Logging Critical Events

Most modern OSs keep system log files with data such as failed authentication events and other security-relevant information. Although it is impractical to review this data on all hosts, examining it on critical systems is essential.

Part I. Network Security Foundations

Network Security Axioms

Security Policy and Operations Life Cycle

Secure Networking Threats

Network Security Technologies

Part II. Designing Secure Networks

Device Hardening

General Design Considerations

Network Security Platform Options and Best Deployment Practices

Common Application Design Considerations

Identity Design Considerations

IPsec VPN Design Considerations

Supporting-Technology Design Considerations

Designing Your Security System

Part III. Secure Network Designs

Edge Security Design

Campus Security Design

Teleworker Security Design

Part IV. Network Management, Case Studies, and Conclusions

Secure Network Management and Network Security Management

Case Studies

Conclusions

References

Appendix A. Glossary of Terms

Appendix B. Answers to Applied Knowledge Questions

Appendix C. Sample Security Policies

INFOSEC Acceptable Use Policy

Password Policy

Guidelines on Antivirus Process

Index



Network Security Architectures
Network Security Architectures
ISBN: 158705115X
EAN: 2147483647
Year: 2006
Pages: 249
Authors: Sean Convery

Similar book on Amazon

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net