fa fi fi fi fi fa fi fi fi fi et fi fi fi fi et fi fi fi fi fi fi fi fi fi fi fi fi fi fi en fi en fi fi fi fi fi fi fi fi en fi fi fi fi es en en en fi en fi fi fi en fi fi fi fi fi fi fi fi fi fi fi fi en fi fi en en en fi en en en en en fi en kn ko ko kn kn en fi en en en kn kn fi en fi en en en en en en de en en kn et fi fi en hbs_lat en ro en en et fi en et fi en fi en fi en hbs_lat en en en en fi en fi en fi fi fi en fi en en en en fi fi fi fi en tt fi fi fi fi fi fi fi en fi fi en vi en kn en fi fi hbs_lat fi en fi fi fi fi it fi fi it fi fi uk fi fi fi uk fi fi fi fi uk fi fi en fi fi fi ne fi en fi de fi ru de ru fi fi fi fi fi fi fi en fi en en en en en en en en fi en en fi en en en fi en fi es fi en fi fi fi en en en fi fi fr fi fi fi fi fi fi en fi fi fi fi fi en fi fi fi fi fi fi fi fi fi fi fi
SSL = Secure Sockets Layer, TLS = Transport Layer Security. Periaatteessa TLS on uusi versio SSL:stä, käytännössä termiä ”SSL” käytetään geneerisenä molemmista.
Salakirjoitusprotokolla, perustuu ns. julkisen avaimen salakirjoitukseen (salaukseen käytetään myös symmetristä ts. jaetun salaisen avaimen salakirjoitusta).
Kaksi funktiota: autentikointi ja salaus.
Käytetään sekä palvelimen aitouden vermistamiseen että (harvemmin) toisinpäin, käyttäjän autentikoimiseen palvelimelle.
Itse allekirjoitettua sertifikaattia voi käyttää omien koneidensa välillä, ja muutenkin pelkkään salaukseen (ilman autentikointia), mutta nykyisin selaimet valittavat aggressiivisesti sertifikaateista, joita eivät tunnista.
Sertifikaatti voi olla yhdelle tai useammalle host-nimelle tai wildcard koko (ali)domainille (*.jyu.fi).
tunnistetietoja, erityisesti DN (Distinguished Name, tässä yhteydessä domain-nimi kuten ”kone.example.org”), erilaisia osoitetietoja mukaanlukien yhteyssähköpostiosoite, allekirjoitettuna sertifikaatin haltijan salaisella avaimella;
haltijansa julkisen avaimen, jota vastaavalla salaisella avaimella haltija voi todistaa sertifikaatin omakseen;
sertifikaatin myöntäjän salaisella avaimella tehdyn allekirjoituksen, jonka voi tarkistaa vastaavalla julkisella avaimella.
Ottaessaan yhteyden suojattuun palvelimeen asiakas (selain tms) ensin tarkistaa sertifikaatin aitouden hallussaan olevalla myöntäjän julkisella avaimella ja sitten varmistaa palvelimen aitouden sertifikaatissa olevalla haltijan julkisella avaimella.
Vastaavasti asiakassertifikaattia käytettäessä palvelin tarkistaa sen hallussaan olevalla julkisella avaimella
Autentikointi siis edellyttää, että käyttäjä (selain tms) tuntee entuudestaan julkisen avaimen, jolla palvelimen sertifikaatti (avain) on allekirjoitettu (tai avaimen, jolla on allekirjoitettu avain, jolla se on allekirjoitettu… ketju voi olla pitkä). Sertifikaattien myöntäjien pitää siis saada oma julkinen avaimensa kaikkiin (yleisiin) selaimiin, mikä yleensä maksaa.
(1) Hakija luo itselleen avainparin (julkisen ja salaisen avaimen) ja
(2) sertifikaattipyynnön (Certificate Signing Request), joka sisältää hakijan tunnistetiedot sekä julkisen avaimen allekirjoitettuna salaisella avaimella, ja
(3) sertifikaatin myöntäjä (tarkistettuaan enemmän tai vähemmän luotettavasti hakijan tiedot) allekirjoittaa CSR:n omalla salaisella avaimellaan ja luo siten siitä sertifikaatin (CRT) ja toimittaa sen hakijalle.
Sertifikaatin käyttö siis edellyttää vastaavan salaisen avaimen hallussapitoa. Jos salainen avain kaapataan, kaappari voi esiintyä sen haltijana kunnes sertifikaatti revokoidaan eli tehdään mitättömäksi: myöntäjä ylläpitää listaa revokoiduista avaimista, jota käyttäjien (ohjelmien) pitäisi seurata. Käytännössä kaapattua avainta voi usein käyttää kunnes se vanhenee (hyvä syy sertifikaattien määräaikaisuudelle).
Avainten ja sertifikaattien hallintaan käytetään komentorivityökalua openssl
Oma avainpari luodaan tähän tapaan:
openssl genpkey -algorithm RSA -out oma.pem -aes-256-cbc -pkeyopt rsa_keygen_bits:4096
Syntyneen avainparin salaisen avaimen (molemmat avaimet ovat samassa tiedostossa) käyttö edellyttää aina sen passphrasen syöttämistä. Jos sitä ei haluta syöttää aina kun www-palvelin käynnistyy, luodaan siitä suojaamaton versio:
openssl rsa -in oma.pem -out oma.key
Syntynyt tiedosto sisältää sekä salaisen että julkisen avaimen. Sillä voi nyt luoda CSR:n tähän tapaan:
openssl req -new -key oma.key -out oma.csr
CSR lähetetään sertifikaatin myöntäjälle (certificate authority), joka palauttaa sitä vastaavan sertifikaatin (esim. oma.crt).
Tiedostojen nimikonventiot ja muukin terminologia vaihtelevat, erityisesti *.pem ja *.key voivat sisältää milloin mitäkin.
Sertifikaattien myöntäjillä on yleensä myös web-työkaluja sertifikaattien käsittelyyn.
Testaamiseen ja omien koneiden välisiin yhteyksiin voi käyttää itse allekirjoitettua sertifikaattia. Se tapahtuu yksinkertaisesti allekirjoittamalla luotu CSR omalla avaimella:
openssl x509 -req -days 365 -in oma.csr -signkey oma.key -out oma.crt
Allekirjoitusta varten voisi myös luoda eri avaimen (esim. yrityksen oman, jota vastaava julkinen avain sitten talletettaisiin työntekijöiden koneisiin)
Nykyisin selaimet yleensä valittavat ikävännäköisesti itseallekirjoitetuista selaimista, sähköpostipalvelimille ne kelpaavat paremmin.
Kummassakin tapauksessa avain ja sertifikaatti talletetaan; paikka on periaatteessa vapaa, tässä Ubuntun oletus:
Ubuntun openssl-paketin asennus luo samalla itseallekirjoitetun ”snakeoil” -sertifikaatin tiedostoihin /etc/ssl/private/ssl-cert-snakeoil.key ja /etc/ssl/certs/ssl-cert-snakeoil.pem, joita voi myös käyttää testaukseen.
Letsencrypt.org on ilmainen sertifikaattipalvelu, jonka käyttö on yritetty tehdä mahdollisimman helpoksi sertifikaattien automaattista uusimista myöten.
Käyttö edellyttää joko domainin nimipalveluun tai siellä olevan www-palvelimen juureen pääsyä; jälkimmäinen toimii vain jos nimipalvelu ei estä sitä CAA-tietueella (Certificate Authority Authorization).
Palvelimen pitää näkyä maailmalle sertifikaattia luotaessa ja uusittaessa (letsencrypt ei kerro mistä osoitteista käsin se ne tarkistaa). Sertifikaatin voi myös luoda eri koneessa kuin missä sitä käytetään mutta se on hieman hankalaa.
https = http SSL:n yli, salattuna ja autentikoituna (teknisesti aina molemmat)
Käyttää oletuksena porttia 443.
Alunperin käytti vain IP:tä ts. virtual hostit eivät toimineet (URL välitettiin vasta SSL-kättelyn jälkeen); sitä varten kehitettiin laajennus SNI (Server Name Indication), kaikki melkeinkin uudet selaimet tukevat sitä nykyisin.
Asennus erilainen eri palvelinohjelmille, mutta perusaskeleet samat.
hankitaan sertifikaatti ja asennetaan se ja vastaava salainen avain sopiviin paikkoihin
lisäksi voidaan tarvita allekirjoitusketjutiedosto
ohjelmasta riippuen em. tiedostoja voi joutua yhdistelemään eri tavoin
konfiguroidaan palvelinohjelma käyttämään https:ää (usein saman tien pakko-ohjataan http-yhteydenotot https:ään)
avataan asianomaisiin palomuureihin tarvittavat reiät
testataan että kaikki toimii (mielellään usealla eri selaimella)
laitetaan kalenteriin muistutus sertifikaatin vanhenemispäivästä (voimassaoloaika vaihtelee, useimmiten yksi vuosi), että muistetaan hakea uusi ajoissa (ellei automatisoitu)
Lighttpd haluaa avaimen ja sertifikaatin samassa tiedostossa.
Ubuntun mukana tulleella käärmeöljysertifikaatilla:
cat /etc/ssl/private/ssl-cert-snakeoil.key /etc/ssl/certs/ssl-cert-snakeoil.pem >/etc/lighttpd/server.pem
Edellä itsetehdyllä sertifikaatilla vastaavasti:
cat /etc/ssl/private/oma.key /etc/ssl/certs/oma.crt >/etc/lighttpd/server.pem
Haluttaessa https usealle virtual hostille eri sertifikaateilla (/etc/lighttpd/conf-available/... -tiedostoon):
$SERVER["socket"] == ":443" {
ssl.pemfile = "/etc/lighttpd/server.pem" # oletus
$HTTP["host"] == ”tt1.student.it.jyu.fi" {
$HTTP["host"] == "s019.vm.it.jyu.fi" {
Jos halutaan pakottaa kaikki liikenne käyttämään SSL:ää (yleensä hyvä idea):
$HTTP["scheme"] = "http" {
$HTTP["host"] =~ ".*' {
url.redirect = (".*" => "https://%0$0")
Ohjauksen voi tehdä valikoidenkin jos jostain syystä haluaa jakaa jonkin URLin http:nä.
Lisäoptioita tietoturvan parantamiseksi (esimerkki):
server.modules += ( "mod_setenv" )
$HTTP["scheme"] == "https" {
setenv.add-response-header = ( "Strict-Transport-Security" => "max-age=63072000; includeSubdomains; ")
# avaa palomuurissa portit 80 ja 443, myös ulospäin
certbot certonly --webroot -d ties478.site
ln -sf $PWD/ties478.site/server.pem /etc/lighttpd
Automaattinen päivitysskripti /etc/cron.d/certbot ei toimi lighttpd:n kanssa, koska sertifikaatit pitää yhdistää samaan tiedostoon. Korjataan esim. tähän tapaan (polut vaihtelevat):
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew && cat /etc/letsencrypt/live/ties478.site/{cert,privkey}.pem >/etc/lighttpd/server.pem
Jos sertifikaatteja on (tai voi olla) useita ne voidaan käsitellä kaikki tähän tapaan:
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew && for d in /etc/letsencrypt/live/*/cert.pem; do cat $d ${d%cert.pem}privkey.pem >${d%cert.pem}server.pem; done
Sertifikaattipolkujen pitää olla samat vastaavissa /etc/lighttpd/conf-enabled/* -määrittelytiedostoissa
Nginx:n https-konfiguraatiossa tarvitaan minimissään seuraavantapaiset rivit server{} -blokkiin:
Siis sertifikaatti ja salainen avain eri tiedostoissa.
Jos halutaan pakottaa kaikki liikenne käyttämään SSL:ää, laitetaan http-blokkiin (jossa on listen 80) sääntö tyyliin
certbot osaa tehdä tämän automaattisesti
80-portin voi myös sulkea kokonaan, mutta yleensä se ei ole hyvä idea.
Mahdollista on myös jakaa http:llä eri sisältöä kuin https:llä mutta se on harvoin järkevää.
Nginx:n https-konfiguraatiossa voi (ja kannattaa) myös tehdä tietoturvasäätöjä (ei kattava lista):
Erityisesti ssl_protocols -rivi on suositeltava (poistaa käytöstä vanhat, turvattomat protokollat); TLSv1.2:n voinee jo jättää poiskin
Syytä tarkistaa säännöllisesti uusien tietoturva-aukkojen varalta, ks. esim. https://wiki.mozilla.org/Security/Server_Side_TLS, https://safeciphers.org/
Letsencryptin certbot on nykyisin Ubuntun vakiorepositoryssä, joten asennus on helppo:
Porttien 80 ja 443 pitää taas olla auki myös ulospäin
Osaa yleensä muuttaa konfiguraation automaattisesti (kysyy halutaanko sitä), em. tietoturvasäädöt pitää lisätä sen jälkeen käsin
Automaattipäivitys toimii ilman eri säätöä
Proxy-konfiguraatiossa (reverse) proxyn pitää hoitaa SSL, proxyn ja taustapalvelinten liikennettä ei yleensä tarvitse salata. Maailman ja proxyn välinen liikenne siis SSL-suojattua portin 443 kautta, proxyn ja taustapalvelinten välinen suojaamatonta portin 80 kautta eikä taustapalvelinten välttämättä tarvitse tietää SSL:stä mitään, ellei jokin niissä pyörivä ohjelma sitä erityisesti kaipaa.
Jos taustapalvelimessa pyörivän ohjelman pitää tietää käyttävänsä SSL:ää (esim. WordPress), sille pitää välittää tieto siitä lisäheaderilla (miten, riippuu www-palvelinohjelmasta):
X-Forwarded-Proto: "https" (vanha, standardoimaton)
Forwarded: proto="https" (RFC 7239, ei kaikkialla tuettu)
ja kertoa siitä ohjelmalle, esim. wp-config.php (WordPress):
”identity daemon”: kertoo kuka (käyttäjä) tulee tietystä portista
Käyttää tcp-porttia 113, avattava palomuurissa, esim.
iptables -A INPUT -p tcp --dport 113 -j ACCEPT
Vanha, ei nykyisin kovinkaan hyödyllinen tietoturvamekanismina, käyttäjätietoon ei voi luottaa (saattaa paljastaa osoitekaappauksia joskus, erityisesti jos identd vastaa mutta ei kerro käyttäjää (tcp-wrapperissa UNKNOWN@host) on syytä epäillä IP-spoofausta)
Nykyisin hyödyllinen lähinnä IRC-käyttäjille, voi olla käyttökelpoinen omassa verkossa tcp wrapperin kanssa muutenkin.
nullidentd: triviaalitoteutus, ei kerro oikeita käyttäjätunnuksia vaan vakion tai satunnaisen
oidentd: yleinen, hyvin ylläpidetty, monipuolinen (käyttäjien voi antaa säätää omaa vastaustaan), konfiguraatiotiedosto /etc/oidentd.conf
inetd (”Internet super server daemon”) on ohjelma (demoni), joka kuuntelee useita tcp- ja udp-portteja ja liikennettä havaitessaan käynnistää ko. portille määritellyn ohjelman (demonin).
Säästää muistia jos ko. palvelua ei tarvita koko aikaa (modernit virtuaalimuistiratkaisut tekevät tämän aika turhaksi) ja yksinkertaistaa niiden koodaamista, kun niiden ei itse tarvitse osata verkkoprotokollia vaan inetd välittää niille yhteyden stdin'in ja stdout'in kautta ja tarjoaa tcp wrapper -toiminnallisuuden myös.
Useita toteutuksia, jotka tarjoavat useita saman perustoiminnallisuuden plus vaihtelevasti muuta, Linux-ympäristöissä mm. xinetd. Alkuperäinen ”inetd” on lähes kadonnut ja sanaa käytetään yleisterminä sen toiminnallisuudelle. Nykyisin systemd sisältää inetd'n ominaisuudet ja muut toteutukset ovat ovat lähes kadonneet.
Monet yleiset demonit voi konfiguroida toimimaan joko itsenäisinä tai inetd'n kautta. Useat inetd-toteutukset tarjoavat joitakin palveluita sisäisestikin (tyypillisesti ainakin echo ja discard).
TCP Wrapper on yleinen mekanismi (kirjasto), jolla sisääntulevia yhteyksiä voidaan kontrolloida (nimestään huolimatta se toimii UDP-palveluidenkin kanssa).
Toiminnallisuus samankaltainen kuin iptables input filter, mutta toimii ylemmällä tasolla (application layer) ja voi suodattaa sovelluskohtaisesti säännöillä, joita pakettifiltteri ei näe (esim. käyttäjäkohtaisesti, myös salattuja yhteyksiä jne).
Toiminta edellyttää, että ao. sovellus käyttää inetd:tä tai siinä itsessään on libwrap-kirjasto mukana. Yleisten palveluiden kuten ssh ja ftp kanssa se toimii.
Joskus samat (konekohtaiset) rajoitukset tehdään sekä pakettifiltterillä että tcp wrapperilla: jos yhteys ei toimi, tarkista molemmat.
Etäkäyttäjän tunnistamiseen käytetään identd:tä, joka ei useinkaan ole käytettävissä, ja silloin käyttäjäkohtaiset rajoitukset eivät toimi.
Konfiguraatiotiedostojen muuttaminen vaikuttaa heti, niitä ei tarvitse erikseen ladata eikä sovelluksia tarvitse käynnistää uudelleen.
Ei kannattane enää uusissa asennuksissa käyttää.
TCP Wrapperin säännöt kirjoitetaan tiedostoihin /etc/hosts.allow ja /etc/hosts.deny. Ensin luetaan hosts.allow, jos sieltä löytyy salliva sääntö yhteys sallitaan saman tien, ellei, luetaan hosts.deny ja jos ei löydy kieltävää sääntöä yhteys taas sallitaan.
Molempien tiedostojen syntaksi on samanlainen:
daemon_list : client_list [: shell_command ]
daemon_list määrää palvelut joita sääntö koskee sitä ohjaavan demoniprosessin nimellä kuten ps sen näyttää, esim. sshd
client_list tarkoittaa koneita tai verkkoalueita, joita sääntö koskee; käyttäjäkohtainen sääntö voidaan tehdä syntaksilla user@host
shell_command on komento, joka suoritetaan täsmäävälle säännölle
Jos halutaan sallia kaikki mitä ei ole erikseen kielletty (blacklisting): ei lainkaan hosts.allow -tiedostoa ja kiellot hosts.deny -tiedostoon, esim.
Jos halutaan kieltää kaikki mitä ei ole erikseen sallittu (whitelisting), tehdään hosts.deny yksinkertaisesti näin:
ja luetellaan sallitut hosts.allow -tiedostossa:
vsftpd tftpd: ALL EXCEPT 134.170.
Voidaan salata koko levy, levyosio, tiedosto, LVM:n alla LV tai PV, RAID-pakka… ehkä yleisintä salata LV tai osio
Usein salataan kaikki paitsi /boot, nykyisin senkin voi salata kun grub osaa avata salauksen. VM-alustakoneessa voi jättää käyttöjärjestelmän salaamatta ja salata vain virtuaalikoneiden levyimaget tai niitä sisältävät tiedostojärjestelmät.
Myös swap pitää salata jos sitä käytetään.
Perustyökalu cryptsetup, yleisin käyttötapa LUKS.
Salausavain komentoriviltä tai tiedostosta.
Tehdään salattu /sala omana LV:nään:
lvcreate -n sala -L 100M vg_tt2
cryptsetup luksOpen /dev/vg_tt2/sala sala_crypt
mkfs -t ext4 /dev/mapper/sala_crypt
Salatun levyn "sulkeminen" käytön jälkeen:
Salausavaimen lisäys, vaihto, poisto:
cryptsetup luksAddKey [options] /dev/tt_vg/crypt
cryptsetup luksChangeKey [--keyslot...] /dev/tt_vg/crypt
cryptsetup luksRemoveKey [--keyslot...] /dev/tt_vg/crypt
viimeisen (ainoan) avaimen poisto tekee levystä pysyvästi lukukelvottoman!
Käyttöönoton helpottamiseksi jatkossa laitetaan tiedostoon /etc/crypttab rivi
sala_crypt /dev/tt1_vg/sala none luks
/dev/mapper/sala_crypt /sala ext4 defaults 0 0
Usein halutaan molempiin optio "noauto", että koneen saa bootattua ilmankin
lvextend -L+100M /dev/tt_vg1/sala # ei -r:ää!
resize2fs /dev/mapper/sala_crypt # tai xfs_growfs tai ...
RAID (Redundant Array of Inexpensive Disks) on mekanismi, jolla useita (halpoja) levyjä yhdistämällä parannetaan turvaa levyvaurioiden varalta ja/tai levyjärjestelmän suorituskykyä. Mahdollistaa myös fyysisiä levyjä isompien tiedostojärjestelmien luomisen ilman LVM:ää (yleensä LVM on parempi siihen).
Virtuaalikoneissa RAIDia ei juurikaan käytetä (muuten kuin ehkä harjoittelumielessä), virtuaalikonealustoissa kylläkin.
Useita tasoja, jotka eroavat vaurionsietokyvyn, nopeuden ja kapasiteetin suhteen, mm.
RAID0: nopea, ei hukkaa levytilaa, ei suojaa mitään (yhden levyn särkyminen hukkaa kaiken)
RAID1 eli peilaus, kaikki data joka levyllä, paras suoja, syö paljon tilaa, nopeuttaa lukemista, ei juurikaan hidasta kirjoittamista
RAID5: nopea lukea mutta hidas kirjoittaa, kohtalainen suoja (kestää yhden levyn särkymisen), vie vähän tilaa (yhden levyn per pakka)
RAID6: nopea lukea, hidas kirjoittaa, hyvä suoja (kestää kahden levyn särkymisen), vie kohtalaisesti tilaa (kaksi levyä per pakka)
RAID10 (tai 1+0): nopea sekä lukea että kirjoittaa, hyvä suoja (jopa puolet levyistä saa särkyä), vie paljon tilaa (puolet levyistä)
Usein lisänä "hot spare".
Toteutus voi olla levyohjainkortin firmwaressa (”rautaraid”) tai käyttöjärjestelmätasolla (”softaraid”).
Isojen levyjen kanssa etenkin RAID5 hieman turvaton, levyn vaihto särkyneen tilalle kestää kauan ja toisenkin levyn särkymisriski sen aikana voi olla merkittävä.
LVM sisältää softaraid-toiminnallisuutta, mutta rajoitetusti eikä sitä usein Linux-ympäristöissä käytetä.
Linuxin standardisoftaraid nykyisin on md, komentorivityökalu mdadm
Boottaaminen onnistuu md-pakalta raid1:n kanssa, edellyttää huolellisuutta grub-konfiguraation kanssa. Muiden raid-tasojen kanssa bootti ei yleensä ole mahdollista.
md:n alla olevat levyt voivat olla myös levyosioita eivätkä vain kokonaisia levyjä. Samojen levyjen eri osioiden RAIDaaminen eri tavoin voi olla järkevää em. boottirajoituksen takia.
md:n alla levyt voi vaihtaa isompiinkin ja ottaa koko tilan käyttöön lennosta (ei yleensä onnistu rautaraidilla).
md:n käytön voi todeta (pseudo)tiedostosta /proc/mdstat ja sen (bootti)konfiguraation tiedostosta /etc/mdadm/mdadm.conf
RAID + LVM + salaus
LVM:n kanssa yleensä tehdään RAID-pakoista PV:tä. Salaus voidaan tässä kuviossa tehdä monessa eri kohdassa:
Salataan tiedosto salaamattomassa LV:ssä (mdadm → pvcreate → vgcreate → lvcreate → mkfs → cryptsetup ...)
Salataan LV salaamattoman VG:n sisällä (mdadm → pvcreate → vgcreate → lvcreate → cryptsetup → mkfs ...)
Salataan RAID-pakat ja tehdään niistä PV:t, niiden päälle VG (mdadm → cryptsetup → pvcreate → vgcreate → ...)
Salataan fyysiset levyt RAIDin alla (cryptsetup → mdadm → pvcreate → ...)
Yleensä pari ensinmainittua ovat parhaita (ja viimeinen mielekäs harvoin, lähinnä vain jos levyissä on jokin oma rautasalausratkaisu).