On Thu, Mar 19, 2020 at 1:28 PM Slym <[email protected]> wrote:
> OK. I will check your link and try to find what's best for me. > Sounds good. > A basic authentication system on the guacd server itself should be enough > for security purpose. Then once connected and authenticated, be able to > manage connections from client-side. It is the web application sitting between the client and guacd which functions as the authentication layer. I understand you want to focus on the security but sometimes the security > goes against some use cases. If i'm right, most of the guacamole > installations are used to access some machines from an external network. > This scenario is indeed requiring a good level of security. > > But in my case, everything is in the same isolated network (guacd, > guacamole-client etc). > My own web application stores all the credentials and guacamole would only > be used as a proxy for RDP/SSH protocols. So the security of the GUACD > server is non-issue for me. Plus, i's a very low-security environment > (isolated Lab platform). > I strongly recommend against adopting the mindset that any situation does not require proper security practices. You should deploy/implement things with the Principle of Least Privilege in mind, and never grant such broad, unrestricted access. If the intent of your web application is to store all credentials and strongly dictate where connections may be directed, then that is good - this is what the Guacamole webapp does and what the stack is intended to require. You should *not* simply allow your users to feed the entire connection configuration from the client side. Consider what would happen if one of your users tried to connect to "localhost" instead of where you intend, or if a user specified "/etc" for the "drive-path" parameter of an RDP connection. You should not grant users in general with what amounts to the equivalent of administrative powers. - Mike
