New driver lnsfw for TCP SPI and more...

Hi all,

Here is a new beta driver for LNSFW.SYS/Internet Filtering.

The main change is about the TCP SPI:
- bug fixes (related to bad detection of closing state)
- 256 entries
- improvements regarding timeout handling

Some other changes in this new driver:
- fix for "Different And" criteria which was not working (thanks Phant0m )
- support for IP Fragmented packets. When an IP datagram is fragmented, now the ruleset is applied only to the first packet of the datagram to know the behaviour (block/allow/alert), and same behaviour is applied to the other packets of the datagram.
To activate this feature you need to add the following registry key (and reboot):
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lnsfw1]
"IPFragActive"=dword:00000001

This new driver is available to download here:
http://looknstop.soft4ever.com/Beta/lnsfw/lnsfw.sys
Update: this driver is now included in 2.05p3 version available here, and no longer available through this link.

To install it:
- rename your current C:\WINNT\system32\drivers\lnsfw.sys into lnsfw.old (to come back to a working driver in case of problem)
- put the new file in C:\WINNT\system32\drivers
- reboot

Note this is anyway a beta driver, so you should not use it if you are afraid of encountering problems...

Regards,

Frederic

 

Hello Frederick,

Thank you for the update,and glad to see you and Phant0m are working together again, you make a great team!

 

Hi Frederic

You call this a beta driver? It surely doesn’t feel like one…

I’m very pleased to see the release of this here beta driver; it was definitely long over due fixes and adjustments, and I’m very happy you decided to put some effort into Look ‘n’ Stop SPI Implementation.

I have tried it out some, and I really like.
I believe many Look ‘n’ Stop customers will also like a lot too.

Even though adjustment to entries had been heightened, I do still experiencing problems.
I really, really, really, really and really hope you decide to include a hidden or not, custom feature to adjust this fixed limit.

I hope this is a beginning of something very beautiful, I hope it continue to furthermore improve Look ‘n’ Stop packet-filter, to have it cover many of today’s malformed and incomplete and invalid packets, have it detect/control more then just a couple types of packet fragmentations, and to improve on the stateful engine to better inform users of reasons for its SPI alert occurrences, for instance ….“Out of Connection”, “Invalid Flags”. I like to see feature to detect & block TCP packets containing CWR, ECE flags. I also like to see virtual connections caching for UDPs and ICMP state to cover Ping Request/Replies and so on. I personally feel there is much that should be done to Look ‘n’ Stop packet-filter, and to be honest just the few things I mentioned above is just the beginning and I hope you can understand my reasons for saying this and for wanting, and hope you’ll give it some serious consideration. It is not like you’ll be alone on this, I’ll be helping you all the way, and you just need to be willing!

I also like to see a feature, Plug-In possibly? To offer much more control over packets, to allow me make rules to detect different types of scans, malformed, incomplete, and invalid packets.

I also would like to see feature allowing us to make IP list that capable of holding two or more IPs, able to make new IP list and same with Port list capable of holding two or more Ports, able to make new Port list. For instance an IP list can be used for Ingress Filters, able to add all Private IPs that should not be used over Internet. Have the Rule Editor have a selectable list that can choose one of the created IP list available such like the one for Ingress Filters, the rule can be set to authorize or block, and this will apply to all the IPs in the list, the same pretty much goes for port list.

Btw; Excellent job on the fix for "Different And" criteria, works beautifully now, I can really work with this feature…


Thanks Fred!

 

I've got a really dumb question. Is the value in the registry key hexadecimal or decimal?

Thanks

 

You can select Hedadecimal and enter "00000001", which will be converted to 1.

 

Umm, on Windows 98 I cannot locate the driver or the folder.

Some help please?

 

the modification to the driver seems to work perfectly and apparently the problem relative to the cohabitation of L'n'S with emule, thanks to 256 entries, is old.....
Great, great job!

 

Could someone tell me which directory to install it to?

because I can't find the directory or the file.

 

i suggest you to search "LNSFW.SYS" with the search option from start menu...

 

After the search, I find :

