Internet-filtering rules limit! My today’s beef, a very old beef!

Hey Frederic

My today’s beef is a very old beef; my beef is the Look ‘n’ Stop Internet-filtering rules limit, my personal copy of the Ruleset is MAXED-OUT to the very limit and has been for some years. Is it a surprise? I don’t believe it to be the case, Look ‘n’ Stop doesn’t have ( IDS ) Intrusion Detection System yet, so it should have been obviously foreseen by far that a user would rely on rule creations via Internet-filtering. And server rules needing for variety of applications that acts as server, take p2p software and variety of p2p networks and lot being used by each individual. And look at when allowing or blocking, one rule per IP (with masking usage), two IPs without masking...

Is there a particular reason for this limitation for very small amount of rules? Does Look ‘n’ Stop somehow differ from other rule-based firewalls that a significant amount of rules would make Look ‘n’ Stop PF unusually slower in this aspect?

The question is do you feel this restriction is that necessary? And even worth addressing sometime soon?


Thanks…

 

Hi Phant0m,

100 rules was supposed to be large enough...

The reason is performance. There is nothing special done to optimize the rule verification, so having a lot of rules could slow down the internet connection, since for each packet many rules have to be examined.

If you didn't experiment any performance/slowness, I could extend a little the number of rules (128 or 150).

Using the RawRule edition plugin you can extend the possibilities of the ruleset. To do that you just need to have two consecutives fields using the same offsets and you have to use "positive" criterias (I mean, "equal to", "or equal to", "range in"...). In that case (since it is not useful to have an AND for the same field offset check) the driver performs an OR between these two fields consecitive field testing the same position.
So theorically it is possible to check for 16 IP address per rule, or 8 IP ranges (since there are two fields and since 1 is required for ethernet protocol, and 1 for IP protocol).

Frederic

 

As I have said, my personal ruleset copy is maxed-out and has been since forever and I haven’t seen any noticeable performance / slowness being traced back to Look ‘n’ Stop product.

I can tell you what would be very beneficial in this area, implementing Trusted / Deny Zones like shown by various other firewalls, and of course this includes the masking capability…

And also feature built into Look ‘n’ Stop to retrieve LAN computers, every retrieved machine entry should have two columns, both with selections, one for NetBIOS to permit or deny another to set it to Trusted.

This would help a lot right there!

 

I thought my suggestions were awesome ones!

 

I thought the discussion was about the number of rules to allow IP address.
And your last post is about trusted/zone, netbios authorizations... which is normally not a problem, even if there is no dedicated dialog box to do that (this is currently the way Look 'n' Stop is designed: no special dialog box to create hidden rules besides the Internet Filtering page).

Frederic

 

Right! It is about number of rules in a Look ‘n’ Stop rule-set, whether it is to permit or deny… I thought I’d be funny to show you how badly the need for more rules in the Look ‘n’ Stop rule-set is needed.

I have several rules in the rule-set dedicated just to blocking IP ranges, nothing fancy, creating special area (either through hidden dialogs or separate TAB or from a single rule on the Internet filtering screen), as long as it is a native part of Look ‘n’ Stop I would be really excited. If you made special setup dedicated to the blocking of IP ranges you could optimize the processing of the list and be far faster then what it would be as separate rules with various fields to be applied / checked / compared too currently like done on the Internet-filtering screen…

 

I second this request, although I'm yet to starve my amount of rules on Internet rules (I'm almost starved and thinking ahead).

I really wish the Application Filtering rules would be increased as well. I've totally exhausted those and that's why I've switched to a completely different firewall.

Is it as good as Look'n'stop, well yes and no.

But I'd much rather continue using LnS, if it wasn't so max ruleset limited for my needs.

 

You aren’t the first person I know of to have switched do to these Look ‘n’ Stop limits…

And as for myself, I find these Look ‘n’ Stop limits are upsetting…

* SPI (Stateful packet Inspection) I can’t use, because of its unusual / non-custom limit.
* Application filtering rules are maxed-out
* Internet filtering rules are maxed-out

 

