Re: Nmap compliance with new RFC 3514

I don't know, my Avian Carrier got killed by a boy with a slingshot, so
i didn't got my email.

On Tue, 2003-04-01 at 14:06, Steven P. Adelman wrote:
> We all know this was an April fools joke right?
> 
> SPA
> 
> 
> 
> On 1 Apr 2003, Florin Andrei wrote:
> 
> > 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).
> > 
> > 
> 
-- 
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).