Hardened Tomcat 9 on CentOS Stream 9

Charges for this image cover the security hardening, optimization, and pre-integration work Hanwei performs on top of the upstream Tomcat 9 and CentOS Stream 9 projects. Tomcat 9 is installed from the distribution repository with its service enabled, so the container is listening on port 8080 when the instance finishes booting and a war file dropped into the webapps directory deploys without further configuration. The operating system underneath carries the same hardened and tuned baseline used across this catalogue.

What Hanwei Adds to Upstream Tomcat 9

• Container installed and enabled at build time: Tomcat 9 comes from the distribution repository, so it is updated through dnf along with the rest of the system, and the service is enabled with the manager and host-manager applications present.
• Management applications left restricted as shipped: the manager and host-manager contexts accept requests from the loopback address only and no user accounts are defined, so neither is reachable or usable until an administrator adds a role and a user.
• Startup timeout raised for the JVM: a drop-in extends the service start timeout to 300 seconds, so a cold start on a smaller instance is not terminated by the default 75 second limit before deployment finishes.
• Tuning baseline applied identically across the catalogue: the file descriptor limit goes from 1024 to 65536 and the memory-map ceiling from 65530 to 262144; the device receive backlog goes from 1000 to 16384 and the TCP SYN backlog from 128 to 8192, so bursts queue instead of being dropped; socket buffer maxima reach 16 MB for larger autotuned windows; connections keep their congestion window across idle periods; and the journal is capped at 500 MB. The profile raises ceilings only and does not alter protocol semantics or application behaviour.
• Applied hardening beyond the distribution default: SSH is limited to a vetted cipher, key exchange and MAC list, X11 forwarding is off, the login grace period is shortened and verbose authentication logging is on; auditd runs a base rule set for privileged command execution; the kernel drops ICMP redirects on IPv4 and IPv6, logs martian packets, filters reverse paths in loose mode, restricts dmesg, disables setuid core dumps and turns off sysrq.
• AWS operational integration: the SSM Agent is installed and enabled for Session Manager and Patch Manager without an inbound SSH rule; chrony points at the Amazon Time Sync Service; and the root filesystem extends at boot when the volume exceeds the image default.
• Patch level set at the build date: packages come from official upstream repositories at the newest level published when the image was built.
• Repeatable build and EC2 validation: each version comes from the same build process and is launched and exercised on EC2 before release.

Access and Security Posture

• SELinux runs in enforcing mode and auditd records activity against a base rule set.
• Sign in as 'ec2-user' with the key pair selected at launch, then use 'sudo su -' for a root shell. Session Manager is available as an alternative that needs no inbound port.
• Direct root login over SSH is disabled and password authentication is not accepted.
• No authorized keys and no SSH private keys are embedded in the image.

Operational Impact on EC2

• Launch-to-serving time is reduced to a single boot cycle.
• Every instance starts from an identical configuration, removing drift between development, staging and production hosts.
• Network services need no per-host limit or backlog adjustment before handling load.
• Clock accuracy comes from the Amazon Time Sync Service, which matters for log correlation and request signing.
• Post-launch patching effort is lower because the package set is current at release.

Where This Image Fits

• Java web applications packaged as war files that expect a servlet container.
• Application hosts behind an Application Load Balancer terminating TLS.
• Development and test instances for teams working on Servlet 4.0 codebases.
• Staging hosts for validating a deployment before it reaches a larger fleet.

About Tomcat 9 and CentOS Stream 9

Apache Tomcat is a servlet container implementing the Java Servlet, JSP and WebSocket specifications. Version 9 implements Servlet 4.0 under the javax.* namespace, which is what the large body of existing Java web applications is compiled against, so a war file built for a Servlet 4.0 container deploys here without source changes.

CentOS Stream 9 is a Linux distribution that tracks the development stream of Red Hat Enterprise Linux 9. Packages land in CentOS Stream before they appear in a RHEL minor release, so it stays close to the RHEL package set and toolchain while remaining freely redistributable. It uses dnf, systemd and SELinux, which makes it a predictable base for server workloads that need RHEL compatibility.