Stateful Packet Inspection : ideas for the future

I saw the other thread about it, but it ended up in a quarrel between Phant0m`` and gkweb, and PaulWilders eventually locked it.

Anyway, I think we should go on discussing about the SPI topic, as it's clearly something LnS has to be worked on about.

As for me, I tend to think that 128 TCP connections is a limitation that should not be...

I know maybe LnS code's difficult to adjust to include the 'no limit' feature...it might have to be mostly re-written, I don't know...If Frederic said "I need time, I've been working on that", I'd take it as a good thing...I mean, no one can pretend to have the 'cake' baked in one hour (or just a few days...)

Phant0m`` is right when he says that many other sw firewall have no limitations on TCP connections, and work good on quite any modern PC without eating such a lot of memory and quite any band at all..

So, my question is: stated that I LOVE LnS, I really would like it to have this "SPI no limits" feature, in its future versions!

I'm not that expert about protocols and the like, though I know how to look down over the topic..That said, I had really no idea of LnS TCP limitation...I found out there was something wrong when using WinMX...after a while I would not browse nor do anything at all anylonger...
First I thought it was WinMX, but then, looking in LnS log win, I noticed at least as many as 10 TCP SPI lines added per second!
TCP SPI feature disabled, situation back to normal...

That's not a good thing, anyway...We can't expect all LnS users to be some ProtocolMasters and that they're able to find out what the problem is, when it comes to use P2P software...
They might be told to disable the feature...but then why is it there? It is because SPI is an important feature!

So, here's something Phant0m`` said which I completely agree with:

Of course I like to control any single aspect in my firewall...but sometimes I just might want to "set and forget" it...

I say it again, I love LnS but I also love to use P2P software...and, be the situation as above, LnS can't be a set and forget firewall.
That's a pity, and a reason why many users might stop using it...

It's not easy if the user has to go into LnS settings and disable SPI and start his p2p sw..and when finished, call back LnS and re-activate SPI...and wait! I forgot to search for a song! So back to LnS, SPI off again...

So, Frederic, please work on that...

My 2 cents...

 

Hi all,
while I agree that SPI is a major feature of any firewall, I think it's a tough question on whether or not to limit it.

The problem is that - conceptually - you're implementing your own DoS vulnerability into your firewall both ways: with a bounded SPI table, you've just described how a lot of connections (as we nowadays can initiate very simply, day-to-day-like with a P2p app) can can lead to a factual block of your internet connection, but with an unbounded table, you're practically inviting malware to DoS you (e.g. send messages to hosts that you know have lots of connections (because they appeared on a p2p portscan), which will have them compare the new packet to every entry in the table. and send lots of those messages (I've just thought of that strategy, don't nail me on it)), and you'll have your CPU practically blocked and won't be able to do anything either.

The conceptual problem will not go away, merely be alleviated, by a clever implementation. That's why I would at least like the possibility to switch everything involved on or off - both the limitation and the SPI itself. Drop that choice and you wouldn't have a major feature, but a major problem there. IMHO.

