RE: Nmap compliance with new RFC 3514

http://www.ietf.org/rfc/rfc3093.txt
http://www.ietf.org/rfc/rfc3092.txt
http://www.ietf.org/rfc/rfc3091.txt
http://www.ietf.org/rfc/rfc1149.txt
http://www.ietf.org/rfc/rfc0748.txt


 
_____________________
Dave Kleiman
[email protected]
www.netmedic.net

 


-----Original Message-----
From: Florin Andrei [mailto:[email protected]] 
Sent: Tuesday, April 01, 2003 13:20
To: [email protected]
Cc: [email protected]
Subject: Re: Nmap compliance with new RFC 3514

The Evil Bit should be set to 1 automatically when packets are routed
through Avian Carriers (see RFC1149).

On Mon, 2003-03-31 at 21:49, Fyodor wrote:
> Hey everyone,
> 
> Security expert Steven Bellovin just released RFC 3514 which details
> an innovative new approach to IPv4 security.  The described "security
> bit" flags the intention of IP traffic (0x0 means innocent and 0x1 is
> for "evil" packets).  The RFC (below) specifically notes the
> dual-purpose nature of security scanners such as Nmap:
> 
> "Some hosts scan other hosts in a fashion that can alert intrusion
>  detection systems.  If the scanning is part of a benign research
>  project, the evil bit MUST NOT be set.  If the scanning per se is
>  innocent, but the ultimate intent is evil and the destination site
>  has such an intrusion detection system, the evil bit SHOULD be set."
> 
> I think this leads to two important questions WRT Nmap compliance:
> 
> 1) How should Nmap determine evil intent?  Perhaps an --evil option
>    would be handy, or maybe a standard environmental variable should
>    be used (SCRIPT_KIDDIE=1?) so that all security programs run by the
>    hacker set the flag appropriately?  Or maybe Nmap could ship with a
>    hardcoded list of UNIX usernames used by known malicious hackers?
>    Maybe shady options like "decoy scan" and Idle Stealth scan should
>    always set the bit.
> 
> 2) Should the overall Nmap default be to set the bit unless the user
>    gives a "good intentions" option, or should we assume innocence
>    until proven guilty?
> 
> Let me know what you think :).  As usual, I don't plan to implement
> the IPv6 extensions unless I get sufficient requests to demonstrate
> demand.
> 
> -Fyodor
> 
> Here is the RFC text:
> 
> [ ftp://ftp.rfc-editor.org/in-notes/rfc3514.txt ]
> Network Working Group                                        S. Bellovin
> Request for Comments: 3514                            AT&T Labs Research
> Category: Informational                                     1 April 2003
> 
> 
>                   The Security Flag in the IPv4 Header
> 
> Status of this Memo
> 
>    This memo provides information for the Internet community.  It does
>    not specify an Internet standard of any kind.  Distribution of this
>    memo is unlimited.
> 
> Copyright Notice
> 
>    Copyright (C) The Internet Society (2003).  All Rights Reserved.
> 
> Abstract
> 
>    Firewalls, packet filters, intrusion detection systems, and the like
>    often have difficulty distinguishing between packets that have
>    malicious intent and those that are merely unusual.  We define a
>    security flag in the IPv4 header as a means of distinguishing the two
>    cases.
> 
> 1. Introduction
> 
>    Firewalls [CBR03], packet filters, intrusion detection systems, and
>    the like often have difficulty distinguishing between packets that
>    have malicious intent and those that are merely unusual.  The problem
>    is that making such determinations is hard.  To solve this problem,
>    we define a security flag, known as the "evil" bit, in the IPv4
>    [RFC791] header.  Benign packets have this bit set to 0; those that
>    are used for an attack will have the bit set to 1.
> 
> 1.1. Terminology
> 
>    The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
>    SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
>    document, are to be interpreted as described in [RFC2119].
> 
> 2. Syntax
> 
>    The high-order bit of the IP fragment offset field is the only unused
>    bit in the IP header.  Accordingly, the selection of the bit position
>    is not left to IANA.
> 
>    The bit field is laid out as follows:
> 
>              0
>             +-+
>             |E|
>             +-+
> 
>    Currently-assigned values are defined as follows:
> 
>    0x0  If the bit is set to 0, the packet has no evil intent.  Hosts,
>         network elements, etc., SHOULD assume that the packet is
>         harmless, and SHOULD NOT take any defensive measures.  (We note
>         that this part of the spec is already implemented by many common
>         desktop operating systems.)
> 
>    0x1  If the bit is set to 1, the packet has evil intent.  Secure
>         systems SHOULD try to defend themselves against such packets.
>         Insecure systems MAY chose to crash, be penetrated, etc.
> 
> 3. Setting the Evil Bit
> 
>    There are a number of ways in which the evil bit may be set.  Attack
>    applications may use a suitable API to request that it be set.
>    Systems that do not have other mechanisms MUST provide such an API;
>    attack programs MUST use it.
> 
>    Multi-level insecure operating systems may have special levels for
>    attack programs; the evil bit MUST be set by default on packets
>    emanating from programs running at such levels.  However, the system
>    MAY provide an API to allow it to be cleared for non-malicious
>    activity by users who normally engage in attack behavior.
> 
>    Fragments that by themselves are dangerous MUST have the evil bit
>    set.  If a packet with the evil bit set is fragmented by an
>    intermediate router and the fragments themselves are not dangerous,
>    the evil bit MUST be cleared in the fragments, and MUST be turned
>    back on in the reassembled packet.
> 
>    Intermediate systems are sometimes used to launder attack
>    connections.  Packets to such systems that are intended to be relayed
>    to a target SHOULD have the evil bit set.
> 
>    Some applications hand-craft their own packets.  If these packets are
>    part of an attack, the application MUST set the evil bit by itself.
> 
>    In networks protected by firewalls, it is axiomatic that all
>    attackers are on the outside of the firewall.  Therefore, hosts
>    inside the firewall MUST NOT set the evil bit on any packets.
>    Because NAT [RFC3022] boxes modify packets, they SHOULD set the evil
>    bit on such packets.  "Transparent" http and email proxies SHOULD set
>    the evil bit on their reply packets to the innocent client host.
> 
>    Some hosts scan other hosts in a fashion that can alert intrusion
>    detection systems.  If the scanning is part of a benign research
>    project, the evil bit MUST NOT be set.  If the scanning per se is
>    innocent, but the ultimate intent is evil and the destination site
>    has such an intrusion detection system, the evil bit SHOULD be set.
> 
> 4. Processing of the Evil Bit
> 
>    Devices such as firewalls MUST drop all inbound packets that have the
>    evil bit set.  Packets with the evil bit off MUST NOT be dropped.
>    Dropped packets SHOULD be noted in the appropriate MIB variable.
> 
>    Intrusion detection systems (IDSs) have a harder problem.  Because of
>    their known propensity for false negatives and false positives, IDSs
>    MUST apply a probabilistic correction factor when evaluating the evil
>    bit.  If the evil bit is set, a suitable random number generator
>    [RFC1750] must be consulted to determine if the attempt should be
>    logged.  Similarly, if the bit is off, another random number
>    generator must be consulted to determine if it should be logged
>    despite the setting.
> 
>    The default probabilities for these tests depends on the type of IDS.
>    Thus, a signature-based IDS would have a low false positive value but
>    a high false negative value.  A suitable administrative interface
>    MUST be provided to permit operators to reset these values.
> 
>    Routers that are not intended as as security devices SHOULD NOT
>    examine this bit.  This will allow them to pass packets at higher
>    speeds.
> 
>    As outlined earlier, host processing of evil packets is operating-
>    system dependent; however, all hosts MUST react appropriately
>    according to their nature.
> 
> 5. Related Work
> 
>    Although this document only defines the IPv4 evil bit, there are
>    complementary mechanisms for other forms of evil.  We sketch some of
>    those here.
> 
>    For IPv6 [RFC2460], evilness is conveyed by two options.  The first,
>    a hop-by-hop option, is used for packets that damage the network,
>    such as DDoS packets.  The second, an end-to-end option, is for
>    packets intended to damage destination hosts.  In either case, the
>    option contains a 128-bit strength indicator, which says how evil the
>    packet is, and a 128-bit type code that describes the particular type
>    of attack intended.
> 
>    Some link layers, notably those based on optical switching, may
>    bypass routers (and hence firewalls) entirely.  Accordingly, some
>    link-layer scheme MUST be used to denote evil.  This may involve evil
>    lambdas, evil polarizations, etc.
> 
>    DDoS attack packets are denoted by a special diffserv code point.
> 
>    An application/evil MIME type is defined for Web- or email-carried
>    mischief.  Other MIME types can be embedded inside of evil sections;
>    this permit easy encoding of word processing documents with macro
>    viruses, etc.
> 
> 6. IANA Considerations
> 
>    This document defines the behavior of security elements for the 0x0
>    and 0x1 values of this bit.  Behavior for other values of the bit may
>    be defined only by IETF consensus [RFC2434].
> 
> 7. Security Considerations
> 
>    Correct functioning of security mechanisms depend critically on the
>    evil bit being set properly.  If faulty components do not set the
>    evil bit to 1 when appropriate, firewalls will not be able to do
>    their jobs properly.  Similarly, if the bit is set to 1 when it
>    shouldn't be, a denial of service condition may occur.
> 
> 8. References
> 
>    [CBR03]   W.R. Cheswick, S.M. Bellovin, and A.D. Rubin, "Firewalls
>              and Internet Security: Repelling the Wily Hacker", Second
>              Edition, Addison-Wesley, 2003.
> 
>    [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
>              1981.
> 
>    [RFC1750] Eastlake, D., 3rd, Crocker, S. and J. Schiller, "Randomness
>              Recommendations for Security", RFC 1750, December 1994.
> 
>    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
>              Requirement Levels", BCP 14, RFC 2119, March 1997.
> 
>    [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
>              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
>              October 1998.
> 
>    [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
>              (IPv6) Specification", RFC 2460, December 1998.
> 
>    [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
>              Address Translator (Traditional NAT)", RFC 3022, January
>              2001.
> 
> 9. Author's Address
> 
>    Steven M. Bellovin
>    AT&T Labs Research
>    Shannon Laboratory
>    180 Park Avenue
>    Florham Park, NJ 07932
> 
>    Phone: +1 973-360-8656
>    EMail: [email protected]
> 
> 
> 10. Full Copyright Statement
> 
>    Copyright (C) The Internet Society (2003).  All Rights Reserved.
> 
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implementation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph are
>    included on all such copies and derivative works.  However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into languages other than
>    English.
> 
>    The limited permissions granted above are perpetual and will not be
>    revoked by the Internet Society or its successors or assigns.
> 
>    This document and the information contained herein is provided on an
>    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
>    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
>    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
>    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
>    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
> 
> Acknowledgement
> 
>    Funding for the RFC Editor function is currently provided by the
>    Internet Society.
> 
> --------------------------------------------------
> For help using this (nmap-hackers) mailing list, send a blank email to 
> [email protected] . List run by ezmlm-idx (www.ezmlm.org).
> 
-- 
Florin Andrei

"The Internet's elementary laws never figured people would build
careers on not understanding them." -  Doc Searls and David Weinberger


---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
[email protected] . List run by ezmlm-idx (www.ezmlm.org).






---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
[email protected] . List run by ezmlm-idx (www.ezmlm.org).