One additional note, that I didn't mention in the snippet: AJP This savesĪ lot of work writing an article myself - Big Win! :) I think I could get used to mentioning something to David. Establish firewall rules that only allow AJP connections from trusted hosts.If using AJP, update your Tomcat version to the newly updated ones with the patched AJP code.It's also a good idea to block external access to the port in case the AJP gets re-enabled accidentally in the future. If not using AJP, disable the AJP connection on port 8009 in server.xml.Since posting the blog, news of Ghostcat has been spreading: Įvery system admin, whether using AJP or not, needs to make changes in their environment: If you see Olaf out and about, you should thank him (as I do) for gathering this information for us. If you update your Tomcat server to 9.0.31 (or later), you are going to need to make some changes to the configuration for these new AJP updates.Ģ. So basically to continue to use AJP, you're going to be editing the default server.xml that Tomcat ships with to enable the connector, possibly bind to a network address (if HTTPd is on another server), plus include these attribute changes highlighted above.ġ. (markt)Ĭaused a few confusions that were discussed on the tomcat mailing list. Requests with unrecognised attributes will be blocked with a 403. Add a new attribute, allowedRequestAttributesPattern to the AJP/1.3 Connector.When secretRequired is true the AJP/1.3 Connector will not start unless the secret attribute is configured to a non-null, non-zero length String. Rename the requiredSecret attribute of the AJP/1.3 Connector to secret and add a new attribute secretRequired that defaults to true.Change the default bind address for the AJP/1.3 connector to be the loopback address.Disable (comment out in server.xml) the AJP/1.3 connector by default.Those who don't use AJP don't need to do anything, those that use AJP should notice this "secure by default" configuration and make sure that they don't open a security hole by re-enabling. Rather than rewording myself, I'm just going to quote Olaf since he did all of the work:Īs soon as our bundles are updated to Tomcat 9.0.31, note that there were some changes in the AJP Connectors that might disrupt people's expectation: They're disabled by default, and enabling them requires setting an interface explicitly, as well as a secret that must be shared with the reverse proxy. To me, these two things alone make AJP a clear win, even though it has the extra deployment and setup concerns. So you have to go through additional configuration to expose things like the incoming URL, the source IP address and port, etc. With the Proxy option, the request that Tomcat gets originates from the HTTPd server, not the remote client. So the source address, port, and other information are given to Tomcat as-is. Second, Tomcat sees the request as though it came straight through to Tomcat, without Apache HTTPd in the middle. Using AJP, the pre-parsed form is passed on to Tomcat for processing, unlike with the proxy method where Apache HTTPd is parsing, but then Tomcat also has to do the parsing again. The headers, cookies, parameters and other values in an HttpServletRequest? Those get parsed by Apache HTTPd already. So why does it make sense to try and pursue the AJP option?įirst, it's a connection leveraging a binary protocol. Oh, and Apache doesn't normally ship the AJP connector with HTTPd, so there's extra effort to get AJP connection going in your environment. Port 8080 is open and the default Tomcat port and it's why we all just spin up a Tomcat instance and will use 8080 in our browser URLs for testing.īecause this is just an OOTB configuration for both HTTPd and Tomcat, it is really an easy way to connect the two. I think typically you'll find most often that sys admins front tomcat with Apache HTTPd using mod_proxy, basically a mechanism where httpd accepts the incoming HTTP connection on port 80 and will proxy an HTTP request to tomcat running typically on port 8080. I'll present these shortly, but wanted to summarize first. There were also some changes to configuring AJP correctly. It was removed to prevent exposure as a security attack vector. Long story short, in Tomcat 9.0.31 (and onward), the AJP connector is not going to be enabled by default. I must say, though, that this is just a blog about Olaf's efforts, I'm now just playing Watson to his Holmes. Since I'm a big fan of using AJP to connect Apache HTTPd and Tomcat, I thought I'd share what he found with you. Update: What maybe we didn't know, Tomcat 9.0.31 (and other versions of Tomcat 6, 7, 8 and 8.5) were all being fixed to address a newly identified attack vector against Tomcat nicknamed Ghostcat: My friend, Olaf Kock, recently shared with me that he had struggled with and resolved an issue after moving to Tomcat 9.0.31 when using AJP.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |