Look'n'Stop activity on Port 5355

Discussion in 'LnS English Forum' started by G_reg, May 11, 2008.

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

    G_reg Registered Member

    Joined:
    May 11, 2008
    Posts:
    5
    Hello,

    I'm a new user of Look'n stop. I'm currently setting up all my application rules and trying to fine tune them by using the logs.

    I am using the Phant0m ruleset but I think this question is specific to look n stop. Please forgive me if I am posting on the wrong forum.
    I noticed in my log that Look n Stop Personal Firewall has entries which look like the examples below...

    U-16 05-11-08.20:19:45 APP:UDP port not allowed EXE Look'n'Stop Personal Firewall Port 5355, IP: ff02::1:3
    U-16 05-11-08.20:19:45 APP:UDP port not allowed EXE Look'n'Stop Personal Firewall Port 5355, IP: 224.0.0.252

    I've done a search within LnS English forum for 5355 and found a very informative post by Climenole

    -----------------------------------------------------------------

    LLMNR queries are sent to and received on port 5355. The IPv4 link-
    scope multicast address a given responder listens to, and to which a
    sender sends queries, is 224.0.0.252. The IPv6 link-scope multicast
    address a given responder listens to, and to which a sender sends all
    queries, is FF02:0:0:0:0:0:1:3.

    Responders MUST listen on UDP port 5355 on the link-scope
    multicast address(es) defined in Section 2, and on TCP port 5355
    on the unicast address(es) that could be set as the source
    address(es) when the responder responds to the LLMNR query.

    http://tools.ietf.org/html/rfc4795

    -----------------------------------------------------------------

    But unfortunately I am no nearer to understanding if this is an action that Look'n'Stop should be performing.

    Currently for Look'n'Stop application I have added TCP conditions - Ports 80;443. UDP conditions - Ports 53 @IP 87.194.0.51 which is my dns server.

    Should this entry in my log overly concern me?
    Should I add an allow port 5355 @ IP 224.0.0.252 to the UDP conditions for Look 'n' Stop in application filtering?

    THanks for any help

    Kind Regards

    Greg
     
  2. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,353
    Location:
    France
    Hi Greg,

    This is very strange, Look 'n' Stop is not supposed to use this protocol.

    Maybe it is related to IP name resolution. Usually only DNS (port 53) is required, but perhaps Windows tries this protocol when there is no result from DNS.

    Could you try to disable IP name resolution in Look 'n' Stop options tab (and press the Apply button). After doing that, just verify if you still have these alerts or not.

    Thanks,

    Frederic
     
  3. G_reg

    G_reg Registered Member

    Joined:
    May 11, 2008
    Posts:
    5
    Hey Frederic,

    I checked that I could replicate the the log entries for the look 'n'stop application - reboot and open a web browser or get look'n'stop to check for updates managed to generate the log entries again. I did this twice and each time I had those messages in my log.

    I removed the check from "Solve IP address Names" in the options tab and since doing so I have not received those entries in my log again.

    So what does this mean?

    For extra info.....
    I am behind a router using vista x64 and I am using the Host Manager from www.bluetack.co.uk so have the DNS service disabled. The Phant0m ruleset is unmodified and I haven't fully set up look'n'stop yet for filesharing or for being behind a router - (I noticed a few posts about that which upon a quick skim read indicate that additional rules are required) so am working my way round to checking all these things. Just trying to fine tune the application rules first :D and get used to this very impressive firewall. I've been an Outpost user the last 5 years and am now a bit out of my comfort zone (a good thing though)

    Kind Regards

    Greg
     
  4. G_reg

    G_reg Registered Member

    Joined:
    May 11, 2008
    Posts:
    5
    Ahhhhh appears I spoke too soon.

    As soon as I hit "post reply" the same messages appeared in my log again.
    I still have "Solve Port Names" checked in the options tab, would you like me to uncheck that and try again.

    I will perform a few more reboots and use a few apps that access the internet to doubly confirm that removing the check from "Solve IP address Names" hasn't stopped these log entries.
     
  5. G_reg

    G_reg Registered Member

    Joined:
    May 11, 2008
    Posts:
    5
    Oooops, forget my last post, I was being a plum. I'd unchecked "Solve IP address Names" but forgot to hit Apply. I had the window so that the bottom portion was off the desktop and couldnt see the aply button. Oh the shame!

    Yes it appears to have stopped the log entries, I've browsed, downloaded through itunes, checked email, and checked look'n'stop for updates. So does this mean that Look'n'stop is now no longer peforming actions that generate those log entries or that it isn't logging those events?

    Kind Regards

    Greg
     
  6. Frederic

    Frederic LnS Developer

    Joined:
    Jan 9, 2003
    Posts:
    4,353
    Location:
    France
    Ok, so it is really a consequence of IP name solving.
    Look 'n' Stop doesn't use the port directly, but use some windows API which are using this 5355 protocol to get IP names.

    Some information here about that protocol:
    http://technet.microsoft.com/fr-fr/library/bb878128(en-us).aspx
    =>
    LLMNR allows name resolution on networks where a DNS server is not present or practical.

    If you cant to have IP name resolution still working, and no alert, you can add 5355 to the list of allowed ports.
    Then probably you will get alerts from the Internet Filtering since there is no rule in the packet filter to allow this protocol.
    In that case, just create a new rule with a right click on an alert in the log. Then you can either allow the packets (nothing else to do), or you can block them silently (by checking the Stop sign for this new rule).
    My advice would be to block them, if everything is working well already today, without allowing these packets.

    Regards,

    Frederic
     
  7. G_reg

    G_reg Registered Member

    Joined:
    May 11, 2008
    Posts:
    5
    Hi Frederic,

    This is excellent. Thanks very much for the link and info. I can now make an informed decision on what's best. Awesome!

    And thanks in advance for any future questions I will have (though I am trying to minimise the amount by reading previous posts)

    Kind Regards

    Greg
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.