I’m currently running version 3.0.17.304 of Comodo. When I was using the previous version I didn’t touch any global rules, but just created an anything “Out” rule and a port specific TCP/UDP “In” rule for uTorrent itself and everything was fine. uTorrent displayed it’s green tick, and when I checked port forwarding via the browser it told me port forwarding was active while uTorrent was running and inactive when it wasn’t. Once I upgraded to version 3.0.17.304 Comodo started to bug me about uTorrent wanting to connect to the internet, but it still was connected, and port forwarding was working fine. Turns out Comodo now thinks or doesn’t like uTorrent wanting to connect to the loop back zone, so I had to create a rule to allow it to which I hadn’t needed before. At least though I still haven’t had to touch the global rules and port forwarding is still only active while uTorrent is running.
It made me wonder though… if a firewall creates a rule for when only a specific program is running, does that rule apply to the specific program only? For instance if I have a certain port set up to forward as a rule for uTorrent, does that port get forwarded to everything else when uTorrent is running, or is it only being forwarded to uTorrent? I guess I’m asking as I don’t know if the port forwarding test result is simply being reported by the browser or if the browser itself is somehow conducting the test. Anyone know how that works?
Just upgraded to whatever the latest version of Comodo is. Hopefully I won’t have to add any more rules after I reboot this time…
Whats with all these rules? seems very complicated to me.
Ive got a Netgear router with UnPP enabled, and UnPP enabled in Utorrent. With utorrent listed as trusted, everything is automatic. The prog opens the port in my router, and closes it when its not running.
I never went to all that bother to get Utorrent to work perfectly, all I did was install it and define it as TRUSTED APP. in Firewall and Defense+, it opens a random port using UPnP in my Netgear Router DG834gv3 and when Utorrent is closed, everything it opened is also closed.
[quote author=SiberLynx link=topic=15677.msg135871#msg135871 date=1203238543]
Hi I have done the two rules as suggested in te IP address but still get very slow downloads nothing greater than 20KB/S how can I speed them up, when I used bit torrent before they used to be at least 3 times as fast
Hi thephoenix572,
That’s interesting quote from SiberLynx. … but I don’t remember writing that ???
Moreover, I’m reading my request again now and cannot see what was quoted by you
My Q was “a bit” different
How that could happen? :THNK
Thanks
Yeah! it looks like that ^_^. Glad 2 hear from you Little Mac.
I hope when you or other Gurus have spare minute. or 1.69 min. I’ll get some response to my beautiful story with pictures (above).
I will add that the rule Allow IP OUT… was returned and the madness stopped and all works as it should be. ??? Cheers
at rainbowjunior and delgado ~ this may work well enough, but it’s not a step we recommend. Reason being from a security standpoint, “we” prefer to control which port is opened so that all communication (since these are unsolicited inbound connections) only happens when/if/how we say so. By using UPnP in both router and p2p app, you are creating a security risk that is rather easy to exploit. Since you’re “trusting” the p2p app w/in v3, if an illegitimate connection is attempted, it will be accepted, and then you’re toast (so to speak).
at SiberLynx ~ I looked back thru the posts a little bit, and did not see your beautiful story with pictures. If you’ll get me a link to it, I’ll take a look at it. Based on your statement about the IP Out rule helping, I’d guess that for your setup, it probably wants to do some ICMP (some do, some don’t), and the IP Out rule is allowing that to pass.
Sorry, SiberLynx, I completely missed your post! The Shame, the Shame!
I have to say that those two rules for IP In and IP Out simply MUST GO!!! That’s a big security risk. All you should need for p2p is an Out rule for TCP/UDP, and In rule(s) for TCP and UDP on the associated port for each protocol (I’d suggest using separate ports, if you can - if you even need both protocols).
The small pic is just a notice that uT is creating a connection w/localhost/loopback 127.0.0.1. Probably nothing to be concerned about (check w/the uT folks to see if that’s normal behavior for the application). If it’s not normal behavior, then it’s a concern; otherwise I wouldn’t worry.
Regarding why it worked with the IP In and Out rules, and not without, is probably (as I mentioned before) related to an ICMP requirement. To track it down, clear the logs, run uT, see what ICMP ends up in there, and tailor your rules to allow only what is needed.
Thanks a lot for detailed reply LM,
I’ll try to answer step by step.
Well, this raises only questions and a bit of disappointment.
The similar Allow rules, which Comodo creates by default for any App. should always be security risk in this case, shouldn’t they? Because during creation “nobody” knows that the app. Is P2P. If Yes, Why are they default?
Why some have In / OUT IP default but I had only OUT?
this is not a Q but rather suggestion to add an explicit note in Tutorial for uTorrent and alike about the necessity to remove those (some people trying to block the, some leave them alone …etc.)
It seems like in uTorrent it is not possible as ther is only one port to be set for communication (?).
Sure I can and will contact uT Guys. The Q is why I never saw this message before (with current version of uT – important!)? It means that something changed in Comodo so that this event now became “visible” to Comodo and it’s flagging a concern. Comodos own “worries” - that’s one thing. The other thing is my personal concern, which I expressed in initial message. I will allow to repeat it, sorry:
The Orange Message appears only when top IP rules (which are the risk as you said as a matter of fact) are removed.
IT does not matter whether I allow or ignore this message. I will be connected IN irrespectively to where uT Global rule is “above or below the Main Block IN (!!!???)
that I have to dig deeper it is less understandable for me including that I did not change anything it ICMP area compare to previous versions and now I don’t have any blocking reported,… but I had those before. But again, this is just lack of my knowledge in this field and I have to fix that.
Section 1
Item 1. Did you choose, during installation, that you need to open up inbound connections for using p2p? If not, how did you get these “default” rules to Allow IP In and Allow IP Out in Global Rules?
Item 2. Don’t know. Must be user-related.
Item 3. We need to know precisely how/when/where the rules were created.
Section 2
Okay. Some p2p apps allow different port settings for TCP and UDP, some don’t.
Section 3
In current release of v3, I believe it is set to automatically monitor localhost/loopback connections; in previous versions you had to turn it on. It’s part of their new format.
To have IP In and IP Out Allow rules obviates all other v3 security on the Global Rules side, thus loopbakc/localhost connects (and all other connections) are allowed. it’s like turning off the network firewall entirely.
If you do not respond to the alert, the connection will be blocked. Then (provided it’s normal behavior for uT to use localhost/loopback) uT will also be blocked. If you choose to Deny the connection to localhost, uT will be blocked. If you Allow it, the connection will be allowed, and uT will probably connect to the 'net normally. 127.0.0.1 is an internal (your computer only) IP; connecting thru it does NOT mean the application is connecting to the net. Many apps communicate internally this way; it’s not a cause for concern UNLESS the app is not suppsoed to do so. Localhost is commonly used by local proxies (such as proxomitron) for surfing the 'net.
Section 4
CFP by default will Block any network traffic (ie, Global rules) that is not explicitly or implicitly allowed. Thus, if your only rules address TCP and UDP, ICMP will be blocked whether it’s coming In or going Out. ICMP, being a subset of IP, will be Allowed if you have rules to Allow IP In and IP Out. Wikipedia can be your friend to help gain understanding…
I just installed CF and I did get a green ok for my Utorrent… but i’m not able to DL, so I looked in my firewall events and I see that they ALL are been blocked and I don’t know what to do next. I must say that I did everything on the tutorial–only that I’m using a single port ex.666666 were it said utorrent port and the rest I set it like port 1025–65535.
Hi ecoSix,
If you did all as per instruction including moving Global uTorrent rule below Main “red” Block IN rule and get green all should be fine. The only thing which I couldn’t get is what highlighted in the quote.
What do you mean by that?There should not be any other port settings for uTorrent except 1(one) port for communication - “single port ex.666666” as you called it which is forwarded (TCP & UDP).
Another thing is - you may probably post those (few) blocking events here and the settings for “1025–65535” ??? so some Gurus can see more.
My regards
Thanks again for detailed response.
I will try to comment only 2 points. (in order 2 b less annoying then usual )
It is deep in my memory stack but the answer 99.(999)% - Yes. The only thing left to think about is that as you said - it would be security risk and it is advisable to remove later anyway… Well,… let’s leave it alone, because the following looks like more important to understand.
The answer to this part unfortunately is NO. What you wrote is how it should be and it is correct. But when IP OUT (1rule in my case) removed - as depicted above in #136 I do Not respond to that window and I have 300KB/ “IN” immediately with “red uTorrent” to the moment the Orange window will go away itself (default 120sec) the speed IN will be ~800KB/sec …
So uTorrent works correctly according to all “green rules” only if IP OUT added and allowed. It means:
No Orange window;
No connection when red;
if I move Global rule above Main IN block during download I get yellow flag from uTorrent and download stops, which is correct (as a reminder from prev.post - it doesn’t matter where global rule is when IP OUT removed - I’m in and out like no FW present)
Before posting this I performed another experiment. With IP OUT present as it is now but set to Block - uTorrtent will neither download nor upload.
Don’t spend time on this. I may slowly learn and share if I find something more interesting.
My kind regards
Thank you for the quick reply, but I’m having problem with my main PC and once I’m able to work on it or fix it, I will be able to answer your questions.
Sorry that it took so long, but I had to solve other issues before I came here.
Ok, let me start by saying that I get a green ok, in my firefox browser when I click for a connection test on utorrent.
I notice that my connection are been blocked and I don’t why.
3.portrage= 1025–65535. With this I wanted to say that I put the same information from start 1025 to end-65535 and not my pvt port for Utorrent. is this correct?
4.I tried to upload a picture but I don’t know how.
Ok, I did some more reading and I found out a new setting that probably it would work for me.
I got a router an a modem and I tried the (reply#23 til 29) and I got a connection(green D/L in utorrent) but I was connected to port 80
and I don’t want that, I would like to use my pvt port. Is there another way around this? Here is a pic of it.
Rule 3
Action = Allow
Protocol = UDP
Direction = Out
Description = Rule for outgoing UDP connections
Source Address = Any
Destination Address = Any
Source port = (start port = 1025 / end port = 65535)
Destination port = 53
and cannot see what was quoted by you
If you’ll get me a link to it, I’ll take a look at it. Based on your statement about the IP Out rule helping, I’d guess that for your setup, it probably wants to do some ICMP (some do, some don’t), and the IP Out rule is allowing that to pass.