reopening the same panel (Stealth Ports Wizard) the setting goes back to standard option (Define a new trusted network) discarding previous selection
ports are not stealthed (I can check this for example on port 53 on my system) - you have to be careful as you are visible and some ports can be opened
The display is a bit misleading. It always reverts to the first option-it is not intended to show status, just options. You can check under your global rules that the block has happened.
Most common reason for non-stealthed ports if you run something like GRC Shields Up is if you are using a router. A router is often set up to respond to certain incoming, ahead of CFP Otherwise, CFP should not respond to unsolicited traffic from the internet with the stealth setting.
To check your global rules, go to firewall/advanced/network policy/global rules tab. The last rule should be a block and log all incoming requests. Port 53 should only be reachable if you have sent out a DNS query, unless your router is keeping it open to simplify itself by avoiding NAT. How do you verify it is open? To check your CFP protection: If you can, bypass the router and plug your ethernet cable directly into your modem from your computer. What kind of internet link do your have. eg cable or DSL, if DSL PPPOE or DHCP or static IP? Are you running Shields Up at www.grc.com?
Yes, I am using that GRC test. It can be that my router is answering to the GRC test packet, I just wonder how and why!
About those Global Rules I dont understand how they work:
example:
DNS UPD out to any:53 allowed works ok
DNS UDP in from any blocked DOESNT WORK (at least if that is a DNS name server reply)
TCP OUT to any:80 allowed works ok, tcp request
TCP IN from any blocked DOES WORK and blocks my http request
Why the answer to the first UDP query is allowed superseding my user setup
and the answer to my TCP connection is blocked?
Should it not be the other way round as UDP is connectionless and TCP connection was started by my client?
The UDP request can only get the data requested by the destination sending back another UDP datagram. So CFP is smart enough to know that if you send out a DNS request, that you expect a DNS response back from the same destination. SPI is used to recognize this and keep the “block all in” global rule from inhibiting DNS, DHCP, a few other items that work like this.
TCP works differently and an outbound connection allows data to flow both ways. The connection does not use port 80 on your side, but a port assigned by a one-up-counter for each connection. HTTP will actually set up several TCP outs on port 80 if you look at the firewall/firewall tasks/view active connections display. This is because there is a separate TCP connection set up for each of the features on the page. There are no TCP in connections associated with http, so don’t know what you are blocking from your description. Maybe you can post a copy of your log?
I meant, I simply set a Network Control Rule in Global Rules
Allow TCP OUT
from any source address
to any destination address
source port: any
destination port: http ports (80,8080,443)
+
(Block all the rest)
This way my http browser connection doesnt work
If I modify the above with
Allow TCP IN/OUT
then the http goes
why is TCP IN necessary?
We agree there is no TCP inbound connection necessary.
I thought it could be that the network rules are applicable to each single TCP packets, no matter if they are associated to a TCP outbound or TCP inbound connection but you seem to exclude this view.
Please help to understand.
It could be a good firewall but that there are too many feature not documented or out of user control - which experienced users dont like … intelligent enough can mean also intelligent enough to be a big trojan horse
I don’t use global rules, but are you using the default “web browser” rules for your application? Would still like to see your whole set of global rules to see what is happening-maybe loopback? Does anything show up in your firewall log when http is blocked? One thing to do is make separate TCP in and TCP out rules, since the in/out sometimes confuses sources and destinations in CFP. Network rules are about connections, not tcp packets, and once you set up any tcp connection it is bidirectional in terms of data. You don’t need any global rules for http, just use the “web browser” default rules for your application.
Yep, you are right (I see that your title of Comodo’s hero is well deserved!!)
If browser (Firefox) loopback is enabled, then it will not connect if there is no TCP IN allowed as network global rule.
If loopback is disabled, it works correctly with TCP OUT allowed only.
At the moment I cannot figure out why, can you? whast the hell is browser doing with loopback?
Firefox communicates setup information with itself at initialization using TCP. The way that happens internal to a computer is to use 127.0.0.1 (localhost) to send between two ports accessible to Firefox. Why Firefox communicates that way instead of other, ??? I use Opera.
By the way my problem has occured again:
I have changed location and updated my UDP rules to allow DNS resolution through a different router (192.168.1.1)
Result:
Firefox blocked again, logs say UDP DNS request by svchost.exe are blocked (despite all my rules allow it!)
only way out of it … allowing TCP IN in my network rules for a second, after that it works.
What is the relation between svchost.exe, UDP blocked and TCP in allowed?
I start to think Comodo is buggish …
I will report another problem in a different message.
Is your router set up to be acting as a DNS server? If it is, I am suspecting that there is router traffic in that is not being allowed. If not, you need to directly access an Internet DNS server like 4.2.2.1 or 4.2.2.2. My Web Browser rules are attached if that helps. The rules for svchost are usually buried under “Windows Updater Applications” and need to allow outgoing TCP and UDP. As mentioned in another post, upgrading to the firewall/D+ portion of CIS and not the AV/toolbar should fix some of the problems.
