Add security http headers to vhost configuration. Change IMAP AUTH type (['imap_auth_type']) to value 'LOGIN'.
This commit is contained in:
parent
f8084d731b
commit
c2d163f142
@ -1110,6 +1110,80 @@ cat <<EOF > ${APACHE_VHOST_DIR}/${WEBSITE_NAME}.conf 2>> $log_file
|
||||
RewriteCond %{HTTPS} !=on
|
||||
RewriteRule (.*) https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
|
||||
|
||||
# ==========
|
||||
# - HTTP security Headers
|
||||
# ==========
|
||||
|
||||
# - X-Frame-Options
|
||||
# -
|
||||
# - The X-Frame-Options header (RFC), or XFO header, protects your visitors
|
||||
# - against clickjacking attacks. An attacker can load up an iframe on their
|
||||
# - site and set your site as the source, it's quite easy:
|
||||
# -
|
||||
# - <iframe src="https://scotthelme.co.uk"></iframe>
|
||||
# -
|
||||
# - Using some crafty CSS they can hide your site in the background and create some
|
||||
# - genuine looking overlays. When your visitors click on what they think is a harmless
|
||||
# - link, they're actually clicking on links on your website in the background. That
|
||||
# - might not seem so bad until we realise that the browser will execute those requests
|
||||
# - in the context of the user, which could include them being logged in and authenticated
|
||||
# - to your site!
|
||||
# -
|
||||
# - Troy Hunt has a great blog on 'Clickjack attack – the hidden threat right in front :
|
||||
# - of you':
|
||||
# -
|
||||
# - http://www.troyhunt.com/2013/05/clickjack-attack-hidden-threat-right-in.html
|
||||
# -
|
||||
# - Valid values include DENY meaning your site can't be framed, SAMEORIGIN which allows
|
||||
# - you to frame your own site or ALLOW-FROM https://example.com/ which lets you specify
|
||||
# -sites that are permitted to frame your own site.
|
||||
# -
|
||||
Header always set X-Frame-Options "SAMEORIGIN"
|
||||
|
||||
# - X-Xss-Protection
|
||||
# -
|
||||
# - This header is used to configure the built in reflective XSS protection found
|
||||
# - in Internet Explorer, Chrome and Safari (Webkit). Valid settings for the header
|
||||
# - are 0, which disables the protection, 1 which enables the protection
|
||||
# - and 1; mode=block which tells the browser to block the response if it
|
||||
# - detects an attack rather than sanitising the script.
|
||||
# -
|
||||
Header always set X-Xss-Protection "1; mode=block"
|
||||
|
||||
# - X-Content-Type-Options
|
||||
# -
|
||||
# - Nice and easy to configure, this header only has one valid value, nosniff.
|
||||
# - It prevents Google Chrome and Internet Explorer from trying to mime-sniff
|
||||
# - the content-type of a response away from the one being declared by the server.
|
||||
# - It reduces exposure to drive-by downloads and the risks of user uploaded content
|
||||
# - that, with clever naming, could be treated as a different content-type, like
|
||||
# - an executable.
|
||||
# -
|
||||
Header always set X-Content-Type-Options "nosniff"
|
||||
|
||||
# - Content Security Policy
|
||||
# -
|
||||
# - The CSP header allows you to define a whitelist of approved sources of content
|
||||
# - for your site. By restricting the assets that a browser can load for your site,
|
||||
# - like js and css, CSP can act as an effective countermeasure to XSS attacks. I
|
||||
# - have covered CSP in a lot more detail in my blog Content Security Policy - An
|
||||
# - Introduction (https://scotthelme.co.uk/content-security-policy-an-introduction/).
|
||||
# -
|
||||
# - Here is a basic policy to enforce TLS on all assets and prevent
|
||||
# - mixed content warnings.
|
||||
# -
|
||||
#
|
||||
Header always set Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'"
|
||||
|
||||
# - Referrer-Policy
|
||||
# -
|
||||
# - The HTTP referer (originally a misspelling of referrer[1]) is an HTTP header
|
||||
# - field that identifies the address of the webpage (i.e. the URI or IRI) that
|
||||
# - linked to the resource being requested. By checking the referrer, the new
|
||||
# - webpage can see where the request originated.
|
||||
# -
|
||||
Header set Referrer-Policy "strict-origin-when-cross-origin
|
||||
|
||||
CustomLog ${APACHE_LOG_DIR}/${WEBSITE_NAME}-access.log combined
|
||||
ErrorLog ${APACHE_LOG_DIR}/${WEBSITE_NAME}-error.log
|
||||
|
||||
@ -1178,7 +1252,79 @@ EOF
|
||||
fi
|
||||
cat <<EOF >> ${APACHE_VHOST_DIR}/${WEBSITE_NAME}.conf 2>> $log_file
|
||||
|
||||
SSLEngine on
|
||||
# ==========
|
||||
# - HTTP security Headers
|
||||
# ==========
|
||||
|
||||
# - X-Frame-Options
|
||||
# -
|
||||
# - The X-Frame-Options header (RFC), or XFO header, protects your visitors
|
||||
# - against clickjacking attacks. An attacker can load up an iframe on their
|
||||
# - site and set your site as the source, it's quite easy:
|
||||
# -
|
||||
# - <iframe src="https://scotthelme.co.uk"></iframe>
|
||||
# -
|
||||
# - Using some crafty CSS they can hide your site in the background and create some
|
||||
# - genuine looking overlays. When your visitors click on what they think is a harmless
|
||||
# - link, they're actually clicking on links on your website in the background. That
|
||||
# - might not seem so bad until we realise that the browser will execute those requests
|
||||
# - in the context of the user, which could include them being logged in and authenticated
|
||||
# - to your site!
|
||||
# -
|
||||
# - Troy Hunt has a great blog on 'Clickjack attack – the hidden threat right in front :
|
||||
# - of you':
|
||||
# -
|
||||
# - http://www.troyhunt.com/2013/05/clickjack-attack-hidden-threat-right-in.html
|
||||
# -
|
||||
# - Valid values include DENY meaning your site can't be framed, SAMEORIGIN which allows
|
||||
# - you to frame your own site or ALLOW-FROM https://example.com/ which lets you specify
|
||||
# -sites that are permitted to frame your own site.
|
||||
# -
|
||||
Header always set X-Frame-Options "SAMEORIGIN"
|
||||
|
||||
# - X-Xss-Protection
|
||||
# -
|
||||
# - This header is used to configure the built in reflective XSS protection found
|
||||
# - in Internet Explorer, Chrome and Safari (Webkit). Valid settings for the header
|
||||
# - are 0, which disables the protection, 1 which enables the protection
|
||||
# - and 1; mode=block which tells the browser to block the response if it
|
||||
# - detects an attack rather than sanitising the script.
|
||||
# -
|
||||
Header always set X-Xss-Protection "1; mode=block"
|
||||
|
||||
# - X-Content-Type-Options
|
||||
# -
|
||||
# - Nice and easy to configure, this header only has one valid value, nosniff.
|
||||
# - It prevents Google Chrome and Internet Explorer from trying to mime-sniff
|
||||
# - the content-type of a response away from the one being declared by the server.
|
||||
# - It reduces exposure to drive-by downloads and the risks of user uploaded content
|
||||
# - that, with clever naming, could be treated as a different content-type, like
|
||||
# - an executable.
|
||||
# -
|
||||
Header always set X-Content-Type-Options "nosniff"
|
||||
|
||||
# - Content Security Policy
|
||||
# -
|
||||
# - The CSP header allows you to define a whitelist of approved sources of content
|
||||
# - for your site. By restricting the assets that a browser can load for your site,
|
||||
# - like js and css, CSP can act as an effective countermeasure to XSS attacks. I
|
||||
# - have covered CSP in a lot more detail in my blog Content Security Policy - An
|
||||
# - Introduction (https://scotthelme.co.uk/content-security-policy-an-introduction/).
|
||||
# -
|
||||
# - Here is a basic policy to enforce TLS on all assets and prevent
|
||||
# - mixed content warnings.
|
||||
# -
|
||||
#
|
||||
Header always set Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'"
|
||||
|
||||
# - Referrer-Policy
|
||||
# -
|
||||
# - The HTTP referer (originally a misspelling of referrer[1]) is an HTTP header
|
||||
# - field that identifies the address of the webpage (i.e. the URI or IRI) that
|
||||
# - linked to the resource being requested. By checking the referrer, the new
|
||||
# - webpage can see where the request originated.
|
||||
# -
|
||||
Header set Referrer-Policy "strict-origin-when-cross-origin
|
||||
|
||||
# - HTTP Strict Transport Security (HSTS)
|
||||
# -
|
||||
@ -1190,6 +1336,8 @@ cat <<EOF >> ${APACHE_VHOST_DIR}/${WEBSITE_NAME}.conf 2>> $log_file
|
||||
# -
|
||||
Header always set Strict-Transport-Security "max-age=31536000"
|
||||
|
||||
SSLEngine on
|
||||
|
||||
SSLCertificateFile ${APACHE_CERT_DIR}/$APACHE_SERVER_CERT
|
||||
SSLCertificateKeyFile ${APACHE_CERT_DIR}/$APACHE_SERVER_KEY
|
||||
$SSLCertificateChainFile
|
||||
@ -1214,6 +1362,80 @@ cat <<EOF >> ${APACHE_VHOST_DIR}/${WEBSITE_NAME}.conf 2>> $log_file
|
||||
RewriteCond %{HTTPS} !=on
|
||||
RewriteRule (.*) https://%{SERVER_NAME}%{REQUEST_URI} [R=301,L]
|
||||
|
||||
# ==========
|
||||
# - HTTP security Headers
|
||||
# ==========
|
||||
|
||||
# - X-Frame-Options
|
||||
# -
|
||||
# - The X-Frame-Options header (RFC), or XFO header, protects your visitors
|
||||
# - against clickjacking attacks. An attacker can load up an iframe on their
|
||||
# - site and set your site as the source, it's quite easy:
|
||||
# -
|
||||
# - <iframe src="https://scotthelme.co.uk"></iframe>
|
||||
# -
|
||||
# - Using some crafty CSS they can hide your site in the background and create some
|
||||
# - genuine looking overlays. When your visitors click on what they think is a harmless
|
||||
# - link, they're actually clicking on links on your website in the background. That
|
||||
# - might not seem so bad until we realise that the browser will execute those requests
|
||||
# - in the context of the user, which could include them being logged in and authenticated
|
||||
# - to your site!
|
||||
# -
|
||||
# - Troy Hunt has a great blog on 'Clickjack attack – the hidden threat right in front :
|
||||
# - of you':
|
||||
# -
|
||||
# - http://www.troyhunt.com/2013/05/clickjack-attack-hidden-threat-right-in.html
|
||||
# -
|
||||
# - Valid values include DENY meaning your site can't be framed, SAMEORIGIN which allows
|
||||
# - you to frame your own site or ALLOW-FROM https://example.com/ which lets you specify
|
||||
# -sites that are permitted to frame your own site.
|
||||
# -
|
||||
Header always set X-Frame-Options "SAMEORIGIN"
|
||||
|
||||
# - X-Xss-Protection
|
||||
# -
|
||||
# - This header is used to configure the built in reflective XSS protection found
|
||||
# - in Internet Explorer, Chrome and Safari (Webkit). Valid settings for the header
|
||||
# - are 0, which disables the protection, 1 which enables the protection
|
||||
# - and 1; mode=block which tells the browser to block the response if it
|
||||
# - detects an attack rather than sanitising the script.
|
||||
# -
|
||||
Header always set X-Xss-Protection "1; mode=block"
|
||||
|
||||
# - X-Content-Type-Options
|
||||
# -
|
||||
# - Nice and easy to configure, this header only has one valid value, nosniff.
|
||||
# - It prevents Google Chrome and Internet Explorer from trying to mime-sniff
|
||||
# - the content-type of a response away from the one being declared by the server.
|
||||
# - It reduces exposure to drive-by downloads and the risks of user uploaded content
|
||||
# - that, with clever naming, could be treated as a different content-type, like
|
||||
# - an executable.
|
||||
# -
|
||||
Header always set X-Content-Type-Options "nosniff"
|
||||
|
||||
# - Content Security Policy
|
||||
# -
|
||||
# - The CSP header allows you to define a whitelist of approved sources of content
|
||||
# - for your site. By restricting the assets that a browser can load for your site,
|
||||
# - like js and css, CSP can act as an effective countermeasure to XSS attacks. I
|
||||
# - have covered CSP in a lot more detail in my blog Content Security Policy - An
|
||||
# - Introduction (https://scotthelme.co.uk/content-security-policy-an-introduction/).
|
||||
# -
|
||||
# - Here is a basic policy to enforce TLS on all assets and prevent
|
||||
# - mixed content warnings.
|
||||
# -
|
||||
#
|
||||
Header always set Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'"
|
||||
|
||||
# - Referrer-Policy
|
||||
# -
|
||||
# - The HTTP referer (originally a misspelling of referrer[1]) is an HTTP header
|
||||
# - field that identifies the address of the webpage (i.e. the URI or IRI) that
|
||||
# - linked to the resource being requested. By checking the referrer, the new
|
||||
# - webpage can see where the request originated.
|
||||
# -
|
||||
Header set Referrer-Policy "strict-origin-when-cross-origin
|
||||
|
||||
CustomLog ${APACHE_LOG_DIR}/${WEBSITE_NAME}-access.log combined
|
||||
ErrorLog ${APACHE_LOG_DIR}/${WEBSITE_NAME}-error.log
|
||||
|
||||
@ -1283,7 +1505,79 @@ EOF
|
||||
fi
|
||||
cat <<EOF >> ${APACHE_VHOST_DIR}/${WEBSITE_NAME}.conf 2>> $log_file
|
||||
|
||||
SSLEngine on
|
||||
# ==========
|
||||
# - HTTP security Headers
|
||||
# ==========
|
||||
|
||||
# - X-Frame-Options
|
||||
# -
|
||||
# - The X-Frame-Options header (RFC), or XFO header, protects your visitors
|
||||
# - against clickjacking attacks. An attacker can load up an iframe on their
|
||||
# - site and set your site as the source, it's quite easy:
|
||||
# -
|
||||
# - <iframe src="https://scotthelme.co.uk"></iframe>
|
||||
# -
|
||||
# - Using some crafty CSS they can hide your site in the background and create some
|
||||
# - genuine looking overlays. When your visitors click on what they think is a harmless
|
||||
# - link, they're actually clicking on links on your website in the background. That
|
||||
# - might not seem so bad until we realise that the browser will execute those requests
|
||||
# - in the context of the user, which could include them being logged in and authenticated
|
||||
# - to your site!
|
||||
# -
|
||||
# - Troy Hunt has a great blog on 'Clickjack attack – the hidden threat right in front :
|
||||
# - of you':
|
||||
# -
|
||||
# - http://www.troyhunt.com/2013/05/clickjack-attack-hidden-threat-right-in.html
|
||||
# -
|
||||
# - Valid values include DENY meaning your site can't be framed, SAMEORIGIN which allows
|
||||
# - you to frame your own site or ALLOW-FROM https://example.com/ which lets you specify
|
||||
# -sites that are permitted to frame your own site.
|
||||
# -
|
||||
Header always set X-Frame-Options "SAMEORIGIN"
|
||||
|
||||
# - X-Xss-Protection
|
||||
# -
|
||||
# - This header is used to configure the built in reflective XSS protection found
|
||||
# - in Internet Explorer, Chrome and Safari (Webkit). Valid settings for the header
|
||||
# - are 0, which disables the protection, 1 which enables the protection
|
||||
# - and 1; mode=block which tells the browser to block the response if it
|
||||
# - detects an attack rather than sanitising the script.
|
||||
# -
|
||||
Header always set X-Xss-Protection "1; mode=block"
|
||||
|
||||
# - X-Content-Type-Options
|
||||
# -
|
||||
# - Nice and easy to configure, this header only has one valid value, nosniff.
|
||||
# - It prevents Google Chrome and Internet Explorer from trying to mime-sniff
|
||||
# - the content-type of a response away from the one being declared by the server.
|
||||
# - It reduces exposure to drive-by downloads and the risks of user uploaded content
|
||||
# - that, with clever naming, could be treated as a different content-type, like
|
||||
# - an executable.
|
||||
# -
|
||||
Header always set X-Content-Type-Options "nosniff"
|
||||
|
||||
# - Content Security Policy
|
||||
# -
|
||||
# - The CSP header allows you to define a whitelist of approved sources of content
|
||||
# - for your site. By restricting the assets that a browser can load for your site,
|
||||
# - like js and css, CSP can act as an effective countermeasure to XSS attacks. I
|
||||
# - have covered CSP in a lot more detail in my blog Content Security Policy - An
|
||||
# - Introduction (https://scotthelme.co.uk/content-security-policy-an-introduction/).
|
||||
# -
|
||||
# - Here is a basic policy to enforce TLS on all assets and prevent
|
||||
# - mixed content warnings.
|
||||
# -
|
||||
#
|
||||
Header always set Content-Security-Policy "default-src https: data: 'unsafe-inline' 'unsafe-eval'"
|
||||
|
||||
# - Referrer-Policy
|
||||
# -
|
||||
# - The HTTP referer (originally a misspelling of referrer[1]) is an HTTP header
|
||||
# - field that identifies the address of the webpage (i.e. the URI or IRI) that
|
||||
# - linked to the resource being requested. By checking the referrer, the new
|
||||
# - webpage can see where the request originated.
|
||||
# -
|
||||
Header set Referrer-Policy "strict-origin-when-cross-origin
|
||||
|
||||
# - HTTP Strict Transport Security (HSTS)
|
||||
# -
|
||||
@ -1295,6 +1589,8 @@ cat <<EOF >> ${APACHE_VHOST_DIR}/${WEBSITE_NAME}.conf 2>> $log_file
|
||||
# -
|
||||
Header always set Strict-Transport-Security "max-age=31536000"
|
||||
|
||||
SSLEngine on
|
||||
|
||||
SSLCertificateFile ${APACHE_CERT_DIR}/$APACHE_SERVER_CERT
|
||||
SSLCertificateKeyFile ${APACHE_CERT_DIR}/$APACHE_SERVER_KEY
|
||||
$SSLCertificateChainFile
|
||||
@ -1662,6 +1958,15 @@ cat <<EOF >>$WEBSITE_BASEDIR/roundcubemail-${ROUNDCUBE_VERSION}/config/config.in
|
||||
\$config['login_autocomplete'] = 1;
|
||||
|
||||
|
||||
// ----------------------------------
|
||||
// IMAP (further settings)
|
||||
// ----------------------------------
|
||||
|
||||
// IMAP AUTH type (DIGEST-MD5, CRAM-MD5, LOGIN, PLAIN or null to use
|
||||
// best server supported one)
|
||||
\$config['imap_auth_type'] = 'LOGIN';
|
||||
|
||||
|
||||
// ----------------------------------
|
||||
// USER PREFERENCES
|
||||
// ----------------------------------
|
||||
|
Loading…
Reference in New Issue
Block a user