Linux-palvelimen suojaaminen: käytännön tarkistuslista

Useimmat onnistuneet palvelinmurrot eivät käytä uutta haavoittuvuutta. Ne käyttävät sitä, mikä on unohtunut: salasanapohjaista SSH:ta, paikkaamatonta pakettia, avoimia portteja, joiden pitäisi olla kiinni, ja käyttäjätiliä, jonka omistaja lähti yrityksestä kaksi vuotta sitten.

Hyvä uutinen on, että suuren osan tästä voi tarkistaa itse. Alla oleva lista kattaa ne asetukset, joita käytännössä useimmin puuttuu, kun otamme hallintaan jonkun toisen määrittämän Linux-palvelimen.

1. SSH — tärkein yksittäinen asetus

Pääsy palvelimelle kulkee SSH:n kautta, ja juuri sitä hyökätään eniten. Jokainen julkisessa internetissä oleva palvelin saa salasanan murtoyrityksiä joka päivä riippumatta siitä, kuinka tuntematon se on.

Tarkista:

• Salasanapohjainen kirjautuminen on pois päältä ja käytössä ovat vain avaimet. Tämä yksi muutos lopettaa valtaosan yrityksistä.
• root-tunnuksella ei kirjauduta suoraan — käytä tavallista tiliä ja sudo-komentoa.
• Epäonnistuneiden yritysten esto on päällä (esim. fail2ban tai vastaava).
• Kenellä ylipäätään on pääsy — käy läpi kaikki tilit ja valtuutetut avaimet. Poista ne, joita ei enää tarvita.

2. Palomuuri — kaikki kiinni paitsi tarpeellinen

Oletuksena tulisi olla kaikki kielletty ja auki vain se, mitä oikeasti tarvitaan: verkkoliikenne, SSH ja palvelut, joita tietoisesti tarjoat.

Erityistä huomiota vaativat tietokannat. Tietokannan ei tulisi lähes koskaan olla saavutettavissa julkisesta internetistä — se on yksi yleisimmistä ja vakavimmista löydöksistä. Tarkista, mitkä portit ovat ulkoa auki, ja kysy jokaisen avoimen portin kohdalla, miksi se on niin.

3. Päivitykset ja paikat

Tarkista, onko asentamattomia tietoturvapäivityksiä, ja selvitä, kuinka vanha käytössä oleva järjestelmä on. Erillinen kysymys: saako käytössä oleva jakeluversio enää tietoturvapäivityksiä lainkaan? Tuen päättyminen tarkoittaa, ettei uusia paikkoja enää tule, ajoitpa päivityksen kuinka monta kertaa tahansa.

Sama koskee palvelimella pyörivää ohjelmistoa — PHP:ta, tietokantaa, verkkopalvelinta. Vanhentunut PHP-versio on yhtä suuri riski kuin vanhentunut käyttöjärjestelmä.

4. Varmenteet ja HTTPS

Tarkista, että varmenne on voimassa, uusiutuu automaattisesti ja kattaa kaikki käytössä olevat aliverkkotunnukset. Tarkista myös, että HTTP ohjataan aina HTTPS:ään ja että vanhat, heikot protokollaversiot on poistettu käytöstä. Vanhentunut varmenne on yksi harvoista teknisistä virheistä, jonka jokainen kävijä huomaa heti.

5. Varmuuskopiot — ja palautuksen kokeilu

Kolme kysymystä, joihin on oltava konkreettinen vastaus:

1. Kuinka vanha on tuorein kopio?
2. Missä se sijaitsee — palvelimen ulkopuolella? Samalla koneella oleva kopio ei auta, jos kone katoaa.
3. Milloin viimeksi kokeilit palautusta?

Jos kolmanteen kysymykseen ei ole vastausta, varmuuskopioita ei oikeasti ole — on vain toivo. Tee yksi palautuskokeilu testiympäristöön ja merkitse kalenteriin, milloin se toistetaan.

6. Lokit ja valvonta

Käy läpi, seuraako kukaan levyn täyttymistä, muistin käyttöä ja palveluiden elossaoloa. Täysi levy on yksi yleisimmistä katkojen syistä ja käytännössä aina ehkäistävissä — se ei täyty yhdessä yössä.

Lokeissa kannattaa seurata toistuvia kirjautumisyrityksiä, epätavallisia pyyntöjä ja virheilmoituksia, jotka ovat yhtäkkiä lisääntyneet. Muutos kaavassa on yleensä ensimmäinen merkki.

7. Kuka ja mikä palvelimella pyörii

Käy läpi, mitkä palvelut palvelimella ovat käynnissä. Vuosien mittaan sinne kertyy usein asioita, joita kukaan ei enää käytä: vanha testiympäristö, kauan sitten unohtunut apuväline, jonkun tilapäinen ratkaisu. Jokainen käynnissä oleva palvelu on hyökkäyspintaa — poista se, mitä ei tarvita.

8. Dokumentaatio

Kirjaa ylös, missä palvelin sijaitsee, mitä siellä pyörii, kenellä on pääsy ja miten toimia häiriön sattuessa. Tämä on osa, jonka arvo selviää päivänä, jona entinen ylläpitäjä ei ole tavoitettavissa — ja se päivä tulee ennemmin tai myöhemmin aina.

Mitä tehdä, jos lista herätti enemmän kysymyksiä kuin vastauksia

Juuri se on listan tarkoitus. Jos useaan kohtaan et osannut vastata, palvelimen tila on todennäköisesti sellainen, joka kannattaa käydä läpi.

Katsomme Linux-palvelimesi läpi, sanomme konkreettisesti, mikä on kunnossa ja mikä ei, ja teemme ehdotuksen korjattavasta — myös silloin, kun johtopäätös on, ettei suuria töitä tarvita. Laajemmin kirjoitimme siitä, mitä juokseva ylläpito sisältää, artikkelissa Linux-palvelimen ylläpito: mitä sopimus sisältää.