New driver lnsfw for TCP SPI and more...

- OK I can see your reasons for being reluctant now at this moment, and I can’t say I’m against that but if assuming one did set a large limit and there were SPI logging occurrences every app session, wouldn’t you not think this be obvious indication of a flawed SPI design anyways?

- “Out of Connection” Only, is a blunt and least informative I’d say.
By what you said, and my interpretation of this, it seems to me you saying Look ‘n’ Stop SPI implementation does limited state analysis? May I ask a question to what are all Look ‘n’ Stop state analyses?

Assuming for a second that Look ‘n’ Stop state analyses does compare up to other firewalls documented state analyses then it would be very beneficial and much less confusional to be informative for Look ‘n’ Stop SPI occurrences.

Yes, while that is true, many Invalid Flags combinations (that “I” know of existing) can be dealt with by rules, weren’t you the one always against many rules in a rule-set? And furthermore it isn’t like EVERYBODY is using Phant0m``s Rule-set, and you don’t include by default the rules in your pre-made rule-set for every possible known Invalid Flag combinations. And even though it is great to have these capabilities through Rule Edition, there should be in addition a mechanism hard-coded into the application to detect and block which are in regards to state analyses, regardless and for security purposes.

And likewise for packet fragmentation, one of the reasons I used and like Look ‘n’ Stop for all the time I had because of it unique wide range of controls for rule making. But for many reasons I believe packet fragmentations should be in addition hard-coded with global control and switches to enable/disable at user will. And let’s not ignore the idea of Look ‘n’ Stop rule capability only capable of detecting and blocking two types of packet fragmentations, and with your pre-made EnhancedRulesSet.rls there are two “limited” packet fragmentation rules which are off by default if I’m not mistaken?

- It would be nice to see packets with CWR & ECE flags blocked by a hard-coded global implementation with switches to enable/disable, in addition to but not necessary, controls offered through Rule Edition.

- It applies for both, and there is no need for me to start detailing some of those security risks. Just not knowing/uncertain on your part is risk all of its own, risk is a risk, something you willing to ignore or should I say risk it seems.

- I’ll take a look at the most recent Raw Rule Edition Plug-In you have available for download and get back to yea on this one…

However, if it is possible to handle several checks regardless, it should be only temporary for you to have chance to implement into Look ‘n’ Stop. I do have a question regarding usage of Raw Rule Edition Plug-In, how much of possible impact on the performance can there be for Look ‘n’ Stop with the use of Raw Rule Edition?

- I’m glad you found this suggestion of mine elegant, I think it’ll beat the extensive processing that comes with a rule processing, and think of MANY rules that is many times the processing just to achieve a goal.

 

Much of this thread goes whooosh! straight over my head but I must say I value and respect both Frederick and Phantoms`knowledge and am pleased to see both of you discussing your ideas to improve LnS.
Could I ask if its possible for someone to post a screenshot of their HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lnsfw1 Key. So that I can be sure I`ve added all the new entries correctly.
Am I right in having?:
"CheckDNSQ"=dword:00000001
"CheckHSRE"=dword:00000001
"CheckVAEUDTF"=dword:00000001
And also:
"IPFragActive"=dword:00000001
in that lnsfw1 key?

TIA,

Trev.
____________________
Useful Links:
Anti-virus:
NOD32 Anti-virus ... Avast Anti-virus (Free) ... AVG Anti-virus (Free) ... Housecall (Online Scan)
Firewall:
LooknStop Firewall ... Sygate Personal Firewall (Free)
Anti-trojan:
TDS-3 ... Trojan Hunter ... A² (Personal & Free) ... BOClean
Anti-Spyware:
AdAware SE ... Spybot S&D 1.3 ... HijackThis! ... SpywareBlaster ... DialerWatcher
Misc:
System Safety Monitor ... Proxomitron ... Firefox ... SysMetrix ... Rainlender

 

phaedrus - The entries you have are correct. To improve the detection of PCAudit2, it may be required to also activate the following key (this key already exists since several versions, as an hidden feature):
"ActivatedSoon"=dword:00000001

You also need to activate the feature "Watch thread injection" in advanced options of Look 'n' Stop. On the other hand the feature "Watch DNS call" can be disabled (normally CheckDNSQ flag is supposed to replace it).

 

I guess I missed something. Are all the entries listed by phaedrus supposed to be in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lnsfw1 "CheckDNSQ"=dword:00000001
"CheckHSRE"=dword:00000001
"CheckVAEUDTF"=dword:00000001
And also:
"IPFragActive"=dword:00000001
in that lnsfw1 key? (This one I did with the new beta driver).


Where was that info? Thanks.

 

On further review, I now see the other beta driver with those registry entries; lnsfw1.sys. I'll install that too.

 

Hi.
Could you explain me the meaning of this rule ( its function) and if there is a particular position in which the rule must be placed in the internet filtering page?
(i.e. before TCP:block incoming connection...)

