LnS "primer"- what can be hard to understand from the beginning

OK, here are a few things about LnS that were unclear for me at the beginning (and maybe for some other users). Now I hope I understand things right:

1. LnS is composed of two *independent* filters- application filter and network filter. Application filter allows/blocks applications, and network filter allows/block packets. Thus, allowing application through application filter does not mean it can connect to outside world- appropriate rules in network filter are required. These are so calles TDI (application) and NDIS (network) filters; some diagrams here: http://www.ndis.com/papers/winpktfilter.htm.
2. Application filter is like monitoring connect() and bind() calls from Un*x, world with possibility to define allowed/blocked ports and addresses for outbound TCP/UDP traffic.
3. Network TCP filtering is basically stateless, however there are 3 features that make up a bit for this deficiency:
- possibility to define two-way rules
- ability to block incoming packets based on TCP flag values.
- possiblity to turn on stateful packet inspection in Advanced Options, that in LnS automatically drops packets that do not belong to properly opened connection (*Note these*: There is no automated opening of ports for fe. inbound traffic for connection opened by WWW browser, previously allowed by application filtering and network filtering. Also, only up to 128 connections can be tracked and after the limit is reached next are not allowed, which can be a problem fe. for P2P users).
4. LnS binds itself to interface selected in options tab. That means, that network filtering is possible only for this interface, other traffic will not be detected. *However*, application filter detects applications connectiong/listening on every interface (so actually you can block application accessing any interface), *but* (I will test it more) TCP/UPD ports/addresses filtering is active only for selected interface (is ignored for other interfaces than selected).
5. After starting LnS first application you probably would like to allow is C:\WINDOWS\system32\services.exe (change c:\windows part if needed), it performs DHCP and DNS lookups. Also, C:\WINDOWS\system32\wuauclt.exe is the thing that performs automatic updates (btw, the file wuauclt1.exe is legit but not requested for automatic updates).
6. Any changes in settings (like turning on/off application/network filtering) may be not immediately active. You just need to wait a moment for them to "catch up".

Please correct me if I am wrong.
X.

 

Hey Xyzzy

You obviously did some research, excellent researching…

I agree that there isn’t really much information on different aspects of Look ‘n’ Stop floating around on the official website or the forums even, though if anyone really interested in asking some questions, just contact Frederic via E-mail and he would be more than excited to answer your questions. That is one thing I especially like about Frederic, isn’t nothing he would not answer and answer honestly about his product.

Now something you didn’t mention is; Look ‘n’ Stop does detect applications accessing server environments in addition client environments, and on this note Look ‘n’ Stop unlike other application filtering systems detects very early in the stage before connection information is possible.

The only real dislike I have for Look ‘n’ Stop Application filtering is the fact it doesn’t specify between listening and connecting with no way to control either thing separately like ZoneAlarm for instance, Look ‘n’ Stop control works at a global level, very annoying and misguided way I believe…

 

As I mentioned earlier (in another topic) you have to exit out of all client applications and re-launch once you enable Look ‘n’ Stop SPI (by default of Look ‘n’ Stop Install it is OFF) otherwise you experience connection loss of all current connections and connecting issues.

And if people were to enable that feature they should know also this, Look ‘n’ Stop SPI implementation will interfere with some clients/server software, and not necessarily have to correspond with P2P, and it does have a major impact on P2Ping.

No one should be without stateful packet-filter (correct me if I’m wrong but don’t XP built-In firewall offer excellent stateful packet-filter?), but if experiencing problems you can make rules to clean up bit of the “leaks”, for instance If one were to view my publicly available rule-set this person will notice majority of the blocking rules were for TCP Invalid Flag combinations and this covers everyone except one particular TCP scan type that can only be dealt by the use of a stateful packet-filter. It has been awhile since I saw my publicly available rule-set but if my memory serves me correctly, 16 TCP Flag combinations to be blocked, which means 16 rules used in the rule-set to cover this aspect. If you were to be using SPI, and using my rule-set the blocking of these 16 TCP Flag combinations would be done at much earlier stage, by the standard packet-filter with those 16 rules before SPI even has a chance. I always preferred this way because Look ‘n’ Stop SPI logging aren’t detailed and offers no information on reasons for SPI triggering. With those rules in place, on a blocking and log displays the rule-name, the labelling of the rule will keep the viewer informed of what has occurred. Among a list of reasons I think Look ‘n’ Stop SPI implementation being incomplete, this is one of them (no SPI detailed logging)…

