Welcome
Welcome to vistafirewallcontrol

You are currently viewing our boards as a guest, which gives you limited access to view most discussions and access our other features. By joining our free community, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content, and access many other special features. In addition, registered members also see less advertisements. Registration is fast, simple, and absolutely free, so please, join our community today!

Unblocking LocalHost in AllApps Zone

Unblocking LocalHost in AllApps Zone

Postby metal450 » Tue Dec 20, 2016 6:49 pm

As I've been gradually setting up & refining my zones/rules, I've been finding myself needing to unblock an ever-growing list of apps from "Localhost." It appears to be fairly common for software to use 127.0.0.1 to communicate with itself, for IPC (i.e. iTunes won't sync unless you unblock localhost from a whole host of binaries, some Adobe applications crash, etc).

This got me to thinking: is there any reason not to just enable LocalHost via the AllApps zone? This would mitigate the need to list each binary individually, so I was curious if there's any reason you *wouldn’t* want to do it. Aka if there's any reason I'd still want my system firewalled “from itself”?

The only example I could think of might be with antivirus that "redirects" all network traffic through localhost. But aside from that, any reason not to just stick LocalHost in AllApps & call it a day?
metal450
 
Posts: 50
Joined: Tue Dec 20, 2016 6:19 pm

Re: Unblocking LocalHost in AllApps Zone

Postby VistaFirewallControl » Wed Dec 21, 2016 10:52 am

>As I've been gradually setting up & refining my zones/rules, I've been finding myself needing to unblock an ever-growing list of apps from "Localhost." It appears to be fairly common for software to use 127.0.0.1 to communicate with itself, for IPC (i.e. iTunes won't sync unless you unblock localhost from a whole host of binaries, some Adobe applications crash, etc).

Actually many applications use localhost for IPC and do not expect localhost may be blocked.
You might notice that localhost enabling rule is included in almost any predefined zone.
If you started creating the zones from scratch, you should take care about localhost yourself.


>The only example I could think of might be with antivirus that "redirects" all network traffic through localhost.

Precisely, it’s the main reason.
Having locahost enabled blindly for all application with some antiviruses installed, you practically set EnableAll to your system.

>But aside from that, any reason not to just stick LocalHost in AllApps & call it a day?


Another reason is rather theoretical.
The default firewall policy is “disable-by-default”.
So no communication can be available without your permission.
Obviously you can implement any policy you want.
The above is just the setup default state.
Needless to say that localhost enabled in AllApps contradicts the default policy.
Undoubtedly there is a set of other localhost dependent applications you may want to disable.
There is a lot of various proxies and tunnels utilizes localhost. Such via-proxy communications should not be enabled unconditionally.
Anyway the localhost-in-AllApps decision is yours solely.
You should take into account that there may be an application with unwanted localhost usage.
With localhost-in-AllApps you would not be able to manage such apps individually.
Moreover it would not be too easy to notice such activity with localHost-in-AllApps.

All in all if you think that localHost-in-AllApps is safe and suitable for you, please feel free to add locahost to AllApps.

If you have any questions please do not hesitate to contact us
VistaFirewallControl
Site Admin
 
Posts: 1493
Joined: Fri Mar 27, 2009 11:25 am

Re: Unblocking LocalHost in AllApps Zone

Postby metal450 » Wed Dec 21, 2016 6:54 pm

That makes a lot of sense - thanks for the thoughtful reply :) I hadn't considered the possibility of other proxies, but it makes perfect sense that if antiviruses do it, other programs might too. In light of that, I'll just stick with the safer route of listing each localhost app explicitly.

Cheers!
metal450
 
Posts: 50
Joined: Tue Dec 20, 2016 6:19 pm

Re: Unblocking LocalHost in AllApps Zone

Postby metal450 » Wed Dec 21, 2016 7:06 pm

One more quick related question:

I noticed that the default ThisPCOnly zone, in addition to allowing traffic to localhost, globally allows port 53 (for DNS). But if the app is only allowed to communicate within the local PC anyway, why might this additional port opening be needed? Wouldn't it be slightly safer/more restrictive if removed, without any loss of capability - or is this indeed needed for something even on localhost?

(I'm thinking about it being possible to be used by something for dns tunneling, for instance)
metal450
 
Posts: 50
Joined: Tue Dec 20, 2016 6:19 pm

Re: Unblocking LocalHost in AllApps Zone

Postby VistaFirewallControl » Thu Dec 22, 2016 3:35 pm

>I noticed that the default ThisPCOnly zone, in addition to allowing traffic to localhost, globally allows port 53 (for DNS). - or is this indeed needed for something even on localhost?

It’s rather the practice based.
We had a set of support issues before. There are some programs that just crash with DNS disabled. Please feel free to remove the DNS rules if it’s required.
Even a DNS name is resolved, program can't establish a connection to outside under ThisPCOnly.


>(I'm thinking about it being possible to be used by something for dns tunneling, for instance)

Not only DNS tunneling but SOCKS based "tunneling" as well, for instance.
The list of samples may be huge.
VistaFirewallControl
Site Admin
 
Posts: 1493
Joined: Fri Mar 27, 2009 11:25 am

Re: Unblocking LocalHost in AllApps Zone

Postby metal450 » Thu Dec 22, 2016 6:42 pm

>>program can't establish a connection to outside under ThisPCOnly.

Can't it? It looks to me like the rule allows port 53 connections to "anywhere," so if assigned ThisPCOnly, program *could* establish an outside connection - as long as it does so on port 53. No?

>>Not only DNS tunneling but SOCKS based "tunneling" as well, for instance. The list of samples may be huge.

...So I'm a bit confused by this response. Previous sentence said a program can't establish a connection to outside, but this says that it could use DNS tunneling - thus, it could establish a connection to outside...?

Thanks for clarifications :)
J~
metal450
 
Posts: 50
Joined: Tue Dec 20, 2016 6:19 pm

Re: Unblocking LocalHost in AllApps Zone

Postby VistaFirewallControl » Fri Dec 23, 2016 3:18 pm

Sorry, we had to make it clearer.

Of course, formally DNS connection is a connection.
However it could be hardly possible (until a DNS spoofing is involved anyhow) to send a personal information via a DNS request.
Imagine you asked DNS to resolve a domain name to IP. So what. A lot of machines ask for the same domain name resolving and the responses are mostly the same. So no personal information is involved into the communication.

The main firewall purpose is protecting from personal information leakage.
Any application that uses by-name access asks for DNS first to resolve a name to IP.
No direct by-name access is technically possible.
So even a non-personalized (DNS) communications is allowed worldwide, any following attempt to send a (potentially personal) payload will be blocked by ThisPCOnly zone.

That’s why DNS enabled may be treated as rather safe.
Anyway if you feel DNS is dangerous for ThisPCOnly, remove DNS related rules from the zone and the zone will be strict.
Just be ready that an application under the zone may not work properly, not only disabled “online”. Actually some applications may not suffer such blocking and being unable to verify connection related error codes, may just crash.

> but this says that it could use DNS tunneling - thus, it could establish a connection to outside

Any kind of tunneling is a different subject to discuss.
Tunnels are ways to create additional network connectivities.
You should be aware of a tunnel presence on your machine in advance.
Tunnel is not a virus, so a tunnel (if it is) was installed intentionally and evidently most probably.
So you should just take into account a tunnel presence while implementing your security policy.
For instance if you have a DNS “tunnel” and would like to stop DNS-via-the-tunnel for ThisPCOnle as well, you can just remove “typical” DNS access rules and add localhost:53 disabling rules at the bottom.
As the result no DNS connectivity will be possible even via a DNS tunnel.

Or maybe DisableAll would be better for your application?
VistaFirewallControl
Site Admin
 
Posts: 1493
Joined: Fri Mar 27, 2009 11:25 am

Re: Unblocking LocalHost in AllApps Zone

Postby metal450 » Fri Dec 23, 2016 7:00 pm

Fair enough, all makes sense. Lol yeah, I experienced crashing software already with localhost being blocked ;)

I suppose my curiosity just arose from the surprise of finding a "localhost-only" zone that actually allowed talking to anywhere (as long as it's over port 53). Although port 53 is supposed to be used for DNS, my (possibly incorrect) understanding was that, it technically *could* be used for any communication - not just DNS - as long as the remote server were listening on that port. Just like port 21 is typically for FTP, but an FTP server could be setup to listen on almost any other port, if you wanted.

Yes, I'm sure that in practical terms this isn't much risk, & even thinking about it would be excessively paranoid. So my question was probably more theoretical - like why it would be wise to open up a port (regardless of its *typical* service use) worldwide, in a zone that's designed for "local only." I suppose the reason is something like "because if you don't, some local-only software may break, and the realistic chance of information leaking is essentially none, so it seems like an overall better default solution." :)
metal450
 
Posts: 50
Joined: Tue Dec 20, 2016 6:19 pm

Re: Unblocking LocalHost in AllApps Zone

Postby VistaFirewallControl » Fri Dec 23, 2016 8:06 pm

>Lol yeah, I experienced crashing software already with localhost being blocked

Predictable more or less.
Connection errors are not checked always, so a program may continue using a non-established connection, so have a chance to crash.
Especially with localhost. A program could hardly expect localhost blocked, in spite of error checking is rather a good practice.
The typical behavior is freezing though……

> it technically *could* be used for any communication - not just DNS - as long as the remote

Obviously, but in spite of using DNS to send/receive arbitrary data belongs to rather malware, it’s not a good practice.
So technically you can create a server listening on UDP:53 and connect to the server from anywhere using arbitrary protocol. BUT DNS is not a good choice for that.
A DNS request can be issued probably easily, but then a reply will come.
The reply is expected of DNS format and such replies are parsed by system.
There is no guarantee that the system reaction will be adequate.
So DNS spoofing is not too wide spread.


>Yes, I'm sure that in practical terms this isn't much risk, & even thinking about it would be excessively paranoid.

There are some marketing platforms that use DNS extensions for some business communication.
Such cases are rare, the communication is still strict DNS formatted and the data sent is not private.

>So my question was probably more theoretical - like why it would be wise to open up a port (regardless of its *typical* service use) worldwide, in a zone that's designed for "local only." I suppose the reason is something like "because if you don't, some local-only software may break, and the realistic chance of information leaking is essentially none, so it seems like an overall

Hmm…. Hard to say precisely. DNS is the only we are aware of…..
Actually local-only (ThisPCOnly) is an exception and not used widely practically.
Generally if you need to disable an app from worldwide you should use LanOnly (as your LAN is probably safe). With LanOnly there are no such questions.
ThisPCOnly is a marginal sample never suggested by the Zone Adviser. Just an available option.
If you would like to exclude a (dangerous) PC from LanOnly you should just create a specific disabling rule. So if you need local only use LanOnly.
VistaFirewallControl
Site Admin
 
Posts: 1493
Joined: Fri Mar 27, 2009 11:25 am

Re: Unblocking LocalHost in AllApps Zone

Postby metal450 » Fri Dec 23, 2016 8:26 pm

>>Actually local-only (ThisPCOnly) is an exception and not used widely practically. Generally if you need to disable an app from worldwide you should use LanOnly (as your LAN is probably safe). With LanOnly there are no such questions.

I actually have a ton of software under ThisPCOnly. It seemed a better choice than LanOnly because:
1) If the software doesn't actually require the whole LAN, it's only doing IPC, why not just give it the minimum of what it needs? This is obviously just a matter of policy, but if one's policy is "disable by default & enable as-needed, & no more," LAN seemed to be more than is actually needed.
2) Much more importantly, as my system is a laptop & can move from LAN to LAN, the LAN is decidedly unsafe. i.e. if I'm at home it's certainly ok, but anytime I'm working in a coffee shop, a hotel room, conference, restaurant, etc, there could be other malicious people within the same network doing who-knows-what. So I actually treat "Lan" as potentially very insecure...
metal450
 
Posts: 50
Joined: Tue Dec 20, 2016 6:19 pm

Next

Return to Specific behavior

Who is online

Users browsing this forum: No registered users and 3 guests

cron
suspicion-preferred