All of this doesn't mean that I'm for or against the option of unlimited SPI. Only, if Frederic finds an effective way of implementing it (if there is one, taking LnS's basic architecture into account), I'd insist on having the option to switch it on/off.

I, for one, disable Internet Filtering when I'm using P2p. (P2p is a ride on the razorblade anyway.) Another way would be to disable SPI when on p2p. Another thing you should do anyway is setting your max. sources / max. connections in your p2p software.

Possibly increasing LnS's SPI limitation to the P2P software's default of max connections could be a feasible first step for future LnS versions?


My 0.02 Euro

Andreas

 

You might be right...anyway I'm wondering how some firewalls can handle the unlimited TCP connections without the browsing speed being affected...

Yes, I agree that choice would be the best thing to be implemented, so to have LnS to fit any specific user's needs!

 

Yummy!

Here is what we probably determined to this point:

* TCP Stateful Packet Inspection is crucial
* Mainly the p2p (peer-to-peer) users are effected
* And I think it would be fair to assume majority of Look ‘n’ Stop users uses p2p Software.

My observations:

- Regardless how many TCP Sessions or I prefer to say TCP Connections I can possibly make simultaneous in-attempt to test different Software Firewalls with minimum TCP SPI, there were no delays, freezes or out of the original resource usage WITHOUT THE USE OF LIMITATION FOR MONITORED/ALLOWED TCP sessions/connections.

My Suggestions:

+ Use Netfilter concept; by default, the maximum number of connections that Netfilter will track depends on the amount of memory available. On system with 256MB, this is 16376. Like Netfilter offer customizable feature for one to increase OR decrease at will!

My Thoughts:

= Look ‘n’ Stop Personal Firewall is incredibly powerful as-is, it is definitely far superior then most Software Firewalls I’ve seen. It’s just that I’m incredibly picky over the Packet Filtering systems in the Software Firewalls I use; this doesn’t mean you all have to be the alike.

Additional word; I also don’t like to be limited, I’ve been limited in so many ways and I refuse to be limited on my computer.

Bests Regards,

 

While I am unaffected by the current limitations placed on TCP SPI since I do not use any p2p programs, I can see how this could be a pain for those who do use p2p. There is no reason why people shouldn't be able to use Look'n'stops TCP SPI all the time without having problems. Since this is a design issue in Look'n'stop, it does really need to be looked into seriously by Frederic and changed somehow for the next version imo. It should be a top priority I would hope. Improving the packet filtering is the most important thing, much more so than anything else - including taking care of those stupid leaktests.

 

I dont know the core structure of the engine, but the ability to define your own max connections through SPI would be useful.

At a guess it would come down to the buffer/cache sizes used to capture, interogate and allow or deny stack data. By keeping the arrays, heaps etc statically sized, it will really help improve performance, as soon as dynamic, theres going to be a lot of waste cycles.

If it does require an extensive rewrite, id rather wait for LnS 3 in a complete manner, than a hacked together attempt to keep the crouds happy, as even without SPI, LnS is still one of the top software firewalls.

 

I just wondered what Frederic thinks about the subject...

 

Hi All,

Well, TCP SPI & P2P in LnS is still a controversial subject .

So I will try to propose an implementation which:
- works with P2P applications
- let the user change the limitation if required (perhaps only as an hidden feature, assuming the default case will suit to standard P2P needs).
- doesn't slow down the performances

I don't know yet if a complete rewritting is needed. This question is tied to the maximum number of TCP connections in case of P2P, the TCP SPI has to watch.
If it is 100000, yes probably things have to be done differently. If it is only to support about 500, perhaps not.
So, your inputs are welcome on that point.

Thanks,

Frederic

 

Great - go this way and we will get somewhere

Ruben

 

Yes, there have been many discussions on the LnS-P2P issue here in the forum.

I would like to ask the 2 provocative questions:

1.) Should Frederic spend a large fraction of his energy on the implementation of P2P-support in LnS ??

I would say: NO! There are a few other issues, which are more important for LnS: For example a correctly working application filtering (it is still not correctly working, at least on my system!)

2.) In addition, should Frederic spend some time on the efficiency of LnS to detect "leaks" (some of these dangerous leaks can be seen/tested at gkwebs website) ?

I would say: YES!! This is where LnS should go!

If I prefer to use P2P software in Windows, why do I need a software firewall at all?? Modern P2P requires >500 open ports on a local system. So why using any software firewall under these conditions? Your computer will be open like a swiss cheese

If you like to use P2P and you are concerned about internet security, you better go for Linux and create a user with maximum system restrictions! Under these conditions it might be safe to use.

Just my 2 cents,
Thomas

 

Is the SPI implemented in Look n Stop aware of the applications making the connections?

If so, how about keeping the default connection limit, but providing a secondary limit for applications specified by the user?

The default limit could be used for connections made by all applications except those specified to use the secondary limit.

The secondary limit could allow more than the default limit, but would only be in effect if the applications specified are in use.

Possible? Impossible? I have no idea... Just my two cents

 

I'd really appreciate if you could do what you wrote...stated what I've already written in this thread...
I don't know how many spi calls may be done while using p2p sw, but I'm sure they're more than 500..though less than 100000...well, depending on how long you leave your p2p application on...
Not all the people have routers with hardware spi blocking features...I don't either...so I must count only on my software firewall!

Anyway...thank you for thinking about doing the changes we've been asking you!!

 

I think the best way is to disable Internet Filtering and install a professionnal firewall who support TCP SPI without limitation and other new UDP SPI approach.
So just keep the looknstop application filtering and no more problem with P2P

 

Here is the breakdown solution... Lets make everyone happy! LOL

<<Stateful Packet Inspection>>


[x] Default Connections with SPI = 128
(enabled by default)
[ ] User defined SPI connections[#]
____[ ] No limit

[Select File] Add an application

Application Connections
KazaaLite.exe [#]
WinMX.exe [#]
Blahfile.exe [#]

The user can ethier select the standard limit as provided "in box", define the limit, or choose the no limit option. The "add an application" feature allows for the user to bump up the number of SPI protected connections when they are running and to return back to the standard default when they are terminated.

Key
<<Stateful Packet Inspection>> Tab within main menu of Look 'n' Stop
[x] checked box
[#] user defined set of numbers
[Select File] buttons
[ ] unchecked box (by default)