As for your number 4, you can run several Look ‘n’ Stop instances to cover other Network Interfaces, I always been wanting something that ConSeal PC Firewall offered from the beginning (Rule-set scope feature) to offer way to have the one rule-set apply for all Network Devices and Separate Rule-sets for each device without needing to run other Look ‘n’ Stop instances…

 

1. I added "(so actually you can block application accessing any interface)" if anyone wonders what was changed in original post.

2Phantom

2. Do you mean "detecting application/dll that runs connecting application" by "detect applications accessing server environments in addition client environments"? If no, what do you mean by that?

3. Well, as for lack of control similar to ZA's one- I admit this would be more comfortable than current handling. I wonder if it can be done in LnS without affecting any of its present features and characteristics? I prefer more careful planning and clear way the application works to easy setup but hacks in software.

4. "SPI implementation will interfere with some clients/server software". So the SPI option sometimes fails and blocks legit packets?

5. I agree that LnS may feel uncomfortable for anyone who hasn't dealt with ipchains in command line

6. As for features, full state inspection definitely should be there, regardless of how it can be simulated with available features. However, as I understand it, you still would need to define blocking rules for flags, as already opened connection might be used for attack.

X.

 

2. Basically what I had said, Look ‘n’ Stop Application filtering will detect applications attempting to act as server….

3. Looking at the design of Look ‘n’ Stop Application filtering, I wouldn’t think it would be difficult to defining between client and server actions, the problem may be a way to implement It, I know it might be by far much earlier in the process to determine if application is acting as server. Another thing is Frederic is against bunch of popup alerts scaring its customers, but he could implement a switch and default state being OFF he could implement another checking mechanism for authorized applications for to be determined if application is connecting or actually listening with a capabilities to deny it doing one or the other, and besides being more informing it wouldn't be much point to offer capabilities to block both when one can merely resort to the main approach to block application by Look ‘n’ Stop Application filtering.

4. No In this particular case I’m mentioning, it basically has to-do with the irrational and annoying limitations of how many simultaneous TCP connections is allowed.

5. I don’t understand the reasons for u to say that…

6. No I’m saying for user comprehension of what is occurring or had been occurring rules with proper rule labelling needs to be used to give you “bit” of information/reasons. To rely on Look ‘n’ Stop SPI implementation is to be blind sided, no information/reasons for its triggering.

 

This may seem ridiculous to some or many depending on the group of viewers, but there is just so much limitations in real life, I get on the computer and browse and stuff to take “my” mind off of limitations in life, I don’t expect to see reminders on the machine also… I want to come on here and do what I like to-do and not be limited without being offered controls to disable and modify the limits.

This is why I take this so serious, regardless how I were really dedicated to something I will not even blink to ensure I not get reminded of life limitations while I’m on here in my happy, happy cyber world…

 

2. Well, so far my tests explicitly show that LnS does NOT detect listening servers. I set up a working ident server without need to authorize it with application filtering control (which was ON of course).

3. I was not writing about how to do it in GUI, but about issues with implementing the feature _internally_. This IS important.

4. What is the connection limit for LnS, after exceeding which SPI fails?

5. Just stating a fact.

6. Well, basic info is presented- I do not need more. And I do not think that putting Ethereal in LnS is reasonable. I do not think anything close can be implemented in LnS. Let's not make firewall a sniffer.

