Caddy, HSTS és security.txt

Modul 7: Domain, webszerver és https · Olvasási idő: 12 perc

Tanulási cél: A lecke végére Ön képes lesz a Caddyt egyszerű, automatikus https-sel működő webszerverként használni, a HSTS-t és a legfontosabb biztonsági fejléceket beállítani (Caddyben és nginxben) úgy, hogy a webhelye elérhető maradjon, valamint érvényes security.txt fájlt közzétenni.

Kulcsfogalmak: Caddy, Caddyfile, automatikus 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 gond nélkül

A 7.2. és a 7.3. leckében nginx és certbot segítségével épített egy https-es webhelyet. Ez két program, néhány fájl és egy időzítő. A Caddy mindezt egyben tudja: beépített ACME-klienssel rendelkező webszerver. Ha egy név szerepel a konfigurációban, erre a szerverre mutat, és a 80-as és 443-as port elérhető, akkor a Caddy maga szerzi be a tanúsítványt, időben megújítja, és a http-t átirányítja https-re.

A Caddy megtalálható a Debian és az Ubuntu csomagforrásában (kissé régebbi verzióban); a fejlesztők saját apt-forrást is kínálnak a legújabb verzióval, saját kulccsal és Signed-By beállítással, ahogy a 4.1. leckében. A 9. modulban a Caddy konténerként fut a Docker-szolgáltatásai előtt (9.4. lecke). Itt hagyományos szolgáltatásként használjuk.

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

A 80-as és 443-as porton vagy nginxet, vagy Caddyt használjon, ne mindkettőt: egy porton csak egy program figyelhet.

A Caddyfile

A konfiguráció a /etc/caddy/Caddyfile fájlban található. Egy statikus webhely és egy reverse proxy mögötti alkalmazás:

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
}

Ennyi az egész. A Caddy magától figyel IPv4-en és IPv6-on, tanúsítványt kér a három névre, átirányítja a http-t https-re, és reverse_proxy esetén magától továbbítja a X-Forwarded-For és X-Forwarded-Proto fejlécsorokat (amit nginxben kézzel állított be, 7.2. lecke).

A tesztelés és az újratöltés ugyanúgy megy, mint nginx esetén:

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

A naplóban (journal) látja a tanúsítványok beszerzését. Ha valami nem sikerül, ott áll az ok is: többnyire ugyanaz, mint a certbotnál (a 80-as port zárva, a név máshová mutat, hibás az IPv6; 7.3. lecke).

HSTS: a böngésző jegyezze meg, hogy https

A http átirányítása https-re egy gyenge ponttal jár: a legelső, http-n érkező kérés még titkosítatlan. Valaki ugyanazon a hálózaton ezt elfoghatja, és a látogatót http-n tarthatja. Erre ad megoldást a HSTS (HTTP Strict Transport Security, RFC 6797). A webhelye https-en keresztül ezt a fejlécsort küldi:

Strict-Transport-Security: max-age=31536000

A böngésző ekkor egy évig (31.536.000 másodpercig) megjegyzi, hogy ez a név csak https-en érhető el. Ha a látogató később beírja, hogy http://, a böngésző maga alakítja https-re, még mielőtt bármi a hálózatra kerülne. A http-n érkező HSTS-fejlécet a böngésző figyelmen kívül hagyja; csak https-en számít.

Ennek van árnyoldala is. Ha egy böngésző megjegyezte a HSTS-t, és tanúsítványhibát lát (lejárt, rossz névre szól), akkor a látogató nem kap gombot a továbblépéshez. A webhelye ezeknek a látogatóknak elérhetetlen, amíg a tanúsítvány rendbe nem jön. Ezért:

1. Csak akkor kapcsolja be a HSTS-t, ha a https mindenhol működik, és a megújítás automatikus (7.3. lecke).
2. Kezdjen rövid max-age értékkel, például egy nappal (86400), és lépésenként növelje egy évre.
3. Legyen óvatos a includeSubDomains beállítással: ez minden aldomainre vonatkozik, egy régi aldomainre is, amelyen érvényes tanúsítvány nélküli eszköz vagy szolgáltatás fut.
4. A preload egy böngészőkbe beépített listára való felvételt kér (hstspreload.org). Ehhez többek között legalább egyéves max-age, includeSubDomains és minden aldomainen https szükséges. A listáról lekerülni hónapokig tart. Csak akkor tegye meg, ha biztos benne, hogy a teljes domain végleg https marad.

A többi biztonsági fejléc

A HSTS mellett van néhány fejlécsor, amely kevés munkával sokat segít:

Egy teljes Content-Security-Policy (mely szkriptek és stílusok tölthetők be) webhelyenként egyedi munka, és túlmutat ezen a tanfolyamon; kezdje csak a frame-ancestors beállítással.

Caddyben ezeket a header direktívával állítja be egy webhely blokkjában:

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
	}
}

A Caddy a HSTS-t és ezeket a fejlécsorokat nem állítja be magától; ezeket tehát valóban bele kell írnia. A -Server eltávolítja a Server fejlécsort. A 9.4. leckében ugyanilyen blokkban állítja be a saját X-Weboke-Cursus fejlécsorát a feladathoz.

