Mailing List Archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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.

    For example:

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

      systemctl edit nginx.service

    and add settings like (demonstration ONLY):

    # 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.
    # Has to write logs, so whitelist this path
    # 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%.

Home | Main Index | Thread Index