-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FR: Protect GUI with an optional simple user/pass login. #1726
Comments
+1 Would be nice to have some type of auth for API too. |
You don't need it. Just use authelia. Don't reinvent the auth wheel. |
Thanks for the suggestion. IMO that's an overkill. Unfortunately I'm not very familiar with python, but I would assume there are libraries to manage token based auth. |
Well, the auth wheel using Autheria and ngnix is not a "simple plugin" in Home Assistant Supervised. Like Frigate after adding your cameras to the config. Again, sorry for not having the correct data at hand. But isnt the majority of the frigate users Home Assistant users running Home Assistant Supervised if that is true - then how would our mainstream majority group of users go about protecting their frigate install? Frigate uses ngnix if I am not mistaken, are you suggesting to implement yet another ngnix and autheria and put that in front of Frigate? A agree with xiki808, its way overkill. Frigate is becoming a new and up-and-coming "NVR++" solution. And we cannot protect the installation with just a few parameters in the config file. |
Its not really overkill. You are using ngnix reverse proxy manager to listen to a sub domain. Then using authelia to front the incoming request. Its two docker containers and a supporting MySQL db. https://docs.ibracorp.io/all-guides-in-order/documentation/authelia I believe you can use https://www.cloudflare.com/teams/access/ too Otherwise if you can try trafiek + https://github.com/thomseddon/traefik-forward-auth Finally, the simplest but most insecure -> https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/ |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Landing here, throwing in my 2 cents. I don't use nginx (way too complex and super-annoying to configure), but I do use It's possible to configure an authentication HTTP middleware for frigate by adding labels to your services:
That should give you TLS + HTTP basic auth :-) |
How are you hashing your password? That step might be needed to be explicitly stated in case someone runs by this thread. |
In my case, I run Here's what the output looks like: Not sure if there are better alternatives out there, but |
This looks like a valid solution, it looks like the required hashing is MD5, SHA1, or BCrypt. Its been a while since I've seen how secure those hashes are, but traefik also supports a file that one could use in its place. |
Would you have a complete guide on how to put this in motion? Does this prevent randoms to use the local ip as well? |
This is documented in Traefik's docs
Yes: I currently also use a middleware to perform OAuth login via Google/GitHub, and it applies to other family members too. They need to log in with their account, before accessing locally exposed web services. |
@blakeblackshear |
Frigate shouldnt be responsible for auth. You can do auth in Home Assistant. If you using ngnix or traefik, they each have their own auth modules. A simple google search for traefik / ngnix auth, or traefik / ngnix http basic auth. |
Actually, i dont understand when you say Frigate should not be responsible of it. Not that I take anything as granted. Just generaly speaking of hosted tools, I dont see much tools not having any auth system even if they do not hold sensitive data. Thanks for the link, im hosting frigae on its own, without HA, without nging or treffik either. Ill try to install one of these and try to secure it like this. To come back to the question, it is just a question about a closed request that doenst seems to have any proper anwser. |
At this time we are not interested in implementing a first party auth system. To build an auth system that is secure and up to par with standards would take a lot of work and maintenance; especially as more requests would be made on top of the initial system to add analogous features. Meanwhile, through existing options like NginxProxyManager, Traeffik, etc, secure access can easily be setup (also easily setup for more than just frigate with the same service). We don't want to duplicate efforts that are already available in a solution that fully works with frigate. This is one of the many advantages of frigate being built in docker. |
My 2 cents: even if frigate implemented authentication, I wouldn't trust it, and would rather defer to a gateway. This is not mistrust in the maintainers, but rather encouragement of letting them work on what they do best 💪 |
As others said it would be nice to have simple user authentication, not for outside connection. It can be done with different solution. But for different privileges for specific user. At least for configuration, logs, deleting media, access for specific camera etc.. |
Does this solution with traefik avoid someone within your network being able to access Frigate using its local ip address and port 5000 or do you need an extra layer to achieve that? could you share your docker-compose.yml file? |
I don't expose frigate on port 5000: only via HTTPS through traefik. Unless a malicious actor gets access to the docker network itself, it should be OK. Generally don't leave stuff with open ports lying around, even if in LAN 😁 |
@mitchross I was able to protect Frigate using basic authentication with Caddy just to realise the Home Assistant Frigate card (https://github.com/dermotduffy/frigate-hass-card) doesn´t work as it requires Frigate with port 5000 exposed to be able to show the video/snapshots/recordings in Home Assistant @Ocramius do you use Home Assistant and this card by any chance? any idea how to make it work without exposing port 5000? |
@heisenberg2980 no home assistant: that's something you should report on the card's project |
@Ocramius thank you for the quick response, I will try to report it in the Home Assistant Frigrate integration project, but as Frigate doesn´t have any authentication on its own, I guess it is normal that anything that connects to Frigate (like Home Assistant Frigate integration) is not prepare to manage authentication and it just accesses Frigate using its local IP and port EDIT: issue open to Home Assistant Frigate integration: blakeblackshear/frigate-hass-integration#449 |
@Ocramius as I expected, the answer I got in the issue I created for the Home Assistant Frigate integration has been answered with "this is not an issue with the integration, the backend (Frigate) needs to support authentication, or the integration cannot use it" and I think that is correct. Taking into consideration the popularity of Frigate and how many people have it running at home (and I suspect this will only increase as it is an amazing piece of software), I think some basic authentication should be added to the UI. Having something with a port exposed in your local network without any type of authentication, and specially Frigates which manages camera feeds, is a bit worrying. Just as an example, any device within the network (including IOT devices) could access Frigate and send all the data (real time video, snapshots, recordings, etc) to an internet server, and this device would only need to do a quick scan of the network to find an IP address with port 5000 open, so this is basically an open door for scammers. @NickM-27 any thoughts? Note: I am happy to be corrected here, but I believe none of the solutions proposed (i.e. adding a reverse proxy and blocking port 5000) can be implemented without loosing access to other components connected to Frigate (like the Home Assistant integration). |
Hi guys. Frigate as a "secure NVR solution", especially in bigger networks and/or non-home context will be quite hard hence clips can be removed, configuration altered and the Frigate NVR-system taken down by anyone with the ip/hostname and port. Just navigate to http://:5000 If exposed to a public network such Internet its a no-brainer to ensure some sorts of auth, for example via a RevProxy solution etc. I would personally love for a simple "basic auth" solution to be built in to Frigate to protect it from misuse. NGINX is part of the architecture so it would be quite easy feat. If we decide to "stop with Basic Auth". |
Oof, this is why I don't use custom integrations in Home Assistant: it will basically open up anything to the outside, often unauthenticated. That's why I put Traefik in front of my HA instance, and it cannot get out of its own little VLAN corner, where it shall be stay in punishment forever. Putting Traefik in front of your services is good practice. |
This is an example of poor network design if you are trying to be conscious of security. It's being presented as of this is the way it has to be done but that's not true. There are many tools including VLANs, docker networking tools, reverse proxies, etc. which provide security, restrict network communication, remove unrestricted access to devices on the network, etc. which are highly recommended if you are trying to create a secure local network, and recommended even if frigate did also have an auth system. I'm not saying there's NO reason for frigate to have this, but presenting it as though it's the only option to secure frigate is incorrect and unrealistic. Even a simple auth system (frontend and API) is a lot of work and requires continuous testing / verification which is time that maintainers of frigate may not have. IMO a bad / rushed auth system is worse than none as it creates a false sense of security for users. |
Having basic auth without TLS is like setting up a password protected system and just putting the password on a sticky note on the monitor. The small fraction of frigate users who are running TLS for their local network surely also know how to setup wireguard or something similar to secure communication between machines on their local network. |
Cloudflare Tunnels and https://developers.cloudflare.com/cloudflare-one/applications/ is a very simple way to add sso with very minimal configuration. |
@NickM-27 @blakeblackshear what I am trying to say is Frigate is not following the standard basic authentication mechanism that almost all other products (i.e. pihole, portainer, influxdb, just to name some examples) are using, and while it is true that basic authentication without TLS is not secure, it is much better than no authentication (in the same way that a password protected system with the password on a sticky note in the monitor, while really poor security it is better than no password at all, as at least avoid remote attacks and it requires the attacker to be physically present in the room). With basic authentication an hypotetical IOT devices in the network trying to send Frigate data to an internet server would need to sniff the traffic between other device and Frigate during the login negotiation to be able to extract the credentials, which is not trivial and increases the complexity of the attack by various order of magnitude in comparison to just scan devices in the network with port 5000 open. I am still trying to figure out how to secure my Frigate instance without loosing the Home Assistant integration, so my guess is most people with a similar setup won´t even bother and will just have frigate with port 5000 exposed in their networks |
Like has been said, there are many tools to restrict which devices can communicate and how the network(s) can be used to alleviate this concern. It seems the issue is being presented as if no security at all or frigate providing its own auth are the only two options which is simply not the case. |
This isn't even how basic authentication works. Credentials are sent in a header on every request. It is trivial to sniff that traffic. If we implement auth in the future, it will be something worth implementing. |
Counterpoint: Network design and application security are orthogonal. Every application should be secure in and of itself regardless of the network, which should enable and allow end-to-end connectivity and not get involved in application access control. This doesn't mean that authentication and link layer encryption necessarily has to be done by Frigate itself. It could still be handled by something that "encapsulates" Frigate. |
I realize this is most likely a lost battle, but I'd like to add my 2 cents on why I think Frigate should have an authentication system:
Now, if the answer is "we don't have the time and resources to build something like this", I can totally understand it, but perhaps others in the community would like to step in and help (I know I would). Currently the answer is "we don't want it at all", which means no one is going to build it. To be more practical, if I managed to convince anyone, I can suggest the following plan:
Happy to hear any thoughts. |
There are like 5 billion guides on the internet about how to secure your services with ngnix . Frigate does not need a auth system. https://nginxproxymanager.com/guide/#quick-setup |
I disagree, and listed 7 reasons why. I count at least 3 of those 7 that an external authentication system won't address. Additionally, Frigate is already using nginx - asking people to setup yet another instance, and try to secure it themselves, is not going to lead to a more secure outcome. |
Also, ironically that 1st project you referenced does roll its own authentication and authorization mechanism |
If nothing else, the all or nothing approach to access is not good.
|
I comprehend that the developers would like to focus on the core implementation, but let's face the current situation: anything that gets access to the application port will have access to the configuration of the server, logs, system info, events, recordings, camera feeds and the HTTP API. For a so sensitive application, is critical the separation of concerns between multiple users, as is implemented in other systems, if there's any goal to make Frigate more mature. None of the solutions presented here can easily help with this. So, please, do not reject so strongly the implementation/integration of an Authorization system to Frigate. |
This is a duplicate of #1074 |
Describe what you are trying to accomplish and why in non technical terms
Protect the GUI from unauthorized access with a simple username/password login.
Describe the solution you'd like
Protect the events in Frigate from being deleted by non authorized users.
Describe alternatives you've considered
Network segmentation seems a bit drastic.
The text was updated successfully, but these errors were encountered: