Caddy, HSTS ja security.txt

Moodul 7: Domeen, veebiserver ja https · Lugemisaeg: 12 minutit

Õpieesmärk: Pärast seda õppetundi oskad kasutada Caddyt lihtsa veebiserverina automaatse https-iga. Oskad seadistada HSTS-i ja olulisemad turvapäised (Caddys ja nginxis) nii, et su sait ei muutu kättesaamatuks, ning avaldada kehtiva security.txt-faili.

Põhimõisted: Caddy, Caddyfile, automaatne 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 ilma muretsemata

Õppetundides 7.2 ja 7.3 ehitasid nginxi ja certbotiga https-iga saidi. Selleks oli vaja kahte programmi, paari faili ja taimerit. Caddy teeb kõik ühes: see on veebiserver, millel on sisseehitatud ACME-klient. Kui nimi on konfiguratsioonis, see osutab serverile ning pordid 80 ja 443 on kättesaadavad, hangib Caddy ise sertifikaadi, uuendab seda õigel ajal ja suunab http päringud https-ile.

Caddy on Debiani ja Ubuntu paketihoidlas (veidi vanem versioon). Tegijad pakuvad ka oma apt-hoidlat uusima versiooniga, oma võtme ja Signed-By-ga nagu õppetunnis 4.1. Moodulis 9 töötab Caddy konteinerina sinu Dockeri teenuste jaoks (õppetund 9.4). Siin kasutad seda tavalise teenusena.

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

Kasuta portidel 80 ja 443 kas nginxi või Caddyt, mitte mõlemat: porti saab kuulata ainult üks programm.

Caddyfile

Konfiguratsioon asub failis /etc/caddy/Caddyfile. Siin on staatiline sait ja pöördproksi taga olev rakendus:

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
}

See ongi kõik. Caddy kuulab ise nii IPv4 kui ka IPv6 kaudu ja taotleb kolmele nimele sertifikaadid. Ta suunab http päringud https-ile ja edastab reverse_proxy puhul päised X-Forwarded-For ja X-Forwarded-Proto ise (nginxis tegid seda käsitsi, õppetund 7.2).

Testimine ja uuesti laadimine käib nagu nginxi puhul:

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

Journalis näed sertifikaatide hankimist. Kui midagi läheb valesti, on põhjus seal kirjas. Tavaliselt on see sama mis certboti puhul: port 80 on suletud, nimi osutab mujale või IPv6 on katki (õppetund 7.3).

HSTS: lase brauseril meeles pidada, et sait on https

http-lt https-ile suunamisel on üks nõrk koht: kõige esimene päring http kaudu liigub veel krüptimata. Keegi samas võrgus saab selle kinni püüda ja hoida külastajat http peal. HSTS (HTTP Strict Transport Security, RFC 6797) lahendab selle. Su sait saadab https kaudu kaasa selle päise:

Strict-Transport-Security: max-age=31536000

Brauser jätab siis aastaks (31.536.000 sekundit) meelde, et seda nime tohib avada ainult https kaudu. Kui külastaja kirjutab hiljem http://, teeb brauser sellest ise https, enne kui midagi võrku läheb. HSTS-päist, mis tuleb http kaudu, brauser arvesse ei võta. See kehtib ainult https kaudu.

Sellel on ka varjukülg. Kui brauser on HSTS-i meelde jätnud ja näeb sertifikaadiviga (aegunud sertifikaat, vale nimi), ei saa külastaja mingit nuppu, et ikkagi edasi minna. Su sait on siis nende külastajate jaoks kättesaamatu, kuni sertifikaat on korras. Seepärast:

1. Lülita HSTS sisse alles siis, kui https töötab kõikjal ja uuendamine käib automaatselt (õppetund 7.3).
2. Alusta lühikese max-age-ga, näiteks ühe päevaga (86400), ja tõsta seda sammhaaval aastani.
3. Ole ettevaatlik valikuga includeSubDomains: see kehtib iga alamdomeeni kohta. See puudutab ka vana alamdomeeni, kus on seade või teenus ilma kehtiva sertifikaadita.
4. preload taotleb lisamist nimekirja, mis on brauseritesse sisse ehitatud (hstspreload.org). Selleks nõutakse muu hulgas vähemalt aasta pikkust max-age, valikut includeSubDomains ja https-i kõigil alamdomeenidel. Nimekirjast eemaldamine võtab kuid. Tee seda ainult siis, kui oled kindel, et kogu domeen jääb jäädavalt https-ile.

Teised turvapäised

Lisaks HSTS-ile on mõned päised, mis aitavad vähese vaevaga palju:

Täielik Content-Security-Policy (millised skriptid ja stiilid tohivad laadida) tuleb iga saidi jaoks eraldi koostada ja jääb sellest kursusest välja. Alusta ainult frame-ancestors-ga.

