Neljännet tehtävät – julkisen virtuaalipalvelimen ja domain-nimen vuokraaminen ja käyttö

Aikaisemmista viikoista poiketen suurimman osan tämän viikon tehtävistä teimme jo edellisen oppitunnin aikana. Tästä syystä teen tällä kertaa raportointini suurimmaksi osaksi muistinvaraisesti. Ehdin jo ennen tehtävien lukemista hankkia omalle domainilleni SSL-sertifikaatinkin, ja huomasin vasta myöhemmin sen kuuluvan vapaaehtoisiin tehtäviin. Tämän viikon tehtävät eivät myöskään etene mielestäni missään erityisessä järjestyksessä, joten normaalien tehtävänumeroiden (tai kirjainten) sijasta käytän kuvaavampia väliotsikoita.

Virtuaalipalvelimen vuokraaminen ja käyttöönotto

Virtuaalipalvelimen vuokraaminen on kätevää ja kannattavaa, mikäli haluaa saada omaa sisältöään, kuten kotisivut, nettiin. Korvaava vaihtoehto voisi olla esimerkiksi oman palvelinkoneen kasaaminen ja sen kotona pyörittäminen. Tämä kuitenkin vaatii jonkinlaista rautapuolen osaamista sekä isompaa alkuinvestointia. Tämän lisäksi palvelimen on koko ajan oltava nettiyhteyden päässä ja sähköpistokkeessa kiinni. Tällaisessa tapauksessa esimerkiksi satunnainen sähkökatkos tai koneen rikkoutuminen johtaisivat siihen, etteivät vierailijat pääsisi kotisivulle normaaliin tapaan. Virtuaalipalvelimia vuokraavilla tahoilla puolestaan on omistuksessaan valtavia palvelinsaleja, joiden turvallisuudesta huolehditaan, ja esimerkiksi raudan rikkoutuessa palvelimen käyttäjän ei tarvitse itse ratkaista tilannetta.

Oman palvelimeni vuokrasin DigitalOceanilta, joka kutsuu omia virtuaalipalvelimiaan dropleteiksi. Palvelimen vuokraaminen edellyttää tunnusten luomista ja joko korttitietojen antamista tai Paypal-tunnusten käyttöä. Itse olen opiskelija, joten aktivoin aluksi oman Github Education Pack:ini, jonka mukana tulee mm. viidenkymmenen dollarin kuponki DigitalOceanin sivuille. Tämän kertaluontoisen kupongin saa aktivoitua syöttämällä annetun koodin DigitalOceanin sivuilla olevan Account-välilehden Billing-kohtaan. Kortiltani ei siis velotettu vuokraamisen yhteydessä mitään, vaan maksu otettiin saamastani saldosta.

Education Packia hakiessani täytin lomakkeen, jossa kysyttiin mm. valmistumisvuottani, ja sitä, missä opiskelen. Täytin lomakkeen mielestäni kokonaan, mutta olinkin vahingossa jättänyt yhden kentän tyhjäksi. Yrittäessäni lomakkeen lähetystä sain virheilmoituksen tyhjästä kentästä, ja kyseisen kentän täytettyäni lähetin lomakkeen uudestaan. Samalla sekunnilla kuin painoin lähetyspainiketta huomasin, että esimerkiksi valmistumisvuoteni oli vaihtunut valitsemastani vuodesta 2020 takaisin vuoteen 2019. En tiedä, saako aikaa jatkettua enää myöhemmin, joten halusin mainita tämän törttöilyni varoituksena muille. Olen ilmeisesti liian tottunut siihen, että yleensä virheilmoituksen saamisen yhteydessä virheettömästi täytetyt kentät eivät palaudu oletusarvoihinsa.

Tietojen syöttämisen jälkeen oli aika siirtyä itse palvelimen luomiseen valitsemalla DigitalOcean-sivun yläpalkista create -> new droplet. Suurin osa oletusasetuksista oli ihan käypää kamaa, mutta muutamia asioita muutimme. Käyttöjärjestelmäksi valitsimme jo itsellemme tutun Ubuntu 18.04.01:n ja automaattisesti ehdotetun koon vaihdoimme pienimpään mahdolliseen, sillä pienempi tila riittää peruskäyttöön aivan hyvin ja tarpeen tullessa sitä on helppo hankkia lisää. Datacenterin sijainniksi oli mielekästä valita Frankfurt, sillä ainoa toinen Euroopassa sijaitseva vaihtoehto on Lontoo, ja Brexit-sekoilut kannattaa ottaa tässä tilanteessa huomioon varmuuden vuoksi. Hostname-kohtaan kannattaa valita esimerkiksi jokin yksinkertainen sana. Tämä hostname tulee näkymään esimerkiksi terminaalissa silloin kun olet ottanut SSH-yhteyden kyseiseen palvelimeen. Omaksi host-nimekseni valitsin horsman, sillä se oli edesmenneen kotikoneeni nimi, ja nyt minulle tuli mahdollisuus pitää horsman muisto elossa :D Itselläni näkyisi terminaalissa siis helkera@horsma.

