Of statefull firewall and what not

Discussion in 'other firewalls' started by HKEY1952, Apr 20, 2012.

Thread Status:
Not open for further replies.
  1. HKEY1952

    HKEY1952 Registered Member

    Joined:
    Jul 22, 2009
    Posts:
    648
    Location:
    HKEY/SECURITY/ (value not set)
    Re: Private fw for the non tweeker?

    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
     
  2. Seer

    Seer Registered Member

    Joined:
    Feb 12, 2007
    Posts:
    1,596
    Location:
    Singidunum
    Re: Private fw for the non tweeker?

    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.

    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.
     
  3. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Re: Private fw for the non tweeker?

    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.



    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
     
  4. sparviero

    sparviero Registered Member

    Joined:
    Apr 23, 2009
    Posts:
    88
    Re: Private fw for the non tweeker?

    Knowledge solves many dilemmas.

    I'm sick....
     
  5. sparviero

    sparviero Registered Member

    Joined:
    Apr 23, 2009
    Posts:
    88
    Re: Private fw for the non tweeker?

    The same goes for you, read the post above.
     
  6. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Re: Private fw for the non tweeker?

    You are linking "Wikipedia" as a reference :eek:


    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
     
    Last edited: Apr 21, 2012
  7. Seer

    Seer Registered Member

    Joined:
    Feb 12, 2007
    Posts:
    1,596
    Location:
    Singidunum
    Re: Private fw for the non tweeker?

    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.

    What can I say... Excellent advice.

    A link now please...?
     
  8. sparviero

    sparviero Registered Member

    Joined:
    Apr 23, 2009
    Posts:
    88
    Re: Private fw for the non tweeker?

    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..
     
  9. Seer

    Seer Registered Member

    Joined:
    Feb 12, 2007
    Posts:
    1,596
    Location:
    Singidunum
    Re: Private fw for the non tweeker?

    I was hoping for another link, but...

    Likewise.
    See you around.
     
  10. Cudni

    Cudni Global Moderator

    Joined:
    May 24, 2009
    Posts:
    6,956
    Location:
    Somethingshire
    Split from original thread.
     
  11. Kees1958

    Kees1958 Registered Member

    Joined:
    Jul 8, 2006
    Posts:
    5,857
    SPARVIERO bit the syn, syn/nak, nak/can, eot and got sick :blink:

    SEER syn, syn/ack, ack, ack with STEM ;)
     
  12. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Connection still open between us, I like that.

    Regards,

    - Stem
     
  13. HKEY1952

    HKEY1952 Registered Member

    Joined:
    Jul 22, 2009
    Posts:
    648
    Location:
    HKEY/SECURITY/ (value not set)
    Re: Private fw for the non tweeker?

    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:
    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
    3WHS.gif
    TCP Three Way Handshake
    (SYN,SYN+ACK,ACK)


    EDIT: clarity/completeness


    HKEY1952
     
    Last edited: Apr 23, 2012
  14. Scoobs72

    Scoobs72 Registered Member

    Joined:
    Jul 16, 2007
    Posts:
    1,108
    Location:
    Sofa (left side)
    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.
     
  15. Seer

    Seer Registered Member

    Joined:
    Feb 12, 2007
    Posts:
    1,596
    Location:
    Singidunum
    It simply means that the synchronization is done, and ACK packets are now expected.
    Here's from HKEY1952 -

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

    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,
     
  16. datarishik

    datarishik Registered Member

    Joined:
    May 11, 2010
    Posts:
    182
Loading...
Thread Status:
Not open for further replies.