Secure Tomcat Platform Automation
Tomcat is the forgotten middle-tier service. Deployed by everyone, hardened by no one. What the lennlay scanner finds is what the auditor should not find.
Java applications are running, Tomcat is running, and in most environments there are twelve instances with twelve different configurations. No uniform hardening baseline. No documentation. The problem is not in the deployment itself — it is that nothing happens afterwards.
One scan. 12 Tomcat instances. 12 configurations.
What the lennlay compliance scanner finds in unconfigured environments is not an exception. It is the normal state in grown Java landscapes.
Anyone with network access can stop Tomcat. No auth, no audit trail, no protection.
The Apache JServ Protocol connector accepts connections without a configured shared secret.
Tomcat's management interfaces are reachable, often with default credentials or without access restrictions.
Cross-Site Tracing (XST) is possible. A known attack vector that is prevented by a single configuration line.
Outdated protocol versions are accepted. Not compliant with current requirements for transport encryption.
X-Powered-By and Server headers reveal the Tomcat version. Reconnaissance becomes trivial.
Web directories are browsable when no index file exists. Files and structures are exposed to any requester.
X-Content-Type-Options, X-Frame-Options, and comparable headers are absent. Basic browser-level protection goes unused.
Deployed is not secured.
Tomcat was built to make Java applications accessible, not to be hardened out of the box. The default configuration is designed for functionality. Security comes from explicit configuration. In most environments, that configuration never happens.
The result: every instance deployed without a hardening baseline is an audit risk. Not because anyone acted negligently, but because no process exists that enforces, verifies, and documents hardening. The lennlay.tomcat Ansible Collection closes exactly this gap.
lennlay.tomcat: Fix the findings, not just document them.
The lennlay.tomcat Ansible Collection implements the hardening baseline technically. What the scanner finds, the Collection fixes. Reproducibly, versioned, auditably.
Hardening by Policy
CIS Level 1 as the foundation, selective Level 2 based on risk, lennlay Best Practice as a pragmatic middle ground. Configuration through versioned policy files, not individual decisions.
Reproducible Deployment
Tomcat installation, configuration, and hardening via Ansible in a single pipeline. Every instance receives the same defined target state, regardless of person or environment.
Auditable Compliance
Scanner scripts check the actual state against the policy. The result is a report, not a gut feeling. Directly usable in audits, reviews, and internal compliance checks.
Define policy. Build. Deliver. Verify.
Apache Tomcat is listed in the GIaaS MVP catalog. The policy model allows different security profiles depending on environment and requirements.
CIS L1, CIS L2, lennlay Best Practice, or CUSTOM. The target state is defined as code, not as a document.
Ansible Collection implements the policy technically. Reproducible across any environment, without manual steps.
Hardened Tomcat image as a versioned artifact. Golden image workflow for your target environment.
Deployment into existing CI/CD pipelines. No configuration drift between environments.
Basic security requirements with low operational risk. Recommended as a minimum standard in all environments.
Extended security requirements, higher configuration effort. Appropriate for environments with elevated protection needs.
CIS L1 as the foundation, supplemented by selective L2 rules based on risk assessment. Pragmatic and audit-ready.
Freely configurable rule set, adapted to internal standards, industry requirements, or existing compliance mandates. Fully auditable.
Where organizations are when they start with lennlay.
Grown Java landscape
Tomcat instances deployed over years, each configured differently by the development team. No uniform hardening standard, no shared baseline, no traceable change history. The scanner shows the current state. The Collection brings every instance to the same defined target.
Pre-audit: scanner reveals gaps
A few weeks before an audit, a compliance tool reports critical findings. Shutdown port open, Manager accessible, TLS 1.0 active. Hardening now needs to happen quickly, verifiably, and reproducibly — not as manual rework across twelve servers.
Moving from manual setup to Ansible
Tomcat is currently configured manually or managed through ad-hoc scripts. The team wants to move to Ansible but needs a ready-to-use, tested Collection as a starting point rather than a greenfield project.
Where Tomcat hardening matters most.
Large Java landscapes with multiple Tomcat generations, teams, and areas of responsibility. Uniform baselines create consistency across organizational boundaries.
Java applications in core banking, payment processing, or regulatory reporting. Regulatory audits expect technical hardening evidence, not written descriptions.
Tomcat as the runtime environment for Java specialist systems. BSI IT-Grundschutz and NIS2 requirements demand traceable security configuration and change documentation.
Risk management, technical security measures, traceability of configuration changes.
Hardening reference for Tomcat. lennlay uses CIS as a baseline, not as a certification claim.
Technical controls as documented safeguards. Hardening evidence for the technological security domain.
CUSTOM Policy allows mapping your own security standards as auditable configuration.
What is available today, and what is coming next.
Scanner scripts for Tomcat are available and proven in production. GIaaS Apache Tomcat is listed in the MVP catalog. The lennlay.tomcat Ansible Collection is being expanded alongside concrete customer scenarios. The full golden image workflow is currently under development.
If Tomcat is part of your platform roadmap, reach out early. Early projects help shape the direction of development.
Tomcat unaudited in your environment? Let the scanner take a look.
Non-binding · No sales pitch · Confidential
