mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3427] Can we have an option to block access to 127.0.0.1 and/or other internal only IP addresses? #2153
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2153
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ilikenwf on GitHub (May 21, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3427
This is a pretty big issue as far as security is concerned as some websites fingerprint...and stuff...by using websockets to 127.0.0.1 looking for various ports:
https://nullsweep.com/why-is-this-website-port-scanning-me/
When I'm on a trusted network I can use a namespace, but when I'm moving around and using a VPN, this is not possible.
@rusty-snake commented on GitHub (May 21, 2020):
I think this is only possible by using network namespaces. Without
net/netnsis would break your hole system.In order to protect against those websites, you should use uBlock origin and/or uMatrix
uBlock origin: (
||127.*$third-partyor||127.0.^$important,third-party) and||localhost^$important,third-partyuMatrix: whitelist JS and block all third-party stuff.
I'm using
|ws://(unencrypted websockets) for over a year without issues@ilikenwf commented on GitHub (May 21, 2020):
@rusty-snake I can confirm after testing that those ubo filters work...this person wrote up an article and provided a proof of concept with a websocket port scanner:
https://medium.com/@stestagg/stealing-secrets-from-developers-using-websockets-254f98d577a0
The scanner (resource heavy):
http://frontend-overflowstack.com/
@SkewedZeppelin commented on GitHub (May 21, 2020):
Those uBO rules don't prevent the issue when a scanner uses a domain that points to localhost instead due to CORS.
+1 for uMatrix however.
-----Original Message-----
From: rusty-snake notifications@github.com
Reply-To: netblue30/firejail reply@reply.github.com
To: netblue30/firejail firejail@noreply.github.com
Cc: Subscribed subscribed@noreply.github.com
Subject: Re: [netblue30/firejail] Can we have an option to block access to 127.0.0.1 and/or other internal only IP addresses? (#3427)
Date: Thu, 21 May 2020 09:01:08 -0700
I think this is only possible by using network namespaces. Without
net/netnsis would break your hole system.In order to protect against those websites, you should use uBlock origin and/or uMatrix
uBlock origin: (
||127.*$third-partyor||127.0.^$important,third-party) and||localhost^$important,third-partyuMatrix: whitelist JS and block all third-party stuff.
I'm using
|ws://(unencrypted websockets) for over a year without issues@ts1a commented on GitHub (May 21, 2020):
What about disabling websockets in uBO?
*$websocketAnd if you want to add exceptions you can do it this way:
*$websocket,denyallow=twitch.tv@ilikenwf commented on GitHub (May 21, 2020):
Sounds like a good case for an addon of some kind really...I wonder if the default of "privacy oriented origin policy" would already mitigate it.
@ilikenwf commented on GitHub (May 21, 2020):
The websocket filter in uBO doesn't work for me, I may have something else managing CSP?
@rusty-snake commented on GitHub (May 28, 2020):
This will break things like dnsmasq, Xorg (depending on setup), ...
@ilikenwf commented on GitHub (May 29, 2020):
It would be optional...but it looks like uBO is working on a fix anyway.
@rusty-snake commented on GitHub (May 29, 2020):
https://privacy-handbuch.de/handbuch_21g.htm has now also good lists.
@curiosityseeker commented on GitHub (May 31, 2020):
Yes, but according to @gorhill, @gwarser 's list is better.
@ghost commented on GitHub (May 31, 2020):
Some explanations why Privacy Handbuch filters are bad: https://github.com/uBlockOrigin/uBlock-issues/issues/1070#issuecomment-634706689
Some questions about further improvements of my list: https://github.com/uBlockOrigin/uBlock-issues/issues/1070#issuecomment-636483139
@rusty-snake commented on GitHub (May 31, 2020):
Thanks, however I already block any third-party request with uMatrix.
@ilikenwf commented on GitHub (Jun 1, 2020):
So here's a question...could firejail implement a system to allow a prioritized whitelist of network interfaces to use, and automatically switch between them?
Like, if I list tun0, wlan0, eth0 in that order, firejail will poll and detect when one or more of these is up, and if it had been using one of the others, switch to the one of highest priority that is available...
This would support the use of network namespaces while also making firejail less a pain in the ass when one is switching network contexts regularly.
Even if not automatic, it could just detect changes to the routing table and stop all network access for the application(s) using this feature, and trigger a notification or something via dbus, allowing a desktop notification, so that the user can close the application and reopen it for the new network to be used.
@rusty-snake commented on GitHub (Jun 1, 2020):
Should be possible
Maybe a bridge can help you here for now.
@ilikenwf commented on GitHub (Jun 1, 2020):
Except tun0 doesn't necessarily always exist, and I'm not sure a bridge can be created using a not presently existing interface.
@rusty-snake commented on GitHub (Jun 1, 2020):
I mean running a script when changing network connection (NetworkManager can do this automatic).
@ilikenwf commented on GitHub (Jun 1, 2020):
I didn't realize networkmanager could handle a bridge in conjunction
with vpn...
Guess I'll have to check the docs...
On 6/1/20 12:58 PM, rusty-snake wrote:
@cabonamigo commented on GitHub (Jun 4, 2020):
What I do is block 127.x.x.x entirely on iptables or nft, I only open with a rule for specific location:port paiir, I think this would be better done there (ipt and nft), just assign a ip for it and use the same ip, and block it.