Unrecognized libpcap format or not libpcap data

******ebook converter DEMO Watermarks*******

******ebook converter DEMO Watermarks*******

The Tao of Network Security Monitoring

Beyond Intrusion Detection

Richard Bejtlich

Boston • San Francisco • New York • Toronto • Montreal London • Munich • Paris • Madrid

Capetown • Sydney • Tokyo • Singapore • Mexico City

******ebook converter DEMO Watermarks*******

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. This is a book about network monitoring. The act of collecting traffic may violate local, state, and national laws if done inappropriately. The tools and techniques explained in this book should be tested in a laboratory environment, separate from production networks. None of the tools or techniques should be tested with network devices outside of your responsibility or authority. Suggestions on network monitoring in this book shall not be construed as legal advice. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers discounts on this book when ordered in quantity for bulk purchases and special sales. For more information, please contact: U.S. Corporate and Government Sales

(800) 382-3419 corpsales@pearsontechgroup.com

For sales outside of the U.S., please contact: International Sales

(317) 581-3793 international@pearsontechgroup.com

Visit Addison-Wesley on the Web: www.awprofessional.com Library of Congress Cataloging-in-Publication Data Bejtlich, Richard. The Tao of network security monitoring : beyond intrusion detection / Richard Bejtlich. p. cm. ISBN 0-321-24677-2 (pbk.)

******ebook converter DEMO Watermarks*******

mailto:corpsales@pearsontechgroup.com
mailto:international@pearsontechgroup.com
http://www.awprofessional.com
1. Computer networks—Security measures. I. Title.

TK5105.59.B44 2004 005.8-dc 22 2004007857 Copyright © 2005 by Pearson Education, Inc. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America. Published simultaneously in Canada. For information on obtaining permission for use of material from this work, please submit a written request to: Pearson Education, Inc.

Rights and Contracts Department 75 Arlington Street, Suite 300 Boston, MA 02116 Fax: (617) 848-7047

ISBN 0-321-24677-2 Text printed in the United States on recycled paper at Courier Stoughton in Stoughton, Massachusetts. 10th Printing March 2010

******ebook converter DEMO Watermarks*******

TO MY WIFE, AMY: LOVE IS CERTAIN, LOVE IS KIND. IT ISN'T SOMETHING THAT WE FIND. IT'S

SOMETHING THAT WE DO.

******ebook converter DEMO Watermarks*******

Contents

Foreword Preface About the Author About the Contributors Part I. Introduction to Network Security Monitoring Chapter 1. The Security Process What Is Security? What Is Risk? Threat Vulnerability Asset Value A Case Study on Risk Security Principles: Characteristics of the Intruder Some Intruders Are Smarter Than You Many Intruders Are Unpredictable Prevention Eventually Fails Security Principles: Phases of Compromise Reconnaissance Exploitation Reinforcement Consolidation Pillage

******ebook converter DEMO Watermarks*******

Security Principles: Defensible Networks Defensible Networks Can Be Watched Defensible Networks Limit an Intruder's Freedom to Maneuver Defensible Networks Offer a Minimum Number of Services Defensible Networks Can Be Kept Current Conclusion Chapter 2. What Is Network Security Monitoring? Indications and Warnings Collection, Analysis, and Escalation Detecting and Responding to Intrusions Why Do IDS Deployments Often Fail? Outsiders versus Insiders: What Is NSM's Focus? Security Principles: Detection Intruders Who Can Communicate with Victims Can Be Detected Detection through Sampling Is Better Than No Detection Detection through Traffic Analysis Is Better Than No Detection Security Principles: Limitations Collecting Everything Is Ideal but Problematic Real Time Isn't Always the Best Time Extra Work Has a Cost What NSM Is Not NSM Is Not Device Management NSM Is Not Security Event Management NSM Is Not Network-Based Forensics NSM Is Not Intrusion Prevention NSM in Action ******ebook converter DEMO Watermarks*******

Conclusion Chapter 3. Deployment Considerations Threat Models and Monitoring Zones The Perimeter The Demilitarized Zone The Wireless Zone The Intranet Accessing Traffic in Each Zone Hubs SPAN Ports Taps Inline Devices Wireless Monitoring Sensor Architecture Hardware Operating System Sensor Management Console Access In-Band Remote Access Out-of-Band Remote Access Conclusion Part II. Network Security Monitoring Products Chapter 4. The Reference Intrusion Model The Scenario The Attack ******ebook converter DEMO Watermarks*******

Conclusion Chapter 5. Full Content Data A Note on Software Libpcap Tcpdump Basic Usage of Tcpdump Using Tcpdump to Store Full Content Data Using Tcpdump to Read Stored Full Content Data Timestamps in Stored Full Content Data Increased Detail in Tcpdump Full Content Data Tcpdump and Berkeley Packet Filters Tethereal Basic Usage of Tethereal Using Tethereal to Store Full Content Data Using Tethereal to Read Stored Full Content Data Getting More Information from Tethereal Snort as Packet Logger Basic Usage of Snort as Packet Logger Using Snort to Store Full Content Data Using Snort to Read Stored Full Content Data Finding Specific Parts of Packets with Tcpdump, Tethereal, and Snort Ethereal Basic Usage of Ethereal Using Ethereal to Read Stored Full Content Data Using Ethereal to Rebuild Sessions Other Ethereal Features

******ebook converter DEMO Watermarks*******

A Note on Commercial Full Content Collection Options Conclusion Chapter 6. Additional Data Analysis Editcap and Mergecap Tcpslice Tcpreplay Tcpflow Ngrep IPsumdump Etherape Netdude Using Netdude What Do Raw Trace Files Look Like? P0f Conclusion Chapter 7. Session Data Forms of Session Data Cisco's NetFlow Fprobe Ng_netflow Flow-tools Flow-capture Flow-cat and Flow-print sFlow and sFlow Toolkit Argus ******ebook converter DEMO Watermarks*******

Argus Server Ra Client Tcptrace Conclusion Chapter 8. Statistical Data What Is Statistical Data? Cisco Accounting Ipcad Ifstat Bmon Trafshow Ttt Tcpdstat MRTG Ntop Conclusion Chapter 9. Alert Data: Bro and Prelude Bro Installing Bro and BRA Interpreting Bro Output Files Bro Capabilities and Limitations Prelude Installing Prelude Interpreting Prelude Output Files Installing PIWI Using PIWI to View Prelude Events ******ebook converter DEMO Watermarks*******

Prelude Capabilities and Limitations Conclusion Chapter 10. Alert Data: NSM Using Sguil Why Sguil? So What Is Sguil? The Basic Sguil Interface Sguil's Answer to “Now What?” Making Decisions with Sguil Sguil versus the Reference Intrusion Model SHELLCODE x86 NOOP and Related Alerts FTP SITE Overflow Attempt Alerts SCAN nmap TCP Alerts MISC MS Terminal Server Request Alerts Conclusion Part III. Network Security Monitoring Processes Chapter 11. Best Practices Assessment Defined Security Policy Protection Access Control Traffic Scrubbing Proxies Detection Collection Identification ******ebook converter DEMO Watermarks*******

Validation Escalation Response Short-Term Incident Containment Emergency Network Security Monitoring Back to Assessment Analyst Feedback Conclusion Chapter 12. Case Studies for Managers Introduction to Hawke Helicopter Supplies Case Study 1: Emergency Network Security Monitoring Detection of Odd Orders System Administrators Respond Picking Up the Bat Phone Conducting Incident Response Incident Response Results Case Study 2: Evaluating Managed Security Monitoring Providers HHS Requirements for NSM HHS Vendor Questionnaire Asset Prioritization Case Study 3: Deploying an In-House NSM Solution Partner and Sales Offices HHS Demilitarized Zone Wireless Network Internal Network “But Who Shall Watch the Watchers?”

******ebook converter DEMO Watermarks*******

Other Staffing Issues Conclusion Part IV. Network Security Monitoring People Chapter 13. Analyst Training Program Weapons and Tactics Definition Tasks References Telecommunications Definition Tasks References System Administration Definition Tasks References Scripting and Programming Definition Tasks References Management and Policy Definition Tasks References Training in Action Periodicals and Web Sites ******ebook converter DEMO Watermarks*******

Case Study: Staying Current with Tools Conclusion Chapter 14. Discovering DNS Normal Port 53 Traffic Normal Port 53 UDP Traffic Normal Port 53 TCP Traffic Suspicious Port 53 Traffic Suspicious Port 53 UDP Traffic Suspicious Port 53 TCP Traffic Malicious Port 53 Traffic Malicious Port 53 UDP Traffic Malicious Port 53 TCP and UDP Traffic Conclusion Chapter 15. Harnessing the Power of Session Data The Session Scenario Session Data from the Wireless Segment Session Data from the DMZ Segment Session Data from the VLANs Session Data from the External Segment Conclusion Chapter 16. Packet Monkey Heaven Truncated TCP Options SCAN FIN Chained Covert Channels Conclusion ******ebook converter DEMO Watermarks*******

Part V. The Intruder versus Network Security Monitoring Chapter 17. Tools for Attacking Network Security Monitoring Packit IP Sorcery Fragroute LFT Xprobe2 Cisco IOS Denial of Service Solaris Sadmin Exploitation Attempt Microsoft RPC Exploitation Conclusion Chapter 18. Tactics for Attacking Network Security Monitoring Promote Anonymity Attack from a Stepping-Stone Attack by Using a Spoofed Source Address Attack from a Netblock You Don't Own Attack from a Trusted Host Attack from a Familiar Netblock Attack the Client, Not the Server Use Public Intermediaries Evade Detection Time Attacks Properly Distribute Attacks Throughout Internet Space Employ Encryption Appear Normal Degrade or Deny Collection ******ebook converter DEMO Watermarks*******

Deploy Decoys Consider Volume Attacks Attack the Sensor Separate Analysts from Their Consoles Self-Inflicted Problems in NSM Conclusion Epilogue. The Future of Network Security Monitoring Remote Packet Capture and Centralized Analysis Integration of Vulnerability Assessment Products Anomaly Detection NSM Beyond the Gateway Conclusion Part VI. Appendixes Appendix A. Protocol Header Reference Appendix B. Intellectual History of Network Security Monitoring Appendix C. Protocol Anomaly Detection Index

******ebook converter DEMO Watermarks*******

Foreword

We've all heard the phrase “knowledge will set you free.” When it comes to real-world network security, I can think of no other phrase with which security professionals must arm themselves. Whether you are brand new to network intrusion detection, an incident responder, or a long-time network security veteran, you must always boil any situation down to its basic facts. The book you are about to read will arm you with the knowledge you need to defend your network from attackers, both the obvious and the not so obvious. Unlike other computer security books that focus on catching the “hack of the week,” this book will equip you with the skills needed to perform in-depth analysis of new and emerging threats. This book discusses many different approaches to network security. It also describes how to communicate and in some cases justify security monitoring efforts. This is important because many organizations may not readily appreciate the need for monitoring— until it is too late. Frequently I run into security “professionals” who rely on “cookbook” methodologies or their favorite tools. Too often, these people do not have a broad understanding of how networks really work and are not effective in increasing their network's defensive posture or communicating with the network administrators. Although there is no substitute for actual system and network administration experience, by reading this book you will undoubtedly come away knowing more relevant information than when you started. In many large organizations, to gain the respect of the system or network administrators, you need to be able to converse at their level—even if it is way above or below your expertise. The amount of plain talk in this book struck me as amazing. Firewalls can fail! Intrusion detection systems can be bypassed! Network monitors can be overloaded! We don't normally hear these messages from our vendors, nor do we hear it from our security administrators. Neither the vendor nor the administrator would be very successful if they focused on all the things that could go wrong. Unfortunately, this creates many false perceptions in the minds of managers and users. ******ebook converter DEMO Watermarks*******