7. Enter in Google search "stateful packet inspection" and read 3 or so first links- maybe we agree then on what SPI is. Logging of SPI does not decide if SPI in application is full of not. And do not mix it with your wishes.
You write about lack "full" of SPI in LnS and pack into this notion all- real SPI, pseudo SPI (UDP pseudo-state tracking is not SPI, quite simple; also, FTP handling is not SPI, it is stateful *protocol* inspection), logging, some problems with number of connections, issue with dropped connections on turning on SPI, which I would label rather feature (you would like ALL your connections states traced after turning SPI on, wouldn't you?; not have some tracked and some not).
This is misleading.

X.

 

2. Then you obviously don’t know what you are doing….
- If you have mIRC (www.mIRC.co.uk) for instance, launch it and DO NOT connect to any servers, remove mIRC from application-filtering list if it exists and type /socklisten ListeningPortAt 80 you will see look ‘n’ stop application filtering DOES detect applications acting as server applications…

3. If you actually read anything I poster then you know I weren’t specifically in reference to GUI implementation.

4. For monitored TCP Connections limit it were 64 but is upped to 128.
“TCP Stateful Packet Inspection: the maximum number of monitored TCP connections has been set to 128 (instead of 64). “

5. I’m not sure what you are getting at, but my comfortless weren’t due to not understanding Look ‘n’ Stop, it were because I felt Look ‘n’ Stop packet-filtering isn’t being kept maintained and issues regarding the SPI Implementation, and I have not used ipchains yet.

6. I have much to say on this but I wont, let me just say, It isn’t difficult to implement “reasons” for SPI triggering, as it is obvious to anyone with any knowledge, It has no problem determining reason to discard the packets and it would be very little work to ADD reasons on the SPI alerts. And I feel it is crucial to be informed in detail what is happening and what has happened, lot less confusion this way.

7. Ohhh we have Mr. Rocket Scientist in our presence…. Listen, mentioning of the Look ‘n’ Stop SPI Implementation logging laciness has nothing to-do for my opinions concerning hmmm the way you put it “incompleteness?”… It is just something I want Frederic to consider for an opinion/suggestion of mine for future improvement on Look ‘n’ Stop product…
…
….
And who the freak talking about pseudo UDP SPI, or FTP handling corresponding with Look ‘n’ Stop SPI Implementation “incompleteness?”...

And if you want to know what is misleading, jumping to conclusions without knowing exactly what I meant, if you don’t think you understand fully what I have said, ask questions!!!!!

 

Phantom,

After stating that

means something along "You are wrong, LnS monitors also servers" I state that my English language skills are not enough for your English. Thus I can not properly interpret your posts and back off my assumptions about you views and opinions, which I expressed in previous posts.

Technical part:
You are right, application filtering works also for servers. I am not sure what I did wrong at the first time testing. I updated first post accordingly and also will check how LnS monitors Microsoft Networking services.

My position on number of ports supported by SPI option is that home user (and LnS is personal firewall, not intended for server systems) does not need to keep opened more than even 64 connections, even using P2P applications, for many reasons.

I consider current logging abilities of SPI option adequate. In case more information is needed, dedicated tools should be used.

X.

 

You>>>

Me>>

I couldn’t have had been clearer there, so if you couldn’t interpret that then it isn’t because of lack of English on my behalf…

You>>

From this it is obviously you understood, and that I had made myself clearer for you to interpret.

And my response to that…

Me>>

-

As I had mentioned before to you, Look ‘n’ Stop isn’t accurate in informing, it doesn’t define between applications accessing server environments and applications accessing client environments. And if applications (not known to Look ‘n’ Stop App-filter list) attempts to act as server Look ‘n’ Stop Application-filtering popup stating application making a connection to internet (misleading very). Once the application been added to the list, authorized or denied flag applies at a global level for both connecting and listening. And Look ‘n’ Stop does not obviously define when application begins acting as server, and no details for server acts like Listening socket information… No controls to have one and not the other, really sad because It would draw I can imagine many people to Look ‘n’ Stop.

….


Here are my opinions;

A) You on Dial-up so you don’t give a damn.
B) You are afraid of P2P software
C) Because you don’t support P2P you expect everyone else to not.
D) You think if SPI is improved that it would bloat our favourite little Software Firewall, and it would not run smoothly on your slow system.
E) You want to be different and have something to debate about and draw people’s attention by trying taking the Phant0m`` on….

- Your own opinions are irrelevant, try giving a damn about the majority and their habits, and like it or not majority of home user’s habits do revolve around P2P software. Hell why don’t you try being in their shoes and use P2P software with Look ‘n’ Stop SPI Implementation activated, let see how long it takes you before you begin getting annoyed.
- And don’t even attempt to hand me a bunch of crap about Look ‘n’ Stop SPI implementation like everything else’s SPI implementations, I’ve been using many strong & true stateful packet-filtering systems without having anything come close to problems and problems I have experience while using Look ‘n’ Stop with its SPI Implementation activated.

 

Debate is good....but....Nobody's going to take anybody on in this thread or any other

Let's both be mindful....as you peacefully continue your discussion....something Xyzzy said earlier !

"I state that my English language skills are not enough for your English. Thus I can not properly interpret your posts and back off my assumptions about you views and opinions, which I expressed in previous posts."

 

If your going to try prove Phant0m WRONG! You better get your facts in order first!,or don't even bother! I have yet to see somebody prove Phant0m wrong,and I have been following him for over a year,I have learned more about LNS from Phant0m,then from all the online help that LnS has to offer,so Xyzzy do you still think you are correct in this matter? You do know alot, I give you that,but sometimes people just know the correct answer,and in this case you don't,but you made some vaild points,just not all information was correct.We all are trying to learn,and if you would listen to what Phant0m said,you would understand why you are incorrect!