Hello all,
One thing we could look at is the CIS Benchmarks for Tomcat found here:
https://www.cisecurity.org/benchmark/apache_tomcat The benchmark is not
perfect. For example, it does not mention adding:
Valve className="org.apache.catalina.valves.ErrorReportValve"
showServerInfo="false"/>
This is something I think is important. It does recommend users do something
similar by extracting the ServerInfo.properties from the catalina.jar, altering
it, then repackaging it. As I stated above, it is not perfect, but many people
are using this as a guide.
We could add a page to the site pointing people to this link as well as
bulleting some of the items we feel is most important. We should encourage all
users to follow what makes sense for them.
Thanks,
Rod.
On 3/13/22, 12:51 PM, "Zowalla, Richard" <richard.zowa...@hs-heilbronn.de>
wrote:
Nationwide Information Security Warning: This is an EXTERNAL email. Use
CAUTION before clicking on links, opening attachments, or responding. (Sender:
dev-return-28942-JENKIR14=nationwide....@tomee.apache.org)
------------------------------------------------------------------------------
Thanks for brining up this important topic!
Perhaps it would be a good idea to include a security walkthrough on
our web page (even if we only link to Tomcat) as well to cover this
(very) important topic. This could also include secure systemd
configuration, etc.
In addition it might be an option to go the "mariadb" way (I am
thinking of 'mysql_secure_installation' [1]) and provide a shell / bash
(+ Windows) script, which we include in our distribution archives. If a
user execute the script, the default configurations are hardended.
However, we would need to "promote" it, so users get to know it.
This would mitigate possible pain in our code base / tests / examples
or for developers working with or on TomEE applications (or on TomEE
itself).
Wdyt?
Gruß
Richard
[1] https://mariadb.com/kb/en/mysql_secure_installation/
Am Sonntag, dem 13.03.2022 um 11:45 +0100 schrieb Jean-Louis Monteiro:
> Thanks David for the quick reply. There is probably a balance to
> find.
>
> I agree that the tradeoffs can hurt us more than the actual small
> settings
> to apply.
> They are pretty well documented and clear in the following page
> https://tomcat.apache.org/tomcat-9.0-doc/security-howto.html
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>
>
> On Sun, Mar 13, 2022 at 9:58 AM David Blevins <dblev...@tomitribe.com
> >
> wrote:
>
> > > On Mar 12, 2022, at 11:34 PM, Jean-Louis Monteiro <
> > jlmonte...@tomitribe.com> wrote:
> > > xpoweredBy giving the exact version of Tomcat for instance
> > > The error valve attributes are set to false so it does not
> > > display
> > Tomcat's
> > > version and does not discard exceptions.
> > >
> > > Should we somehow pre-configure TomEE to be a bit more secure?
> > > The downside is that in development, with Arquillian or TomEE
> > > Maven
> > plugin
> > > we lose some useful information to debug and understand what's
> > > going on.
> >
> > I think you raise a key point in that last sentence. If we do
> > things like
> > have TomEE eat stacktraces and fail silently by default, that
> > doesn't just
> > make it harder for people to write applications on TomEE, that also
> > makes
> > it harder for us to develop TomEE.
> >
> > I think that would likely translate into fewer people making it out
> > of the
> > development phase, which means fewer users, fewer contributors and
> > fewer
> > resources.
> >
> > We'd also have to sweep through all our test cases and examples and
> > ensure
> > that things like stacktraces are enabled, which would make tests
> > and
> > examples more complicated. It could also reinforce people using
> > the dev
> > settings in production if they're seeing them repeated in our 180+
> > examples. They'd still be in the position of having to read a doc
> > to undo
> > the settings before production.
> >
> > Not totally against, it just sounds very tricky.
> >
> > It's definitely a good conversation and there are likely specific
> > things
> > we can do that could be palatable but don't completely sacrifice
> > the dev
> > experience.
> >
> >
> >
> > -David
> >
> >