You will enjoy the many examples in this book that show how a network is compromised and how it could have been prevented with some extra monitoring. Another dirty little secret that many security professionals don't speak much about is that our own tools are sometimes the most insecure portion of a network. You may be quite surprised to find out that the server set up to do sniffing or monitoring may be the gateway into the very network you are defending. You will learn ways to mitigate that threat too. I strongly urge you to try using the tools described throughout this book while you are reading it. All of the tools are available for FreeBSD, Linux, and, in many cases, Windows. Although it may take longer to read the book, learning by using is more effective than skimming the command-line syntax. If you are new to network security, don't put this book back on the shelf! This is a great book for beginners. I wish I had access to it many years ago. If you've learned the basics of TCP/IP protocols and run an open source or commercial intrusion detection system, you may be asking, “What's next?” If so, this book is for you. Some people have been performing network security monitoring for a very long time, and this book reviews that history. It will expose you to many other forms of monitoring that are not pure intrusion detection. The information about how you can use various tools to enhance your network security monitoring activities is an excellent resource all on its own. I wish you the best of luck monitoring and defending your network! Ron Gula

CTO and Founder of Tenable Network Security Original author of the Dragon Intrusion Detection System

******ebook converter DEMO Watermarks*******

Preface

Welcome to The Tao of Network Security Monitoring: Beyond Intrusion Detection. The goal of this book is to help you better prepare your enterprise for the intrusions it will suffer. Notice the term “will.” Once you accept that your organization will be compromised, you begin to look at your situation differently. If you've actually worked through an intrusion—a real compromise, not a simple Web page defacement—you'll realize the security principles and systems outlined here are both necessary and relevant. This book is about preparation for compromise, but it's not a book about preventing compromise. Three words sum up my attitude toward stopping intruders: prevention eventually fails. Every single network can be compromised, either by an external attacker or by a rogue insider. Intruders exploit flawed software, misconfigured applications, and exposed services. For every corporate defender, there are thousands of attackers, enumerating millions of potential targets. While you might be able to prevent some intrusions by applying patches, managing configurations, and controlling access, you can't prevail forever. Believing only in prevention is like thinking you'll never experience an automobile accident. Of course you should drive defensively, but it makes sense to buy insurance and know how to deal with the consequences of a collision. Once your security is breached, everyone will ask the same question: now what? Answering this question has cost companies hundreds of thousands of dollars in incident response and computer forensics fees. I hope this book will reduce the investigative workload of your computer security incident response team (CSIRT) by posturing your organization for incident response success. If you deploy the monitoring infrastructure advocated here, your CSIRT will be better equipped to scope the extent of an intrusion, assess its impact, and propose efficient, effective remediation steps. The intruder will spend less time stealing your secrets, damaging your reputation, and abusing your resources. If you're fortunate and collect the right information in a forensically sound manner, you might provide the evidence needed to put an intruder in jail.

******ebook converter DEMO Watermarks*******

Audience

This book is for security professionals of all skill levels and inclinations. The primary audience includes network security architects looking for ways to improve their understanding of their network security posture. My goal is to provide tools and techniques to increase visibility and comprehension of network traffic. If you feel let down by your network-based intrusion detection system (NIDS), this book is definitely for you. I explain why most NIDS deployments fail and how you can augment existing NIDS with open source tools. Because this book focuses on open source tools, it is more likely to be accepted in smaller, less bureaucratic organizations that don't mandate the use of commercial software. Furthermore, large organizations with immense bandwidth usage might find some open source tools aren't built to handle outrageous traffic loads. I'm not convinced the majority of Internet-enabled organizations are using connections larger than T-3 lines, however.1 While every tool and technique hasn't been stress-tested on high-bandwidth links, I'm confident the material in this book applies to a great majority of users and networks. If you're a network security analyst, this book is also for you. I wrote this book as an analyst, for other analysts. This means I concentrate on interpreting traffic, not explaining how to install and configure every single tool from source code. For example, many books on “intrusion detection” describe the Transmission Control Protocol/Internet Protocol (TCP/IP) suite and how to set up the Snort open source IDS engine with the Analysis Console for Intrusion Databases (ACID) interface. These books seldom go further because they soon encounter inherent investigative limitations that restrict the usefulness of their tools. Since my analytical techniques do not rely on a single product, I can take network-based analysis to the next level. I also limit discussion of odd packet header features, since real intrusions do not hinge on the presence of a weird TCP flag being set. The tools and techniques in this book concentrate on giving analysts the information they need to assess intrusions and make decisions, not just identify mildly entertaining reconnaissance patterns.

******ebook converter DEMO Watermarks*******

This book strives to not repeat material found elsewhere. You will not read how to install Snort or run Nmap. I suggest you refer to the recommended reading list in the next section if you hunger for that knowledge. I introduce tools and techniques overlooked by most authors, like the material on protocol anomaly detection by Brian Hernacki, and explain how you can use them to your advantage. Technical managers will appreciate sections on best practices, training, and personnel issues. All the technology in the world is worthless if the staff manning it doesn't understand their roles, responsibilities, and escalation procedures. Managers will also develop an intuition for the sorts of information a monitoring process or product should provide. Many vendors sell services and products named with combinations of the terms “network,” “security,” and “monitoring.” This book creates a specific definition for network security monitoring (NSM), built on a historical and operational foundation. Prerequisites

I've tried to avoid duplicating material presented elsewhere, so I hope readers lacking prerequisite knowledge take to heart the following reading suggestions. I highly recommend reading the following three books prior to this one. If you've got the necessary background, consider these titles as references. • Internet Site Security, by Erik Schetina, Ken Green, and Jacob Carlson

(Boston, MA: Addison-Wesley, 2002). This is an excellent “security 101” book. If you need to start from the ground floor, this book is a great beginning.

• Counter Hack: A Step-by-Step Guide to Computer Attacks and Effective Defenses, by Ed Skoudis (Upper Saddle River, NJ: Prentice Hall PTR, 2001). Counter Hack offers the best single-chapter introductions to TCP/IP, Microsoft Windows, UNIX, and security issues available.

• Hacking Exposed: Network Security Secrets and Solutions, 4th ed., by Stuart McClure, Joel Scambray, and George Kurtz (New York:

******ebook converter DEMO Watermarks*******

McGraw-Hill, 2003). Hacking Exposed explores the capabilities and intentions of digital threats. By knowing how to compromise computers, you'll understand the sorts of attacks network security monitoring practitioners will encounter.

If you need an introduction to intrusion detection theory, I recommend the following book: • Intrusion Detection, by Rebecca Gurley Bace (Indianapolis, IN: New

Riders, 2000). While not strictly needed to understand the concepts in this book, Intrusion Detection provides the history and mental lineage of IDS technology. As The Tao of Network Security Monitoring focuses on network-based tactics, you can turn to Intrusion Detection for insight on host-based detection or the merits of signature- or anomaly-based IDS.

It helps to have a good understanding of TCP/IP beyond that presented in the aforementioned titles. The following are a few of my favorite books on TCP/IP. • Internet Core Protocols: The Definitive Guide, by Eric A. Hall