Sen jälkeen kun asetukset on saatu kuntoon, klikataan create-painiketta. Rekisteröityessä käytettyyn sähköpostiin ilmestyy tämän jälkeen viesti, jossa on luodun palvelimen tiedot, esimerkiksi yhteyden muodostamiseen tarvittava root-salasana. Palvelimen käyttöönottoon liittyvät hyvät ohjeet löytyvät opettajamme kotisivuilta, joten en itse kerro kyseisestä prosessista tässä kirjoituksessa. Ohjeissa ei käydä läpi Apachen asentamista, mutta sen taas tein edellisessä päivityksessäni, jossa kerron myös, miten käyttäjille myönnetään Apache-moduulin käyttöoikeus kotihakemistoon. Virtuaalipalvelimelle tein nämä asiat aivan samalla tavalla, joten en kuvaa prosessia enää tässä uudestaan.

Domain-nimen vuokraaminen

Kuten ylempänä linkittämässäni ohjeessa sanotaan, hyviä paikkoja domain-nimen vuokraamiseen ja erilaisten nimien saatavuuden tutkimiseen ovat esimerkiksi Namecheap ja Gandi. Ilmeisesti näistä kahdesta Namecheap on hieman halvempi, ja sieltä vähemmän kysyttyjä vapaina olevia osoitteita vaikuttaa saavan hieman alle kympillä vuodessa. Opettajamme kehotti meitä tarkistamaan, olisiko oma sukunimemme vapaana .com-päätteisissä osoitteissa, sillä tämäntyyppisen domainin omistaja voisi luoda esimerkiksi etunimi@sukunimi.com -tyyppisiä sähköpostiosoitteita vaikka koko suvulle. Juuri .com -päätteiset sivut ovat niitä, joita kannattaa vuokrata, sillä .com on puheessa hyvin vakiintunut pääte, jonka ihmiset tunnistavat ja johon luotetaan.

Moni kurssilaiseni saikin varattua itselleen tämäntyyppisen osoitteen, mutta itseäni ei lykästänyt. Rehellisesti sanottuna olisin ollut äärimmäisen yllättynyt, jos huttunen.com -osoite olisi ollut vielä vapaana, sillä Huttunen on hyvin yleinen sukunimi. Itse en kuitenkaan kokenut tästä mitään erityistä pettymystä, sillä olen aina esiintynyt netissä vakiintuneella nimimerkilläni oikean nimeni sijasta, enkä nää erityistä syytä muuttaa tapojani tässä asiassa. Ehkä yritän alitajuisesti pitää nimimerkkikulttuuria elossa, haha.

Vuokraamisen jälkeen oli vuorossa domain-nimen yhdistäminen virtuaalipalvelimeen, jonka teimme sen tämän ohjeen mukaisesti. Oli hieman omituista, että kummatkin valmiista recordeista olivat turhia ja ne poistettiin ennen omien A recordien lisäämistä. Lopputulos oli, että meillä oli ensimmäisen A recordin hostina @ eli root domain ja toisen A recordin hostina www. Tämä mahdollistaa sen, että vierailija ohjautuu oikealle sivulle riippumatta siitä kirjoittaako hän osoitteen alkuun www vai ei.

Seuraavaksi loin uuden tiedoston kansioon /etc/apache2/sites-available komennolla

$ sudo nano helkera.conf

ja muokkasin sen sisällön seuraavanlaiseksi:

Tallennettuani tiedoston painamalla Ctrl + X ja valitsemalla Y ja Enter annoin myös komennon

  $ sudo a2ensite helkera.conf

, joka lisäsi saman tiedoston myös enabled sites -kansioon aktivoiden samalla sivun käyttöä varten. Seuraavaksi piti tietenkin luoda kuvan mukaiseen hakemistoon index.html -sivu ja käynnistää Apache2 uudestaan komennolla

 $ sudo systemctl restart apache2

Kotisivujen käyttö

Edeltävien toimenpiteiden jälkeen helkera.com-sivullani näkyy kotihakemistossani sijaitseva index.html-tiedosto, joka tässä tapauksessa sattuu edelleen olemaan rakas maskottini, ASCII-kala:

