Please confirm/check my eMule rules in Outpost 4.0

Discussion in 'other firewalls' started by feniks, Sep 30, 2007.

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

    feniks Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    130
    This is question for newest version of Outpost 4.0 and Windows XP Pro SP2.

    I did some research about it and the rules here are my conclusions.

    However I have small request to experts. Can you check my eMule rules if they are correct? They are working without any problem and I have high ID but I am wondering if they are correct according to firewall philosophy, rules for making rules etc.

    Also I am wondering about UDP. Because there is option for direction in Outpost I did use to be more restrictive, it but is the way that is working? I hear that UDP is directionless.

    Of course also if they are safe, but I think you can not do much more with eMule with safety.

    Please forgive me my English if that is unclear. I will be very grateful for advice.


    ***********
    eMule Rules
    ***********

    [eMule] eMule.exe

    RuleName: allow eMule TCP in
    Protocol: TCP
    Direction: Inbound
    LocalPort: 4662 (standard eMule port but can be changed)
    AllowIt

    RuleName: allow eMule UDP in
    Protocol: UDP
    Direction: Inbound
    LocalPort: 4672 (standard eMule port but can be changed)
    AllowIt

    RuleName: allow TCP out
    Protocol: TCP
    Direction: Outbound
    LocalPort: 1025-65535
    RemotePort: 1025-65535
    AllowIt

    RuleName: allow UDP out
    Protocol: UDP
    Direction: Outbound
    LocalPort: 1025-65535
    RemotePort: 1025-65535
    AllowIt

    RuleName: block eMule TCP in
    Protocol: TCP
    Direction: Inbound
    BlockIt

    RuleName: block eMule TCP out
    Protocol: TCP
    Direction: Outbound
    BlockIt

    RuleName: block eMule UDP
    Protocol: UDP
    BlockIt

    *********************************

    Extra rules but I do not use them
    (if use will be placed before blocking rules)

    RuleName: eMule Client Connections to eMule Webinterface
    Protocol: TCP
    Direction: Inbound
    LocalPort: 4711 (change this if you use another port)
    AllowIt (change to BlockIt if you don't use the Webinterface)

    RuleName: eMule Client Connections to MobileMule
    Protocol: TCP
    Direction: Inbound
    LocalPort: 80 (This is the default port for MobileMule connection, you should change it if you plan to use MobileMule)
    AllowIt (change to BlockIt if you don't use MobileMule)
    Reply With Quote
     
  2. feniks

    feniks Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    130
    Like I said before these rules were based on what I read here on Outpost forum about eMule rules.

    However I also was afraid that there are to many ports open, especially local. I understand that remote port can be changed by many people to different then default but I am setting local ports for eMule and there are actually two - one TCP and one for UDP.

    I also observe something I do not understand. When I allow UDP with only one local port specified and nothing specified for remote ports, even with the last rule for block UDP - eMule is using all remote ports but only one local, the one I specified in rule. I wanted to restrict eMule to not use well known ports so I had to specify the remote ports in allow rule to achieve that. Then it is working like I want, the ports 1-1024 are not used. So seems that if you do not specify remote ports with one local allowed all remote ports are usable even with the last rule block all UDP?

    Or the blocking rule (or allow) is not correct without specifing ports? I understand that if I do not specify ports in rule (remote or local) then the rule should apply to all ports, am I correct?

    But this idea was not working with allow UDP for local only specified (all remote where used). So I am little confused how it is working.

    I made my observations by observing log viewer.

    I did change the rules and I have high ID and no problem with eMule working, only two local ports are working one for TCP one for UDP and remote port that eMule is using are without well known ports (1-1024).

    But I have question, sorry for that. Maybe the rules are to restrictive? I mean they block the way eMule is working so I do not have the speed of download I could have without any restrictions? So far I do not observe that it is slowing eMule in any way.

    My new rules:

    [eMule]
    eMule.exe
    RuleName: allow eMule TCP in (Connections Client to Client, Source Exchange)
    Protocol: TCP
    Direction: Inbound
    LocalPort: 4662 (standard eMule port but can be changed)
    AllowIt

    RuleName: allow eMule UDP
    (Source asking on servers, Extended eMule Protocol, Queue Rating, File Reask Ping - remote)
    (eMule Queue Rating, File Reask Ping, Source- & Filesearch from Servers - local)
    Protocol: UDP
    RemotePort: 1025-65535
    LocalPort: 4672 (standard eMule port but can be changed)
    AllowIt

    RuleName: allow TCP out (eMule Connections to Server & Clients)
    Protocol: TCP
    Direction: Outbound
    RemotePort: 1025-65535
    AllowIt

    RuleName: block eMule TCP in
    Protocol: TCP
    Direction: Inbound
    BlockIt

    RuleName: block eMule TCP out
    Protocol: TCP
    Direction: Outbound
    BlockIt

    RuleName: block eMule UDP
    Protocol: UDP
    BlockIt
     
  3. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Hello feniks, Welcome to Wilders,
    With any firewall, where inbound is allowed to local port, then the remote ports, if not specified, will allow any. An end blocking rule will only block what is not already allowed. If you want to restrict ports used by remote for the inbound, then you do need to enter these ports (a non-entry of ports, will be seen as "ANY")

    You should not see much slowdown due to these rules. The only possible problem would be the fact that quite a few users do use the low ports for inbound (below 1024), they do this to get around possible throttling by their ISP, so you will not be making connections to these users.
     
  4. feniks

    feniks Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    130
    Thank you very much for your answer that is what I wanted to know. I see I was somehow little blind. This is big step for me to understand firewalls.

    So looking for my rules I can see that all remote ports for TCP inbound are allowed (because I do not specify them in TCP in so it means any so the TCP blocking rule is not blocking them)

    Also I see that same way all my local port are not restricted in TCP out.

    I hope I do understand it correct?

    My idea actually was to restrict my local ports to the two used by eMule for incoming TCP and UDP and restrict my local ports 1-1024 for TCP out for more safety and block remote port actually only DNS 53 (out only I think but I will block in also) because of the alerts Outpost is showing.

    So maybe my rules should look like thgis to achieve that? Am I correct?

    [eMule]
    eMule.exe
    RuleName: allow eMule TCP in
    Protocol: TCP
    Direction: Inbound
    LocalPort: 4662 (standard eMule port but can be changed)
    AllowIt

    RuleName: allow eMule UDP
    Protocol: UDP
    LocalPort: 4672 (standard eMule port but can be changed)
    AllowIt

    RuleName: allow TCP out
    Protocol: TCP
    Direction: Outbound
    LocalPort: 1025-65535
    AllowIt

    RuleName: block eMule TCP in
    Protocol: TCP
    RemotePort: 53
    Direction: Inbound
    BlockIt

    RuleName: block eMule TCP out
    Protocol: TCP
    RemotePort: 53
    Direction: Outbound
    BlockIt

    RuleName: block eMule UDP
    Protocol: UDP
    RemotePort: 53
    BlockIt
     
  5. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Hi feniks,

    The port blocking rules (for port 53) will need to be placed at the top of the ruleset.

    You will also have to add a rule to allow UDP to remote ports used by other users (so this could be any remote port)
     
  6. feniks

    feniks Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    130
    Thank you for your patience Stem and for your answers.

    Thank you for remaind me that top rule goes first, I just forget things because I am to fresh yet.

    But with the UDP, according to what you teach me before - not specify ports means ANY and I understand UDP is directionless.

    By observing the log it is working that way. eMule is using only the local port I specify in the UDP allow rule and is using all the remote ports in communication.

    The UDP block it rule did not block any remote ports just block every local ports except the one I specify. Now when I put the UDP block rule for port 53 above other UDP rules is blocking only port 53 not any other remote ports even there is rule on bottom for block all UDP.

    So is like you said before not specify mean ANY so the block all UDP (without specify any ports local or remote) also block only all local ports except the one specified port (becuse I specify one in the rule above) and did not block any remote ports (becuse I did not specify any ports in the rule above which means allow any remote ports and it was superior). I hope it is clear. :)

    So I am little confused in understanding what did you mean?
     
  7. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Hi feniks,
    UDP is "Connectionless" not "Directionless".
    I did forget that OutPost does not filter UDP by direction. Normally, for a P2P, in the firewalls I use, I would set rules to allow in UDP (to specific port), then allow out UDP (to any).

    Sorry if I confused you.

    Regards,
     
  8. feniks

    feniks Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    130
    Stem you are right and I will use your approach to make rules for UDP. This way is more universal.

    That is Outpost who was confusing me and that is way I said directionless. Now you explain this. Thank you.

    If you still have patience for me, there is something in Outpost confusing me and I for week already did not have any answer on their forum.

    When you create rule in Outpost you can chose in actions "do not log this activity". It is working for all my eMule rules but not for the TCP in allow to port specified. Is still showing activity in log viewer based on this rule. When I uncheck that option is showing much more with this option less.

    But it should show nothing right?
     
  9. feniks

    feniks Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    130
    I figure it out.

    When I change the order of rules first outgoing then incoming it is working like supposed to - not showing anything in viewer.

    So it has to be something with the order of rules and it is strange but it is how Outpost is working.

    So it does not have anything to do with logic or knowledge about firewalls. Looks like every firewall has in addition its own way. Some bugs, workarounds, tricks etc.

    This make things even more confusing.
     
  10. Stem

    Stem Firewall Expert

    Joined:
    Oct 5, 2005
    Posts:
    4,948
    Location:
    UK
    Good to hear, well done.

    It is one of the problems with any security software. Problems can arrise due to some conflict with other drivers (or combination of drivers) on your system. Problems can arrise due to orphaned files/drivers being left from other firewalls etc. In your example, it would look (to me) more a case your option to "not log" was not correctly added to the rule when saved.

    It can at times. But you did find your own solution to your logging problem.
     
  11. feniks

    feniks Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    130
    Thank you Stem for your assistance.

    Like they say - no pain no gain.
     
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.