iSCSI

• ”internet SCSI” (Small Computer System Interface)
• Alemman tason levynjakomekanismi kuin NFS, CIFS ym: iSCSI-levy (target) näkyy asiakaskoneelle (initiator) laitteena eikä tiedostojärjestelmänä.
• iSCSIlla voidaan jakaa levyä koneesta toiseen niin, että se käyttäytyy kuten lokaali levy: sitä voidaan partitioida, käyttää LVM:n fyysisenä volumena jne.
• Yleinen datacenter-ympäristöissä ja erityisesti juuri virtuaalikoneiden kanssa.

iSCSI

• Mahdollistaa (virtuaalisten) levyjen migraation helposti, asiakaskoneita juurikaan häiritsemättä.
• Toimii periaatteessa kaikenlaisten SCSI-laitteiden kanssa, mutta eniten käytetään levyjen jakamiseen (joskus nauhureidenkin).
• iSCSI-palvelin on usein dedikoitu verkkolevy (tai levyjärjestelmä, storage array), mutta voi olla normaali palvelinkonekin (löytyy useimmille yleisille käyttöjärjestelmille).
• Ei salaa liikennettä, usein toteutettu erillisellä dedikoidulla sisäverkolla

Migration

• Virtuaalikoneen voi siirtää yhdestä alustakoneesta toiseen monella tavalla:
• offline: kone sammutetaan siirron ajaksi
• pseudolive: kone "hibernoidaan" siirron ajaksi
• live: kone on koko ajan käynnissä, katko vain hetkellinen kun verkkoyhteydet siirtyvät alustakoneesta toiseen

Offline migration

• Virtuaalikoneen siirto alustakoneesta toiseen sammuttaen se ensin (ikäänkuin kovalevyn siirto fyysisestä koneesta toiseen):
• Nykyisessä alustakoneessa (esim. lonka7):
• virsh shutdown kone1
• virsh dumpxml kone1 > kone1.xml
• virsh undefine kone1
• scp kone.xml kone1.img [kone1b.img...] lonka6:
• Uudessa alustakoneessa (lonka6):
• virsh define kone1.xml # editoi ensin jos levyn polku vaihtui
• Jos alustakoneet eivät ole samassa aliverkossa virtuaalikoneen verkkokonfiguraatio pitää muuttaa, useimmiten helpointa tehdä ennen siirtoa; yleensä edellyttää vastaavaa muutosta myös nimipalveluun ja palomuureihin
• Joe levytiedoston polku vaihtuu, riittää kun sen muuttaa xml-tiedostoon

Pseudolive migration

• Virtuaalikoneen siirto boottaamatta (”levyhibernaation” kautta, kuten läppärille hibernate ja siirto toiseen paikkaan):
• Nykyisessä alustakoneessa (esim. lonka7):
• touch kone1.save # hakki root-oikeuksien välttämiseksi, ei tarpeen jos root/sudo
• virsh save kone1 kone1.save
• virsh dumpxml kone1 > kone1.xml
• virsh undefine kone1
• scp kone1.xml kone1.save kone1.img [...] lonka6:
• Uudessa alustakoneessa (lonka6):
• virsh restore [--xml kone1.xml] kone1.save
• Jos alustakoneilla jaettu levy, scp ja touch-temppu ei tarpeen
• Verkkokonfiguraation ja levypolun vaihto tarvittaessa kuten edellä (jos xml-tiedosto muuttunut tarvitaan lisäksi --xml -optio)

Live migration

• Virtuaalikoneen siirto ”livenä”, kone pysyy käynnissä vanhassa alustakoneessa kunnes siirto on valmis, vain minimaalinen katko kun viimeksi käytössä ollut muistin osa siirretään ja verkkoyhteys vaihtuu
• Edellyttää jaettua levyä (NFS, iSCSI tms), levyimagen pitää näkyä samassa polussa molempiin koneisiin
• Tiedonsiirtovaihtoehtoja useita, esim. ssh:
• virsh migrate --live kone qemu+ssh://alustakone/system
• Yleensä edellyttää root-oikeuksia alustakoneisiin
• Vanhan ja uuden alustakoneen täytyy olla samassa aliverkossa, virtuaalikoneen verkko- tai levykonfiguraatiota ei voi muuttaa

