Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE OpenStack Cloud 9

9 Preventing Host Header Poisoning Edit source

Depending on the environment and context of your SUSE OpenStack Cloud deployment, it may be advisable to configure horizon to protect against Host header poisoning (see ref. #1 below) by using Django's ALLOWED_HOSTS setting (see ref. #2 below). To configure horizon to use the ALLOWED_HOSTS setting, take the following steps:

  1. Edit the haproxy settings to reconfigure the health check for horizon to specify the allowed hostname(s). This needs to be done first, before configuring horizon itself. Otherwise, if horizon is first configured to restrict the values of the "Host" header on incoming HTTP requests, the haproxy health checks will start to fail. So, the haproxy configuration needs to be updated first, if this is being done on an existing installation.

    1. On your Cloud Lifecycle Manager node, make a backup copy of this file and then open /usr/share/ardana/input-model/2.0/services/horizon.yml

    2. Find the line that contains "option httpchk" and modify it so it reads the following way:

      - "option httpchk GET / HTTP/1.1\r\nHOST:\ my.example.com"
      # Note the escaped escape characters.

      In this example, my.example.com is the hostname associated with the horizon VIP on the external API network. However, you are not restricted to just one allowed host. In addition, allowed hosts can contain wildcards (though not in the horizon.yml file; there you must have an actual resolvable hostname or a routeable IP address). However, for this change to the haproxy healthcheck, it is suggested that the hostname associated with the horizon VIP on the external API network be used.

  2. Edit the template file that is used for horizon's local_settings.py configuration file.

    1. While still on your Cloud Lifecycle Manager node, open ~/openstack/my_cloud/config/horizon/local_settings.py.

    2. Change the line that sets the "ALLOWED_HOSTS" setting. This can be a list of hostnames and (V)IPs that eventually get routed to horizon. Wildcards are supported.

      ALLOWED_HOSTS = ['my.example.com', '*.example.net', '']

      In the above example, any HTTP request received with a hostname not matching any in this list will receive an HTTP 400 reply.

    3. Commit the change with a "git commit -a" command.

  3. Run the configuration processor

    cd ~/openstack/ardana/ansible
    ansible-playbook -i hosts/localhost config-processor-run.yml
  4. Enable the configuration: This can be done in one of a few ways: As part of a site deploy play, as part of an upgrade play, or by re-running the FND-CLU and horizon deploys on an existing deployment: If modifying an existing deploy, the FND-CLU deploy will need to be run first, since changing the ALLOWED_HOSTS setting in horizon first will cause the default health check to fail, if it does not specify a Host header in the HTTP request sent to check the health of horizon's Apache virtual host.

    cd ~/openstack/ardana/ansible
    ansible-playbook -i hosts/localhost ready-deployment.yml
    cd ~/scratch/ansible/next/ardana/ansible
    ansible-playbook -i hosts/verb_hosts horizon-deploy.yml
    ansible-playbook -i hosts/verb_hosts FND-CLU-deploy.yml


Print this page