- Add HTTP security headers to vhost configuration.

- Version to install is requested and no longer part of the configuration file.
This commit is contained in:
Christoph 2017-11-05 19:09:59 +01:00
parent a53d252d69
commit 7427ebec6b
2 changed files with 326 additions and 8 deletions

View File

@ -2,10 +2,6 @@
# - Configuration for postfixadmin install script
# -----------------------------------------------
# - Version of Postfix Admin
# -
PF_ADMIN_VERSION=
# - Name of the website - usualy 'webmail.<domain>.<tld>'
# -
WEBSITE_NAME=""

View File

@ -34,6 +34,13 @@ declare -A check_entry_main_cf_arr
# - Functions
# -------------
clean_up() {
# Perform program exit housekeeping
rm -f "$log_file"
exit $1
}
echononl(){
echo X\\c > /tmp/shprompt$$
if [ `wc -c /tmp/shprompt$$ | awk '{print $1}'` -eq 1 ]; then
@ -50,7 +57,7 @@ fatal(){
echo ""
echo -e "\t\033[31m\033[1mInstalllation wird abgebrochen\033[m\033[m"
echo ""
exit 1
clean_up 1
}
error(){
@ -151,6 +158,25 @@ else
echo_ok
fi
echo -e "\033[32m--\033[m"
echo ""
echo "Version of the Postfixadmin to install"
echo ""
echo ""
PF_ADMIN_VERSION=
while [ "X$PF_ADMIN_VERSION" = "X" ]
do
echononl "Postfixadmin Version: "
read PF_ADMIN_VERSION
if [ "X$PF_ADMIN_VERSION" = "X" ]; then
echo -e "\n\t\033[33m\033[1mA version number is required!\033[m\n"
fi
done
echo ""
echo -e "\033[32m--\033[m"
echo ""
# - Default values
@ -1130,6 +1156,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
@ -1197,7 +1297,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)
# -
@ -1209,6 +1381,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
@ -1233,6 +1407,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
@ -1301,7 +1549,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)
# -
@ -1313,6 +1633,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
@ -2956,7 +3278,7 @@ EOF
)"
echo ""
exit 0
clean_up 0
# =========================================================================================
# =========================================================================================