How to disable Apache HTTP Header info in AWS Load Balancer Response? - apache

I have a node.js environment deployed using AWS Elastic Beanstalk on an Apache server. I have run a PCI scan on the environment and I'm getting 2 failures:
Apache ServerTokens Information Disclosure
Web Server HTTP Header Information Disclosure
Naturally I'm thinking I need to update the httpd.conf file with the following:
ServerSignature Off
ServerTokens Prod
However, given the nature of Elastic Beanstalk and Elastic Load Balancers, as soon as the environment scales, adds new servers, reboots etc the instance config will be overwritten.
I have also tried putting the following into an .htaccess file:
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule .* https://%{HTTP:Host}%{REQUEST_URI} [L,R=permanent]
# Security hardening for PCI
Options -Indexes
ServerSignature Off
# Dissallow iFrame usage outside of loylap.com for PCI Security Scan
Header set X-Frame-Options SAMEORIGIN
On the node js side I use the "helmet" package to apply some security measures, I also use the "express-force-https" package to ensure the application is enforcing https. However, these only seem to be taking effect after the Express application is initiated and after the redirect.
I have Elastic Load Balancer listeners set up for both HTTP (port 80) and HTTPS (port 443), however the HTTP requests are immediately routed to HTTPS.
When I run the following curl command:
curl -I https://myenvironment.com --head
I get an acceptable response with the following line:
Server: Apache
However when I run the same request on the http endpoint (i.e. before redirects etc):
curl -I http://myenvironment.com --head
I get a response that discloses more information about my server than it should, and hence the PCI failure:
Server: Apache/2.4.34 (Amazon)
How can I force my environment to restrict the http header response on HTTP as well as HTTPS?

Credit to #stdunbar for leading me to the correct solution here using ebextensions.
The solution worked for me as follows:
Create a file in the project root called .ebextensions/01_server_hardening.config
Add the following content to the file:
files:
"/etc/httpd/conf.d/03_server_hardening.conf":
mode: "000644"
owner: root
group: root
content: |
ServerSignature Off
ServerTokens Prod
container_commands:
01_reload_httpd:
command: "sudo service httpd reload"
(Note: the indentation is important in this YAML file - 2 spaces rather than tabs in the above code).
During elastic beanstalk deployment, that will create a new conf file in /etc/httpd/conf.d folder which is set up to extend the httpd.conf settings in ELB by default.
The content manually turns off the ServerSignature and sets the ServerTokens to Prod, achieving the PCI standard.
Running the container command forces a httpd reboot (for this particular version of Amazon linux - ubuntu and other versions would require their own standard reload).
After deploying the new commands to my EB environment, my curl commands run as expected on HTTP and HTTPS.

An easier and better solution exists now.
The folder /etc/httpd/conf.d/elasticbeanstalk is deleted when the built-in application server is restarted (e.g. when using EB with built-in Tomcat). Since .ebextensions are not re-run the above solution stop working.
This is only the case when the application server is restarted (through e.g. Lambda or the Elastic Beanstalk web-console). If the EC2 instance is restarted this is not an issue.
The solution is to place a .conf file in a sub-folder in the .ebextensions.
.ebextensions
httpd
conf.d
name_of_your_choosing.conf
Content of the file is the same as the output of the .ebextensions above, e.g.
ServerSignature Off
ServerTokens Prod
This solution will survive a restart of the application server and is much easier to create and manage.

You will ultimately need to implement some ebextensions to have this change applied to each of your Beanstalk instances. This is a mechanism that allows you to create one or more files that are run during the initialization of the beanstalk. I have an older one that I have not tested in your exact situation but it does the HTTP->HTTPS rewrite like you're showing. It was used in the Tomcat Elastic Beanstalk type - different environments may use different configurations. Mine looks like:
files:
"/tmp/00_application.conf":
mode: "000644"
owner: root
group: root
content: |
<VirtualHost *:80>
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R,L]
</VirtualHost>
container_commands:
01_enable_rewrite:
command: "echo 'LoadModule rewrite_module modules/mod_rewrite.so' >> /etc/httpd/conf/httpd.conf"
02_cp_application_conf:
command: "cp /tmp/00_application.conf /etc/httpd/conf.d/elasticbeanstalk/00_application.conf"
Again, this is a bit older and has not been tested for your exact use case but hopefully it can get you started.
This will need to be packaged with your deployment - i.e. in Java a .jar or .war or a .zip in other environments. Take a look at the documentation link to learn more about deployments.

There is a little change in configuration file path as AWS has introduced Amazon Linux 2
.ebextentions
.platform
httpd
conf.d
whateverFilenameyouwant.conf
in .platform/httpd/conf.d/whatever-File-NameYouWant.conf
add below two line
ServerSignature Off
ServerTokens Prod
Above is for Apache
Since AWS by default uses nginx for reverse proxy
replace httpd to nginx it should work

Related

How to proxy web requests to Lucee/Tomcat under Apache?