Thanks in advance,
Max

 

I have some additional questions, but seeing you very busy lately I’ll only ask couple.

* Is this driver required a newer version of Look ‘n’ Stop to fully operate? I’m still observing problems in regards to Look ‘n’ Stop state table.

* I don’t know if you’ll remember but long ago, days of the Becky Board, I reported issue regarding Look ‘n’ Stop not showing full named addresses and it were fixed, but the problem now has returned, I’ve been observing this problem once again.
…

 

Yes an update of looknstop.exe is necessary to handle some new codes:
https://www.wilderssecurity.com/showpost.php?p=387060&postcount=15

Could you refresh me a little, I don't remember exactly this problem.

Thanks,

Frederic

 

Hi Frederic

Thanks for responding.

- Yea I knew about that, however I’m not in reference to the translation incompleteness.

There is a problem with the state table; things are permanently getting stuck in there for the entire Look ‘n’ Stop session. Now correct me if I’m wrong, Look ‘n’ Stop state table viewer in the GUI only receives the messages, the (lnsfw.) driver is what handles and maintains the state table. And so when the state table viewer in GUI gets refreshed, it is the driver resending the entire table info, so everything shown in the viewer previously gets cleared of its previous information firstly?

- When Look ‘n’ Stop does its translates onto IP addresses to get Named Addresses, the last part in many long Named Addresses gets cut off with =<IP>

 

Hi Phantom,

Yes, you're right but the risk is to have some side effect if someone put a large number, and I don't want to spend time investigating this.

The TCP SPI handles almost all the usual TCP state (according to the RFC).
But I don't understand what kind of information this can provide when an "out of connection" packet is detected.
For these packets there is no state, and this is why they are detected.

Could you give an example of what kind of information could be provided ?

I'm not favourable to hardcoded methods when it is possible to do the same through the rule (and by the way this is why I found your suggestion about handling IPs list elegant, it avoids to have another specific blocking module, just an extension of what is existing).
No, I'm not against many rules in a ruleset, when the added rules are common to all users, and have not to be configured precisely by the user.
So, if there is a set of rules about bad combination flags, no problem to add it in the enhanced ruleset.

Yes, these rules were not activated by default because with some internet providers, having fragmented packets is something normal.
What is not normal is to have fragmented packet without having an initial one (saying the datagram is imcomplete), but this couldn't be detected by Look 'n' Stop with the current version.
Now, with the new feature which tracks the correct fragmented packets, these two rules could be activated by default with no problem.

Yes, I agree I take a risk, but I consider the risk as being very limited. And if there is a new vulnerability discovered here, I will try to react asap as usually.

No impact at all on the performance. For the driver there is no difference between the two kind of rules (actually all the rules are seen as raw ones).

Frederic

 

Yes, everything is cleared and the driver resend all the information.
The problem is some new states should be considered as closed by Look 'n' Stop and therefore not displayed, and it is not the case currently with the current version of the exe.

Ok, I suppose the new size I've put is not sufficient. Are you talking about the log page or the TCP Connections window ?

Frederic

 

Hi nv 25,

If you look at the TCP header for instance from here:
http://www.soft4ever.com/LooknStop/En/TramesetRFC.html
you will see the usual TCP Flags and a reserved zone just before.
With standard protocols the bits of this zone should be normally set to 0.
This is what does this rule: it blocks the packet if one of the reserved bits is set to 1.
With some particular protocols, two of the reserved bits are used, and in particular the two ones just following the standard TCP Flags, and these two bits are named CWR & ECE.

And by the way I just notice using my FTP client these two bits are not always set to 0 . I don't know if it is normal or not, but I have to disable the rule on my PC as soon as I use my FTP client .

Frederic

 

- ok, I see some problems here, firstly my theory is Look ‘n’ Stop isn’t using or properly using Time-outs, things being seen “Connecting” for instance for the entire session of Look ‘n’ Stop, and this can be days, weeks and even months.

I don’t even use "History of the last connections" but I’m seeing connecting entries and closed entries that are permanent for the Look ‘n’ Stop session, the driver definitely should have time-outs for connecting, as for closed entries which I also see permanent for the entire Look ‘n’ Stop session, this information shouldn’t be kept more then an hour at the most, and at that time cleared from the records.

 

- both.

 

Thanks Frederic

I appreciate you responding to this.

- I can understand that, but I was thinking at least a temporary ReG_Tweak for the advanced users.

With this here recent driver, I still experience legit initiation connections being blocked by Look ‘n’ Stop SPI limit. If it weren’t for that fact I would be using Look ‘n’ Stop SPI and running my own thorough tests without SPI interfering with normal everyday activities.

-
- At least four SPI Logging descriptions that should be used to inform.

1. "Out of connection" - This can represent either a non-SYN scan or a packet arriving after a particular timeout value has caused the tear down of a connection.

