Am 05.03.2020 08:12, schrieb Jürgen Göres:
Ghostcat is the name of a malware strain that has been around since at
least October last year. When referencing vulnerabilities it is best
to
stick to the CVE reference since they should be unique (and if
something
goes wrong and they aren't there are procedures to get them re-issued
so
they are).
we are using Tomcat 9.0.x and 8.5.x in our stack. We make use of the
AJP protocol since we use Apache HTTPD as reverse proxy and found it
to be mostly hazzle-free over the last few years, so we would like to
continue using it.
Since the HTTPD and the Tomcats are in general not on the same nodes,
the AJP connector has to listen on all interfaces.
My first question is: what value do I need to set in the "address"
attribute to indicate that I want the connector to listen on ALL
interfaces (for IPv4 AND IPv6)? Maybe that should be documented. :-)
It will vary by system. Some systems can't listen on both IPv4 and
IPv6
with a single socker. Usually either "::" or "0.0.0.0" will have the
desired result.
That is a bit of a problem for us. In the environments we support (Win
and Linux), from my observation the connectors would successfully bind
to both IPv4 and IPv6 addresses. Since we have customers that use
either IPv4, IPv6, or both and often have multiple interfaces on their
machines, we cannot know which address/interface (or even which IP
version) to bind to. And up to now, we didn't have to worry about it.
Now our installation routine would somehow need to find out whether it
should put a "::" or a "0.0.0.0" in the "address" attribute. What was
"zero conf" for us so far now suddently becomes a new source for
problems (=customer calls).
Is there no way to optionally configure the old binding behaviour for
the AJP connector?
Have you tried using either of the given configurations on your system?
I believe Thomas wanted to point out, that there are systems, that can't
bind to both, but that depends on your system, so we can't tell you, if
it works for you.
In my experience both of the configs will work and bind to both types
IPv4 and IPv6.
Felix
So the question is: is the root cause actually fixed?
Yes.
Great, thx. :-)
The very nature of the AJP protocol is such that clients have to be
trusted.
Tomcat trusts the "real" client IP address provided. That could be
used
for access control.
Tomcat may be configured to trust the authenticated user name
provided.
That almost certainly will then be used for access control.
So far, we had instructions for our customers to not expose the AJP
ports (or any other internal ports of other components in our stack).
However, I am pretty sure that there are installations out there where
these ports are exposed (hopefully only on the intranet).
In any case, we will update to the latest Tomcat version (but need to
find a way to solve the "to which interface should we bind" problem
without too much hazzle for customers), and in addition will also try
to use the "secret" approach to secure access to the AJP connectors,
so that even those customers that ignored the security guidelines will
not be affected by other possible attacks over the AJP protocol.
If it is, what is the recommended mitigation? We consider using the
"secret" feature (the filtering by request attributes is infeasible
for us), but that would be a bit of effort and we are in a hurry.
It would be unusual for an application to be using request attributes
directly. These have to be explicitly set in the reverse proxy and are
normally used for the reverse proxy to pass information to Tomcat
about
the client etc.
I was under the naive assumptions that "request attributes" meant
"HTTP request attributes". ;-)
If I understand you right here we are talking about attributes used in
the AJP protocol to convey info between reverse proxy and Tomcat.
Like info about the true client IP address (i.e., an AJP equivalent to
HTTP's X-Forwarded-For header).
- setting up a dedicated subnet for reverse proxy to Tomcat
communication;
- configuring a firewall on the Tomcat box to only accept connections
to the AJP port from specific hosts
That is what we advise our customers to do.
For any network configuration you can configure a shared secret for
the
reverse proxy workers and the AJP connector.
And since this is closest to "zero config" we can get, this is what we
will do on perspective.
Regards
JG
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