I'm having trouble setting Lucce to run on Apache in a CentOS 9 machine.
The steps I've followed are bellow:
Installed .run file from https://downloads.lucee.org
Left the default for apachectl, httpd conf and http modules (I've already checked and it seems they're correct, I can provide the values if you need)
Set Tomcat to run on port 8888, the default value (tomcat is in fact running because i can access it externally)
Accepted to install Apache connector
Accepted to install mod_cfml
Then, when Lucee is being installed, I get a post-install step error, mentioning that the installation may not complete correctly:
Error running /opt/lucee/sys/install_mod_proxy.sh -m install -t 8888 -f
/etc/httpd/conf/httpd.conf -c /usr/sbin/apachectl: apachectl: The "-M" option is
not supported.
apachectl: The "-M" option is not supported.
But the installation process ends and everything seems to be fine.
Tomcat is running (I can access through domain.com:8888)
Proxy is added to httpd.conf file with the following rules
<IfModule mod_proxy.c>
ProxyPreserveHost On
ProxyPassMatch ^/(.+\.cf[cm])(/.*)?$ http://127.0.0.1:8888/$1$2
ProxyPassMatch ^/(.+\.cfml)(/.*)?$ http://127.0.0.1:8888/$1$2
# optional mappings
#ProxyPassMatch ^/flex2gateway/(.*)$ http://127.0.0.1:8888/flex2gateway/$1
#ProxyPassMatch ^/messagebroker/(.*)$ http://127.0.0.1:8888/messagebroker/$1
#ProxyPassMatch ^/flashservices/gateway(.*)$ http://127.0.0.1:8888/flashservices/gateway$1
#ProxyPassMatch ^/openamf/gateway/(.*)$ http://127.0.0.1:8888/openamf/gateway/$1
#ProxyPassMatch ^/rest/(.*)$ http://127.0.0.1:8888/rest/$1
ProxyPassReverse / http://127.0.0.1:8888/
</IfModule>
mod_cfml is loaded in httpd.conf file
LoadModule modcfml_module modules/mod_cfml.so
CFMLHandlers ".cfm .cfc .cfml"
ModCFML_SharedKey "{{ shared_key_here }}"
LogHeaders false
LogHandlers false
LogAliases false
VDirHeader false
In the end I restarted Lucee and Apache services and created a index.cfm file in /var/www/html, but when I try o access it I get a 503 error.
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Catalina.out logs from tomcat and error_logs from apache dont give me any hints on whats happerning.
Can anyone point me any direction to solve this?
Any additional info you may need in order to help me fell free to ask.
Thanks.
So I found that my machine had SE (Security Enhanced) enabled, and there was a setting that prevented the request to be correctly proxied to tomcat, which is httpd_can_network_connect.
I had to run /usr/sbin/setsebool httpd_can_network_connect true in order to make it work, after this and restarting httpd service, everything was ok!

Apache as a proxy for multiple nginx servers

I'm starting from the bitnami jenkins stack. Everything is working perfectly with jenkins.
http://sample:8080/jenkins (works fine)
I'm trying to add additional directories to apache to proxy to nginx:
http://sample:8080/other_tool
I can get to the other_tool homepage, but references to that other tool break down because they are looking for http://sample:8080/relative_url rather than http://sample:8080/other_tool/relative_url
I can pull config settings from the necessary files as needed, but it is on an air-gapped network so wholesale posting would be a challenge
The apache conf looks like:
<Directory /other_tool>
ProxyPass http://localhost:9999
ProxyPassReverse http://localhost:9999
</Directory>
The nginx configuration is a standard "/" with root directory. I'm not as familiar with nginx so I can't recall the exact information off the top of my head. If needed I will provide it.
I could try to switch the jenkins hosting over to nginx, but I'm not sure that simplifies anything.
I can't open more ports on the machine. I can't use a subdomain as that would require additional DNS entries that I do not control.
Ideas or suggestions?

How to setup glassfish 4.1.1 behind apache on Ubuntu 16.04 server

