Has your firewall been set to drop packets with the evil bit?

Discussion in 'NZ Computing' started by Shane, Mar 27, 2007.

  1. Shane

    Shane Guest

    http://www.ietf.org/rfc/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.

    [...]

    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.

    __EOP__

    Note the date on the RFC.
    Shane, Mar 27, 2007
    #1
    1. Advertising

  2. Shane wrote:
    > http://www.ietf.org/rfc/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.
    >
    > [...]
    >
    > 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.
    >
    > __EOP__
    >
    > Note the date on the RFC.

    Dam a joke with maybe laughable intentions but so many stupid users will
    actually fall for this
    Collector»NZ, Mar 27, 2007
    #2
    1. Advertising

  3. Shane

    Shane Guest

    Collector»NZ wrote:

    > Shane wrote:
    >> http://www.ietf.org/rfc/rfc3514.txt


    >>
    >> Note the date on the RFC.

    > Dam a joke with maybe laughable intentions but so many stupid users will
    > actually fall for this


    Thankfully not too many users read the RFC's, or even know what they are :)
    Shane, Mar 27, 2007
    #3
  4. In article <eubtvg$ul1$>, -a-geek.net says...
    >
    > Thankfully not too many users read the RFC's, or even know what they are :)
    >


    RFC? Yet another acronym I don't recognize.
    However, I can read a date. April 1st,2003 indeed.
    "Attack software must set the evil bit" - not enough to make me snort coffee
    into the keyboard through my nose, but pretty funny all the same ;-)

    -P.

    --
    =========================================
    firstname dot lastname at gmail fullstop com
    Peter Huebner, Mar 27, 2007
    #4
  5. Peter Huebner wrote:
    > In article <eubtvg$ul1$>, -a-geek.net says...
    >> Thankfully not too many users read the RFC's, or even know what they are :)

    >
    > RFC? Yet another acronym I don't recognize.
    > However, I can read a date. April 1st,2003 indeed.
    > "Attack software must set the evil bit" - not enough to make me snort coffee
    > into the keyboard through my nose, but pretty funny all the same ;-)


    http://en.wikipedia.org/wiki/Request_for_Comments
    http://www.ietf.org/rfc.html
    Mark Robinson, Mar 27, 2007
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Marc
    Replies:
    8
    Views:
    743
    Martik
    Jul 25, 2005
  2. dejola
    Replies:
    6
    Views:
    609
    jason43050
    Dec 30, 2005
  3. Brian McCrary
    Replies:
    0
    Views:
    2,816
    Brian McCrary
    Jun 6, 2007
  4. sandy58
    Replies:
    5
    Views:
    597
    Mr. Arnold
    Jan 6, 2008
  5. chuckcar
    Replies:
    0
    Views:
    479
    chuckcar
    Nov 10, 2009
Loading...

Share This Page