LuLu
LuLu copied to clipboard
Blocklist not working
As a follow up to issue #291 and to assist in recreating the problem
Example of blocklist not blocking is - hotelscombined.com.au
It is on blockyoulist.txt, which is installed per instructions and site immediately loads (screenshots attached).
![Screen Shot 2021-01-15 at 8 37 13 am](https://user-images.githubusercontent.com/76892534/104653769-05b7d300-56b3-11eb-90c8-3b28107a0259.png)
![Screen Shot 2021-01-15 at 8 53 06 am](https://user-images.githubusercontent.com/76892534/104653774-07819680-56b3-11eb-9edc-7ce2cd2705f5.png)
![Screen Shot 2021-01-15 at 8 36 25 am](https://user-images.githubusercontent.com/76892534/104653748-ff295b80-56b2-11eb-9799-30fe684b4162.png)
I can also reproduce this. Currently the block list is non functional for me. But maybe I just misconfigured it some how? Would love to get this to work!
What I also tried:
- Restart LuLu
- Restart OSX
- Custom (Local) Blocklist
- Completely reinstalled LuLu (and installed with brew)
- Verified I am on Version 2.1.0
Update:
- It works in Safari ✅ but not in Chrome ❌
Thanks for the bug report and helpful repo steps!
I'm continuing to dig, but did find one issue in the code ...the block list isn't captured/saved if you close the window after copy & pasting in the block list (local or remote, i.e. https://ceadd.ca/blockyouxlist.txt). Obviously this is a bug in LuLu 😅
I've fixed this locally in code and will shortly be releasing a new version ...but if you want a workaround for now, (re)enter a block list, (i.e. https://ceadd.ca/blockyouxlist.txt) and then hit "Enter" to trigger it being captured/saved.
Once its captured/saved, blocking appears to work (e.g, http://hotelscombined.com.au
...in Safari):
Patrick Thanks for your efforts.
While the workaround is effective for Safari and Firefox - it is necessary to repeat it at each login. However blocklist sites remain accesible in Brave, Vivaldi or Tor (I don't have Chrome installed).
I believe I figured out why items on the blocklist remain accessible in Brave (and maybe Chrome, yet to be tested)
Apple's documentation notes:
/*!
* @property URL
* @discussion The flow's HTTP request URL. Will be nil if the flow did not originate from WebKit.
*/
@property (readonly, nullable) NSURL *URL;
Confirmed in Brave that the reported flow (that passes thru the firewall) only has the ip address, and the URL is nil.
...which means URL-based items in block list (e.g. hotelscombined.com.au
) are ineffective, as the the host/URL never is seen by the firewall.
Will dig more to see if there is workaround, but this might just be an OS-limitation, that we have to live with :(
Just pushed v2.2.0 which has the the discussed fixes ...specifically block list is always captured when entered, and now correctly (re)loaded. on reboot.
Also confirmed that to limitations of macOS, blocking via host name is only applicable to (as Apple notes) "Network.framework or NSURLSession connections".
As such, for browsers (such as Chrome), that do not leverage these frameworks, only ip address based blocking is supported. ...as Safari and Firefox leverage such frameworks, they are not subject to this limitation.
If you wanted to download/give v2.2.0 a test, that'd be great!
Grab from: https://github.com/objective-see/LuLu/releases/tag/v2.2.0 or https://bitbucket.org/objective-see/deploy/downloads/LuLu_2.2.0.dmg
It is effective in Safari but not Firefox. To further check I have tried both ceadd file and local file. I have also added URLs to the local file with the same outcome (blocked in Safari but not Firefox).
![Screen Shot 2021-01-17 at 8 22 42 pm](https://user-images.githubusercontent.com/76892534/104836574-a3bfbf00-58a6-11eb-9860-fd28db50d035.png)
![Screen Shot 2021-01-17 at 8 18 21 pm](https://user-images.githubusercontent.com/76892534/104836570-9f93a180-58a6-11eb-90cf-c97f4d71dd22.png)
![Screen Shot 2021-01-17 at 8 18 31 pm](https://user-images.githubusercontent.com/76892534/104836572-a1f5fb80-58a6-11eb-9932-b5b87c8e3f1a.png)
![Screen Shot 2021-01-17 at 8 19 50 pm](https://user-images.githubusercontent.com/76892534/104836573-a3272880-58a6-11eb-84f7-ae7471cb6f62.png)
For remote list, would it be possible to have a periodical update setting? Rather than only loading upon blocklist init.. Comparing to local list which is checked for timestamp every time a new flow is handled, remote list update frequency is very low.
Thanks a lot!
I'm also seeing that it's effective in Safari but not Firefox.
Lulu 2.2.0 macOS 11.1 (M1)
I believe I figured out why items on the blocklist remain accessible in Brave (and maybe Chrome, yet to be tested)
Apple's documentation notes:
/*! * @property URL * @discussion The flow's HTTP request URL. Will be nil if the flow did not originate from WebKit. */ @property (readonly, nullable) NSURL *URL;
Confirmed in Brave that the reported flow (that passes thru the firewall) only has the ip address, and the URL is nil. ...which means URL-based items in block list (e.g.
hotelscombined.com.au
) are ineffective, as the the host/URL never is seen by the firewall.Will dig more to see if there is workaround, but this might just be an OS-limitation, that we have to live with :(
I tried this functionality in Little Snitch 5 (LS) and it was able to block requests by domain in all apps, not only Safari. Doesn't they use the same network extension framework?
I also don't understand why Lulu alerts for Safari doesn't contain a domain but only an IP address like that:
In some cases, alerts do contain a domain, though. @objective-see
Hello the rules list doesn't work at all for me. When I select a local text file list and hit enter then click the button that says "View Rules" The LuLu program window stays empty and does not show any of the rules on my list.
Same for me, using the latest version
If I list sites by domain name it does not have any effect on browsers or even ping command in terminal If I add ip address it does not have have any effect on browsers if I use domain name, but it does block the sites by ip address in all browsers including the ping command
- Follow up to this issue with new version (2.4.2) of LuLu as seen in attached images.
- MacOS Big Sur V 11.5.2
- Browser is FireFox. List tested is the provided "ceadd".
- URL tested from list: plex2.com (for others testing, this website was clean on virustotal.com)
- Website loaded. I tried the press enter after adding list workaround, and reloaded browser and inputted the domain and it loaded all the same.
I'm confused here..
I made a blocklist file with a single entry google.com
, but I can still ping google.com
But if I add 0.0.0.0 google.com
to my /private/etc/hosts
file, it blocks the pings/https just fine.
How can I get this to work in Lulu?
I'm having the same problem, the domains on the Lulu blocklist are still accessible in Safari. The domains are only successfully blocked when I add them in host (with Lulu's block list disabled).
- Lulu version 2.4.2
- macOS 12.6.2
Block list not works. Tried url and local file, restarted Lulu and Mac, clicked "Update" and switched "on/off".
- Lulu version 2.4.2
- macOS 13.2 (22D49)
I tried again with a local txt file, and the blocklist still doesn't seem to work. Wonder if it is my configuration's problem.
- Lulu v2.4.2
- macOS 13.3
LuLu blocklist not working for me. I have tried both local .txt
file blocklist and an oneline one such as https://ceadd.ca/blockyouxlist.txt
. With regards to browsers i have tried Orion, Chrome and Safari. My methodology is to insert the blocklist and press enter. Hereafter i open safari and type in the url of a given site such as hotelscombined.com.au
and observe that the site continues to load for a given site. Also i can ping through terminal hotelscombined.com.au
- Lulu v2.4.3
- macOS Ventura (13.3.1)
Weirdly, it's the same for me. Tried it all, seems blocklist doesn't do anything 😐
I've got a blocklist which starts like that. And I can ping all of those hosts.
Interestingly, this only makes apple.com inaccessible in Firefox, despite I didn't block it there! Maybe could it be a parsing error?
Anyway, this looks like a huge issue... :|