Perl for System Administration

Chapter 10. Security and Network Monitoring

Any discussion of security is fraught with peril. There are at least three snares that can doom a discussion on security:

1. Security means different things to different people. If you walked into a conference of Greco-Roman scholars and asked about Rome, the first scholar would rise dramatically to her feet and begin to lecture about aqueducts (infrastructure and delivery), the second Pax Romana (ideology and policies), a third would expound on the Roman legions (enforcement), a fourth on the Roman Senate (administration), and so on. The need to deal with every facet of security at once is security’s first trap.

2. People think that something can be secure, be it a program, a computer, a network, etc. This chapter will never claim to show you how to make anything secure; it will try to help you make something more secure, or at least recognize when something is less secure. Security is a continuum.

3. Finally, one of the most deadly traps in this business is specificity. It is true that the deity of security is often in the details, but it is an ever-shifting set of details. Patching security holes A, B, and C on your system only guarantees (and perhaps not even) that those particular holes will not be a source of trouble. It does nothing to help when hole D is found. That’s why this chapter will focus on principles and tools for improving security. It will not tell you how to fix any particular buffer overflow, vulnerable registry key, or world-writable ...