Of statefull firewall and what not

[HKEY1952]

Originally Posted by STEM

In most cases a firewall will by default "block all inbound TCP SYN packets"

The only time inbound TCP SYN packets from an lower security interface are blocked by the higher security interface,
is when the higher security interface DOES NOT exist an INITIATED OUTBOUND CONNECTION with the lower security
interface. (WAN to LAN).


If the inbound TCP SYN packet is traversing through the clients INITIATED OUTBOUND CONNECTION as an REPLY to the
clients outbound TCP SYN packet, then the inbound TCP SYN packet will not be blocked. (LAN to WAN).


So, in most cases, by default, not "all" inbound TCP SYN packets are blocked.


HKEY1952

[Seer]

Originally Posted by HKEY1952

The only time inbound TCP SYN packets from an lower security interface are blocked by the higher security interface,
is when the higher security interface DOES NOT exist an INITIATED OUTBOUND CONNECTION with the lower security
interface.

A SYN packet coming from "a lower security interface" (whatever that may be) should be blocked every time (unless you run a server),
and not just in that case. Read on.

If the inbound TCP SYN packet is traversing through the clients INITIATED OUTBOUND CONNECTION as an REPLY to the
clients outbound TCP SYN packet, then the inbound TCP SYN packet will not be blocked.

Wrong. A reply to client's outbound initiated connection (a TCP packet with a SYN flag set) is a TCP packet with an SYN/ACK flags set, not a SYN one.
A three-way handshake's already mentioned in this thread. Take a good hard look at the refs on the net and elsewhere.

[Stem]

Originally Posted by Stem

First:
Block inbound TCP SYN flags
Second:
Block all inbound TCP flags
So which ever way I look at that, there is a big difference

A stateful firewall would only block an inbound "TCP SYN" packet as a connection attempt. What you put forward, is that an inbound TCP SYN/ACK would also be blocked as an inbound connection attempt, when that could possibly be a reply to an outbound connection. So you cannot simply block all inbound TCP packets with any flag set.

Originally Posted by Stem

Windows firewall is policy based.
As can be seen in the pic you posted your "block all inbound" refers to "Block Inbound connections" not to "Block all inbound"

There is a big difference between "Block inbound connections" which is "Block inbound TCP SYN" and "Block all inbound" which would block all inbound TCP with any flag set as I put forward above.

With windows firewall, with the "Block inbound connection" active, yes it blocks inbound connection attempts(TCP SYN), but it does not block, for example, inbound TCP SYN/ACK, because that could be part of an outbound connection reply, it instead allows the packet and checks to see if it is part of a connection, if it is not, then it will reply with a TCP RST/ACK.


- Stem

[sparviero]

Originally Posted by Seer

so I'm wondering what "stateful filtering" are you talking about here.

Knowledge solves many dilemmas.

The firewall is programmed to distinguish legitimate packets for different types of connections. Only packets matching a known active connection will be allowed by the firewall; others will be rejected.
http://en.wikipedia.org/wiki/Stateful_firewall

I'm sick....

[sparviero]

Originally Posted by Stem

because that could be part of an outbound connection reply

The same goes for you, read the post above.

[Stem]

Originally Posted by sparviero

The same goes for you, read the post above.

You are linking "Wikipedia" as a reference

Only packets matching a known active connection will be allowed by the firewall; others will be rejected.

With windows firewall, the "block all connections" is a perimeter rule, it does not process those packets, it simply drops them. If that rule was to block all inbound TCP with any flag, then those packet would not be processed to see if they are part of a current connection, therefore all inbound TCP packets would be blocked, including legitimate replies.

- Stem

[Seer]

Originally Posted by sparviero

I'm sick....

You are rude and arrogant, aren't you?
I do appreciate your contribution to WF thread,
(specifically the one with tying the event log entry to a trigger that will then produce a pop-up),
but you need to develop a sense for a moment when you need to step down.
You give some wiki link on firewalls and quote a sentence that does not explain anything
(Wikipedia is awful for networking topics, except the most basic ones).
What's a good and what's a bad packet?
How exactly does a firewall distinguish between good and bad packets?
What happens when a packet is rejected?
What if the bad one goes through, what happens then?
Yes, it may be the case of improper terminology (block inbound attempts/block all inbound),
but we need to set this straight.

pay no attention to packet filtering

What can I say... Excellent advice.

A link now please...?

[sparviero]

Carefully read the conversation between me and your helper, maybe you'll find wire.
I see, you take the time to loosen these knots like "block all" or whatever and now your helper with "stateful filtering".
Good luck.

I'm sick, and I wish you all very nice weekend..

