I installed CFP 3.0.14.276 and was delighted to see it handle outgoing loopback connections “properly”: network rules now apply to them too. Great work, developers! (:CLP)
I have two questions about this:
1. Will the incoming connections processing be adjusted accordingly, too?
I have a squid.exe (Squid HTTP proxy) in Network Security Policy and one of it’s rules blocks all incoming traffic from 127.0.0.1. Still, it successfully receives incoming loopback connections.
Not that it’s critical, but it would be great to be able to control loopback connections exactly the same way you control all the other connections. We now have control over “outgoing” loopback connections (thanks for that!). Having the same control over “incoming” loopback connections (to completely block application’s attempts to listen to a certain port, for example) would be great, too.
2. Is the “Loopback Networking” option in application’s Access Rights useless now?
In Computer Security Policy I set the iexplore.exe’s (Internet Explorer) and squid.exe’s (Squid HTTP proxy) Access Rights / Loopback Networking to Block. Defense+ is in Paranoid Mode. Still, IE is able to browse through Squid, so both applications use loopback networking. The Loopback Networking setting in Access Rights seems to be ignored.
Personally I’m OK with that (I believe loopback connections should be governed like all others - by the Firewall’s network rules). Just wanted to know whether this behavior is intentional, or a bug.
I am not sure I understand the problem. Since the loopback connection is restricted to the local machine, the only connections that will occur would be outgoing, created by the program initiating the connection. Unless your machine is initiating connections with itself?
Loopback networking is exactly that - a machine’s connection with itself.
There are still two parties: one application initiates the “outgoing” loopback connection, the other application receives the “incoming” loopback connection. For example, when Internet Explorer tries to browse through a local proxy server it creates an outgoing TCP connection to IP 127.0.0.1, port 8080. On the other side, the proxy server receives the incoming TCP connection from IP 127.0.0.1, to port 8080.
With 14.276 we can control outgoing connections to 127.0.0.1. But we cannot control incoming loopback connections. I have a rule for squid.exe (proxy server) that blocks all incoming connections. Any connection attempts coming from outside are blocked, as expected. Connections coming from localhost are allowed, despite the rule.
So there is no way to completely forbid a certain application to listen to a certain port and receive connections on it: loopback connections are allowed, no matter what network rules say.
I was wondering about a couple of things. First, do your firewall rules for applications connecting to your proxy (and the proxy too, I guess) have the Allow IP Out any any any any rule in their policy? I was wondering if that kind of rule would mess up the Defense+ control of loopback networking. It should allow outbound connections to 127.0.0.1 in conflict with the Defense+ setting. Another possibility is perhaps Squid uses a different function from the usual to access loopbacks. There was a previous problem that involved a function included in the .net framework that used a different call to invoke a common function.
I also noted an option to enable loopback connection alerts (Firewall>Advanced>Firewall Behavior Settings>Alert Settings tab: see checkbox). Maybe that will give a greater degree of control?
I have loopback connection alerts enabled in Firewall Behavior Settings. Both iexplore.exe and squid.exe have Loopback Networking set to Block in Computer Security Policy - Access Rights. Apllication rules for iexplore.exe allow it to establish outgoing connection to IP 127.0.0.1, port 8080. Application rules for squid.exe allow outgoing connections and block incoming connections. I’ve also made an additional rule to explicitly block incoming connection to port 8080, just in case.
Despite the Loopback Networking setting in applications’ Access Rights and the network rules for squid.exe, Internet Explorer can browse through localhost Squid proxy.
Speaking of functions used to access loopback networking, I’ll try to install something else (like apache or some ftp server) and see if this is Squid’s or Comodo’s issue.
OK, I now have MySQL Server and MySQL GUI Tools installed and I observe exactly the same behavior:
MySQLQueryBrowser.exe (client) has an application rule that allows outgoing TCP connections to 127.0.0.1;
mysql-nt.exe (server) has an application rule that blocks any incoming connections;
both mysql-nt.exe and MySQLQueryBrowser.exe have their Loopback Networking access rights set to Block.
And that doesn’t stop the Query Browser from successfully connecting to the localhost MySQL Server. So I think it’s safe to conclude now that in CFP 3.0.14.276:
Loopback Networking setting in aplication’s Access Rights is ignored completely.