Re: [tlug] Dealing with software with wide attack surface

[Jens John <lists@example.com>]

On Sat, Aug 28, 2021 at 02:58:19PM +0200, Christian Horn wrote:
> I am wondering how you deal with software with a big
> attack surface, or to which degree you care.

Containment and resource restraints, lastly offline backups of the persistence
layer.

For which you should be making use of all possible modern Linux security
features, which is often overlooked even and especially by major distributions
which ship systemd .service files for apache, nginx etc that are not
particularly hardened.

  - you should use a Linux distribution with MAC set up properly, which means
    Ubuntu/$Derivative and AppArmor or RHEL/Fedora/$Derivative and SELinux. Of
    course, SELinux should be in enforcing mode and labels assigned correctly as
    to deny nginx to write to anything it shouldn't write to.

  - you should be using systemd and its containment features even with nginx,
    apache etc provided by the main OS. When you use systemd properly and its
    capabilities to contain and restrain processes, separate container runtimes
    are obsolete and KVM level isolation almost overkill (for maximum security,
    by all means, add micro VMs on top).

    People CANNOT WRITE sysvinit scripts that even come close to covering the
    same array of control without VERY deep knowledge and they will likely get
    it wrong anyway. Use systemd, and use it correctly.

    https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html
    https://www.freedesktop.org/software/systemd/man/systemd.exec.html

    For example:

    Install nginx, configure it to serve your webstuff, then enter

      systemctl edit nginx.service

    and add settings like (demonstration ONLY):

    [Service]
    # Allow executing nginx as non-root while still being able to bind to
    # privileged ports 80 and 443. On Ubuntu-like systems, nginx runs as root
    # with privdropped worker processes. Completely unnecessary.
    User=www-data
    Group=www-data
    AmbientCapabilities=CAP_NET_BIND_SERVICE
    NoNewPrivileges=yes
    MemoryMax=1G
    PrivateDevices=yes
    ProtectSystem=strict
    ProtectHome=yes
    ProtectKernelTunables=yes
    ProtectControlGroups=yes
    # Has to write logs, so whitelist this path
    ReadWritePaths=/var/log/nginx
    # Will not be able to write to UNIX sockets
    RestrictAddressFamilies=AF_INET AF_INET6

    and many more settings are possible; you can even control the amount of
    bandwidth and CPU the webserver can take.

The aforementioned features alone, which are easy to configure and easy to learn
by spending time with the systemd manpages, should easily cover 99.99% of attack
surface on dynamic components.

Of course, in the end, you will have a persistence layer somewhere, a database
server or a directory hierarchy with user-generated content. This type of stuff
needs to be shipped off of the online system to a backup location that is
write-only excluding overwrites from the source system or completely
disconnected, like offline backups. Because in the end, no security is 100%.