Caddys seadistad need header-direktiiviga saidi plokis:

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 ei lisa HSTS-i ega neid päiseid ise, need pead ise kirja panema. -Server eemaldab päise Server. Õppetunnis 9.4 lisad samasugusesse plokki ülesande jaoks oma päise X-Weboke-Cursus.

nginxis paned samad read pordi 443 server-plokki:

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 tagab, et päised saadetakse kaasa ka vealehtedega. Pane tähele nginxi tuntud lõksu: kui location-plokis endas on kasvõi üks add_header, ei kehti server-ploki add_header-read selle location'i jaoks enam. Seepärast kontrolli alati tulemust:

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: nii saab keegi sulle turvaaugust teada anda

Oletame, et keegi leiab su serverist turvaaugu, näiteks avatud kausta või aegunud teenuse. Kust see inimene teab, keda hoiatada? Selleks on security.txt (RFC 9116): väike tekstifail kindlas kohas, 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

Reeglid:

• Contact on kohustuslik: mailto:-, https://- või tel:-aadress, kuhu teated jõuavad. Kasuta aadressi, mida keegi ka päriselt loeb.
• Expires on kohustuslik ja tohib esineda ainult üks kord: see on kuupäev, millest alates faili loetakse aegunuks. RFC soovitab kuupäeva, mis jääb aasta sisse. Nii ei jää alles faili ammu unustatud aadressiga. Märgi kalendrisse, millal pead faili pikendama.
• Preferred-Languages, Canonical ja Policy (link sinu teadete käsitlemise põhimõtetele) on valikulised.
• Fail peab tulema https kaudu, lihttekstina (text/plain, UTF-8). Vana asukoht /security.txt on lisaks lubatud, kuid /.well-known/ on eelistatud.

Paigaldamine staatilise saidi puhul:

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

Kui kasutad nginxis õppetunni 7.2 püünisreeglit location ~ /\. { deny all; }, lisa selle ette erand: location ^~ /.well-known/ { }. Pöördproksi taga oleva rakenduse puhul saad Caddys suunata tee /.well-known/security.txt failile handle-ploki ja file_server abil.

Levinud viga: sait või rakendus vastab igale tundmatule teele avalehega ja olekuga 200. Siis security.txt "on olemas", aga tegelikult on see HTML. Kontrolli seega ka sisu.

AlmaLinuxis ja Rocky Linuxis

Seal tuleb Caddy tegijate hoidlast või EPEL/COPR-ist. Nagu nginxi puhul, peab SELinux pöördproksi lubama (setsebool -P httpd_can_network_connect 1). Caddyfile ja päised on samad.

Kokkuvõte

• Caddy hoolitseb ise sertifikaatide, uuendamise ja https-ile suunamise eest; reverse_proxy edastab õiged päised ise.
• HSTS paneb brauserid meeles pidama, et su sait töötab ainult https-iga. Tõsta max-age järk-järgult, ole ettevaatlik includeSubDomains-ga ja väga ettevaatlik preload-ga.
• Lisa ka X-Content-Type-Options: nosniff, frame-ancestors 'self' ja Referrer-Policy: Caddys header-ga, nginxis add_header ... always-ga. Kontrolli tulemust curl -I-ga.
• security.txt asub aadressil /.well-known/security.txt, tuleb https kaudu ja on lihttekst. Selles on kohustuslik Contact ja üks Expires, mis jääb aasta sisse.

Test

Ülesanne

Ülesanne Z7.4: HSTS, päised ja security.txt. Seadista oma saidile HSTS (vähemalt 180 päeva, pärast seda kui https on mõnda aega korralikult töötanud), X-Content-Type-Options: nosniff ja frame-ancestors 'self' (või X-Frame-Options). Avalda security.txt, milles on Contact ja aasta sisse jääv Expires. Sisesta oma hostinimi. Programm laadib https://<hostnaam>/ ja kontrollib päiseid ning laadib https://<hostnaam>/.well-known/security.txt ja kontrollib välju. See ei salvesta midagi peale tulemuse ja Expires-kuupäeva.

Loe edasi

• HSTS ja turvapäised sinu veebilehele
• Caddy, Automatic HTTPS: https://caddyserver.com/docs/automatic-https
• Caddy, header-direktiiv: https://caddyserver.com/docs/caddyfile/directives/header
• RFC 6797, HTTP Strict Transport Security: https://www.rfc-editor.org/rfc/rfc6797.html
• HSTS preload-nimekiri ja nõuded: https://hstspreload.org/
• RFC 9116, security.txt: https://www.rfc-editor.org/rfc/rfc9116.html
• securitytxt.org (loomine ja kontrollimine): https://securitytxt.org/