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.

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.

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

Sure, on it.

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

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

Yes I know.

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

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.

> 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

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/).

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.

It is working now, thanks!