I want to setup Apache and Glassfish on Ubuntu 16.04 server.
I have installed
apache2
libapache2-mod-jk
glassfish
The following are the steps I have followed
Configuring the MPM module
Set MaxRequestWorkers to 400 in /etc/apache2/mods-available/mpm_event.conf
Configuring the JK Module
<IfModule mod_jk.c>
JkWorkersFile /usr/share/glassfish4/glassfish/domains/<domain-doamin1>/config/workers.properties
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel error
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
JkRequestLogFormat "%w %V %T"
JkMountCopy all
</IfModule>
JkMount /myapp/* ajp13
<Location "/myapp/WEB-INF/">
require all denied
</Location>
Create a workers.properties file in your GlassFish domain's config directory
worker.list=ajp13
worker.ajp13.type=ajp13
worker.ajp13.host=localhost
worker.ajp13.port=8009
# load balancing only: worker.ajp13.lbfactor=50
connection_pool_size=10
connection_pool_timeout=600
worker.ajp13.socket_keepalive=False
worker.ajp13.socket_timeout=30
Create the JK listener in GlassFish using these commands
asadmin create-http-listener --listenerport 8009 --listeneraddress 0.0.0.0 --defaultvs server jk-listener
asadmin set server-config.network-config.network-listeners.network-listener.jk-listener.jk-enabled=true
then I restarted glassfish domain successfully but when i try to restart apache2 with sudo /etc/init.d/apache2 restart I get the error below
[....] Restarting apache2 (via systemctl): apache2.serviceJob for apache2.service failed because the control process exited with error code. See "systemctl status apache2.service" and "journalctl -xe" for details.
failed!
This error occurs when I edit the file jk.conf located under /etc/apache2/mods-available/jk.conf
Where am I going wrong. Is there a complete guide to accomplishing this? Finally the newer apache2 doesn't have the file httpd.conf and all the tutorials allover the Internet rely upon this file. Thanks in advance.
Since your objective is just to forward requests from Apache to GlassFish, not to loadbalance requests from Apache to multiple GlassFish servers, I would recommend avoiding mod_jk. You can certainly achieve your goal with it, but if you are new to the concepts involved, you will find it difficult to understand and maintain.
Instead you can use mod_proxy and, optionally, mod_proxy_ajp.
First, a definition:
AJP vs HTTP
AJP is a protocol like HTTP, but binary rather than text based. It has no secure/insecure options like HTTPS/HTTP since it is normally used behind a firewall and performs much better than HTTP for these scenarios. When you mark any GlassFish network listener as jk-enabled, you are enabling AJP communication, rather than HTTP.
You've installed Apache via the ubuntu apache2 package which has its own example structure to configuration which is different to the layout you would get if you downloaded and unzipped it. This has advantages, but we need to understand the Apache configuration file before getting to that.
Apache Configuration
Generally, you will see internet guides refer to httpd.conf as the configuration file to edit. This is just the default "parent" configuration file. In Debian/Ubuntu systems (and their derivations, like Linux Mint), the file to look for is apache2.conf.
This file is read, and its directives applied, from top to bottom, so if you have set the same property to two different values, the second will apply. (More accurately, they will both apply but the first will only apply until the second setting is read).
This file can also specifically "include" files and folders (where any *.conf file in an included folder will be included). These will be read in and merged with the main configuration at the point where the "include" statement is written. So the very last line in the main configuration file (if it is not specifying another file) will be the last line of configuration to be set, no matter what.
Debian config layout
I would highly recommend you read the opening comment in the apache2.conf file, since it will tell you all you need to know about the layout. Suffice it to say that keeping all the config in one file is very painful to maintain. The Debian package separates configuration into three categories:
sites
Sites are single configuration files for a website or web project. This could be anything: PHP, static HTML or a Java EE application deployed to an app server like GlassFish.
mods
Modules are subdivided into *.load files which load the actual libraries needed to run them, and *.conf files which have global configuration for the modules. Note that this configuration applies to every site that uses the module, so it is best to put any site/app specific module configuration in the appropriate site.conf file
conf
These files are just for any other general configuration which fits into a nice group. This could be SSL configuration like keystore and truststore locations.
When you look at the directory structure, you will see that each of these have 2 folders: *-available and *-enabled. This is because the Debian Apache package comes with 6 helper tools, a2ensite and a2dissite; a2enmod and a2dismod; a2enconf and a2disconf. The idea is that you follow these rules:
Never directly edit the apache2.conf file
only ever add or change files in the *-available folders
Use the helper tools to enable or disable sites/modules/conf files.
Answer
So to (finally) answer your question, I would do the following steps:
Enable mod_proxy_ajp
a2enmod mod_proxy_ajp
Create a new myApp.conf in sites-available. You can copy the default one, which is a good example. Assuming you have just want to forward all requests to GlassFish, you can use the default VirtualHost settings of ` which will process a request for any hostname on port 80. Use port 443 if you want to add HTTPS.
Add ProxyPass and ProxyPassReverse directives to the location of your server. If Apache and GlassFish are on the same server, it is likely you will want to use ajp://localhost:8080
ProxyPass / ajp://host_name:0000
ProxyPassReverse / ajp://host_name:0000
Note: This assumes you are using AJP. If that causes you problems, switch to HTTP by changing ajp to http above and disabling the jk-listener in GlassFish.
Once you have completed your myApp.conf configuration, remember to disable the default site:
a2dissite 000-default-site.conf
And enable your new site:
a2ensite myApp.conf
Those commands will appropriately modify the main apache2.conf and create the appropriate links in the sites-enabled folder.
That should be all you need. Now, everything that points to your hostname after the root / of the URL will be forwarded to the root context / of GlassFish.

Configure apache on elastic beanstalk

I'm developing with django on elastic beanstalk and I want to make two changes to apache configuration:
1.
redirect www.domain.com to domain.com
2.
redirect http://domain.com to https://domain.com
I don't have experience with apache configuration, googling it gave me the idea that I should put RewriteRules in .htaccess file.
example:
How to force https on amazon elastic beanstalk without failing the health check
I couldn't find instructions on how to do it with elastic beanstalk configuration (.ebextensions), I tried to simply put a .htaccess file in my root filder and deploy but it didn't work.
Does anyone know how it's possible to add the RewriteRules in elastic beanstalk?
Having www.example.com go to example.com can be done with a CNAME in DNS if you don't care about having it actually being a redirect. If you need a redirect, you can add it to the Apache config below. The primary point of this answer is to detail how you modify Apache config on Elastic Beanstalk (because doing this properly is not very straight forward).
This answer assumes you have already enabled https in the load balancer security group, added the SSL certificate to the load balancer, added 443 to the ports forwarded by the load balancer, and pointed your domain name at the Elastic Beanstalk environment with Route 53 (or equivalent DNS service).
Amazon Linux 2
Most AWS Linux version 2 based platforms have the option to pick Apache as your proxy host. This can be done by going to "Configuration" > "Software" >
"Container Options" and setting "Proxy Server" to "Apache", or adding the following to one of your .config files in .ebextensions:
option_settings:
aws:elasticbeanstalk:environment:proxy:
ProxyServer: apache
On AWS Linux 2, Apache is configured exclusively through adding files to your codebase in .plaform/httpd/conf.d/, from which they will get added to the server's Apache config. You can no longer edit Apache files through .ebextensions.
To do an HTTP to HTTPS redirect using Apache, add a configuration file named .platform/httpd/conf.d/ssl_rewrite.conf to your codebase (relevant AWS docs) with the following contents:
RewriteEngine On
<If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</If>
Note that nginx can be configured in a similar way, namely by adding a .conf file to .platform/nginx/conf.d/ (though the contents of this file will obviously be different).
Amazon Linux 1
All you need to do is add the following to one of your .config files in the .ebextensions directory of your project:
files:
"/etc/httpd/conf.d/ssl_rewrite.conf":
mode: "000644"
owner: root
group: root
content: |
RewriteEngine On
<If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</If>
Explanation
This is moderately straight forward outside of Elastic Beanstalk. One usually adds an Apache rewrite rule like the following:
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Or, if behind a load balancer, like we are in this case:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
However, these configurations only work within a <VirtualHost> block. Changing the RewriteCond to an <If> block allows it to work properly outside of a <VirtualHost> block, allowing us to put in in a standalone Apache config file. Note that standard Apache setup on CentOS (including the setup on ElasticBeanstalk) inculdes all files matching /etc/httpd/conf.d/*.conf, which matches the file path where we are storing this file.
The -n '%{HTTP:X-Forwarded-Proto}' part of the condition prevents it from redirecting if you are not behind a load balancer, allowing you to have shared configuration between a production evironment with a load balancer and https, and a staging environment that is single instance and does not have https. This is not necessary if you are using load balancers and https on all of your environments, but it doesn't hurt to have it.
Bad solutions I have seen
I have seen a lot of bad solutions to this problem, and it is worth going through them to understand why this solution is necessary.
Use Cloudfront: Some people suggest using non-cached Cloudfront setup in front of Elastic Beanstalk to do the HTTP to HTTPS redirect. This adds a whole new service (thus adding complexity) that isn't exactly appropriate (Cloudfront is a CDN; it's not the right tool for forcing HTTPS on inherantly dynamic content). Apache config is the normal solution to this problem and Elastic Beanstalk uses Apache, so that's the way we should go.
SSH into the server and...: This is completely antithetical to the point of Elastic Beanstalk and has so many problems. Any new instances created by autoscaling won't have the modified configuration. Any cloned environments won't have the configuration. Any number of a reasonable set of environment changes will wipe out the configuration. This is just such a bad idea.
Overwrite the Apache config with a new file: This is getting into the right realm of solution but leaves you with a maintenance nightmare if Elastic Beanstalk changes aspects of the server setup (which they very well may do). Also see the problems in the next item.
Dynamically edit the Apache config file to add a few lines: This is a decent idea. The problems with this is that it won't work if Elastic Beanstalk ever changes the name of their default Apache config file, and that this file can get overwritten when you least expect: https://forums.aws.amazon.com/thread.jspa?threadID=163369
this is an easy solution
ssh into your EC2 instance
copy the contents of /etc/httpd/conf.d/wsgi.conf into a local file called wsgi.conf which will be placed in the base folder of your application
Edit the local version of wsgi.conf and add the following redirect rules within the < VirtualHost> < /VirtualHost> tags
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule !/status https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301]
Change the “/status” to whatever page you are using as a health check page.
Save the file
Edit your < app>.conf file inside your .ebextensions directory to add a container command to copy this version of wsgi.conf over Amazon’s version
container_commands:
01_syncdb:
command: "django-admin.py syncdb --noinput" leader_only: true
02_collectstatic:
command: "django-admin.py collectstatic --noinput"
03_wsgireplace:
command: 'cp wsgi.conf /etc/httpd/conf.d/wsgi.conf'
...
Deploy the code.
The deployed version of wsgi.conf at /etc/httpd/conf.d/wsgi.conf will now include the necessary redirect rules.
It should work and the file will be properly updated for each deployment. The only thing to watch for is if Amazon changes their base wsgi.conf file contents in the future, then your copy may no longer work.
Source : rickchristianson
This is very well explained in AWS documentation as below:
To extend the Elastic Beanstalk default Apache configuration, add .conf configuration files to a folder named .ebextensions/httpd/conf.d in your application source bundle. The Elastic Beanstalk Apache configuration includes .conf files in this folder automatically.
~/workspace/my-app/
|-- .ebextensions
| -- httpd
| -- conf.d
| -- myconf.conf
| -- ssl.conf
-- index.jsp
To override the Elastic Beanstalk default Apache configuration completely, include a configuration in your source bundle at .ebextensions/httpd/conf/httpd.conf.
~/workspace/my-app/
|-- .ebextensions
| `-- httpd
| `-- conf
| `-- httpd.conf
`-- index.jsp
If you override the Elastic Beanstalk Apache configuration, add the following lines to your httpd.conf to pull in the Elastic Beanstalk configurations for Enhanced health reporting and monitoring, response compression, and static files.
IncludeOptional conf.d/*.conf
IncludeOptional conf.d/elasticbeanstalk/*.conf
Note
To override the default listener on port 80, include a file named
00_application.conf at
.ebextensions/httpd/conf.d/elasticbeanstalk/ to overwrite the
Elastic Beanstalk configuration.
For a working example, take a look at the Elastic Beanstalk default configuration file at /etc/httpd/conf/httpd.conf on an instance in your environment. All files in the .ebextensions/httpd folder in your source bundle are copied to /etc/httpd during deployments.
Further details can be seen on this link under Extending and overriding the default Apache configuration. Better to use correct approach instead of patches or workarounds.
Just for reference for others, using Zags' solution to redirect non-www to www, add this to your .ebextensions/your_file.config:
files:
"/etc/httpd/conf.d/www_rewrite.conf":
mode: "000644"
owner: root
group: root
content: |
RewriteEngine On
<If "'%{HTTP_HOST}' !~ /^www\./">
RewriteRule ^(.*)$ http://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</If>

How to force https on elastic beanstalk?

I can't seem to force https on the free usage tier of elastic beanstalk.
I have tried the following suggestion at How to force https on amazon elastic beanstalk without failing the health check
Using this Apache rewrite rule
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{REQUEST_URI} !^/status$
RewriteCond %{REQUEST_URI} !^/version$
RewriteCond %{REQUEST_URI} !^/_hostmanager/
RewriteRule . https://%{SERVER_NAME}%{REQUEST_URI} [L,R]
When I try that, http requests do not get redirected to https as I would like. Instead, the http page loads normally. I've also tried to use the X-Forwarded-Port header with the same result.
I've also tried the following rewrite rule
RewriteCond %{SERVER_PORT} 80
RewriteRule . https://%{SERVER_NAME}%{REQUEST_URI} [L,R]
And this rule causes a redirect loop. So it would seem that the apache rewrite rules don't pick up the Elastic Load Balancer headers X-Forwarded-Port and X-Forwarded-Proto, but also a redirect loop isn't what I am going for either.
Please help. I am new to AWS, Elastic Beanstalk, and not very familiar with Apache rules. I am not too sure where to go from here. Thanks.
This answer assumes you have already enabled https in the load balancer security group, added the SSL certificate to the load balancer, have both ports 80 and 443 being forwarded by the load balancer, and pointed your domain name at the Elastic Beanstalk environment with Route 53 (or equivalent DNS service).
Option 1: Do the redirect with Apache
This is only possible if you are on an Elastic Beanstalk environment that uses Apache (AWS Linux 2 based deployments can be configured to use Apache). It may not work for a docker-based deployment.
Amazon Linux 2
Most AWS Linux version 2 based platforms have the option to pick Apache as your proxy host. This can be done by going to "Configuration" > "Software" >
"Container Options" and setting "Proxy Server" to "Apache", or adding the following to one of your .config files in .ebextensions:
option_settings:
aws:elasticbeanstalk:environment:proxy:
ProxyServer: apache
Having done that, add a configuration file named .platform/httpd/conf.d/ssl_rewrite.conf to your codebase (relevant AWS docs) with the following contents:
RewriteEngine On
<If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</If>
Amazon Linux 1
All you need to do is add the following to one of your .config files in the .ebextensions directory of your project:
files:
"/etc/httpd/conf.d/ssl_rewrite.conf":
mode: "000644"
owner: root
group: root
content: |
RewriteEngine On
<If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
</If>
Explanation
This is moderately straight forward outside of Elastic Beanstalk. One usually adds an Apache rewrite rule like the following:
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
Or, if behind a load balancer, like we are in this case:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
However, these configurations only work within a <VirtualHost> block. Changing the RewriteCond to an <If> block allows it to work properly outside of a <VirtualHost> block, allowing us to put in in a standalone Apache config file. Note that standard Apache setup on CentOS (including the setup on ElasticBeanstalk) inculdes all files matching /etc/httpd/conf.d/*.conf, which matches the file path where we are storing this file.
The -n '%{HTTP:X-Forwarded-Proto}' part of the condition prevents it from redirecting if you are not behind a load balancer, allowing you to have shared configuration between a production evironment with a load balancer and https, and a staging environment that is single instance and does not have https. This is not necessary if you are using load balancers and https on all of your environments, but it doesn't hurt to have it.
Option 2: Do the redirect with the ALB
This is only possible if you are using an Application Load Balancer. Amazon has instructions for how to do that here: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/configuring-https-httpredirect.html
All you need to do is add the following to one of your .config files in the .ebextensions directory of your project to replace the http listener with a redirect:
Resources:
AWSEBV2LoadBalancerListener:
Type: AWS::ElasticLoadBalancingV2::Listener
Properties:
LoadBalancerArn:
Ref: AWSEBV2LoadBalancer
Port: 80
Protocol: HTTP
DefaultActions:
- Type: redirect
RedirectConfig:
Host: "#{host}"
Path: "/#{path}"
Port: "443"
Protocol: "HTTPS"
Query: "#{query}"
StatusCode: "HTTP_301"
Bad solutions I have seen
I have seen a lot of bad solutions to this problem, and it is worth going through them to understand why this solution is necessary.
Use Cloudfront: Some people suggest using non-cached Cloudfront setup in front of Elastic Beanstalk to do the HTTP to HTTPS redirect. This adds a whole new service (thus adding complexity) that isn't exactly appropriate (Cloudfront is a CDN; it's not the right tool for forcing HTTPS on inherantly dynamic content). Apache config is the normal solution to this problem and Elastic Beanstalk uses Apache, so that's the way we should go.
SSH into the server and...: This is completely antithetical to the point of Elastic Beanstalk and has so many problems. Any new instances created by autoscaling won't have the modified configuration. Any cloned environments won't have the configuration. Any number of a reasonable set of environment changes will wipe out the configuration. This is just such a bad idea.
Overwrite the Apache config with a new file: This is getting into the right realm of solution but leaves you with a maintenance nightmare if Elastic Beanstalk changes aspects of the server setup (which they very well may do). Also see the problems in the next item.
Dynamically edit the Apache config file to add a few lines: This is a decent idea. The problems with this is that it won't work if Elastic Beanstalk ever changes the name of their default Apache config file, and that this file can get overwritten when you least expect: https://forums.aws.amazon.com/thread.jspa?threadID=163369
EDIT: While I love this answer, it is now very old. AWS has come up with new services (like Certificate Manager) that make part of this answer obsolete. Additionally, using the .ebextensions folder with Apache is a cleaner way to handle this redirect as explained above.
If you are hosting your website on S3, parts of this answer may still be useful to you.
This worked for me:
Upload the certificate to AWS using the aws console command. The command structure is:
aws iam upload-server-certificate --server-certificate-name CERTIFICATE_NAME --certificate-body "file://PATH_TO_CERTIFICATE.crt" --private-key "file://YOUR_PRIVATE_KEY.pem" --certificate-chain "file://YOUR_CERTIFICATE_CHAIN.ca-bundle" --path /cloudfront/
In your Elastic Beanstalk application, go to Configuration -> Network Tier -> Load Balancing and click the gear icon.
Select Secure listener port as 443. Select Protocol as HTTPS. Select the CERTIFICATE_NAME from step 2 for SSL certificate ID. Save the configuration.
Go to your Console. Click EC2 Instances. Click Load Balancers. Click through the load balancers. Click Instances and scroll down to see the EC2 instances assigned to that load balancer. If the EC2 instance has the same name as your Application URL (or something close), take note of the DNS Name for the load balancer. It should be in the format awseb-e-...
Go back to your Console. Click CloudFront. Click Create Distribution. Select a Web distribution.
Set up the distribution. Set your Origin Domain Name to the load balancer DNS name you found in step 5. Set the Viewer Protocol Policy to Redirect HTTP to HTTPS. Set Forward Query Strings to Yes. Set Alternate Domain Names (CNAMEs) to the URL(s) you want to use for your application. Set SSL Certificate to the CERTIFICATE_NAME you uploaded in step 2. Create your distribution.
Click on your distribution name in CloudFront. Click Origins, select your origin, and click Edit. Ensure your Origin Protocol Policy is Match Viewer. Go back. Click Behaviors, select your origin, and click Edit. Change Forward Headers to Whitelist and add Host. Save.
Note: I wrote a longer guide as well.
With the new Application Load Balancers you can do this fairly trivially now...
Ensure you setup one of these at the time you setup an EB environment (still defaults to classic load balancer I believe). You could not change the type once the environment is created, so recreate it
Once this is done, go to your EC2 settings -> Load Balancers. Click on the load balancer you created for your EB environment.
You must ensure that you have setup a HTTPS listener prior to this task so make sure you listen on HTTPS 443 with an SSL cert and forward traffic to your instances with HTTP on 80.
Then add a new listener which listens on HTTP and add a default action of "Redirect to:". Make sure you set HTTPS as the protocol, 443 as the port, "Original host, path, query" as the option and finally 301 as the HTTP response code.
Once this listener is added ensure that you update your EC2 Load Balancer security group to accept both HTTPS and HTTP connections, you will see small warning sign on the listener to remind you!
Chris
The most upvoted doesn't work for me.. the <If> directive only works with Apache 2.4+, but ElasticBeanstalk has version 2.2.x.
So, following the same advice as above. Create a file called .ebextensions/https_rewrite.config with the following content
files:
"/etc/httpd/conf.d/ssl_rewrite.conf":
mode: "000644"
owner: root
group: root
content: |
LoadModule rewrite_module modules/mod_rewrite.so
RewriteEngine On
# This will enable the Rewrite capabilities
RewriteCond %{HTTPS} !=on
# This checks to make sure the connection is not already HTTPS
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
This seems to work for me.
On how to build this file into your WAR file, see this answer
Edit: Zags solution is more general and correct. I recommend it over mine (which is specific to a python env)
Here's a clean and quick solution that I came up with that avoids hacking wsgi.conf or using CloudFront
In your .ebextensions/some_file.config:
# Redirect HTTP to HTTPS
"/etc/httpd/conf.d/https_redirect.conf":
mode: "000644"
owner: root
group: root
content: |
<Directory /opt/python/current/app/>
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} ^http$
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</Directory>
I feel like this is too easy, but seems to be working fine.
Also note that I am explicitly redirecting HTTP instead of "not HTTPS".
I am trying to redirect an elastic beanstalk with loadbalancer in 2018. None of the above answers works in my environment. Several issues I encoutered:
I was trying the most voted answer, but my tomcat is version 2.7. It does not support .
I was using container_commands and copy the 00_applications setting. AWS simply ignores it.
So finally I got it working by reading this:
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/java-tomcat-proxy.html
Here is what I do:
I recreated the folder structure:
.ebextensions
- httpd
-conf.d
-ssl.conf
And then this is the content of ssl.conf
<VirtualHost *:80>
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
<Proxy *>
Order Allow,Deny
Allow from all
</Proxy>
ProxyPass / http://localhost:8080/ retry=0
ProxyPassReverse / http://localhost:8080/
ProxyPreserveHost on
ErrorLog /var/log/httpd/elasticbeanstalk-error_log
</VirtualHost>
Hope this will help.
It's work for me with the next command:
RewriteCond %{HTTP:X-Forwarded-Port} !=443
and without the https check:
RewriteCond %{HTTP:X-Forwarded-Proto} !https
It's look like ELB change the value of X-Forwarded-Proto to http (even on TCP protocol).
None of the above answers worked for me but some helped me to figure out the answer that worked for me
Also I found the below url which helped
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/java-tomcat-platform.html
I created the file structure mentioned in above url to change 2 files
httpd.conf
00_application.conf
copy the whole httpd.conf from your instance and put it in your code under .ebextention under the folder structure mentioned in the above link. Then just add below line to that file in your project
LoadModule rewrite_module modules/mod_rewrite.so
Do that same for 00_application.conf, copy it from your instance and place it in your codebase under .ebextention under httpd/conf.d/elasticbeanstalk/00_application.conf
Now edit this file and add the below between VirtualHost
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Now deploy your code
It should work.
On elastic beanstalk you can just add your on configuration so that AWS overwrite their, it will allow you to overwrite the web-server configuration and submit your own configuration.
Simply add the following file under the path: .ebextensions\httpd\conf.d
File content:
<VirtualHost *:80>
LoadModule rewrite_module modules/mod_rewrite.so
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTP_USER_AGENT} !ELB-HealthChecker
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / http://localhost:8080/ retry=0
ProxyPassReverse / http://localhost:8080/
ProxyPreserveHost on
ErrorLog /var/log/httpd/elasticbeanstalk-error_log
</VirtualHost>
The '.ebextensions' is the standard configuration folder in AWS and the rest just point to which file and folder you wish to overwrite.
If the file or folder doesn't exist simple create them.
I had a difficult time figuring this out so after I came up with a solution I wrote a detailed explanation of my solution to hopefully help someone else. This is specific to Tomcat 8, Apache2, and Spring Boot app. There are really useful ebextension examples in the AWS labs github.
Summary of what worked for me:
Create a file at /src/main/webapp/.ebextensions/httpd/conf.d/elasticbeanstalk.conf
Add rewrite conds/rules being careful to include "LoadModule rewrite_module modules/mod_rewrite.so"
Deploy to AWS EBS
Here is an example Spring Boot app.
I have following configurations for elastic beanstalk (64bit Amazon Linux 2016.09 v2.3.1 running Tomcat 8 Java 8).
I created a directory .ebextensions and added a .config YAML file with the rewrite conditions
Zagas solution described above (which is very complex) doesn't work for me.
Because "If" condition is unknown
Because of Apache 2.2 I don't have mod_rewrite.so included in my httpd.conf file
This solution make more sense for me, but also this doesn't work. Nothing happens, and I cannot see file "ssl_rewrite.conf" under "conf.d" directory.
Third tried solution was to add "run.config" and "ssl_rewrite.conf" files under ".ebextendsion" directory.
run_config contains
container_commands:
copy-config:
command: "cp .ebextensions/ssl_rewrite.conf /etc/httpd/conf.d"
ssl_rewrite.conf contains
LoadModule rewrite_module modules/mod_rewrite.so
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule . https://%{HTTP:Host}%{REQUEST_URI} [L,R=permanent]
ssl_rewrite.conf is created under "conf.d" direcotry but redirect from http to https doesn't work.
The only worked solution for me was to add the following lines in "/etc/httpd/conf.d/elasticbeanstalk/00_application.conf"
<VirtualHost *:80>
......
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
......
</VirtualHost>
but this is a temporary solution and if a machine is replaced my https redirection is gone.
Just in case anybody is still struggling:
I've struggled for some time and finally, I've found a GitHub (from AWS team) with all AWS configs and the example below works for the HTTP>HTTPS redirection for Apache 2.2. (For configs for Apache 2.4 and Nginx please see the link below).
Apache 2.2
Create a file in the root directory of your app:
YOUR_PROJECT_ROOT/.ebextensions/httpd/conf.d/elasticbeanstalk.conf
(In case of using IntelliJ / Java make sure it go added to the final .WAR artifact)
Add the following lines to enable the redirection in the virtual host:
<VirtualHost *:80>
LoadModule rewrite_module modules/mod_rewrite.so
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTP_USER_AGENT} !ELB-HealthChecker
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / http://localhost:8080/ retry=0
ProxyPassReverse / http://localhost:8080/
ProxyPreserveHost on
ErrorLog /var/log/httpd/elasticbeanstalk-error_log
</VirtualHost>
For more examples for Apache 2.4 and Nginx please visit this GitHub repository:
https://github.com/awsdocs/elastic-beanstalk-samples/tree/master/configuration-files/aws-provided/security-configuration/https-redirect/java-tomcat
Also, there is plenty more useful configuration and examples available.
Regards
Enabling HTTPS through an environment variable
I needed to enforce HTTPS only for our production environment, and not for the development and staging ones which are also on Elastic Beanstalk but do not use a load balancer (and therefore cannot be assigned a certificate directly).
I use an environment variable USE_HTTPS. We copy the the ssl_rewrite.conf file if and only if USE_HTTPS is set to true.
.ebextensions/files/ssl_rewrite.conf
RewriteEngine On
<If "-n '%{HTTP:X-Forwarded-Proto}' && %{HTTP:X-Forwarded-Proto} != 'https'">
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</If>
.ebextensions/https.config
files:
"/home/ec2-user/https_setup.sh":
mode: "000755"
owner: root
group: root
content: |
#!/bin/bash
echo "USE_HTTPS env var: ${USE_HTTPS,,}"
outfile=/etc/httpd/conf.d/ssl_rewrite.conf
if [ "${USE_HTTPS,,}" == "true" ]; then
echo "Configure SSL rewrite"
cp .ebextensions/files/ssl_rewrite.conf $outfile
chmod 644 $outfile
chown root:root $outfile
else
[ -f $outfile ] && rm $outfile
echo "Do not use SSL"
exit 0
fi
container_commands:
01_https_setup:
command: "/home/ec2-user/https_setup.sh"
Note that if you change USE_HTTPS, you need to redeploy your application for the change to take effect. You can also remove the echo commands in the https.config file if you wish.
AWS has also some documentation on this.
If you're using an application load balancer, add the file http-to-https.config to your .ebextensions folder and then add the following config (Don't forget to put in the ARN of your https certificate):
NOTE: Please be sure that you haven't yet added a listener on port 443 via the EB console. If you did so, delete the listener before adding the .config file.
Resources:
AWSEBV2LoadBalancerListener:
Type: 'AWS::ElasticLoadBalancingV2::Listener'
Properties:
DefaultActions:
- Type: redirect
RedirectConfig:
Protocol: HTTPS
Port: '443'
Host: '#{host}'
Path: '/#{path}'
Query: '#{query}'
StatusCode: HTTP_301
LoadBalancerArn:
Ref: AWSEBV2LoadBalancer
Port: 80
Protocol: HTTP
AWSEBV2LoadBalancerListenerHTTPS:
Type: 'AWS::ElasticLoadBalancingV2::Listener'
Properties:
Certificates:
- CertificateArn: Replace with Certificate ARN
DefaultActions:
- Type: forward
TargetGroupArn:
Ref: AWSEBV2LoadBalancerTargetGroup
LoadBalancerArn:
Ref: AWSEBV2LoadBalancer
Port: 443
Protocol: HTTPS
The advantage of using your LB for this is that your config will be agnostic to the server you use like nginx, apache, etc.
I found an answer from here to be helpful.
All I did was make the health check path /index.php instead of / in the application load balancer default process.
Why don't you simply put an .htaccess file in the root folder? That way you can simply test and debug it. And if you include it in the .zip, it will automatically deployed on all instances again.
Simply use .htaccess:
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
Please note that the most voted answer is a bit old now.
The answer by A Paul is actually the correct answer. The link provided in his answer is by AWS (so it is the recommended method to override your Apache configuration to make the redirection from HTTP to HTTPS when running your application on Elastic Beanstalk).
There is one very important thing to note. If you are deploying more than 1 web app, then adding the .ebextensions folder inside one of your web app is not going to work. You will notice that Non of the configurations you specified are being written or created. If you are deploying multiple Web Apps on Elastic Beanstalk environment, then you will need to read this article by AWS
Java Tomcat Deploy Multiple WAR files on Elastic Beanstalk
In general, you will need to have the following structure before you issue the eb command on it to deploy the WAR files:
MyApplication.zip
├── .ebextensions
├── foo.war
├── bar.war
└── ROOT.war
if .ebextentions folder exists inside each WAR file, then you will notice that it is completely ignored and no configuration changes will be performed.
Hope this helps someone else.
We have solved it on our backend by handling X-Forwarded-Proto properly.
This is our Grails config but it will help you with the idea:
grails.plugin.springsecurity.secureChannel.useHeaderCheckChannelSecurity = true
grails.plugin.springsecurity.portMapper.httpPort = 80
grails.plugin.springsecurity.portMapper.httpsPort = 443
grails.plugin.springsecurity.secureChannel.secureHeaderName = 'X-Forwarded-Proto'
grails.plugin.springsecurity.secureChannel.secureHeaderValue = 'http'
grails.plugin.springsecurity.secureChannel.insecureHeaderName = 'X-Forwarded-Proto'
grails.plugin.springsecurity.secureChannel.insecureHeaderValue = 'https'
grails.plugin.springsecurity.secureChannel.definition = [
[pattern: '/**', access: 'REQUIRES_SECURE_CHANNEL']
]
To extend another two answers to this question https://stackoverflow.com/a/43026082/8775205, https://stackoverflow.com/a/42035023/8775205.
For spring boot users who deploy their services on AWS with ELB, and need step by step guide, you can add an ****.conf file under src/main/webapp/.ebextensions/httpd/conf.d/ in your project.
src
--main
----java
----resources
----webapps
------.ebextensions
--------httpd
----------confd
------------****.conf
****.conf looks like the following. Noticed that I have my testing site with a single instance, so I add a condition to exclude it.
<VirtualHost *:80>
LoadModule rewrite_module modules/mod_rewrite.so
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTP_USER_AGENT} !ELB-HealthChecker
RewriteCond %{HTTP_HOST} !testexample.com #excludes test site
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / http://localhost:8080/ retry=0
ProxyPassReverse / http://localhost:8080/
ProxyPreserveHost on
ErrorLog /var/log/httpd/elasticbeanstalk-error_log
</VirtualHost>
After this, remember to add a "resource" under maven-war-plugin in your pom.xml in order to pick up the above configuration.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webResources>
<resource>
<!-- some other resource configured by yourself-->
</resource>
<resource>
<directory>src/main/webapps/.ebextensions</directory>
<targetPath>.ebextensions</targetPath>
<filtering>true</filtering>
</resource>
</webResources>
</configuration>
<version>2.1.1</version>
</plugin>
Finally commit and push your code, wait AWS codebuild and codepipeline to pick up your code from your repository and deploy to beanstalk environment, or simply pack your project into a war file and upload it to your AWS beanstalk environment
AWS do not accept unserscores (_) in headders, while we can use (-), So Remove underscores from the header variables, example:- header_var_val = "some value" replace it with headervarval = "some value". It works for me.
All of the above answers are outdated in 2022, since AWS made silent changes to ElasticBeanstalk without updating the documentation properly.
However it has become very simple to do it from the AWS console when using a load balancer. You just need to disable the listener on the 80 port (http) once you created the https listener (environment -> configuration -> load balancer). And that's it.
No more problem with health checks since they are performed directly on the instance, not on the load balancer.
If you use a Load Balanced environment you can follow the instructions for Configuring HTTPS for your AWS Elastic Beanstalk Environment and at the end disable the HTTP port.
Note that currently the AWS Free Usage Tier includes the same amount of hours for an Elastic Load Balancing (ELB) as for an EC2 Micro Instance.
this is an easy solution
ssh into your EC2 instance
copy the contents of /etc/httpd/conf.d/wsgi.conf into a local file called wsgi.conf which will be placed in the base folder of your application
Edit the local version of wsgi.conf and add the following redirect rules within the < VirtualHost> < /VirtualHost> tags
RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule !/status https://%{SERVER_NAME}%{REQUEST_URI} [L,R=301]
Change the “/status” to whatever page you are using as a health check page.
Save the file
Edit your < app>.conf file inside your .ebextensions directory to add a container command to copy this version of wsgi.conf over Amazon’s version
container_commands:
01_syncdb:
command: "django-admin.py syncdb --noinput" leader_only: true
02_collectstatic:
command: "django-admin.py collectstatic --noinput"
03_wsgireplace:
command: 'cp wsgi.conf ../wsgi.conf'
...
Deploy the code.
The deployed version of wsg.conf at /etc/httd/conf.d/wsgi.conf will now include the necessary redirect rules.
It should work and the file will be properly updated for each deployment. The only thing to watch for is if Amazon changes their base wsgi.conf file contents in the future, then your copy may no longer work.
Autor rickchristianson