A mini-writeup to elucidate what a basic setup of a secured server might look like. Which might essentially be a DMZ kind of setup. Threat model being an adversary gaining user-level privilege on the server machine, with access to the attached network. This implies:

• Connecting network should be a dedicated DMZ VLAN.
  • Hole-punching in the firewall from the DMZ should be strictly limited to necessary services only.
• Minimize exposed services
  • Rationale: Codebase must additionally fulfill two conditions to be considered secure, (1) codebase must be regularly maintained and possibly audited, and have a decent vuln reporting policy, (2) system must be regularly patched to check for updates.
  • Web server security-focused
• For access to internal network, use dedicated ports and access controls

TODOS:

• AppArmor is a tool that desperately needs more widespread adoption! https://apparmor.net/

The writeup by OpenSUSE is fairly great and in detail. A nice introduction to AppArmor and usage, and some perspectives from pentesting POV. FAQ page from official wiki.

The goal of AppArmor is to perform incremental deployment of MAC security policies, confining specific applications to specific tasks and file accesses. It works by monitoring the paths accessed by the application, and granting access only if it matches with the AppArmor profile associated with the application. The other viable offering is SELinux, but Ubuntu already has AppArmor baked in.

AppArmor configuration is achieved by configuring the profiles as the root user, then rebooting the computer to enforce those profiles at the kernel-level. Despite not necessarily securing against a malicious actor with root-privileges, this model is still useful since most of modern servers nowadays provide network services rather than direct SSH access. Note that even then, root-level privileges can still be restricted by generating a restricted shell with AppArmor.

Three main states for AppArmor profiles:

1. Enforcement: Actions that violate policies are logged and blocked.
2. Complain: Actions (that are not explicit deny rules) are logged but not blocked.
3. Unconfined: Actions are neither logged nor blocked.

root:~# aa-status  # check 
32 profiles are loaded.
32 profiles are in enforce mode.
0 profiles are in complain mode.
0 profiles are in kill mode.
0 profiles are in unconfined mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.