Oikeastaan tein aluksi uuden index.html-tiedoston palvelinkoneellani ja kopioin siihen vanhan koodin, mutta jostain syystä <pre> -tageista huolimatta kala levisi yhdeksi pitkäksi merkkijonoksi. Lopulta siirsin alkuperäisen sivun sellaisenaan palvelimelle scp-komennolla, minkä jälkeen kala näytti taas normaalilta itseltään. Tämän viikon tehtäviin kuuluu nimenomaan scp:llä tiedostojen palvelimelle siirtäminen, mutta myös php-sivun kokeilu, joten lyön nyt kaksi kärpästä yhdellä iskulla ja siirrän jonkin php-koodia sisältävän sivun palvelimelle scp:llä. Ensin minun kuitenkin pitänee asentaa palvelinkoneelle php ja mahdollistaa käyttäjille php:n ajaminen omista kotihakemistoistaan käsin. Kävin myös tämän prosessin läpi viime viikon tehtävien c -kohdassa, joten en käy sitä läpi enää tässä.

Tehtyäni omalla virtuaalikoneellani pienen php-sivun, jonka ideana on tulostaa kävijän IP-osoite, siirsin sen palvelinkoneelleni komennolla

$ scp ipaddr.php helkera@helkera.com:/home/helkera/public_html

Ja nyt helkera.com:ista löytyykin uusi sivu:

Kuvassa Geditissä auki oleva koodi on minun virtuaalikoneellani, sillä palvelinkoneella ei ole graafista käyttöliittymää, jota vaaditaan Geditin käyttöön. Epähuomiossa viime tunnilla yritin vanhasta tottumuksesta käyttää Gedittiä palvelinkoneella ja kun tajusin, ettei sitä ollut, ajattelin että äkkiäkös minä sen asennan. Tajusin virheeni vasta kun olin jo antanut apt-get install -komennon ja näin kun Ubuntu alkoi lataamaan noin tuhatta ja yhtä pakettia. Onneksi sain asennuksen keskeytettyä, mutta hetken aikaa olin hieman huolissani ja häpeissäni. Palvelinkoneellani on tosiaan sen verran vähän muistia, että graafisten ohjelmien pyörittämisessä ei ole mitään mieltä. Mutta kuten äsken demonstroin, on hyvin kätevää tehdä koodi Geditillä omalla koneella ja lähettää vasta valmis tiedosto palvelimelle scp:llä.

Murtautumisyrityksiä

Palvelimen pystyttämisestä lähtien olen tarkkaillut satunnaisesti /var/log -hakemistossa sijaitsevaa auth.log-tiedostoa. Komennolla

$ tail -f auth.log

saa helposti seurattua reaaliajassa lokiin tulevia uusia rivejä. Ja niitä muuten tulee tajuttomalla tahdilla. Opettajamme ei todellakaan liiotellut kun hän totesi, että heti kun palvelin on yhteydessä nettiin, siihen yritetään murtautua. Tahdista päätellen nämä yritykset tulevat todennäköisesti erilaisilta bottiverkoilta. Useimmiten botit yrittävät kirjautua root-käyttäjänä, mikä on juuri se syy, miksi root-käyttäjän salasana deaktivoitiin palvelimen pystytyksen yhteydessä. Mikäli ulkopuolinen taho onnistuisi kirjautumaan palvelimelleni root-käyttäjänä, seuraukset olisivat varmasti äärimmäisen ikävät.

Olen kuitenkin nähnyt bottien yrittävän myös muille tunnuksille kirjautumista. Admin-tunnuksia olen nähnyt muutaman kerran, mikä ei ole yllätys, mutta myös ihmisten nimiä vilahtelee auth.login epäonnistuneissa kirjautumisyrityksissä toisinaan. Selkeästi murtautumisyritykset ovat myös erilaisia päivästä riippuen. Ensimmäisenä iltana palvelimen pystyttämisen jälkeen kaikki kirjautumisyritykset, joiden lähteen tarkistin whois-komennolla, tulivat Venäjältä. Mielestäni erikoista oli se, että kaikissa saamissani whois-tulosteissa mainittiin yksittäisten ihmisten nimiä ja katuosoitteita. Päättelinkin, että nämä käyttäjät saattavat olla normaaleja ihmisiä, joiden koneille hakkerit ovat jollain tapaa päässeet ja heidän koneensa on liitetty osaksi jonkinlaista hyökkäyksiä tehtailevaa bottiverkkoa.

Siinä missä ensimmäisen illan venäläinen bottiverkko vaikutti yrittävän myös satunnaisille tunnuksille kirjautumista, tällä hetkellä auth.logiin tulee pelkkiä root-käyttäjään kohdistuvia kirjautumisyrityksiä ja vain muutamasta eri IP-osoitteesta. Toinen osoitteista kuuluu DigitalOceanille, josta itsekin palvelimeni vuokrasin, ja toinen Chinanetille:

Jos annan whois-komennossa oman palvelimeni IP-osoitteen, niin tuloste on samanlainen kuin ensimmäisessä kuvassa. Tämän illan murtautumisyrityksistä vastuussa olevat tahot ovatkin varmaan hyödyntäneet samaa palveluntarjoajan whois protectionia kuin minäkin. Olisi kyllä kiinnostavaa tietää, tulevatko yritykset useammalta eri koneelta vai vain yhdeltä.