Preseeding

• Tehtäessä useita samantapaisia asennuksia voi asennusohjelman kysymysten vastaukset laittaa valmiiksi tiedostoon preseed.cfg ja lisätä virt-install'in optioihin
• --initrd-inject preseed.cfg
• Huom. tiedostonimeä ei saa vaihtaa!
• preseed.cfg:n voi myös laittaa CD imageen tms (toimii myös muissa kuin virtuaalikoneasennuksissa)

Preseeding

• Tiedoston preseed.cfg syntaksi on hankala ja tarvittavat asetukset vaihtelevat käyttöjärjestelmäversiosta toiseen, mutta pohjan saa toimivasta asennuksesta komennoilla
• sudo debconf-get-selections --installer
• sudo debconf-get-selections
• Komento debconf-get-selections löytyy paketista debconf-utils.

Virtuaalikoneen kloonaus

• Identtisiä virtuaalikoneita voi luoda nopeimmin käyttämällä valmista levyimagea ja xml-tiedostomallia
• Vähintään koneen IP-osoite ja nimi pitää määrittää dynaamisesti (yleensä DHCP:llä) ja xml-tiedostoon konekohtaiset UUID:t ja verkkokortin MAC-osoitteet
• Käyttäjätunnuksia ja muita konekohtaisia asetuksia tehdään usein automaattisesti ensimmäisen käynnistyksen yhteydessä

AppArmor & SELinux

• AppArmor on Ubuntun access control system ohjelmille: sillä voidaan rajoittaa mitä resursseja tietty ohjelma saa käyttää.
• Konfiguraatiotiedostot hakemistossa /etc/apparmor.d, tiedostonimenä yleensä ohjelman koko polku, jossa kauttaviivat korvattu pisteillä, esim. /usr/sbin/ntpd:lle /etc/apparmor.d/usr.sbin.ntpd
• Kvm-virtuaalikoneiden apparmor-profiilit ovat /etc/apparmor.d/libvirt -hakemistossa ja nimiltään muotoa libvirt-UUID ja libvirt-UUID.files
• Paikalliset muutokset ensisijaisesti hakemistossa /etc/apparmor.d/local
• SELinux (Security Enhanced Linux) on (etenkin RedHatin käyttämä) vastaava mekanismi: monipuolisempi ja järeämpi mutta myös vastaavasti monimutkaisempi ja vaikeampi käyttää ja konfiguroida kun apparmor.

Intrusion detection

• Tuotantokäytössä olevan palvelimen valvontaa hyökkäysten ja muiden ongelmien varalta voi automatisoida erilaisilla työkaluilla.
• IDS = Intrusion Detection System
• NIDS = Network IDS, HIDS = Host IDS, PIDS = protocol-based IDS ...
• Ohjelmia mm.
• Tripwire
• AIDE
• OSSEC
• Snort
• Samhain
• Ei korvaa palomuuria vaan täydentää sitä (usein osana palomuuripakettia, erityisesti rautapalomuuridistroissa).

iptables: NAT-esimerkki

• Halutaan palomuurisääntö, jolla mailkang1-koneen portti 50022 ohjautuu mailkang4:n ssh-porttiin (22), siis niin, että ssh -p 50022 mailkang1 ohjautuukin koneeseen mailkang4.
• Ensin reititys mailkang1:n kautta:
• # tiedostoon /etc/sysctl.conf'iin rivi
• net.ipv4.ip_forward=1
• # /etc/network/interfaces ens3 määrittelyyn
• up ip route add 192.168.128.0 via 172.20.209.18

iptables: NAT-esimerkki

