Hacker News Reader

Comment by kibwen | Hacker News Reader

If all you need is a simple way to serve static files that minimizes resource consumption and is reliably secure, what is the state of the art these days? In the past I would probably reach for Nginx, but I wonder if a more focused/less configurable tool would be preferable from a security standpoint.

View on HN

I use https://static-web-server.net/

Cross-platform, written in Rust, straightforward configuration, secure defaults, also has a hardened container image and a hardened NixOS module.

I wouldn't recommend Caddy. Their official docker image runs as root by default [1], and they don't provide a properly sandboxed systemd unit file [2].

[1]: https://github.com/caddyserver/caddy-docker/issues/104

[2]: https://github.com/caddyserver/dist/blob/master/init/caddy.s...

EDITED: phrasing

What's wrong with the unit file?

All linux processes have a default set of permissions that's absurdly large, even when not running as root. Web servers don't need but a fraction of those permissions. This may help: https://www.redhat.com/sysadmin/mastering-systemd

I use this...

    [Unit]
    Description=Caddy webserver
    Documentation=https://caddyserver.com/docs/
    After=network-online.target
    Wants=network-online.target systemd-networkd-wait-online.service
    StartLimitIntervalSec=14400
    StartLimitBurst=10

    [Service]
    User=caddy
    Group=caddy

    # environment: store secrets here such as API tokens
    EnvironmentFile=-/var/lib/caddy/envfile
    # data directory: uses $XDG_DATA_HOME/caddy
    # TLS certificates and other assets are stored here
    Environment=XDG_DATA_HOME=/var/lib
    # config directory: uses $XDG_CONFIG_HOME/caddy
    Environment=XDG_CONFIG_HOME=/etc

    ExecStart=/usr/bin/caddy run --config /etc/caddy/Caddyfile
    ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile

    # Do not allow the process to be restarted in a tight loop.
    Restart=on-abnormal

    # Use graceful shutdown with a reasonable timeout
    KillMode=mixed
    KillSignal=SIGQUIT
    TimeoutStopSec=5s

    # Sufficient resource limits
    LimitNOFILE=1048576
    LimitNPROC=512

    # Grants binding to port 443...
    AmbientCapabilities=CAP_NET_BIND_SERVICE
    # ...and limits potentially inherited capabilities to this
    CapabilityBoundingSet=CAP_NET_BIND_SERVICE

    # Hardening options
    LockPersonality=true
    NoNewPrivileges=true
    PrivateTmp=true
    PrivateDevices=true

    ProtectControlGroups=true
    ProtectHome=true
    ProtectKernelTunables=true
    ProtectKernelModules=true
    ProtectSystem=strict

    ReadWritePaths=/var/lib/caddy
    ReadWritePaths=/etc/caddy/autosave.json
    ReadOnlyPaths=/etc/caddy
    ReadOnlyPaths=/var/lib/caddy/envfile
    [Install]
    WantedBy=multi-user.target

If you want a sandboxed unit file, why not just sandbox it yourself?

Sandboxing it yourself is fraught because any new feature could cause things like a syscall filter to crash the app. It has to be part of the application build/test/release process to prevent that, like it is in SWS.

Besides, we should be creating and using software that is secure by default: https://www.cisa.gov/sites/default/files/2023-06/principles_...

Ah yes, I agree Linux should not let processes have a set of permissions that large by default.

Shameless plug: Caddy does a great job here. Automatic HTTPS, written in Go so memory safety bugs are not a concern, has a solid file_server module.

Isn't everything forced to https now

No.

Some things were never meant to be, like downloading CRLs over HTTPS.

Browsers try to navigate you to HTTPS but no, http the protocol is still working as it always has. Both nginx and Apache will require configuration to serve HTTPS.

You might still use HTTP on an internal network in a DMZ or other trusted network.

Good to know

+1 to Caddy. Just tried it recently and I was very happy to forget all the nginx jargon the next moment.

Im using caddy, it's great!

I have used Caddy for years, automatic SSL certificates, does file serving, does reverse proxy, very easy and clear to configure. Single-binary (Go) so easy to "install", single configfile.

Caddy is pretty simple to configure and serve static files from.

Merecat

https://github.com/troglobit/merecat/

Last release 2016??

OP wanted a simple web server for serving static content. Are you aware of open CVEs? No? It's possible for software to be done you know. Just because something isn't a rolling release of change for the sake of change (like most Google crapware) doesn't mean it isn't fit for purpose.

Considering the vast majority of commit were made after 2016, I don't think it is "done".

And a C program, written by a single developer, with only 27 issues ever being filed? With all due respect, that's guaranteed to have some nasty bugs in there.

werc, shttpd, etc.

Treat any web request like you would a real user on a Linux system you'd need to give access to to download files via scp. Chroot, strict permissions, etc. Can't escape what you can't escape. A ../ should return the same as expected in the shell, permission denied

how is a static site served from S3 considered in these parts of the interweb? i've never done this, but see it as an option, yet i never really hear others using it either.

Good Q. Using S3 as origin behind Cloudfront seems like a pretty standard AWS CDN setup for static assets... but S3 isn't a traditional web server.

In my view, it's perfect (okay, maybe slightly less than perfect, and dedicated platforms taking ot to the next level like Netlify, CloudFlare Pages, Firebase Hosting, etc are for their added related services and tools, as well as their generous free tiers). It's pay as you go, scales from zero to infinite, and has zero attack surface or maintenance.

I've run a couple of websites (WordPress or Hugo based, including my personal blog) like that and it's great.

You probably want some kind of CDN to avoid a HN frontpage link from making you go bankrupt, but it's a pretty decent solution.

I personally prefer something like Github Pages, though - it doesn't get much more hands-off than that!

Could you give a commentary to traefik also ? In terms security and reliability, thanks

Reply on news.ycombinator.com