By: Cedric Ferraris user 21 Sep 2018 at 10:14 a.m. CDT

13 Responses
Cedric Ferraris gravatar
Hello, Do you have a doc related to best practices for hardening the Gluu server? Something like a list of the things to do before putting it in production? For example I can think of : - hiding/encrypting the setup.properties files (since it contains passwords); - Etc. Thanks

By Michael Schwartz staff 21 Sep 2018 at 11:11 a.m. CDT

Michael Schwartz gravatar
It's a good idea, but we don't have such a document like this. If you want to start one, we can review it.

By Aliaksandr Samuseu staff 21 Sep 2018 at 12:08 p.m. CDT

Aliaksandr Samuseu gravatar
Hi, Cedric. Let me try to gather some useful hints we could suggest in the past in one place. You are also welcomed to make your own points on the subject, as Michael suggested. Usually we would say that Gluu Server is not that much different from any other web service, thus the regular considerations apply. You are right about the `setup.properties.last` file, in the past we even suggested to remove it post-install (after properly documenting all passwords stored in it). Though most of those passwords still can be gathered by studying different configuration files, assuming intruder can access file system and knows where to look for them, no need to make their life easier. You also could review Apache's configuration in `/etc/httpd/conf.d/https_gluu.conf`, in particular SSL/TLS cipher suites allowed by it. We try to not limit the default setup too much, but depending on your requirements you may want to disable some of them if they are not secure enough. You also could consider uncommenting "Content-Security-Policy" and "X-Frame-Options" clauses there, but those haven't been proprly tested and defaults may need to be adjusted to be compatible with the current Gluu package. Another thing you could consider is to set "dynamicRegistrationEnabled" to false at "Configuration -> JSON Configuration -> oxAuth", if you don't plan to use the feature, or OIDC altogether. We also usually recommend to block access to oxTrust web UI from public networks. This can be achieved, for example, by limiting access to a specific ip address/network range only for corresponding "Location" directive in `/etc/httpd/conf.d/https_gluu.conf`: ``` <Location /identity> ProxyPass http://localhost:8082/identity retry=5 connectiontimeout=5 timeout=15 Require ip 45.55.232.15 </Location> ``` We'll get back to you when we'll come up with a more comprehensive list.

By Michael Schwartz staff 21 Sep 2018 at 12:09 p.m. CDT

Michael Schwartz gravatar
Alex, can you start a document in github under community edition project? I think this is a really great idea.

By Aliaksandr Samuseu staff 21 Sep 2018 at 12:10 p.m. CDT

Aliaksandr Samuseu gravatar
Sure, on it.

By Cedric Ferraris user 21 Sep 2018 at 12:44 p.m. CDT

Cedric Ferraris gravatar
Thanks, I'll wait for the list/document !

By Mohib Zico staff 27 Sep 2018 at 8:29 a.m. CDT

Mohib Zico gravatar
Just FYI... This ticket is in 'public' state and not covering any SLA / Support Plan: n/a ( Screenshot attached ).

By Cedric Ferraris user 27 Sep 2018 at 12:52 p.m. CDT

Cedric Ferraris gravatar
Yes I know.

By Cedric Ferraris user 04 Oct 2018 at 2:25 p.m. CDT

Cedric Ferraris gravatar
Hello, Have you already started that github document you mentioned? By the way, I've tried to restrict access to oxTrust UI from public networks by doing this in the httpd config: ``` <Location /identity> ProxyPass http://localhost:8082/identity retry=5 connectiontimeout=5 timeout=15 Order deny,allow Deny from all Allow from 10.0.0.0/8 172.0.0.0/8 </Location> ``` But it does not seem to work. If I'm trying to connect to https://MYURL, it redirects me to https://MYURL/oxauth anyway. And since I have no restriction in the oxAuth Location directive, I'm able to login to the GUI as an admin from public networks. Thanks

By Aliaksandr Samuseu staff 04 Oct 2018 at 3:13 p.m. CDT

Aliaksandr Samuseu gravatar
Hi, Cedric. Yes, we've started a collaborational internal project to gather related experiences of our engineers and developers. Please bear with us a bit longer until we'll finalize it and prepare for publishing. Thank you for your feedback, I'll try to reproduce the issue with the "Allow from" clause.

By Cedric Ferraris user 10 Oct 2018 at 3:45 p.m. CDT

Cedric Ferraris gravatar
> I'll try to reproduce the issue with the "Allow from" clause. Have you been able to reproduce the issue? I haven't been able to restrict access to oxTrust UI, neither with the "Allow from" nor with the "Require ip" clause. Thanks

By Aliaksandr Samuseu staff 10 Oct 2018 at 3:51 p.m. CDT

Aliaksandr Samuseu gravatar
Hi, Cedric. I haven't tried these exactly clauses ("allow from"), but next worked for me just fine (the same original suggestion mentioned): ``` <Location /identity> ProxyPass http://localhost:8082/identity retry=5 connectiontimeout=60 timeout=60 Order deny,allow #Allow from all <RequireAny> Require ip 192.168.238.162 Require ip 192.168.238.102 Require ip 127.0.0.1 </RequireAny> </Location> ``` In this example access will only be allowed from those 2 private IPs and from the localhost (when 443 port is forwarded to your local machine). Do you think this will satisfy your requirements? We also have published the doc on hardening security, as promised. You can find it [here](https://gluu.org/docs/ce/3.1.4/operation/security/).

By Aliaksandr Samuseu staff 10 Oct 2018 at 4:06 p.m. CDT

Aliaksandr Samuseu gravatar
If you need to allow access based on subnets, then according to [Apache's doc](https://httpd.apache.org/docs/current/mod/mod_authz_core.html#require) this is the clause you need to use: ``` Require ip 10 172.20 192.68.2 ``` This defines 3 ranges of ip addresses allowed to access the service.

By Cedric Ferraris user 11 Oct 2018 at 11:46 a.m. CDT

Cedric Ferraris gravatar
It is working now, thanks!