[ISN] Honeypots: Simple, Cost-Effective Detection

From: InfoSec News (isnat_private)
Date: Thu May 01 2003 - 01:01:08 PDT

  • Next message: InfoSec News: "[ISN] Former Cybersecurity Czar To Join Ebay"

    http://www.securityfocus.com/infocus/1690
    
    by Lance Spitzner, www.tracking-hackers.com 
    last updated April 30, 2003 
    
    This is the fourth article in an ongoing series examining honeypots.  
    In previous installments, we have covered two different honeypot
    solutions: Honeyd and Specter. Both honeypots are low-interaction
    production solutions; their purpose is to help protect organizations,
    as opposed to research honeypots, which are used to gather
    information. Production honeypots work by emulating a variety of
    services and operating systems. Honeyd, an OpenSource solution, is
    considered more powerful and flexible than Specter, but it is also
    more difficult to use. Specter, a commercially supported solution, is
    easier to use as it runs on Windows. In this paper we take a step back
    for a moment and discuss the value of honeypot technologies in
    general. Why would you want to deploy production honeypots in your
    organization? How can a honeypot help security professionals to do
    their job more effectively?
    
    As you are about to find out, the answer is very simple: honeypots are
    a simple, cost-effective way to detect illicit, unauthorized activity.  
    This article will examine the role of detection in the overall
    security strategy. It will then discuss some traditional detection
    approaches as well as some problems inherent in those approaches. It
    will then show how honeypots effectively overcome those problems,
    thereby strengthening the detection component of the security
    strategy.
    
    What is Detection?
    
    Many organizations approach security as three different layers:  
    prevention, detection, and response. Prevention is the process of
    keeping the bad guys out. Detection is consists of identifying there
    is a failure in prevention and alerting systems administrators
    accordingly. Finally, response is the way in which the organization
    reacts to the security incident. Of the three, I consider detection to
    be the most critical. No matter what preventative technologies,
    processes, or programs are in place, sooner or later there will be a
    failure. The simple reason for this is that security is based on
    humans, and humans make mistakes. When such a failure happens, it is
    critical that security personnel quickly identify and react to it.
    
    The advantages to effective detection are twofold. First, by quickly
    identifying unauthorized activity, you may be able to stop an attack
    before it happens. For example, if you detect someone on your internal
    network scanning for open file shares, you can identify and stop that
    person before they find any files they should not have access to.  
    Second, timely detection can be used to mitigate a successful
    compromise. If you quickly determine that a system or resource has
    been taken over, you can isolate and recover the system. However, if
    an attacker takes over your mail server, and its not discovered for
    over a month, extensive damage can be done as they intercept and
    monitor your communications.
    
    Traditional Detection Approaches (and Problems)
    
    You would think that detecting and alerting on unauthorized activity
    would be easy. Unfortunately, it's not, as many readers will already
    know. Traditionally, one of the most common detection technologies has
    been network intrusion detection systems (NIDS). These systems work by
    passively monitoring network traffic for suspicious or unauthorized
    activity. When these systems identify such activity they generate an
    alert.
    
    The trick to NIDS is defining how it identifies suspicious or
    unauthorized activity. There are many ways to do this; however, the
    two most common approaches are is rules based and anomaly based.  
    Rules-based NIDS is based on a series patterns or signatures, which
    are essentially strings of code that are known to be indicative of
    malicious traffic. If a packet (or collection of packets) trying to
    enter the network contains these known patterns, it assumes
    unauthorized activity is occurring and an alert is generated. For
    example, below is an IDS rule from the OpenSource solution Snort. This
    particular rule is designed to capture attacks against an FTP server.  
    It looks for packets going to port 21 that contain "5057 440A 2F69".  
    This content is given as a hexadecimal value. Whenever that content is
    matched, an alert is generated.
    
    alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP EXPLOIT
    overflow"; flow:to_server,established;  content:"|5057 440A 2F69|";
    classtype:attempted-admin;  sid:340;  rev:3;)
    
    Unfortunately, NIDS are notorious for generating false positives, or
    alerting for attacks on traffic that is, in fact, benign. For example,
    when someone uploads an image to a file server, part of the image may
    match the content, even though the traffic is legitimate, falsely
    generating an alert. When a rules-based NIDS is deployed, it can take
    an organization several weeks to tweak the rule-base, identifying
    which rules falsely trigger alerts. The reduction of false positives
    is critical. If too many are generated, organizations will ignore
    their detection mechanisms, just as most people simply ignore when car
    alarms go off.
    
    While false positives are a problem with NIDS, so is the problem of
    updating. As new attacks are identified, new rules have to be added to
    the database or the NIDS will fail to identify the new attacks. This
    process of updating rules never ends, just as the development of new
    attacks never ends.
    
    Anomaly-based NIDS is different. It does not work on rules; instead,
    anomaly based technologies attempt to learn what is normal network
    behavior, then triggers an alert on anything considered abnormal, to
    include an attack. The challenge to anomaly-based detection is
    defining what is normal. If a network does not change over a long
    period of time, then it becomes relatively simple to learn what normal
    is. However, new applications and technologies are constantly being
    added to networks, so change is often the norm. Chat programs,
    peer-to-peer networks, new implementations of existing protocols, the
    dynamic nature of IP communications, all of this makes it extremely
    difficult to establish a metric by which to establish normal network
    behavior.
    
    The advantages rule-based and anomaly-based technologies share are
    they can be quickly deployed and monitor most systems quite
    comprehensively. By passively monitoring all systems, almost all
    network activity can be analyzed for suspicious activity. However,
    most NIDS face the same challenges:
    
    [...]
    
    
    
    -
    ISN is currently hosted by Attrition.org
    
    To unsubscribe email majordomoat_private with 'unsubscribe isn'
    in the BODY of the mail.
    



    This archive was generated by hypermail 2b30 : Thu May 01 2003 - 03:16:42 PDT