# Tapaukset tehtävään Z10.2 (kurssi VPS ja Linux-palvelimen ylläpito)

Valitse jokaisesta tapauksesta, mikä virhe on kyseessä ja mikä on paras ensimmäinen askel. Kaikki nimet ja osoitteet ovat esimerkkejä.

**Virheet (oppitunnilta 10.2):**
A. Root-kirjautuminen salasanalla
B. Tietokanta, välimuisti tai hakuklusteri avoinna internetiin
C. Docker-API avoinna tai `docker.sock` kontissa
D. `chmod 777` virheilmoituksen poistamiseksi
E. `curl ... | bash` ja ohjelmistoja mistä tahansa
F. Ei päivityksiä tai päivitykset "myöhemmin"
G. Ei varmuuskopiota tai varmuuskopio, jota ei ole koskaan testattu
H. Hallintapaneeli avoinna kaikille ilman kaksivaiheista tunnistautumista
I. Salaisuudet Gitissä tai compose-tiedostossa
J. Palomuuri "hetkeksi" pois päältä, kaikki rootina, ei muistiinpanoja

---

**Tapaus 1.** Palvelimella `web1.example.com` tiedostossa `compose.yaml` on palvelun `redis` kohdalla: `ports: - "6379:6379"`. `ufw status` näyttää vain portit 22, 80 ja 443. Ulkopuolinen skannaus löytää portin 6379 avoimena.
Ensimmäinen askel: (a) käynnistä ufw uudelleen (b) poista porttisääntö tai muuta se muotoon `"127.0.0.1:6379:6379"` ja suorita uudelleen `docker compose up -d` (c) anna Redisille toinen porttinumero (d) käynnistä palvelin uudelleen

**Tapaus 2.** Palvelimella `app.example.net` olevan verkkosovelluksen kehittäjä ilmoittaa, että tiedostojen lataus ei toiminut. Hän on "korjannut" asian, ja nyt kaikkien hakemiston `/var/www/app` tiedostojen oikeudet ovat `-rwxrwxrwx`.
Ensimmäinen askel: (a) jätä ennalleen, nyt se toimii (b) anna verkkopalvelimen käyttäjälle kirjoitusoikeus vain lataushakemistoon ja palauta muut oikeudet arvoihin 644/755 toisella omistajalla (c) aja verkkopalvelinta rootina (d) poista AppArmor käytöstä

**Tapaus 3.** Julkisessa repositoriossa on eilisestä lähtien ollut tiedosto `.env`, jossa on palvelimen `web2.example.org` `MAIL_API_KEY=...`.
Ensimmäinen askel: (a) poista tiedosto repositoriosta (b) peruuta avain sähköpostipalvelussa ja luo uusi, ja lisää `.env` tiedostoon `.gitignore` (c) nimeä repositorio uudelleen (d) älä tee mitään

**Tapaus 4.** `sudo sshd -T | grep -E "permitrootlogin|passwordauthentication"` antaa tuloksen `permitrootlogin yes` ja `passwordauthentication yes`. Journalissa on joka minuutti kirjautumisyrityksiä rootina.
Ensimmäinen askel: (a) asenna fail2ban eikä mitään muuta (b) lisää avain tavalliselle ylläpitäjälle, jolla on sudo, testaa ja poista sitten salasanakirjautuminen ja root-kirjautuminen salasanalla käytöstä (c) siirrä SSH porttiin 2222 (d) tallenna root-salasana tekstitiedostoon

**Tapaus 5.** `cat /etc/os-release` näyttää Ubuntu-julkaisun, jonka vakiotuki päättyi kolme vuotta sitten, eikä ESM:ää ole. `apt list --upgradable` on tyhjä.
Ensimmäinen askel: (a) ole iloinen, päivityksiä ei ole (b) suunnittele päivitys tai uusi palvelin tuettuun LTS-versioon, tilannevedoksen ja varmuuskopion kanssa (c) asenna unattended-upgrades uudelleen (d) käynnistä palvelin uudelleen

**Tapaus 6.** Kontilla `portainer` on taltio `/var/run/docker.sock:/var/run/docker.sock`, ja se on tavoitettavissa osoitteessa `https://hallinta.example.com` salasanalla `admin123` ilman kaksivaiheista tunnistautumista.
Valitse virhe, joka mahdollistaa suurimman vahingon, jos salasana arvataan. Ensimmäinen askel: (a) siirrä paneeli SSH-tunnelin tai kiinteän osoitteen taakse ja ota käyttöön vahva salasana ja kaksivaiheinen tunnistautuminen (b) käynnistä kontti uudelleen (c) valitse toinen aliverkkotunnus (d) asenna Docker uudelleen

**Tapaus 7.** Epäonnistuneen tietokantapäivityksen jälkeen selviää, että ainoa varmuuskopio on kaksi kuukautta vanha tilannevedos samalla tallennustilalla kuin palvelin. Kukaan ei ole koskaan kokeillut palautusta.
Ensimmäinen askel tulevaisuutta varten: (a) tee enemmän tilannevedoksia (b) ota käyttöön salatut varmuuskopiot palvelimen ulkopuolelle (esimerkiksi restic), valvonnan ja palautustestin kanssa (c) älä enää koskaan päivitä tietokantaa (d) toinen levy samaan palvelimeen

**Tapaus 8.** Palvelimella on `/usr/local/bin/tool` ja tuntematon pakettilähde `extra.list`, jossa on asetus `[trusted=yes]`. Kukaan ei tiedä, mistä ne ovat peräisin; edellinen ylläpitäjä asensi "kaiken yhdellä rivillä jostain verkkosivulta".
Ensimmäinen askel: (a) jätä ennalleen, se toimii (b) selvitä, mikä lähde ja ohjelma ovat, poista lähde käytöstä komennolla `trusted=yes` ja asenna jatkossa vain jakelusta tai tekijän virallisesta lähteestä komennolla `Signed-By` (c) käynnistä palvelin uudelleen (d) poista kaikki paketit

Täytä jokaiselle tapaukselle: virhe (A-J) ja ensimmäinen askel (a-d).