Caddy, HSTS in security.txt

Modul 7: Domena, spletni strežnik in https · Čas branja: 12 minut

Učni cilj: Po tej lekciji boste znali uporabljati Caddy kot preprost spletni strežnik s samodejnim https, nastaviti HSTS in najpomembnejše varnostne glave (v Caddy in nginx), ne da bi Vaše spletno mesto postalo nedosegljivo, ter objaviti veljavno datoteko security.txt.

Ključni pojmi: Caddy, Caddyfile, samodejni https, reverse_proxy, file_server, header, HSTS (Strict-Transport-Security), max-age, includeSubDomains, preload, X-Content-Type-Options, frame-ancestors, Referrer-Policy, security.txt, Contact, Expires, /.well-known/

Caddy: https brez skrbi

V lekcijah 7.2 in 7.3 ste z nginx in certbot postavili spletno mesto s https. To sta dva programa, nekaj datotek in časovnik. Caddy vse to opravi sam: je spletni strežnik z vgrajenim odjemalcem ACME. Če je ime navedeno v konfiguraciji, kaže na strežnik in sta vrati 80 in 443 dosegljivi, Caddy sam pridobi certifikat, ga pravočasno obnovi in preusmeri http na https.

Caddy je v repozitoriju paketov Debiana in Ubuntuja (nekoliko starejša različica); razvijalci ponujajo tudi lasten repozitorij apt z najnovejšo različico, z lastnim ključem in Signed-By kot v lekciji 4.1. V modulu 9 Caddy teče kot vsebnik za Vaše storitve Docker (lekcija 9.4). Tukaj ga uporabljate kot običajno storitev.

anna@web1:~$ sudo apt install caddy
anna@web1:~$ systemctl status caddy

Na vratih 80 in 443 uporabljajte bodisi nginx bodisi Caddy, ne obeh: na posameznih vratih lahko posluša le en program.

Datoteka Caddyfile

Konfiguracija je v /etc/caddy/Caddyfile. Statično spletno mesto in aplikacija za povratnim posrednikom (reverse proxy):

example.com, www.example.com {
	root * /var/www/example.com
	file_server
	encode zstd gzip
}

app.example.com {
	reverse_proxy 127.0.0.1:3000
}

To je vse. Caddy samodejno posluša na IPv4 in IPv6, zahteva certifikate za vsa tri imena, preusmeri http na https in pri reverse_proxy samodejno posreduje glavi X-Forwarded-For in X-Forwarded-Proto (kar ste v nginx naredili ročno, lekcija 7.2).

Preizkus in ponovno nalaganje potekata kot pri nginx:

anna@web1:~$ caddy validate --config /etc/caddy/Caddyfile
Valid configuration
anna@web1:~$ sudo systemctl reload caddy
anna@web1:~$ sudo journalctl -u caddy -f

V dnevniku (journal) vidite pridobivanje certifikatov. Če gre kaj narobe, je tam naveden razlog: običajno isti kot pri certbot (vrata 80 zaprta, ime kaže drugam, IPv6 ne deluje; lekcija 7.3).

HSTS: naj si brskalnik zapomni, da gre za https

Preusmeritev s http na https ima eno šibko točko: prva zahteva prek http še vedno poteka nešifrirano. Nekdo v istem omrežju jo lahko prestreže in obiskovalca zadrži na http. HSTS (HTTP Strict Transport Security, RFC 6797) to reši. Vaše spletno mesto prek https pošlje to glavo:

Strict-Transport-Security: max-age=31536000

Brskalnik si nato eno leto (31.536.000 sekund) zapomni, da je to ime dovoljeno le prek https. Če obiskovalec pozneje vtipka http://, brskalnik sam spremeni naslov v https, še preden karkoli steče po omrežju. Glavo HSTS, ki pride prek http, brskalnik prezre; velja le prek https.

Obstaja pa tudi slaba stran. Če si je brskalnik zapomnil HSTS in naleti na napako certifikata (potekel, napačno ime), obiskovalec ne dobi gumba, s katerim bi kljub temu nadaljeval. Vaše spletno mesto je za te obiskovalce nedosegljivo, dokler certifikat ni v redu. Zato:

1. HSTS vklopite šele, ko https deluje povsod in obnavljanje poteka samodejno (lekcija 7.3).
2. Začnite s kratkim max-age, na primer en dan (86400), in ga postopoma povečujte do enega leta.
3. Bodite previdni z includeSubDomains: to velja za vsako poddomeno, tudi za staro poddomeno z napravo ali storitvijo brez veljavnega certifikata.
4. preload zahteva vpis na seznam, ki je vgrajen v brskalnike (hstspreload.org). Za to med drugim zahtevajo max-age vsaj eno leto, includeSubDomains in https na vseh poddomenah. Izbris s seznama traja mesece. To storite le, če ste prepričani, da bo celotna domena za vedno na https.

Druge varnostne glave

Poleg HSTS obstaja nekaj glav, ki z malo truda veliko pomagajo:

Popoln Content-Security-Policy (katere skripte in slogi se smejo naložiti) je treba prilagoditi vsakemu spletnemu mestu posebej in presega ta tečaj; začnite samo z frame-ancestors.

V Caddy jih nastavite z direktivo header v bloku spletnega mesta:

example.com, www.example.com {
	root * /var/www/example.com
	file_server
	header {
		Strict-Transport-Security "max-age=31536000"
		X-Content-Type-Options "nosniff"
		Content-Security-Policy "frame-ancestors 'self'"
		Referrer-Policy "strict-origin-when-cross-origin"
		-Server
	}
}

