Virtuaalipalvelimen koventaminen ja suojaaminen Azuressa ihan oikeasti

Vuosien varrella olen ollut mitä moninaisimmissa projekteissa mukana. Aika usein kädet savessa, toisinaan viisastelemassa, ja välillä katselmoimassa. Minulle on sen myötä kehkeytynyt osin irrationaalinen pelko siitä, että mikäli en ole sormet näppäimistöllä, korvieni välissä oleva näkymätön mentaalitasolla toimiva lihas surkastuu, enkä kykene enää suorittamaan työtäni riittävällä laadulla.

Projektien välissä tai iltaisin kannustan itseäni opiskelemaan ja sisäistämään uusia asioita. Labraympäristössä on turvallista turata menemään, kun ei varsinaisesti ole ihoa pelissä. Tämän myötä olen rakennellut hiljalleen erilaisia tuotantomaisia – ja ihan tuotannossa pyöriviä – ratkaisuja ja palveluita. Omaksi ja muiden iloksi. Ja näin meidän kesken, suurin syy on se, että voin koeponnistella toteutuksia ”kuten asiakasympäristöissä” ilman lamauttavaa pelkoa siitä, että asiakkaan järjestelmät kärsivät. Ja tätä oppia hyödynnän sitten oikeissa projekteissa – muistijäljet kantavat yllättävän pitkälle, kun jonkin asian on kertaalleen tehnyt.

Mikä juttu?

Muistelen rakentaneeni ensimmäisen palvelimen tuotantokäyttöön rahaa vastaan vuonna 1990 tai 1991. Fyysinen pannu, Linuxilla. Ensimmäisen virtuaalipalvelimen rakensin suunnilleen 2001, silloin modernilla Virtual PC by Connectix-tuotteella, joka sittemmin muuntui monen mutkan kautta nykyiseen Hyper-V/Hypervisor-platformiin.

Niihin aikoihin virtuaalipalvelimen koventaminen ja suojaus oli yllättävän vaikeaa, ja samalla kuitenkin niin yksinkertaista. Palomuurit tikkiin, Windowsin omat asetukset kuosiin ja koska sisäverkossa oli vain kavereita ja hyviä tyyppejä, se riitti.

Nykyiset virtuaalipalvelimet Azuressa ovat toki jo ihan toisenlaisia rakennuspalikoita. On helppo heittää puskista laiskoja viisauksia, kuten ”säädä Web Application Firewall kuntoon” tai ”tsekkaa että Windows on pätsätty!”, ottamatta kantaa kovin laajasti mitä ja miten asioita pitäisi tehdä.

Virittelin omaksi ja monen muun iloksi muutaman tuotantokäyttöön soveltuvan virtuaalipalvelimen. Ensimmäisessä ympäristössä pyörii Signal-pikaviestinsovelluksen proxy-palvelu, ja toisessa ympäristössä pyörii WhatsApp-pikaviestinsovelluksen proxy-palvelu.

Mihin näitä proxyjä tarvitsee?

Jos luet tätä blogia mukavasti kotitoimistolla jostain päin Suomenniemeä, hörppien pannukahvia Iittala-mukista samalla kun nojaat Ikea-tuolissa hieman taaksepäin, on minulla sinulle uutisia. Et tarvitse WhatsAppiin tai Signaliin proxyä. Sen sijaan, jos reissaat työn tai vapaa-ajan merkeissä vaikkapa Iraniin (plussat: lämmintä, kuulemma hyvää ruokaa; miinukset: et puhu kieltä), voi tulla tenkkapoo kun pitäisi viestitellä työkavereille lomakuvia basaarista. Ei toimi.

Pyörittämällä semi-kevyitä proxy-palveluita julkisessa Internetissä, voin (hyvin) pienellä panoksellani avustaa sellaisten maiden kansalaisia, joilla pääsy pikaviestinsovelluksiin on ns. kiven alla. Konfiguroimalla proxy-palveluni osoitteen mobiili-WhatsAppiin tai Signaliin voidaan useissa tapauksissa ohittaa mahdollinen kansallisen tason palomuuri joka parhaan kykynsä mukaan yrittää estää järkevän viestimisen tilanteessa kuin tilanteessa. Mobiiliappi kontaktoi proxyn, ja kierrättää viestiliikenteen salattuna varsinaiseen pikaviestipalveluun. Todella jees!

Hieman tekniikkaa

