SPI features

Discussion in 'LnS English Forum' started by nuser, Nov 26, 2007.

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

    nuser Registered Member

    Joined:
    May 31, 2007
    Posts:
    105
    Location:
    Singapore
    Hi, Frederic,
    In an earlier post, you have mentioned that TCP SPI is applied AFTER a packet has been accepted by ruleset.
    However, a packet belonging to an established connection should NOT be tested by ruleset in the view of SPI. So, is there any possible security problem to put the SPI checking BEFORE ruleset? (which will speedup dataflow)
     
    Last edited: Nov 26, 2007
  2. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,726
    Location:
    Canada
    It is..., and I don't think there's security concerns here, but achieving top-level performance might be of an issue though. I thought originally it should have only the SYN packet initiating a TCP connection be processed through the list of rules, if matching an acceptance rule the session is then entered into the firewall stateful connection table, which is located in kernel memory. Every packet that follows (that does not have a SYN) is then compared to the stateful inspection table in kernel memory (very fast)... If the session is in the table, and the packet is part of that session, then the packet is accepted otherwise it’s dropped.

    However, there's some benefits to the current design.

    Anyways, Frederic should have something interesting to respond with when he returns.
     
  3. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,353
    Location:
    France
    Hi nuser and Phant0m,

    I don't think there is a security problem with that.

    With the current version of the SPI it is not possible to choose exactly when it is called, and not possible to have something different between the SYN packets and the subsequent packets.
    Since it is anyway interesting to block a special port before giving it to the SPI, it was decided to put the SPI check (SYN & other) after the ruleset checking, so it is more flexible.
    Note that the path to block a port is then optimized because there is no need to look for all SPI table entries.

    Maybe this will be changed in a future version to have TCP SPI checking configurable as rules and then the user can put them where he wants inside the ruleset. This is the chosen strategy for the new SPI feature that wille come (but it doesn't apply to TCP flows, only basic Req/Resp protocols).

    Regards,

    Frederic
     
  4. Phant0m

    Phant0m Registered Member

    Joined:
    Jun 7, 2003
    Posts:
    3,726
    Location:
    Canada
    To have just the SYN packets initiating a TCP connections be processed through the regular list of filters, if permitted then there should be little number of checks and filters in an set of filters to be processed.

    When rule existing to permit this SYN packet, and when processed the session is entered into the firewall stateful connection table, which any TCP packets that's not initiating a TCP connection be read firstly and accepted or dropped without going through the huge regular set of filters.

    And since this is Look 'n' Stop we're talking about... :), I propose that there's some way to control and add/del/modify instructions specifically relating to TCP packets, and not have several different unrelated checking procedures involved here. :D
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.