Caddy HSTS in teh glav ne nastavi sam; zato jih morate res dodati. -Server odstrani glavo Server. V lekciji 9.4 v enako vrsto bloka za nalogo dodate svojo glavo X-Weboke-Cursus.

V nginx iste vrstice dodate v blok server za vrata 443:

add_header Strict-Transport-Security "max-age=31536000" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Content-Security-Policy "frame-ancestors 'self'" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

always poskrbi, da se pošljejo tudi pri straneh z napako. Pazite na znano past v nginx: če je v bloku location sam en add_header, vrstice add_header iz bloka server za ta location ne veljajo več. Zato vedno preverite rezultat:

anna@laptop:~$ curl -sI https://example.com | grep -iE 'strict|nosniff|frame|referrer'
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
content-security-policy: frame-ancestors 'self'
referrer-policy: strict-origin-when-cross-origin

security.txt: tako Vam lahko nekdo prijavi ranljivost

Recimo, da nekdo na Vašem strežniku najde ranljivost, na primer odprto mapo ali zastarelo storitev. Kako ta oseba ve, koga naj opozori? Za to je namenjen security.txt (RFC 9116): majhna besedilna datoteka na stalnem mestu, https://<jouwdomein>/.well-known/security.txt.

Contact: mailto:security@example.com
Expires: 2027-10-31T23:00:00Z
Preferred-Languages: nl, en
Canonical: https://example.com/.well-known/security.txt

Pravila:

• Contact je obvezen: naslov mailto:, https:// ali tel:, kamor prihajajo prijave. Uporabite naslov, ki ga nekdo res bere.
• Expires je obvezen in se sme pojaviti le enkrat: datum, po katerem datoteka velja za zastarelo. RFC priporoča datum v roku enega leta. Tako ne ostane datoteka z davno pozabljenim naslovom. V koledar si zapišite, kdaj jo morate podaljšati.
• Preferred-Languages, Canonical in Policy (povezava do Vaše politike za prijave) so neobvezni.
• Datoteka mora biti dostavljena prek https kot navadno besedilo (text/plain, UTF-8). Staro mesto /security.txt je dovoljeno kot dodatek, a /.well-known/ ima prednost.

Namestitev pri statičnem spletnem mestu:

anna@web1:~$ sudo mkdir -p /var/www/example.com/.well-known
anna@web1:~$ sudoedit /var/www/example.com/.well-known/security.txt
anna@laptop:~$ curl -sI https://example.com/.well-known/security.txt | grep -i content-type
content-type: text/plain; charset=utf-8

Če v nginx uporabljate varovalko location ~ /\. { deny all; } iz lekcije 7.2, pred njo dodajte izjemo: location ^~ /.well-known/ { }. Za aplikacijo za povratnim posrednikom lahko v Caddy pot /.well-known/security.txt usmerite na datoteko z blokom handle in file_server.

Pogosta napaka: spletno mesto ali aplikacija, ki na vsako neznano pot odgovori z naslovno stranjo in statusom 200. Takrat security.txt "obstaja", vendar je HTML. Zato preverite tudi vsebino.

Na AlmaLinux in Rocky Linux

Caddy tam namestite iz repozitorija razvijalcev ali iz EPEL/COPR. Tako kot pri nginx mora SELinux dovoliti povratni posrednik (setsebool -P httpd_can_network_connect 1). Caddyfile in glave so enaki.

Povzetek

• Caddy sam poskrbi za certifikate, obnavljanje in preusmeritev na https; reverse_proxy samodejno posreduje prave glave.
• HSTS poskrbi, da si brskalniki zapomnijo, da je Vaše spletno mesto le na https; max-age povečujte postopoma, bodite previdni z includeSubDomains in zelo previdni s preload.
• Poleg tega nastavite X-Content-Type-Options: nosniff, frame-ancestors 'self' in Referrer-Policy; v Caddy z header, v nginx z add_header ... always, in preverite z curl -I.
• security.txt je na /.well-known/security.txt, prek https, kot navadno besedilo, z obveznim Contact in enim Expires v roku enega leta.

Kviz

Naloga

Naloga Z7.4: HSTS, glave in security.txt. Za svoje spletno mesto nastavite HSTS (vsaj 180 dni, ko https že nekaj časa dobro deluje), X-Content-Type-Options: nosniff in frame-ancestors 'self' (ali X-Frame-Options) ter objavite security.txt s Contact in Expires v roku enega leta. Vnesite svoje ime gostitelja. Program pridobi https://<hostnaam>/ in preveri glave ter pridobi https://<hostnaam>/.well-known/security.txt in preveri polja. Ne shrani ničesar razen rezultata in datuma Expires.

Za nadaljnje branje

• HSTS in varnostne glave za Vašo spletno stran
• Caddy, Automatic HTTPS: https://caddyserver.com/docs/automatic-https
• Caddy, direktiva header: https://caddyserver.com/docs/caddyfile/directives/header
• RFC 6797, HTTP Strict Transport Security: https://www.rfc-editor.org/rfc/rfc6797.html
• Seznam HSTS preload in zahteve: https://hstspreload.org/
• RFC 9116, security.txt: https://www.rfc-editor.org/rfc/rfc9116.html
• securitytxt.org (izdelava in preverjanje): https://securitytxt.org/