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)
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.
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
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.