Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > NZ Computing > Has your firewall been set to drop packets with the evil bit?

Reply
Thread Tools

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

 
 
Shane
Guest
Posts: n/a
 
      03-27-2007
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.
 
Reply With Quote
 
 
 
 
Collector»NZ
Guest
Posts: n/a
 
      03-27-2007
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
 
Reply With Quote
 
 
 
 
Shane
Guest
Posts: n/a
 
      03-27-2007
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

 
Reply With Quote
 
Peter Huebner
Guest
Posts: n/a
 
      03-27-2007
In article <eubtvg$ul1$(E-Mail Removed)>, http://www.velocityreviews.com/forums/(E-Mail Removed)-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
 
Reply With Quote
 
Mark Robinson
Guest
Posts: n/a
 
      03-27-2007
Peter Huebner wrote:
> In article <eubtvg$ul1$(E-Mail Removed)>, (E-Mail Removed)-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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
the tutor list has been strangely silent for a few days. Anyone knowwhat has happened? bill.wu Python 0 01-17-2008 03:38 PM
Evil, evil wxPython (and a glimmer of hope) vivainio@gmail.com Python 12 02-17-2006 07:49 PM
The printing has been stopped and this job has been add to the queu? dejola Computer Support 6 12-30-2005 03:26 AM
I need help I has been over 6 months since I've been able to do the system check for updates Marc Computer Support 8 07-25-2005 07:04 PM
ZoneAlarm has detected a problem with your installation, and therefore has restricted Internet access from your machine for your protection. Don’t panic A Teuchter Computer Support 2 05-19-2005 09:20 PM



Advertisments