(Cambridge, MA: O'Reilly, 2000). Many people consider Richard Stevens' TCP/IP Illustrated Volume 1: The Protocols (Reading, MA: Addison-Wesley, 1994) to be the best explanation of TCP/IP. I think Eric Hall's more recent book is better suited for modern network traffic analysts.

• Network Analysis and Troubleshooting, by J. Scott Haugdahl (Boston, MA: Addison-Wesley, 2000). Troubleshooting books tend to offer the more interesting explanations of protocols in action. Scott Haugdahl works his way up the seven layers of the Open Systems Interconnect (OSI) model, using packet traces and case studies.

• Troubleshooting Campus Networks: Practical Analysis of Cisco and LAN Protocols, by Priscilla Oppenheimer and Joseph Bardwell (Indianapolis, IN: Wiley, 2002). This title is considerably broader in scope than Scott Haugdahl's work, with coverage of virtual local area networks (VLANs), routing protocols, and wide area network (WAN) protocols like Asynchronous Transfer Mode (ATM).

One other book deserves mention, but I request you forgive a small amount ******ebook converter DEMO Watermarks*******

of self-promotion. The Tao of Network Security Monitoring is primarily about detecting incidents through network-based means. In some senses it is also an incident response book. Effective incident response, however, reaches far beyond network-based evidence. To learn more about host-based data, such as file systems and memory dumps, I recommend Real Digital Forensics (Boston, MA: Addison-Wesley, 2005). I wrote the network monitoring sections of the book, and coauthors Keith Jones and Curtis Rose did the host- and memory-level forensics. If you'd like to see the big picture for incident response, read Real Digital Forensics. A Note on Operating Systems

All of the tools I discuss in this book run on the FreeBSD (http://www.freebsd.org) operating system. FreeBSD is a UNIX-like, open source environment well suited for building network security monitoring platforms.2 If you're familiar with Linux or any other Berkeley Software Distribution (OpenBSD or NetBSD), you'll have no trouble with FreeBSD. I strongly recommend running NSM tools on UNIX-like platforms like the BSDs and Linux. You might consider trying a live CD-ROM FreeBSD distribution prior to committing a hard drive to installation. You may already know about Knoppix (http://www.knopper.net/knoppix/index-en.html), the most famous Linux-based live CD-ROM operating system. FreeBSD offers the FreeSBIE distribution (http://www.freesbie.org). FreeSBIE recently shipped version 1.0, based on the FreeBSD 5.2.1 RELEASE edition. Live distributions boot from the CD-ROM and run all programs within memory. They can be configured to write to removable media like USB thumb drives or the hard drive of the host computer. Live distributions are a good way to test hardware compatibility before going through the time and effort to install a new operating system on a system's hard drive. For example, before upgrading a FreeBSD 4.9–based system to version 5.2.1, I booted a FreeBSD 5.2.1–based live distribution and checked whether it saw all of the hardware properly. Figure 1 shows FreeSBIE 1.0 running several programs. Many security tools are included in the distribution, including Nessus, Nmap and NmapFE, Snort, ******ebook converter DEMO Watermarks*******

http://www.freebsd.org
http://www.knopper.net/knoppix/index-en.html
http://www.freesbie.org
and Ethereal. I am investigating building an NSM-minded FreeBSD-based live distribution to run the tools discussed in this book.

Figure 1. FreeSBIE 1.0 running Ethereal, NmapFE, Snort 2.1.0, and The Gimp

If you want to learn about FreeBSD, I suggest these books. • FreeBSD: An Open-Source Operating System for Your Personal

Computer, 2nd ed., by Annelise Anderson (Portola Valley, CA: Bit Tree Press, 2001). Absolute UNIX newbies will find Annelise Anderson's book the gentlest introduction to FreeBSD.

• Absolute BSD: The Ultimate Guide to FreeBSD, by Michael Lucas (San Francisco, CA: No Starch Press, 2002). Michael Lucas has an uncanny ability to answer the questions his readers are bound to ask. Keep in mind that Annelise Anderson's book and Absolute BSD focus on FreeBSD 4.x, so certain details might change with FreeBSD 5.x.

• The Complete Guide to FreeBSD, 4th ed., by Greg Lehey (Cambridge, MA: O'Reilly, 2003). Greg Lehey covers more than just FreeBSD; he

******ebook converter DEMO Watermarks*******

addresses system and network administration issues as well. This is the first book explicitly written with FreeBSD 5.x in mind.

I'm often asked why I use FreeBSD and not OpenBSD. I use FreeBSD because I believe it is the best general-purpose operating system available. It has more applications in its ports tree, a larger development community, and better network and multiprocessor performance. I develop and test all of my applications and techniques on FreeBSD. OpenBSD is more innovative in terms of security, with integrated defensive features like Systrace, the Pf firewall, increased use of privilege separation, and relentless removal of coding flaws. I believe OpenBSD may be a superior platform for building dedicated “security appliances.” Once the application is tested under a general-purpose operating system like FreeBSD, it can be deployed on a security-minded platform like OpenBSD. As the TrustedBSD project (http://www.trustedbsd.org) brings additional security features into the FreeBSD 5.x tree, FreeBSD's security features are competing well with OpenBSD. FreeBSD is beginning to adopt security systems like mandatory access control that are found in commercial operating systems like Trusted Solaris. In reality all three major BSD projects feed security ideas into each other, so competition among the projects is not a huge concern. Linux and Windows users might wonder where I stand on their operating systems. I believe Linux benefits from having a very large development community. Because so many coders run Linux, users are more likely to see patches introduced to improve Tcpdump's performance or implement other features useful to security professionals. I still prefer the BSDs to Linux because Linux is a kernel supplemented by tools selected by various distribution aggregators.3 There is also doubt about which Linux distribution is most likely to be used by the community. Prior to the arrival of Fedora Core, Red Hat Linux was more or less the de facto standard. Debian may be the heir to Red Hat's throne, but that situation remains in flux. This is not the best environment for developing security applications and standards. Windows is an operating system for consumers. It was designed to “make life easy” at the expense of security and operational transparency. The underlying Windows design model has not withstood connectivity to the Internet very

******ebook converter DEMO Watermarks*******

http://www.trustedbsd.org
well. The operating system provides far too many services on single ports. How can one disable port 135 or 139 TCP, for example, without breaking a dozen built-in applications? I believe the supposed ease of use of a Windows system, even if one accepted this feature to be true, is far outweighed by the risk of introducing the operating system in a critical security role. Those adding a security platform to a network should not violate the first rule of the Hippocratic Oath: do no harm. I have far more confidence in the reliability and resiliency of a FreeBSD or other UNIX system compared to a Windows system. Scope

The book is broken into five major parts, followed by an epilogue and appendices. You can focus on the areas that interest you, as the sections were written in a modular manner. You may wonder why greater attention is not paid to popular tools like Nmap or Snort. With The Tao of Network Security Monitoring, I hope to break new ground by highlighting ideas and tools seldom seen elsewhere. If I don't address a widely popular product, it's because it has received plenty of coverage in another book. Part I offers an introduction to NSM, an operational framework for the collection, analysis, and escalation of indications and warnings to detect and respond to intrusions. Part I begins with an analysis of the terms and theory held by NSM practitioners. Chapter 1 discusses the security process and defines words like security, risk, and threat. It also makes assumptions about intruders and their prey that set the stage for NSM operations. Chapter 2 addresses NSM directly, explaining why NSM is not implemented by modern NIDSs alone. Chapter 3 focuses on deployment considerations, such as how to access traffic using hubs, taps, SPAN ports, and inline devices. Part II begins an exploration of the NSM “product, process, and people” triad. Chapter 4 is a case study called the “reference intrusion model.” This is an incident explained from the point of view of an omniscient observer. During this intrusion, the victim collected full content data in two locations. We will use those two trace files while explaining the tools discussed in Part II. Following the reference intrusion model, I devote chapters to each of the four types of data that must be collected to perform NSM—full content, ******ebook converter DEMO Watermarks*******

session, statistical, and alert data. Chapters 5 through 10 describe open source tools tested on the FreeBSD operating system and available on other UNIX derivatives. Part II also includes a look at tools to manipulate and modify traffic. Featured in Part II are little-discussed NIDSs like Bro and Prelude, and the first true open source NSM suite, Sguil. Part III continues the NSM triad by discussing processes. If analysts don't know how to handle events, they're likely to ignore them. I provide best practices in Chapter 11 and follow with Chapter 12, written explicitly for technical managers. That material explains how to conduct emergency NSM in an incident response scenario, how to evaluate monitoring vendors, and how to deploy an NSM architecture. Part IV, intended for analysts and their supervisors, completes the NSM triad. Entry-level and intermediate analysts frequently wonder how to move to the next level of their profession. In Chapter 13, I offer some guidance for the five topics with which a security professional should be proficient: weapons and tactics, telecommunications, system administration, scripting and programming, and management and policy. Chapters 14 through 16 offer case studies, showing analysts how to apply NSM principles to intrusions and related scenarios. Part V is the offensive counterpart to the defensive aspects of Parts II, III, and IV. I discuss how to attack products, processes, and people. Chapter 17 examines tools to generate arbitrary packets, manipulate traffic, conduct reconnaissance, and exploit flaws in Cisco, Solaris, and Microsoft targets. In Chapter 18 I rely on my experience performing detection and response to show how intruders attack the mind-set and procedures on which analysts rely. An epilogue on the future of NSM follows Part V. The appendices feature several TCP/IP protocol header charts and explanations. I also wrote an intellectual history of network security, with excerpts and commentary on the most important papers written during the last 25 years. Please take the time to at least skim that appendix; you'll see that many of the “revolutionary ideas” often heralded in the press were in some cases proposed decades ago. Neither Part V nor other parts are designed as “hacking” references. You will not find “elite” tools to compromise servers; if so inclined, refer to the

******ebook converter DEMO Watermarks*******

suggested reading list. The tools I profile were selected for the traffic they generate. By looking at packets created by readily available offensive tools, analysts learn to identify normal, suspicious, and malicious traffic. Welcome Aboard

I hope you find this book useful and enjoyable. I welcome feedback on its contents, especially tips on better uses of tools and tactics. While doing research I was amazed at the amount of work done in the field of intrusion detection over the last 25 years. Intrusion detection is only one component of NSM, but it is the general community in which NSM practitioners feel most at home. Much of what I present is the result of standing on the shoulders of giants.4 Our community is blessed by many dedicated and talented people who contribute code, ideas, and resources to Internet security issues. I hope my contribution is worthy of the time you dedicate to reading it. Acknowledgments

I would first like to thank my wife Amy for her encouragement and understanding. Many nights I wrote until two or three o'clock in the morning. I appreciate the space and time she gave me to complete this book, as well as the unconditional love and support she has shown as my wife. Our dog Scout was also helpful, reminding me to stop writing every once in a while to play fetch with him. I thank my parents and sisters for providing a nurturing childhood home and encouraging a desire to learn. I owe a lot to the NSM gurus I met as a captain in the Air Force. These include Bamm Visscher, author of Sguil and the person who's been a great mentor and friend for the last five years. I enjoyed working with some real security professionals in the Air Force Computer Emergency Response Team (AFCERT) where I started my NSM journey: Sam Adams, Dave Bibighaus, Dustin Childs, Steve Chism, LeRoy Crooks, John Curry, DeWayne Duff, Ryan Gurr, Steve Heacox, Bill Kelly, Zeb King, Jason Mathews, Bruce

******ebook converter DEMO Watermarks*******

McGilvery, Don Nelson, Will Patrick, Greg Patton, Chuck Port, Jason Potopa, Chad Renfro, Chris Rochester, Billy Rodriguez, Christi Ruiz, Marty Schlachter, Jay Schwitzgebel, Mark Shaw, Larry Shrader, Byron Thatcher, Ralph Toland, and Rich Zanni. I appreciate Cheryl Knecht's patience when I caught my first reconnaissance activity from Russia. I'd also like to recognize my former supervisors in the Air Intelligence Agency's plans division, Jesse Coultrap and J.J. Romano, who acted when they realized I would be happier in the AFCERT. At Ball Aerospace & Technologies Corporation, Bamm, Dave Wheeler, and I built an NSM operation from scratch. When writing this book I kept in mind the needs of our first analysts, who in many ways were guinea pigs for the “new NSM” built on the ruins of the “good ol' days” of AFCERT NSM operations. I know some of them are watching your networks right now. Working at Foundstone gave me the chance to work on the incident response side of the NSM experience. I learned from my former boss Kevin Mandia that “we win some, and we lose some.” Forensic gurus Keith Jones and Matt Pepe showed how to replace people with very small scripts, usually named “parser.” Julie Darmstadt was there to see me “pit out” in front of dozens of students and was ready to carry a class forward when we risked another “debacle.” The Addison-Wesley team helped make this book a reality. Jessica Goldstein guided me through the writing process with skill and tact. Chrysta Meadowbrooke copyedited the text with incredible attention to detail. Heather Mullane, Chanda Leary-Coutu, and Joan Murray helped bring news of my work to readers worldwide. Talented reviewers, including Luca Deri, Ron Gula, Aaron Higbee, Kirby Kuehl, Paul Myrick, and Marcus Ranum, kept me on track. I appreciate the contributions to Chapter 9 by Bro expert Christopher Manders, Prelude-IDS founder Yoanne Vandoorselaere, and IT solution provider Dreamlab. Brian Hernacki wrote the great appendix on protocol anomaly detection. Amy Fisher of Net Optics gave expert advice on Chapter 3. I've learned quite a bit while reviewing books for Amazon.com. I appreciate the review copies sent by Joan Murray at Pearson Education, Bettina Faltermeier at McGraw-Hill/Osborne, Amy Pedersen at Syngress, Eric Holmgren at Wiley, and my friends at O'Reilly. I was tempted to cover much

******ebook converter DEMO Watermarks*******

http://Amazon.com
more ground than what appears here, but I defer to subjects better covered by other authors like Ross Anderson and Ed Skoudis. I would also like to thank the members of the FreeBSD community who devote themselves to the world's most capable operating system. Articles and books by Dru Lavigne, Greg Lehey, and Michael Lucas have been extremely helpful. I encourage anyone looking for a coherent, consistent, stable, feature-rich operating system to consider FreeBSD. I hope those of us who benefit from open source projects support them by purchasing distributions from vendors like FreeBSDMall.com and BSDMall.com. In addition to the FreeBSD community, I tip my hat to all of the developers of the open source software profiled in this book. Open source software is proving to be the wave of the past and the future. I have yet to find a software requirement not met by open source software. The next time you need an application, search an archive like SourceForge.net. If you don't find what you need, consider hiring a developer to write the code and then release it to the world under a license approved by the Open Source Initiative (http://www.opensource.org).

******ebook converter DEMO Watermarks*******

http://FreeBSDMall.com
http://BSDMall.com
http://SourceForge.net
http://www.opensource.org
About the Author

Richard Bejtlich is a security engineer in ManTech International Corporation's Computer Forensics and Intrusion Analysis division. He was previously a principal consultant at Foundstone, performing incident response, emergency network security monitoring, and security research. Prior to joining Foundstone in 2002, Richard served as senior engineer for managed network security operations at Ball Aerospace & Technologies Corporation. He helped organize and train 12 analysts offering outsourced network security monitoring for commercial clients. Richard's technical interpretation of network traffic helped identify and mitigate over three dozen intrusions during his 15 months at BATC. From 1998 to 2001 Richard defended global American information assets as a captain in the Air Force Computer Emergency Response Team (AFCERT). He led the AFCERT's real-time intrusion detection mission, supervising 60 civilian and military analysts. Richard's network security monitoring work supported law enforcement investigations and the Air Force's response to the Melissa, ILOVEYOU, and Y2K rollover incidents. Richard is a recognized voice in the computer security community. He has written several papers on network security monitoring and made technical presentations at SANS, FIRST, Infragard, ISSA, and SHADOW conferences. He reviews computer and security books for Amazon.com and is consulted by publishers to scrutinize book proposals and drafts. He wrote original material for Hacking Exposed, 4th ed., and Incident Response, 2nd ed., both published by McGraw-Hill/Osborne. Richard is also coauthor of Real Digital Forensics, published by Addison-Wesley. Formally trained as a military intelligence officer, Richard deployed to Europe in 1997 to support NATO information collection efforts during the Bosnia-Herzegovina conflict. He is a 1994 graduate of the United States Air Force Academy, where he earned bachelor of science degrees in history and political science and minor degrees in French and German. He earned a master's degree in public policy from Harvard University in 1996. He received his CISSP certification in 2001 and his Certified Information ******ebook converter DEMO Watermarks*******

http://Amazon.com
Forensics Investigator credentials in early 2004. His home page is at http://www.taosecurity.com and his Web blog resides at http://taosecurity.blogspot.com.

******ebook converter DEMO Watermarks*******

http://www.taosecurity.com
http://taosecurity.blogspot.com
About the Contributors

About the Contributing Author

Brian Hernacki (Protocol Anomaly Detection, Appendix C)

Brian Hernacki is an architect in the Symantec Research Labs, where he works with a dedicated team to develop future technologies. With more than ten years of experience with computer security and enterprise software development, he has also conducted research and commercial product development in a number of security areas, including intrusion detection and analysis techniques. Brian previously led the development, design, and architecture of products and the investigation and research of new technologies at Recourse Technologies. He has been involved in numerous intrusion detection evaluation efforts and speaks often on the subject. Before working at Recourse Technologies, Brian served as a senior software developer, group manager, and product architect at Netscape Communications Corporation, where he played a pivotal role in the development of a number of high-end enterprise and service provider server products. Prior to Netscape, his experience included engineering and management positions at Computer Aided Engineering Network (CAEN), where he developed a network-wide intrusion detection system and maintenance and system reliability tools. Brian earned a bachelor of science degree in computer engineering, with honors, from the University of Michigan. About the Technical Contributors

Christopher Jay Manders (Bro and BRA, Chapter 9)

******ebook converter DEMO Watermarks*******

Christopher Jay Manders is a cyber-security analyst, computer systems engineer, and entrepreneur who lives in San Francisco, California. He has managed large and small projects that range from ISP services to security and intrusion analysis and vulnerability assessment. He has worked with Bro and other intrusion detection and analysis tools for over seven years and has over ten years of UNIX systems administration and programming experience. He currently works for Lawrence Berkeley National Laboratory, where he is a division security liaison and group leader. Christopher programs in his spare time on such projects as the BRA user environment for Bro and systems administration tools for sending MIME attachments using Perl from a UNIX command line. One of his upcoming projects focuses on responding to and reporting scans reported by Bro. Christopher also translates Nepali (Gorkhali) literature for amusement and pleasure with friends and family. Yoanne Vandoorselaere (Prelude, Chapter 9)

Yoanne Vandoorselaere is a development engineer and specialist in networking and security. He is the project leader for Prelude (http://www.prelude-ids.org), a hybrid intrusion detection system he initiated in 1998. He tutors students pursuing their master's degrees at ESIEA (Ecole Supérieure d'Informatique–Electronique–Automatique, http://www.esiea.fr). Yoanne lives in Lyon, France, and spends most of his time developing Prelude and contributing to open source software.

******ebook converter DEMO Watermarks*******

http://www.prelude-ids.org
http://www.esiea.fr
Part I. Introduction to Network Security Monitoring

******ebook converter DEMO Watermarks*******

1. The Security Process

You've just hung up the phone after speaking with a user who reported odd behavior on her desktop. She received a pop-up message that said “Hello!” and she doesn't know what to do. While you listened to her story, you read a trouble ticket opened by your network operations staff noting an unusual amount of traffic passing through your border router. You also noticed the delivery of an e-mail to your abuse account, complaining that one of your hosts is “attacking” a small e-commerce vendor in Massachusetts. Your security dashboard joins the fray by offering its blinking red light, enticing you to investigate a possible intrusion by external parties. Now what? This question is familiar to anyone who has suspected one or more of their computers have been compromised. Once you think one of your organization's assets has been exploited, what do you do next? Do you access the suspect system and review process tables and directory listings for improper entries? Do you check firewall logs for odd entries, only to remember you (like most organizations) only record traffic rejected by the firewall?1 (By definition, rejected traffic can't hurt you. Only packets allowed through the firewall have any effect, unless the dropped packets are the result of a denial-of-service attack.) Do you hire consultants who charge $200+ per hour, hoping they can work a one-week miracle to solve problems your organization created during a five-year period? There must be a better way. My answer is network security monitoring (NSM), defined as the collection, analysis, and escalation of indications and warnings to detect and respond to intrusions. This book is dedicated to NSM and will teach you the tools and techniques to help you implement NSM as a model for security operations. Before describing the principles behind NSM, it's helpful to share an understanding of security terminology. Security professionals have a habit of using multiple terms to refer to the same idea. The definitions here will allow us to understand where NSM fits within an organization's security posture. Readers already familiar with security principles may wish to skim this chapter for highlighted definitions and then ******ebook converter DEMO Watermarks*******

move directly to Chapter 2 for a more detailed discussion of NSM. What Is Security?

Security is the process of maintaining an acceptable level of perceived risk. A former director of education for the International Computer Security Association, Dr. Mitch Kabay, wrote in 1998 that “security is a process, not an end state.”2 No organization can be considered “secure” for any time beyond the last verification of adherence to its security policy. If your manager asks, “Are we secure?” you should answer, “Let me check.” If he or she asks, “Will we be secure tomorrow?” you should answer, “I don't know.” Such honesty will not be popular, but this mind-set will produce greater success for the organization in the long run. During my consulting career I have met only a few high-level executives who truly appreciated this concept. Those who believed security could be “achieved” were more likely to purchase products and services marketed as “silver bullets.”3 Executives who grasped the concept that security is a process of maintaining an acceptable level of perceived risk were more likely to commit the time and resources needed to fulfill their responsibilities as managers. The security process revolves around four steps: assessment, protection, detection, and response (see Figure 1.1).4

1. Assessment is preparation for the other three components. It's stated as a separate action because it deals with policies, procedures, laws, regulations, budgeting, and other managerial duties, plus technical evaluation of one’s security posture. Failure to account for any of these elements harms all of the operations that follow.

2. Protection is the application of countermeasures to reduce the likelihood of compromise. Prevention is an equivalent term, although one of the tenets of this book is that prevention eventually fails.

3. Detection is the process of identifying intrusions. Intrusions are policy violations or computer security incidents. Kevin Mandia and Chris Prosise define an incident as any “unlawful, unauthorized, or

******ebook converter DEMO Watermarks*******

unacceptable action that involves a computer system or a computer network.”5

As amazing as it may sound, external control of an organization's systems is not always seen as a policy violation. When confronting a determined or skilled adversary, some organizations choose to let intruders have their way—as long as the intruders don't interrupt business operations.6 Toleration of the intrusion may be preferred to losing money or data. 4. Response is the process of validating the fruits of detection and taking steps to remediate intrusions. Response activities include “patch and proceed” as well as “pursue and prosecute.” The former approach focuses on restoring functionality to damaged assets and moving on; the latter seeks legal remedies by collecting evidence to support action against the offender.

Figure 1.1. The security process

With this background, let's discuss some concepts related to risk. What Is Risk?

******ebook converter DEMO Watermarks*******

The definition of security mentioned risk, which is the possibility of suffering harm or loss. Risk is a measure of danger to an asset. An asset is anything of value, which in the security context could refer to information, hardware, intellectual property, prestige, and reputation. The risk should be defined explicitly, such as “risk of compromise of the integrity of our customer database” or “risk of denial of service to our online banking portal.” Risk is frequently expressed in terms of a risk equation, where risk = threat × vulnerability × asset value Let's explore the risk equation by defining its terms in the following subsections. Threat

A threat is a party with the capabilities and intentions to exploit a vulnerability in an asset. This definition of threat is several decades old and is consistent with the terms used to describe terrorists. Threats are either structured or unstructured. Structured threats are adversaries with a formal methodology, a financial sponsor, and a defined objective. They include economic spies, organized criminals, terrorists, foreign intelligence agencies, and so-called information warriors.7 Unstructured threats lack the methodology, money, and objective of structured threats. They are more likely to compromise victims out of intellectual curiosity or as an instantiation of mindless automated code. Unstructured threats include “recreational” crackers, malware without a defined object beyond widespread infection, and malicious insiders who abuse their status. Some threats are difficult to classify, but structured threats tend to be more insidious. They pursue long-term systematic compromise and seek to keep their unauthorized access unnoticed. Unstructured threats are less concerned with preventing observation of their activities and in many cases seek the notoriety caused by defacing a Web site or embarrassing a victim. A few examples will explain the sorts of threats we may encounter. First,

******ebook converter DEMO Watermarks*******

consider a threat to the national security of the United States. An evil group might hate the United States, but the group poses a minor threat if it doesn't have the weapons or access to inflict damage on a target. The United States won't create task forces to investigate every little group that hates the superpower. Moving beyond small groups, consider the case of countries like Great Britain or the former Soviet Union. Great Britain fields a potent nuclear arsenal with submarines capable of striking the United States, yet the friendship between the two countries means Great Britain is no threat to American interests (as least as far as nuclear confrontation goes).8 In the 1980s the Soviet Union, with its stockpile of nuclear forces and desire to expand global communism, posed a threat. That nation possessed both capabilities and intentions to exploit vulnerabilities in the American defensive posture. Let's move beyond national security into the cyber realm. A hacking group motivated by political hatred of oil companies and capable of coding attack tools designed for a specific target could be a threat to the Shell oil company. An automated worm unleashed by a malicious party is a threat to every target of the worm's attack vector. A frustrated teenager who wants to “hack” her boyfriend's e-mail account but doesn't understand computers is not a threat. She possesses the intentions but not the capabilities to inflict harm. Threats are expressed within threat models, which are descriptions of the environment into which an asset is introduced. The threat model for the early Internet did not include malicious hackers. The threat model for early Microsoft Windows products did not encompass globally interconnected wide area networks (WANs). The deployment of an asset outside the threat model for which it was designed leads to exploitation. The method by which a threat can harm an asset is an exploit. An exploit can be wielded in real time by a human or can be codified into an automated tool. The process by which the intentions and capabilities of threats are assessed is called threat analysis. The Department of Homeland Security (DHS) Advisory System uses a color-coded chart to express the results of its threat analysis process.9 This chart is a one-word or one-color summarization of the government's assessment of the risk of loss of American interests, such as lives and property. The system has been criticized for its apparent lack of ******ebook converter DEMO Watermarks*******

applicability to normal Americans. Even when the DHS announces an orange alert (a high risk of terrorist attacks), government officials advise the public to travel and go to work as normal. Clearly, these warnings are more suited to public safety officials, who alter their levels of protection and observation in response to DHS advisories. DHS threat conditions (ThreatCons) are based on intelligence regarding the intentions and capabilities of terrorist groups to attack the United States. When the DHS ThreatCon was raised to orange in February 2003, the decision was based on timing (the conclusion of the Muslim pilgrimage, or hajj), activity patterns showing intent (the bombings of a nightclub in Bali in October 2002 and a hotel in Mombasa, Kenya, in November 2002), and capabilities in the form of terrorist communications on weapons of mass destruction.10 Security professionals can perform the same sorts of assessments for the “computer underground,” albeit with lesser tools for collecting information than those possessed by national agencies. Vulnerability

A vulnerability is a weakness in an asset that could lead to exploitation. Vulnerabilities are introduced into assets via poor design, implementation, or containment. Poor design is the fault of the creator of the asset. A vendor writing buggy code creates fragile products; clever attackers will exploit the software's architectural weaknesses. Implementation is the responsibility of the customer who deploys a product. Although vendors should provide thorough documentation on safe use of their wares, customers must ultimately use the product. Containment refers to the ability to reach beyond the intended use of the product. A well-designed software product should perform its intended function and do no more. A Web server intended to publish pages in the inetpub/wwwroot directory should not allow users to escape that folder and access the command shell. Decisions made by vendors and customers affect containment. Asset Value

******ebook converter DEMO Watermarks*******

The asset value is a measurement of the time and resources needed to replace an asset or restore it to its former state. Cost of replacement is an equivalent term. A database server hosting client credit card information is assumed to have a higher value or cost of replacement than a workstation in a testing laboratory. Cost can also refer to the value of an organization's reputation, brand, or trust held by the public. A Case Study on Risk

Putting these terms to work in an example, let's consider the risk to a public Web server operated by the Polish Ministry of Defense (www.wp.mil.pl). On September 3, 2003, Polish army forces assumed control of the Multinational Division Central South in Iraq. A hypothetical anti–Iraq war hacker group, Code Not Bombs, reads the press release at www.nato.int and is angry about Poland's involvement in the war.11 One of their young coders, N@te, doesn't like Poland's involvement and wants to embarrass the Polish military by placing false news stories on the Ministry of Defense's Web site. He discovers that although www.wp.mil.pl is running Apache, its version of OpenSSL is old and subject to a buffer-overflow attack. If N@te so desired, he could accomplish his goal. The Polish military spends $10,000 (or the Polish equivalent) per year maintaining its Web server. Damage to national prestige from an attack would be several times greater. When translating this story into a risk equation, it's fine to use an arbitrary numerical scheme to assign ratings to each factor. In this case, imagine that a 5 is a severe value, while a 1 is a minor value. Parsing this scenario using our terminology, we find the results shown in Table 1.1.

Table 1.1. Sample risk assessment for the Polish army Web server

******ebook converter DEMO Watermarks*******

http://www.wp.mil.pl
http://www.nato.int
http://www.wp.mil.pl
What is the security of the Polish Web server? Remember our definition: Security is the process of maintaining an acceptable level of perceived risk. Assume first that the Polish military is unaware that anyone would think to harm its Web server. If the security administrators believe the threat to www.wp.mil.pl is zero, then their perceived risk of loss is zero. The Polish military organization assesses its Web server to be perfectly secure. Perception is a key to understanding security. Some people are quick to laugh when told, “The world changed on September 11th, 2001.” If the observer perceives little threat, then the risk is perceived to be low and the feeling of security is high. September 11th changed most people's assessment of threats to the American way of life, thereby changing their risk equations. For anyone inside the intelligence community, the world did not change on 9/11. The intelligence community already knew of thousands of potential evildoers and had spent years fighting to prevent harm to the United States. Now assume the Polish military is aware that the computer underground detests the Polish army's participation in reconstructing Iraq. Once threats are identified, the presence of vulnerabilities takes on new importance. Threats are the key to security, yet most people concentrate on vulnerabilities. Researchers announce thousands of software vulnerabilities every year, yet perhaps only a few dozen are actually used for purposes of exploitation. Recognizing the parties that possess the capabilities and intentions to harm a target is more important than trying to patch every vulnerability published on the BugTraq mailing list. ******ebook converter DEMO Watermarks*******

http://www.wp.mil.pl
By knowing who can hurt an organization and how they can do it, security staff can concentrate on addressing critical vulnerabilities first and leaving less severe holes for later. The Simple Network Management Protocol (SNMP) vulnerabilities published in February 2002 received a great deal of attention because most network devices offer management via SNMP.12 However, widespread exploitation of SNMP did not follow.13 Either malicious parties chose not to write code exploiting SNMP, or they did not possess evil intentions for targets operating vulnerable SNMP-enabled devices. (It's also quite possible that hundreds or thousands of SNMP-enabled devices, like routers, were quietly compromised. Routers tend to lie outside the view of many network-based intrusion detection products.) Contrast that vulnerability with many of the discoveries made concerning Windows Remote Procedure Call (RPC) services in 2003.14 Intruders wrote dozens of exploits for Windows RPC services throughout 2003. Automated code like the Blaster worm exploited Windows RPC services and caused upward of a billion U.S. dollars in lost productivity and cleanup.15 Consider again the OpenSSL vulnerability in the Polish Web site. If the Poles are unaware of the existence of the vulnerability, they might assess the security of their Web site as high. Once they read BugTraq, however, they immediately change their perception and recognize the great risk to their server. Countermeasures are needed. Countermeasures are steps to limit the possibility of an incident or the effects of compromise, should N@te attack the Polish Web site. Countermeasures are not explicitly listed in the risk equation, but they do play a role in risk assessment. Applying countermeasures decreases the vulnerability rating, while the absence of countermeasures has the opposite effect. For example, restricting access to www.wp.mil.pl to parties possessing a digital certificate reduces the vulnerability profile of the Web server. Allowing only authorized Internet Protocol (IP) addresses to visit www.wp.mil.pl has a similar effect. Countermeasures can also be applied against the threat. They can act against the offending party's capabilities or intentions. If the Polish government makes a large financial contribution to Code Not Bombs, N@te might change his mind concerning Poland's role in Iraq. If Poland arrests N@te for his earlier compromise of another Web site, then Code Not Bombs has lost its primary cyber-weapon. ******ebook converter DEMO Watermarks*******

http://www.wp.mil.pl
http://www.wp.mil.pl
How do you assess risk when an attacker is not present? The Polish Web site could be hosted on an old 486-class system with a ten-year-old hard drive. Age is not a threat because old hardware is not an active entity with capabilities and intentions. It's better to think in terms of deficiencies, which are flaws or characteristics of an asset that result in failure without an attacker's involvement. Failures due to deficiencies can be considered risks, although reliability is the term more often associated with these sorts of problems. Security Principles: Characteristics of the Intruder

With a common understanding of security terms, we must analyze certain assumptions held by those who practice NSM operations. If you accept these principles, the manner in which NSM is implemented will make sense. Some of these principles are accepted throughout the security community, and others could provoke heated debate. The first set of security principles, presented in this section, address the nature of the attacker. Some Intruders Are Smarter Than You

Let's begin with the principle most likely to cause heartache. As Master Kan said in the pilot of the 1970s Kung Fu television series, “A wise man walks with his head bowed, humble like the dust.” However smart you are, however many years you've studied, however many defenses you've deployed, one day you will face a challenger who possesses more skill, more guile, and more cunning. Don't despair, for Master Kan also said, “[Your spirit] can defeat the power of another, no matter how great.” It is this spirit we shall return to when implementing NSM—plus a few helpful open source tools! This principle doesn't mean all intruders are smarter. For every truly skilled attacker, there are thousands of wanna-be “script kiddies” whose knowledge extends no further than running precompiled exploits. NSM is designed to deal with the absolute worst-case scenario, where an evil mastermind decides to test your network's defenses. Once that situation is covered, everything else is easier to handle. ******ebook converter DEMO Watermarks*******

Many Intruders Are Unpredictable

Not only are some intruders smarter than you, but their activities cannot be predicted. Again, this discussion pertains more accurately to the highest-end attacker. Planning for the worst-case scenario will leave you much better prepared to watch the low-skilled teeming intruder masses bounce off your security walls. Defenders are always playing catch-up. No one talks about “zero-day defenses”; zero-day exploits are privately held programs coded to take advantage of vulnerabilities not known by the public. Vendors have not published patches for the vulnerabilities targeted by zero-day exploits.16 The best intruders save their exploits for the targets that truly matter. The fully patched remote access server offering nothing but the latest OpenSSH service could fall tomorrow. (That's why you can't tell your manager you'll “be secure” tomorrow.) The U.S. military follows the same principles. During the first Gulf War, munitions containing flexible metal strips disabled Iraqi power stations. This simple technique was supposedly kept a secret after chaff was mistakenly dropped on a power station in southern California, disrupting Orange County's electricity supply. Only during the aftermath of the first Gulf War did the technique become publicly acknowledged.17 Prevention Eventually Fails

If at least some intruders are smarter than you and their ways are unpredictable, they will find a way to penetrate your defenses. This means that at some point your preventative measures will fail. When you first accept the principle that prevention eventually fails, your worldview changes. Where once you saw happy, functional servers, all you see now are potential victims. You begin to think of all the information you need to scope and recover from the future intrusion. Believing you will be a victim at some point in the future is like a nonswimmer planning for a white-water rafting trip. It's possible your boat won't flip, but shouldn't you learn to swim in case it (inevitably) does? If you don't believe the rafting analogy, think about jumping from an airplane. Preventing the failure of a skydiver's main chute is impossible; at some point,

******ebook converter DEMO Watermarks*******

for some skydiver, it won't open. Skydivers mitigate this risk by jumping with a reserve chute. This principle doesn't mean you should abandon your prevention efforts. As a necessary ingredient of the security process, it's always preferable to prevent intrusions than to recover from them. Unfortunately, no security professional maintains a 1.000 batting average against intruders. Prevention is a necessary but not sufficient component of security. Security Principles: Phases of Compromise

If we want to detect intrusions, we should understand the actions needed to compromise a target. The five phases described in this section— reconnaissance, exploitation, reinforcement, consolidation, and pillage—are not the only way for an intruder to take advantage of a victim.18 Figure 1.2 illustrates the locations in time and space where intruders may be detected as they compromise victims.

Figure 1.2. The five phases of compromise

******ebook converter DEMO Watermarks*******

The scenario outlined here and in Chapter 4 concentrate on attacks by outsiders. Attacks by outsiders are far more common than those by insiders. Attacks for which insiders are more suited, such as theft of proprietary information, are more devastating. They are not as frequent as the incessant barrage perpetrated by outsiders, as we will see in the discussion in Chapter 2 of the CSI/FBI computer security survey. Recognizing that intruders from the outside are a big problem for networked organizations, we should understand the actions that must be accomplished to gain unauthorized access. Some of the five phases that follow can be ignored or combined. Some intruders may augment these activities or dispense with ******ebook converter DEMO Watermarks*******

them, according to their modus operandi and skill levels. Regardless, knowledge of these five phases of compromise provide a framework for understanding how and when to detect intrusions. Reconnaissance

Reconnaissance is the processes of validating connectivity, enumerating services, and checking for vulnerable applications. Intruders who verify the vulnerability of a service prior to exploitation have a greater likelihood of successfully exploiting a target. Structured threats typically select a specific victim and then perform reconnaissance to devise means of compromising their target. Reconnaissance helps structured threats plan their attacks in the most efficient and unobtrusive manner possible. Reconnaissance can be technical as well as nontechnical, such as gathering information from dumpsters or insiders willing to sell or share information. Unstructured threats often dispense with reconnaissance. They scan blocks of IP addresses for systems offering the port for which they have an exploit. Offensive code in the 1990s tended to check victim systems to determine, at least on a basic level, whether the victim service was vulnerable to the chosen attack. For example, a black hat19 might code a worm for Microsoft Internet Information Server (IIS) that refused to waste its payload against the Apache Web servers. In recent years, offensive code—especially against Windows systems—has largely dispensed with reconnaissance and simply launched exploits against services without checking for applicability. For example, SQL Slammer is fired at random targets, regardless of whether or not they are running the SQL resolution service on port 1434 User Datagram Protocol (UDP). Sometimes the trade-off in speed is worth forgoing reconnaissance. For a worm like W32/Blaster, connection to port 135 Transmission Control Protocol (TCP) is itself a good indication the target is a Windows system because UNIX machines do not offer services on that port.20 An exception to this “fire and forget” trend was the Apache/mod_ssl worm, which performed a rudimentary check for vulnerable OpenSSL versions before launching its attack.21 Assume an intruder uses IP Address 1 as the source of the traffic used to ******ebook converter DEMO Watermarks*******

profile the target. At this point the attacker probably has complete control (hereafter called root access) of his workstation but no control over the target. This limits his freedom of movement. To validate connectivity, he may send one or more “odd” or “stealth” packets and receive some sort of reply. When enumerating services, he may again rely on slightly out-of- specification packets and still receive satisfactory results. However, to determine the version of an application, such as a Web server, he must speak the target's language and follow the target's rules. In most cases an intruder cannot identify the version of Microsoft's IIS or the Internet Software Consortium's Berkeley Internet Name Daemon (BIND) without exchanging valid TCP segments or UDP datagrams. The very nature of his reconnaissance activities will be visible to the monitor. Exceptions to this principle include performing reconnaissance over an encrypted channel, such as footprinting a Web server using Secure Sockets Layer (SSL) encryption on port 443 TCP. Many of the so-called stealthy reconnaissance techniques aren't so stealthy at all. Traditional stealth techniques manipulate TCP segment headers, especially the TCP flags (SYN, FIN, ACK, and so on), to evade unsophisticated detection methods. Modern intrusion detection systems (IDSs) easily detect out-of-specification segments. The best way for an intruder to conduct truly stealthy reconnaissance is to appear as normal traffic. Exploitation

Exploitation is the process of abusing, subverting, or breaching services on a target. Abuse of a service involves making illegitimate use of a legitimate mode of access. For example, an intruder might log in to a server over Telnet, Secure Shell, or Microsoft Terminal Services using a username and password stolen from another system. Subversion involves making a service perform in a manner not anticipated by its programmers. The designers of Microsoft's IIS Web server did not predict intruders would exploit the method by which Unicode characters were checked against security policies. This oversight led to the Web Server Folder Directory Traversal vulnerability described by CERT in 2000.22 To breach a service is to “break” it—to stop it from

******ebook converter DEMO Watermarks*******

running and potentially to assume the level of privilege the process possessed prior to the breach. This differs from subversion, which does not interrupt service. Modern exploit code often restarts the exploited service, while the attacker makes use of the privileges assumed during the original breach. Like the enumeration of services phase of reconnaissance, delivery of an exploit normally takes place via everyday protocols. Because intruders still are in full control of only their workstations, with no influence over their targets prior to exploitation, intruders must speak proper protocols with their victims. Since the attackers must still follow the rules, you have a chance to detect their activities. In some cases the intruders need not follow any rules because vulnerable services die when confronted by unexpected data. Limitations caused by encryption remain. Furthermore, the capability for IDSs to perform real-time detection (i.e., to generate an alert during exploitation) can be degraded by the use of novel or zero-day attacks. In this respect, the backward-looking network traffic audit approach used by NSM is helpful. Knowledgeable intruders will launch exploits from a new IP address (e.g., IP Address 2, in the case of our hypothetical intruder mentioned earlier). Reinforcement

Reinforcement is the stage when intruders really flex their muscles. Reinforcement takes advantage of the initial mode of unauthorized access to gain additional capabilities on the target. While some exploits yield immediate remote root-level privileges, some provide only user-level access. The attackers must find a way to elevate their privileges and put those ill- gotten gains to work. At this point the intruders may have root control over both their own workstations and those of their victims. The intruders leverage their access on the victims to retrieve tools, perhaps using File Transfer Protocol (FTP) or Trivial FTP (TFTP). More advanced intruders use Secure Copy (SCP) or another encrypted derivative, subject to the limitations imposed by their current privilege levels. The most advanced intruders transfer their tools through the same socket used to exploit the victims.

******ebook converter DEMO Watermarks*******

In the case of our hypothetical intruder, when he retrieves his tools, they will be stored at a new system at IP Address 3. This is another machine under the intruder's control. The attacker's tools will contain applications to elevate privileges if necessary, remove host-based log entries, add unauthorized accounts, and disguise processes, files, and other evidence of his illegitimate presence. Most significantly, skilled intruders will install a means to communicate with the outside world. Such covert channels range from simple encrypted tunnels to extremely complicated, patient, low-bandwidth signaling methods. Security professionals call these means of access back doors. Consolidation

Consolidation occurs when the intruder communicates with the victim server via the back door. The back door could take the form of a listening service to which the intruder connects. It could also be a stateless system relying on sequences of specific fields in the IP, TCP, UDP, or other protocol headers. In our hypothetical case, IP Address 4 is the address of the intruder, or his agent, as he speaks with the victim. A second option involves the intruder's back door connecting outbound to the intruder's IP address. A third option causes the victim to call outbound to an Internet Relay Chat (IRC) channel, where the intruder issues instructions via IRC commands. Often the intruder verifies the reliability of his back door and then “runs silent,” not connecting to his victim for a short period of time. He'll return once he's satisfied no one has discovered his presence. When covert channels are deployed, the ability of the analyst to detect such traffic can be sorely tested. Truly well-written covert channels appear to be normal traffic and may sometimes be detected only via laborious manual analysis of full content traffic. At this stage the intruder has complete control over his workstation and the target. The only limitations are those imposed by network devices filtering traffic between the two parties. This key insight will be discussed more fully in Chapter 3 when we discuss packet scrubbing. You may wonder why an intruder needs to install a back door. If he can access a victim using an exploitation method, why alter the victim and give clues to his presence? Intruders deploy back doors because they cannot rely

******ebook converter DEMO Watermarks*******

on their initial exploitation vector remaining available. First, the exploit may crash the service, requiring a reboot or process reinitialization. Second, the system administrator may eventually patch the vulnerable service. Third, another attacking party may exploit the victim and patch the vulnerable service. Intruders often “secure” unpatched services to preserve their hold on victim servers. Use of a back door is less likely to attract attention from IDSs. Pillage

Pillage is the execution of the intruder's ultimate plan. This could involve stealing sensitive information, building a base for attacks deeper within the organization, or anything else the intruder desires. In many cases the intruder will be more visible to the network security analyst at this point, as attacking other systems may again begin with reconnaissance and exploitation steps. Unfortunately, intruders with a beachhead into an organization can frequently dispense with these actions. From the intruders' vantage point they may observe the behavior and traffic of legitimate users. The intruders can assume the users' identities by obtaining credentials and abusing privileges. Because most organizations focus their prevention and detection operations toward external intruders, an attacker already inside the castle walls may go largely unnoticed. We can assess the chances of detection at each of the five phases of compromise. Table 1.2 highlights when and where detection can occur.

Table 1.2. Detecting intruders during the five phases of compromise

******ebook converter DEMO Watermarks*******

Throughout this book, we will examine intruder actions and the network traffic associated with those activities. Familiarity with these patterns enables defenders to apply their understanding across multiple protection and detection products. Like design patterns in software development, an understanding of intruder activities will bear more fruit than intimate knowledge of one or two exploits sure to become dated in the years to come. Security Principles: Defensible Networks

I use the term defensible networks to describe enterprises that encourage, rather than frustrate, digital self-defense. Too many organizations lay cables

******ebook converter DEMO Watermarks*******

and connect servers without giving a second thought to security consequences. They build infrastructures that any army of defenders could never protect from an enemy. It's as if these organizations used chain-link fences for the roofs of their buildings and wonder why their cleaning staff can't keep the floors dry. This section describes traits possessed by defensible networks. As you might expect, defensible networks are the easiest to monitor using NSM principles. Many readers will sympathize with my suggestions but complain that their management disagrees. If I'm preaching to the choir, at least you have another hymn in your songbook to show to your management. After the fifth compromise in as many weeks, perhaps your boss will listen to your recommendations! Defensible Networks Can Be Watched

This first principle implies that defensible networks give analysts the opportunity to observe traffic traversing the enterprise's networks. The network was designed with monitoring in mind, whether for security or, more likely, performance and health purposes. These organizations ensure every critical piece of network infrastructure is accessible and offers a way to see some aspects of the traffic passing through it. For example, engineers equip Cisco routers with the appropriate amount of random access memory (RAM) and the necessary version of Internetwork Operating System (IOS) to collect statistics and NetFlow data reflecting the sort of traffic carried by the device. Technicians deploy switches with Switched Port ANalyzer (SPAN) access in mind. If asymmetric routing is deployed at the network edge, engineers use devices capable of making sense of the mismatched traffic patterns. (This is a feature of the new Proventia series of IDS appliances announced by Internet Security Systems, Inc., in late 2003.) If the content of encrypted Web sessions must be analyzed, technicians attach IDSs to SSL accelerators that decrypt and reencrypt traffic on the fly. A corollary of this principle is that defensible networks can be audited. “Accountants” can make records of the “transactions” occurring across and through the enterprise. Analysts can scrutinize these records for signs of misuse and intrusion. Network administrators can watch for signs of

******ebook converter DEMO Watermarks*******

misconfiguration, saturation, or any other problems impeding performance. Networks that can be watched can also be baselined to determine what is normal and what is not. Technicians investigate deviations from normalcy to identify problems. A second corollary is that defensible networks are inventoried. If you can watch everything, you should keep a list of what you see. The network inventory should account for all hosts, operating systems, services, application versions, and other relevant aspects of maintaining an enterprise network. You can't defend what you don't realize you possess. Defensible Networks Limit an Intruder's Freedom to Maneuver

This second principle means attackers are not given undue opportunity to roam across an enterprise and access any system they wish. This freedom to maneuver takes many forms. I've encountered far too many organizations whose entire enterprise consists of publicly routable IP addresses. The alternative, network address translation (NAT), translates one or more public IP addresses across a range of private addresses. Internet purists feel this is an abomination, having “broken” end-to-end connectivity. When multiple private addresses are hidden behind one or more public IPs, it's more difficult to directly reach internal hosts from the outside. The security benefits of NAT outweigh the purists' concerns for reachability. NAT makes the intruder's job far more difficult, at least until he or she compromises a host behind the router or firewall implementing NAT. Beyond directly limiting reachability of internal IP addresses, reducing an intruder's freedom to maneuver applies to the sorts of traffic he or she is allowed to pass across the enterprise's Internet gateways. Network administrators constantly battle with users and management to limit the number of protocols passed through firewalls. While inbound traffic filtering (sometimes called ingress filtering) is generally accepted as a sound security strategy, outbound filtering (or egress filtering) is still not the norm. Networks that deny all but the absolutely necessary inbound protocols reduce the opportunities for reconnaissance and exploitation. Networks that deny all but mission-critical outbound protocols reduce the chances of successful reinforcement and consolidation. These same sorts of restrictions should be

******ebook converter DEMO Watermarks*******

applied to the IP addresses allowed to transit Internet gateways. An organization should not allow traffic spoofing Microsoft's address space to leave its enterprise, for example.

How Else Can Administrators Limit an Intruder's Freedom to Maneuver?

Ron Gula, CTO of Tenable Network Security and creator of the Dragon IDS, offers the following advice:

When deploying defense-in-depth solutions, many enterprise networks forget that their switches come with a robust set of features to limit access to the network at the port level. Protocols like 802.1x allow any system attached to a switch to get a minimal access control policy. For example, all default servers could be configured this way to access the Internet with a bandwidth of 1 Mbps and offer no services. A legal Web server could be configured to offer Web services to just the allowed visitors, but management traffic could be sent from just the administrators. When enterprises turn this basic form of policy enforcement on, they can immediately see a reduction in scanning, intrusion attempts, and exposed vulnerabilities.23

An open source implementation of 802.1x is being developed at http://open1x.sourceforge.net. An open source RADIUS server to perform authentication is available at http://www.freeradius.org.

An additional element of limiting an intruder's traffic involves scrubbing traffic that doesn't meet predefined norms. Scrubbing is also called normalization, which is the process of removing ambiguities in a traffic stream. Ambiguities take the form of fragmented packets, unusual combinations of TCP flags, low Time to Live (TTL) values, and other aspects of traffic. The concept was formally pioneered by Mark Handley and Vern Paxson in 2001.24 The OpenBSD firewall, Pf, offers an open source ******ebook converter DEMO Watermarks*******

http://open1x.sourceforge.net
http://www.freeradius.org
implementation of scrubbing. Chapter 3 describes how to set up an OpenBSD firewall running Pf and performing packet scrubbing. Traffic normalization reduces an intruder's ability to deploy certain types of covert channels that rely on manipulating packet headers. Defensible Networks Offer a Minimum Number of Services

There's nothing mysterious about penetrating computers. Aside from certain vulnerabilities in applications that listen promiscuously (like Tcpdump and Snort), every remote server-side exploit must target an active service.25 It follows that disabling all unnecessary services improves the survivability of a network. An attacker with few services to exploit will lack the freedom to maneuver. Where possible, deploy operating systems that allow minimal installations, such as the various BSD distributions. An intruder who gains local access should find a system running with the bare necessities required to accomplish the business's objectives. A system without a compiler can frustrate an intruder who needs to transform source code into an exploit. Consider using operating systems that provide services within a “jail,” a restricted environment designed to operate exposed network services.26 Defensible Networks Can Be Kept Current

This principle refers to the fact that well-administered networks can be patched against newly discovered vulnerabilities. Although I'm not a big fan of Microsoft's products, I must advocate upgrading to its latest and greatest software offerings. What's the latest patch for Windows NT 4.0? It's called Windows Server 2003. This is no joke. Microsoft and other vendors retire old code for a purpose. Flaws in the design or common implementations of older products eventually render them unusable. “Unusable” here means “not capable of being defended.” Some might argue that certain code, like Plan 9, doesn't need to be abandoned for newer versions. Also, using sufficiently old code reduces the number of people familiar with it. You'd be hard pressed to find someone active in the modern computer underground who could exploit software from ten or twenty years ago.

******ebook converter DEMO Watermarks*******

Most intrusions I've encountered on incident response engagements were the result of exploitation of known vulnerabilities. They were not caused by zero- day exploits, and the vulnerabilities were typically attacked months after the vendor released a patch. Old systems or vulnerable services should have an upgrade or retirement plan. The modern Internet is no place for a system that can't defend itself. Conclusion

This chapter introduced the security principles on which NSM is based. NSM is the collection, analysis, and escalation of indications and warnings to detect and respond to intrusions, a topic more fully explained in Chapter 2. Security is the process of maintaining an acceptable level of perceived risk; it is a process, not an end state. Risk is the possibility of suffering harm or loss, a measure of danger to an asset. To minimize risk, defenders must remain ever vigilant by implementing assessment, protection, detection, and response procedures. Intruders bring their own characteristics to the risk equation. Some of them are smarter than the defenders they oppose. Intruders are often unpredictable, which contributes to the recognition that prevention inevitably fails. Thankfully, defenders have a chance of detecting intruders who communicate with systems they compromise. During reconnaissance, exploitation, reinforcement, consolidation, or pillage, an intruder will most likely provide some form of network-based evidence worthy of investigation by a defender. Successfully implementing a security process requires maintaining a network capable of being defended. So-called defensible networks can be watched and kept up-to-date. Defensible networks limit an intruder's freedom to maneuver and provide the least number of potential targets by minimizing unnecessary services. With this understanding of fundamental security principles, we can now more fully explore the meaning and implications of NSM.

******ebook converter DEMO Watermarks*******

******ebook converter DEMO Watermarks*******

2. What Is Network Security Monitoring?

Now that we've forged a common understanding of security and risk and examined principles held by those tasked with identifying and responding to intrusions, we can fully explore the concept of NSM. In Chapter 1, we defined NSM as the collection, analysis, and escalation of indications and warnings to detect and respond to intrusions. Examining the components of the definition, which we do in the following sections, will establish the course this book will follow. Indications and Warnings

It makes sense to understand what we plan to collect, analyze, and escalate before explaining the specific meanings of those three terms in the NSM definition. Therefore, we first investigate the terms indications and warnings. Appreciation of these ideas helps put the entire concept of NSM in perspective. The U.S. Department of Defense Dictionary of Military Terms defines an indicator as “an item of information which reflects the intention or capability of a potential enemy to adopt or reject a course of action.”1 I prefer the definition in a U.S. Army intelligence training document titled “Indicators in Operations Other Than War.”2 The Army manual describes an indicator as “observable or discernible actions that confirm or deny enemy capabilities and intentions.” The document then defines indications and warning (I&W) as “the strategic monitoring of world military, economic and political events to ensure that they are not the precursor to hostile or other activities which are contrary to U.S. interests.” I&W is a process of strategic monitoring that analyzes indicators and produces warnings.3 We could easily modify the definition of indicator as stated by the Army manual and define digital I&W as the strategic monitoring of network traffic to assist in the detection and validation of intrusions.

******ebook converter DEMO Watermarks*******

Observe that the I&W process is focused against threats. It is not concerned with vulnerabilities, although the capability of a party to harm an asset is tied to weaknesses in an asset. Therefore, NSM, and IDS products, focus on threats. In contrast, vulnerability assessment products are concerned with vulnerabilities. While some authors consider vulnerability assessment “a special case of intrusion detection,” 4 logic shows vulnerabilities have nothing to do with threats. Some vulnerability-oriented products and security information management suites incorporate “threat correlation” modules that simply apply known vulnerabilities to assets. There are plenty of references to threats but no mention of parties with capabilities and intentions to exploit those vulnerabilities. Building on the Army intelligence manual, we define indications (or indicators) as observable or discernible actions that confirm or deny enemy capabilities and intentions. In the world of NSM, indicators are outputs from products. They are the conclusions formed by the product, as programmed by its developer. Indicators generated by IDSs are typically called alerts. The Holy Grail for IDS vendors is 100% accurate intrusion detection. In other words, every alert corresponds to an actual intrusion by a malicious party. Unfortunately, this will never happen. IDS products lack context. Context is the ability to understand the nature of an event with respect to all other aspects of an organization's environment. As a simple example, imagine a no-notice penetration test performed by a consulting firm against a client. If the assessment company successfully compromises a server, an IDS might report the event as an intrusion. For all intents and purposes, it is an intrusion. However, from the perspective of the manager who hired the consulting firm, the event is not an intrusion. Consider a second example. The IDS could be configured to detect the use of the PsExec tool and report it as a “hacking incident.”5 PsExec allows remote command execution on Windows systems, provided the user has appropriate credentials and access. The use of such a tool by an unauthorized party could indicate an attack. Simultaneously, authorized system administrators could use PsExec to gain remote access to their servers. The granularity of policy required to differentiate between illegitimate and legitimate use of such a tool is beyond the capabilities of most institutions and probably not worth the effort! As a result, humans must make the call. ******ebook converter DEMO Watermarks*******

All indicators have value, but some have greater value. An alert stating a mail server has initiated an outbound FTP session to a host in Russia is an indicator. A spike in the amount of Internet Control Message Protocol (ICMP) traffic at 2 A.M. is another indicator. Generally speaking, the first indicator has more value than the second, unless the organization has never used ICMP before. Warnings are the results of an analyst's interpretation of indicators. Warnings represent human judgments. Analysts scrutinize the indicators generated by their products and forward warnings to decision makers. If indicators are similar to information, warnings are analogous to finished intelligence. Evidence of reconnaissance, exploitation, reinforcement, consolidation, and pillage are indicators. A report to management that states “Our mail server is probably compromised” is a warning. It's important to understand that the I&W process focuses on threats and actions that precede compromise, or in the case of military action, conflict. As a young officer assigned to the Air Intelligence Agency, I attended an I&W course presented by the Defense Intelligence Agency (DIA). The DIA staff taught us how to conduct threat assessment by reviewing indicators, such as troop movements, signals intelligence (SIGINT) transcripts, and human intelligence (HUMINT) reports. One of my fellow students asked how to create a formal warning report once the enemy attacks a U.S. interest. The instructor laughed and replied that at that point, I&W goes out the window. Once you've validated enemy action, there's no need to assess their intentions or capabilities. Similarly, the concept of I&W within NSM revolves around warnings. It's rare these days, in a world of encryption and high-speed networks, to be 100% sure that observed indicators reflect a true compromise. It's more likely the analysts will collect clues that can be understood only after additional collection is performed against a potential victim. Additional collection could be network-based, such as recording all traffic to and from a possible compromised machine. Alternatively, investigators could follow a host-based approach by performing a live forensic response on a suspect victim server.6 This contrast between the military and digital security I&W models is important. The military and intelligence agencies use I&W to divine future

******ebook converter DEMO Watermarks*******

events. They form conclusions based on I&W because they have imperfect information on the capabilities and intentions of their targets. NSM practitioners use I&W to detect and validate intrusions. They form conclusions based on digital I&W because they have imperfect perception of the traffic passing through their networks. Both communities make educated assessments because perfect knowledge of their target domain is nearly impossible.7 Collection, Analysis, and Escalation

We now appreciate that NSM is concerned with I&W. According to the NSM definition, indicators are collected and analyzed, and warnings are escalated. In the NSM world, distinct components are responsible for these actions. Products perform collection. A product is a piece of software or an appliance whose purpose is to analyze packets on the network. Products are needed on high-speed networks because people cannot interpret traffic without assistance. I discuss numerous NSM products in Part II of this book. People perform analysis. While products can form conclusions about the traffic they see, people are required to provide context. Acquiring context requires placing the output of the product in the proper perspective, given the nature of the environment in which the product operates. Because few products are perfectly customized for the networks they monitor, people increasingly complement deficiencies in software. This is not the fault of the developer, who cannot possibly code his product to meet all of the diverse needs of potential customers. On the other hand, it is an endorsement of open source software. Being free to accept modifications by end users, open source software is best suited for customization. Just as products must be tuned for the local environment, people must be trained to understand the information generated by their products. Part IV gives suggestions for training analysts. Processes guide escalation. Escalation is the act of bringing information to the attention of decision makers. Decision makers are people who have the authority, responsibility, and capability to respond to potential incidents. Without escalation, detection is virtually worthless. Why detect events if no one is responsible for response? ******ebook converter DEMO Watermarks*******

Detecting and Responding to Intrusions

Detection and response are the two most important of the four elements of the security process we discussed in Chapter 1. Since prevention eventually fails, organizations must maintain the capability to quickly determine how an intruder compromised a victim and what the intruder did after gaining unauthorized access. This response process is called scoping an incident. “Compromise” doesn't always mean “obtain root access.” An intruder who leverages the privileges given to him or her by a flawed database is just as deadly as the attacker who obtains administrator access on a Windows host. Anyone who has performed incident response on a regular basis quickly learns the priorities of decision makers. Managers, chief information officers, and legal staff don't care how an intruder penetrated their defenses. They typically ask the following questions. • What did the intruder do? • When did he or she do it? • Does the intruder still have access? • How bad could the compromise be? Answers to these questions guide the decision makers' responses. If executives don't care how an intrusion was detected, it doesn't matter how the compromise is first discovered. No one asks, “Did our intrusion detection system catch this?” NSM analysts turn this fact to their advantage, using the full range of information sources available to detect intrusions. It doesn't matter if the hint came from a firewall log, a router utilization graph, an odd NetFlow record, or an IDS alarm. Smart analysts use all of these indicators to detect intrusions. Although executives don't care about the method of intrusion, it means the world to the incident responders who must clean up the attacker's mess. Only by identifying the method of access and shutting it down can responders be confident in their remediation duties. Beyond disabling the means by which the intruder gained illegitimate access, incident responders must ensure their enterprise doesn't offer other easy paths to compromise. Why patch a weak IIS Web server if the same system runs a vulnerable version of Microsoft ******ebook converter DEMO Watermarks*******

RPC services? When determining a postincident course of action, the work of vulnerability assessment products becomes important. Assessment tools can identify “low- hanging fruit” and guide remediation actions once evidence necessary to “patch and proceed” or “pursue and prosecute” is gathered.8 Over the course of my career I've noted a certain tension among those who try to prevent intrusions, those who detect them, and those who respond to them. All three groups should come together in the incident response process to devise the most efficient plan to help the organization recover and move forward. The three parties can contribute expertise in the following manner. The prevention team should share the security posture of the organization with the detection and response teams. This knowledge helps guide the detection and response processes, which in return verifies the effectiveness of the prevention strategy. The detection team should guide the responders to likely candidates for in-depth, host-based analysis, while letting the preventers know which of their proactive measures failed. The response team should inform the detection folks of the new exploits or back doors not seen by the NSM operation. The response team can also guide the prevention strategy to reduce the risk of future incidents. Should any new policies or reviews be required, the assessment team should be kept in the loop as well. Remember that intrusions are policy violations. Outsiders or insiders can be responsible for these transgressions. Although NSM data is helpful for identifying network misconfigurations, determining resource use, and tracking employee Web surfing habits, its legitimate focus is identifying intrusions. Why Do IDS Deployments Often Fail?

It seems the number of disgruntled IDS owners exceeds the number of satisfied customers. Why are IDS deployments prone to failure? The answer lies in the comparison among “must-have” products of the 1990s. The must- have security product of the mid-1990s was the firewall. A properly configured firewall implements access control (i.e., the limitation of access to systems and services based on a security policy). Once deployed, a firewall provides a minimal level of protection. If told to block traffic from the ******ebook converter DEMO Watermarks*******

Internet to port 111 TCP, no one need ever check that it is doing its job. (The only exception involves unauthorized parties changing the firewall's access control rules.) This is a technical manager's dream: buy the box, turn the right knobs, and push it out the door. It does its job with a minimum amount of attention. After the firewall, security managers learned of IDSs. In the late 1990s the IDS became the must-have product. Commercial vendors like Internet Security Systems, the Wheel Group (acquired by Cisco in February 1998), and Axent (acquired by Symantec in July 2000) were selling IDS software by fall 1997. Articles like those in a September 1997 issue of InternetWeek praised IDSs as a “layer of defense that goes beyond the firewall.”9 Even the Gartner Group, now critical of intrusion detection products, was swept up in the excitement. In that InternetWeek article, the following opinion appeared:

In the past, intrusion detection was a very labor-intensive, manual task, said Jude O'Reilley, a research analyst at Gartner Group's network division, in Stamford, Conn. “However, there's been a leap in sophistication over the past 18 months,” and a wider range of automated tools is hitting the market, he said.

Technical managers treated IDS deployments as firewall deployments: buy, configure, push out the door. This model does not work for IDSs. A firewall performs prevention, and an IDS performs detection. A firewall will prevent some attacks without any outside supervision. An IDS will detect some attacks, but a human must interpret, escalate, and respond to its warnings. If you deploy an IDS but never review its logs, the system serves no purpose. Successful IDS deployments require sound products, trained people, and clear processes for handling incidents. It is possible to configure most IDSs as access control devices. Features for implementing “shunning” or “TCP resets” turn the IDS from a passive observer into an active network participant. I am personally against this idea except where human intervention is involved. Short-term incident containment may merit activating an IDS's access control features, but the IDS should be returned to its network audit role as soon as the defined access control device (e.g., a filtering router or firewall) is configured to limit or deny intruder activity. ******ebook converter DEMO Watermarks*******

Outsiders versus Insiders: What Is NSM's Focus?

This book is about network security monitoring. I use the term network to emphasize the book's focus on traffic and incidents that occur over wires, radio waves, and other media. This book does not address intruders who steal data by copying it onto a USB memory stick or burning it to a CD-ROM. Although the focus for much of the book is on outsiders gaining unauthorized access, it pertains equally well to insiders who transfer information to remote locations. In fact, once an outsider has local access to an organization, he or she looks very much like an insider.10 Should this book (and NSM) pay more attention to insiders? One of the urban myths of the computer security field holds that 80% of all attacks originate from the inside. This “statistic” is quoted by anyone trying to sell a product that focuses on detecting attacks by insiders. An analysis of the most respected source of computer security statistics, the Computer Crime and Security Survey conducted annually by the Computer Security Institute (CSI) and the FBI, sheds some light on the source and interpretation of this figure.11 The 2001 CSI/FBI study quoted a commentary by Dr. Eugene Schultz that first appeared in the Information Security Bulletin. Dr. Schultz was asked:

I keep hearing statistics that say that 80 percent of all attacks are from the inside. But then I read about all these Web defacements and distributed denial of service attacks, and it all doesn't add up. Do most attacks really originate from the inside?

Dr. Schultz responded:

There is currently considerable confusion concerning where most attacks originate. Unfortunately, a lot of this confusion comes from the fact that some people keep quoting a 17-year-old FBI statistic that indicated that 80 percent of all attacks originated from the [inside]. . . . Should [we] ignore the insider threat in favor of the outsider threat? On the contrary. The insider threat remains the

******ebook converter DEMO Watermarks*******

greatest single source of risk to organizations. Insider attacks generally have far greater negative impact to business interests and operations. Many externally initiated attacks can best be described as ankle-biter attacks launched by script kiddies. But what I am also saying is that it is important to avoid underestimating the external threat. It is not only growing disproportionately, but is being fueled increasingly by organized crime and motives related to espionage. I urge all security professionals to conduct a first-hand inspection of their organization's firewall logs before making a claim that most attacks come from the inside. Perhaps most successful attacks may come from the inside (especially if an organization's firewalls are well configured and maintained), true, but that is different from saying that most attacks originate from the inside.12

Dr. Dorothy Denning, some of whose papers are discussed in Appendix B, confirmed Dr. Shultz's conclusions. Looking at the threat, noted by the 2001 CSI/FBI study as “likely sources of attack,” Dr. Denning wrote in 2001:

For the first time, more respondents said that independent hackers were more likely to be the source of an attack than disgruntled or dishonest insiders (81% vs. 76%). Perhaps the notion that insiders account for 80% of incidents no longer bears any truth whatsoever.13

The 2002 and 2003 CSI/FBI statistics for “likely sources of attack” continued this trend. At this point, remember that the statistic in play is “likely sources of attack,” namely the party that embodies a threat. In addition to disgruntled employees and independent hackers, other “likely sources of attack” counted by the CSI/FBI survey include foreign governments (28% in 2003), foreign corporations (25%), and U.S. competitors (40%). Disgruntled employees are assumed to be insiders (i.e., people who can launch attacks from inside an organization) by definition. Independent hackers are assumed to not be insiders. But from where do attacks actually originate? What is the vector to the target? The CSI/FBI study asks

******ebook converter DEMO Watermarks*******

respondents to rate “internal systems,” “remote dial-in,” and “Internet” as “frequent points of attack.” In 2003, 78% cited the Internet, while only 30% cited internal systems and 18% cited dial-in attacks. In 1999 the Internet was cited at 57% while internal systems rated 51%. These figures fly in the face of the 80% statistic. A third figure hammers the idea that 80% of all attacks originate from the inside. The CSI/FBI study asks for the origin of incidents involving Web servers. For the past five years, incidents caused by insiders accounted for 7% or less of all Web intrusions. In 2003, outsiders accounted for 53%. About one-quarter of respondents said they “don't know” the origin of their Web incidents, and 18% said “both” the inside and outside participated. At this point the idea that insiders are to blame should be losing steam. Still, the 80% crowd can find solace in other parts of the 2003 CSI/FBI study. The study asks respondents to rate “types of attack or misuse detected in the last 12 months.” In 2003, 80% of participants cited “insider abuse of net access” as an “attack or misuse,” while only 36% confirmed “system penetration.” “Insider abuse of net access” apparently refers to inappropriate use of the Internet; as a separate statistic, “unauthorized access by insiders” merited a 45% rating. If the insider advocates want to make their case, they should abandon the 80% statistic and focus on financial losses. The 2003 CSI/FBI study noted “theft of proprietary information” cost respondents over $70 million; “system penetration” cost a measly $2.8 million. One could assume that insiders accounted for this theft, but that might not be the case. The study noted “unauthorized access by insiders” cost respondents only $406,000 in losses.14 Regardless of your stance on the outsider versus insider issue, any activity that makes use of the network is a suitable focus for analysis using NSM. Any illicit action that generates a packet becomes an indicator for an NSM operation. One of the keys to devising a suitable NSM strategy for your organization is understanding certain tenets of detection, outlined next. Security Principles: Detection

Detection lies at the heart of the NSM operation, but it is not the ultimate goal

******ebook converter DEMO Watermarks*******

of the NSM process. Ideally, the NSM operation will detect an intrusion and guide incident response activities prior to incident discovery by outside means. Although it is embarrassing for an organization to learn of compromise by getting a call from a downstream victim or customer whose credit card number was stolen, these are still legitimate means of detecting intrusions. As mentioned in Chapter 1, many intruders are smart and unpredictable. This means that people, processes, and products designed to detect intrusions are bound to fail, just as prevention inevitably fails. If both prevention and detection will surely fail, what hope is there for the security-minded enterprise? NSM's key insight is the need to collect data that describes the network environment to the greatest extent possible. By keeping a record of the maximum amount of network activity allowed by policy and collection hardware, analysts buy themselves the greatest likelihood of understanding the extent of intrusions. Consider a connectionless back door that uses packets with PSH and ACK flags and certain other header elements to transmit information. Detecting this sort of covert channel can be extremely difficult until you know what to monitor. When an organization implements NSM principles, it has a higher chance of not only detecting that back door but also keeping a record of its activities should detection happen later in the incident scenario. The following principles augment this key NSM insight. Intruders Who Can Communicate with Victims Can Be Detected