lnsfw.sys C:\WINDOWS\Desktop (The driver I downloaded)
LNSFW1.vxd C:\WINDOWS\SYSTEM
LNSFW C:\WINDOWS\SYSTEM

Help?

 

it should be what I left....

 

Huh?

It's a .vxd file not a .Sys

Should I put the driver in that folder?

 

This driver update is only for Win2K/XP/2003 Server

 

Is it normal that after installing the new driver my "TCP Connection State Window" shows these huge number of closing connections ?

With the previous drivers my list of closing connections was much smaller

Thomas

 

Hi Thomas,

Yes, this is normal, the status codes are updated in this version of the driver and are not aligned yet with looknstop.exe.

"Closing: 960" and "Closing: 963" have to be considered as Closed
"Closing 4" has to be considered as Connecting.

Regards,

Frederic

 

Yes, sorry there is no Win9x/Me update at this time

Frederic

 

Any estimated date when a Win98 version will be available?

 

I agree with Kasmir. You and Phantom make a great team .

 

eMule seems to be working well with SPI now...
Should please the p2p users here..
Thanks for the good work

 

Thanks Frederic! Been running it for a couple of days now without any problems. Only thing I notice is more entries in the Log compared with the previous driver. Is this to be expected ?

LnS just gets better and better!

 

Sorry, I don't know yet. Anyway the Win2K/Xp driver has to be finalized first (regarding these improvements).

Frederic

 

You are welcome

What kind of entries do you notice ? TCP SPI alerts ? (if yes, are you using P2P ?)

Frederic

 

The main entries in my log are DNS-Allowed-1, +TCP: Block incoming connections, and Block: All other packets. I was thinking this might be due to the new support for fragmented packets where each fragment is treated separately, whereas before several were lumped together. Could this be the reason I'm seeing more entries ?

BTW, I'm using Phant0m's ruleset.

 

Hi Phant0m,

Thanks for your comments.
Here are some explanations and additional comments.

Regards,

Frederic

I'm a bit reticent to do that because I don't want people having problem because they put a large limit here, in order to solve supposedly issues because of the number of simultaneous connections.
For instance, with the last driver there was actually some bugs, and increasing the number of connections was not the solution (and I'm afraid it would have complicated some investigations).
So I would like to be sure first there is no other bug behind.

Basically, the TCP SPI alerts are all related to "Out Of Connection" packets. Looking at the TCP flags of the packet will just give some additional info but not another reason.
Invalid flags are caught by some other rules. Same for packet fragmentation.

I think this is already possible with Raw Rule Edition.
Here is a raw rule, that will detect any TCP packet with any of the reserved bit not set to 0:
http://looknstop.soft4ever.com/Rules/TCP Reserved Flags.rie
This includes normally CWR & ECE Flags.

I agree it could be interesting to detect and block any strange packets to control everything, but is there really a security risk here (a direct one or a non-stealth one) ?
This is mainly to know the priority of such improvements.

Normally the Raw Rule Edition plugin is already able to detect any kind of packet. If something is not possible, could you specify more ?

Yes, thanks for the suggestion, this is perhaps an elegant way to proceed in order to keep anyway the system of rules.
I'm just afraid of the number of IPs or Port to handle. If it is huge (>100 to give an idea) this could dramatically decrease the performances of the internet connection if the implementation is too simple.

 

Hi Defenestration,

If the blocked packets are fragmented, now you will have one alert per fragmented packet (the initial packet of the datagram as before, and the other packets on the same datagram).
With the previous version I suppose you were allowing all fragmented packets so you didn't have alerts for fragmented packets.

This is the only reason I see at this time to have more alerts. Normally you should see that in the Additional column, where fragmented packets are clearly notified.

If the new alerts are not fragmented packets, then another reason has to be found. And perhaps you should deactivate the IPFragActive registry setting (just set it to 0 to keep the entry) to verify it makes a difference regarding the number of alerts.

Another question, are your internet connections anyway Ok with these blocked packets ? Because if incorrect packets are now blocked, this should have an impact on some application or the internet connection.

Frederic