This whole book is about reducing the probability, severity, and consequences of intrusions. Be realistic. No system is 100 percent secure and anyone who claims that his system or his products are 100 percent secure is a fool or a liar. Perhaps 99 percent of the people reading this book will have someone attempt to break into their systems. Without changing your configuration to monitor for this, you never will know.[1]
[1] My server does not provide Sun RPC services, telnet, ftp, or cracker Trojans but by monitoring these ports, I know when attacks are directed to these ports and my systems lock these crackers out automatically. This might be considered to be acting as a honeypot; that is, providing something sweet to attract crackers away from something more valuable or sensitive.
Perhaps 10 20 percent of people reading this book will suffer a system break-in. Those who are scared by this statistic and are considering buying another book or switching to another operating system instead are encouraged to reread the previous paragraph!
The suggestions in Part I were a methodical approach to eliminating known security holes in the various parts of your system and network and "people issues" such as education and policy. Part II addressed being able to recover quickly by having backup tapes and "hot backup systems" tailored for recovery from intrusions. It also covered scanning your systems for vulnerabilities with some of the same tools that crackers use and the subsequent hardening by removing those vulnerabilities. It also covered the Secure SHell, PGP, TCP Wrappers, Adaptive TCP Wrappers, and the Cracker Trap.
Now comes the vigilant watch for intrusion attempts. If following the advice of the previous parts of this book makes your system so secure, why should you care about thwarted attacks? As I write this, the current versions of all Linux distributions have a known DNS vulnerability, due to a bug in the new version of the named program. By monitoring system and network activity, you may detect these intrusions quickly and reduce or eliminate the consequences.
It is quite important to monitor the security sites discussed in Appendix A so that you can update your system when someone else gets broken into, before the same exploit happens to your systems. However, this is not a cure-all. One of my clients suffered a break-in in late 1999, via FTP, using a method that had not been discussed in the security sites (which I had been monitoring very closely while conducting research for this book).
The log files indicated suspicious FTP activity with time-stamps indicating it happened shortly before the cracker installed some files. The logs indicated no sendmail or DNS activity. This was enough to satisfy me as to the means of the attack. Certainly, an extremely sophisticated cracker could have planted false logs, but this is very unusual and this incident looked like the work of a script kiddie. Even a post-mortem search of the security sites turned up only a brief mention that it had happened to someone else, with no clues as to the vulnerability more specific than "FTP." I followed the advice in Part IV for finding Trojans and other damage.
I then concurred with the MIS Department that TCP Wrappers would prevent a re-occurrence and TCP Wrappers were installed. No subsequent problems were encountered. If automatic logging to another system is set up, you might have clues as to how the penetration was done, even if a sophisticated cracker has cleaned your log files of incriminating evidence. This will allow you to know where to harden your system to avoid a repeat attack from the same cracker or a different one.
Do not discount the value of log files in convincing management of the importance of budgeting for security work. The log files will help convince management that only your spending significant time on security matters has prevented a break-in. Log files also help put crackers out of business. Personally, I have caused a number of cracker accounts to be shut down by providing a detailed report of their attempts against my systems to their ISPs, explaining how "trying to connect to known cracker ports, Sun RPC ports, and the like could not possibly be considered to be legitimate access." In one case I caused an account owner to be informed that his account had been compromised (well, at least that is what he told his ISP). This has happened often enough that I have been tempted to modify the blockip Adaptive TCP Wrappers program to generate this e-mail automatically; it certainly would be easy enough.
The chapters in this part are:
Chapter 16, "Monitoring Activity" on page 605
Chapter 17, "Scanning Your System for Anomalies" on page 645
