I installed the latest nextclud hub. Everything seems to be working fine. Result from Nextcloud Security Scan is green A. In order to have an A + result, I need to edit something. Nextcloud hub runs on apache2 with configuration
<VirtualHost *:80>
DocumentRoot "/var/www/html/www.micloud.ddns.info"
ServerName www.micloud.ddns.info
ErrorLog ${APACHE_LOG_DIR}/nextcloud.error
CustomLog ${APACHE_LOG_DIR}/nextcloud.access combined
<Directory /var/www/html/www.micloud.ddns.info/>
Require all granted
Options FollowSymlinks MultiViews
AllowOverride All
<IfModule mod_dav.c>
Dav off
</IfModule>
SetEnv HOME /var/www/html/www.micloud.ddns.info
SetEnv HTTP_HOME /var/www/html/www.micloud.ddns.info
Satisfy Any
</Directory>
RemoteIPHeader X-Real-IP
RemoteIPInternalProxy 192.168.1.105
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
</VirtualHost>
In front of the apache2 server is the reverse proxy server nginx. it is configured as follows
server {
server_name micloud.ddns.info;
return 301 http://www.micloud.ddns.info$request_uri;
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/micloud.ddns.info/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/micloud.ddns.info/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
server_name www.micloud.ddns.info;
location / {
proxy_pass http://192.168.1.108;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/micloud.ddns.info/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/micloud.ddns.info/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
location /.well-known/carddav {
return 301 $scheme://$host/remote.php/dav;
}
location /.well-known/caldav {
return 301 $scheme://$host/remote.php/dav;
}
}
server {
if ($host = micloud.ddns.info) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name micloud.ddns.info;
return 404; # managed by Certbot
}
server {
if ($host = www.micloud.ddns.info) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name www.micloud.ddns.info;
return 404; # managed by Certbot
}
The domain micloud.ddns.info is invented.
I need to solve the red crosses in the picture
thx
I found out that I scan the web with www, so the test turns out badly (see the picture in the first post). If I test without www, the test result is A +. However, it is important for me to have www there. I also have nginx set to always redirect the web to www
I use letsencrypt and I generated the certificate for the domain with www and also without www certbot --nginx -d micloud.ddns.info -d www.micloud.ddns.info
but nothing was resolved. I have no idea how I should solve this problem.
I read somewhere that it is not recommended to dive nextcloud deep into directories. I tried to change the path from
most likely the issue is related to hostname you use to access your Nextcloud. As you get right results without www. prefix and worse result with prefix and test clearly states __host-Prefix cookies are missingā¦ the issue must be related to your redirection from micloud.ddns.info to www.micloud.ddns.info. Most likely Nextcloud is configured for micloud.ddns.info and is not avare of www. Strictrly speaking both websites are not the same so cookie your system places on the client are wrong which is the reason you get bad security rating.
You can inspect the cookie your server places on the client using āF12ā browser dev tools. Here screenshot from Firefox - double check domain of the cookie matches the address you access.
will do the trick. The other security headers are present when you access using right URL - most likely it works once you adopt the overwritehost directive in the config.php.
I tried what you advised me, but the result was none.
Of course Iām doing a new scan
However, there are a few tutorials where you can see the configuration for the nginx reverse proxy and the apache backend.
The question is how it works on scan.nextcloud
I have one more container where the old nextcloud is installed. If I do a security scan on the old nextcloud, the result is
with wwww
New and old nextcloud are behind the same reverse proxy server. The Nginx configuration files are the same.
Could there be a problem in .htaccess?
My .htaccess
<IfModule mod_headers.c>
<IfModule mod_setenvif.c>
<IfModule mod_fcgid.c>
SetEnvIfNoCase ^Authorization$ "(.+)" XAUTHORIZATION=$1
RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION
</IfModule>
<IfModule mod_proxy_fcgi.c>
SetEnvIfNoCase Authorization "(.+)" HTTP_AUTHORIZATION=$1
</IfModule>
</IfModule>
<IfModule mod_env.c>
# Add security and privacy related headers
# Avoid doubled headers by unsetting headers in "onsuccess" table,
# then add headers to "always" table: https://github.com/nextcloud/server/pull/19002
Header onsuccess unset Referrer-Policy
Header always set Referrer-Policy "no-referrer"
Header onsuccess unset X-Content-Type-Options
Header always set X-Content-Type-Options "nosniff"
Header onsuccess unset X-Download-Options
Header always set X-Download-Options "noopen"
Header onsuccess unset X-Frame-Options
Header always set X-Frame-Options "SAMEORIGIN"
Header onsuccess unset X-Permitted-Cross-Domain-Policies
Header always set X-Permitted-Cross-Domain-Policies "none"
Header onsuccess unset X-Robots-Tag
Header always set X-Robots-Tag "none"
Header onsuccess unset X-XSS-Protection
Header always set X-XSS-Protection "1; mode=block"
SetEnv modHeadersAvailable true
</IfModule>
# Add cache control for static resources
<FilesMatch "\.(css|js|svg|gif)$">
Header set Cache-Control "max-age=15778463"
</FilesMatch>
# Let browsers cache WOFF files for a week
<FilesMatch "\.woff2?$">
Header set Cache-Control "max-age=604800"
</FilesMatch>
</IfModule>
<IfModule mod_php7.c>
php_value mbstring.func_overload 0
php_value default_charset 'UTF-8'
php_value output_buffering 0
<IfModule mod_env.c>
SetEnv htaccessWorking true
</IfModule>
</IfModule>
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} DavClnt
RewriteRule ^$ /remote.php/webdav/ [L,R=302]
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
RewriteRule ^remote/(.*) remote.php [QSA,L]
RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
RewriteRule ^\.well-known/(?!acme-challenge|pki-validation) /index.php [QSA,L]
RewriteRule ^(?:\.(?!well-known)|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>
<IfModule mod_mime.c>
AddType image/svg+xml svg svgz
AddEncoding gzip svgz
</IfModule>
<IfModule mod_dir.c>
DirectoryIndex index.php index.html
</IfModule>
AddDefaultCharset utf-8
Options -Indexes
<IfModule pagespeed_module>
ModPagespeed Off
</IfModule>
#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####
ErrorDocument 403 //
ErrorDocument 404 //
you compare completely different tests. the A result is 3 years old! this installation would never get āAā today as everything before NC19 is out of support now. And this must be two different installation as they clearly show different versions!
you need to know security scan doesnāt happen each time you visit the website - you need to run another test with a button ātrigger re-scanā and review the result few minutes laterā¦
Please review you test procedure carefully and compare right results.
What I wrote in this post applies.
The issue is not yet resolved. Why do i have to wait between scans?
Each time I modified the config, I restarted the service and did a scan.
I do the test in Google Chrome Version 91.0.4472.77
I did the nextcloud scan again and the result was green A. Iām already desperate for that.
Then I tried to do a scan of mozilla firefox and the result was A +.
I also tried chromium and the A + result.
Then I cleared the cache in google chrome and did the scan again. The result is A +
I commented all the headers again and the result is still A +
again - the scan doesnāt happen when you just visit https://scan.nextcloud.com - you need to trigger another scan manually and wait a little to get fresh results!
If you just want to check for the headers, there are other scan services as well just for that.
Especially if you had different services under different subfolders in the past, such things are not handled very well. There is no special repo to report issues, sometimes it was just done in the regular repo for the homepage: Issues Ā· nextcloud/nextcloud.com Ā· GitHub
For ssl related stuff, Iād use ssllabs.com as well.
