---

Wiki: Creating Custom Apache Application Users for Security Hardening

1. Problem Statement

Background

The Nautilus application is a mission critical, defense related, multi tier web application deployed across multiple Linux servers in the Stratos Datacenter. The application stack uses Apache as the web server and hosts multiple applications on the same server.

Historically, applications running under Apache were executed using a single OS level user. This design introduces a major security risk.

Core Issue

When multiple applications run under the same OS user on a server, a vulnerability in one application can lead to unauthorized access to all other applications on the same server. This significantly increases the blast radius of any security incident.

Key risks include:

• Lateral file access between applications

• Unauthorized modification of application code

• Leakage of configuration files and secrets

• Persistence mechanisms planted by attackers

This risk exists even if servers have different admin users.

Why This Is a Real Problem

Attackers do not usually target server admin accounts first. They target:

• Web application vulnerabilities

• File upload flaws

• Code execution bugs

• Misconfigured endpoints

Once exploited, the attacker gains access as the Apache runtime user, not as a server admin. If all applications share the same runtime user, the compromise spreads instantly.

---

2. Objective

To mitigate this risk, the security team decided to enforce application level isolation by creating custom Linux users per application.

Each application:

• Has its own OS user

• Owns only its own application files

• Cannot access other applications on the same server

This applies to every application server.

---

3. Common Confusion Clarified

Why server admin users are not enough

Each server has its own admin user, for example:

• stapp02 has admin user steve

This controls:

• Who can SSH into the server

• Who can perform administrative actions

It does not control:

• What an exploited application can access

• How Apache processes interact with files

Server admins protect servers.
Application users protect applications.

Both are required.

---

4. High Level Architecture Context

• Load balancer distributes traffic to multiple app servers

• Same applications are deployed on all app servers

• Same vulnerabilities exist everywhere

Therefore:

• Application isolation must exist on each app server

• Not doing this multiplies the impact of an attack

---

5. Task Summary

Create a custom Apache application user with the following specifications:

• Username: jim

• UID: 1910

• Home directory: /var/www/jim

• Server: App Server 2 (stapp02)

This user is:

• Non human

• Non login

• Used only by Apache to run application files

---

6. Infrastructure Details Used

From the infrastructure documentation:

• App Server 2 hostname: stapp02.stratos.xfusioncorp.com

• App Server 2 IP: 172.16.238.11

• Admin user: steve

• Purpose: Nautilus Application Server

Access to internal servers is done via the Jump Server.

---

7. Step by Step Execution

Step 1: Login to Jump Server

ssh thor@jump_host.stratos.xfusioncorp.com

Password:

mjolnir123

---

Step 2: Login to App Server 2

ssh steve@stapp02.stratos.xfusioncorp.com

Password:

Am3ric@

Verify you are on the correct server:

hostname

Expected output:

stapp02

---

Step 3: Switch to root user

Creating system users requires root privileges.

sudo su -

Verify:

whoami

Expected output:

root

This confirms you are root only on stapp02, not globally.

---

8. User Creation

Create the application user with exact specifications:

useradd -u 1910 -d /var/www/jim -m -s /sbin/nologin jim

what is meaning of this above command:
This command creates a non login Linux user named Jim with a fixed UID and a controlled home directory for securely running an Apache hosted application.

Why each option is required

• -u 1910 ensures UID consistency

• -d /var/www/jim aligns with Apache document root conventions

• -m creates the directory

• -s /sbin/nologin prevents SSH access

• jim is the application identity

This enforces least privilege.

---

9. Verification Steps

Verify user identity

id jim

Expected:

uid=1910(jim)

---

Verify home directory and ownership

ls -ld /var/www/jim

Expected:

• Owner: jim

• Group: jim

---

Verify passwd entry

getent passwd jim

Expected format:

jim:x:1910:1910::/var/www/jim:/sbin/nologin

---

10. Identity Model After Change

On App Server 2, identities are now clearly separated:

• root
  Full system control

• steve
  Human server administrator
  SSH and sudo access

• jim
  Application user
  Owns only its application files
  No login access

This separation is intentional and required.

---

11. Security Outcome

Without application users

• One exploited app compromises all apps on the server

With application users

• Compromise is limited to a single application

• Blast radius is reduced

• Compliance posture improves

• Incident response becomes manageable

This is not optional hardening. This is baseline production security.

---

12. Key Takeaway for Future Revision

Remember this permanently:

• Server admins manage servers

• Application users protect applications

• Different servers do not replace application isolation

• Most real world breaches start at the application layer

---

13. Status

Task completed successfully on App Server 2.
User jim created with correct UID, home directory, and restricted access.

---