Block subdomains?

[bignumbers]

Is there the means in Little Snitch to block a domain and its subdomains? I've been reading about 2o7.net and how it's used by applications (including iTunes, Adobe CS3). I really don't like the privacy implications.

There's an opt-out but I'd like to block this and other domains, completely, from all applications.

Thanks!

[hagen]

I made two rules for All Applications:

Deny connections to *.2o7.net

Deny connections to *.207.net

So far this seems to be working, although it's been only a few hours. I also read somewhere that it will prevent a lot of web pages from completing. My defense against this type of thing is to click stop, then refresh. Many times that gets around a hangup.

[Guest]

I've tried the same thing to block everything from doubleclick.net with the following rule: *.doubleclick.net

I must be doing something wrong since it still shows up in the connection history as having sent a few bytes to doubleclick.net

[fukami]

Is there the means in Little Snitch to block a domain and its subdomains?

Doesn't seem to work with *.domain.tld. So maybe someone can enlighten us how to manage to block domains including all of their subdomains without knowing every single name of it :)

The other thing I recognized is the following: When you choose to block lets say 192.168.112.2o7.net for all applications, Safari still grant access to it (well, if you have a rule that generally allows Safari to access port 80 on any server). I wonder how to properly include Safari into block lists of this kind.

[hagen]

oops, I spoke too soon. My "deny *.207.net" rule doesn't work after all.

Has anyone tried denying a range of IP addresses, as we could do in version 1? I'll have to see if that works when I get some free time.

[norbert]

Little Snitch does not allow wildcards in DNS hostnames, so entering hostnames like "*.207.net" wont work.

However you can specify IP ranges using prefix notation. For example:

17.112.152/24 represents the range from 17.112.152.0 to 17.112.152.255 (the "24" means that only the first 24 bits of the IP address are considered). Or enter 138/8 to specify the range 138.0.0.0 - 138.255.255.255

[Guest]

Little Snitch does not allow wildcards in DNS hostnames, so entering hostnames like "*.207.net" wont work.

However you can specify IP ranges using prefix notation. For example:

17.112.152/24 represents the range from 17.112.152.0 to 17.112.152.255 (the "24" means that only the first 24 bits of the IP address are considered). Or enter 138/8 to specify the range 138.0.0.0 - 138.255.255.255

So why don't you still have the useful drop-down menu with all the possible subnets already calculated? THAT was COOL! You shouldn't have taken that feature out!

[Nat!]

Little Snitch does not allow wildcards in DNS hostnames, so entering hostnames like "*.207.net" wont work.

It would be so nice, to for example allow *.imageshack.us. My rules are getting out of hand here

[SandManMattSH]

So is there any way to put a wildcard on a URL rather than an IP range?

[L-Snitzcher]

I am still confused about this.

Exactly how are we supposed to deny or allow all connections to image sites like photobucket.com and imageshack.us which have ever-changing image number prefixes before their actual domain names? As others here have stated, you simply can't use a wildcard, (asterisk), before the domain name. Little Snitch complains that it is an invalid domain name, and it doesn't work.

As I am sure the developer understands, it is extremely tedious to have to sit here and repeatedly click on the allow/deny dialog window while dozens of avatars are loading on a forum page.

I hope that the developer can offer us a clear, precise answer regarding this problem, which I suspect many LS users experience.

Thanks!

[L-Snitzcher]

Okay, I just did some experimenting at one of the popular forums that I frequent, where members use a number of the different free image hosting sites for their avatars. I allowed dozens of different image URLs from these sites, and then converted them to full IP ranges, based on the developer's instructions in a previous post here.

Here is what I put in Little Snitch. This is not a full list of the IP addresses that these image hosting sites use, but it is enough to prove my point:

209.17.65/ = photobucket.com
209.17.68/ = s1.tinypic.com
209.17.69/ = photobucket.com
209.17.73/ = photobucket.com
209.17.74/ = s3.tinypic.com/s4.tinypic.com
38.99.77/ = imageshack.us
69.16.251/ = picoodle.com
69.50.205/ = avatarist.com
92.48.112/ = lookpic.com

In spite of putting the above IP ranges in Little Snitch, each time that I go back to that same forum page, Little Snitch again asks me if I want to allow or deny the URLs.

In short, this method of allowing or denying IP ranges, at least for these kinds of image hosting sites, is NOT working. We really do need a solution to this problem. Little Snitch is a great product. I hope the developer can find a way around this problem.

Thanks again!

[egrieco]

So this post answers my question about whether LittleSnitch supports domain wildcards. Has that or will it change in a future version?

The two most useful features that I would like to see at this point:
1. Domain wildcards
2. Domain lists

Then you could say:
Allow access to "DomainWhitelist"
Deny access to "*.doubleclick.net"

Two other features that would be nice:
3. LS rule set synchronization
4. the ability to share LS rule sets easily to see what everyone else is blocking.

[L-Snitzcher]

Well, it has been almost three weeks since I posted my last comments, and others have posted about the same problem even before I did. In light of the clear silence from the developer on his own forum, should we just assume that he has no interest in dealing with this problem, or perhaps simply doesn't know how to fix it, and thus remains silent?

To the developer:

Sir, a lot of people here would really appreciate hearing from you regarding this issue. Good customer service will go a long way towards promoting your product. Silence, on the other, does not build customer confidence, or increase sales. Thanks!

[farnsworth]

(bump)

I had hopes for 2.0.5, but no such luck. My rules for iTunes alone look like:

-----
Allow TCP connections to port 443 (https) of genius-download.itunes.apple.com
Allow TCP connections to port 443 (https) of genius-upload.itunes.apple.com
Allow TCP connections to port 443 (https) of genius.itunes.apple.com
Allow TCP connections to port 443 (https) of p7-buy.itunes.apple.com
Allow TCP connections to port 443 (https) of phobos.apple.com
Allow TCP connections to port 443 (https) of securemetrics.apple.com
Allow TCP connections to port 80 (http) of 199.45.62.0/24
Allow TCP connections to port 80 (http) of 206.57.29.0/25
Allow TCP connections to port 80 (http) of 209.170.118.0/26
Allow TCP connections to port 80 (http) of 209.18.0.0/18
Allow TCP connections to port 80 (http) of 8.21.194.0/26
Allow TCP connections to port 80 (http) of 96.17.0.0/16
Allow TCP connections to port 80 (http) of itunes.com
Allow TCP connections to port 80 (http) of metrics.apple.com
Allow TCP connections to port 80 (http) of my.itunes.apple.com
Allow TCP connections to port 80 (http) of phobos.apple.com
Allow TCP connections to port 80 (http) of service.cddb.com
-----

And of course continue to require mucking-with. Do no developers find that ridiculous? An astersik wildcard would reduce that to what it logically should be:

-----
Allow TCP connections to port 443 (https) of *.apple.com
Allow TCP connections to port 80 (http) of *.edgesuite.net
Allow TCP connections to port 80 (http) of itunes.com
Allow TCP connections to port 80 (http) of *.apple.com
Allow TCP connections to port 80 (http) of service.cddb.com
-----

So, what's the holdup?

[PhilMac]

Agreeing with this 500%. This is insane! My typing is being interrupted right now (by iTunes) for this very reason.

In fact, I wouldn't be surprised if this is already a feature, but an obscure one.

Either way, I wish the developer would just come on here and say something about it. As it is, it seems like he's just blowing us off. I guess I'll send an email.