Tähänastisen kokemukseni perusteella vaikuttaa myös, että tietyt vuorokaudenajat ovat suositumpia kuin muut mitä murtautumisen yrittämiseen tulee. Kerran tarkastelin auth.logia päivällä koulussa istuessani ja silloin uusia yrityksiä tuli melko harvakseltaan. Keskimääräisesti arvioisin, että noin muutaman minuutin välein, mutta välillä yritysen väliin saattoi jäädä viisikin minuuttia. Tämä on melko radikaali ero, kun vertaa tahtia tähän hetkeen. Kello on nyt 4.04 lauantain ja sunnuntain välisenä yönä, ja uusia yrityksiä auth.logiin tipahtelee n. 1-20 sekuntin välein, ja monesti yrityksiä tulee lähes kerralla useita peräkkäin.

TLS-sertifikaatin hankkiminen

Kun ensimmäisiä kertoja tarkastelin omia sivujani selaimella, kiinnitin huomiota siihen, ettei sivu ollut Chromen mielestä turvallinen. Pidin tätä hieman tylsänä, joten lähdin selvittämään, kuinka asian saisi muutettua. Päädyin opettajamme suosittelemalle Let’s Encrypt -sivustolle, jonka kautta löysin hyvältä vaikuttavat ohjeet sertifikaatin hankkimiseen. Ilmeisesti prosessi on nykyään automatisoitu, ja sisältää lähinnä certbot-ohjelman sekä oikeanlaisen pluginin lataamisen. Seurasin näitä ohjeita, ja koska olin vuokrannut palvelimeni DigitalOceanilta, oikeaan pluginiin liittyvät ohjeet löytyivät täältä.

Kohtasin kuitenkin asennuksen aikana ongelman. Sain jatkuvasti virheilmoituksen siitä, ettei domain-nimeäni voitu varmistaa. Yritin googlettaa, mitä olin tehnyt väärin, mutta en aluksi löytänyt mitään kovin järkevää. Lopulta päädyin laittamaan oman sivustoni nimen SSL Checker -sivulle, jonka tarkastuksen epäonnistuessa sain virheilmoituksen, jossa viitattiin siihen, etten olisi ehkä sallinut HTTPS-liikennettä palvelimelleni. Ja siitähän ongelma johtuikin. Päädyin käyttämään DigitalOceanin ohjeita, joissa mainittiin myös tarvittava komento HTTPS-liikenteen sallimiselle. Tämän jälkeen certbot sai tehtävänsä hoidettua mallikkaasti ja sain vihdoin sivulleni sertifikaatin.

Linkki sivulle
Linkki sivulle

Asennuksen aikana minulta kysyttiin, haluaisinko ohjata kaiken saapuvan liikenteen turvalliseen osoitteeseen, ja jostain syystä sillä hetkellä vastasin kieltävästi. Myöhemmin tultuani katumapäälle yritin etsiä tapaa muuttaa asetus, ja löysinkin muutamia potentiaaliselta vaikuttavia keinoja, mutta halusin kokeilla asetusten muuttamisen ulkoistamista certbotille. Annoinkin komennon

$ sudo certbot --redirect

ja botti heräsi taas henkiin. Aluksi se pyysi minua valitsemaan, mille osoitteille haluaisin ottaa uudelleenohjauksen käyttöön, ja valitsin sekä juuriosoitteen että www-osoitteen. Tämän jälkeen certbot ilmoitti, että minulla vaikuttaa olevan jo voimassaoleva sertifikaatti, joten valitsin annetuista vaihtoehdoista, että muutos tehtäisiin aikaisempaan sertifikaattiini. Kaikki onnistui hyvin ja certbot teki itsenäisesti tarvittavat muutokset VirtualHost-tiedostooni:

Tämän jälkeen kun yritän selaimella mennä osoitteeseen helkera.com, minut ohjataan sivulle https://helkera.com, ja selain ilmoittaa sivun olevan turvallinen. Kyllä nyt sielu lepää!

Tämän viikon vapaaehtoisiin tehtäviin olisi kuulunut myös lukuisia WordPressiin liittyviä tehtäviä. Halutessani voisinkin siis nyt siirtää tämän WordPress-blogini omalle palvelimelleni. En aio kuitenkaan yrittää sitä operaatiota enää tänään, sillä minulla on vielä tämän illan kuntopyöräilyt tekemättä. Eli siirrynkin nyt ihan perinteisempään hikoiluun tällaisen metaforisen tehtävien parissa hikoilun jälkeen. Hyvää yötä vaan kaikille!

Tietoa kirjoittajasta

Noora Huttunen

Opiskelen ohjelmistotuotantoa Haaga-Helian tietojenkäsittelylinjalla.