Question about the LOG file in Look 'n' Stop

Discussion in 'LnS English Forum' started by BillTheScienceGuy, Feb 25, 2010.

Thread Status:
Not open for further replies.
  1. BillTheScienceGuy

    BillTheScienceGuy Registered Member

    Joined:
    Feb 25, 2010
    Posts:
    2
    Location:
    near the middle east, actually. Think Cairo
    First some background: using on an XP machine, Pentium 4, Look 'n' Stop ver 2.06 from May 2007. Using the 'enhanced' rules (EnhancedRulesSet.rls) set I downloaded and everything seems to work fine. Antivirus package: Kaspersky Antivirus.

    BUT...here's my question:

    Under the LOG tab, I sometimes see potentially strange things going on. I need to understand what's going on.

    Best if I broke it down to a series of smaller questions.

    1. When you see lines and lines of entries under the LOG file, and in particular UDP: Any other UDP Packet Rule (column), are these UDP (User Datagram Protocol?) packets that are BLOCKED? Or stuff that's simply being logged (i.e., going on regardless, and L'n'S is simply recording it)? This is crucial. I assume it's stuff being blocked, in particular with the "Any other UDP Packet Rule"

    2. Let's assume the answer to #1 is YES. Because if not, my PC has some serious problems with perhaps some malware embedded inside it, though it has not ever shown a problem with the Kaspersky AntiVirus program I have running on it. Now, if these are UDP packets being blocked, you have a column that's either U or D (upload or Download), a date, a rule, a type, an address, and additional info. Fine. Now let's take an actual example of a UDP blocked on startup today:

    U-135--upload packet #135 in a sequence, fine.

    Date: 2-25-10 with timestamp, fine

    Rule: UDP: Any other UDP Packet --fine--can I assume that using the EnhancedRulesSet.rls that these UDPs being logged are blocked? Again that's fundamental to this question.

    Type: UDP

    Address: my PC ethernet card address and the destination, "94.245.115.118.189" Looked this up at Whois and it's Microsoft (Europe). Fine.

    If I "Look" (press the Look button) at a particular line, it gives more information, including source port (my PC) and destination port. Fine. It also shows PC>>Internet most of the time (in fact always for upload, which makes sense) which is saying the UDP is being uploaded.

    Now, if I right click the same line in the LOG file, it says "Add Rule: UDP: Allow port 3544" which is the port of the destination.

    Now here's my question: does this "Add Rule" mean that the UDP is question is being blocked, and if I add this rule, it will (for this destination port) be unblocked? If this seems like the same as Question #1--you're right. Just making sure.

    Now some general questions: everything on my system works fine, including all Microsoft products, but why would programs residing on my machine want to dial up Microsoft? Some Update modules maybe?

    Likewise, on occasion I get similar LOG file entries for UDPs that want to contact (from my PC) places in Russia, Poland, and today Kazakhstan. The domain names under Whois show some obscure server in these countries--nothing from a multinational company like Microsoft. Since I don't interact with these countries, or know of people in these countries (save Russia), does this mean my PC is possibly infected with malware or some virus? If so, why is this malware not showing up in Kaspersky's scan?

    Any insight appreciated.

    Bill
     
  2. Seer

    Seer Registered Member

    Joined:
    Feb 12, 2007
    Posts:
    1,596
    Location:
    Singidunum
    There is an option in the "internet filtering" tab (if you activated "advanced mode") to log blocked as well as allowed packets. If you didn't mess with the ruleset (read: enabled logging of allowed) then the answer to this (as you correctly assumed) is "yes".

    I am curious - check to see if you have TCP/IP protocol v6 installed (in connection properties). If so, when you disable/untick it, does the UDPs stop? Clear the logs, reboot and recheck the logs.
    Check that first (do not worry, unticking TCP/IPv6 will not cripple your connection in any way), and then we'll explain what that was. I am assuming IPv6 through IPv4 tunneling.
     
  3. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,354
    Location:
    France
    For blocked packets, the first column indicates a '-' (like U-220). When a packet is allowed you get a + (D+56 for instance).
    The "Any othe UDP Packet Rule" is a blocking rule, so the packets are blocked when this rule appears in the log.
    Yes, they are.
    Yes, exactly.
    Yes, windows update, also the Activation and Genuine verification tools could contact Microsoft Server.
    The time server (used by the clock) also may contact time.windows.com.
    Probably, there are some other conditions but I don't have them in mind.
    For Russia, it could be Kapersky updates, or another activity.

    If you are not using P2P software at all, yes it could be a malware.
    The question also is what is the connecting application detected by Look 'n' Stop for these alerts ?

    It could be some plugin/add-on modules added to an allowed application.
    You can enable the DLL Filtering in the advanced options dialog box. This feature could detect some of these plugin/add-on (if they are implemented as DLL).

    In the application filtering, you can enable the full log (!! attribute) for some applications, to know which applications are sending these packets.
    Don't do that systematically for all applications at once (especially, not on system ones, like svchost.exe, services.exe..., or browsers) because this will generate a lot alerts in the log, and sometimes some overload problems could appear in Look 'n' Stop. Just do it on suspicious applications, and 3 or 4 applications at a time.

    Regards,

    Frederic
     
  4. Creer

    Creer Registered Member

    Joined:
    Jun 29, 2008
    Posts:
    1,345
    Hi Seer,

    I had a lot of events in my LnS log like this:
    Code:
    03-19-10,10:46:01  U-1278 'UDP : Any other UDP pack' 94.245.115.186    UDP       Ports Dest:3544 Src:52479
    03-19-10,10:46:17  U-1279 'UDP : Any other UDP pack' 94.245.115.186    UDP       Ports Dest:3544 Src:52479
    03-19-10,10:46:44  D-1280 'All other packets       ' 192.168.15.1      IGMP      Type:17 (Version 1, Type 1)
    03-19-10,10:48:48  U-1281 'UDP : Any other UDP pack' 94.245.115.188    UDP       Ports Dest:3544 Src:51072
    03-19-10,10:48:49  U-1282 'UDP : Any other UDP pack' 94.245.115.188    UDP       Ports Dest:3544 Src:51072
    
    So I did what you suggested - I had enabled IPv6 in Properties of my Internet Card - when I've disabled this - logs in LnS has stoped growing :thumb:
    Since then my logs are clear, but is it really good/safe solution? I mean disable IPv6 rather than create additional rule in LnS with IPv6 enabled: "Add rule UDP: Allow Port 3544 - Client" ?


    Thanks,
    Creer
     
  5. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,354
    Location:
    France
    Yes, if you don't need IPV6, it's probably safer to disable it completely, so you have less packets received/sent, and you reduce the risks.

    Frederic
     
  6. Creer

    Creer Registered Member

    Joined:
    Jun 29, 2008
    Posts:
    1,345
    Ok, Thank you Frederic, IPv6 disabled I don't need it so far I think.
     
  7. Creer

    Creer Registered Member

    Joined:
    Jun 29, 2008
    Posts:
    1,345
    Just FYI,

    I have enabled IPV6 again (UDP 3544 entries in Log tab in LnS shows up as I mentioned in my previous posts), but this time I've blocked and disabled Teredo in my system from command prompt (there is also option to disable it via registry entry).

    More about Teredo security issues and how to disable it:
    http://searchsecurity.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid14_gci1288817,00.html

    After that I have enabled IPV6 protocol on my network card (my ISP is IPV6 ready) and my LnS logs are finally clear :thumb:

    HTH
     
Thread Status:
Not open for further replies.