2. "Invalid Flags" - This condition occurs when a packet arrives with a delay beyond its corresponding state timeout values.

3. "Invalid Sequence Number"

4. "Invalid Acknowledge Number"

And for each limit, Look ‘n’ Stop should have reason for its SPI Log occurrences.

This would be shown a lot less confusion for both of us, you and the customers.

- Since SPI does it all, all you needing is the reasons to be informational…
* "Invalid Flags" – NULL
* "Invalid Flags" – ACK
* "Invalid Flags" – FIN
…

The only reason I prefer to use rules to handle (all those which can be done without the use of an SPI) is for the labelling purposes, to be informational for Look ‘n’ Stop customers, to better inform them what is or has been occurring to make up for the incompleteness non-informational Look ‘n’ Stop SPI logging occurrences.

- k, but what are your thoughts about offering controls for series of checks on fragmented packets?

-

-

 

About the filename/service name - how come it in the registry is named 'lnsfw1' - but the file is only 'lnsfw'. Should I rename the file in system32/drivers folder to lnsfw1?

I DO have both a lnsfw1.sys and lnsfw.sys in my system32/drivers folder. Which one is in use?

Thanx

Edit: And btw - wouldn't a .reg file be in place to add along with the beta updates so everyone has the correct keys added? - Could be something like this:

Code:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lnsfw1]
"CheckDNSQ"=dword:00000001
"CheckHSRE"=dword:00000001
"CheckVAEUDTF"=dword:00000001
"IPFragActive"=dword:00000001
"ActivatedSoon"=dword:00000001

 

No, don't rename the file. Both lnsfw.sys and lnsfw1.sys (the low-level drivers for the firewall) are used by LnS. I imagine Frederic chose to use a single registry key of "lnsfw1" to keep everything in a single place.

I agree Frederic should add a link to a .reg file in the first post in the thread to make it easy for users to apply the relevant changes. However, the line "Windows Registry Editor Version 5.00" should be changed to "REGEDIT4" because that works with older versions of windows. The same should be done with the other beta driver thread.

 

Thanx Defenestration - and yes, of course, the .reg should be usable for all win version...

 

I installed this driver, without having enabling the 'standard' (2.05p2) first. So I do not know if this is a problem regarding the new release.

If I enable TCP SPI, I can't connect to a lot of websites. Or only some parts of the websites are shown (i.e. the frame a the top). Is this a known problem?

With regards, Ernst

 

Hi Ersnt,

Did you notice some alerts in the log page ?

Normally activating TCP SPI is not supposed to block the websites.

Perhaps a problem with fragmented packets. The log content should help to verify.

Frederic

 

TCP SPI on:
I think this problem is related to the number of connections. If I do not run Emule and BitComet, it is ok. If I only run Emule, most of the time it is ok. But if I run them both at the same time, Firefox has trouble to load some pages. Those pages are radomly chosen.

TCP off:
It doesn't matter which program I run: I can look at every webpage.

On the logpage I see a lot of entries of SPI. But I can't really understand them. All entries on the log page are blocked?

(If you need more information, ask me)

 

Yes, it is probably related to the number of connections if you are using intensively P2P.
However with this last beta driver this kind of problem is supposed to be less frequent. Many users reported they can now activate teh TCP SPI when using P2P.

To verify if the problem is related to the number of connections, open the console, ask for driver logs and just after "FW:" if you see some "CFull" indication, this means there was no free entry to add a new connection to be monitored.
You may also see NCF indications which mean "No Connection Found" (ie one packet is not part of a known and active TCP connection, and thus this packet has been blocked).

To decrease the number of alerts with P2P, you can specify the following registry key:
[HKEY_CURRENT_USER\SOFTWARE\Soft4Ever\looknstop\options]
"SPIInOnly"=dword:00000001
or
[HKEY_LOCAL_MACHINE\SOFTWARE\Soft4Ever\looknstop\options]
"SPIInOnly"=dword:00000001
(depending if the registry option is set to "per user" or "system").
The change has to be done when Look 'n' Stop is not running.

After this change only received packets (from internet) will be blocked and will cause SPI alerts, assuming the packets sent by the PC (to internet) are anyway OK (even if no connection is found).

Frederic

 

Yes, exactly.

"IPFragActive" has to be put in LNSFW1 entry even if it applies to LNSFW.
As Defenestration said, this is to have everything in a single place, but also because the LNSFW is actually the SFILTER key which could be a bit confusing.

Frederic

 

I am using LnS. I do hope when this driver is placed into an update it does not require understanding what is being talked about here.

Of course, I assume that is the reason it is beta, and these discussions result in the final version being something that someone like me can just install as an update, and then never know it is there.
I appreciate all the efforts so that when I do install it there will be no problem.
Jerry

 

In the future, are you going to release that is not affecting P2P?Or do you think the SPI can't be made more efficienty?