Osallistun Haaga-Helia ammattikorkeakoulussa Linux-palvelimet kurssille, jonka opettajana toimii Tero Karvinen. Kaikki tehtävät ovat hänen verkkosivuiltaan http://terokarvinen.com/.
Suoritan tehtävän pöytätietokoneellani, jossa pyörii Debian 9.7. ja samalla käytän Digital Oceanilta vuokrattua virtuaalipalvelinta, jossa pyörii Ubuntu 18.04.
Tehtävänanto kuuluu seuraavasti:
A.) SSH:n asennus
Ensimmäisessä tehtävässä sanotaan vain, että tulee asentaa SSH-demoni. Kello on 12:11. Se asennettaan tuttuun tapaan komennolla $ sudo apt install ssh. Kun se on asennettu, niin sen voi vielä tarkistaa, katsomalla hakemiston /etc komennolla $ cd /etc/. Sitten voi joko etsiä manuaalisesti itse tai antaa komennon $ ls |grep ssh, jolloin pitäisi näkyä SSH-demonin hakemisto, jos se on asennettuna. Kello on 12:17.
B.) Tulimuuri ja SSH-reikä
Toisessa tehtävässä oli tarkoitus suojata kone tulimuurilla ja asettaa reikä SSH:lla. Kello on 12:30. Minulla on tulimuuri jo laitettu pystyyn ja siellä on HTTP- ja HTTPS-reiät laitettuna. Halusin statuksen tehtävää varten, joten etsin, kuinka voin näyttää tulimuurin nykyisen statuksen. Täältä löysin, että komento on $ sudo ufw status verbose. Kun annoin komennon, niin se sylkäisi tällaista:
Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22/tcp ALLOW IN Anywhere 80/tcp ALLOW IN Anywhere 443/tcp ALLOW IN Anywhere 22/tcp (v6) ALLOW IN Anywhere (v6) 80/tcp (v6) ALLOW IN Anywhere (v6) 443/tcp (v6) ALLOW IN Anywhere (v6)
Siispä tästä voimme nähdä, että tulimuuri on aktiivinen ja vain portit 22, 80 ja 443 ovat avattuja.
Jos olisimme halunneet laittaa tulimuurin nollasta päälle, niin tämän ohjeen mukaan, se kävisi vain kahdella komennolla. $ sudo ufw allow 22/tcp ja sitten vaan $ sudo ufw enable. Näillä komennoilla tulimuurissa olisi tarvittavat vaatimukset eli päällä ja SSH-portti auki. Kello on 12:41.
C.) SSH-tiedostosiirto
Seuraavassa tehtävässä olisi tarkoitus siirtää tiedostoja SSH:lla. Toisin ilmaistuna SCP-menetelmällä tai Rsyncillä. Ei käytännössä ole niinkään väliä, kumpaa menetelmää käytän, sillä ajattelin siirtää vain yhden tiedoston demoa varten. Kello on 12:44.
Teen testitiedoston pöytäkoneelleni. $ nano foo.txt, jonka jälkeen laitan tiedostoon jotain pientä demotekstiä. Tämän jälkeen tallennan tekstitiedoston. Sitten yritän siirtää tämän tiedoston palvelimelleni vaikka tällä kertaa Rsyncillä. Sitten vaan komento $ rsync foo.txt santeri@santerisiirila.me: (Huom! Kaksoispiste komennossa on tärkeä, eikä toimi ilman!) Tämän jälkeen kävin katsomassa palvelimeltani, oliko se siirtynyt käyttäjäni kotihakemistoon.
Tadaa!
Halusin kokeilla vielä jotain isompaa, koska miksikäs ei?
Menin metsästämään pöytäkoneestani jotain paria kilotavua isompaa tiedostoa/hakemistoa. Tähän on hyvä käyttää $ ls -lh, mutta varmasti voisi find-komentoa myös hyödyntää. Itse etsin manuaalisesti tuolla aiemmin mainitsemalla komennolla. Löysin vanhan mobiiliohjelmointiprojektin ja siinähän on node-modules, joka tunnetusti vie tilaa ihan kiitettävästi. Siipä päätän siirtää tuon hakemiston.
$ rsync viskiprojekti santeri@santerisiirila.me: -r -v –progress
Löysin pienet ohjeet, jotta saan progressin ja kokonaisen kansion siirrettyä. Voit lukea lähteet täältä ja täältä. Näin sain rekursiivisesti siirrettyä koko hakemiston palvelimelle. Tältä näytti lopputulos:
Vielä käydään katsomassa palvelimelta, mitä sinne kuuluu:
Hyvältä näyttää! Kello on 13:23.
D.) Julkinen avain
Tässä tehtävässä halutaan automatisoida kirjautuminen palvelimelle julkisen avaimen menetelmällä. Kello on 13:25.
Olen tämän jo tehnyt, mutta se tapahtuisi siis siten, että luodaan aluksi paikalliselle koneelle SSH-keygenillä itselleen julkinen ja salainen avain. Siispä $ ssh-keygen. Tämän jälkeen ohjelma kysyy kysymyksiä, jotka voi läpäistä vain rämppäämällä enteriä, mutta kannattaa silti lukea ne läpi. Noin, sinulle on nyt generoitu avainpari. Tämän jälkeen tulee vain asettaa sinun julkinen avain palvelimelle ssh-copy-id-komennolla. Esimerkkinä:
$ ssh-copy-id -i .ssh/id_rsa.pub santeri@santerisiirila.me
Tämän jälkeen joudut vielä kirjoittamaan salasanan kerran etähallintakoneelle, mutta sitten avain on asetettu, etkä enää tule tarvitsemaan salasanaa paitsi mahdollisesti joskus sudo-komentoihin. Minä itse saan tästä varoituksen, koska olen jo asettanut avaimet palvelimelle. Tämän jälkeen kuitenkin, kaiken pitäisi olla valmista. Kello on 13:37.
J.) Sysstat
Tässä tehtävässä oli tarkoitus asentaa Sysstat-paketti ja katsoa sen toimivuus. Lopulta pitää antaa sen pyöriä vaikka noin päivän omin voimin, jonka jälkeen voi katsoa tuloksia. Kello on 13:50.
Asennetaan aluksi Sysstat komennolla $ sudo apt install sysstat. Kun Sysstat on asennettu, niin voidaan konfiguroida se oikein. Eli siis, tämän ohjeen mukaan, kun haluaa aloittaa datan keräyksen, niin vain mennään aluksi komennolla $ cd /etc/default konfiguroimaan Systatin oma tiedosto. Sitten voidaan $ sudoedit sysstat -komennolla muokata tiedostosta kohta ENABLED=”false” tähän: ENABLED=”true”. Tämän jälkeen vain käynnistetään Sysstat-demoni uudestaan komennolla $ sudo service sysstat restart. Sitten demonin pitäisi kertätä tietoa, mutta sen voi vielä tarkistaa vaikka komennolla $ sar -r.
Tadaa, se toimii! Huomenna tullaan tutkimaan tuota lisää, mutta nyt ei ole vielä tarpeeksi tietoa. Kello on 14:03.
I.) Scan of the Month 15
Seuraavaksi olisi tarkoitus suorittaa Scan of the Month 15 -haaste. Haaste on löydettävissä tältä sivulta: http://old.honeynet.org/scans/scan15/ Kello on 14:31.
Latasin aluksi linkistä, tar.gz-tiedoston, jonka sitten purin komennolla $ tar -xzf honeynet.tar.gz. Nyt samassa kansiossa on /honeynet-kansio. Siellä oli vain README- ja honeypot.hda8.dd (mount image) -tiedostot.
En tiennyt ollenkaan, miten tätä tehtävää tulisi lähteä selvittämään, joten otin yhden mallivastauksista ja tein hänen kirjoitelmansa mukaan kaikki vaiheet. Tässä linkki tämän henkilön kirjoitelmaan: http://old.honeynet.org/scans/scan15/proj/som32.txt. Hänen mukaansa tämä image-tiedosto tulisi mountata read only -moodissa turvallisuussyistä, joten tein juuri niin. $ sudo mount honeypot.hda8.dd /mnt/test -oloop,ro oli komento, jota käytin tähän.
Kun olin mountannut kyseisen imagen, putosin kärryiltä aivan täysin. Jopa vaikka luinkin mallivastauksia. En ymmärrä, miten asiat tässä tapahtuvat ja vaikka on komentoja kerrottu teksteissä, niin siltikään en ymmärrä mitä mikäkin komento tekee. En koe tästä olevan hyötyä, koska vaikka tekisin kaiken mitä ohjeessa sanotaan, niin en silti ymmärtäisi mitä tapahtuu. Jätän tämän tehtävän tähän. Kello on 15:23.
Tässä on tekstejä, mitä yritin hyödyntää:
http://old.honeynet.org/scans/scan15/som/som33.html http://old.honeynet.org/scans/scan15/som/som6.txt http://old.honeynet.org/scans/scan15/som/som19.txt
G.) SSHFS
Katkerana, kun en saanut edettyä tuossa edellisessä tehtävässä, niin päätin tehdä jotain, jonka olen jo tehnyt joskus. Tässä tehtävässä olisi tarkoitus siis käyttää SSHFS:ää ja siten mountata itselleen uusi asema, joka olisi vaikkapa palvelimella. Tarkoitukseni on siis mountata oman palvelimeni kotihakemisto pöytäkoneelleni. Kello on 15:40.
Ensiksi asennetaan SSHFS, $ sudo apt install sshfs. Sitten loin kotihakemistooni mnt-hakemiston, jota aion käyttää mount pointina /mnt-hakemiston sijaan. $ mkdir mnt $ cd mnt. Sitten olisikin tarkoitus mountata tämä palvelimeni tuohon hakemistoon. Käytän apunani opettajamme ohjetta.
$ cd $ sshfs santeri@santerisiirila.me: mnt/ $ cd mnt/ $ ls foo.txt public_html publicsites viskiprojekti
Kuten tuosta voi päätellä, niin mount toimi oletetetusti. Testaan vielä lisätä vaikka jonkin tiedoston ja katsoa, että tuleeko se palvelimelle myös:
$ nano testi.txt $ ls foo.txt public_html publicsites testi.txt viskiprojekti
Siirryin palvelimelleni:
santeri@ubuntu-s-1vcpu-2gb-fra1-01:~$ ls foo.txt public_html publicsites testi.txt viskiprojekti
Se toimii, kuten toivottukin.
Nyt haluan vielä tehdä sen oikeasti oikeaoppisesti, eikä siten, että kaikki menee nyt sekaisin, jos yhteys menisikin poikki. Siispä unmountaan ensiksi komennolla $ fusermount -u /home/santeri/mnt. Sitten vaan oikeaoppinen mount vielä: $ mount sshfs -o reconnect,ServerAliveInterval=5,ServerAliveCountMax=3 santeri@santerisiirila.me: mnt/
Tämän jälkeen testasin vielä samalla tavalla kuin aiemmassakin esimerkissä ja kaikki edelleen toimi. Kello on 16:00.
Jatkoa Sysstatiin
Kello on 18:43 seuraavaa päivää, eli siitä on yli vuorokausi, kun asensimme Sysstat-paketin koneellemme ja laitoimme datan keräyksen aktiiviseksi. Nyt jos käytämme vaikkapa komentoa $ sar, niin saamme jo paljon mielenkiintoisempia tuloksia kuin viimeksi. Minulla tuo komento antoi tällaista:
Tässähän näkyy, että CPU:n käyttöaste on todella pieni järjestelmässäni. %Idle on koko ajan yli 99 %, eli toisin sanottuna järjestelmäni kaipaisi lisätekemistä yli 99 % ajasta. Ainakin tämän lähteen mukaan. No, ihan hyvä tietää, ettei tietokoneen CPU ainakaan ole ylikuormitettu.
$ iostat -komennolla saatiin taas tällaista outputia:
Tämän ohjeen mukaan, %user on käyttöaste käyttäjätasolla (ohjelmat), %nice on käyttäjätasolla oleva käyttöaste “nice”-prioriteetilla, %system on taas kernel-tasolla tapahtuva suoritinkäyttö, %iowait kertoo idle-ajasta kun järjestelmä on saanut suuren I/O-pyynnön levylle, %steal viittaa aikaan kun hypervisor on palvellut jotain toista virtuaaliprosessoria ja siten odotuttanut suoritinta ja viimeiseksi %idle on vain toimettomuuden käyttöaste – suorittimella ei ole ollut tekemistä tarpeeksi.
Tuo toinen osio kertoo laitteisiin kohdistuneet kirjoitukset ja lukemiset (I/O). TPS viittaa siirtoihin sekunnissa (transfers per second), kB_read/s on luettu data (kilotavua sekunnissa), kB_wrtn/s on laitteelle kirjoitetun datan määrä (kilotavua sekunnissa), kB_read on kokonainen määrä tavuja luettu ja kB_wrtn on kokonaismäärä tavuja kirjoitettu laitteelle. Näistä voi päätellä, että palvelimelleni on kirjoitettu noin 33 miljoonaa kilotavua kokonaisuudessaan ja sieltä on luettu noin 2 miljoonaa kilotavua.
Viimeiseksi vielä, komennolla $ pidstat, joka siis myös kuuluu tähän Sysstat-pakettiin, saadaan tällainen lista:
Tämä näyttää vahvasti samalta kuin aiemmat statistiikkaohjelmat, mutta tässä on lisätty itse demoni, joka sitä käyttää. Listalla näkyy esimerkiksi Apache, SSH ja MySQL (MariaDB). Kuten tästäkin voisi päätellä, suoritinkäyttö ei todellakaan ole katossa, mutta tuosta voi tarvittaessa katsoa, jos jokin tuntuu syövän tehoja. Tuosta saa myös kätevästi kunkin demonin PID-numeron (Process ID). Muuta ihmeellistä en löytänyt tästä. Kello on 19:14.
Linux-palvelimet 