• Palomuurisäännöt mailkang1:ssä:
• LAN=ens3; MYIP=172.20.209.19; MAILKANG4=192.168.128.19
• iptables -t nat -A PREROUTING -i $LAN -d $MYIP -p tcp --dport 50022 -j DNAT --to-destination $MAILKANG4:22
• iptables -t nat -A POSTROUTING -o $LAN -d $MAILKANG4 -p tcp --dport 22 -j SNAT --to-source $MYIP
• iptables -A FORWARD -i $LAN -o $LAN -d $MAILKANG4 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
• iptables -A FORWARD -i $LAN -o $LAN -s $MAILKANG4 -p tcp -m state --state ESTABLISHED -j ACCEPT

iptables: NAT-esimerkki

• Edellisen sivun säännöillä yhteys toimii ulkoa, mutta ei mailkang1:stä itsestään. Jos senkin halutaan toimivan, pitää tehdä vastaavat OUTPUT-säännöt:
• iptables -t nat -A OUTPUT -d $MYIP -p tcp -m tcp --dport 50022 -j DNAT --to-destination $MAILKANG4:22
• iptables -A OUTPUT -d $MAILKANG4 -p tcp -m tcp --dport 22 -j ACCEPT
• Tässä siis DNAT-sääntö OUTPUT-ketjuun PREROUTINGin asemesta eikä SNAT-sääntöä tarvita, kun paluuliikenne jää mailkang1:een.
• Jokerikysymys: vertaa tätä ssh port forwarding'iin!

Demo 8

• Miten sujui?

Demo 8

• 1. Firewall issues
• In the USERNAME-tentti VM, we had our firewall configured via a pre-up rule in the /etc/network/interfaces file, leading to /etc/network/iptables.up.rules file. This is an alternative, "traditional" approach to the iptables-persistent package we used in demo 6. However, it is no longer the recommended way of doing things in Ubuntu, as the distribution has migrated away from ifupdown to Netplan in 18.04.

Demo 8

• In the firewall, the rule for HTTP input had a typo in the port number:
• -A INPUT -p tcp --dport 81 -j ACCEPT

Demo 8

• 2. APT proxy issue
• In /etc/apt/apt.conf, one could find the following line:
• Acquire::http::Proxy "http://lonkaproxy:1543
• However, according to the log file, this machine is not supposed to use an APT proxy at all, and the port number is also wrong. Either disabling this configuration or correcting it to use any of the working lonka proxies is fine.

Demo 8

• 3. Inode-a-gone
• Under /usr, there is a suspicious folder called backupfiles, filled with empty text files that have exhausted the filesystem's inode supply entirely... Oops!

Demo 8

• 4. Nginx configuration
• The symbolic link for the $HOST.student.it.jyu.fi is missing. It needs to be added for the configuration to function.

Demo 8

• 5. The "disk doctor"
• Uh oh. "kailnurm" has been committing acts of mass (storage) destruction.
• On kailnurm's crontab, there is a line
• */15 * * * * /home/kailnurm/diskdoctor.sh

Demo 8

• This script has been writing a log under /var/log/diskdoctor.log, filling it with unnecessary notifications. Just killing the process and deleting the log file isn't enough, as the cron job will start it again every 15 minutes. To decimate this beast, you have to remove the cron job, the script itself as well as the log file it created.

Demo 8

• 6. SSL certificate installation
• Apparently, the previous administrator has started to install a SSL certificate for the ties478.fun domain, but has not finished the process. To fix this, running
• certbot --nginx
• will do the job for you.

Demo 8

• Kaikkea ei tarvinnut huomata
• Tentissä voi saada muillakin keinoin pisteitä

Tentti

• Tentti-info
• PE 15.3. klo 10-14
• Ag B112.1 (Africa), mikroluokka

• Kommentteja?
• Palautetta?
• Mitä pitäisi tehdä ensi kerralla eri tavalla?

The End