If the ruleset is full because of IP ranges, did you try my above proposal through the rawrule edition dialog box ?
Note that users don't require this plugin to use a rule that have been edited with this plugin. The .rie will be anyway compatible without the plugin installed.

Frederic

 

This one will be configurable through the registry in the 2.06. Up to 1024 simultaneous TCP connections.

Frederic

 

YES!!!!!! YOU ARE THE MAN!!!
I’ve WAITED a very long time for that change!!!!

Look 'n' Stop ROCKS!!!!!

 

Oh, the RawRule plug-in isn’t necessary, just to create it but the processing of everything is done just with the application? Therefore one rule equals 8 Masking addresses covered without a RawRule plug-in?

If this is correct, I understand this correctly, I never knew this!

 

In this case things changes a bit, but I’d still prefer to see a special area where the processing of multiple IP & IP masks are compared without extra fields being retrieved, and compared…

 

Yes exactly, the processing is even done mainly by the driver itself since the raw format is actually very close to what the driver is handling.

Normally, yes. However, this has not be used very deeply so far, so some problems may surface, but I will support that.

Frederic

 

You are right, there are problems…

Working with masking is a huge problem for this plug-In

 

Hi Phant0m,

I don't know what problem you encountered exactly, but you are right there are some problems, especially with criteria above NOTMASK_VALUE1.
I no longer remembered that I had already worked on that:
https://www.wilderssecurity.com/showthread.php?t=150914
So it is not working as I mentioned above sorry for that.

Unfortunately the problem is not in the plugin itself but in the application. This is fixed in 2.06.

Frederic

 

Use of two or more fields seems to be using hard-coded ‘AND’ instead of ‘OR’, not at all matching up to the information you have previously posted on this topic, saying it does just the opposite… I checked the server today, the plug-In I download is no different then the one I’m using already

 

This is not true.

When two consecutive fields are using the same offset and same size an OR is applied.
This behavior has been validated by several persons.

The problem is it works only with the following criteria:
EQUAL_VALUE1
RANGE_IN
MASK_VALUE1

The following one is not supported (because of the bug I mentioned):
EQUAL_VALUE1OR2

So, yes I agree it is not possible to check for 16 IP address as I said, but 8 at this time.

Frederic

 

I don’t think we are on the same page; you said through the use of the raw rule plug-in that I could do multi-masking handling. Masking I need to apply the ‘MASK_VALUE1’ criteria or am I mistaken?

When I apply just one mask handling, it works, when I use another consecutive field and apply another mask, then neither works. I’m sorry I have to insist that something like ‘AND’ instead of ‘OR’ is being applied between consecutive fields…

 

Hi Phant0m,

I've verified again this specific criteria and you are right it is not supported for this OR behaviour between consecutive fields.
Only the following criteria are supported actually:
- EQUAL_VALUE1
- RANGE_IN
- RANGE_OUT

Phant0m, my apologies, I should have checked more precisely the limitations and real behaviour of that feature before proposing it here.

Regards,

Frederic

 

It is okay Fred.

 

The plugin itself cannot be updated to address this masking problem, I assume it is a problem with the driver?

 

Actually the problem is in looknstop.exe.

Frederic

 

Ah I see, I thought the Look ‘n’ Stop packet-filtering driver handles the processing of the Ruleset, so if it is the looknstop.exe, it must mean the looknstop isn’t correctly obeying the rawrules plug-in when creating the necessary information to make the masking support?

The question now would be how should the Ruleset file be seen when having successfully been updated for masking support?

 

It is likely irrelevant though, a plug-in itself cannot make a change to the Ruleset directly, well it can but the Look ‘n’ Stop uses the memory load and dumps on … shutdown / restart and especially upon changes to the Ruleset. And there is no way momentarily to call a reload of the Ruleset with Look ‘n’ Stop application using a plug-in, so it is likely the changes directly made to be very fruitless…