As per Relevance of the word incoming, we have this rfc below:
Network Working Group I.
Request for Comments: 3128 Singularis
Updates: 1858 June 2001
Category:
Protection Against a Variant of the Tiny Fragment
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document discusses how RFC 1858 compliant filters can
vulnerable to a variant of the "Tiny Fragment Attack" described
section 3.1 of the RFC. This document describes the attack
recommends corrective action
1.
RFC 1858 provides an excellent description of a class of attack
Internet firewalls and proposes countermeasures. However one
these countmeasures, the "Indirect Method" (section 3.2.2)
vulnerable to a combination of two of the attacks described
The attack combines the features of the "Tiny Fragment Attack
(section 3) and the "Overlapping Fragment Attack" (section 4).
1.1 The scope of the
Where the filtering rules allow incoming connections to a machine
there other ports which allow only outgoing connections on the
host, the attack allows incoming connections to the
outgoing-only ports
Note that only the initial connection message need be fragmented
Once the connection is established further traffic on it is legal
The significance of this weakness will depend on the security
in force
Miller Informational [Page 1]
RFC 3128 Protection Against a Tiny Fragment Attack June 2001
2. The Tiny Overlapping Fragment
The attack typically consists of sending three fragments
Fragment 1: (Fragment offset = 0; length >= 16)
Includes whole header and is entirely legal. Typically
describes a SYN packet initiating a new TCP connection to a
on the target host that is allowed to receive
connections
e.g., Incoming connection to port 25 SMTP
Fragment 2: (Fragment offset = 0; length = 8)
Is only the first 8 bytes and could be legal depending on
other 8-bytes of the header, but is NOT legal combined with
corresponding bytes from Fragment 1. Such a fragment
only the port numbers and sequence number from the TCP header
Typically this packet replaces the destination port number with
port number on which the destination host that is not allowed
receive incoming connections
Fragment 3: (Fragment offset >= 2; length = rest of message
Contains no header and completes the message. (This
fragment is not part of the attack. However Fragment 1 cannot
the complete message or it would be passed up to the
before Fragment 2 arrived so a third fragment is necessary.)
2.1 Example of the
Consider the following trivial set of rules for incoming packets
+---+-------+-------+-------+-------+-----------------------+
| No|Action | Source| Dest. | Flags | Purpose |
| | | Port | Port | | |
+===+=======+=======+=======+=======+=======================+
| 1 |Permit | >1023 | SMTP | ANY | Incoming E-mail |
+---+-------+-------+-------+-------+-----------------------+
| 2 |Permit | >1023 | ANY | Ack=1| Existing FTP data |
| | | | | channel connections. |
+---+-------+-------+-------+-------+-----------------------+
| 3 |Deny | ANY | ANY | ANY | Default deny |
+---+-------+-------+-------+-------+-----------------------+
Fragment 1: attacker(1234) -> target(SMTP) Ack=0
This is a new SMTP connection and is permitted by rule 1.
Fragment 2: attacker(1234) -> target(Telnet=23) Ack=
All fields present conform to rule 2, as it could be the start
an FTP packet
Miller Informational [Page 2]
RFC 3128 Protection Against a Tiny Fragment Attack June 2001
Depending on the precise implementation of the fragment reassembly
the target machine's IP stack, fragment B may overwrite fragment A
produce:-
attacker(1234) -> target(Telnet) Ack=0
(new telnet connection
2.2 The failure of "Indirect Method
The Indirect Method attempts to solve both Tiny Fragment
Overlapping Fragment attacks, solely by rejecting packets with FO=1.
However none of the above fragments have FO=1, so none are rejected
The failure is clear on careful reading. In section 3.2.2 "
Method", RFC 1858 states:-
The indirect method relies on the observation that when a
packet is fragmented so as to force "interesting" header
out of the zero-offset fragment, there must exist a fragment
FO equal to 1.
This is normally true where the fragments are genuine fragments
generally by bona fide software, but it is simply not true that
hacker forging fragments is forced to produce an FO=1 fragment
because (s)he has produced an 8-byte FO=0 fragment.
vulnerability flows from this false premise
3.
Whereas apparently very elegant, RFC 1858's Indirect Method is
robust. In addition to blocking FO=1 packets, it is also
to block FO=0 that hold less than a complete header
if FO=0 and PROTOCOL=TCP and TRANSPORTLEN < tmin
DROP
if FO=1 and PROTOCOL=TCP
DROP
4. Security
This memo is concerned entirely with the security implications
filtering fragmented IP packets
Miller Informational [Page 3]
RFC 3128 Protection Against a Tiny Fragment Attack June 2001
5. Author's
Ian
Singularis
32 Stockwell
CB1 3ND
Phone: +44 1223 511943
EMail: Ian_Miller@singularis.ltd.
Miller Informational [Page 4]
RFC 3128 Protection Against a Tiny Fragment Attack June 2001
6. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Miller Informational [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
