We are currently using the "standard" architecture created by AWS OpsWorks.
We have set up AWS ELB in front of multiple machines, which sends the requests to one machine using round-robin algorithm ( we have stateless application without any cookies ). Apache httpd + Apache tomcat is installed on every machine ( everything set up and configured by AWS OpsWorks ). So Apache httpd handles the connection and then sends it to Tomcat via AJP connection.
I would like to get rid of the apache httpd.
Few reasons for that:
Easier architecture, easier configuration
Maybe slight gain in performance
Less monitoring ( need to monitor only Tomcat, but not Apache httpd )
I have checked the following thread:
Why use Apache Web Server in front of Glassfish or Tomcat?
and haven't find any reasons why I shouldn't remove apache httpd from my architecture.
However, I know that some applications have nginx in front of the Tomcat for the following reasons:
Slow clients handling ( ie worker thread of tomcat is freed, but async nginx thread sends clients )
DDoS SYN ( using SYN cookies ) protection
Questions to consider:
Does apache httpd protects from these DDoS techniques?
Does AWS ELB protects from these DDoS techniques?
Should I remove apache httpd ( given that I don't need anything from the list )? Should I replace it with nginx? Should I replace it with nginx ( taking into account that we have a DDoS protection with Incapsula )?
Any other advice/comment would be highly appreciated!
Thank you in advance!
Does apache httpd protects from these DDoS techniques?
No apache httpd does not automatically protect from DDOS attack you have to enable and configure the security modules.
Does AWS ELB protects from these DDoS techniques?
AWS ELB features are High Availability, Health Checks, Security Features By managing associated security groups, SSL Offloading for encryption etc.No AWS ELB does not protect from the DDOS and DDoS techniques.
Should I remove apache httpd?
By using Apache HTTP as a front end you can let Apache HTTP act as a front door to your content to multiple Apache Tomcat instances. If one of your Apache Tomcats fails, Apache HTTP ignores it and your Sysadmin can sleep through the night. This point could be ignored if you use a hardware loadbalancer and Apache Tomcat's clustering capabilities. This option is when you are not using AWS ELB.
Should I replace it with nginx?
If you have Incapsula for DDOS there no need to complex the process by adding nginx.
Related
I'd like to know if is a good decision to configure tomcat through port 80 (in apache with virtual-hosts ).
I need to setup a tomcat service in the same server I have apache, plus I need to use Tomcat through port 80.
Is this right? or is best to use them in separated servers?
That's OK. But sometimes tomcat is deployed with Apache. The Apache is a front-end server to balance load. And many tomcats are as back-end servers.
We have a security requirement to configure SSL between tomcat and apache http server. I am using mod_jk for connection between httpd and tomcat servers.
I couldn't find the correct document which explains my situation. If anyone knows, pl. help me.
Short answer, you need to use the HTTP protocol instead of AJP.
HTTP supports encrypted communications (i.e. HTTPS), but AJP does not. If you want to stick with AJP, you'd need to use encryption at a lower level, like a VPN or encrypted tunnel, and then route your AJP traffic over the encrypted network.
If you switch to HTTP, you can use HTTPD, mod_proxy and mod_ssl to encrypt connections between HTTPD & Tomcat. The standard documentation on this is pretty good.
http://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypass
http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslproxyengine
For reasons we're not going to change, our application needs to handle the SSL connection, and not the ELB. The goal of using the Proxy Protocol is to get the client's IP address over an SSL connection.
http://aws.typepad.com/aws/2013/07/elastic-load-balancing-adds-support-for-proxy-protocol.html?ref_=9 indicates "Alternatively, you can use it if you are sending HTTPS requests and do not want to terminate the SSL connection on the load balancer. For more information, please visit the Elastic Load Balancing Guide."
Unfortunately, it appears the guide that's linked to doesn't actually elaborate on this, and the basic documentation for the Proxy Protocol ( http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/enable-proxy-protocol.html ) fails in our environment when configured as described.
Does anyone have steps or a link for this?
The proxy protocol (version 1) injects a single line into the data stream at the beginning of the connection, before SSL is negotiated by your server. You don't get this information "over" an SSL connection; you get the information prior to SSL handshaking. Your server has to implement this capability and specifically be configured so that it can accept and understand it. For an IPv4 connection, it looks like this:
PROXY TCP4 source-ip dest-ip source-port dest-port\r\n
The standard for the protocol is here:
http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt
Additional info in the ELB docs here:
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html#proxy-protocol
Regarding Apache support, at least at the time AWS announced support for the proxy protocol...
“neither Apache nor Nginx currently support the Proxy Protocol header inserted by the ELB”
— http://aws.typepad.com/aws/2013/07/elastic-load-balancing-adds-support-for-proxy-protocol.html?ref_=9
That is subject to change, of course, but I didn't successfully google for any Apache support of the proxy protocol. Of course, since Apache is open source, you could presumably hack it in there, though I am unfamiliar with the Apache source code.
Realizing that you don't want to change what you're doing now, I still would suggest that depending on your motivation for not wanting to change, there may still be a relatively simple solution. It's a change, but not involving SSL on ELB. What about running HAProxy behind ELB to terminate the SSL in front of Apache? Since HAProxy 1.5 can terminate SSL and appears to be able to translate the proxy protocol string from ELB into an X-Forwarded-For header, as well as generate X-SSL headers to give your application information about the client's SSL cert (perhaps that's your motivation for terminating SSL at the app server instead of on the ELB?) ... so this might be an alternative.
Otherwise, I don't have suggestions unless Apache implements support in the future, or we can find some documentation to indicate that they already have.
For the newer Network Load Balancers which allow your application servers to terminate the TLS connections, you can still get the real IP addresses of your clients and avoid all the work of configuring proxy protocol on the ELBs and in the web server config by simply configuring the target groups to use the servers' instance ids rather than their IP addresses. Regardless of which web server you use, the real IPs of the clients will show up in the logs with no translation needed.
Just to follow up on Michael - sqlbot's answer discussing the AWS support for proxy protocol on EC2 instances behind classic TCP elastic load balancers, the Apache module to use that implements the proxy protocol is mod_remoteip. Enabling it and updating the configuration properly will correct the problem of logging IP addresses of users rather than the elastic load balancer's IPs.
To enable proxy protocol on the elastic load balancer you could use these aws cli commands described in the aws documentation:
aws elb create-load-balancer-policy --load-balancer-name my-elb-name --policy-name my-elb-name-ProxyProtocol-policy --policy-type-name ProxyProtocolPolicyType --policy-attributes AttributeName=ProxyProtocol,AttributeValue=true
aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-elb-name --instance-port 443 --policy-names my-elb-name-ProxyProtocol-policy
aws elb set-load-balancer-policies-for-backend-server --load-balancer-name my-elb-name --instance-port 80 --policy-names my-elb-name-ProxyProtocol-policy
To enable use of proxy protocol in apache, in a server-wide or VirtualHost context, follow the mod_remoteip documentation such as below:
<IfModule mod_remoteip.c>
RemoteIPProxyProtocol On
RemoteIPHeader X-Forwarded-For
# The IPs or IP range of your ELB:
RemoteIPInternalProxy 192.168.1.0/24
# The IPs of hosts that may need to connect directly to the web server, bypassing the ELB (if applicable):
RemoteIPProxyProtocolExceptions 127.0.0.1
</IfModule>
You'll need to update the LogFormat wherever you have those defined (e.g. httpd.conf) to use %a rather than %h else the load balancer IP addresses will still appear.
JBoss Enterprise Application Platform 6.1 on Linux Enterprise Redhat
I have seen several examples on how to have Apache forward requests to JBoss. I am looking to have a JBoss server listening on port 80 forward cgi calls to an Apache server. Can JBoss be configured to listen at port 80 and forward all requests containing "cgi-bin" to port 8080 where Apache server is listening?
The need to do this arises from
Jboss not supporting cgi (mod_perl in my case) AFAIK
Since i am migrating from a server where all web requests used port 80, needing to keep the port as 80 to avoid programming changes
99% server calls are handled by JBoss, so i want it to be the primary point of contact
Despite JBoss handling the 99% of calls, the better architecture is to have Apache in front of JBoss.
You would have Apache serve port 80 and forward to JBoss via mod_cluster or mod_jk. This will allow you to control your content via Apache. You should serve your static content directly from Apache as well.
Additionally with this architecture, you can cluster your environment and load balance across multiple servers. This gives you higher fault tolerance (session replication, failover), handle more load, and helps you avoid server outages.
mod_cluster is recommended for EAP 6, but mod_jk works just fine too.
We want to front-end our Tomcat instance with an Apache instance (running on the same machine) that will be serving everything on HTTPS and connect Apache to Tomcat using AJP. When using AJP, do we need to do anything to make sure that the connection between Apache and Tomcat is secure? (We dont want passwords to be sniffable on the network between Apache and Tomcat). The O/S is Red Hat Enterprise Linux 6.3
You are saying
Tomcat instance with an Apache instance (running on the same machine)
and later you are saying
We dont want passwords to be sniffable on the network between Apache and Tomcat
This just contradicts each other.
EDIT: AJP is not designed to be secure, if you need security, use mod_proxy_http and proxy over https, or create SSH tunnel. Needless to say, you will have to pay for this overhead.
When using AJP you cannot do anything to ensure it is secure. It isn't. There is no SSL version. You would have to use HTTPS. AJP is designed for the usual case where HTTPD and Tomcat are in the same private LAN and security isn't an issue.