nginxben ugyanezeket a sorokat a 443-as port server blokkjába írja:

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;

Az always gondoskodik arról, hogy a hibaoldalakon is elküldésre kerüljenek. Figyeljen az nginx egy ismert csapdájára: ha egy location blokkban magában is szerepel egy add_header, akkor a server blokk add_header sorai arra a location-re már nem érvényesek. Ezért mindig ellenőrizze az eredményt:

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: így jelezhetik Önnek a sebezhetőségeket

Tegyük fel, hogy valaki sebezhetőséget talál a szerverén, például egy nyitott mappát vagy egy elavult szolgáltatást. Honnan tudja, kit kell értesítenie? Erre szolgál a security.txt (RFC 9116): egy kis szövegfájl egy rögzített helyen, 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

A szabályok:

• A Contact kötelező: egy mailto:, https:// vagy tel: cím, ahová a bejelentések érkeznek. Olyan címet adjon meg, amelyet valaki ténylegesen olvas.
• Az Expires kötelező, és csak egyszer szerepelhet: az a dátum, amely után a fájl elavultnak számít. Az RFC egy éven belüli dátumot javasol. Így nem marad fenn olyan fájl, amelyben egy rég elfelejtett cím áll. Jegyezze fel a naptárába, mikor kell meghosszabbítania.
• A Preferred-Languages, Canonical és Policy (egy link a bejelentésekre vonatkozó irányelveihez) nem kötelező.
• A fájlnak https-en kell érkeznie, egyszerű szövegként (text/plain, UTF-8). A régi hely, /security.txt, kiegészítésként használható, de a /.well-known/ az elsődleges.

Elhelyezés statikus webhely esetén:

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

Ha nginxben a 7.2. lecke location ~ /\. { deny all; } védőhálóját használja, tegyen elé egy kivételt: location ^~ /.well-known/ { }. Reverse proxy mögötti alkalmazás esetén Caddyben a /.well-known/security.txt útvonalat egy handle blokkal és file_server segítségével egy fájlra irányíthatja.

Gyakori hiba: egy webhely vagy alkalmazás minden ismeretlen útvonalra a kezdőlappal és 200-as állapotkóddal válaszol. Ilyenkor a security.txt "létezik", de valójában HTML. Ezért a tartalmat is ellenőrizze.

AlmaLinux és Rocky Linux esetén

Ott a Caddy a fejlesztők forrásából vagy az EPEL/COPR-ból érhető el. Ahogy az nginx esetén, a SELinuxnak itt is engedélyeznie kell a reverse proxyt (setsebool -P httpd_can_network_connect 1). A Caddyfile és a fejlécek ugyanazok.

Összefoglalás

• A Caddy maga intézi a tanúsítványokat, a megújítást és a https-re való átirányítást; a reverse_proxy magától továbbítja a megfelelő fejlécsorokat.
• A HSTS-sel a böngészők megjegyzik, hogy a webhelye csak https-en érhető el; a max-age értéket fokozatosan növelje, legyen óvatos a includeSubDomains és nagyon óvatos a preload beállítással.
• Ezenkívül állítsa be a X-Content-Type-Options: nosniff, a frame-ancestors 'self' és egy Referrer-Policy fejlécet; Caddyben a header, nginxben az add_header ... always segítségével, és ellenőrizze ezzel: curl -I.
• A security.txt a /.well-known/security.txt helyen található, https-en, egyszerű szövegként, kötelező Contact mezővel és egyetlen, egy éven belüli Expires mezővel.

Kvíz

Feladat

Feladat Z7.4: HSTS, fejlécek és security.txt. Állítsa be a webhelyén a HSTS-t (legalább 180 napra, miután a https egy ideje hibátlanul működik), a X-Content-Type-Options: nosniff és a frame-ancestors 'self' (vagy X-Frame-Options) fejlécet, és tegyen közzé egy security.txt fájlt Contact mezővel és egy éven belüli Expires mezővel. Adja meg a gépnevét. A program lekéri a https://<hostnaam>/ címet, és ellenőrzi a fejlécsorokat, majd lekéri a https://<hostnaam>/.well-known/security.txt címet, és ellenőrzi a mezőket. Az eredményen és az Expires-dátumon kívül semmit nem tárol.

További olvasnivaló

• HSTS és biztonsági fejlécek a weboldalához
• Caddy, Automatic HTTPS: https://caddyserver.com/docs/automatic-https
• Caddy, header direktíva: https://caddyserver.com/docs/caddyfile/directives/header
• RFC 6797, HTTP Strict Transport Security: https://www.rfc-editor.org/rfc/rfc6797.html
• A HSTS preload lista és a követelmények: https://hstspreload.org/
• RFC 9116, security.txt: https://www.rfc-editor.org/rfc/rfc9116.html
• securitytxt.org (létrehozás és ellenőrzés): https://securitytxt.org/
• security.txt elhelyezése a weboldalán
• VPS: az első bejelentkezéstől a biztonságos szerverig 5.1: Caddy: weboldal automatikus https-sel