On Tue, May 5, 2020 at 9:42 AM Zer0Cool <melin3...@gmail.com> wrote: > You really shouldn't be running guacd or tomcat as root (or really anything > else you can avoid doing so on). Create service accounts for both and > run/permission them according to those accounts. > > Totally agree. There is no reason to run *any* of the Guacamole components as root.
> As mentioned its likely a good idea to set ownership and file permissions > on > the tomcat/guacamole related directories to be as restrictive as you can > while still working. > > Yes. This is the biggest thing to do to mitigate the risk - make sure that only the accounts (dedicated accounts for the various services) can get to the files. Also, make sure the DB itself has been properly secured. > Password hashing would be a good way to go. The /path/to/file method is > pointless...the idea with that is have a credential file with more strict > permissions (and usually a hidden file, aka .filename) than the file that > looks at it...you can just set the guac.properties to be that strict > instead. > > I'm not even sure password hashing is all that valuable, but certainly a separate file doesn't really add anything. Just secure the files that are already there properly. > Also, there are many other things you can do to help secure guacamole that > really makes this a non-issue (from an outside threat perspective): > > - Dont run things as root > - Dont allow root ssh (instead authorized users should need to su, sudo -i, > etc. if they need root...which should be very rare). > - Run behind a reverse proxy > - Properly configure HTTPS/SSL and enforce it. > - Use service accounts with no shell login, and when possible no home dir > for running services. > Only note here is that FreeRDP now requires a home directory for storing known certificates for RDP hosts (similar to SSH known_hosts file), so the account running guacd will need a valid home directory. > - Log access and usage. Monitor logs or at least periodically check. > - Backup, backup...and then backup some more. You can never have too many > backups. Scheduled, on site/off site, manual, etc. Test backups to make > sure > you can get set back up. > - If available use security features like SEL or AppArmour > - Use 2FA like TOTP > - Do NOT expose SSH or anything other than ports 80/443 to your server from > the outside world. If you must remote access the server itself VPN. > > > +1 on pretty much everything, here. I would also say avoid exposing port 80 if you possibly can (I know it's required if you use LetsEncrypt for your certificates) - basically 443 should be the only thing open. On the system running guacd, also make sure that guacd is only listening on 127.0.0.1, and/or you block firewall access on port 4822. If your guacd and Tomcat instances are on different systems then you should SSL protect the Tomcat <-> guacd channel as documented in the manual. -Nick