[Seer]

I was hoping for another link, but...

Originally Posted by sparviero

I wish you all very nice weekend..

Likewise.
See you around.

[Cudni]

Split from original thread.

[Kees1958]

SPARVIERO bit the syn, syn/nak, nak/can, eot and got sick

SEER syn, syn/ack, ack, ack with STEM

[Stem]

Originally Posted by Kees1958

SEER syn, syn/ack, ack, ack with STEM

Connection still open between us, I like that.

Regards,

- Stem

[HKEY1952]

Originally Posted by Seer

Wrong. A reply to client's outbound initiated connection (a TCP packet with a SYN flag set) is a TCP packet with an
SYN/ACK flags set, not a SYN one.

No, Not Wrong, the SYN+ACK packet is an synchronization packet with the acknowledgement flag set, because, it is the
first packet sent from the lower security interface to the higher security interface.

Opening an TCP initialized outbound connection from the higher security interface to the lower security interface
involves exchanging three packets. Those three packets are commonly labled: SYN, SYN + ACK, and ACK.

The TCP header exists SYN (for synchronize) and ACK (for acknowledge) bits.

The first packet, sent from the higher security interface to the lower security interface,
is an synchronization packet,
has the SYN bit set.

The second packet (first packet), sent from the lower security interface back to the higher security interface,
is an synchronization packet with the acknowledgement flag set,
has both SYN + ACK bits set.

The third packet, sent from the higher security interface back to the lower interface,
is an acknowledgement packet,
only has the ACK bit set.


Only the first packet sent from each end should have the SYN bit flag set, because,
Some other flags change meaning based on this flag, and some are only valid for when it is set,
and still others when it is clear.

Also note, that, ALL packets after the initial SYN packet sent by the CLIENT must have the ACK flag set.

.....Therefore:
Before the reply (SYN + ACK) from the lower security interface back to the higher security interface, as an reply,
will be accepted by the higher security interface, there must be an synchronization on the first packet sent
from the lower security interface, so that both ends can initiate and negotiate separate TCP socket connections at
the same time. Being able to negotiate multiple TCP socket connections in both directions at the same time allows
an single physical network interface (such as ethernet) to be multiplexed.

.....Hence:

Originally Posted by HKEY1952

If the inbound TCP SYN packet is traversing through the clients INITIATED OUTBOUND CONNECTION as an REPLY to the
clients outbound TCP SYN packet, then the inbound TCP SYN packet will not be blocked. (LAN to WAN).

After synchronization with the lower security interfaces 'SYN' packet, the acknowledgement (ACK) flag is noted and
then the higher security interface sends an acknowledgement (ACK) packet, minus the (SYN) flag, back to the lower
security interface, and the higher security interfaces initiated TCP initialized outbound connection is established.


WATCH THE MOVIE IN THE GRAPHIC PLAY THE INITIALIZED OUTBOUND CONNECTION

TCP Three Way Handshake
(SYN,SYN+ACK,ACK)


EDIT: clarity/completeness


HKEY1952

[Scoobs72]

Jeez, guys.....give it a rest. You're both right. HKEY1952 is describing the handshake in a 'classical' manner, Seer is describing it in the way 99% of people would understand it. Read the original RFC and it describes the response to the initial SYN being a SYN,ACK, but then shows the originator going into state "SYN received" on receipt of the SYN,ACK. So the response to the original SYN is indeed SYN,ACK, but the originator of the SYN, after sending it, goes into a state of "awaiting SYN".

So you're both correct.

[Seer]

Originally Posted by Scoobs72

but then shows the originator going into state "SYN received" on receipt of the SYN,ACK.

It simply means that the synchronization is done, and ACK packets are now expected.
Here's from HKEY1952 -

Originally Posted by HKEY1952

there must be an synchronization on the first packet sent
from the lower security interface, so that both ends can initiate and negotiate separate TCP socket connections at
the same time. Being able to negotiate multiple TCP socket connections in both directions at the same time allows
an single physical network interface (such as ethernet) to be multiplexed.

- explains the need for a SYN flag in first and second packet.

Originally Posted by Scoobs72

So you're both correct.

What was going on here, was that HKEY1952 claimed (let's not quote it, it's quoted twice already on this page) that a reply from a "lower interface" is a SYN, in an attempt to defend his/her view that SYN packets should be allowed on a "higher interface". Wrong path.
Post #13, though looking like a reference transcript, is correct. Except the false quote.
But I think we'll be OK now.

ack

Cheers,

[datarishik]

The 3-Way Handshake is clearly explained here along with the animated graphic: http://www.inetdaemon.com/tutorials/...andshake.shtml