Molempien kilpailevien palveluiden proxyt ovat pääosin samanlaiset. Docker-kontissa pyörivä endpoint, johon mobiiliappi ottaa yhteyttä. Konttiratkaisut ovat keveähköt, muutamia satoja megatavuja muistia vaativia joten virtuaalipalvelinten osalta kevyt varustelu riittää.

Pohdin aluksi Web Application Firewallin käyttöönottoa, mutta koska proxyt tulivat ajoon eri aikoihin, ajattelin pärjätä vielä hetken ilman. Käytön kasvaessa on fiksua lisätä WAF väliin filtteroimaan turhaa liikennettä pois.

WhatsAppin proxy vaatii muutamia esoteerisiä portteja auki, johtuen lähinnä WhatsAppin käyttämistä teknologiavalinnoista. Signal Proxyn osalta tilanne on siistimpi – 80 ja 443/TCP riittävät.

Molemmat proxyt perustuvat Linux-pohjaiseen containeriin joten käyttöjärjestelmänä virtuaalipalvelimissa on tuore Ubuntu.

Ja sitten kovennetaan ja suojataan

En tässä artikkelissa graafisesti kuvaa jokaista toimenpidettä, vaan nostan kokonaisuutta selkeämmin esille. Samalla huomioin havaintoja konfigurointityön ääreltä. Molempiin palveluihin pätivät samat kovennukset ja suojaukset.

Aivan alkuun monitorointi. Kytkin hälytykset ja reagoinnit päälle, kun tietyt ehdot täyttyvät – törkeä määrä ulospäin menevää liikennettä, kova CPU-kuorma, ja muut perusasiat

Monitorointi nappaa aika herkästi kiinni – yllä kuvassa selkeä piikki saapuvassa (mobiiliappsilta proxyyn) liikenteessä.

Azure Policyiden puolelta menin pokeritermein all in, ja kytkin suurimman osan vakiopolicyistä päälle. Siellä on toki paljon turhaa – esimerkiksi Windows-sidonnaisia tarkistuksia, joita Ubuntu-puolella ei näy.

Etäyhteydet palvelimelle on rakennettu SSH:lla private avaimilla, ja oletuksena palomuurista pääsy on estetty. Tästä lisää pian.

Varmuuskopiot ajetaan 4 tunnin välein ympäri vuorokauden – snapshotteina, ja joka 4. kerta standardivarmistuksina. Sinänsä palvelimissa ei ole mitään kriittistä, koska uuden proxyn konfigurointi on parin minuutin juttu – mutta miksi ei.

Disaster Recovery ei ole käytössä – koska Azure ei sitä tue. Tämä oli harmillinen takaisku. Otin liian tuoreen Ubuntun, johon Azuren DR ei toistaiseksi päde. Toisin sanoen, virtuaalipalvelimia ei replikoida toisaalle odottelemaan vikatilanteiden esiintymistä.

Käyttöjärjestelmä- ja muut päivitykset ajetaan automaattisesti kerran viikossa kyytiin.

Defender for Server (Plan 2) on käytössä – ja sen kautta lisäominaisuudet kuten haavoittuvuuksien havainnointi, Just-in-Time etäyhteydet, tiedostojen monitorointi on kytketty käyttöön. Kaikki havaitut haavoittuvuudet ja puutteelliset konfiguraatiot on korjattu sen jälkeen vielä käsin.

Lopuksi

Jätin luetteloimatta tylsiä konfigurointeja ja perusasioita, jotka tekisin joka tapauksessa vaikka palvelu ei olisi julkiverkkoon näkyvissä alkuunkaan. On ollut jälleen mielenkiintoista seurata palvelun käytön kasvua ja peilata sitä samalla esiin nouseviin tietoturvariskeihin ja havaintoihin.

Azure tekee yllättävän paljon puolestasi, toisaalta havaittuihin yksityiskohtiin kuluu helposti kahvia ja proteiinismoothieta, kun asioita selvitetään. Voinko esimerkiksi kytkeä IP Forwarding-featuren pois Linuxin kernelistä ilman, että proxy-palvelu räjähtää? Tätä(kin) varten oma testiympäristö on hyvä lisä.

Jatkan ympäristöjen virkkaamista seuraavaksi lisäämällä eteen Web Application Firewallin, Microsoft Sentinelin tuomat edut sekä kryptatut levyt omilla avaimilla.

Jos tästä heräsi ajatuksia oman ympäristönne katselmointiin ja turvaamiseen, ole yhteydessä!