Mark, Robert, et al,
On 9/5/23 11:26, Mark Thomas wrote:
I spoke to some CIS representatives at a recent conference given that I
have concerns about the quality of some of the recommendations.
It appears that these benchmarks are effectively crowdsourced. My
primary concern is that there is no validation of the resulting
recommendations so they run the risk of reinforcing current widespread
bad practice as well as good practice.
This is interesting information. Lore really isn't a good source of
security information. :( It makes me wonder why they are charging for
that kind of information if it's basically the output of an internet
search for "how do i secure a Tomcat installation".
Regarding the suggestion to edit the contents of a JAR, that is a bad
idea on so many levels.
+1
Assuming that you are using signed JAR files, what you end up with is a
JAR whose signature can no longer be validated. This would require that
you disable JAR signing, which is probably another no-no when it comes
to security -- and I'd agree -- if you have signed JARs you ought to be
validating them. Another option would be to re-sign the modified JAR
file with an internal certificate but that can present its own
challenges. Most dev teams would just implement some kind of lazy
auto-signing process with the cert and key sitting right on the server
where it's being used, and at that point you are giving an attacker
everything they need to work-around your security controls.
I'd argue that rather than spending time hiding the current Tomcat
version - which is nothing more than security by obscurity - system
admins should be investing time in an update process that allows easy
updates (and roll-backs) to the Tomcat version. You only need to hide
the version number if you aren't on top of your security updates. And if
you aren't on top of your security updates you have bigger problems than
needing to hide the version number.
+1
https://tomcat.apache.org/presentations.html#latest-split-installation
If you find you need to hide this version number to appease auditors -
and using smarter auditors isn't an option - then there are a range of
options as set out in the Tomcat 8.5 security guide. That guide also
provides the correct way to override the version number (if you really
need to) without editing the JAR contents. In short, you can simply
override the individual file by placing at the right place in the file
system:
$CATALINA_BASE/lib/org/apache/catalina/util/ServerInfo.properties
+1
The only argument /against/ doing that in the past that I've ever seen
was that they "didn't want to pollute [their] Tomcat installation" which
is crazy when the alternative is to alter a signed JAR provided by a
trusted vendor.
This is also probably worth a read:
https://cwiki.apache.org/confluence/display/TOMCAT/Community+Review+of+DISA+STIG
I would bet that many of the items listed here have overlap with some of
the more dubious items coming from CIS.
Hope that helps,
-chris
On 05/09/2023 14:54, Robert Turner wrote:
Thanks Peter. Just to be clear that I have no concern about the goal
of the
test -- only the method for obtaining the information, and the "implied"
correction.
After going through the rest of the document I was provided, it seems to
"get more modern" as the questions go on -- suggesting the method of
improvement is additive, and possibly not corrective.
Improvements are definitely corrective as well as additive. Early
versions of the guide had very odd advice regarding MIME type mapping
that has since been removed.
On Tue, Sep 5, 2023 at 9:36 AM Peter Kreuser <l...@kreuser.name> wrote:
Robert,
While Mark Thomas will have a more detailled answer to this...
The finding behind this test is valid (information disclosure with
server
version in responses), though the remediation listed here is from looong
time ago, when the was no ErrorReportValve to purge the version info.
So the CIS Tomcat 8(!) Guide is pretty outdated! Probably in more than
this spot...
Peter
Am 05.09.2023 um 14:03 schrieb Robert Turner <rtur...@e-djuster.ca>:
While I think I know the answer to my question, I wanted to
double-check
with the group to confirm.
I have been asked to perform the CIS Apache Tomcat 8 Benchmark (v1.1.0)
on
our production Tomcat installation, and I am looking through the
questions
/ information extraction requests, and I suspect they are not really
evaluating what they think they are, and furthermore encouraging bad
practices.
For instance, the first entry I have in the spreadsheet I was
provided is
listed as follows:
CIS Control:
2.1 Alter the Advertised server.info String (Scored)
Description:
The server.info attribute contains the name of the application service.
This value is presented to Tomcat clients when clients connect to the
tomcat server.
Audit Procedures:
Perform the following to determine if the server.info value has been
changed:
Extract the ServerInfo.properties file and examine the server.info
attribute.
$ cd $CATALINA_HOME/lib
$ jar xf catalina.jar org/apache/catalina/util/ServerInfo.properties
$ grep server.info org/apache/catalina/util/ServerInfo.properties
So, other than a few issues with the audit procedures, etc. This
seems to
be doing the following:
a) evaluating a default value which I believe can be overridden and
thus
may not actually reflect the value the server may provide to external
clients
b) encouraging the modification of the catalina.jar contents to correct
the
default value
There are a few similar items (for server.number, server.built) (2.2,
2.3).
Thoughts / comments from "those in the know"?
Thanks,
Robert
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
