Looking for peoples experience with public/world accessible OOD sites

Hi all, I’m looking for feedback, experience, and advice, from folks who have public instances of OOD running. By public I mean the OOD site and Keycloak are available without a VPN from anywhere (not counting firewall geoblocking).

Here is my list of questions:

  1. What is your experience, and setup, for a public OOD instance?
  2. When making Keycloak public what additional security measures, to the base installation, did you make?
  3. When making OOD public what additional security measures, to the base installation, did you make?
  4. Is there any additional hardening that you did on the host OS?
  5. Are you using selinux on the keycloak or OOD server?
  6. Do you have any advice or recommendations?
1 Like

To answer a few of my own questions to give an idea where I am at for my site:

  1. I currently have a public Keycloak and private (vpn protected) OOD instance in production.
  2. My Keycloak instance is behind a F5 reverse proxy (virtual server), and then behind a nginx reverse proxy on the host. For the firewall we do geoblocking to restrict access to USA IPs. Then in nginx we have the Admin Urls restricted to a few specific static IPs in our campus network using allow/deny rules. In Keycloak itself we have brute force detection turned on in every realm that can be reached publicly.
  3. My OOD instance is currently private, behind our campus’ VPN, and we manage the deployment through Ansible and the OOD provided role. The web server is also behind a F5 reverse proxy (virtual server) but access is restricted to campus IP addresses.
  4. On the Keycloak server we follow CISCAT best practices but on the OOD server we do not due to login node requirements.
  5. The Keycloak server uses selinux but the OOD server does not (again due to login node requirements).
  6. Putting Keycloak behind nginx gave a lot of flexibility in protecting the admin pages which is nice.

I would really like to see some responses to this post!

OSC runs public sites. Both OOD and Keyloack are public. @tdockendorf do you have anything to add? Rate-limiting on F5s for example?

  1. What is your experience, and setup, for a public OOD instance?

OSC OOD instance and Keycloak are all on what is essentially a DMZ network, the only firewall between those instances and internet is iptables but port 443 is pretty much wide open except a few bad actor denials we maintain.

  1. When making Keycloak public what additional security measures, to the base installation, did you make?

We don’t do much, just protect with SSL behind Apache and Keycloak itself only listens on localhost and is served up by Apache. We enable Duo so some users and most staff are required to use two factor authentication.

  1. When making OOD public what additional security measures, to the base installation, did you make?

Just using SSL and only authenticates with Keycloak.

  1. Is there any additional hardening that you did on the host OS?

No one can log into the VMs via SSH but a select number of staff, this is handled by pam_access. The only ports open through iptables are what’s absolutely necessary like port 443. Port 22 is only open to OSC bastion servers which are our points of entry into all other systems and those bastion hosts require Duo two factor authentication. We use Puppet to avoid rogue config changes opening things up and also ensuring any rogue firewall rules or sudo entries are deleted if not defined in Puppet.

  1. Are you using selinux on the keycloak or OOD server?

We don’t use SELinux.

  1. Do you have any advice or recommendations?

If you can sure up the applications and host security so you are certain the only people who can log in are your staff and users, then next thing is ensuring users have to change passwords on regular basis and have some amount of complexity to those passwords. You can’t always prevent users from getting hacked if they use password known to the internet due to data breaches so just have to ensure if a user’s account is compromised, they are the only people affected. We require users to change passwords every 180 days and can’t reuse passwords. Staff have to change passwords every 90 days and can’t reuse passwords.

@jeff.ohrstrom - We are not behind any F5 equipment, our VMs are pretty much on the internet with nothing between the VM and internet. At some point in the future we will go behind Juniper SRX firewalls but that’s a ways down the road.