4948204 2000-03-28  06:59  /63 rader/ Postmaster
Mottagare: Bugtraq (import) <10379>
Ärende: The TCP Flags Playground
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID:  <003401bf97b5$d06e2f60$0f05a8c0@packettechnologies.com>
Date:         Mon, 27 Mar 2000 08:29:32 +0200
Reply-To: ofir@packet-technologies.com
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Ofir Arkin <ofir@packet-technologies.com>
X-To:         bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM

Ok, once and for all I want to list what certain TCP Flags
combination do:

Host Detection: Any combination of the ACK bit, except with a RST,
would elicit a RST back from a probed machines whether we probe an
opened port or a closed one.

SYN+FIN+URG would elicit a RST|ACK back whether we probe an opened
port or a closed one.

SYN, SYN+FIN, SYN+PUSH, SYN+URG, SYN+FIN+PUSH, SYN+URG+PUSH,
FIN+URG+PUSH+SYN, all will elicit a RST|ACK from a closed port and a
SYN|ACK from an opened port.

OS Distinguish: FIN, FIN+URG+PUSH, URG, URG+PUSH, URG+FIN, PUSH,
PUSH+FIN and NULL Flags would all elicit a RST|ACK on a closed port,
*NIX machines will not respond when probed for an opened port,
Windows machines still reply with RST|ACK.

Filtering Device Present: If we use one of the Host Detection
Combinations and we do not get a reply - a filtering device is
present and prevent the probe from going inside the protected "zone"
or the reply from coming out.

The Filtering Device is lame: if the firewall is just a simple packet
filter that blocks incoming SYN's than some of the combinations I
have listed would elicit a reply. If the Firewall is statefull (AND
do his job as it should. I have seen some idiotically cases were
statefull was not implemented as it should.) nothing should pass it.

Hope this clarifies some questions I have seen people asked on various
mailing lists.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Ofir Arkin                      <ofir@packet-technologies.com>
Security QA Manager    http://www.packet-technologies.com
Packet Technologies
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The opinions in this message are my own, and not in any
way representative of Packet Technologies.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
(4948204) ------------------------------------------(Ombruten)

4952052 2000-03-29  07:16  /78 rader/ Postmaster
Mottagare: Bugtraq (import) <10391>
Ärende: Re: The TCP Flags Playground
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Authentication-Warning: enki.corp.icopyright.com: lamont owned process doin 
                        -bs
X-Sender: lamont@enki.corp.icopyright.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.LNX.4.21.0003281008440.1964-100000@enki.corp.icopyright.com>
Date:         Tue, 28 Mar 2000 11:34:31 -0800
Reply-To: lamont@ICOPYRIGHT.COM
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: "Granquist, Lamont" <lamont@ICOPYRIGHT.COM>
X-To:         Ofir Arkin <ofir@packet-technologies.com>
X-cc:         BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <003401bf97b5$d06e2f60$0f05a8c0@packettechnologies.com>

Unfortunately, it isn't anywhere near as simple as this.  For
example, older Linux stacks will respond to a SYN|FIN to an open port
with a SYN|FIN|ACK.  Also, when hitting a Solaris (2.5.1 and 2.6 at
least) box, the URG flag being turned on with a SYN will cause that
packet to be dropped.  There are other flag combinations which
respond differently on different systems, e.g. not everything that is
FIN scannable is NULL (no flags) scannable.

There are also other fun things that you can do to try to bypass
firewalls such as fragmenting your packets and sending them
out-of-order.  You can also try more advanced things like exploiting
the 2.2.x ipchains fragment reassembly bug.

On Mon, 27 Mar 2000, Ofir Arkin wrote:
> Ok, once and for all I want to list what certain TCP Flags combination do:
>
> Host Detection:
> Any combination of the ACK bit, except with a RST, would elicit a RST back
> from a probed machines whether we
> probe an opened port or a closed one.
>
> SYN+FIN+URG would elicit a RST|ACK back whether we probe an opened port or a
> closed one.
>
> SYN, SYN+FIN, SYN+PUSH, SYN+URG, SYN+FIN+PUSH, SYN+URG+PUSH,
> FIN+URG+PUSH+SYN, all will elicit a RST|ACK from a closed port and a SYN|ACK
> from an opened port.
>
> OS Distinguish:
> FIN, FIN+URG+PUSH, URG, URG+PUSH, URG+FIN, PUSH, PUSH+FIN and NULL Flags
> would all elicit a
> RST|ACK on a closed port, *NIX machines will not respond when probed for an
> opened port, Windows machines
> still reply with RST|ACK.
>
> Filtering Device Present:
> If we use one of the Host Detection Combinations and we do not get a reply -
> a filtering device is present and
> prevent the probe from going inside the protected "zone" or the reply from
> coming out.
>
> The Filtering Device is lame:
> if the firewall is just a simple packet filter that blocks incoming SYN's
> than some of the combinations I have listed
> would elicit a reply. If the Firewall is statefull (AND do his job as it
> should. I have seen some idiotically cases were
> statefull was not implemented as it should.) nothing should pass it.
>
> Hope this clarifies some questions I have seen people asked on various
> mailing lists.
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Ofir Arkin                      <ofir@packet-technologies.com>
> Security QA Manager    http://www.packet-technologies.com
> Packet Technologies
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> The opinions in this message are my own, and not in any
> way representative of Packet Technologies.
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
(4952052) ------------------------------------------(Ombruten)